To: hallam@Etna.ai.mit.edu From: Carl Ellison Subject: SDSI name interpretation Cc: "Brian M. Thomas" , spki@c2.org, hallam@Etna.ai.mit.edu Bcc: X-Attachments: >Subject: Re: comments on client auth At 04:39 PM 6/13/96 -0400, hallam@Etna.ai.mit.edu wrote: >I think that we should be clear to distinguish between two different >interpretations of chained namespaces. IN SDSI I can create a name using a path >- "RSA.com's Verisign.com" I think that this is impractical since it fragments >the namespace preventing any equality tests is RSA.com's verisign.com the same >as openmarket's ? > >The basis of the Web is to finesse the naming scheme issue by overloading DNS. >So the statement becomes "The entity which rsa.com believe to have IANA DNS >registration verisign.com" as opposed to "The entity which rsa.com calls >verisign.com". I recomend that SPKI follow the Web epistemology. I have to come down on the side of SDSI's original scheme. What you're asking for is covered by SDSI as (rsa.com's DNS's verisign.com) which is probably the same as (openmarket's DNS's verisign.com). As for equality testing, that's where I believe there are two interpretations of chained names which need to be distinguished. The individual at the end of that chain, if it's an individual, owns (controls) a public key (probably a signature key). If the end of the chain is a group, that group could be indicated by a signature key (used only to sign notices of group membership or non-membership). Either way, a chain can resolve to something unique in the world and those unique things can be compared for equality. The other interpretation is that the name chain is a little program -- the outline of a dynamic process for determining group membership. In this case, even an individual is a group of 1 -- with every chain entry except the last empowered to redefine its link in the chain on the fly. Both of those interpretations have value. --------------------- The way I like to think of a SDSI chain is that it is a compact representation of the linkages in some relationship. If the links were labeled (e.g., (ron's [neighbor] jim's [daughter] daughter) rather than (ron's jim's daughter) then we could call them full relationship statements. Let's say, for example, that Ron knows I do massage and am fascinated by cryptography and also knows that Jim's daughter shares those two interests -- so he introduces us electronically and by certificate chain. I now have a certified intro path not only to Jim's daughter but to her key. So, I start a secure e-mail conversation with her. I also file her key in my local database under her nickname Ami and generate my own certificate for her key, binding it to my name for her. (ron's jim's daughter) = (carl's ami) Under one interpretation, that equality holds. Under the other it doesn't. Under the interpretation that the equality does hold, it might hold only for a short period of time. (e.g., Jim could disown Ami for having encrypted conversations with someone as disreputable as I am and then adopt a new daughter :) -- or Ron could move away and in his new neighborhood find a new neighbor named Jim -- or Ron could have a falling out with Jim over a lawn mower and purge Jim from his database, letting his cousin Jim have that nickname now so that (ron's jim's daughter) refers to Cousin Jim's 3-yr-old, Tiffany.) - Carl From ???@??? Fri Jun 14 13:31:06 1996 Return-Path: Received: from callandor.cybercash.com (callandor1.cybercash.com) by cybercash.com (4.1/SMI-4.1) id AA25336; Fri, 14 Jun 96 12:49:36 EDT Received: by callandor.cybercash.com; id MAA10935; Fri, 14 Jun 1996 12:46:26 -0400 Received: from infinity.c2.org(140.174.185.11) by callandor.cybercash.com via smap (V3.1) id xma010906; Fri, 14 Jun 96 12:46:12 -0400 Received: (from daemon@localhost) by infinity.c2.org (8.7.4/8.6.9) id JAA03078 for spki-outgoing; Fri, 14 Jun 1996 09:43:54 -0700 (PDT) Community ConneXion: Privacy & Community: Message-Id: <2.2.32.19960614164500.003aadf8@cybercash.com> X-Sender: cme@cybercash.com X-Mailer: Windows Eudora Pro Version 2.2 (32) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 14 Jun 1996 12:45:00 -0400 To: hallam@Etna.ai.mit.edu From: Carl Ellison Subject: SDSI name interpretation Cc: "Brian M. Thomas" , spki@c2.org, hallam@Etna.ai.mit.edu Sender: owner-spki@c2.org Precedence: bulk >Subject: Re: comments on client auth At 04:39 PM 6/13/96 -0400, hallam@Etna.ai.mit.edu wrote: >I think that we should be clear to distinguish between two different >interpretations of chained namespaces. IN SDSI I can create a name using a path >- "RSA.com's Verisign.com" I think that this is impractical since it fragments >the namespace preventing any equality tests is RSA.com's verisign.com the same >as openmarket's ? > >The basis of the Web is to finesse the naming scheme issue by overloading DNS. >So the statement becomes "The entity which rsa.com believe to have IANA DNS >registration verisign.com" as opposed to "The entity which rsa.com calls >verisign.com". I recomend that SPKI follow the Web epistemology. I have to come down on the side of SDSI's original scheme. What you're asking for is covered by SDSI as (rsa.com's DNS's verisign.com) which is probably the same as (openmarket's DNS's verisign.com). As for equality testing, that's where I believe there are two interpretations of chained names which need to be distinguished. The individual at the end of that chain, if it's an individual, owns (controls) a public key (probably a signature key). If the end of the chain is a group, that group could be indicated by a signature key (used only to sign notices of group membership or non-membership). Either way, a chain can resolve to something unique in the world and those unique things can be compared for equality. The other interpretation is that the name chain is a little program -- the outline of a dynamic process for determining group membership. In this case, even an individual is a group of 1 -- with every chain entry except the last empowered to redefine its link in the chain on the fly. Both of those interpretations have value. --------------------- The way I like to think of a SDSI chain is that it is a compact representation of the linkages in some relationship. If the links were labeled (e.g., (ron's [neighbor] jim's [daughter] daughter) rather than (ron's jim's daughter) then we could call them full relationship statements. Let's say, for example, that Ron knows I do massage and am fascinated by cryptography and also knows that Jim's daughter shares those two interests -- so he introduces us electronically and by certificate chain. I now have a certified intro path not only to Jim's daughter but to her key. So, I start a secure e-mail conversation with her. I also file her key in my local database under her nickname Ami and generate my own certificate for her key, binding it to my name for her. (ron's jim's daughter) = (carl's ami) Under one interpretation, that equality holds. Under the other it doesn't. Under the interpretation that the equality does hold, it might hold only for a short period of time. (e.g., Jim could disown Ami for having encrypted conversations with someone as disreputable as I am and then adopt a new daughter :) -- or Ron could move away and in his new neighborhood find a new neighbor named Jim -- or Ron could have a falling out with Jim over a lawn mower and purge Jim from his database, letting his cousin Jim have that nickname now so that (ron's jim's daughter) refers to Cousin Jim's 3-yr-old, Tiffany.) - Carl +--------------------------------------------------------------------------+ |Carl M. Ellison cme@cybercash.com http://www.clark.net/pub/cme | |CyberCash, Inc. http://www.cybercash.com/ | |207 Grindall Street PGP 2.6.2: 61E2DE7FCB9D7984E9C8048BA63221A2 | |Baltimore MD 21230-4103 T:(410) 727-4288 F:(410)727-4293 | +--------------------------------------------------------------------------+