Confirm
610
edits
Changes
Added a section on CA hierarchies, and made some other relatively minor changes
** 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.
* 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.
* 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).)
* CAs 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 indeed address the issue of homographic spoofing of internationalized domain names (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 describes should describe how it handles the issue of spoofing when authenticating the owner of a domain.)
==== Notes for future work ====
