Revocation certificate creation (was: options files)

Werner Koch wk at
Tue Feb 26 09:52:05 CET 2013

On Tue, 26 Feb 2013 01:25, craig at said:

> I really wish a 1y or 2y expiry was the default and that gpg prompted
> you to generate a revcert as part of key generation. I spend a lot of

I wish I had done that right from the beginning.  The reason why I did
not was the fear that then the revocation certificate would be readily
available on the disk and 3 things may happen:

- The user accidentally imports that certificate and it would
  eventually end up on the keyservers.

- Someone else gets access to the revocation certificate and sends it to
  the keyserver.

- The disk crashed and the user has no backup.

Reviewing this today I may say that the first could be mitigated by
indenting the lines of the revocation certificate so that GPG would no
be able to import it directly.  The second is not a real issue.  The
third is probably the most likely threat; however, it would not be worse
than not having a revocation certificate at all.

Given that the default for smartcards is to store the backup on disk and
ask the user to move it to a safer place, we might as well do something
similar for revocation certificates.  Comments?

Regarding a default expiration date: It may be useful if GUIs would do
this (as long as they also offer an option to prolong the expiration).



Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.

More information about the Gnupg-users mailing list