Best practice for periodic key change?

[Hauke Laging]

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 
alternative?

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 
signatures? ;-)


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

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 
you.

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.


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/20110508/3d5c724e/attachment-0001.pgp>