[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
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:
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.
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.
is the public key associated with the Cert-Name encoded using base64.
date that the cert expires. In US-ASCII in RFC 1123 (updated RFC822)
format. Converted to local language/conventions by user agent.
serial number. Uses same algorithm as mail Message-IDs. Can be used in a CRL.
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.