Wandering Thoughts archives


TLS Certificate Authority root certificate expiry dates are not how trust in them is managed

One of the reasons I've seen people put forward for respecting the nominal expiry dates of CA root certificates (and not having ones that are too long) is that this is a way to deal with organizational change in Certificate Authorities, and in general in potential trust issues that come up over time. This idea feels natural, because limiting certificate lifetimes is certainly how we deal with a host of trust issues around end TLS certificates (and why very limited certificate lifetimes are a good idea). The only practical way to deal with a mis-issued or compromised end TLS certificate is having it expire, so we need that to happen before too long.

(Even if certificate revocation worked, which it doesn't, you would be relying on someone to detect that the certificate was bad and then notify people, even if it was embarrassing, a lot of work, expensive, or just a hassle. Heartbleed and some other famous TLS issues have convincingly demonstrated that a lot of people won't.)

However, continued trust in Certificate Authorities is not managed through certificate expiry in this way, and it can't be. The lifetimes of CA root certificates are (and have to be) far too long for that, and a compromised CA or root certificate is capable of doing far too much damage in even a short amount of time. Instead, browser and operating system trust in CAs is managed through ongoing audits, supervision, and these days also Certificate Transparency. The specific root certificates in root trust stores are in one sense simply a mechanical manifestation of that trust. You do not trust a CA because you have its root certificate; you have its root certificates because you trust the CA. If trust starts to be lost in a CA, its certificates go away from root trust stores or get limited.

(This hands-on, high-work approach to trust is only viable for CAs because there aren't very many of them.)

As one more or less corollary of this, I think it's fairly unlikely that Mozilla, Chrome, Apple, or Microsoft would refuse to add a new root certificate for a Certificate Authority that had one or more expiring but valid and accepted current root certificates. If they don't trust the CA any more, they would either remove it entirely or stop trusting certificates issued after (or expiring after) a certain date, as was done in 2016 with WoSign. Leaving in the current root certificate with full trust until it expires while refusing to add a new root certificate would be the worst of both worlds, especially since not all software even pays attention to the expiry date of root certificates.

With that said, concerns about the viable lifetime of public key algorithms and cryptographic hashes are reasonably good reasons to not let root certificates live forever. But in practice, if RSA or SHA-2 or whatever starts looking weak, people would probably again not rely on the expiry times of root certificates to deal with it; they would start making more fine-grained and explicit policies about what certificate chains would be trusted under what circumstances. It's very likely that these would effectively sunset current root certificates much faster than their actual expiry times (even for ones that expire earlier than the 2040s).

(There should be no worries about key compromise for root certificates because all root certificates should have keys held only in hardware security modules. This is probably even mandated somewhere in the audit requirements for CAs.)

PS: These days the requirement for regular, contiguous audits mean that a CA has to be actively alive and willing to spend money in order to remain trusted. Inactive or effectively defunct CAs will be automatically weeded out within a year or so, even if no one otherwise notices that they've stopped being active. I also suspect that people monitor Certificate Transparency logs to see what CAs aren't issuing certificates and flag them for greater attention.

tech/TLSRootCertificatesAndDatesII written at 00:48:30; Add Comment

Page tools: See As Normal.
Login: Password:
Atom Syndication: Recent Pages, Recent Comments.

This dinky wiki is brought to you by the Insane Hackers Guild, Python sub-branch.