On Mon, Oct 20, 2014 at 8:33 AM, Ryan Sleevi < [email protected]> wrote:
> On Mon, October 20, 2014 7:17 am, Anne van Kesteren wrote: > > On Mon, Oct 20, 2014 at 3:41 PM, Gervase Markham <[email protected]> > wrote: > > > Perhaps we just need to jump that gap and accept what is /de facto/ > > > true. > > > > Yeah, as with publicsuffix.org we should own this up. > > I would, in fact, argue strongly against this, despite recognizing the > value that the open root program has. > I strongly agree with Ryan. Besides his very good points, I will add: Not all of the relevant information about the roots is even available in certdata.txt. For example, the name constraints on DCSSI are not encoded in certdata.txt. For a long time there were hard-coded restrictions on some Comodo and the Diginotar certificates, which weren't encoded in certdata.txt. None of Google's CRLSet information is in certdata.txt, and none of Mozilla's OneCRL information is in certdata.txt. One of the key pinning information is in certdata.txt. More generally, when Mozilla or Google address issues related to the root program, they may do so with a code change to Firefox or Chrome that never touches certdata.txt. And, they might do so in a hidden bug that people trying to reuse certdata.txt may not see for many months. It's not reasonable to give everybody who wants to use certdata.txt access to those bugs, and it's not reasonable to constrain fixes to require they be done through certdata.txt. AFAICT, none of the libraries or programs that try to reuse the Mozilla root set even have enough flexibility to add all of these additional data sources to their validation process. For example, let's say some CA in Mozilla's root program mis-issues a google.com certificate. Because google.com is pinned to certain CAs in Firefox, Mozilla might not take any immediate action and may not make the public aware of the issue for a long time (or ever). Note that a consequence of this, even applications that use the NSS cert verification APIs might not be as safe as they expect to be when trusting the NSS root CA set. Cheers, Brian _______________________________________________ dev-security-policy mailing list [email protected] https://lists.mozilla.org/listinfo/dev-security-policy
