Michael, Michael Str�der wrote: > > Ben Bucksch wrote: > > Julien Pierre wrote: > > > >> the private key could have been sent to the CA if it required key > >> escrow during enrollment, > >> > > Eh, but the software (i.e. Mozilla) will clearly and obviously tell me > > about it in any and all cases, won't it? > > This would have been also my next question. CMP/CRMF is very > powerful and I wonder how client software will keep the user > informed what *really* happens...
I tested this once with Mozilla and an internal test CA setup for key escrow, and saw the dialog warning about the key escrow and prompting to proceed or not. Typically, if you have dual-key certs (separate signing and encrypting keys), only the encrypting private key will be backed up. It's never a big deal if you lose the signing key, since you will be able to generate a new signing keypair and cert. However, if you lose your private encrypting key, as the original poster did, you will also lose access to all the data you have encrypted with it, such as any S/MIME encrypted e-mails you saved locally. This is a moot point for the at poster who lost the entire profile anyway, but not necessarily for everybody, if only the key got lost, and not the rest. Note that I'm not necessarily advocating key escrow here - I think it somewhat defeats the purpose of encryption - I'm only advocating key backups. It can be a pain for individual users to backup their keys safely, but it is necessary. If smartcards are use, a backup of the keys is usually not possible however if the keys were generated within the smartcard. -- "Except for the lack of debugging and the ps thing, [Linux] kernel threads are generally fine right now. And if you're not too fussed about the more fiddly details of POSIX threads, and your application doesn't spend most of its time in thread creation, then LinuxThreads is great too." Linux-Kernel archive
