** 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 Issuing Sub-CAs to Authorized Domains (DRAFT) Network Security Controls ==='''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 pagesmust maintain current best practices regarding network security, and bugs have been filed regarding this:* qualified network security audits performed on a regular basis. The [https://wikiwww.mozillacabforum.org/CA:Problematic_Practices#Restrict_government_roots_to_their_TLDs* https://wiki.mozilla.org/CA:CertPolicyUpdates#Second_Phase (Compelled CAs)* Browser Forum] has published a document called [https://bugzillawww.mozillacabforum.org/show_bugdocuments.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 html Network and second-level domains. The CA’s CP/CPS documentation Certificate System Security Requirements] which 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 be used a part set of the PKIX profile recommendations for certificates. See RFC5280, section 4.2.1.10, <http://www.apps.ietf.org/rfc/rfc5280.html#sec-4.2.1.10>, protecting network 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.googlesupporting systems.com/group/mozilla.dev.tech.crypto/browse_thread/thread/131420ae821960df#
== Notes for future work ==
