[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: yet another <auth> type

David,

	thanks for being the straight man.  This is why I posted the idea.
Otherwise, I agree with Pat that there's no reason to talk about
additional auth types.  They're very easy to add.

	[I did note the request for documentation on that procedure.]


At 12:27 PM 2/24/97 -0500, David P. Kemp wrote:
>> From: Carl Ellison <cme@cybercash.com>
>> 
>> It makes sense to issue an SPKI cert for the statement:
>> 
>> "The subject keyholder (K1) is the same person as the keyholder of (K2), on 
>> <date>."
>> 
>> This allows someone to start a service by which someone can map old keys to 
>> new ones.
>> 
>> Thoughts?
>> 
>>  - Carl
>
>
>It sounds like a duct-tape patch for the fundamental limitation of
>SPKI certs.

I agree with you.  I was prepared to shoot this down shortly myself, after 
it generated discussion.  The problem with my original suggestion is
that <auth> wasn't being mapped through the service provider.  If you do
map the <auth> through that service provider, then you have just reinvented
a certificate issuing service.  You can do that, or you can go back to the
original issuer (who should retain control over its own certs anyway) and
have it issue the new certs.

Alternatively, you can ask all your issuers to issue certs to a persistent
"identity" -- a super-long key, held by your service provider for you --
and let that provider declare a group of members, all of which are your
own (temporary) keys.  In SPKI such a group is a signature key.  In SDSI
it's a name.

>The premise of SPKI is that persistent identities are an unnecessary
>middle step between the public key and the "stuff" (names, email
>addresses, priviledges, etc) to be attached to that key.  Therefore
>persistent identities have been eliminated as a concept from SPKI.

I would rather say that as we discussed other people's attempts at providing 
persistent identities, c/o X.509, we discovered that they failed.  If 
persistent identity were possible, then it might be desirable to indirect 
through it.  However, I'm not sure it's possible in the first place, short 
of doing something like tattooing numbers on each human's forearm (or 
forehead).  I'm therefore not sure it's acceptable in the land of the free.  
There's a basic freedom in the US to change your identity -- do adopt an 
assumed name and start over -- to enter your own witness protection program.

There might be a method of doing persistent identity which doesn't prevent 
someone from changing his or her identity.  My original note was a step in 
that direction.

As was pointed out, an especially long key might be used as a master 
identity for someone.  However, as I believe you would second, I've said on 
occasion that a name has the advantage that it's invulnerable to 
cryptanalytic attack.  The problem is that it's not invulnerable to theft 
(spoofing), unless it is tied to something truly attached to the human -- 
like a tattoo on the forehead or a complete DNA map.  It also depends on
a trusted third party.  [If we subsume SDSI, we allow for that 
possibility, without requiring it.  It doesn't remove the S in SPKI.
It leaves choice of an identity-provider and indirection service as an
option up to the user.]

My preference for providing persistent identity is the one I presented at 
USENIX Security last year.  In that paper, I define identity Webster's way, 
as "the distinguishing character or personality of an individual".  In 
particular, identity is established via shared memories (shared secrets, in 
a sense).  If one uses that definition of identity (contents of a mind), 
then one can back up any certificate issuance service with a means of 
issuing new certificates to a new key for an old person, based on proof of 
identity via shared secrets.  Common practice is to use something weak like 
mother's maiden name for this purpose -- but it's possible (as I 
demonstrated) to make the association arbitrarily strong.

 - 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        |
+------------------------------------------------------------------+