At 11:53 AM 10/2/95 EDT, Carl Ellison <cme at 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 at ix.netcom.com
# Phone +1-510-247-0664 Pager/Voicemail 1-408-787-1281
#---