Key expiration

OpenPGP keys may include an expiration date. This date is included when a certificate of this key is generated. The expiration date within a certificate gives the software processing the cert a hint on how to handle it. Email clients, for instance, might refuse to use an expired certificate to encrypt a message. Signature-verifying software might display a warning, but continue to function.

The expiration date is optional. It's possible to create (or update) keys that never expire. The expiration date does not imply that the certificate becomes "insecure" after that date. It's just a method to enforce an update.

There are different reasons for, and effects of, setting an expiration date for certificates. Whether setting an expiry date represents a security improvement depends on the threat models concerned. If a certificate has an expiry date, you can always extend its validity so long as you have access to the key.

If you lose your key without there being an attack and still have your revocation file stored somewhere safe, you can revoke the key and certificate without having to wait for it to expire. If you don't have a revocation file, you can at least let it expire by itself.

If someone steals your key, they would be able to use it. Only a revocation file would help to avert the damage here as the attacker could also manipulate the expiration date on certificates that they issue.

It can make sense to set different expiration dates for subkeys with different purposes. If only a specific subkey is lost or stolen, it can be revoked independently of the primary key, which will remain valid.

Another reason to set an expiration dates which is often mentioned is that it forces people to refresh their certificate stores or pubrings regularly. In summary, one can say that storing the revocation file somewhere safe that's separate from the key is more important than setting an expiration date. Nevertheless, setting an expiration date could limit possible damage.