Revocation certificates [was: time delay unlock private key.]

[Leo Gaspard]

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