include "keyring.m"; keyring := load Keyring Keyring->PATH; SigAlg: adt { name: string; }; PK: adt { sa: ref SigAlg; owner: string; }; SK: adt { sa: ref SigAlg; owner: string; }; Certificate: adt { sa: ref SigAlg; ha: string; signer: string; exp: int; }; DigestState: adt { # hidden state copy: fn(d: self ref DigestState): ref DigestState; }; Authinfo: adt { mysk: ref SK; mypk: ref PK; cert: ref Certificate; spk: ref PK; alpha: ref IPint; p: ref IPint; };
Each collection is discussed in turn.
An IPint can be converted into two external formats. The first is an array of bytes in which the first byte is the highest order byte of the integer. This format is useful when communicating with the ssl(3) device. The second is a MIME base 64 format, that allows IPints to be stored in files or transmitted across networks in a human readable form.
For public keys algorithms to work, there must be a way to distribute the public keys: in order to verify that X signed something, we must know X's public key. To simplify the problem, we have instituted a trust hierarchy that requires people to know only the public keys of certifying authorities (CAs). After generating a public key, one can have the concatenation of one's name, expiration date, and key signed by a CA. The information together with the name of the CA and the signature is called a certificate.
At the beginning of a conversation, the parties exchange certificates. They then use the CA's public key to verify each other's public keys. The CA's public key, a system wide Diffie-Hellman base and modulus, one's private key, one's public key and certificate are kept in a Limbo adt called Keyring->Authinfo. An Authinfo adt can be read from from a file using readauthinfo or written to a file using writeauthinfo, both from keyring-auth(2).
Authinfo adts are normally created during the login and registration procedures described below.
Encoding uses the line formats provided by the Secure Sockets Layer. See security-intro(2) for more detail.
The login procedures are used by typed commands and by programs using Tk. The login procedure relies on the CA and the user having established a common secret or password. This is done securely off line, perhaps by mail or telephone. This secret is then used to provide a secure path between CA and user machine to transfer the certificate and CA public key. See security-intro(2) for more detail.
The registration procedure is built into the mux(1) interface and is intended for the set top box environment. When the set top box is first turned on, it creates a public/private key pair and dials the service provider's CA to get a key signed. The CA returns its public key and a signed certificate, blinded by a random bit string known only to the CA. A hash of the information is then displayed on the user screen. The user must then telephone the CA and compare this hashed foot print with the one at the CA. If they match and the user proves that he is a customer, the CA makes the blinding string publicly known.
KEYRING-INTRO(2 ) | Rev: Thu Feb 15 14:43:27 GMT 2007 |