Confirm, administrator
5,526
edits
Changes
→Notes for future work
* What (if anything) should we do regarding the use of non US-ASCII character sets in certs? To what extent is this supported today in NSS and by CAs? This whole problem seems analogous to the IDN problem.
** Excluding the IDN problem (on which I comment under "Document Handling of IDNs in CP/CPS"), care should be taken to avoid setting technical requirements more stringent than the X.509 specifications. If X.509 permits non-US-ASCII characters in certificates and if NSS and the Mozilla products that use it can operate correctly in the presence of such characters, they should be permitted. On the other hand, if non-US-ASCII characters cause technical problems for NSS or the Mozilla products that use it, that is already addressed under item #4 (after the first two bullets) in the existing policy. Of course, it might be appropriate to add a new bullet in the second set of bullets under item #4 to state explicitly that certificates must not contain any characters that cause software failures or security vulnerabilities in Mozilla products. As an alternative, characters might be limited to those used in languages for which Mozilla products have been localized.
=== Constrain Issuing Sub-CAs to Authorized Domains (DRAFT) ===
'''PROPOSAL -- Needs further investigation and discussion.'''
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)
* https://bugzilla.mozilla.org/show_bug.cgi?id=555701
Similar concerns have been raised again during the discussion of a recent 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:
Consider constraining your Intermediate Issuing Certificates to the first and second-level domains that they are authorized to issue certificates for, such as .edu, .gov, 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 how the constraints are enforced. For example, indicate the technical controls that are in place, such as the use of Name Constraints as specified in RFC 5280 and marked as critical.
Notes:
* NSS fully supports RFC 3280 name constraints.
* RFC 3280, RFC 4325, and RFC 4630 are all obsolete. RFC 5280 is current.
* 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 that while 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#
