**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.

## Subkeys

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**](http://madduck.net/blog/2006.06.20:expiring-gpg/). 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.