The whole issue of expiration in cryptographic systems is extremely fraught. My gut sense is that X.509 certificate expiry is the most common cause of mega-outages these days, where by "mega outage" I mean the sort of thing that takes down entire cellphone networks or major online services for hours at a time. In the past I've tried arguing against this practice of immediately cutting all communication because a deadline expired, but cryptography as a field is highly resistant to business requirements analysis of any kind. No CEO in their right mind would ever agree to having expiry in their infrastructure but the decisions are made by people far away, very deep down in organizational stacks, and it honestly doesn't occur to most business-side people that anyone could be crazy enough to litter miniature time bombs all throughout mission critical HA infrastructure anyway.

Part of the issue is misalignment of requirements. Keys don't actually expire, of course. In the old RSA days there was a notion of a sort of slow rusting as factoring attacks tended to get better over time, so every so often you'd want to bump the size of an RSA key to keep it secure. But that wasn't something that had to be done on a deadline. When elliptic curve cryptography went off-patent and started getting deployed it fixed that, and a secp256r1 key made today is as good as one made 15 years ago.

So what is the purpose of expiry, then, in today's world?

For DNSSEC, it seems to be a kind of encoding of an assumption that keys can leak without anyone being aware of it, whilst the holes being used to do so get sort of ambiently patched anyway again without anyone being aware that they've done so. If you assume a world where keys are constantly being stolen and abused, then regular rotation can help. However, that's not the real world! These keys are stored in HSMs. Has there ever been a leaked DNSSEC key spotted being abused in the wild? Certainly it's questionable whether the juice is worth the squeeze given the outages it causes, and the way these undermine the entire system.

For certificates there's that, but the original justification was actually about constraining the size of CRLs. If certificates don't expire then in theory any decommd cert has to be recorded and stuck on a revocation list forever, which would mean they can never shrink. How exactly to handle phaseout of old keys and certificate details has experienced a lot of churn over the years with CRLs, OCSP, OCSP Stapling and nowadays CRLsets all doing similar tasks.

Still, this is primarily a logistics and cost management issue rather than an actual security problem. The task could also be done with gradual phase out in which at first expired certs only trigger warnings to developers via the browser console, Google Search console etc. Then later it graduates to a warning in the URL bar. Then eventually TLS stacks start increasing the latency on connections, etc. Then once artificial latency passes a certain threshold that's basically equivalent to an outage anyway and you may as well just return an error immediately.

Lately there's another reason for expiry, with short expiry times being enforced by the CA/B Forum so they can change the rules for certificates quicker, not keys. It took a long time to phase out SHA1 and introduce CT, the people who set the certificate rules didn't like that as their job is security, so by making certs constantly expire they hope to push people into setting up automated renewal pipelines which in turn means they can then do things like mandate new algorithms, change the contents of certificates and so on. Constant expiry certainly helps them do their job, but it makes everyone else's job harder as automated renewal isn't always easy especially outside the context of simple web servers that use LetsEncrypt.

Summary: If tomorrow I was temporarily made King Of The Internet and told that my only mission in life was to increase availability, I'd start by altering X.509 libraries to implement gradual degradation instead of hard expiry, e.g. with a sleep(time_since_expiry) call somewhere in the stack. I'd also default to simply ignoring expiration outside of TLS context, because X.509 gets used in a lot of places that aren't TLS and they're often hard to reach and fix e.g. certs that are hard-coded into embedded devices. You do NOT want your electricity grid to have an outage caused by certificate expiry. In those contexts it hardly matters because the PKIs are often custom and not very large, so CRL sizes just don't matter. You can easily list every revoked certificate for the entire lifetime of the system, if you even need PKIX revocation support at all, and for those use cases expiry is probably a much bigger business risk than attacks using obsolete algorithms.

