On Thu, Jan 23, 2014 at 9:25 PM, Leo Gaspard <[email protected]> wrote: > On Thu, Jan 23, 2014 at 05:53:57PM +0000, nb.linux wrote: >> And, you can be prepared for such an event (i.e. having created the >> revocation certificates in advance, stored them in a save but accessible >> place, printed out on paper,...). > > Actually, this is something I never understood. Why should people create a > revocation certificate and store it in a safe place, instead of backing up the > main key?
It's a sensible thing to do both, of course. > So long as the primary key is encrypted and the passphrase is strong, this > should not lead to any security danger. (Anyway, it's stored in a "safe" > place. > And a revocation certificate misused is dangerous too, as it ruins a web of > trust.) > > And the advantages of doing so are that in case or accidental erasing of the > private key (who never accidentally deleted an important file?), it also > allows > the main key to be retrieved. > > The primary key allows one to create a revocation certificate, not the other > way > around. So, why store a safe revocation certificate? The most damage that a misused revocation certificate can do is revoking one's certificate. This is a bit of a pain, in that one would need to create a new keypair, get it signed, etc., but it wouldn't result in the compromise of sensitive information, messages, etc. Misuse of a revocation certificate is a minor denial-of-service, but not a complete break of security. For example, one could easily give a trusted friend or family member a copy of a revocation certificate (perhaps printed on paper) to keep in a physically distant location. They would need to be trustworthy enough to not abuse the revocation certificate by revoking your certificate, but otherwise would not need to be given absolute trust that comes with having a copy of the private key. Same thing with keeping revocation certificates in a bank safe deposit box or some other location protected by a third-party -- if the box were compromised (say by the authorities with a court order), your private key would not be compromised. > Leo > > PS: Please, do not tell me one might have forgotten his passphrase. In this > case > there is no harm in shredding the secret key and waiting for the expiration > date, answering persons emailing you encrypted files that you lost your > passphrase. Anyway, in this case, you're screwed, and a revocation certificate > would be no better -- unless it was stored unencrypted, at the risk of having > it > used when you do not want it to be. Actually, that's a fairly reasonable scenario. Someone may have forgotten their passphrase for whatever reason (ranging from forgetfulness to head trauma) and would like to inform others that their key is no longer usable. Replying to people saying that their key is lost is essentially indistinguishable from a man-in-the-middle attack -- some people might simply resend the encrypted message in plaintext, defeating the purpose of encryption in the first place. A revocation certificate allows one to revoke the certificate even without access to the private key, so one could reply with their now-revoked public key (or direct someone to the revoked key on the keyserver) and say "Sorry, I lost the private key and had to revoke it." -- while this doesn't resolve the issue of people resending things in plaintext, it does permit someone to actually show that their key is, in fact, revoked. Also, not all keys have expiration dates. I, for one, tend not to set expiration dates on my primary keys, but instead rotate encryption and signing subkeys (which do have expiration dates) for day-to-day use. While I could put an expiration date on the primary and extend the date as needed, it's easier for me to just make revocation certificates and keep them stored off-site. Your mileage may vary, of course. Cheers! -Pete -- Pete Stephenson _______________________________________________ Gnupg-users mailing list [email protected] http://lists.gnupg.org/mailman/listinfo/gnupg-users
