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

Re: persistent identities

At 12:23 PM 2/26/97 -0500, David P. Kemp wrote:
>> >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.
>  Since you are the second to misinterpret what I meant to say, I must not
>have said it very clearly.  I'll try again.


	I was probably responding to others rather than you.  There are those who 
advocate ID certificates in order to prevent someone's generating a second 
key for himself and avoiding negatives attached to his previous "name".  I 
realize that you weren't doing that, but these arguments are stored together 
in my mind and when ID certs are advocated I tend to reply to both.

>By "persistent identity", I meant persistent with respect to a single
>CA, not a unique ID permanently attached to a particular human.  Say
>you open a Swiss bank account, and get an account number from the bank.
>If you open another account with a different bank, you get a different
>number, totally unrelated to the first.
>My only point was that if the account number (your identity to a single
>bank) is actually your SPKI public key, then updating keys as a routine
>good crypto practice means updating your identity.  That's much more
>clumsy than updating your key but keeping the same identity.

I think we are in agreement, or very close to it.

I did have one second thought after sending my previous message to you.  
When I said that a name is not subject to cryptanalysis, that's true -- 
however, I didn't mean to imply that the whole process is less vulnerable to 
cryptanalysis if names are used.  The CA (in your terminology) must still 
have a key and that key is subject to aging, theft, breaking, ....

When you indirect through some CA's key, using a name local to that CA, you 
have the same number of keys as if you had generated your own long SPKI 
group key to indirect through.  The CA might protect its key better than you 
could, but then the CA's key is used for so many different people that it 
becomes more attractive for attack or subversion.  A true risk analysis of 
this situation might be interesting to see.  I wonder (not expecting an 
answer) if NSA has already done such an analysis....

>An X.509 cert with subject name C=CH, O=Bank of Geneva, CN=03827a6b387283fd29*
>would do just fine in this environment, without any adverse privacy
>considerations for the account holder.  The account holder can "write
>checks" using the same "name" for as long as the account is active, while
>still being able to refresh his keys every year.

I think we're coming to a real agreement.  If you indirect through something 
more secure than your daily key, you can achieve the ability conveniently to 
change daily keys without disturbing the slumber of the folks who have 
issued you authorizations.  Given that as agreed, we come to the question of 
who owns the indirection and whether it is via a name or a key.  The name 
versus key choice is the difference between SDSI and SPKI group definitions. 

The new draft (to be posted soon) proposes extending the Subject field to be:

1)	a public key
2)	the hash of a public key
3)	a SDSI name which can map to a public key (at least eventually)
4)	the hash of an object

With (4), one can issue SPKI certificates which apply specific attributes to 
some signed document or code (e.g., "I've tested this code for viruses" or 
"I give this program a rating of 4 mice" or "I'm VP # 6 and sign this P.O.").

With (3), SPKI can create SDSI groups -- ie., indirecting through a name.

However, as I argued above, the use of a name doesn't reduce the number of 
keys involved in the path and therefore may not increase security at all.
Security might be decreased by the use of a name (on the theory that each
extra link -- each indirection -- is a new potential point of attack).

The question of who owns the indirection is also up to the user.  SPKI 
allows a user to generate and hold onto his own indirection key or  
a trusted third party to do that for the user.  My preference is to hold 
the indirection myself, but I can see arguments on both sides.  (For 
example, if a TTP does it, they might define a phone number and voice 
protocol for you to use to declare a key compromised.)

>* technically, one would probably use the attribute type SerialNumber (5)
>  instead of CommonName (3) to represent a bank account number in a
>  Distinguished Name.

For that matter, have you looked at SET?  They use CommonName for the keyed 
hash of an account number, for cardholder certs.  I would have expected 
X.509 purists to howl at that.


 - Carl

P.S.  The idea of key validity has been nagging at me, but I'll start a 
different thread on that one.

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