If a key is ever potentially compromised (say, a key employee quits), you should rotate the key. If this is too hard, people will just not do that, and we will have a world of hurt, with old keys being hard-coded all over the place. But you know what they say, “if something hurts, do it more often”. If key rotation is hard, automate it. Then, when a key really does need replacing, it’s easy. I prefer the pain of key rotation over the pain of all keys being hard-coded everywhere.

There are at least two possible fixes for that situation:

1. Use HSMs

2. Do constant key rotation

But (2) doesn't work for several reasons and (1) does, which is why in practice people use HSMs.

It doesn't work because:

1. There is always a period for which a key is live, and if rogue employee can simply copy a private key on a USB stick they will probably abuse it quite soon after doing so. You're encoding into the infrastructure (at massive cost) the assumption that for some reason the attacker will wait a long-ish period of time before using their access and rotation will thus defeat them, but there's no reason to assume that. So it can easily end up useless.

2. If your key handling is so weak that someone can just walk off with the private key then they can probably tamper with the key generation process too.

It's obviously great if you can make key rotation easy, but in the cases I've been involved with it was always hard. There's got to be a root of trust somewhere so often making key rotation easy and fast just means pushing the trust to a different key that can't be easily rotated (e.g. firmware key).

HSMs aren't perfect. They're just specialized computers at the end of the day. But given a choice between building a better HSM, or trying to solve very thorny distributed computing problems that at minimum assume things like a globally synchronized clock, the former seems easier, much more likely to actually work and much less likely to create unforced outages.

Remember that in my post I'm discussing not only the relatively easy case of well maintained always-online laptops and servers running software built by well funded tech firms and getting certificates from Google-subsidized free CAs. I'm also considering all the other uses of expiring keys/certs, like in private networks, credit card chip systems, industrial control, phone networks, internal cloud usages etc.

A (potential) key compromise can result from more things than an employee leaving. It can also be due to, say, an algorithm change. HSMs do not solve this (and in fact probably make it harder to change the encryption algorithm).

Why do HSMs make it harder? Algorithm changes are rare, and when they happen you'd need to upgrade all the clients that are working with the keys or certificates, so at that point it's a question of software rotation rather than key rotation. The HSM shouldn't be your biggest problem at that point.

There's some irony here: short expiry has some clear practical benefits for at least some of the goals of the WebPKI, and that works because the WebPKI has stakeholders that will push things like "if you issue one more SHA1 certificate we will distrust your CA". Certificate expiration failures are common, but not that common, because "needs a certificate" isn't the default for every host.

Key expiry is a much bigger problem for DNSSEC, since once you sign, every hostname in your whole zone depends on no RR in your DNS configuration expiring. But there are no stakeholders extracting any value from those expirations: nobody can say "if you sign one more record with RSA-1024 we will break your whole TLD".

Further, unlike with the WebPKI, where verification is conceptually offline --- you have a trust anchor and a signature chain and the verification is all done locally --- DNSSEC resolution is online: you have a TTL issue with revocation, but not a "this bogus signature will be valid for an entire year because there is no effective revocation system".

So, arguably, the RRSIG expiration field is another fundamental flaw with DNSSEC.

Yes. It seems there's some thinking around doing offline validation for DNSSEC as part of DANE, so you'd get the proofs you need from DNSSEC on the server side, then combine those with a certificate and send that to TLS clients. That seems reasonable.

There was an effort to staple DANE proofs to TLS handshakes, but it failed: if you could suborn a CA, you could control the TLS handshake enough to stripe the DANE proofs out, and the whole point of the DANE proofs was to avoid trusting CAs.

Catch 22. To know the server wants to exclusively use DANE you must learn that in a secure way, like via DNSSEC, but the point of DANE is to not do interactive DNSSEC queries.

I guess if you're publishing an intent to use DANE stapling exclusively via DNS, then you could have tools that crawl the CT logs looking for CA issuances for domains that claim they don't want them. Though maybe detecting an attack in that way isn't worth much.

There was talk of them proposing a pinning mechanism, but for understandable reasons the browser vendors were having none of it.