Linux Certificate Authority root stores have a too simple view of 'trust'

There is no API to actually handle trust. If you are asking `curl` or `openssl` to verify the chain, it needs to read it from somewhere. By convention, there is `OPENSSLDIR`, for example.

But that just tells us where the root certs are, not much more. In the API, I load the root CAs and check validity of the cert, nothing beyond that.

And I can do that in multiple different TLS engines.

Given that there is no API for this, all the TLS engines need to re-implement this logic. Hell, in most cases, even things like validity range checks are handled by the applicative logic.

On Windows, there is the builtin TLS API `schannel` which means that you have a lot more structure / order in this. Including the ability to express those sort of details.

There is another aspect, as well. You need to be able to express those issues as errors, otherwise the user is going to be left with a broken box and no idea what is going on.

Yeah, TFA seems to make a good argument for a libca-certificates, or so.

> There is another aspect, as well. You need to be able to express those issues as errors, otherwise the user is going to be left with a broken box and no idea what is going on.

TLS libraries are terrible at this. Part of it is C: the "integer is the only error type you'll ever need" cannot convey the necessary context, such as which cert is the problem.

Having a library might also help with path building bugs. I've seen bugs in both OpenSSL and GnuTLS in building a correct path, and both just from when the ISRG cross-sign expired.

… and maybe a more complicated data structure in /etc/certs (or whatever the path is) will keep prying vendors out. I've seen a lot of people make out of band changes there, and I would suspect those qualify as "undefined behavior", but OpenSSL's docs don't seem to answer the question of "what happens if vendors do random stuff?" (Like drop non-CA certs into the list of CAs, or don't update the symlinks that seem to form an index…)

Related:

https://news.ycombinator.com/item?id=33810755 ("Mozilla, Microsoft yank TrustCor's root certificate authority", 5 days ago, > 350 comments)

There are definitely limitations in GNU/Linux root stores. E.g. to my knowledge it's impossible to distinguish between the root coming from the distro vs coming from a custom configuration, e.g. for corporate MITM proxies. So you can't e.g. require SCTs to be present for former but not require them for latter, like how Chrome does it for example.

Also, is this additional information even published by Mozilla in a standardized format or if it's just put somewhere into Firefox source code?

Also note that, given how Firefox doesn't implement SCT requirements, TrustCor could also just back-time certificates. So Firefox has similar vulnerability properties as users of distros that haven't removed TrustCor as a CA.

So ideally you would also make it possible to distinguish between OS provided and custom configured certificates, to allow libraries to check for SCTs at all. Otherwise you haven't gained much from the additional information of limiting a CAs ability to issue new certificates.

> There is no API to actually handle trust.

The various TLS libraries already agree on at least one thing: what certificates look like on disk (e.g. PEM and DER formats). There's no reason why some committee couldn't sit down and standardize a format for ancillary data such as the trust date cutoffs mentioned here. Then the TLS libraries would have to implement it, and return appropriate errors from their validation functions. This could possibly be done in a way without needing applications to also be updated, though that depends on how each TLS library reports validation errors.

But even if a particular TLS library doesn't have a way to express these errors properly, I think it's better to have a user confused as to why they can't connect to a site, than silently connect to a site "protected" by a certificate that shouldn't be trusted.