CA/Information Checklist: Difference between revisions

In order to support cryptographic applications such as SSL/TLS connections to web and other servers, and signed and encrypted email, Firefox and other Mozilla-based products contain digital certificates and related metadata for multiple Certification Authorities (CAs). By including the CA certificates and various associated pre-set metadata values Mozilla-based products can recognize as valid the end entity certificates that are issued under the auspices of the CAs in question and are associated with, e.g., web servers, and email senders.

The information provided by the CA will be verified by a representative of Mozilla to the maximum extent practicable using CAs’ published documentation. Statements attributed to third parties (e.g., auditors) shall be verified with those parties. The information gathered should be published through the appropriate Mozilla channels (e.g., web sites, bug reports, and/or discussion forums).

The POCs will:

* Respond to [https://wiki.mozilla.org/CA/Communications CA Communications]

* [mailto:certificates@mozilla.org Inform Mozilla] when there is a change in the organization, ownership, CA policies, or in the POCs that Mozilla should be aware of, as per items 4 through 7 of [https://www.mozilla.org/about/governance/policies/security-group/certs/policy Mozilla's Root Store Policy].

* [mailto:certificates@mozilla.org Provide Mozilla] with updated contact information if a new person becomes a POC.

Required contact information:

#* Please provide the 3 URLs to the test websites as described in Section 2.2 of the BRs: "The CA SHALL host test Web pages that allow Application Software Suppliers to test their software with Subscriber Certificates that chain up to each publicly trusted Root Certificate. At a minimum, the CA SHALL host separate Web pages using Subscriber Certificates that are (i) valid, (ii) revoked, and (iii) expired

#* Make sure you test it yourself in Firefox first, by doing the following:

#*# Clear browser history

#*# Browse to the test website.

#*** It might also include subordinate CAs operated for the benefit of specific third parties. In this case note that we do ''not'' require that the CA submit a complete customer list; rather we are interested in the general type and nature of the third-party arrangements.

# Sub CAs Operated by 3rd Parties

#* If the CA functions as a super CA such their CA policies and auditing don't apply to the subordinate CAs, then those CAs must apply for inclusion themselves as separate trust anchors.

# Cross-Signing

#*The publicly accessible URLs to the document repository and the published document(s) describing how certificates are issued within the hierarchy rooted at this root, as well as other practices associated with the root CA and other CAs in the hierarchy, including in particular the Certification Practice Statement(s) (CPS) and related documents.  

#*The document(s) and section number(s) where the "Commitment to Comply" with the [https://cabforum.org/baseline-requirements-documents/ CA/Browser Forum Baseline Requirements] may be found, as per BR #8.3 (section 2.2 in BR version 1.3).

#** English translations must be provided for the relevant CP/CPS documents, and must match the current version of the CP/CPS documents.

# Audits

#* If you are requesting to enable the Websites (SSL/TLS) trust bit...

#** URLs and section/page number information pointing directly to the sections of the CP/CPS documents that describe the procedures for verifying that the domain referenced in an SSL cert is owned/controlled by the subscriber.  

#** If a challenge-response mechanism via email is used to confirm the ownership/control of the domain name, then provide the list of email addresses that are used for verification.  

#*** [[CA:Problematic_Practices#Email_Address_Prefixes_for_DV_Certs | Potentially Problematic Practices in regards to Email Address Prefixes]] -- The list that the CA uses must either match or be a subset of the list in this wiki page.