Confirm, administrator
5,526
edits
Changes
m
=== CA Recommended Practices ===
* 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.** The CP/CPS should be publicly available from the CA's official web site.** The format of the CP/CPS document should 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 should be available in an English version.** The CA should provide references to the CP/CPS sections (e.g., by section number and/or page number) that address the requirements of the Mozilla policy.
* === CA Hierarchy ===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.
* === 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.** 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.** 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).
* === Internationalized Domain Names ===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.)
* === Hierarchical Structure ===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]]
==== Notes for future work ====
→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 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.
==== Recommended practices =Publicly Available CP and CPS ===
=== 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.
* What (if anything) should we do regarding the use of non US-ASCII character sets in certs? To what extent is this supported today in NSS and by CAs? This whole problem seems analogous to the IDN problem.
** Excluding the IDN problem (on which I comment under "Recommended practices"), care should be taken to avoid setting technical requirements more stringent than the X.509 specifications. If X.509 permits non-US-ASCII characters in certificates and if NSS and the Mozilla products that use it can operate correctly in the presence of such characters, they should be permitted. On the other hand, if non-US-ASCII characters cause technical problems for NSS or the Mozilla products that use it, that is already addressed under item #4 (after the first two bullets) in the existing policy. Of course, it might be appropriate to add a new bullet in the second set of bullets under item #4 to state explicitly that certificates must not contain any characters that cause software failures or security vulnerabilities in Mozilla products. As an alternative, characters might be limited to those used in languages for which Mozilla products have been localized.
