CA/Required or Recommended Practices: Difference between revisions

Jump to navigation Jump to search

CA/Required or Recommended Practices (view source)

Revision as of 23:47, 21 October 2022

476 bytes removed ,  21 October 2022
→‎Verifying Domain Name Ownership: Updated language
(→‎Revocation of Compromised Certificates: Added references to MRSP 6.1.1 and revocation reason code guidance)
Line 76: Line 76:
We rely on public documentation and audits of those documented processes to ascertain that the requirements of the Mozilla Root Store Policy are met.
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 2.2 of [http://www.mozilla.org/projects/security/certs/policy/ Mozilla's Root Store Policy] states: "For a certificate capable of being used for SSL-enabled servers, the CA must ensure that the applicant has registered all domain(s) referenced in the certificate or has been authorized by the domain registrant to act on their behalf. This must be done using one or more of the methods documented in section 3.2.2.4 of the CA/Browser Forum Baseline Requirements. The CA's CP/CPS must clearly specify the procedure(s) that the CA employs, and each documented procedure should state which subsection of 3.2.2.4 it is complying with. CAs are not permitted to use 3.2.2.5 (4) ("any other method") to fulfill the requirements of method 3.2.2.4.8 (IP Address)."
In accordance with [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], all domains in a certificate capable of being used for TLS must be verified using one of the methods documented in section 3.2.2.4 of the [https://cabforum.org/baseline-requirements-documents/ CA/Browser Forum Baseline Requirements]. The CA's practices documentation (e.g. its CPS) must clearly specify and detail the procedure(s) that the CA employs, including which subsection of 3.2.2.4 it is complying with.


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.
It also needs to provide sufficient information describing the steps taken by the CA to confirm that the applicant owns/controls the domain names to be included in the certificate.  For instance, if a challenge-response procedure is used, then there must be a description of the process. If public resources are used, then there must 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 applicant owns/controls the domain names.


===== Baseline Requirements =====
===== Baseline Requirements =====


It is '''not''' sufficient to simply reference section 3.2.2.4 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 3.2.2.4 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 2.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. The CA SHALL indicate conformance with this requirement by incrementing the version number and adding a dated changelog entry, even if no other changes are made to the document."
It is '''not''' sufficient to simply reference section 3.2.2.4 of the [https://cabforum.org/baseline-requirements-documents/ CA/Brower Forum's Baseline Requirements]. 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 a subsection within section 3.2.2.4 of the BRs does not specify what the CA does, and is insufficient for describing how the CA conforms to the BRs. Section 2.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."


'''Important:'''
'''Important:'''
* The CPS should state what the CA actually does, not what it could do. Such as which of the allowed domain validation methods the CA uses.
* A CPS must state what the CA actually does, not what it could do, such as which of the allowed domain validation methods the CA uses.
* The following validation methods are prohibited: BR subsections 3.2.2.4.1, BR 3.2.2.4.3, BR 3.2.2.4.5, BR 3.2.2.4.6, BR 3.2.2.4.9, BR 3.2.2.4.11, and BR 3.2.2.5.4.
* The following validation methods are prohibited: BR subsections 3.2.2.4.1, BR 3.2.2.4.3, BR 3.2.2.4.5, BR 3.2.2.4.6, BR 3.2.2.4.9, BR 3.2.2.4.10, BR 3.2.2.4.11, and BR 3.2.2.5.4.
* BR subsection 3.2.2.4.10 contains major vulnerabilities. If the CA uses this method, then the CA should describe how they are mitigating those vulnerabilities. If not using this method, the CPS should say so.


===== WHOIS =====
===== WHOIS and DNS =====


[http://en.wikipedia.org/wiki/WHOIS WHOIS] is used by some CAs as a source of information for checking  
[http://en.wikipedia.org/wiki/WHOIS WHOIS] and DNS are used by CAs as a source of information for checking  
ownership/control of the domain name for TLS 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 its CP/CPS about the method it uses to validate the integrity of the data.
ownership/control of the domain name for TLS certificate applications. WHOIS and DNS information may be subject to compromise (e.g. [https://en.wikipedia.org/wiki/BGP_hijacking BGP hijacking]). CAs are responsible for implementing appropriate methods to reduce the risk that a domain validation method has been compromised. For example, a CA could use direct command line, HTTPS to the original registrar, DNSSEC, or correlate multiple sources of WHOIS and DNS information. The CA should disclose the methods that it uses to ensure the integrity of the data.


It is not sufficient for the CP/CPS to just state that WHOIS is checked. The CP/CPS needs to have a high-level description of how the WHOIS information is used. What information must match with that provided by the certificate subscriber? Is a phone call made or email sent to the technical or administrative contact field of the domain's WHOIS record? If an email is sent, does it include non-predictable information that the technical or administrative contact must use to respond?
It is not sufficient for the CP/CPS to just state that WHOIS is checked. The CP/CPS needs to have a high-level description of how the WHOIS information is used. What information must match with that provided by the certificate subscriber? Is a phone call made or email sent to the technical or administrative contact field of the domain's WHOIS record? If an email is sent, does it include non-predictable information that the technical or administrative contact must use to respond?
Bwilson
Confirmed users
569

edits

Retrieved from "https://wiki.mozilla.org/Special:MobileDiff/1244292"

Navigation menu