ignoring for the moment the question of why certificates would be needed at all ....
then public/private key technology is currently being used for (at least) two distinct & different business processes 1) authentication 2) encryption The business process of human person authentication has some requirements about impersonation ... leading to a business requirement that only the person being authenticated should have access to the authentication material (aka only the specific person can originate an authenticated transaction). A hardware token that generates the key-pair inside the token and the private key can never leave the token can satisfy unique person authentication thru one-factor authentication "something you have". The person is the only one with their specific token and that token is the only container for their specific private key. The business process for encryption can be totally different. The assets being encrypted may be corporate assets, not the individuals. In the case of using public/private key in conjunction with encryption of corporate assets, the business requirements totally change. The corporation has a valid requirement for recoverying valuable corporate assets under any condition (failure/loss of token, person leaves the company, etc). In the person authentication case, the impersonation issue typically is viewed as outweighing the failure/loss of token issue. In the case of encryption of corporate assets, the failure/loss of the token issue would typically outweight any issues of guarenteeing absolutely that the key can only occur in a single place not knonw by anybody. The requirement for a private key only existing in a single place under control of a single person isn't an attribute of the public/private key technology .... it is an attribute of a specific business process and associated business requirements related to that business process. However, there are other business process applications for public/private key technology than human person authentication which can have somewhat different requirements. aads chip strawman .... public/private key hardware token w/o any certificates http://www.garlic.com/~lynn/index.html#aads random refs: http://www.garlic.com/~lynn/aepay3.htm#riskm The Thread Between Risk Management and Information Security http://www.garlic.com/~lynn/aadsm9.htm#pkcs12 A PKI Question: PKCS11-> PKCS12 http://www.garlic.com/~lynn/aadsm9.htm#pkcs12b A PKI Question: PKCS11-> PKCS12 http://www.garlic.com/~lynn/aadsm9.htm#pkcs12d A PKI Question: PKCS11-> PKCS12 http://www.garlic.com/~lynn/aadsm10.htm#diskcrypt Looking back ten years: Another Cypherpunks failure (fwd) http://www.garlic.com/~lynn/2000e.html#45 IBM's Workplace OS (Was: .. Pink) http://www.garlic.com/~lynn/2001j.html#16 OT - Internet Explorer V6.0 http://www.garlic.com/~lynn/2001n.html#54 The demise of compaq http://www.garlic.com/~lynn/2002.html#7 The demise of compaq [EMAIL PROTECTED] on 2/4/2002 9:13 am wrote: One other scheme I've seen, and which, while it doesn't give me warm fuzzies, seems reasonable, is to issue the the enduser a smartcard with a keypair on it. The SC generates the pair onboard, and exports only the public half. The private half never leaves the SC (there is no function on the card to export it). If you trust the above, then the only copy of the private key is on the SC, despite it having been generated without the end users participation. Peter --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
