View source for CA/Required or Recommended Practices

This page contains a set of practices for CAs wishing to have their root CA certificates included in Mozilla products. In some cases these practices are required by the [http://www.mozilla.org/projects/security/certs/policy Mozilla Root Store Policy] and so are mandatory for a CA to have its root certificate(s) included. They are listed here because they are things CAs often get wrong. In other cases the practices are only recommended, but will help speed up a CA's application for inclusion and maximize the chances of its application being approved.

== Required Practices ==

=== 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.

* The CP/CPS must be publicly available from the CA's official web site.
* The CP/CPS must clearly indicate which root and subordinate certificates the practices and processes described in those documents apply to.
* 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 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.

===== CP/CPS Revision Table =====

Section 3.3 of [https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/ Mozilla's Root Store Policy] states: "CPs and CPSes MUST be reviewed and updated as necessary at least once every year, as required by the Baseline Requirements. CAs MUST indicate that this has happened by incrementing the version number and adding a dated changelog entry, even if no other changes are made to the document."

===== CAA Domains listed in CP/CPS =====

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
"issuewild" records as permitting it to issue.

===== BR Commitment to Comply statement in CP/CPS =====

For root certificates with the Websites (TLS/SSL) trust bit enabled, Mozilla requires the corresponding CP/CPS documents to include a statement of commitment to comply with the CA/Browser Forum's Baseline Requirements, as per section 2.2 of the [https://cabforum.org/baseline-requirements-documents/ BRs.]

===== 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.
* The words "''No Stipulation''" mean that the particular document imposes no requirements related to that section. 
** Note that Mozilla's root store policy may be updated soon to forbid the use 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. 
* Sections should 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 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.

Examples:
* If your CA does not allow a particular domain validation method to be used, then the CP or CPS should say that, e.g. "This method of domain validation is not used".
* 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”.
* 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 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.)

===== CP/CPS Documents will be Reviewed! =====

During the [[CA/Application_Verification#Detailed_Review|Detailed Review]] phase, 
your CP/CPS documentation will be thoroughly reviewed and commented on. Concerns raised by the reviewer must be sufficiently resolved before the request will be allowed to enter [[CA/Application_Verification#Public_discussion|public discussion]]. 

Here are some examples of previous reviews of CP/CPS documents:
* [https://bugzilla.mozilla.org/show_bug.cgi?id=1474556#c16 Detailed Review Feedback on Dubai Government CA]
* [https://bugzilla.mozilla.org/show_bug.cgi?id=1448093#c56 Detailed Review Feedback on Microsoft CA]
* [https://bugzilla.mozilla.org/show_bug.cgi?id=1480510#c10 Detailed Review Feedback on Entrust CA]
* [https://bugzilla.mozilla.org/show_bug.cgi?id=1464306#c29 Detailed Review Feedback on Hongkong Post CA]
* [https://bugzilla.mozilla.org/show_bug.cgi?id=1442337#c37 Detailed Review Feedback on eMudhra CA]
* [https://bugzilla.mozilla.org/show_bug.cgi?id=1309797#c72 Detailed Review feedback on SHECA]
* [https://bugzilla.mozilla.org/show_bug.cgi?id=1325532#c41 Detailed Review Feedback on Google Trust Services]
* [https://bugzilla.mozilla.org/show_bug.cgi?id=1390803#c14 Detailed Review Feedback on GlobalSign]
* [https://groups.google.com/d/msg/mozilla.dev.security.policy/36t-jbTQnTY/nwkFyzobAgAJ Review Feedback on WISeKey]
** That was after [https://bugzilla.mozilla.org/show_bug.cgi?id=1403591#c17 blocking problems with the CP/CPS] were resolved.
* [https://groups.google.com/d/msg/mozilla.dev.security.policy/skev4gp_bY4/snIuP2JLAgAJ Review Feedback on Camerfirma]
** CA may submit new root inclusion request for newly generated root that is fully compliant with Mozilla's Root Store Policy and the BRs.
* [https://groups.google.com/d/msg/mozilla.dev.security.policy/R2uG3wisU7s/ie_v7RHMBwAJ Review Feedback on TrustCor]
**  CP and CPS documents clear, well written, and they provided sufficient detail to assess the policies in place. 
* Review Feedback on Kamu SM (Government of Turkey)
** [https://groups.google.com/d/msg/mozilla.dev.security.policy/EtJpw8r7uGs/NmOfjdKIAwAJ CPS document clear and well written]
** [https://groups.google.com/d/msg/mozilla.dev.security.policy/vjXyml8Hy-E/bhxftrNkEAAJ New requirements for Domain Validation] -- all CAs must update their CP/CPS according to section 3.2.2.4 of [https://cabforum.org/wp-content/uploads/CA-Browser-Forum-BR-1.4.1.pdf version 1.4.1 of the BRs].
* Review Feedback on Guangdong Certificate Authority (GDCA)
** [https://groups.google.com/d/msg/mozilla.dev.security.policy/kB2JrygK7Vk/YVOKPfnSAQAJ English translations of documents MUST match the original document.]
** [https://groups.google.com/d/msg/mozilla.dev.security.policy/kB2JrygK7Vk/blMVMaHlAwAJ CA is responsible for providing accurate translation.]
* [https://groups.google.com/d/msg/mozilla.dev.security.policy/zZ5RHXCkpGM/dvx0DjswBgAJ Review Feedback on Amazon Trust Services' CP/CPS]
** Amazon was commended for the clarity of their CP and CPS.
* [https://groups.google.com/d/msg/mozilla.dev.security.policy/Mezqdljjerc/eHC0JDQwBgAJ Review Feedback on Japan GPKI's CP/CPS]
** Japan GPKI's CP/CPS did not contain sufficient detail, so discussion put on hold pending updated CP/CPS.
* A-Trust discussion [https://groups.google.com/d/msg/mozilla.dev.security.policy/Q1beEDFdzxg/6ZILykF0AgAJ put on hold pending translation of CP/CPS into English].
* [https://groups.google.com/d/msg/mozilla.dev.security.policy/uTBDhqO_IB0/bGWV7_lwBAAJ Review Feedback on ComSign's CP/CPS]
** ComSign's discussion was put on hold until the CP/CPS is updated to conform to either RFC 2527 or RFC 3647, as required by the Baseline Requirements. And be translated into English.
* [https://groups.google.com/d/msg/mozilla.dev.security.policy/W0st0yN9bTM/14_-nZ7jGAAJ Review Feedback on SSC's CP/CPS]
** SSC's discussion was put on hold pending updated CP/CPS.
* [https://groups.google.com/d/msg/mozilla.dev.security.policy/gKCqWRmBQ_8/A1eI_zsoAAAJ Review Feedback on ISRG's CP/CPS]
** ISRG's CP/CPS had enough detail, and there were only minor corrections/clarifications to be made.
* [https://groups.google.com/d/msg/mozilla.dev.security.policy/z1rc7vUSlb0/wJkwv5x3AgAJ Review Feedback on DocuSign's CP/CPS]
** DocuSign's CP/CPS had enough detail, and there were only minor corrections/clarifications to be made.
* [https://groups.google.com/d/msg/mozilla.dev.security.policy/dYoQcI0e1qA/ucp1cHfVAAAJ Review Feedback on HARICA's CP/CPS]
** HARICA's CP/CPS had enough detail, and there were only minor corrections/clarifications to be made.
* [https://groups.google.com/d/msg/mozilla.dev.security.policy/47Jz7f8E4RI/ACHCpG2KCpYJ Review Feedback on LuxTrust's CP/CPS]
** The concerns raised regarding LuxTrust's CP/CPS resulted in the inclusion request being put on hold until the CP/CPS was updated.
* [https://groups.google.com/d/msg/mozilla.dev.security.policy/aTN3lkAt0HM/Xvmolz36PsEJ Review Feedback on Krajowa Izba Rozliczeniowa (KIR) CP/CPS]
** KIR updated their CP/CPS according to the [https://groups.google.com/d/msg/mozilla.dev.security.policy/aNbK4zw_Zb8/wmwnbVbLb8cJ review feedback provided in their first discussion] 
** Then had to update their CP/CPS again due to feedback in their second discussion.

=== Audit Criteria ===

CAs must supply evidence of their being evaluated according to one or more of the criteria accepted as suitable per the Mozilla policy.

* The CA must 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 must be publicly available.
* Documents purporting to be from the CA's auditor (or other evaluator) should be available directly from the auditor (e.g., as documents downloadable from the auditor's web site).

==== Complete Audit History ====

[https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy#71-inclusions Mozilla's Root Store Policy] states: "Before being included, CAs MUST provide evidence that their CA certificates have continually, from the time of creation, complied with the then-current Mozilla Root Store Policy and Baseline Requirements."

This requirement may be met via one of the following options:
* Providing the sequence of audit statements on the CA's website.
* Attaching the sequence of audit statements to the root inclusion request (Bugzilla Bug).

=== Revocation of Compromised Certificates ===

CAs must revoke certificates with private keys that are known to be compromised, or for which verification of subscriber information is known to be invalid.

=== 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 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)."

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 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."

'''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.
* BR subsections 3.2.2.4.1 and 3.2.2.4.5 were banned effective 1-August-2018.
** "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 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 =====

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

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 =====

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

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.

=== 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 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 digitally signing 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 or has been authorized by the email account holder to act on the account holder’s behalf. The CA's CP/CPS must clearly specify the procedure(s) that the CA employs to perform this verification."

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.

The recommended way to satisfy this requirement is to perform a challenge-response type of procedure in which the CA sends email to the email address to be included in the certificate, and the applicant must respond in a way that demonstrates that they have control over that email address. For instance, the CA may send an email to the address to be included in the certificate, containing secret unpredictable information, giving the applicant a limited time to use the information within.

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 ===

According to the [https://cabforum.org/baseline-requirements-documents/ CA/Browser Forum Baseline Requirements:]
* Section 7.1.4.2.1 states:
** Certificate Field: '''extensions:subjectAltName'''
** Required/Optional: '''Required'''
** Contents: This extension MUST contain at least one entry. Each entry MUST be either a dNSName containing the Fully-Qualified Domain Name or an iPAddress containing the IP address of a server. The CA MUST confirm that the Applicant controls the Fully-Qualified Domain Name or IP address or has been granted the right to use it by the Domain Name Registrant or IP address assignee, as appropriate. Wildcard FQDNs are permitted.
* Section 7.1.4.2.2 states:
** Certificate Field: '''subject:commonName''' (OID 2.5.4.3)
** 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 7.1.4.2.1).

=== OCSP ===

OCSP responders should be set up to listen on a standard port (e.g. port 80), because firewalls may block ports other than 80/443. Firefox and some other clients do not work with HTTPS OCSP responders, and many firewalls block requests that aren't over port 80, so OCSP responders must be accessible over HTTP (not only HTTPS) on port 80. 

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)
# OCSP Responders SHALL NOT respond “Good” for Unissued Certificates. (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)
# CAs MUST NOT issue OCSP responder certificates using SHA-1 (section 7.1.3)
# OCSP responses MUST conform to RFC6960 and/or RFC5019. (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:
* Go to Firefox -> Preferences... -> Privacy & Security -> Certificates
* Check the box for "Query OCSP responder servers to confirm the current validity of certificates"
* 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.

=== Network Security Controls ===

CAs must maintain current best practices for network security, and have qualified network security audits performed on a regular basis. The [https://www.cabforum.org/ CA/Browser Forum] has published a document called [https://www.cabforum.org/documents.html Network and Certificate System Security Requirements] which should be used as guidance for protecting network and supporting systems.

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.]
* Check for mis-issuance of certificates, especially for high-profile domains.
* Review network infrastructure, monitoring, passwords, etc. for signs of intrusion or weakness.
* Ensure Intrusion Detection System and other monitoring software is up-to-date.
* Confirm the ability to shut down certificate issuance quickly if alerted of intrusion.

=== Precertificates ===

The current implementation of [https://www.certificate-transparency.org/ Certificate Transparency] does not provide any way for Relying Parties to determine if a certificate corresponding to a given precertificate has or has not been issued. It is only safe to assume that a certificate corresponding to every precertificate exists.

[https://tools.ietf.org/html/rfc6962 RFC 6962] states “The signature on the TBSCertificate indicates the certificate authority's intent to issue a certificate.  This intent is considered binding (i.e., misissuance of the Precertificate is considered equal to misissuance of the final certificate).”
 
However, [https://cabforum.org/baseline-requirements-documents/ BR] section 7.1.2.5 states “For purposes of clarification, a Precertificate, as described in RFC 6962 – Certificate Transparency, shall not be considered to be a “certificate” subject to the requirements of RFC 5280 - Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile under these Baseline Requirements.”

Mozilla interprets the BR language as a specific exception allowing CAs to issue a precertificate containing the same serial number as the subsequent certificate [1]. Otherwise, Mozilla infers from the existence of a precertificate that a corresponding certificate has been issued.

This means, for example, that:
* A CA must provide OCSP services and responses in accordance with Mozilla policy for all certificates presumed to exist based on the presence of a Precertificate, even if the certificate does not actually exist
* A CA must be able to revoke a certificate presumed to exist, if revocation of the certificate is required under Mozilla policy, even if the certificate does not actually exist.
* If any corresponding certificate with the same serial number and issuer exists, and can not be verified to match the precertificate using the algorithms in RFC 6962, it will be considered misissued.
* In examining historical issuance, the CA must consider both final certificates and precertificates, even if the precertificate did not ultimately result in the issuance of a certificate.

== Recommended Practices ==

=== 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:
* The CA should provide a graphical or textual description of the CA hierarchy or hierarchies, including which subordinates are under which root CAs
* The CA should indicate the general types of certificates (i.e., for SSL/TLS servers, email signing/encryption, and code signing) issued by each subordinate CA under each root.
* Where a CP/CPS applies to multiple subordinate CAs and/or multiple CA hierarchies, the CA should indicate whether particular sections of the CP/CPS apply to different subordinates and/or hierarchies and, if so, what the differences are.

We also recommend that CAs consider using separate root CA certificates with separate public keys (or separate intermediate CA certificates with separate public keys under a single root) when issuing certificates according to different Certificate Policies, so that we or others may selectively enable or disable acceptance of certificates issued according to a particular policy, or may otherwise treat such certificates differently (e.g., in our products' user interfaces).

=== 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.)

=== 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.

=== Pre-Issuance Linting ===

Recently, several tools have been developed ([https://github.com/awslabs/certlint certlint/cablint], [https://github.com/kroeckx/x509lint x509lint], [https://github.com/zmap/zlint zlint]) which can check a tbsCertificate (To Be Signed Certificate - the certificate complete except for the signature) for a large number of standards violations (BRs, RFCs etc.). It is strongly recommended that CAs integrate such tools into their issuance pipelines such that issuance is, minimally, held up for manual review if an error or warning is found. Because BR or RFC violations are generally considered by Mozilla to be misissuance, such integration will reduce the number of misissuance events a CA experiences, if earlier parts of their pipeline fail in their job of keeping certificates compliant.