Accountapprovers, antispam, confirm, emeritus
4,925
edits
Changes
Split into Required and Recommended
=== Publicly Available CP and CPS ===
===== 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:
** 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 should must 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 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 should 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).
=== Revocation of Compromised Certificates ===
CAs should must 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 ===
===== 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
* 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.
== 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.)
