Changes

This page contains comments about various CA practices that have been the subject of discussion in past CA evaluations. Some of these practices are addressed by the [http://www.mozilla.org/projects/security/certs/policy Mozilla's Root Store Policy] and are forbidden. They are listed here because they are things CAs often get wrong. Others, we do not necessarily consider security risks, but we want to highlight them because they've occasioned controversy in the past and have in some cases caused approval of applications to be delayed. Additional practices may be addressed in future versions of the policy.

[https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/ Mozilla's Root Store Policy] requires CAs to conform to the [https://cabforum.org/baseline-requirements-documents/ CA/Browser Forum Baseline Requirements (BRs)] in the issuance and management of publicly trusted TLS server certificates. This includes the BR restrictions on the use of email as a way of validating that the certificate subscriber owns or controls the domain name to be included in the certificate. CAs are expected to conform to BR Section section 3.2.2.4, which restricts the email addresses that may be used to authenticate the subscriber to information listed in the "registrant", "technical", or "administrative" WHOIS records (BR § 3.2.2.4.2) and a selected whitelist of constructed addresses, which are limited to local-parts of "admin", "administrator", "webmaster", "hostmaster", and "postmaster" followed by the "at" sign ("@") and the domain name in question (read BR § 3.2.2.4.4 for specifics).

A CA that authorizes certificate subscribers by contacting any other email addresses is deemed to be non-compliant with Mozilla's Root Store Policy and non-conforming to a violation of the Baseline Requirements, and may have action taken against it. CAs are also reminded that Mozilla's Root Store Policy and the Baseline Requirements extend to any CA certificates that are technically capable of issuing SSL TLS server certificates, and subordinate CAs that fail to follow these requirements reflect upon put the issuing root CA that certified itin jeopardy of removal from Mozilla's root store.

Section 5.2 of [https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy#52-forbidden-and-required-practices Mozilla's Root Store Policy] states: "CAs CA operators MUST NOT generate the key pairs for end-entity certificates that have an EKU extension containing the KeyPurposeIds id-kp-serverAuth or anyExtendedKeyUsage, unless the certificate is being issued to the CA itself."

In other words, CAs must never note generate the key pairs for TLS server certificates, except for their own use (e.g. certificates for the test websites required by BR section 2.2). CAs may only generate the key pairs for S/MIME certificates. Distribution or transfer of S/MIME certificates in unprotected PKCS#12 form through unsecure electronic channels is not allowed. If a PKCS#12 file is distributed via a physical data storage device, then:

This A Subject Alternative Name (SAN) with an internal or local name or with a reserved or private IP address is forbidden by Section section 7.1.4.2.1 of the [https://cabforum.org/baseline-requirements-documents/ Baseline Requirements], which says, "CAs SHALL NOT issue certificates with a subjectAlternativeName extension or Subject commonName field containing a Reserved IP Address or Internal Name."

Issuance of SHA-1 subordinate CA certificates, SSL end entity certificates, and or OCSP responder certificates is forbidden by [https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy#51-algorithms section 5.1 of Mozilla's Root Store Policy] and section 7.1.3 .2.1 of the [https://cabforum.org/baseline-requirements-documents/ Baseline Requirements]. Other uses of SHA-1 are also being phased out. See [https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy#513-sha-1 MRSP § 5.1.3].

[https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy#22-validation-practices Section 2.2 of Mozilla's Root Store Policy] says: "The CA operator SHALL NOT delegate validation of the domain portion of an email address."

More information on our disclosure requirements [https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/#84-externally-operated-subordinate-cas Section 8.4 of the Mozilla Root Store Policy] requires that externally operated CAs undergo public discussion unless they meet one of the enumerated exceptions (e.g. they are already in the root store with the ability to issue the same type of certificate that they were already approved for). See [https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/#84-externally-operated-subordinate-cas MRSP § 8.4] and [https://wiki.mozilla.org/CA:SubordinateCA_checklist/External_Sub_CAs#NonProcess_for_non-Technically-Constrained_Subordinate_CAs Process for non-Technically-disclosable_Intermediate_Certificates is available hereConstrained Subordinate CAs]for details.

In various contexts Firefox and other Mozilla-based products display to users the names of root CAs, issuing CAs, and intermediate CAs in general. In some cases, CA names are very too generic, e.g., "Secure Server CA"; this , which makes it difficult for users to ascertain who operates the CA without undertaking a detailed investigation.

Additionally, the issuer and subject information in the root certificate should provide clear indication about who owns or operates the certificateCA. Generic issuer and subject information inhibits the users' ability to establish a chain of trust, and to pursue complaints when appropriate. For instance, the following issuer information would not be acceptable totally unacceptable in a root certificate to be included in NSS.

There is no information in this issuer that can be linked back to any particular CAoperator. There is no distinguishable company name or brand name. All of the information in this issuer is too generic to do a search on and hope to find the responsible CAoperator. (Moreover, it lacks the two‐letter ISO 3166‐1 country code, which is required by section 7.1.4.3 of the Baseline Requirements.)

'''Important:''' Both the O and the CN must be meaningful, and not generic terms such as "admin" or "root". It is not acceptable for the O not to have identify the O be CA operator and a generic term such as "Admin" because it could will mislead users that , who rely on the issuer details, such as when you they hover your their mouse over the domain or organization section lock icon in the address bar.

CAs should be contactable by, and accept and act upon complaints made by, those relying on their assertions of identity. For CAs included in Mozilla, this will include being responsive to members of the general public, including people who have not purchased products from that CA. See [https://cabforum.org/baseline-requirements-documents/ Baseline Requirements], section 4.9.3, "The CA SHALL maintain a continuous 24x7 ability to accept and respond to revocation requests and Certificate Problem Reports. The CA SHALL provide Subscribers, Relying Parties, Application Software Suppliers, and other third parties with clear instructions for reporting suspected Private Key Compromise, Certificate misuse, or other types of fraud, compromise, misuse, inappropriate conduct, or any other matter related to Certificates. The CA SHALL publicly disclose the instructions through a readily accessible online means and in Section 1.5.2 of their CPS."