Best practice for periodic key change?

[Hauke Laging]

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 
parsing.

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.


Hauke
-- 
PGP: D44C 6A5B 71B0 427C CED3 025C BD7D 6D27 ECCB 5814
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 555 bytes
Desc: This is a digitally signed message part.
URL: </pipermail/attachments/20110507/550c7eaa/attachment.pgp>