[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
SDSI name interpretation
>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: <owner-spki@c2.org>
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: <URL:http://www.c2.net>
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 <cme@cybercash.com>
Subject: SDSI name interpretation
Cc: "Brian M. Thomas" <bt0008@entropy.sbc.com>, 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 |
+--------------------------------------------------------------------------+