When I first started using GnuPG, one of the most confusing parts was deciding on an expiration date for the keys, and the advice online seems to be contradictory. Note, however, that it is possible to update the expiry date for any key at any time, even after the keys have expired, so this is always something that you can change later.
The user manual itself writes that “[f]or most users a key that does not expire is adequate”, although it later states that “if you lose control of the key and do not have a revocation certificate with which to revoke the key, having an expiration date on the certification key ensures that the key will eventually fall into disuse”. Despite this, as of version 2.4.3, GnuPG generates keys with an expiry date set three years from the time of creation by default. The rationale given for enforcing key expiration is that there would otherwise be no way to remove stale keys from keyservers should the user lose access to both the keys and the revocation certificate. Indeed, there are some GnuPG users who even suggest setting keys to expire after only 100 days to encourage correspondents to notice revocations and other changes to the key as soon as possible.
Other OpenPGP software, however, default to no expiry for new keys. For instance, the developers of the Android OpenPGP client OpenKeychain posit that key expiration does not meaningfully solve keyserver clutter or the problem of unauthorized keys being uploaded, because anyone can already upload keys with arbitrary user ID fields, and so only serves to add unnecessarily complexity. It has been said that key expiry shifts onto unsuspecting correspondents the cognitive burden of knowing how to refresh the expired keys when communications suddenly no longer work.
One important point to note is that key expiration generally has no significant bearing on the security of the keys. This is because the certification key can be used to extend the expiration date of itself and any subkeys bounded to it. The only case I can imagine that expiry might help is if the subkeys but not the certification key were compromised, since this would limit the period that the subkeys could be misused. This could be could be a consideration, though, for those who keep the certification key offline.
Of the two positions, I find the case for key expiration more compelling. At some point, you will probably be in the situation where you either need to make some changes to your keys and redistribute it or revoke the keys and publish the revocation certificate. Your correspondents will not become aware of the changes or revocation until they refresh their keys. However, GnuPG is not yet able to automatically refresh keys from key servers unless the user sets this up themselves. Even if this changes in the future, there is no guarantee other OpenPGP software will do this. Without key expiration, this means that your correspondent may never refresh your key for a long time, incorrectly believing your key to be still valid. At least with an expiry, the period that this can happen is limited.
One could argue that this is not a serious problem because when the receiver of an encrypted message cannot decrypt the message, the recipient will naturally reach out to the sender and the two can resolve the issue together. In some cases where the relationship between the two parties is interactive and symmetric, this might be a reasonable expectation. However, now it is up to the recipient to notice and diagnose the failure and this assumes that the parties have a working out-of-band channel to initiate repair. The question is, who should carry the burden of repair – the sender or the recipient?
Regardless of one’s stance, there are still many situations in which keys need to be refreshed for reasons other than revocation, such as the addition of new user IDs or changes to trust signatures. In these cases there is no obvious failure mode that could prompt the recipient to initiate contact. It also has to be considered that there are a few situations where it is not possible to revoke the key even if it is no longer usable. As an example, should you so happen meet an untimely demise, then the expiry will act like a dead man’s switch.
Therefore, in the general case, I would say that an expiration date is useful to signal that the owner intends to keep the keys periodically updated and to encourage those who import the keys to regularly refresh them. There are still a few unanswered questions, though. One of these is how far in the future to set the expiration date to. As discussed above, the benefit of keeping this short is that others will be likely to notice changes to your keys more quickly, but this should be weighed against the potential inconvenience for yourself, since you will need to then reset the expiration date more often, and others, who might have to manually refresh your keys. Personally, I think that one to three years is a reasonable middle ground.
The next issue is whether to add an expiration to the certification
key, the subkeys or both. Currently, GnuPG adds the same expiration
date to both the certification key and the subkeys when using the
gen-key interface, but only adds an expiration date to the
certification key when using quick-gen-key. I am in favour of
setting a single expiration date for the certification key. The
validity of the subkeys is bound to the certification key, such that
the subkeys automatically become invalid when it expires. Moreover,
when using the edit-key interface to reset the expiration date, as
far as I can tell, it is not possible to simultaneously set the
expiration date for the certification key and the subkeys at the same
time (although it is possible to set the expiration date for multiple
subkeys at once). Technically, this should be doable using
quick-set-expire, but this creates unnecessary hassle.
So, there you go! If you are not sure what to set the expiration date to, just leave the expiration date of the certification key to three years from the creation date, do not worry about expiration dates for the subkeys. Do not forget to reset the expiration date shortly before the key expires.