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. Alex On Thu, May 11, 2017 at 11:33 AM, Ryan Sleevi via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > But if you use the trust database without using NSS, you no longer fit into > any of the assumptions or security models with the discussions here on > m.d.s.p. > > A good example of this would be EKU related misissuance. NSS, like > CryptoAPI and several other platforms, has for the past 15 or so years > enforced a constraint that EKUs in intermediates are subsets of their > issuer's, and can be used to reduce the scope of capabilities for issuance. > > As a result, a certificate with an S/MIME EKU issued from an intermediate > that only has id-kp-serverAuth is not at risk of being trusted for S/MIME. > > In many ways, and across the industry, the trust Store is a function of the > consuming and implementing libraries. As features change and are > implemented - for example, support for Certificate Transparency - that > naturally changes the risk calculus in the trust store. > > That's not to say what you request is apriori unreasonable, simply that > it's unwise, which is why the FAQ covers this - > https://wiki.mozilla.org/CA:FAQ > > There's also the reality that some changes are entirely appropriate for > browser clients, but since Mozilla themselves are not using NSS in > non-browser clients, but are aware that others are, they allow these other > organizations and clients to make the decisions appropriate for their > products and the risks and compatibility issues to their clients. > > The historic process is generally that a change is first made to Firefox, > and then if it is generally desired by the ecosystem, trust status flags > are introduced to NSS and added to the root store and library code. For > example, the constraints for ANSSI followed this pattern. > > Microsoft follows a similar pattern - all "less than trusted" statuses are > captured as extended attributes in the publicly available authroot.stl > > However, for both NSS and CryptoAPI, unless you are using the library > itself to do verification, it's caveat emptor as the consumer. And even if > you are using the library, you still have to be responsible for the > security of your users as relevant to your products needs, and that's > something Mozilla doesn't necessarily have insight into and naturally can't > consider unless you participate here (ideally with commenting on proposals > or sharing what your product would do). Although I suspect since most > non-browser clients are more stable/less likely to update, and have less UI > affordances, the general answer would be biased conservatively towards > doing nothing than the steps necessary to protect browser users. > > On Thu, May 11, 2017 at 7:33 AM Cory Benfield via dev-security-policy < > dev-security-policy@lists.mozilla.org> wrote: > > > On Thursday, May 11, 2017 at 3:21:41 PM UTC+1, Cory Benfield wrote: > > > > > While I’m very supportive of this kind of remediation, it is not a > > remediation that non-browser implementations can follow very easily. For > > example, I run a downstream non-browser HTTP client[1] that by default > uses > > a processed version of the Mozilla CA database[2] to define its list of > > trusted roots. This is very convenient, as it allows me to delegate the > job > > of running a CA program to Mozilla and MDSP, a collection of people much > > better equipped to handle the job. This is a common approach throughout > the > > open source ecosystem: for example, curl also makes available a processed > > version of the Mozilla trust database. > > > > I find it's useful to actually provide the footnotes you say you will: > > > > [1]: http://docs.python-requests.org/en/master/ > > [2]: https://github.com/certifi/python-certifi > > _______________________________________________ > > dev-security-policy mailing list > > dev-security-policy@lists.mozilla.org > > https://lists.mozilla.org/listinfo/dev-security-policy > > > _______________________________________________ > dev-security-policy mailing list > dev-security-policy@lists.mozilla.org > https://lists.mozilla.org/listinfo/dev-security-policy > _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
