[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: persistent identities
> >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.
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.
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.
* technically, one would probably use the attribute type SerialNumber (5)
instead of CommonName (3) to represent a bank account number in a