CA/Required or Recommended Practices: Difference between revisions

Jump to navigation Jump to search

CA/Required or Recommended Practices (view source)

Revision as of 02:43, 15 October 2020

497 bytes removed ,  15 October 2020
Made various changes to update this guidance based on changes to the Baseline Requirements and the Mozilla Root Store Policy
(→‎CP/CPS Documents will be Reviewed!: Added review of Digidentity)
(Made various changes to update this guidance based on changes to the Baseline Requirements and the Mozilla Root Store Policy)
Line 5: Line 5:
=== Publicly Available CP and CPS ===
=== Publicly Available CP and CPS ===


CAs must 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.
CAs must supply the complete Certificate Policy (CP) and Certification Practice Statement (CPS) containing sufficient information to determine whether and how the CA complies with the Mozilla policy requirements.


* The CP/CPS must be publicly available from the CA's official web site.
* The CP/CPS must be publicly available from the CA's official web site.
Line 11: Line 11:
* The format of the CP/CPS document must be PDF or another suitable format for  reading documents. CAs should ''not'' use Microsoft Word or other formats intended primarily for editable documents.
* The format of the CP/CPS document must be PDF or another suitable format for  reading documents. CAs should ''not'' use Microsoft Word or other formats intended primarily for editable documents.
* The CP/CPS must be available in an English version. The non-English version may be authoritative (as that's the working language of the CA) but the CA is responsible for ensuring that the translation is not materially different from the authoritative version of the document.
* The CP/CPS must be available in an English version. The non-English version may be authoritative (as that's the working language of the CA) but the CA is responsible for ensuring that the translation is not materially different from the authoritative version of the document.
* The CA must provide references to the CP/CPS sections (e.g., by section number and/or page number) that address the requirements of the Mozilla policy.
* As part of the inclusion process and the Baseline Requirements self-assessment, CAs must provide references to the CP/CPS sections (e.g., by section number and/or page number) that address the requirements of Mozilla policy and the Baseline Requirements.


===== CP/CPS Revision Table =====
===== CP/CPS Revision Table =====
Line 21: Line 21:
Section 2.2 of the [https://cabforum.org/baseline-requirements-documents/ BRs] states: "CA's Certificate Policy and/or Certification Practice
Section 2.2 of the [https://cabforum.org/baseline-requirements-documents/ BRs] states: "CA's Certificate Policy and/or Certification Practice
Statement ... '''shall clearly specify the set of Issuer Domain Names that the CA recognises in CAA''' "issue" or
Statement ... '''shall clearly specify the set of Issuer Domain Names that the CA recognises in CAA''' "issue" or
"issuewild" records as permitting it to issue.
"issuewild" records as permitting it to issue."


===== BR Commitment to Comply statement in CP/CPS =====
===== BR Commitment to Comply statement in CP/CPS =====
Line 28: Line 28:


===== CP/CPS Structured According to RFC 3647 =====
===== CP/CPS Structured According to RFC 3647 =====
CP/CPS documents must be structured according to RFC 3647. This requirement is stated in section 2.2 of the CA/Browser Forum Baseline Requirements, with the effective of 31 May 2018. Further, CP/CPS documents should include every component and subcomponent, and the placement of information should be aligned with the BRs; e.g. domain validation practices should be documented in section 3.2.2.4 of the CA’s CP/CPS.
CP/CPS documents must be structured according to RFC 3647. This requirement is stated in section 2.2 of the CA/Browser Forum Baseline Requirements. Further, CP/CPS documents should include every component and subcomponent, and the placement of information should be aligned with the BRs; e.g. domain validation practices should be documented in section 3.2.2.4 of the CA’s CP/CPS.
* The words "''No Stipulation''" mean that the particular document imposes no requirements related to that section.  
* The words "''No Stipulation''" mean that the particular document imposes no requirements related to that section.  
** Note that Mozilla's root store policy has been updated to define acceptable usage of "No Stipulation" in CP/CPS documents.  
** Note that the Mozilla root store policy defines acceptable usage of "No Stipulation" in CP/CPS documents.  
* The words "''Not applicable''" are acceptable to indicate that the CA’s policies forbid the practice that is the title of the section. Language similar to “We do not perform <subject of the section>” is preferred.  
* The words "''Not applicable''" are acceptable to indicate that the CA’s policies forbid the practice that is the title of the section. Language similar to “We do not perform <subject of the section>” is preferred.  
* Sections should not be left blank. The purpose of "No Stipulation" is to make it clear that the omission of content was intentional.
* Sections must not be left blank. The purpose of "No Stipulation" is to make it clear that the omission of content was intentional.  
** Note that Mozilla's root store policy may be updated soon to forbid blank sections in CP/CPS documents.  
* If a full description of a section is repeated elsewhere in the document, language similar to “Refer to Section 1.2.3” is preferred. Cross-referencing between CP and CPS documents is acceptable as long as both documents are published on your CA's website, and the CP and CPS documents clearly indicate which root certificates they govern.
* If a full description of a section is repeated elsewhere in the document, language similar to “Refer to Section 1.2.3” is preferred. Cross-referencing between CP and CPS documents is acceptable as long as both documents are published on your CA's website, and the CP and CPS documents clearly indicate which root certificates they govern.
* If a section in your CP/CPS only applies to a certain type of certificate, then your CP/CPS needs to state that. [https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy#52-forbidden-and-required-practices Mozilla's Root Store Policy] says: "CAs MUST NOT generate the key pairs for end-entity certificates that have an EKU extension containing the KeyPurposeIds id-kp-serverAuth or anyExtendedKeyUsage." So if your CP/CPS allows for generation and escrow of private keys for personal certificates, then your CP/CPS should clearly indicate that those sections do not apply to SSL certificates.
* If a section in your CP/CPS only applies to a certain type of certificate, then your CP/CPS needs to state that. [https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy#52-forbidden-and-required-practices Mozilla's Root Store Policy] says: "CAs MUST NOT generate the key pairs for end-entity certificates that have an EKU extension containing the KeyPurposeIds id-kp-serverAuth or anyExtendedKeyUsage." So if your CP/CPS allows for generation and escrow of private keys for personal certificates, then your CP/CPS should clearly indicate that those sections do not apply to TLS server certificates.


Examples:
Examples:
Line 41: Line 40:
* If your CP delegates requirements to one or more CPSs, then the CP should state "Refer to CPS".
* If your CP delegates requirements to one or more CPSs, then the CP should state "Refer to CPS".
* The BRs do not allow certificate suspension, so the CA’s CPS should state that certificate suspension is not allowed for SSL certs, and then the other sections related to suspension should say “Not applicable”.
* The BRs do not allow certificate suspension, so the CA’s CPS should state that certificate suspension is not allowed for SSL certs, and then the other sections related to suspension should say “Not applicable”.
* If your CA does not issue SSL certs containing IP addresses, then section 3.2.2.5, ‘Authentication for an IP Address’ in your CP or CPS should say that such certificate issuance is not allowed; e.g. “No IP address certificates are issued under this CPS.”
* If your CA does not issue TLS server certificates containing IP addresses, then section 3.2.2.5, ‘Authentication for an IP Address’ in your CP or CPS should say that such certificate issuance is not allowed, e.g. “No IP address certificates are issued under this CPS.”
* If your CP contains the full description of section 5, then the CPS may say "As stipulated in section 5 of the CP". (This assumes that the CP is also published on your website, and the CP and CPS documents clearly indicate which root certificates they govern.)
* If your CP contains full descriptions of physical security required by section 5 of RFC 3647, then the CPS may say "As stipulated in section 5 of the CP". (This assumes that the CP is also published on your website, and the CP and CPS documents clearly indicate which root certificates they govern.)


===== CP/CPS Documents will be Reviewed! =====
===== CP/CPS Documents will be Reviewed! =====
Line 136: Line 135:
===== 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."
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."


'''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.
* 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.
* BR subsections 3.2.2.4.1 and 3.2.2.4.5 were banned effective 1-August-2018.
* 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.
** "CAs must stop using domain validation methods BR 3.2.2.4.1 and 3.2.2.4.5, stop reusing validation data from those methods"
* BR subsection 3.2.2.4.9 was banned by ballot SC15, effective 16-March 2019.
* 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.
* 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.
* BR section 3.2.2.5(4) was updated by ballot SC7 to remove "any other method", effective 1-August 2019. Prior to that date:
** Saying the CA follows BR section 3.2.2.5 does not meet [https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy#22-validation-practices Mozilla's disclosure requirements for this method]. The CPS must describe if/how "any other method" is implemented.
** BR subsection 3.2.2.5(4) "any other method" is not permitted in conjunction with 3.2.2.4.8 per [https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy#22-validation-practices Mozilla's Root Store Policy]. The CPS should be clear that they do not do that.


===== WHOIS =====
===== WHOIS =====


[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] 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.
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.


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?


===== Email Challenge-Response =====
===== 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.]]
Many CAs use an email challenge-response mechanism to verify that the TLS 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.]]


CAs using this method of domain validation must ensure that they are using the full email, and that none of their systems misinterpret the localpart of an email. If your system fails to process the exact email, it will misinterpret the '+' sign as a delimiter. Consider, for example, the WHOIS contact information for a domain of "user+word@example.com" or "user=word@example.com". Both of these email addresses conform to the rules set out in RFC 822 with respect to the 'localpart' syntax. If your system emails to "word@example.com", rather than to the full "user+word@example.com" / "user=word@example.com", it will allow an attacker (who obtains "word@example.com") to cause and obtain certificates for example.com. Please work with your engineering department to ensure your systems properly handle such cases, as well as handling productions such as quoted-string, as also detailed in RFC 822 and subsequent RFCs. This is especially important as EAI addresses (described in RFC 6530 and related) come into play.
CAs using this method of domain validation must ensure that they are using the full email, and that none of their systems misinterpret the localpart of an email. If your system fails to process the exact email, it will misinterpret the '+' sign as a delimiter. Consider, for example, the WHOIS contact information for a domain of "user+word@example.com" or "user=word@example.com". Both of these email addresses conform to the rules set out in RFC 822 with respect to the 'localpart' syntax. If your system emails to "word@example.com", rather than to the full "user+word@example.com" / "user=word@example.com", it will allow an attacker (who obtains "word@example.com") to obtain certificates for example.com. Please work with your engineering department to ensure that your systems properly handle such cases, as well as handling variations, such as quoted-string, as also detailed in RFC 822 and subsequent RFCs. This is especially important as EAI addresses (described in RFC 6530 and related) come into play.


=== Verifying Email Address Control ===  
=== Verifying Email Address Control ===  
Line 190: Line 184:


As per the [https://www.cabforum.org/documents.html CA/Browser Forum’s Baseline Requirements]:
As per the [https://www.cabforum.org/documents.html CA/Browser Forum’s Baseline Requirements]:
# The OCSP URI must be provided in the certificate, except when OCSP stapling is used. (sections 7.1.2.2, 7.1.2.3)
# The OCSP URI must be provided in end entity certificates. (BR section 7.1.2.3.c.)
# OCSP Responders SHALL NOT respond “Good” for Unissued Certificates. (section 4.9.10)
# OCSP Responders SHALL NOT respond “Good” for Unissued Certificates. (BR section 4.9.10)
# OCSP Responses shall be updated at least every four days and have a maximum expiration time of ten days (section 4.9.10)
# OCSP Responses shall be updated at least every four days and have a maximum expiration time of ten days (additional OCSP requirements may be found in BR section 4.9.10)
# CAs MUST NOT issue OCSP responder certificates using SHA-1 (section 7.1.3)
# CAs MUST NOT issue OCSP responder certificates using SHA-1 (BR section 7.1.3.2.1)
# OCSP responses MUST conform to RFC6960 and/or RFC5019. (section 4.9.9)
# OCSP responses MUST conform to RFC6960 and/or RFC5019. (BR section 4.9.9)


You MUST test your OCSP service in Firefox! We expect OCSP responders to function without error in Mozilla products. To test in Firefox:
You MUST test your OCSP service in Firefox! We expect OCSP responders to function without error in Mozilla products. To test in Firefox:
* Go to Firefox -> Preferences... -> Privacy & Security -> Certificates
* Go to Firefox -> Options... -> Privacy & Security -> Certificates
* Check the box for "Query OCSP responder servers to confirm the current validity of certificates"
* Check the box for "Query OCSP responder servers to confirm the current validity of certificates"
* You may need to clear your history cache
* You may need to clear your history cache
* Browse to a website whose SSL certificate chains up to your root and has the corresponding OCSP URI in the AIA extension.
* Browse to a website whose TLS certificate chains up to your root and has the corresponding OCSP URI in the AIA extension.


=== Network Security Controls ===
=== Network Security Controls ===
Line 207: Line 201:


It is expected that CAs do the following on a regular basis:
It is expected that CAs do the following on a regular basis:
* Maintain network security controls that at minimum meet the [https://www.cabforum.org/documents.html Network and Certificate System Security Requirements.]
* Maintain network security controls that meet the [https://www.cabforum.org/documents.html Network and Certificate System Security Requirements.]
* Check for mis-issuance of certificates, especially for high-profile domains.
* Check for mis-issuance of certificates, especially for high-profile domains.
* Review network infrastructure, monitoring, passwords, etc. for signs of intrusion or weakness.
* Review network infrastructure, monitoring, passwords, etc. for signs of intrusion or weakness.
Line 217: Line 211:
=== CA Hierarchy ===
=== 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.  
A hierarchical structure of a single root with intermediate certificates (subordinate CAs) is preferred. The single top-level root's public certificate is supplied for Mozilla's root list; subordinate CA certificates (including other self-signed root CA certificates that chain to the trusted root) must be reported in the CCADB.  


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:
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:
Line 232: Line 226:
=== Usage of Appropriate Constraints ===
=== Usage of Appropriate Constraints ===


Root certificates in Mozilla's program can have either the SSL trust bit set, or the Email trust bit, or both. If only one of those bits is set, relying software will trust certificates in that hierarchy for only that purpose. Nevertheless, it is a best practice for the immediately-issuing intermediate certificate to also contain EKU constraints of either id-kp-serverAuth or id-kp-emailProtection as appropriate, such that if the trust status of the root ever changes (or is not enforced for some reason), the end-entity certificates are still appropriately constrained.
Root certificates in Mozilla's program can have either the Websites trust bit set, or the Email trust bit, or both. If only one of those bits is set, relying software will trust certificates in that hierarchy for only that purpose. Nevertheless, it is a best practice for the immediately-issuing intermediate certificate to also contain EKU constraints of either id-kp-serverAuth or id-kp-emailProtection as appropriate, such that if the trust status of the root ever changes (or is not enforced for some reason), the end-entity certificates are still appropriately constrained.


=== Pre-Issuance Linting ===
=== Pre-Issuance Linting ===
Bwilson
Confirmed users
527

edits

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

Navigation menu