On Thu, Jan 23, 2014 at 09:59:30PM +0100, Pete Stephenson wrote: > [...] > > 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.
Well, why not give them a copy of the encrypted key? So long as your passphrase is strong enough (e.g. diceware for 128-bit passphrase), it should not require to have absolute trust in the backup holder. And if you want to account for risks of mental injury serious enough to make you forget your passphrase, well... our threat models are not the same: in mine, my key will expire soon enough in this case, and noone will ever be able to compromise my secret key as noone on earth remembers the cryptographically strong passphrase. > > 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. As you put it, this is essentially indistinguishable from a man-in-the-middle attack, so anyone who resend the encrypted message unencrypted is not respecting the protocol (or believe it is not important enough to be encrypted -- let's remember a lot of people just send christmas cards without envelopes). If anything important has to be transmitted (and the sender refuses to send it in cleartext), the sender will most likely send the message to someone else with physical contact with the recipient. One might argue this protocol is non-perfect, yet it is the best one the sender could achieve, revocation certificate or not. > 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. Indeed. Yet absence of answer should be clear enough to let the sender understand his message did not come to the recipient. Sure, a MitM could block the outgoing message, but anyway the sender has no better option than to find another way of sending his message: the recipient clearly does not receive the message. In case the fact of knowing a key has been revoked is critical in time, well... Knowledge of head traumas tend to expand quickly enough into the circles of acquaintances. (Sure, forgetfulness is a risk. Yet, forgetting a passphrase you type so often must be quite hard past the first few weeks.) And, what's more, such a time-critical scenarios happen only with special needs, which are AFAICT not usual. > 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. Well, you lose the dead-man-switch. BTW, once your key is revoked, will it some day be cleared out of the keyservers, or will it stay there forever? AFAIC guess, keys with an expiration date must be purged a little while after they expired, as there is no point in keeping them, while revoked keys must be kept, as anyone might need to update them to retrieve the revocation certificate. Of course, I'm only discussing the case of "normal people". There must be plenty of cases for which a revocation certificate is really useful, yet the number of tutorials in which I read "Store a backup of your private key and a revocation certificate" just looks like nonsense to me: if one stores both, it should at least be precised it should be in two different locations, as storing the two together is completely pointless, one being able to make the second. Of course, YMMV! Cheers! Leo _______________________________________________ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
