RFC on issue 2701, default expiration time for new keys

[Ximin Luo]

Peter Lebbing:
> On 09/12/16 15:29, Ximin Luo wrote:
>> No, some people like to split their secret master keys and subkeys.
> 
> I'm pretty sure expirations and revocations are signed by the primary
> key, also expirations and revocations of subkeys.
> 
> So if you happen to lose access to the private key material of a subkey,
> you can revoke or expire it on the spot, with the primary key.
> 
> If you say "we should have expiries to cope with the fact that you can't
> revoke anymore once you lose access to the private key", I think that is
> purely related to losing access to the primary key. I don't see the
> purpose of putting an expiry on a subkey in this use case. Obviously
> there can be other reasons to put expiries on subkeys, but are they
> within scope of this discussion?
> 

You are correct in all of the above regarding the power of the private master key.

However, expiry dates are more of a policy statement by the controller of the private master key. When you set an expiry date you're saying to the world "I consider this [sub]key no longer valid after this date", you're making a public committment. This enables your recipient to ensure fresheness of that subkey - if it's expired then "something is wrong", either you should have renewed the expiry date or added a new subkey.

Now it's reasonable that someone might want to set different policy "validation periods" for different subkeys. For example, I like to set the encryption subkey to have a relatively short expiry, to try to provide some approximation to forward secrecy. But I don't see an equal need for signing subkeys to have short expiries, probably longer expiries are more convenient. Or maybe someone else could disagree, then they could set it to have the same expiry as their encryption subkey[s].

X

-- 
GPG: ed25519/56034877E1F87C35
GPG: rsa4096/1318EFAC5FBBDBCE
https://github.com/infinity0/pubkeys.git