Confirm, administrator
5,526
edits
Changes
→OCSP
* Error code: sec_error_bad_database
** the OCSP response gives a cert subject name to identify its signer's certificate, but no certificate by that name can be found -- not in the response, not in the database, and not in the cert chain of the certificate whose status is being checked. See [https://bugzilla.mozilla.org/show_bug.cgi?id=560091 this bugzilla bug] for more details.
=== Constrain 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:
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.
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 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#
== Notes for future work ==
