[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.
>
>Carl,
>
> Since you are the second to misinterpret what I meant to say, I must not
>have said it very clearly. I'll try again.
David,
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)
or
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 |
+------------------------------------------------------------------+