On 2017-05-11 17:57, Alex Gaynor wrote:
Ryan,

I think you've correctly highlighted that there's a problem -- the Mozilla
CA store is "designed" to be consumed from NSS, and CA-specific
remediations are a part of that (hash algorithms, maximum certificate
lifetimes, and any number of other important technical controls).

Unfortunately, we're currently in a position where near as I can tell, most
code (except Go code :P) making HTTPS requests are using a Mozilla-derived
CA store, and OpenSSL's verifier, which only provides a subset of the
technical controls browsers implement. This is unfortunate, particular
because these clients also do not check CT, so it's entirely possible to
serve them certs which are not publicly visible. In a large sense, browsers
currently act as canaries-in-the-coalmine, protecting non-browser clients.

Like Cory, I help maintain non-browser TLS clients. To that end, I think
it'd be outstanding if as a community we could find a way to get more of
these technical controls into non-browser clients -- some of this is just
things we need to do (e.g. add hash algorithm and lifetime checking to
OpenSSL or all consumers of it), other's need coordination with Mozilla's
root program, and I think Cory's proposal highlights one way of making that
happen.

From past discussion on the OpenSSL list, I understand that we want to support a trust store that supports all such kind of attributes. Some things like for what it's trusted are currently supported by using an X509_AUX structure instead of an X509 structure but then OpenSSL is the only thing that can read it, so this isn't really used.

What we need is a format that can be used by all libraries. It probably needs to be extensible. It should probably support both all certificates in 1 file and all in separate files.


Kurt

_______________________________________________
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Reply via email to