|
|
| (59 intermediate revisions by 3 users not shown) |
| Line 1: |
Line 1: |
| = Information checklist for CAs applying for inclusion in Mozilla = | | = 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, 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. | | In order to support cryptographic applications, such as those that make TLS connections to web and other servers, and those that sign and encrypt/decrypt 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 such CAs 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 [http://www.mozilla.org/projects/security/certs/policy/ Mozilla CA certificate 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).
| |
|
| |
|
| == Example and Template == | | == Example and Template == |
| | The example and template below list the information that must be provided by the CA in their root inclusion or update request as per step 1 of [[CA/Application_Process#Process_Overview|Mozilla's Application Process]]. |
|
| |
|
| Here is an example of the output produced during the [[CA:How_to_apply#Information_Verification|Information Verification phase]], showing the information that the CA must provide.
| | * [https://ccadb.my.salesforce-sites.com/mozilla/PrintViewForCase?CaseNumber=00000341 Example] -- This is what it will look like when you '''[[CA/Information_Checklist#Adding_Root_Certificates_and_Creating_Root_Inclusion_Cases|create a Root Inclusion Case directly]]''' in the CCADB. |
| * [[File:CAInformationExample.pdf|CAInformation.pdf]]
| |
|
| |
|
| Here is a template that you may use to provide this information
| | Mozilla's process is public-facing, so all information that will be taken under consideration during the root inclusion request must be publicly available and provided by the CA via a Case in the CCADB and in a Bugzilla bug report. (Both must be created as they will reference each other.) |
| * [[File:CAInformationTemplate.pdf|CAInformationTemplate.pdf]]
| |
|
| |
|
| Mozilla's process is public-facing, so all information that will be taken under consideration during the root inclusion request must be publicly available and provided by the CA via the Bugzilla bug report.
| | == Adding Root Certificates and Creating Root Inclusion Cases == |
| | === Access the CCADB === |
| | If your CA does not yet have access to the CCADB, then you may request access here: |
| | * https://ccadb.org/cas/request-access |
|
| |
|
| == General information about the associated organization of the CA ==
| | Information and instructions for CAs about the CCADB are here: |
| | * https://www.ccadb.org/cas/ |
|
| |
|
| # Name
| | === Create an "Add/Update Root Request" case === |
| #* This is the name by which the CA is most commonly known, e.g., "Symantec / GeoTrust"
| | CAs provide information about their CA organization and root certificates by creating an "Add/Update Root Request". |
| # Website URL
| | # Create an [https://www.ccadb.org/cas/updates "Add/Update Root Request"] case in the CCADB |
| # Organizational type
| | #* Detailed Instructions: [https://docs.google.com/document/d/1AUbwbyqCq3jR7wP0fSWjL1us9s4sZIbXGRyo_ko77QM/edit Create an Add/Update Root Request] |
| #* Indicate 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.)
| | # Add new root certificates to the case. |
| # Primary market / customer base
| | #* In the ROOT INFORMATION tab, click on the "Add/Select Root Certificates" button. Then click on the "Add Root Certificate to CCADB" button and paste the certificate PEM into the window and click on "Validate PEM". If validation is successful, click on the "Create Root Certificate in CCADB" button. |
| #* Which types of customers does the CA serve?
| | # Completely fill in the information in the five tabs of the "Add/Update Root Request" case: CA OWNER, AUDITS, POLICY DOCUMENTS, ROOT INFORMATION, and TEST WEBSITES. |
| #* Are there particular vertical market segments in which it operates?
| | # Click on the "Submit to Root Store" button. |
| #* 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 [http://www.mozilla.org/projects/security/certs/included/ 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? | |
| #* Describe the types of Mozilla users who are likely to encounter your root certificate as relying parties while web browsing (HTTPS servers doing SSL), sending/receiving email to their own MTA (SMTPS, IMAPS servers doing SSL), sending/receiving S/MIME email (S/MIME email certs), etc.
| |
| #* Mozilla CA certificate policy: | |
| #** We will determine which CA certificates are included in software products distributed through mozilla.org, based on the benefits and risks of such inclusion to typical users of those products.
| |
| #** We require that all CAs whose certificates are distributed with our software product ... provide some service relevant to typical users of our software products
| |
|
| |
|
| === CA Primary Point of Contact (POC) ===
| | '''Important''': |
| A CA may have more than one person filling the role of Primary Point of Contact (POC), and may use a contractor as one of the POCs. The CA must have one or more people within the CA’s organization who jointly have authority to speak on behalf of the CA, and to direct whatever changes the review process or Mozilla’s CA Communications require. At least one of the CA’s POCs should also be in a position to make commitments for the CA and be held accountable by the CA.
| | * Audit statements must meet the requirements listed in [https://www.ccadb.org/policy#51-audit-statement-content section 5.1 of the CCADB Policy] '''and''' [https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/#3-documentation in section 3 of the Mozilla Root Store Policy]. |
| | ** Also see Mozilla's [[CA/Audit_Statements#Audit_Lifecycle|audit lifecycle requirements]] |
| | * CCADB automatically converts WebTrust Seal URLs into PDF URLs when you click on ‘Save’ |
| | * In each audit statement section in the AUDITS tab, be sure to select "Applicable Root Certificates". |
| | ** Click on the inverted triangle ("Edit") to select all of the root certificates covered by the audit. |
| | * If you are requesting that the Websites (TLS) trust bit be enabled for your root certificate(s), then be sure to provide the 3 test websites (valid, expired, revoked) in the TEST WEBSITES tab. |
| | ** Click on the "Validate Test Websites" button, resolve all failures, then click on the "Re-run Validation" button to make sure all the websites have Status of PASS. |
| | * Add records to the CCADB for all existing intermediate certificates chaining up to the new root certificate(s). |
| | ** https://www.ccadb.org/cas/intermediates |
|
| |
|
| The POCs will:
| | === Create a "Root Inclusion Request" Case === |
| * Provide [[CA:CommonCADatabase#Updating_Audit_Information|annual audit statements]]
| | After you have provided information to the CCADB about your CA organization and root certificates, you may use a "Root Inclusion Request" case to request that your root certificate(s) be included in Mozilla's root store, update trust bit settings, and/or enable EV treatment. |
| * Respond to [https://wiki.mozilla.org/CA:Communications CA Communications]
| | # Create a [https://www.ccadb.org/cas/inclusion "Root Inclusion Request" Case] in the CCADB |
| * Make sure the CA’s rows in the [http://www.mozilla.org/projects/security/certs/included/ Included CAs Spreadsheet] remain current
| | #* Detailed Instructions: [https://docs.google.com/document/d/1FHSbpNJ3CQOcpVqrj66elKQhTmpllp-IBsDovPy6cOo/edit# Create a Root Inclusion Request] |
| * [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 [http://www.mozilla.org/projects/security/certs/policy/MaintenancePolicy.html Mozilla's CA Certificate Maintenance Policy]. | | # Fill in all of the fields in the MOZILLA tab |
| * [mailto:certificates@mozilla.org Provide Mozilla] with updated contact information if a new person becomes a POC.
| | # Click on the "Submit to Root Store" button. |
| * Input and maintain the CA's [[CA:SalesforceCommunity#Add_Intermediate_Certificate_Data_to_Salesforce|intermediate certificate data]] in the [[CA:CommonCADatabase|Common CA Database]].
| |
|
| |
|
| Required contact information:
| | '''Important''': |
| * Direct E-mail address, full name (first and last name), and phone number to a specific individual within the CA (must be one of the POCs). | | * In the MOZILLA tab, click on the "Print View" button to see the data that will be shared publicly about your request. |
| * CA Email Alias: An email alias is being requested so that more than one person in your organization will receive notifications in case the primary contact is out of the office or leaves the organization. Mozilla CA Communications will be sent to both the POC direct email address(es) and the email alias.
| | * Click on the "Get URLs" button (which may be in the button overflow – upside down triangle) and copy the line that begins with “Mozilla Root Inclusion Case Information:” into a Comment in [[CA/Application_Instructions#Create_Root_Inclusion.2FUpdate_Request|your Bugzilla Bug]]. The line to copy and paste into the Bugzilla Bug looks like: |
| * CA Phone Number: A main phone number from which Mozilla can reach the organization responsible for root certificates for the CA. | | **Mozilla Root Inclusion Case Information: https://ccadb.my.salesforce-sites.com/mozilla/PrintViewForCase?CaseNumber=00000341 |
| * Title / Department: If Mozilla needed to call your main phone number, what Title/Department should the Mozilla representative ask for?
| | * Whenever you update data in your Root Inclusion Case in the CCADB, be sure to [[CA/Application_Instructions#Create_Root_Inclusion.2FUpdate_Request|add a comment to your Bugzilla Bug]] to let folks know to re-check the information.''' |
|
| |
| If the CA uses a contractor as an additional POC, then someone at the CA must be CC’d on the root inclusion Bugzilla bug, CA Communications, and the CA’s responses to CA Communications.
| |
| * An individual within the CA must also get a Bugzilla account and comment in the bug to say that they will be a POC for the CA, and that the contractor has indeed been hired by the CA to act as one of the POCs.
| |
|
| |
|
| To ensure that the POC(s) has the authority to perform the tasks listed above, a representative of Mozilla will do the following.
| | == CA Primary Point of Contact (POC) == |
| # Use the CA’s website, to confirm that the domain in the email address of at least one of the POCs is owned by the CA (e.g. @CAname.com).
| | Each CA organization in the CCADB must provide the contact information for at least one person filling the role of Primary Point of Contact (POC), as described in [https://www.ccadb.org/policy#2-contact-information section 2 of the CCADB Policy]. |
| # Use the CA’s website to contact a person at the CA to confirm that at least one of the POCs that have been provided does indeed have the authority to perform the responsibilities listed above on behalf of the CA.
| |
| # If a contractor is also used as a POC, then contact the POC that was previously verified to confirm that the CA has indeed enlisted the help of the contractor. | |
|
| |
|
| == Technical information about each root certificate == | | === Provide or update POC information === |
| The information listed in this section must be provided for each root CA whose certificate is to be included in Mozilla, or whose metadata is to be modified.
| | * Create an [https://www.ccadb.org/cas/contacts "Add/Update Contacts"] case. |
| | ** Detailed Instructions: [https://docs.google.com/document/d/1QQ-wZYPJ_3p76Zc3RZPE929pKIResc5J4vjSGGi_NuE/edit?usp=sharing Add/Update Contacts] |
| | * Provide the updates in the CONTACTS tab. |
| | * Click on the "Submit to Root Store" button. |
|
| |
|
| # Certificate Name
| | === Responsibilities of a Primary POC === |
| #* This is the "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 CN found within the Subject attribute of the root CA certificate itself.
| | * Provide [http://ccadb.org/cas/updates annual updates] of CP/CPS documents, audit statements, and test websites. |
| # Certificate Issuer Field
| | * Respond to [https://wiki.mozilla.org/CA/Communications CA Communications] |
| #* The Organization Name and CN in the Issuer must have sufficient information about the CA Organization.
| | * Input and maintain the CA’s data in the [https://www.ccadb.org/cas/ CCADB]. |
| # Certificate Summary
| | * [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 |
| #* A summary about this root certificate, it's purpose, and the types of certificates that are issued under it.
| | ** [http://ccadb.org/policy#2-contact-information Section 2 of the CCADB Policy], and |
| # Root Certificate URL
| | ** [https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/#8-ca-operational-changes Section 8 of the Mozilla Root Store Policy]. |
| #* A public URL through which the CA certificate can be directly downloaded.
| | * Make sure the "CA Email Alias" field on the CA Owner page is correct. |
| # SHA1 fingerprint
| | ** An email alias is being requested so that more than one person in your organization will receive notifications in case the primary contact is out of the office or leaves the organization. |
| # Valid from (YYYY-MM-DD)
| | ** The CA Email Alias is updated via an "Add/Update Root Request" case. |
| #* 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.
| |
| # Certificate Version (should be 3)
| |
| #* The X.509 certificate version
| |
| # Certificate Signature Algorithm
| |
| # Signing key parameters
| |
| #* For RSA keys, the modulus length, for example, 2048 or 4096 bits.
| |
| #* For ECC keys, the named curve, for example, NIST Curve P-256, P-384, or P-512.
| |
| # Test website URL -- if you are requesting to enable the Websites (SSL/TLS) trust bit
| |
| #* URL to a website whose SSL cert chains up to this root. Note that this can be a test site.
| |
| #* Make sure you test it yourself in Firefox first, by doing the following:
| |
| #*# Restore the default certificate settings as described [[CA:UserCertDB#How_To_Restore_Default_Root_Certificate_Settings | here]].
| |
| #*# Import the root certificate as described [[CA:UserCertDB#Importing_a_Root_Certificate | here]].
| |
| #*# Set OCSP hard fail as described [[CA:Recommended_Practices#OCSP | here]].
| |
| #*# Clear browser history
| |
| #*# Browse to the test website.
| |
| #*# Open the [https://developer.mozilla.org/en-US/docs/Tools/Web_Console Web Console] to check for any warnings (e.g. SHA-1, etc.) that should be addressed.
| |
| #** Intermediate CA certificates are expected to be distributed to the certificate subjects (the holders of the private keys) together with the subjects' own certificates. Those subject parties (e.g. SSL servers) are then expected to send out the intermediate CA certificates together with their own certificates whenever they are asked to send out their certificates. That is required by SSL/TLS.
| |
| #** Certificate authorities MUST advise their subscribers that all intermediate certificates should be installed in the servers containing the dependent subscriber certificates.
| |
| # Example certificates
| |
| #* If this root does not issue certificates for SSL, then provide example certificate(s) issued within the hierarchy rooted at this root, including the full certificate chain(s).
| |
| # Certificate Revocation Lists (CRLs)
| |
| #* URL(s) at which the CRL(s) may be obtained -- for end-entity certs and for intermediate CAs.
| |
| #* 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 [http://www.cabforum.org/EV_Certificate_Guidelines_V11.pdf 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.
| |
| #** [http://www.cabforum.org/EV_Certificate_Guidelines_V11.pdf 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#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!!!
| |
| #* If requesting to enable the Websites (SSL/TLS) trust bit, then you must perform all of the following tests
| |
| #** Revocation: Browse to http://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/ 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/ | |
| #*** Enter the SHA-1 or SHA-256 Fingerprint for the root certificate. Then click on the 'Search' button.
| |
| #*** When the certificate information is shown, along the left column under Certificate, click on the "Run cablint" and "Run x509lint" links. Each of these will add a row to the table, showing the test results.
| |
| #*** All errors must be resolved/fixed. Warnings should also be either resolved or explained.
| |
| #** Alternatively, you may use the test code directly via Github:
| |
| #*** BR Lint Test: https://github.com/awslabs/certlint
| |
| #*** X.509 Lint Test: https://github.com/kroeckx/x509lint
| |
| #*** All errors must be resolved/fixed. Warnings should also be either resolved or explained.
| |
| #** [[CA:TestErrors|Test Errors]] - Meaning and recommended solutions to errors that CAs have run into while doing the tests listed above. | |
| #* If you are requesting to enable EV treatment, then you must also perform the [[PSM:EV_Testing_Easy_Version | PSM EV Testing]]
| |
| #** You must provide successful output from the [https://tls-observatory.services.mozilla.com/static/ev-checker.html EV Checking Tool].
| |
| # Requested Trust Bits
| |
| #* State which of the two trust bits you are requesting to be enabled for this root. One or more of:
| |
| #** Websites (SSL/TLS)
| |
| #** Email (S/MIME)
| |
| #* Mozilla’s standpoint is that we should operate the root program in terms of minimizing risk. One way that we can minimize risk is by not enabling more trust bits than CAs absolutely require.
| |
| # SSL Validation Type
| |
| #* Indicate the levels of SSL validation that are used for certificates within this root's hierarchy. One or more of:
| |
| #** 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 [http://www.cabforum.org/EV_Certificate_Guidelines_V11.pdf 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.
| |
|
| |
|
| == CA Hierarchy information for each root certificate == | | === Authority === |
| The information listed in this section must be provided for each root certificate to be included in Mozilla, or whose metadata is to be modified.
| | If the CA uses a contractor as a POC, then someone at the CA must also be a POC for the CA Owner record in the CCADB, and the POC from the CA must be CC’d on the root inclusion Bugzilla bug. |
| | | * An individual within the CA must also get a Bugzilla account and comment in the bug to say that they will be a POC for the CA, and that the contractor has indeed been hired by the CA to act as one of the POCs. |
| If Mozilla accepts and includes your root certificate, then we have to assume that we also accept any of your future sub-CAs and their sub-CAs. Therefore, the selection criteria for your sub-CAs and their sub-CAs will be a critical decision factor. As well as the documentation and auditing of operations requirements that you place on your sub-CAs and their sub-CAs. | |
| | |
| # CA Hierarchy
| |
| #*A description of the PKI hierarchy rooted at or otherwise associated with this root CA certificate.
| |
| #** List and/or describe all of the subordinate CAs that are signed by this root.
| |
| #** Identify which of the subordinate CAs are internally-operated; e.g. list the subordinate CAs that 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 to the general public: 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.
| |
| #*** 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 this root has any subordinate CA certificates that are operated by external third parties, then provide the information listed in the [[CA:SubordinateCA_checklist | Subordinate CA Checklist]]
| |
| #* 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
| |
| #* List all other root certificates for which this root certificate has issued cross-signing certificates.
| |
| #* List all other root certificates that have issued cross-signing certificates for this root certificate.
| |
| #* 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 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 Policy]. If you decide to use the mozilla.org Bugzilla system to provide this information, then file the bug against the "CA Certificates" component of the "mozilla.org" product. (https://bugzilla.mozilla.org/enter_bug.cgi?product=mozilla.org&component=CA%20Certificates)
| |
| | |
| == Verification Policies and Practices ==
| |
| We rely on publicly available documentation and audits of those documented processes to ascertain that the CA takes reasonable measures to confirm the identity and authority of the individual and/or organization of the certificate subscriber.
| |
| | |
| If the CP/CPS documents are not in English, then the CP/CPS documents that are relevant to the root inclusion request '''must be translated into English'''. For all of the items listed below, provide both a pointer to the original document (and section or page number of the relevant text) as well as the translated text.
| |
| | |
| # 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/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 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;
| |
| #** WebTrust "Principles and Criteria for Certification Authorities - Extended Validation SSL 1.4.5” or later in WebTrust Program for Certification Authorities;
| |
| #** "Requirements on CA practice", in ETSI TS 101 456 V1.4.3 or later version, Policy requirements for certification authorities issuing qualified certificates (only applicable to electronic signature certificate issuance; applicable to either the "QCP public" or "QCP public + SSCD" certificate policies);
| |
| #** "Requirements on CA practice", in ETSI TS 102 042 V2.3.1 or later version, Policy requirements for certification authorities issuing public key certificates (as applicable to the "EVCP" and "EVCP+" certificate policies, DVCP and OVCP certificate policies for publicly trusted certificates - baseline requirements, and any of the "NCP", "NCP+", or "LCP" certificate policies);
| |
| #** “Trust Service Providers practice” in ETSI EN 319 411-1 v1.1.1 or later version Policy and security requirements for Trust Service Providers issuing certificates; Part 1: General requirements, specifying a policy or policies appropriate to the trust bit(s) being applied for;
| |
| #*** For Websites trust bit (need BR compliance audit) the CA must comply to EN 319 411-1 for "TLS" on level DV or OV or IV, and for "eMail" on level "LCP or NCP".
| |
| #*** For EV treatment the CA must comply with EN 319 411-1 with the policy requirements identified for EVCP.
| |
| #** “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/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://wiki.mozilla.org/CA:BaselineRequirements
| |
| #* 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.
| |
| #** If you provide the information yourself (e.g., it is hosted on your own web site), please provide us with contact information for the auditor (or other third party).
| |
| #** Otherwise please ask the auditor (or other third party) to contact us directly and provide us the audit report(s) or other information.
| |
| #* The audit should not be more than a year old. If it is, then provide an estimate of when the updated audit report will be available. While ETSI Certificates may be valid for 3 years, it is our expectation that there is an annual renewal/review process for the ETSI Certificate to remain valid.
| |
| #* 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 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 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...
| |
| #** 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.
| |
| #*** [[CA:Recommended_Practices#Verifying_Domain_Name_Ownership | Recommended Practices for Verifying Domain Name Ownership]]
| |
| #** 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.
| |
| #** Confirm that you have automatic blocks in place for high-profile domain names (including those targeted in the DigiNotar and Comodo attacks in 2011).
| |
| #*** Specify the procedure for additional verification of a certificate request that is blocked.
| |
| #** If OV verification is performed, then provide URLs and section/page number information pointing directly to the sections of the CP/CPS documents that describe the procedures for verifying the identity, existence, and authority of the organization to request the certificate.
| |
| #*** 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 [http://www.cabforum.org/EV_Certificate_Guidelines_V11.pdf 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...
| |
| #** URLs and section/page number information pointing directly to the sections of the CP/CPS documents that describe the procedures for verifying that the email address to be included in the certificate is owned/controlled by the certificate subscriber.
| |
| #** [[CA:Recommended_Practices#Verifying_Email_Address_Control | Recommended Practices for Verifying Email Address]]
| |
| #*** Note that per the Mozilla policy this verification must be done ''in addition to'' any verification of the subscriber’s legal identity.
| |
| #** If subscriber identity verification is performed, then provide URLs and section/page number information pointing directly to the sections of the CP/CPS documents that describe the procedures for verifying the identity and authority of the certificate subscriber.
| |
| # Code Signing Subscriber Verification Procedures
| |
| #* No longer applicable: Mozilla is no longer accepting requests to enable the Code Signing trust bit, because we plan to remove the Code Signing trust bit in the next version of Mozilla's CA Certificate Policy.
| |
| # Multi-factor Authentication
| |
| #* Confirm that multi-factor authentication is required for all accounts capable of directly causing certificate issuance or specify the technical controls that are implemented by the CA to restrict certificate issuance through the account to a limited set of pre-approved domains or email addresses.
| |
| #** For each account that can access the certificate issuance system, do you have the log-in procedure require something in addition to username/password?
| |
| #** Specify the form factor that you use. Examples of multi-factor authentication include smartcards, client certificates, one-time-passwords, and hardware tokens.
| |
| #** This must apply to all accounts that can cause the approval and/or issuance of end-entity certificates, including your RAs and sub-CAs, unless there are technical controls that are implemented and controlled by the CA to restrict certificate issuance through the account to a limited set of pre-approved domains or email addresses.
| |
| #** 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 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 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.
| |
| #** Ensure Intrusion Detection System and other monitoring software is up-to-date.
| |
| #** Confirm that you will be able to shut down certificate issuance quickly if you are alerted of intrusion.
| |
| | |
| == Response to Mozilla's CA Recommended Practices ==
| |
| Review Mozilla's [[CA:Recommended_Practices | CA Recommended Practices.]] If your practices differ from any of these recommended practices, then describe those differences and explain how the concern(s) are addressed.
| |
|
| |
|
| == Response to Mozilla's list of Potentially Problematic Practices ==
| | To ensure that the POC(s) has the authority to perform the tasks listed above, a representative of Mozilla may do the following. |
| Review Mozilla's list of [[CA:Problematic_Practices | Potentially Problematic Practices.]] For each one, state if it is or is not applicable. For the ones that are applicable, provide URLs and section/page number information pointing directly to the sections of the CP/CPS documents that are relevant, and explain how you address the concern(s).
| | # Use the CA’s website to contact a person at the CA to confirm that the Primary POCs that have been provided do indeed have the authority to perform the responsibilities listed above on behalf of the CA. |
| | # Use the CA’s website, to confirm that the domain in the email address of at least one of the Primary POCs is owned by the CA (e.g. @CAname.com). |
| | # If a contractor is also used as a Primary POC, then contact the Primary POC that was previously verified to confirm that the CA has indeed enlisted the help of the contractor. |