Why add this Recommended Practice?
We have repeatedly had discussions about the desire to constrain certain types of CAs, such as government run/sponsored CAs, to only issuing certificates within their corresponding TLDs. This has been listed in our wiki pages, and bugs have been filed regarding this:* https://wiki.mozilla.org/CA:Problematic_Practices#Restrict_government_roots_to_their_TLDs* https://wiki.mozilla.org/CA:CertPolicyUpdates#Second_Phase (Compelled CAs)Bugs have also been filed regarding this:* https://bugzilla.mozilla.org/show_bug.cgi?id=555701
Similar concerns have been raised again during the discussion of the HARICA root inclusion request. Through the course of the discussion a compromise was reached with a solution that the CA can implement, and is a good step towards addressing the concerns and potential risk.
Proposed text:
CAs are strongly encouraged to constrain their Issuing Certificates to the first and second-level domains that they are authorized to issue certificates for, such as .edu and the country-level TLD. Some CAs only need to issue certificates within certain TLDs, such as government run/sponsored CAs, and CAs for national research and education networks. The CA’s user base is large enough that they believe typical Mozilla users in their region would benefit from having their root certificate included in NSS, but the CA only needs to issue certificates within certain first and second-level domains.
CAs are strongly encouraged to constrain their Intermediate Issuing Certificates to the first and second-level domains that they are authorized to issue certificates for, such as .edu and the country-level TLD. Some CAs only need to issue certificates within certain TLDs, such as government run/sponsored CAs, and CAs for national research and education networks. The CA’s user base is large enough that typical Mozilla users in their region would benefit from having their root certificate included in NSS, but the CA only needs to issue certificates within certain first and second-level domains. The CA’s CP/CPS documentation should indicate the first and second-level domains that the Issuing Subordinate Certificates are constrained to, and cite the use of Name Constraints as specified in RFC 5280, and marked as critical.
Notes:
* NSS already fully supports RFC 3280 name constraints.
* The Name Constraints extension 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 thatwhile it is part of the standard, it is not required to be implemented.
* Reference: https://groups.google.com/group/mozilla.dev.tech.crypto/browse_thread/thread/131420ae821960df#