The only danger to such a world of peace would be those who refuse goverment signed keys and use their own payment provider and trade amounst themselves, they would have to be hunted down seperately.
The original issue involves three factor authentication
* something you have * something you know * something you are
A public key can be representative of hardware token ... say a token where the private key is generated on the token and is designed to never leave the token. A digital signature that can be verified by the corresponding public key can be used to infer possession of the hardware token (something you have). Furthermore, a hardware token can be designed to only work in a specific way when the appropriate pin/password (something you know) or biometric (something you are) have been entered into the token. The entity receiving the digital signature doesn't need a copy of the pin/password or biometric (making it a shared-secret) but infers by the operation of the hardware token that there has been something you know &/or something you are authentication to have happened.
An institution can enroll the person in possession of the token using whatever processes they feel necessary (say anonymous for ISPs up to "know your customer" identity as required by various legislation for financial institutions).
The issue is that can the validating of the entity in possession of the token be a separate business process issue from validating the integrity of the hardware token. The idea is that the integrity of the hardware token can be treated as a totally separate business process from the process of validating the entity being enrolled (an entity that happens to possess the hardware token).
Treating them as totally separate business process doesn't preclude collapsing the enrolling of the entity and enrolling the hardware token into a single process. However, not treating them as separate business process will pretty much preclude ever being able to treat them as separate processes.
So the question is as part of the enrolling process, can the integrity of the hardware token be treated as a totally separate business issue from the characteristics of the entity in possession of the hardware token, say like the advertisements for the service that allows being able to research the history of a used car. Most institutions already have all sorts of business processes involved with enrolling the characteristics of an entity. What would be the incremental requirement for adding being able to enroll (& trust) the integrity of a consumer presented hardware token.
So, i'm a little bit biased, I claimed that I ruthlessly discarded all feature and function from AADS chip strawman that wasn't needed for trusted authentication
http://www.garlic.com/~lynn/index.html#aadsstraw
complexity can contribute to insecurity ... KISS and focus can contribute to security.
--
Anne & Lynn Wheeler http://www.garlic.com/~lynn/
Internet trivia 20th anv http://www.garlic.com/~lynn/rfcietff.htm
--------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
