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
