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, 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.

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 Mozilla's Application Process.

• Example -- an Example Root Inclusion Case in CCADB. If your CA currently has access to the CCADB, then you may create a Root Inclusion Case directly.
• Template (Google Doc) -- If your CA does not currently have access to the CCADB, then this is the form to fill in. Download it from Google Docs, fill it in, and attach to your Bugzilla Bug. Note that the certificate data will be extracted directly from the PEM of the certificate, so the CA should attach the PEM of the root certificate to the Bugzilla bug, or provide a link to the certificate on their website.

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 or a Case in the CCADB.

Create a Root Inclusion Case

If your CA currently has access to the CCADB, then enter your information directly as described below.

1. Login to the CCADB.
2. Create a Root Inclusion Case in the CCADB - one Case per set of audit statements.
   • Navigate to the CA Owner Record for your CA.
     • Click on “CA Owners/Certificates” tab, then in “View:” select “Community User’s CA Owners/Root Certs” and click on “Go!”.
     • Click on the “CA Owner/Certificate Name” of your CA’s Owner record.
   • Scroll down to the ‘Cases’ section.
   • Click on the ‘New Case’ button, and select “CA Root Inclusion Request”.
3. Click on the ‘Submit’ button to create the new Root Inclusion Case.
   • For our use, the ‘Submit’ button is the ‘Save’ button. (Salesforce doesn’t currently let us change the name of this particular button.)
   • You may click on ‘Edit’ and ‘Submit’ as many times as you need to get all of your information entered.
4. Click on the “Copy Audit Info” button, to copy data from a root cert already in the CCADB (if applicable).
5. Click on the ‘Add/Update Root Cases’ button to add the PEM for the new root cert or to indicate which existing root certs are part of this root inclusion or update request.
   • For each root certificate to be considered in your request, check the boxes corresponding to the audit statements that apply. Then click on the “Apply Changes” button. This will create corresponding Root Cases.
6. Click on the ‘Edit Test Websites’ button to enter the test websites for new root certs if you are requesting the Websites (TLS/SSL) trust bit.
7. Click on the ‘Audit Letter Validation (ALV)’ button, and work with your auditor to resolve all problems.
8. Fill in the remaining information in your Case and Root Cases.
   • Scroll down to the “Mozilla Additional Requirements” section and click on the “Print NEED Fields” to see where further information is needed.
9. Click on the ‘Get URLs’ button and copy the line that begins with “Mozilla Root Inclusion Case Information:” into a Comment in your Bugzilla Bug. The line to copy and paste into the Bugzilla Bug looks like:
   • Mozilla Root Inclusion Case Information: https://ccadb-public.secure.force.com/mozilla/PrintViewForCase?CaseNumber=00000341
   • This will trigger step 2 of Mozilla’s root inclusion process.

IMPORTANT:

• Whenever you update data in your Root Inclusion Case in the CCADB, be sure to add a comment to your Bugzilla Bug to let folks know to re-check the information.
• Fields for which a root store operator has set "Data Verified" can not be edited until you ask the root store operator to change the corresponding status back to "Not Verified".

CA Primary Point of Contact (POC)

In addition to the information listed in the template and example above, CA's must provide the contact information for at least 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.

The POCs will:

• Provide annual updates of CP/CPS documents, audit statements, and test websites.
• Respond to CA Communications
• Input and maintain the CA’s data in the Common CA Database (CCADB)
• 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
  • Common CCADB Policy
  • Mozilla's Root Store Policy
• Provide Mozilla with updated contact information if a new person becomes a POC.

Required contact information:

• 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).
• 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.
• CA Phone Number: A main phone number from which Mozilla can reach the organization responsible for root certificates for the CA.
• Title / Department: If Mozilla needed to call your main phone number, what Title/Department should the Mozilla representative ask for?

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.

1. 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).
2. 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.
3. 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.