RFC on issue 2701, default expiration time for new keys

Ximin Luo infinity0 at pwned.gg
Fri Dec 9 15:33:00 CET 2016

Ximin Luo:
> Peter Lebbing:
>> On 09/12/16 14:55, Justus Winter wrote:
>>> [...] 5) adds subkeys to an
>>> existing key.  Both allow one to specify an expiration time (optional,
>>> or '-' to explicitly select the default, or the key words 'never' and
>>> 'none').  By default the keys generated using this way do not expire.
>>> I'd like to change that as well.
>> What's the purpose of putting an expiry date on the subkeys? I thought
>> this was mainly to deal with losing access to the private key material.
>> Isn't that only relevant for the primary key?
> No, some people like to split their secret master keys and subkeys. You can do --export-secret-subkeys then selectively import the subkeys.

For example, what I do here is set 15 months expiry date for the Certify/Sign/Authenticate keys and 9 months for Encrypt.


The numbers are meant to be round numbers (1 year, 1/2 year) plus 3 months to give a suitable overlap time for other people to update your key.

If you set your expiry dates to 3 years, you then have to update things every 2 3/4 years or something like that. It's easier to plan around, if you just do it every December. :)


GPG: ed25519/56034877E1F87C35
GPG: rsa4096/1318EFAC5FBBDBCE

More information about the Gnupg-devel mailing list