Confirm, administrator
5,526
edits
Changes
updated links
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.
CAs wishing to have their certificates included in Mozilla products must comply with the requirements of the [httphttps://www.mozilla.org/projectsabout/governance/policies/security-group/certs/policy/ Mozilla CA certificate policyRoot Store Policy] and must supply the information necessary to determine whether or not the policy’s requirements have been satisfied. The information must be provided in a Mozilla Bugzilla bug as described in [[CA:How_to_apply|How_to_apply.]] This information includes (but is not necessarily limited to) the information listed in this page.
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).
#* Does the CA focus its activities on a particular country or other geographic region?
# Impact to Mozilla Users
#* If your CA will only issue certificates within your organization or for a small number of websites, then rather than including your root certificate in NSS, please consider having your CA hierarchy cross-signed with one of the by an [httphttps://wwwwiki.mozilla.org/projects/security/certs/includedCA/ Included_CAs already-included CA certificates]. If your CA will be issuing certificates to the public or to a large number of websites, then please respond to the following questions.
#* Why does the CA need to have their root certificate directly included in Mozilla’s products, rather than being signed by another CA’s root certificate that is already included in NSS?
#* Does this CA have root certificates included in any other major browsers? If yes, which? If no, why not?
The POCs will:
* Provide [[CA:CommonCADatabase#Updating_Audit_Information|annual audit statements]]
* Respond to [https://wiki.mozilla.org/CA:/Communications CA Communications]* Make sure the CA’s rows information in the [http://www.mozillaccadb.org/projects/security/certs/included/ Included CAs SpreadsheetCommon CA Database (CCADB)] remain remains current* [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 [httphttps://www.mozilla.org/projectsabout/governance/policies/security-group/certs/policy/MaintenancePolicy.html Mozilla's CA Certificate Maintenance Root Store Policy].
* [mailto:certificates@mozilla.org Provide Mozilla] with updated contact information if a new person becomes a POC.
* Input and maintain the CA's [[CA:SalesforceCommunity#Add_Intermediate_Certificate_Data_to_Salesforce|intermediate certificate data]] in the [[CA:CommonCADatabase|Common CA Database]].
#* The value that nextUpdate is set to in the CRLs for end-entity certificates.
#* The sections of your CP/CPS documentation that state the requirements about frequency of updating CRL.
#* Note the [httphttps://www.cabforum.org/EV_Certificate_Guidelines_V11.pdf extended-validation/ CA/Browser Forum's EV guidelines:] CRLs MUST be updated and reissued at least every seven days, and the nextUpdate field value SHALL NOT be more ten days
# OCSP (OCSP is required for the SSL trust bit to be enabled)
#* The OCSP URI that is in the AIA of your subscriber certificates.
#* The maximum time elapsing from the revocation of an end entity or CA certificate until OCSP responders are updated to reflect that revocation.
#* The sections of your CP/CPS specifying availability and update requirements for the OCSP service.
#** [httphttps://www.cabforum.org/EV_Certificate_Guidelines_V11.pdf extended-validation/ CA/Browser Forum's EV Guidelines] Section 26(b): “If the CA provides revocation information via an Online Certificate Status Protocol (OCSP) service, it MUST update that service at least every four days. OCSP responses from this service MUST have a maximum expiration time of ten days.”
#* You must test that your OCSP service is compatible with the Firefox browser.
#** See: https://wiki.mozilla.org/CA:Recommended_Practices/Required_or_Recommended_Practices#OCSP
#** OCSP responders should be set up to listen on a standard port (e.g. port 80), because firewalls may block ports other than 80/443.
# Test!!!
#** Revocation: Browse to https://certificate.revocationcheck.com/ and enter the Test Website URL. Make sure there are no errors listed in the output.
#*** If certificate.revocationcheck.com does not know about the root cert, then use the 'Certificate Upload' tab to directly input the PEM for the certificates.
#** The CA MUST check that they are not issuing certificates that violate any of the [https://cabforum.org/baseline-requirements-documents/ CA/Browser Forum Baseline Requirements] (BRs).
#** Mozilla WILL check that the CA is not issuing certificates that violate any of the BRs by performing the following tests.
#*** Browse to https://crt.sh/
#** DV -- The ownership of the domain name is verified, but the identity/organization of the subscriber is not verified.
#** OV -- In addition to verifying the domain ownership, you also validate the organization to be listed in the O field - making sure public record and government resources can verify the address, existence, and good legal standing of the organization itself. Verifying that the whois listed address matches the verified address, and any other additional checks that a given CA lists in its CPS.
#** EV - Verification meets the requirements of the CA/Browser Forum [httphttps://www.cabforum.org/EV_Certificate_Guidelines_V11.pdf extended-validation/ CA/Browser Forum's EV Guidelines]
# If EV certificates are issued within the hierarchy rooted at this root, the EV policy OID(s) associated with those EV certificates.
#* If any such cross-signing relationships exist, it is important to note whether the cross-signing CAs' certificates are already included in the Mozilla root store or not.
# Technical Constraints or Audits of Third-Party Issuers.
#* As per Items #8, 9, and 10 of [https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/inclusion/ Mozilla's CA Certificate Inclusion Root Store Policy], provide a URL to a web page or a Bugzilla Bug Number that lists all of your publicly disclosed subordinate CA certificates that chain up to certificates in Mozilla's CA program, and contains the required information according to section 10 of [https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/inclusion/ Mozilla's CA Certificate Inclusion Root Store Policy]. #** Already-included CAs may provide this information directly in the CCADB.#** If you decide to use the mozilla.org Bugzilla system to provide this information, then file the bug against the "CA CertificatesCertificate Root Program" component of the "mozilla.orgNSS" product. (https://bugzilla.mozilla.org/enter_bug.cgi?product=mozilla.orgNSS&component=CA%20Certificates20Certificate%20Root Program)
== Verification Policies and Practices ==
# Documentation: CP, CPS, and Relying Party Agreements
#*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://www.cabforum.org/baseline-requirements-documents.html / CA/Browser Forum Baseline Requirements] may be found, as per BR #8.3 (section 2.2 in BR version 1.3).
#* [[CA:Recommended_Practices#CP.2FCPS_Documents_will_be_Reviewed.21|CP/CPS Documents will be reviewed]], and must contain sufficient information for Mozilla and the CA Community to evaluate the CA's processes in regards to Mozilla's policies and the CA/Browser Forum's Baseline Requirements.
#** English translations must be provided for the relevant CP/CPS documents, and must match the current version of the CP/CPS documents.
# Audits
#* The publicly accessible URLs to 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.
#** Section 6 of [https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/inclusion/ Mozilla's CA Certificate Inclusion Root Store Policy]: "We require that all CAs whose certificates are distributed with our software products: ... provide public attestation of their conformance to the stated verification requirements and other operational criteria by a competent independent party or parties with access to details of the CA’s internal operations."
#* We need a publishable (non-confidential) statement or letter from an auditor (who meets the requirements of the Mozilla CA Certificate Policy) that states that they have reviewed the practices as outlined in the CP/CPS for these roots and their CA hierarchies, and that the CA does indeed follow these practices and meets the requirements of one or more of:
#** WebTrust "Principles and Criteria for Certification Authorities 2.0" or later and "WebTrust Principles and Criteria for Certification Authorities – SSL Baseline with Network Security – Version 2.0" or later (as applicable to SSL certificate issuance) in WebTrust Program for Certification Authorities;
#** “Trust Service Providers practice” in ETSI EN 319 411-2 v2.1.1 or later version Policy and security requirements for Trust Service Providers issuing certificates; Part 2: Requirements for trust service providers issuing EU qualified certificates, specifying a policy or policies appropriate to the trust bit(s) being applied for.
#*** For QWACs the CA must comply with EN 319 411-2 with the policy requirements identified for QCP-w. Note: QCP-w defined in EN 319 411-2 builds on EVCP defined in EN 319 411-1.
#* Audits performed after January 2013 need to include verification of compliance with the [https://www.cabforum.org/baseline-requirements-documents.html / CA/Browser Forum Baseline Requirements] if SSL certificates may be issued within the CA hierarchy, and the audit statement shall indicate the results.#** Carefully review with your auditor: #*** https://wikiwww.mozilla.org/CA/about/governance/policies/security-group/certs/policy/#required-audits#*** https:BaselineRequirements//www.mozilla.org//about/governance/policies/security-group/certs/policy/#public-audit-information
#* When audit statements are provided by the company requesting CA inclusion rather than having an audit report posted on the website such as cert.webtrust.org, the Mozilla process requires doing an independent verification of the authenticity of audit statements that have been provided. Provide the website and email address for the company that provided the audit statement.
#** If the information is available from the auditor's (or other third-party's) web site or from another authoritative web site (for example, [http://www.webtrust.org/ webtrust.org] for WebTrust reports), please provide the URL where the information can be found.
#* Renewed root certificates also need to be included in audits. If the root certificate was created after the most recent audit, then provide an estimate of when the new audit report (that includes the operations of the new root) will be available.
#* Government CAs
#** According to section 9 of [http://www.mozilla.org/projects/security/certs/policy/InclusionPolicy.html Mozilla's CA Certificate Inclusion Root Store Policy], the audit must be performed according to criteria that is equivalent to one (or more) of ETSI TS 101 456, ETSI TS 102 042, or WebTrust CA. The government’s auditing agency should provide a statement about which of these their government criteria is equivalent to.#** According to sections 10 and 11 of [http://www.mozilla.org/projects/security/certs/policy/InclusionPolicy.html Mozilla's CA Certificate Inclusion Root Store Policy], it is acceptable for a government auditing organization to perform the audit of the government’s CA organization. It must be clear that the CA organization does not audit itself.
# SSL Verification Procedures
#* If you are requesting to enable the Websites (SSL/TLS) trust bit...
#*** There should be a description of the types of resources that are used to confirm the authenticity of the information provided by the certificate subscriber, what data is retrieved from public resources, and how that data is used for verification of the entity referenced in the certificate.
#** If EV verification is performed, then provide URLs and section/page number information pointing directly to the sections of the CP/CPS documents that pertain to EV and describe the procedures for verifying the ownership/control of the domain name, and the verification of identity, existence, and authority of the organization to request the EV certificate.
#*** The EV verification documentation must meet the requirements of the [httphttps://www.cabforum.org/EV_Certificate_Guidelines_V11.pdf extended-validation/ CA/Browser Forum's EV Guidelines], and must also provide information specific to the CA's operations.
# Email Address Verification Procedures
#* If you are requesting to enable the Email (S/MIME) trust bit...
#** If technical controls are used instead of multi-factor auth for any accounts, then specify what those technical controls are.
# Network Security
#* CAs must maintain current best practices for network security, and have qualified network security audits performed on a regular basis. The [https://www.cabforum.org/ CA/Browser Forum] has published a document called [https://www.cabforum.org/documents.html network-security/ Network and Certificate System Security Requirements] which should be used as guidance for protecting network and supporting systems.
#* Confirm that you have done the following, and will do the following on a regular basis:
#** Maintain network security controls that at minimum meet the [https://www.cabforum.org/documents.html network-security/ Network and Certificate System Security Requirements.]
#** Check for mis-issuance of certificates, especially for high-profile domains.
#** Review network infrastructure, monitoring, passwords, etc. for signs of intrusion or weakness.
