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).
It’s not either/or expiration vs revocation; they are the same thing. Expiration is natural revocation and a ceiling function to the overall cost.
The statement “when a CA’s root certificate expires, it creates a new one” is not a general statement. That’s the exception, rather than the rule, as evidenced by just watching the changes to root stores over the past 30 years. More CAs have left the CA business / folded / been acquired than have carried on. A classic example of this is the AOL root, for which the long-standing scuttlebutt is that no one knows what happened to the key after AOL exited the CA business. The reason it’s scuttlebutt, as opposed to being a Sky is falling DigiNotar, is that the certificate expired. Or, for that matter, look at how many CAs have been distrusted. Expiration fits as a natural bound for legacy software that doesn’t receive updates, failing-secure rather than failing insecurely.
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?