Information Security Stack Exchange is a question and answer site for information security professionals. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I've created a new OpenPGP key to sign a software package in a source repository with an expiration date three years from now. It seemed like a good security measure, because if the key is compromised or stolen the damage will be limited.

But then I thought about the day when I will need to sign my new key. Signing the new key with the old key seems equivalent to keeping the old key, and thus adds nothing to security.

Does setting an expiration date improve key security? If so, what's the best expiration/key replacement policy?

share|improve this question

tl;dr: the expiry date is no reasonable mechanism to protect the primary key, and you should have a revocation certificate at hand.

The slightly longer version is, that the effect of the expiration date differs between primary and subkeys, and also what you aim to prevent.


For subkeys, the effect is rather simple: after a given time frame, the subkey will expire. This expiry date can only be changed using the primary key. If an attacker gets hold of your subkey (and only this), it will automatically be inactivated after the expiry date.

The expiry date of a subkey is a great tool to announce you switch your subkeys on a regular base, and that it's time for others to update your key after a given time.

Primary Keys

For primary keys, the situation is different. If you have access to the private key, you can change the expiry date as you wish. This means, if an attacker gets access to your private key, he can extend the validity period arbitrarily. Worst case you lose access to the key at the same time, then you cannot even revoke it any more (you do have a printed or otherwise offline and safely stored revocation certificate, do you?). An expiry date might help in the case that you lost control over the key, but no attacker has either. It will automatically expire after a given time, so there is no valid key with your name you cannot use on the key servers forever.

Recovering Weak Unrevoked Keys

Even worse, expiry dates might provide a false sense of security. The key on the key servers expired, so why bother to revoke it? There is a large number of well-connected RSA 512 bit keys on the key server network, and probably a comparabily large number of weak DSA keys (because of the Debian RNG problems). With faster processors and possibly new knowledge on algorithm weaknesses, an attacker might in future be able to crack the expired, but non-revoked key and use it!

Keeping a Revocation Certificate Safe Instead

If you've got a revocation certificate and are sure you never might lose access to both your private key and revocation certificate at the same time (consider fire, (physical) theft, official institutions searching your house), there is absolutely no use in setting an expiry date apart from possible confusion and more work extending it.

share|improve this answer
Makes sense. This should be the selected answer. – Kshitiz Sharma Feb 18 '15 at 5:32

Does setting an expiration date improves key security?

Yes. You've already said why, too:

It seemed like a good security measure, because if the key is compromised or stolen - the damage will be limited.

Assuming you are compromised and the key is stolen, clearly, your first action would be to revoke the key and issue a new one. However, not everyone will check for revoked keys; they'll continue blindly using it until it becomes invalid.

Likewise, if you're compromised, somebody can only pretend to be you for a fixed window.

If so, what's the best expiration\key replacement policy?

There really isn't one - the question is more "what is the best I can do given constraints X Y Z". For example, if you set the Window too small, you inconvenience users; however, too high and you open up the risk if compromised. It really comes down to a judgement call - how sensitive exactly is what you're protecting and how often/inconvenient is it to replace keys frequently?

share|improve this answer
By "policy" I actually meant the procedure to undertake when a key is naturally expired. – Adam Matan May 8 '12 at 12:39
This is plain wrong, if your key is stolen, the thief can pretend to be you forever, as he can prevent it from expiring. – remram Feb 27 '14 at 17:01

Note that an expiration date on the master key doesn't really do anything for security, as anyone who compromised that could always just extend it anyway. See

(Expiring subkeys, on the other hand, can be useful, and the option at key creation sets the date on all of the keys.)

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.