Best practice for periodic key change?

Hauke Laging mailinglisten at
Sat May 7 04:33:24 CEST 2011

Am Freitag, 6. Mai 2011, 22:37:12 schrieb Doug Barton:

> > That's not correct for subkeys and offline mainkeys as the good guys do
> > it.
> I don't understand this response. What I'm saying is that if the key is
> compromised, expiration dates become irrelevant. Perhaps you could
> expand your response a bit?

You have to tell apart two cases:

a) The mainkey is compromised.

b) The subkey is compromised.

If someone keeps his mainkey offline and well passphrase-protected then it is 
quite unlikely that the mainkey becomes compromised. If only the subkey gets 
compromised then it is not possible to change the subkey's expiration date. 
Thus your argument works for (a) only which can easily be prevented from 

> > I admit that a subkey expiration date does not make much sense for low
> > security mainkeys but it is quite useful for more secure environments.
> How so? I still haven't seen an explanation of what benefit the
> expiration date provides.

That is a last line of defense as it is quite hard to be sure to have the 
current version of a key under normal circumstances. And it works for people 
who are lazy with key refreshing.

Of course, you cannot be sure when a subkey will become compromised. Probably 
you won't even notice. But a short life time limits the danger resulting from 
a compromised key.

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/653452fb/attachment.pgp>

More information about the Gnupg-users mailing list