Exactly. Certificate expiration has never really been about security. It's purely for practicality, so that CRLs won't grow without bound.

This is especially true now that we have OCSP stapling. From a security perspective, a short-lived certificate is exactly equivalent to a long-lived certificate with mandatory OCSP stapling and a short-lived OCSP response, but the latter is much more complicated.

And in this case since it's a root, it goes even further than that. Root CA's can't be revoked anyway, so if they're compromised, a software update to distrust it is required. There's really not a good reason for them to expire at all.

It’s not true that expiration is not about security. Dan Geer’s talk in 1998, noted at https://cseweb.ucsd.edu/~goguen/courses/275f00/geer.html , is just as relevant today in the design of key management systems.

Expiration is not “just” about cryptographic risk either; there are plenty of operational risks. If you’re putting your server on the Internet, and exposing a service, you should be worried about key compromise, whether by hacker or by Heartbleed. Lifetimes are a way of expressing, and managing, that risk, especially in a world where revocation has a host of failure modes (operational, legal/political, interoperability) that may not be desirable.

As for Root expiration, it’s definitely more complicated than being black and white. It’s a question about whether software should fail-secure (fail-closed) or fail-insecure (fail-open). The decision to trust a CA, by a software vendor, is in theory backed by a variety of evidence, such as the CA’s policies and practices, as well as additional evidence such as audits. On expiration, under today’s model, all of those requirements largely disappear; the CA is free to do whatever they want with the key. Rejecting expired roots is, in part, a statement that what is secure now can’t be guaranteed as secure in 5 years, or 10 years, or 6 months, whatever the vendor decides. They can choose to let legacy software continue to work, but insecurely, potentially laying the accidental groundwork for the botnets of tomorrow, or they can choose to have legacy software stop working then, on the assumption that if they were receiving software updates, they would have received an update to keep things working / extend the timer.

Ultimately, this is what software engineering is: balancing these tradeoffs, both locally and in the broader ecosystem, to try and find the right balance.

I don't see anything about expiration in that talk.

If you don't have a strong revocation system, then your host is vulnerable whether or not you have expiration, since attackers aren't going to wait until the day before your key expires to try to steal it.

In general, when a CA's root certificate expires, it creates a new one and gives it to browser and OS vendors. What's the difference between the CA continuing to guard their old private key, and starting to guard the new private key?

> If you don't have a strong revocation system, then your host is vulnerable whether or not you have expiration, since attackers aren't going to wait until the day before your key expires to try to steal it.

We don't have a strong revocation system. Maybe one day OSCP stapling will be mandatory, although OSCP signatures are reusable within an expiration window, so we still have the question of expiration.

> In general, when a CA's root certificate expires, it creates a new one and gives it to browser and OS vendors. What's the difference between the CA continuing to guard their old private key, and starting to guard the new private key?

Their new key is fresh --- the public key hasn't been floating around being factored for the last 20 years. Maybe it's longer too. It certainly wouldn't be on disk of hardware they discarded before the new key was generated. Of course, they should have taken proper precautions with their discarded hardware, but maybe someone slipped up.

Frequent expiration is a way of limiting the damage of key theft, not a way to prevent it. In some (many?) cases, key theft is not detected, so limiting the amount of time it could be used is helpful.

OTOH, what do you do for devices which are shipped with a CA bundle, and never updated. They may be a problem for other reasons, but at some point, they don't have any valid roots and they turn into a pumpkin. (Fun times if the manufacturer realizes and tries to update, but doesn't get the update distributed before the certs expire; there was an Amazon Kindle update like that once).

When I search for that, all of my hits are about a key-transport protocol that doesn't seem related to certificates at all.

Expiration and revocation are far from the same thing. If my site's private key gets stolen, I want clients to stop trusting it today, not next year.

Expiring roots means that if a device stops getting updates from its vendor, it will gradually become a brick even if no CAs do anything wrong.

Expiration may be useful but how is expiration in 2038 useful?

It isn’t, but then again, in 1995 we might have said the same for expirations in 2015, and yet so, so many poorly managed CAs were expunged in the past 5 years.

A healthy root store would set revocation at a much more aggressive period; say, every five years. Every three years, the CA applies to have their new root trusted, which gives two years to distribute that root to clients that need it, while having the old root sign the new root, to support an immediate transition to the new root. Among other things, this encourages a more robust and healthy CA ecosystem, because you don’t end up with lopsided balances based on “who has the oldest root.” That imbalance encouraged poor behavior which got CAs distrusted, in the past, because they behaved in a manner that assumed they were too big, by virtue of being too ubiquitous, to fail.

Someone on Twitter (forgot whom, maybe swiftonsecurity?) suggested lately in a tongue-in-cheek way that the certs should not hard-expire, but instead add an exponentially-increasing slowdown at TLS handshake.

Once the slowdown is too big, someone will notice and have a look.

Unfortunately, given crypto algo evolution and Moore's Law, the reverse is more likely true. Though that would be a neat hack.

I don't understand how this is relevant. We're talking about a deterministic timeout, based on the diff between cert exp date and current date.

If Chrome added e.g. a 20 second slowdown to connect to the page for every user in the world one day after the cert expired, surely there would be some users who would ping the company that the site is unbearably slow (on social media, by email, whatever). Or someone in the company would notice. Or analytics would drop like hell.

Myriads of ways how a non-abandoned website would learn about it directly or indirectly.

Of course that seems like a giant hack, but a grace period of 1-7 days with browsers doing something less scary than a giant error screen would be more than welcome.

My point, such as it was, is that at present the workfactor penalty favours less-effective crypto, the opposite of the suggestion.

Of course a specifically-implemented timeout might be incorporated. That faces the challenge of bad actors (or incompetent / unaware ones) bypassing such a mechanism.

Incorporating the cost into the algorithm itself (say; requiring, more rounds based on time since first release, according to a mandatory and well-estabished protocol, just off the top of my head, with both client and server agreeing on minimum required rounds) might work.

To revoke a certificate you must keep a list of revoked certificates. Without expiration date that list would grow infinitely. And that list should be downloaded periodically by every entity which wants to verify certificate.

They said "certificates should never expire or should expire daily". Roots already can't be revoked, so they should never expire. Intermediates and leaves should expire daily. Since currently, OCSP responses are often valid for that long, there'd be no need for revocation anymore then.

What if your CA is down for a day? Imagine let's encrypt being down for 24 hours and all if it's certificates going invalid. That would be millions of websites unavailable..

This is no different than an OCSP server going down for a day. Either the site becomes unreachable, or clients take a risk by accepting a certificate that might be revoked.

When OCSP is down nothing happens with most browsers. Except-Staple might worsen it a bit, but how many use that?

My point is that connecting with OCSP down carries the exact same risk that accepting an expired certificate does. In both cases, the risk is that the certificate might have been revoked without you knowing it.

If I operate a website, I might have some confidence that my key hasn't been stolen in the last year. But I might have much less confidence that my key hasn't been stolen in the last 20 years.

Certificate expiration means I don't need to worry about that second case.

That’s only true if your key is regenerated each time you request an updated certificate. This is not mandatory, and there are lots of guides on the internet for generating a csr from an existing key.

Sure but I don't think that's generally done or recommended. I think people only do that if they have certificate pinning, which on the web is pretty rare and getting rarer as browsers drop support for HPKP.

I tend to agree. Seems dealing with expiration dates is just another burden without real security. If something goes wrong you have to revoke now and not wait for another year until the cert expires.