On 12/05/2017 10:06, Kurt Roeckx wrote:
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.
Could something be derived from / based on the ASN.1 format apparently
used by Microsoft in it's root store, with OpenSSL/Mozilla OIDs added
for things that have no Microsoft notation yet.
Another starting point (if not the same) could be the "trusted
certificate" format that some openssl commands can generate.
Ideally in the future, code support for a new restriction type can be
implemented (in both NSS and other libraries) before the community
decision to enforce that restriction against a given CA comes into
effect. For example, some time has already passed since Google
proposed their set of Symantec restrictions, but the trigger has not
been pulled yet on any of those.
Just for clarity, could you confirm that the current (1.0.2 / 1.1.0)
OpenSSL verifiers do not check if issuing CA has a conflicting EKU list?
Enjoy
Jakob
--
Jakob Bohm, CIO, Partner, WiseMo A/S. https://www.wisemo.com
Transformervej 29, 2860 Søborg, Denmark. Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded
_______________________________________________
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy
