Best practice for periodic key change?
expires2011 at ymail.com
Sun May 8 14:50:36 CEST 2011
-----BEGIN PGP SIGNED MESSAGE-----
On Sunday 8 May 2011 at 3:34:52 AM, in
<mid:201105080434.57614.mailinglisten at hauke-laging.de>, 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
> 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"
http://atom.smasher.org/gpg/gpg-migrate.txt 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
> 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?
MFPA mailto:expires2011 at ymail.com
Humility is no substitute for a good personality.
-----BEGIN PGP SIGNATURE-----
-----END PGP SIGNATURE-----
More information about the Gnupg-users