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

[Pete Stephenson]

On Thu, Jan 23, 2014 at 9:25 PM, Leo Gaspard <ekleog at gmail.com> 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