On 2011/09/01 06:12 PDT, Sean Leonard wrote: > Looks like there is some discussion on mozilla.dev.security; I wanted to > respond from more of an NSS point of view. > > On 8/30/2011 9:46 AM, Boris Zbarsky wrote: >> I was looking at our CA root list, and a lot of them seem like >> "specialist" CAs that would only issue certs for a limited range of >> hostnames. Could we formalize this, and have CAs indicate any such >> restrictions as part of their application, then enforce it on our end? > > The proper way to enforce this is through the Name Constraints > extension, which is a part of the PKIX profile for certificates. See RFC > 5280, section 4.2.1.10, > <http://www.apps.ietf.org/rfc/rfc5280.html#sec-4.2.1.10>, and section > 6.1.1, <http://tools.ietf.org/html/rfc5280#section-6.1.1>. Note that > while it is part of the standard, it is not required to be implemented. > It seems that the time has finally come to implement it.
Yes, the time has come for CA's to start constraining their subordinates using name constraints. If Mozilla operated an uber-root CA, cross certifying the CAs that now appear in Mozilla's trusted CA list, rather than including those CAs' self-signed roots, Mozilla could impose name constraints on each and every one of those CAs. [snip] > My own estimate is that it would take a developer with a high degree of > familiarity with NSS approximately one and a half man-months, plus an > additional man-month for testing. NSS already fully supports RFC 3280 name constraints. Has for a long time. Name constraints extensions in CA certs are rare things indeed. [snip] > A lot of people like to complain that there are "hundreds" of roots in > their browser stores. But this is not really true. There is only one > trust anchor that matters for 99.9% of the population: the browser > vendor itself (Mozilla). A more appropriate way to think about it is > that Mozilla/the cert repository maintainers operate the main trust > anchor, but have traditionally lacked the tools or the will to enforce > fine-grained constraints on the CA certificates in the stable. Agreed. Tools are not lacking, IMO. Mozilla has said it doesn't want to operate its own Uber-CA. But as you noted, operating its own root CA list is quite equivalent. [snip] I suggest continuing this discussion in m.d.security.policy. _______________________________________________ dev-security mailing list dev-security@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security
