Re: Certificate proposal
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 #---
-----BEGIN PGP SIGNED MESSAGE-----
Date: Mon, 02 Oct 1995 14:48:26 -0700 From: Bill Stewart <stewarts@ix.netcom.com>
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?)
The whole issue of CRLs is on shaky ground with me. I think it's gotten lost in debates about how to distribute them offline (or perhaps via e-mail) and have them work. CRLs are like the old credit card or check stop lists which used to be at every supermarket checkout station. They aren't there any more. Checkout stations are now on-line. I see nothing wrong with having a "certificate" which says ``certificate available online only at xxx@yyy.zzz''.
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?
Yup -- and it's ugly. It counts on a defined OBJECT ID to define the attribute. That means that if you want to say something about a person ("Boy, she's good looking!") you need to get someone tied to the OBJID hierarchy to issue you a number. If that number is low enough in the tree, (is long enough), then you have the problem that no one knows what it means. For that matter, even numbers high in the tree are unknown to me. I've never seen a dictionary of OBJECT IDs.
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=
Clearly. One should never wait for ISO. In fact, ISO should probably be ignored from now on. (Have you seen on-line Dilbert today?) but back to the question: the slack to use other mechanisms is the weak link I was talking about. You are building a chain from attribute or permission or authorization over to a person where one link (certificate) is a steel link and the other (binding to person) is mercerized cotton. If you want to strengthen the second link, you have to do things like the national ID card -- or restrict the second link to corporate use (the current approach) -- or otherwise regiment the human body in physical space. By chaining directly from key to authorization, the human can be anonymous in physical space while still being known in cyberspace. The thing to avoid is the following:
Make a determination in your own mind whether this key actually belongs to the person whom you think it belongs to, based on available evidence. If you think it does, then based on your estimate of that person's integrity and competence in key management, answer the following question:
The only way to make that determination is to look at the text string and the list of other people who have signed it -- to see if I think they might know a different Bill Stewart from the person I know. But then, since I don't know Bill Stewart at all (except by postings), that's irrelevant to me. Therefore, I can not meet that test. However, there is no reason for me to reject your key as invalid. What's invalid is the assumption that there must be a relationship (or even a person) in physical space *before* one can have a relationship (or a person) in cyberspace.
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?"
I prefer text. I didn't say it had to be free form -- only that it had to include free form so that I could say, from one human to another, something which no one had anticipated and sign that. If you want a machine to read it, you can use SMTP-style "tag: value". The idea that machine readability requires binary transfer and/or ASN.1 encoding (e.g., OBJECT IDs) is ludicrous.
If you look at Verisign's DNs, or the text in my PGP keys, you'll see various ugly attempts at this.
I looked at your keys, just now, and see a whole bunch of keys but no statements like: "this person is allowed to withdraw money from bank account 017123 of xxx" or "this person is a trusted co-conspirator in the group called Cypherpunks" or anything else useful to me. I tried adding an informative UserID to my key on the MIT server -- and it came out as my primary ID. ...big mistake..
And then there's "WHICH person named Bill Stewart does this key belong to?"
Exactly. Back to my point: the fact that you're named ``Bill Stewart'' and are a person is probably important to you -- but if I'm accepting your e-check, I don't give a damn about either. What I care about is whether the signature on the e-check (ie., the public key) is certified by the bank. In checking that authorization (attribute), I don't need to refer to a person's name. That's an irrelevant step in the process, brought on by the way X.509 and PGP both define certificates.
For the latter, I'm interested in solutions other than "Social Security Number", "Citizen-Unit Nationalized ID Card Number", etc.
Amen! - Carl +--------------------------------------------------------------------------+ |Carl M. Ellison cme@tis.com http://www.clark.net/pub/cme | |Trusted Information Systems, Inc. http://www.tis.com/ | |3060 Washington Road PGP 2.6.2: 61E2DE7FCB9D7984E9C8048BA63221A2| |Glenwood MD 21738 Tel:(301)854-6889 FAX:(301)854-5363 | +--------------------------------------------------------------------------+ -----BEGIN PGP SIGNATURE----- Version: 2.6.2 iQCVAwUBMHFF/lQXJENzYr45AQEMwQP8Dw1yd4vHzYGY57FpwWlWxquJLHsS3LrJ tVYEEpCXu7/lGcHVd2o2KDeZHZy7r6qiQ7zo5eayFQlIkRPYjBmRzuvADwLisR7D NK7l6dFVY2fA+SAmLiMtwz2VzsByZGB8HYw3joc+erNfmAmjeOLyVeg5pTaP9Rnu /Xb2SWE4d14= =WVyj -----END PGP SIGNATURE-----
participants (2)
-
Bill Stewart -
Carl Ellison