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

Re: persistent identities




David P. Kemp writes:
> 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.

Actually, your identity is not the key. In fact, the bank cares not
one whit about your "identity" qua "identity" -- the bank cares about
what mechanical procedure it wishes to follow to determine the
legitimacy of requests made of it with respect to a particular
account. The Swiss Bank's decision procedure in this case is simple:
"he who can sign with the private key associated with the public key
associated with this account at our bank may make deposits and
withdrawals, or change the public key bound to the account". The bank
is free to bind an account number to that public key so that it may
maintain continuity of accounting records across key changes, or not
to, as its computers and programmers prefer.

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

Yeah, but why bother? In any case, as has been mentioned here in the
past, this isn't the X.509 bashing or discussion list, its the SPKI
list. The world is a big enough place to support many different
mechanisms for doing the same thing; SMB and NFS are both file sharing
protocols that work just fine, and both are in wide use. The SPKI
constituency would like something much simpler than X.509 for its
uses, but this doesn't preclude others from using X.509 if they wish.

Perry

References: