X-Sender: cme@cybercash.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3 (32) Date: Sat, 02 May 1998 09:24:29 -0400 To: atodd@csi.com From: Carl Ellison Subject: Re: [E-CARM] authentication essay available (fwd) Cc: Carl Ellison , Alan Lloyd , John Gregory , e-carm -----BEGIN PGP SIGNED MESSAGE----- At 01:11 AM 5/2/98 -0400, Alexander Todd wrote: >What I don't understand in the SPKI proposal is how you would retain the same >unique identifier (name) if it is modified whenever an attribute or the key >itself >changes. > >How can a certificate remain constant to uniquely identify an entity over >time, >while allowing for evolutionary changes to the attributes (rights, privileges, >credentials)? > >An inherent paradox exists with common certificate concepts in that rust in a >certificate is earned over time, while the public key contained within >becomes less >reliable the longer it remains unchanged. So in order to build trust in a >certificate, it must have a long life that allows it to build its credentials over >time. > >How can this be accomplished with SPKI certificates, if the identity >changes with time? I need to write that paper -- on key management under SPKI - or maybe key/identity management. It turns out that whatever key/identity management you envision under any other certificate structure, can be mapped directly to SPKI. The mapping isn't directly obvious, which is why it probably needs a paper. >It seems to me that all you need is a URL to uniquely identify a certificate >globally for use on the Internet. Then you can change the keys and other >attributes at will, especially if they reside as separate instruments >outside the public key certificate itself. A URL is a globally unique name by administrative fiat. Its domain name is unique. However, it's not permanent (as maintainers of web pages of links can attest to). For example, my www.clark.net domain was at my current ISP. If I move, I might want to move ISPs -- and meanwhile that ISP was just bought by a bigger ISP and its domain names are migrating. I believe some of the discussion problem I have on this topic comes from the fact that in our daily lives, we use names as perfectly good identifiers. These are names made unique by administrative fiat where the administrators are parents and the community is only the family or small town. They are not globally unique, but they are statistically unique. As long as the community around us remains small, then the probability of finding someone else with the same name is very small. [It is a side theory of mine that the entropy of names in a given language will be related by the birthday paradox to the size of community typical in that culture, but I haven't tested that hypothesis yet.] If we were to assume that the every-day uniqueness of common names were to hold globally, then it would make sense that that name is a valid identifier (both unique and commonly known) and that it could be permanent. Therefore, it would be superior to anything that could change. However, there is no such name. ------------- To answer your question about how we achieve key/identity management under SPKI, I should take you through an evolution of thoughts: ...for identity lifetimes and key management... 1. assume a commercial CA hierarchy can do key/identity management (because this is where most people have done their reading/thinking so far). 2. note that no commercial CA assigns globally unique names. Rather, it assigns names unique within its domain, where that domain is identified by a root key. It may also make names unique only within a given chain -- that is, that the unique name is a list of names: (ca1 ca2 ca3 user) where ca1, ca2 and ca3 are names of intermediate CAs in the hierarchy. 3. map this to SDSI names. Within the domain of that CA hierarchy, the name becomes (name ca1 ca2 ca3 user). To make this useful to anyone outside that hierarchy (ie., any verifier who recognizes more than one CA hierarchy), you need to note the CA root key as well. In SDSI terms, this is a fully qualified name: (name ca1 ca2 ca3 name). 4. this key may be protected very expensively in the CA (hardware, locked rooms, armed guards, ...), but can be protected very well by an individual user and that user is not subject to the same level of attack, since the key is far less valuable (certifies many fewer other keys and conducting far fewer authorizations). I have designed a software only, normal PC root key mechanism for individual users that is safe from everything but rubber-hose attacks. From this I claim that identity management can have as long a lifetime under SPKI/SDSI as it does under any commercial CA hierarchy. In fact, if a user finds himself under as strong an attack as the commercial CA, then she can buy the same hardware key protection. 5. through SPKI/SDSI's delegation and naming mechanisms, a user can define his own temporary keys to be used (e.g., a week at a time), gathering the authorization delegated to the permanent key. That permanent key for the user can be the raw SPKI identity (the root key itself) or a SDSI name hung off that root key (e.g., (name "me") ). ...for key lifetimes... The SPKI Certificate Result Certificate mechanism (see the drafts) reduces a mixture of certificates (performing authorization, delegation or naming) into a single certificate. That single certificate uses fewer keys than the original chain and therefore has a longer lifetime. The key lifetimes of intermediate (now removed) certificates may be longer than the issuer key of the CRC, but the combined key lifetime is still lower than the CRC's key's lifetime. [I'm speaking of key lifetimes, not certificate lifetimes.] Therefore, if the CRC had been issued directly (key to key authorization, in most cases), then it could have a longer lifetime than the chain it replaces. - Carl -----BEGIN PGP SIGNATURE----- Version: PGP for Personal Privacy 5.5.3 iQCVAwUBNUsejRN3Wx8QwqUtAQEGfQP/fEWN5q302TZTIBx6UF8Y7A0sdPf8pCqL vX9V/e2LxjBhFBoUjPcWf+ZbiLaGgPeVCeYIj8jZINS7Te6ZgKtD0LxG6UkRoh12 hEEtB2pD7D4gLYT2N95iso1ksjxWuur6MUnSr0+bfT7QPK/wNa8RIZazSvm904Yc fCY1S30wC1g= =JkoE -----END PGP SIGNATURE----- +------------------------------------------------------------------+ |Carl M. Ellison cme@cybercash.com http://www.clark.net/pub/cme | |CyberCash, Inc. http://www.cybercash.com/ | |207 Grindall Street PGP 08FF BA05 599B 49D2 23C6 6FFD 36BA D342 | |Baltimore MD 21230-4103 T:(410) 727-4288 F:(410)727-4293 | +------------------------------------------------------------------+ X-Sender: cme@cybercash.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3 (32) Date: Mon, 04 May 1998 02:12:50 -0400 To: atodd@csi.com From: Carl Ellison Subject: Re: [E-CARM] authentication essay available (fwd) Cc: Carl Ellison , Alan Lloyd , John Gregory , e-carm -----BEGIN PGP SIGNED MESSAGE----- At 02:01 PM 5/3/98 -0400, Alexander Todd wrote: >I would suggest that a URL is more permanent than either an IP address or an >e-mail address. One of the reasons that people get domain names and e-mail >addresses that are independent of ISPs is to maintain flexibility in >substituting ISPs. Few things in this world are absolutely permanent, but >URLs established to hold critical information that people must rely upon >over a long period of time would be long-lasting, if not permanent. I would love to have a permanent web address. I have cme@acm.org for e-mail, but nothing yet for my web pages. I agree that the need is very strong. There is also a need for archiving -- maybe for a library. >Second level domain names and their subdirectories can serve to narrow the >community of interest within which a unique, yet usable, name would be >practical. The domain name would provide a narrower context for the >certificate name. Nice try, but when I joined Stratus Computer (stratus.com) in 1987, my old friend Bob Mullen worked there - but so did another Bob Mullen. This was out of 1000+ employees. What if it had been ibm.com? You can do what PGP did: extend common name with a whole e-mail address. That's unique. However, they are neither permanent (for most people) nor in common use. I doubt we'll soon see a time when people stop referring to their friend Sam and instead refer always to friends by e-mail addresses. >It may also be valuable to consider a new first level domain name, such as >.DCS, for Digital Certificate Services, although I am not sure that such a >high level of formality is necessary. Ideally, anyone should be able to >post their own certificate at any URL and be able to have it verified >out-of-band by any relying party. The DNSSEC proposal includes posting of certificates at any domain name (resolved down to individuals), within the DNS database. [re. SPKI CRC] > >That does not follow necessarily, since the attributes (subordinate >certificates) could have key life policies that are shorter, thereby >effectively shortening the valid duration of the new CRC key. I need to explain this more carefully, then. A chain of certificates will have a validity period as a function of individual certificate validity dates. The intersection of those date ranges would give the CRC validity date range. This can never exceed the date range of the individual certificates that were used to compute the CRC result. You can compute another kind of lifetime -- based on the probability of key compromise. This gives a probability distribution vs. time. You can then choose a target probability of compromise and read off a date to correspond to that. If you do that for a chain of certificates using multiple keys: K1 -> K2 -> K3 -> K4 where K1 is the top level issuer here, then the expiration date (computed by key lifetime) will be less for that chain than for the equivalent chain: K1 -> K4 To have this show up in validity dates, you would need K4 to go directly to K1 to get a certificate. However, I was using this in an example of name versus key-only operation. If K2 -> K3 -> K4 is a name to key mapping through a normal CA, then there is a valid comparison here. If K1 issues an authorization through K4's CA-certified name, then you have a chain of the form K1->K2->K3->K4 but if K1 issues the authorization directly to K4, you get K1->K4 The key-lifetime-derived certificate chain validity will be longer for the latter case than the former -- and, for that matter, the certificate validity dates will have a certain probability of being longer in the second case than in the first, assuming the two fragments K1->K2 and K1->K4 have the same validity dates. That's because K2->K3->K4 will have a date range that might not entirely contain the date range of K1->K2 >Nevertheless, I like the notion that SPKI proposes a method of bundling >selected attribute certificates for presentation as a package that is >associated with a relevant identity (real or assumed). I assume that there >would be a method by which the relying party could verify each of the >credentials. >How would the verifier of an SPKI certificate obtain all the public keys of >the various authorizers (permission granting organizations) in order to >verify each credential, especailly in the case of a CRC? Would a trusted >third party be required to sign the CRC bundle, in order to simplify the >verification process? SPKI provides both a mechanism for bundling certificates (and keys) that is different from the CRC. The CRC is a single certificate (e.g., K1->K4) computed from a longer chain. The verifier of the CRC doesn't see the source certificates. Rather, he sees that the issuer of the CRC is directly authorizing the subject with no intermediaries. The bundling mechanism is an S-expression of the form (sequence ...) while the CRC is just another certificate. - Carl -----BEGIN PGP SIGNATURE----- Version: PGP for Personal Privacy 5.5.3 iQCVAwUBNU1cYRN3Wx8QwqUtAQFhCwP/YhC7QMNYAoW+UsFWp3bFE0jix1QOtk6X RC8FRkIXU0/if2YONpY+wTT9dM3C3HMmCZvEdhJLbhbto6Qb7GpGu0/HuvSgh4tX vAUGk9/uWR/fE5ZJbo0+wXoWolA8+HGGOOL0jSEsLenI+wMGyTvkA/UbcMPvyMlM FMIqADFdz04= =Xpo0 -----END PGP SIGNATURE----- +------------------------------------------------------------------+ |Carl M. Ellison cme@cybercash.com http://www.clark.net/pub/cme | |CyberCash, Inc. http://www.cybercash.com/ | |207 Grindall Street PGP 08FF BA05 599B 49D2 23C6 6FFD 36BA D342 | |Baltimore MD 21230-4103 T:(410) 727-4288 F:(410)727-4293 | +------------------------------------------------------------------+