TLS Certificate Authority root certificates and their dates

January 3, 2021

One response to the idea that Certificate Authority root certificates in your system's trust store should have their dates ignored (which is done in practice by some versions of Android and which you might put forward as a philosophical argument) is to ask why CA root certificates even have dates in that case. Or to put it another way, if CA root certificates have dates, shouldn't we respect them?

I think there are two levels of answers about why CA root certificates have dates. The first level is that 'not before' and 'not after' times are required in TLS certificates, and there is no special exemption for CA root certificates (this has been required since at least RFC 3280). As a practical matter, using well-formed and not to badly out of range times is probably required because doing otherwise risks having certificate parsing libraries rejecting your root certificate.

The second level is that more or less from the start of SSL I believe there was at least a social expectation that Certificate Authority root certificates would have 'reasonable' expiry dates. People could have generated root certificates that expired in 2099 (or 2199), but they didn't; instead they picked much closer expiry times. Some of this was probably driven by general cryptographic principles of limited lifetimes being good. Back in the early days of SSL (and it was SSL then), this didn't seem as dangerous as it might to us today because it was often a lot easier to get new root certificates into browser and operating system trust stores.

(Some of it may have been driven by fears of running into the Unix year 2038 problem if you had certificate expiry times that were past that point. Some modern CA root certificates carefully come very close to but not past this time, such as this Comodo root certificate, which has an end time that is slightly over three hours before the critical Unix timestamp. On the other hand, Amazon has CA 2, CA 3, and CA 4 that expire in 2040. And HongKong Post Root CA 3 expires in 2042.)

Given that root certificates have to have dates and even early ones likely faced various pressure to not make their end date too far into the future, the end dates of root certificates don't necessarily reflect the point at which one should end trust in a root certificate. Since there isn't general agreement about this, there probably wouldn't be enough support to introduce a special far off date to signal 'trust forever' and then explicitly treat all other dates as real cutoff dates.

(Mozilla may have a policy on the maximum validity of root certificates they'll include, but if so I can't find it. Their current report of CA root certificates in Firefox (see also) currently seems to have nothing after 2046.)


Comments on this page:

By James (trs80) at 2021-01-04 00:30:08:

Here's the Microsoft list which has a few expiring in 2047, and their requirements, which don't mention expiry.

By Jenny Dybedahl at 2021-01-04 06:20:36:

The main standard to look for requirements for browsers is the CA Browser Forum's Baseline Requirements (for non-EV certificates) and the EV SSL Certificate Guidelines (for EV certificates). Neither one of those mention the CA lifetime at all, they only specify the lifetime of the end user certificates. But as a general rule, you want the CA to live for at least 2.5 times the lifetime of the subordinate CA.

The reason for having any limit is, as you say, the RFC.

The main reason for having a relatively short life time is that root CAs are managed by organisations, and organisations themselves have limited lifetimes. Also an organisation that is trustworthy today may not be tomorrow. Having a natural limit to the time you keep old trash certificates around will reduce at least some of the cruft.

Also, there's the issue of the signature of the CA public key - every single piece of cryptography now in use in TLS will at some point become useless and superseded by new algorithms. In theory, everyone in charge of a root CA will revoke it and start issuing certs from a newer CA when that happens. Also in theory, there is no difference between theory and practice...

Having a natural limit to the CA lifetime improves the odds that old and insecure CAs are removed.

Written on 03 January 2021.
« The modern web and (alleged) software stagnation in the past few decades
TLS Certificate Authority root certificate expiry dates are not how trust in them is managed »

Page tools: View Source, View Normal, Add Comment.
Search:
Login: Password:
Atom Syndication: Recent Comments.

Last modified: Sun Jan 3 23:20:15 2021
This dinky wiki is brought to you by the Insane Hackers Guild, Python sub-branch.