Best practice for periodic key change?
mailinglisten at hauke-laging.de
Sat May 7 04:05:18 CEST 2011
Am Freitag, 6. Mai 2011, 21:48:03 schrieb Ingo Klöcker:
> > What is the difference between these two options with respect to the
> > point of confusion?
> Unless I'm missing something the difference is as follows:
> - With prolongation of the expiration time releases signed before the
> prolongation will keep having a valid signature.
I am a bit disappointed that it seems not to be possible to change this by an
option. It seems to me that you have to parse text output which is not
intended for parsing. There is no --with-colons for --verify, or do I just not
notice such a feature?
Several people have mentioned that a signature does not become invalid by
expiration of the key. That is formally correct an describes the GnuPG
behaviour. But with regard to content in such a case there has to be an
additional proof that the signature has been made before the key expired. This
is a formal rule in e.g. the German signature law. If you want to use legally
accepted signatures for proving documents then you have to sign both the
document and the old signature by a new key (i.e. one with a later expiration
date) before the old key expires.
I would prefer GnuPG to work this way: Make a signature by an expired key fail
by (configured) default and add an option like --ignore-key-expiration which
can be used for a second gpg call (after an external verification that the
signature has been made in time).
And I would like to have a verification option for output intended for
We can have a long discussion about the interpretation of signatures by
expired keys (apparently made before the expiration). But as there is IMHO no
way to really make sure that you have the current version of a key (and thus
all revocations) I regard an expiration date as a last line of defense. Thus I
think that it does not make sense to (effectively) ignore such an expiration
by default. Nobody is forced to set expiration dates. Newer subkeys are used
automatically without the old ones being revoked or expired.
> - If one creates a new subkey then releases signed with the old expired
> subkey(s) will have an invalid signature.
That didn't make any sense to me so I checked that. This seems to be wrong. I
have not noticed any change in the verification output (or exit code) between
a valid subkey existing beside the expired one or not.
PGP: D44C 6A5B 71B0 427C CED3 025C BD7D 6D27 ECCB 5814
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 555 bytes
Desc: This is a digitally signed message part.
More information about the Gnupg-users