At 11:53 AM 10/2/95 EDT, Carl Ellison <cme@TIS.COM> wrote:
X.509 certificates are not totally bad. Their structure contains lessons for anyone designing a certificate structure. [Raw X.509 does not imply a hierarchy, I believe. Steve Kent & Co. do.]
I agree with you about hierarchies, and even RFC1422 doesn't really force you to use hierarchy, much less a government-enforced one, though it clearly prefers it, and it definitely does support the concept of having a key signed by more than one CA, at least for CA's keys. The most important differences, from my perspective, are 1) X.509 explicitly addresses Certificate Revocation Lists, though it isn't real precise about how they should be distributed, and the hierarchical approach isn't necessarily the best. (Maybe put the location of the preferred CRL for a key certificate in the cert itself?) 2) X.509 certificates, unlike PGP, only support once signer per certificate; this is a slight hierarchical bias, which forces you to haul around a pile of certificates to have multiply signed keys, without specifying a syntax, so simple key-cert programs may not know what to do with multiples, and hence force hierarchy; the rest of us will just have to deal with multiply syntaxes. But that's mainly a verbosity problem, duplicating Distinguished Names and key info. 3) Neither PGP nor X.509 (as documented in the RFC1422 and PKCS#6) have any mechanism for additional information other than cramming it into the username, but supposedly X.509 Version 3 includes something?
Perhaps the biggest problem is the use of a name -- a text string (or some abortion like the DN which can be reduced to a text string) -- as the anchor point. [.... use the public key instead ....] What remains is a need for attributes to be bound to a key. ... Current certificates are going down a fundamentally wrong path. They are trying to bind keys to people and let Society somehow bind attributes to people -- but the latter binding is too weak to permit keys to be bound to attributes or permissions.
Eventually, there may be a way to represent most of the attributes you want to describe in some format, which I dare say will look _far_ uglier than ASN.1 :-) Binding a key to a text-string usually representing a person does give you the slack to use other mechanisms rather than wait for the release of /standard-name="Attribute Semantics Notation"/version=32769/ORG="International Slowness Organization"/Country=none/reliability=ExtremelyHighTrustUsThisTime/versionh istory= For now, there do seem to be some kinds of attributes that would benefit from better representations than a human-name plus free-form text, such as "which application does the user want you to use this key for?" "how much should I trust the user's desire to have me use that key for that application?" "how do I get this key's owner to give me money?" "does the key-holder have the authority to speak for a given organization/human/bank account?" If you look at Verisign's DNs, or the text in my PGP keys, you'll see various ugly attempts at this. And then there's "WHICH person named Bill Stewart does this key belong to?" For the latter, I'm interested in solutions other than "Social Security Number", "Citizen-Unit Nationalized ID Card Number", etc. #--- # Thanks; Bill # Bill Stewart, Freelance Information Architect, stewarts@ix.netcom.com # Phone +1-510-247-0664 Pager/Voicemail 1-408-787-1281 #---