TLS Certificate Authorities and 'trust'

July 8, 2018

In casual conversation about CAs, it's common for people to talk about whether you trust a CA (or should) and whether a CA is trustworthy. I often bristle at using 'trust' in these contexts, but it's been hard to articulate why. Today, in a conversation on HN prompted by my entry on the first imperative of commercial CAs, I came up with a useful explanation.

Let's imagine that there's a new CA that's successfully set itself up as a copy of how Let's Encrypt operates; it uses the same hardware, runs the same open source software, configures things the same, follows the same procedures, has equally good staff, has been properly audited, and in general has completely duplicated Let's Encrypt's security and operational excellence. However, it has opted for the intellectually pure approach of starting with new root certificates that are not cross-signed by anyone and it is not in any browser root stores yet; as a result, its certificates are not trusted by any browser.

(Let's Encrypt has made this example plausible, because as a non-commercial CA that mostly does things with automation it doesn't have as many reasons to keep how it operates a secret as a commercial CA does.)

In any reasonable and normal sense of the word, this CA is as trustworthy as Let's Encrypt is. It will issue or not issue TLS certificates in the same situations that LE would (ignoring rate limits and pretending that everyone who authorizes LE in CAA records will also authorize this CA and so on), and its infrastructure and procedures are as secure and solid as LE's. If we trust LE, and I think we do, it's hard to say why we wouldn't trust this CA.

If we say that this CA is 'less trustworthy' than Let's Encrypt anyway, what we really mean is 'TLS certificates from this CA currently provoke browser warnings'. This is a perfectly good thing to care about (and it's usually what matters in practice), but it is not really 'trust' and the difference matters because we have a whole tangled set of expectations, beliefs, and intuitions surrounding the idea of trust. When we use the language of trust to talk about technical issues of which CA certificates the browsers accept and when, we create at least some confusion and lose some clarity, and we risk losing sight of what browser-accepted TLS certificates really are, what they tell us, and what we care about with them.

For instance, if we talk about trust and you get a TLS certificate from a CA, it seems to make intuitive sense to say that you need to trust the CA and that it should be trustworthy. But what does that actually mean when we look at the technical details? What should the CA do or not do? How does that affect our security, especially in light of the fundamental practical problem with the CA model?

At the same time, talking about the trustworthiness of a CA is not a pointless thing. If a CA is not trustworthy (in the normal sense of the word), it should not be included in browsers (and eventually will not be). It's just that the trustworthiness of a CA is only loosely correlated with whether TLS certificates from the CA are currently accepted by browsers, which is almost always what we really care about. As we've seen with StartCom, it can take a quite long time to transition from concluding that a CA is no longer trustworthy to having all its TLS certificates no longer accepted by browsers.

There can also be some amount of time when a new CA is trustworthy but is not included in browsers, because inclusion takes a while. This actually happened with Let's Encrypt; it's just that Let's Encrypt worked around this time delay by getting their certificate cross-signed by an existing in-browser CA, so people mostly didn't notice.

(I will concede that using 'trust' casually is very attractive. For example, in the sentence above I initially wrote 'trusted CA' instead of 'in-browser CA', and while that's sort of accurate I decided it was not the right phrasing to use in this entry.)

Sidebar: The one sort of real trust required in the CA model

Browser vendors and other people who maintain sets of root certificates must trust that CAs included in them will not issue certificates improperly and will in general conduct themselves according to the standards and requirements that the browser has. What constitutes improper issuance is one part straightforward and one part very complicated and nuanced; see, for example, the baseline requirements.

Comments on this page:

By Ewen McNeill at 2018-07-09 00:32:17:

I agree with you that "trustworthy" more usefully means "worthy of being trusted" (eg, good processes, reliable, well run, etc) than both that and "will my browser say 'all good' by default" as well.

But it seems to me that the phrase for "trustworthy but 'chain of trust' not automatically present" is "less trusted", as in "the hypothetical Lets Encrypt clone, run just as well, is just as trustworthy but would initially be less trusted" (eg, due to not being in many browser/OS root stores). It's capable of being given the same amount of trust, and there is no reason not to do so (other than maybe "it's new"/"can they keep that up"), but the trust references to do that are not there yet -- so despite being as well run it is currently less trusted.

It seems like maybe you had this intuition about terminology too (eg, "I initially wrote 'trusted CA'"), but I'm unclear why you backed away from it. To my eyes "trustworthy" and "trusted" are two fairly different (if related) concepts; something can be "trustworthy but not trusted" (your example), and something can also be "trusted but not trustworthy" (eg, several CAs that got thrown out of the browser root stores).


It seems to me that distinction you are talking about is whether a CA is trusted by humans vs whether it’s trusted by browsers. An in-browser CA is arguably a CA trusted by browsers, even if it’s one no longer trusted by humans in the know. In your LE clone example, that CA is trustworthy (as per Ewen’s point) but not yet trusted by browsers.

If the problematic uses of “trusted” you object to specifically said “browser-trusted”, I think that would disambiguate away all of the confusion you point out. No? And “a CA whose certificates are accepted by browsers” is a mouthful compared to “a browser-trusted CA”.

So, incorporating Ewen’s point, a distinction between trustworthy and browser-trusted seems to me to cover the ground required to communicate about these issues clearly.

By cks at 2018-07-09 21:14:52:

I like the term 'browser-trusted CA' and I think it's generally unambiguous and clear, but had I thought of it I probably still wouldn't have used it in this specific entry, basically because this is an entire entry about not using 'trust' in relation to CAs.

On a larger scale level, the issue with people using 'trust' in these situations is that I think they generally don't actually mean 'browser-trusted' and probably wouldn't accept me switching their words over to that. They really do intend to mean that they (or you) need to trust the CA and check whether it is worthy of that trust, and I don't think they accept 'the CA will give you a certificate that the browser accepts without complaint' as equivalent or what they care about, regardless of how that gets described. But maybe they would accept and understand me using 'browser-trusted CA' as distinct from the kind of trust they're talking about.

Written on 08 July 2018.
« We've decided to write our future Python tools in Python 3
Remembering that Python lists can use tuples as the sort keys »

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

Last modified: Sun Jul 8 23:02:11 2018
This dinky wiki is brought to you by the Insane Hackers Guild, Python sub-branch.