Best practice for periodic key change?

MFPA expires2011 at
Sun May 8 14:50:36 CEST 2011

Hash: SHA512


On Sunday 8 May 2011 at 3:34:52 AM, in
<mid:201105080434.57614.mailinglisten at>, Hauke Laging

> There is probability but no safety in this assumption.

I have no idea what is the probability. I have seen no figures
relating to what fraction of people using subkeys with expiry dates
claim to keep their master keys offline.

> But it this relevant?

This depends on whether/how the validity of the assumption affects
your threat model.

> How and whom is an expiration date supposed to protect?

Mainly the key's owner, but could also protect others from relying on
signatures from a compromised key for which they have not received a
revocation certificate.

> And what is the alternative?.

I don't know. Expiry dates serve a purpose but cannot be relied upon,
because system clock times/dates cannot be relied upon and a signature
with a timestamp during the key's validity period is a valid openPGP
signature. This may be addressed by using a trusted timestamp service.

> One might ask: Do users who observe expiration dates
> refresh their keyrings less often on average (due to
> false trust in the expiration feature)? Does it make
> sense for an attacker to replace non-expiring subkeys
> with expiring ones in order to reduce the refresh
> frequency of the ones being attacked by forged
> signatures? ;-)

That's an interesting thought experiment.

> But there is security for the owner of the key. He
> knows that his mainkey is stored safely offline so that
> nobody will ever meet forged subkeys of this key. Thus
> he safely protects himself and his communication
> partners from the use of expired keys.

Could a modified version of "HOW TO MIGRATE A (SUB)KEY INTO A NEW KEY" be used to substitute one
of your subkeys with another of the same type and size? Or what would
be the implications of an attacker migrating your subkeys to another
master key?

> As you may remember I promote both an implicit and an
> explicit solution of this problem (not knowing enough
> about others' key handling) here from time to time:


That is very thorough.

> If there was a standard for this GnuPG could be
> extended to allow for a configuration  taking this into
> account. The extreme version: "Trust  certifications of
> others only if they are offline keys."

That does seem extreme but it depends on the threat model.

> And as I am dreaming: With a notation for identifying
> all subkeys (thus extending a certification from UIDs
> to subkeys) the first hurdle for getting GnuPG /
> OpenPGP compliant with German signature law (at least
> on the  theoretical level) would be taken.

Would that mean a certification of a particular UID on a key was not
valid in conjunction with subkeys that were not present on the copy of
the key you signed? If so, wouldn't that discourage people from using
short-life subkeys because they would need to obtain signatures on new
ones? Or have I misunderstood?

- --
Best regards

MFPA                    mailto:expires2011 at

Humility is no substitute for a good personality.


More information about the Gnupg-users mailing list