[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: specification language?



At the LA IETF, there were two decisions at the WG meeting: keep it 
simple, and start with requirements. For me at least, the spec language 
issue doesn't fall under either, _yet_.

Some of my requirements.  SPKI certificiates should be able to be used 
as part of a system
1. .. for key exchange in TLS (or  SSL or PCT, which will become its 
predecessors).
2. ... for key exchange in IPSEC.
3. .. for privacy, authenticity and integrity in a mail system alongside PGP.
4. ... to sign executables and other documents I fetch over the web so 
I can be assured of their authenticity and integrity.

Much lower priority is signing contracts that have decades long 
lifetimes, or signing credit-card purchase slips (only because Visa and 
MC have their own standard; otherwise this would be high priority).

Simple. Very _very_ roughly, just to put up a target to shoot at, the 
basic kinds of things that need to be in a cert could be expressed 
using a RFC822-like form:
        Cert-Name:      <DNS-name>
        Issuer-Name:    <DNS-name>
        Key:            <base64>
        Expires:        <RFC1123-date>
        Serial:         <RFC822-msgID>
        Sig:            <base64>

Cert-name
is a DNS name where the certifcate is stored. US-ASCII.  Doesn't solve 
the "friendly name" problem, but that's not simple, and (bald 
assertion) can be solved at a higher layer. The cert-name is under the 
control of the issuer, who guarantess that it is not a duplicate of any 
one they have certified before.

Issuer-name
is the DNS name of the signer of this certificate, and where the public 
key (DNSSEC) or spki-cert of the issuer can be found. (I haven't 
thought about how to work integration with DNSSEC, so that part of this 
statment may be totally bogus),

The issuer could be a commercial certificate authority or just another 
person. (The verification of authenticity would end when I get to a 
cert or key that I got by an apriori secure means.)  The only "policy" 
in this cert is that the issuer was shown a key and generated a unique 
DNS name which it  bound to that key.  The name itself is semantics 
free and has no necessary connection to with the identity of the 
requestor of the cert.

Key
is the public key associated with the Cert-Name encoded using base64.

Expires
date that the cert expires. In US-ASCII in RFC 1123 (updated RFC822) 
format. Converted to local language/conventions by user agent.

Serial
serial number. Uses same algorithm as mail Message-IDs. Can be used in a CRL.

Sig
signature, using the signing key of the issuer, of the certificate.

This cert in fact can do very little.  For example, with it, if Joe 
tells you "use the the key in cert mabel.certrus.com to communicate 
with me", then you can be know  that if you get a message signed with 
said key and if you have knowledge of the issuer's key, then you know 
it came from Joe (if the cert hasn't expired or been revoked or keys 
compromised, etc., etc.).

But it can be used as a building block. With it, one can build a 
database of entries, signed by a person or agency I trust, that (as an 
example) have the _localized_ name, address, picture, etc, of various 
people and the names of their certificates. Another database could hold 
the DNS names for various web servers and their certificates. Such 
databases can be tailored to an application area, without having to 
complicate the underlying certs. This WG may or may not want to design 
such databases for various applications -- although we probably want to 
do at least a couple to convince ourselves that we got the certs right.

Back to spec language.  We can't and don't need to decide on it yet.  
For example, if we took an approach like the above, then the spec 
language would be English and RFC822 BNF. If we took a different 
approach, it would be ISO-ese and ASN.1. We've got to decide on the 
requirements first -- even what I said above jumps the gun. I only said 
it to make plausible that there are problems that we can duck, er, 
solve at a higher layer, and so keep this simple --- or at least 
decompose the problem into smaller problems.

Paul