At 5:12 PM +0100 2/8/02, Jaap-Henk Hoepman wrote: >I think there _are_ good business reasons for them not wanting the users to >generate the keys all by themselves. Weak keys, and subsequent >compromises, may >give the CA really bad press and resulting loss of reputation (and this >business is built on reputation anyway).
If the CA has nothing to do with key generation in the first place, I'm not sure how weak keys would affect the CA's reputation. "We had nothing to do with making that key, we just signed it" is a concept even the general public can understand. And the risk of weak keys seems small compared to the myriad ways a user's private key can be compromised. If the CA has any access to private keys, any compromise can be blamed on the CA and diminish their reputation. >So: there are good reasons not to >let the CA generate the private key, but also good reasons to not let the user >generate the keys all by himself. > >So the question is: are there key generation protocols for mutually >distrustful >parties, that would give the CA the assurance that the key is generated using >some good randomness (coming from the CA) and would give the user >the guarantee >that his private key is truly private. Also, the CA should be able to verify >later that the random data he supplied was actually used, but this should not >give him (too much) advantage to find the private key. It's hard to see how to establish a secure protocol between the user's machine and the CA without a good source of randomness on the user's machine in the first place. You can't presume there's a shared secret. Simply providing an applet or plug-in to generate keys would seem sufficient. The CA could maintain a list of approved smart cards based on inspecting their source code. They might even let approved smart card vendors embed a signing key in the smart card to let the CA know that the user key had been generated by an approved device. Such a system could be defeated but it's not clear why anyone would have the motivation to do so. If someone wants to create a compromised key incident, they merely have to leak a key. Arnold Reinhold --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]