PGP expired encryption subkey : renew or replace?

Question

I am in the process of learning PGP (GnuPG more precisely).

I am trying to figure out which is the best strategy for my encryption ([E]) subkey in terms of expiration/revocation/renewal. Could you please tell me if the following affirmations are correct ? Because I am not sure I understand everything correctly :

• Strategy 1 (by default with GnuPG) : an [E] subkey without expiration date.
  • Advantage : the most easy setup to administrate, nothing to do
  • If the private [E] subkey is compromised (but not the master key), I can always revoke that subkey.
  • Caveats : I have no influence on how often other users update my public key. If some users don't update it for a long time, they won't know it has been revoked, and thus they may still use it to encrypt messages, although it has been compromised
• Strategy 2 : set an expiration date on the [E] subkey. In that case, what should I do when the subkey expires ? I have the choice between extending the expiration date of the existing subkey, or issue a brand new [E] subkey :
  • Extending the existing subkey's expiration date can present some risk, in case that subkey has been compromised without my knowledge. An attacker could keep using it to decrypt new messages, without my or my correspondents knowledge
  • Issuing a new subkey cancels that risk (the attacker would have to gain access to the new subkey to decrypt future messages)
  • From the other users point of view, there's no difference between the 2 options (extending the expiration date or issuing a new key), because in each case they will have to update my public key because of expiration.

So, in conclusion :

• Easiest thing to do is to issue an [E] subkey without expiration date, but it's the less secure strategy
• A more secure strategy would be to periodically issue a new [E] subkey every n years
• Extending an existing [E] subkey's expiration date doesn't really make any sense : it's less secure than issuing a new subkey, and requires the same work from the part of my correspondents (in both case they have to update my public key)

What do you think ? I am not the only one asking that question, but I couldn't find a thorough answer (see Generate and add new encryption subkey? or https://www.reddit.com/r/GnuPG/comments/dma9hp/expired_encryption_subkey_renew_or_replace/)

Answer 1

In order of preference, I would suggest

1. Prefer to bump the expiration of an existing subkey
2. Rotate to a new subkey and revoke the existing subkey, flagging it as superseded
3. Use an encryption key without an expiration.

Keys without expiration will exist on keyservers effectively forever. Speaking from experience, I forgot the passphrase for some keys I made 25 years ago, and now those will exist in the wild forever because I can't revoke them.

When you expire a subkey, you're not necessarily indicating that it has been compromised, however sometimes clients will ignore this flag and present a fairly alarming error. Personally, I think "expired" is a little more intuitive to indicate something needs an update, while "revoked" sounds like you need to talk to someone's manager.

gpg> revkey
Do you really want to revoke this subkey? (y/N) y
Please select the reason for the revocation:
  0 = No reason specified
  1 = Key has been compromised
  2 = Key is superseded
  3 = Key is no longer used
  Q = Cancel
Your decision?

Things move really slowly in the PGP world (for good reasons). With good security practices, you might find yourself using the same key decades from now, but having a lot of expired keys is probably just going to annoy one you. Other people can delete old encryption keys, but you will need to keep them for as long as you want to be able to decrypt things that were encrypted with them.

Since we live in a world where hardware tokens are easy to find and cheap, I think a good compromise is to bump the expiration of your subkeys every year, and rotate to a new one when you want to change the encryption algorithm, which happens every couple decades. We used to recommend RSA-1024, but as computers got faster we started to recommend bigger RSA-2048 and RSA-4096 keys. I've been considering switching to an ECC 25519 key because aesthetically the signatures are shorter.