CA/Information Checklist

Information checklist for CAs applying for inclusion in Mozilla

In order to support cryptographic applications such as SSL/TLS connections to web and other servers, signed and encrypted email, and verification of digitally signed executable code objects, 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, email senders, and software publishers.

CAs wishing to have their certificates included in Mozilla products must comply with the requirements of the Mozilla CA certificate policy and must supply the information necessary to determine whether or not the policy’s requirements have been satisfied. This information includes (but is not necessarily limited to) the following:

• General information about the CA’s associated organization (i.e., the company, nonprofit organization, or government agency operating the CA), including
  • Name. (This is the name by which the CA is most commonly known, e.g., "GeoTrust".)
  • Website URL. (This should point to the English version of the web site if one exists.)
  • Organizational type. (Whether the CA is operated by a private or public corporation, government agency, international organization, academic institution or consortium, NGO, etc. Note that in some cases the CA may be of a hybrid type, e.g., a corporation established by the government. For government CAs, the type of government should be noted, e.g., national, regional/state/provincial, or municipal.)
  • Primary market / customer base. (Which types of customers does the CA serve? Are there particular vertical market segments in which it operates? Does it focus its activities on a particular country or other geographic region?)
• For each root CA whose certificate is to be included in Mozilla (or whose metadata is to be modified):
  • The name of the root CA. (This is the so-called "friendly name" to be used when displaying information about the root, e.g., "GeoTrust Global CA". It is typically identical to or a variant of the name found within the Subject attribute of the root CA certificate itself.)
  • The root CA certificate. (Preferably this is in the form of a public URL through which the CA certificate can be directly downloaded. If no such public URL exists, a copy of the certificate should be obtained from the CA by other means and that copy should be attached to the bug report associated with the CA's request.)
  • The X.509 certificate version. (For all but legacy roots this should be version 3.)
  • SHA-1 fingerprint. (The SHA-1 fingerprint of the root CA certificate.)
  • Modulus length. (The length of the RSA modulus for the root CA public and private keys. Note that although the Mozilla CA certificate policy does not specify a minimum modulus length, in practice a modulus length of less than 2048 bits is cause for concern.) [What is the corresponding measure for ECC certificates?]
  • Valid from (YYYY-MM-DD). (The date from which the root CA certificate is valid.)
  • Valid to (YYYY-MM-DD). (The date until which the root CA certificate is valid.)
  • A description of the PKI hierarchy rooted at or otherwise associated with this root CA certificate, including:
    • A list or summary description of CAs with certificates signed by this root, including
      • Any subordinate CAs operated by the CA organization associated with the root CA. (For example, this might include subordinate CAs created to issue different classes or types of end entity certificates: Class 1 vs. class 2 certificates, qualified vs. non-qualified certificates, EV certificates vs. non-EV certificates, SSL certificates vs. email certificates, and so on.)
      • Any subordinate CAs operated by third parties, if any. (For example, this might include enterprise CAs for which this root CA has issued CA certificates.)
      • Any other roots for which this root CA has issued cross-signing certificates. (If any such roots exist, it is important to note whether the roots in question are already included in the Mozilla root store or not.)
    • A list of any other root CAs that have issued cross-signing certificates for this root CA. (Again, it is important to note whether any such roots are already included in the Mozilla root store or not.)
    • The extent and nature of contractual and technical controls exercised over subordinate CAs, including
      • Whether or not subordinate CAs are constrained to issue certificates only within certain domains. [We need a technical description of how this is typically controlled.]
      • Whether or not subordinate CAs can create their own subordinates. [We need a technical description of how this is typically controlled.]
    • The extent and nature of audits performed against subordinate CAs, including:
      • Whether or not subordinate CAs are included within the scope of any audit(s) done against the root CA.
      • Whether or not subordinate CAs are subject to third-party audits independent of any audit(s) done against the root CA.
      • The frequency at which any audit(s) for subordinate CAs are done.
  • Whether certificates are issued for any of the following purposes within the hierarchy rooted at this root CA certificate:
    • Certificates usable for enabling web or other servers to support SSL/TLS connections. [We need a description of the technical characteristics of such certificates.]
    • Certificates usable for signing and encrypting email messages (e.g., using S/MIME). [We need a description of the technical characteristics of such certificates.]
    • Certificates usable for digitally signing executable code objects. [We need a description of the technical characteristics of such certificates.]
  • If SSL certificates are issued within the hierarchy rooted at this root CA certificate:
    • Whether or not the domain name referenced in the certificate is verified to be owned/controlled by the certificate subscriber. (Note that per the Mozilla policy this verification must be done in addition to any verification of the subscriber’s legal identity. Certificates for which only this level of verification is done are commonly referred to as DV certificates.)
    • Whether or not the value of the Organization attribute is verified to be that associated with the certificate subscriber. (Certificates for which this level of verification is done are commonly referred to as OV certificates.)
    • Whether verification of the certificate subscriber conforms to the Extended Validation Certificate Guidelines issued by the CAB Forum. (Certificates for which this level of verification is done are commonly referred to as EV certificates.)
  • If email certificates are issued within the hierarchy rooted at this root CA certificate:
    • Whether or not the email account associated with the email address in the certificate is verified to be owned/controlled by the certificate subscriber. (Note that per the Mozilla policy this verification must be done in addition to any verification of the subscriber’s legal identity.)
    • Whether or not the identity information in the certificate is verified to be that of the certificate subscriber.
  • If code signing certificates are issued within the hierarchy rooted at this root CA certificate, whether or not the identity information in the certificate is verified to be that of the certificate subscriber.
  • If EV certificates are issued within the hierarchy rooted at this root, the EV policy OID(s) associated with those EV certificates.
  • Example certificate(s) issued within the hierarchy rooted at this root, including the full certificate chain(s) where applicable. (There should be at least one example certificate for each of the major types of certificates issued, e.g., email vs. SSL vs. code signing, or EV vs. OV vs. DV. For SSL certificates this should also include URLs of one or more web servers using the certificate(s).)
  • Whether or not the validity of end entity and CA certificates issued within the hierarchy rooted at this root may be verified using Certificate Revocation Lists (CRLs) and, if so, the URL(s) at which the CRL(s) may be obtained.
  • Whether or not the validity of end entity and CA certificates issued within the hierarchy rooted at this root may be verified using the Online Certificate Status Protocol (OCSP) and, if so, the URL(s) for the associated OCSP responder(s).
  • The maximum time elapsing from the revocation of an end entity or CA certificate until CRLs and/or OCSP responders are updated to reflect that revocation.
  • 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. (These documents should be available at publicly accessible URLs, and should be in English or available in English translation.)
  • The published document(s) relating to independent audit(s) of the root CA and any CAs within the hierarchy rooted at the root. (For example, for WebTrust for CAs audits this would be the "audit report and management assertions" document available from the webtrust.org site or elsewhere.)

The above information should be verified to the maximum extent practicable using CAs’ published documentation. Statements attributed to third parties (e.g., auditors) should 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).