Best practice for periodic key change?
Hauke Laging
mailinglisten at hauke-laging.de
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
happening.
> > 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.
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/653452fb/attachment.pgp>
More information about the Gnupg-users
mailing list