Best practice for periodic key change?
mailinglisten at hauke-laging.de
Sun May 8 04:34:52 CEST 2011
Am Samstag, 7. Mai 2011, 21:43:38 schrieb MFPA:
> At what point does it become safe to assume that an individual with
> expiry dates on their subkeys keeps their master key securely offline?
There is probability but no safety in this assumption. But it this relevant?
How and whom is an expiration date supposed to protect? And what is the
The user of a non-expired public key does not have to cope with any
disadvantage by checking the expiration date. The alternative would be to
accept the key in any case. That would obviously not be a security advantage.
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
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. I theory. In practice the key owner does not know whether
his communication partners observe the expiration date. But he gives them the
chance to do so. The theoretical model is safe. Reality usually suffers from
worse security problems than that.
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
a) Write a key policy describing this, too. Make this document available
online and put its URL in all your certifications (including your selfsig) and
signatures (policy URL). Have everyone who certifies your key sign this
document (because this cannot beforged by someone who gets access to your
key). The problem: You have to read this document. GnuPG cannot do this for
b) Define some standard notations which give this information. From time to
time I give courses for OpenPGP beginners in an organization I am a member of.
We create two keys for them, one for playing around and lerning to use GnuPG
and a more secure one. When I certify these keys I add a notation
"offline at ourdomain=yes". So anyone using our certifications and understanding
both offline keys and notations (so probably noone) can know how these keys
are used – OK, nearly: How there were supposed to be used. There could be a
different term for keys which have been created elsewhere but are claimed to
be offline keys. "offline-claimed at ourdomain=yes" or something like that.
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."
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.
PGP: D44C 6A5B 71B0 427C CED3 025C BD7D 6D27 ECCB 5814
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 555 bytes
Desc: This is a digitally signed message part.
More information about the Gnupg-users