Accountapprovers, antispam, confirm, emeritus
4,925
edits
Changes
General cleanup, renumber sections of policy
== CA Recommended Practices ==
This page contains a draft set of recommended practices for CAs wishing to have their root CA certificates included in Mozilla products. In some cases these practices are specified or implied by the [http://www.mozilla.org/projects/security/certs/policy Mozilla CA certificate policyRoot Store Policy] and are mandatory for a CA to have its root certificate(s) included. In other cases the recommended practices are not mandatory per policy, but will help speed up a CA's application for inclusion and maximize the chances of its application being approved.
=== Publicly Available CP and CPS ===
This is mandatory.
CAs should supply the complete Certification Policy (CP) and Certification Practice Statement (CPS) containing sufficient information to determine whether and how the CA complies with the Mozilla policy requirements.
==== CP/CPS Documents will be Reviewed! ====
During the [[CA:How_to_apply#Public_discussion|public discussion phase]], your CP/CPS documentation will be reviewed and commented on in the [http://www.mozilla.org/about/forums/#dev-security-policy mozilla.dev.security.policy forum]. Here are some examples of previous reviews of CP/CPS documents:
=== CA Hierarchy ===
A hierarchical structure of a single root with intermediate certs (subroots) is preferred. The single top-level root's public certificate is supplied for Mozilla's root list; the subroots are not. See [[CA:Recommendations_for_Roots]].
CAs that issue certificates under multiple subordinate CAs (i.e., under a root CA whose CA certificate is being requested for inclusion) or under multiple CA hierarchies (i.e., rooted at multiple root CAs, one or more of whose certificates is being requested for inclusion) should provide additional information as noted:
=== Audit Criteria ===
CAs should supply evidence of their being evaluated according to one or more of the criteria accepted as suitable per the Mozilla policy.This is mandatory.
* The CA should indicate exactly which criteria they are being evaluated against (i.e., which of the criteria listed in the Mozilla policy).
* All documents supplied as evidence should be publicly available.
=== Document Handling of IDNs in CP/CPS ===
If a CA allows the use of internationalized domain names (IDNs) in certificates (e.g., as issued for SSL/TLS-enabled servers), the CA should address the issue of homographic spoofing of IDNs in their CP/CPS, even if primary responsibility for dealing with this issue falls on domain registries. (This doesn't mean that the CAs must prevent such spoofing. It merely means that a CA should describe how it handles the issue of spoofing when authenticating the owner of a domain.)
=== Revocation of Compromised Certificates ===
CAs should revoke certificates with private keys that are known to be compromised, or for which verification of subscriber information is known to be invalid. This is mandatory.
=== Verifying Domain Name Ownership ===
We rely on public documentation and audits of those documented processes to ascertain that the requirements of the Mozilla Root Store Policy are met. Section 7 2.2.3 of the [http://www.mozilla.org/projects/security/certs/policy/InclusionPolicy.html Mozilla CA Certificate Inclusion Root Store Policy] states: “for a certificate to be used for SSL-enabled servers, the CA takes reasonable measures to verify that the entity submitting the certificate signing request has registered the domain(s) referenced in the certificate or has been authorized by the domain registrant to act on the registrant's behalf"
The CA's public documentation needs to provide sufficient information describing the steps taken by the CA to confirm that the certificate subscriber owns/controls the domain name to be included in the certificate. For instance, if a challenge-response type of procedure is used, then there needs to be a brief description of the process. If public resources are used, then there should be a description of which public resources are used, what data is retrieved from public resources, and how that data is used to verify that the certificate subscriber owns/controls the domain name.
===== Baseline Requirements: =====
It is '''not''' sufficient to simply reference section 11.1.1 (section 3.2.2.4 in BR version 1.3) of the [https://cabforum.org/baseline-requirements-documents/ CA/Brower Forum's Baseline Requirements (BR)]. The BRs list several ways in which the CA may confirm that the certificate subscriber owns/controls the domain name to be included in the certificate. Simply referencing section 11.1.1 (section 3.2.2.4 in BR version 1.3) of the BRs does not specify which of those options the CA uses, and is insufficient for describing how the CA conforms to the BRs. Section 8.2.1 (section 2 in BR version 1.3) of the BRs says: "The CA SHALL develop, implement, enforce, and annually update a Certificate Policy and/or Certification Practice Statement that describes in detail how the CA implements the latest version of these Requirements."
===== WHOIS: =====
[http://en.wikipedia.org/wiki/WHOIS WHOIS] is used by some CAs as a source of information for checking
ownership/control of the domain name for SSL certificate applications. WHOIS information may be subject to compromise. CAs are responsible for implementing appropriate methods to reduce the risk of compromise. For example, direct command line, HTTPS to the original registrar, or correlating multiple sources. The CA should include information in their CP/CPS about the method that they use to validate the integrity of the data.
===== Email Challenge-Response: =====
Many CAs use an email challenge-response mechanism to verify that the SSL certificate subscriber owns/controls the domain to be included in the certificate. Some CAs allow applicants to select an address from a predetermined list to be used for this verification. See [[CA:Problematic_Practices#Email_Address_Prefixes_for_DV_Certs|Mozilla's restrictions on the set of verification addresses that may be used.]]
=== Verifying Email Address Control ===
We rely on public documentation and audits of those documented processes to ascertain that the requirements of the Mozilla Root Store Policy are met. Section 7 2.2.2 of the [http://www.mozilla.org/projects/security/certs/policy/InclusionPolicy.html Mozilla CA Certificate Inclusion Root Store Policy] states: “for a certificate to be used for digitally signing and/or encrypting email messages, the CA takes reasonable measures to verify that the entity submitting the request controls the email account associated with the email address referenced in the certificate”
The CA's public documentation needs to provide sufficient information describing how the email address is verified to be owned/controlled by the certificate subscriber. For instance, if a challenge-response type of procedure is used, then there needs to be a brief description of the process. If public resources are used, then there should be a description of which public resources are used, what data is retrieved from public resources, and how that data is used to verify that the certificate subscriber owns/controls the email address.
It is not sufficient for the CP/CPS to just say that an email is sent to the customer. The CP/CPS needs to be clear that the RA sends email to the email address to be included in the certificate. The CP/CPS needs to be clear that the email shall contain some non-predictable information that the subscriber must then use or respond with to confirm that the owner of the email address actually received the email and responded.
=== DNS names go in SAN ===
** Required/Optional: '''Deprecated (Discouraged, but not prohibited)'''
** Contents: If present, this field MUST contain a single IP address or Fully-Qualified Domain Name that is one of the values contained in the Certificate’s subjectAltName extension (see Section 9.2.1 - or section 7.1.4.2.1 in BR version 1.3).
=== OCSP ===
