Best practice for periodic key change?

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


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

Hi


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


> 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"
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
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:

[snipped]

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 ymail.com

Humility is no substitute for a good personality.
-----BEGIN PGP SIGNATURE-----

iQE7BAEBCgClBQJNxpG8nhSAAAAAAEAAVXNpZ25pbmdfa2V5X0lEIHNpZ25pbmdf
a2V5X0ZpbmdlcnByaW50IEAgIE1hc3Rlcl9rZXlfRmluZ2VycHJpbnQgQThBOTBC
OEVBRDBDNkU2OSBCQTIzOUI0NjgxRjFFRjk1MThFNkJENDY0NDdFQ0EwMyBAIEJB
MjM5QjQ2ODFGMUVGOTUxOEU2QkQ0NjQ0N0VDQTAzAAoJEKipC46tDG5pT7sEALNB
lErOSpojvDTD7ngm22Q3IC5UvUmQy1cRnpJh6coShgROBNrCW6dDgOv39yi6/VH2
sNKM9LyqWt1XU+fhmVX/uS2nlFgh0VysYfyYjNs81bLSHmkYc771tZLl4jhK9zUf
+GWXxe0AQ7hVukQcRbtT/tj23ThWdQNfSwroZO2O
=Tuwx
-----END PGP SIGNATURE-----




More information about the Gnupg-users mailing list