Once upon a time I would said "yes, we should totally encourage people to lovingly craft their perfect trust store, to reduce their risk profile". Now, not so much.
As we've seen in numerous discussions, customers of CAs, particularly large enterprises and vendors (think payment terminals) love to pick out one or two roots, ship them to a billion devices with no update capability, and then use this as an argument against improvements to the WebPKI ecosystem (e.g. SHA-1) or CA distrust (e.g. take a wild guess :-P). Hand crafted trust stores are significantly less likely to have any hope of getting an update than just shipping the whole Mozilla bundle. Further, with CT enforcement, you can get basically the same security guarantee (only certs I intend; +/- 24 hours) without burdening the ecosystem with your lack of agility. Cheers, Alex On Mon, May 15, 2017 at 9:19 AM, Gervase Markham via dev-security-policy < [email protected]> wrote: > On 12/05/17 09:18, Cory Benfield wrote: > > I try not to decide whether there is interest in features like this: > > if they’re easy I’d just implement them and let users decide if they > > want it. That’s what I’d be inclined to do here. If Mozilla added > > such a flag, I’d definitely be open to adding an extra certifi > > bundle. Certifi currently already ships with two bundles (one > > labelled “weak”, which includes 1024-bit roots to work around > > problems with older OpenSSLs), so we could easily add a third called > > “strong” or “pedantic” or “I hate CAs” or something that removes any > > CA that is subject to graduated trust in Firefox. > > If people actually care enough to make a root store choice, should we be > encouraging them instead to use a store containing only the CA they care > about for the connection they are making (and perhaps a backup)? In > other words, is some sort of easy-to-use root store filtering/splitting > tool a better solution to this issue? > > Gerv > _______________________________________________ > dev-security-policy mailing list > [email protected] > https://lists.mozilla.org/listinfo/dev-security-policy > _______________________________________________ dev-security-policy mailing list [email protected] https://lists.mozilla.org/listinfo/dev-security-policy
