CA/Root Inclusion Overview

From MozillaWiki
< CA
Jump to navigation Jump to search

Root Inclusion: Process & Criteria

Page Purpose and Audience

This page summarizes Mozilla’s published guidance about how to apply for root inclusion and how requests are evaluated. It is written for:

  • CA operators preparing an inclusion request.
  • Mozilla reviewers performing information verification, detailed review, and public discussion triage.

For program policy, always defer to the Mozilla Root Store Policy (MRSP).

Quick Glossary

  • CCADB – The Common CA Database where you file the Root Inclusion Request and upload/provide links to documents.
  • CCADB Public – Public mailing list used to discuss the request.
  • Bugzilla (CA Program) – Public tracking and discussion of the request.
  • MRSP - Mozilla Root Store Policy
  • m-d-s-p - Mozilla Dev Security Policy Mailing List
  • Mozilla CA Wiki – Process documentation, checklists, and reviewer guidance (this page).
  • NSS – Network Security Services trust store; root lands in Firefox via NSS after approval.

Part A – Root Inclusion Process (Step-by-Step)

1) Prepare Your Application

Before opening a case, read:

Deliverables you’ll need on hand:

  • Root certificate(s) and hierarchy description (subordinates, cross-signs, EKUs, OIDs).
  • Public CPS or CP/CPS and related policy documentation.
  • Key ceremony attestation – auditor-witnessed root key generation.
  • All Current and Prior Audits (WebTrust/ETSI) – management assertion, auditor opinion, and a statement of the audit team’s qualifications.
  • Completed Compliance Self-Assessment - within the last 365 days
  • Value statement – why inclusion benefits Mozilla users.

2) Open the Request (CCADB + Bugzilla)

  • Step 1 – Request CCADB access (new CA Owner): Request Access
  • Step 2 – Add/Update Root: upload the root (PEM format) using an “Add/Update Root Request” case and complete all required fields (Add/Update Root Request).
  • Step 3 – File the Root Inclusion Request: after the root(s) has/have been uploaded, open a “Root Inclusion Request” case (Root Inclusion Request).
  • Step 4 – Create Bugzilla entry: open a bug under Product: CA Program → Component: CA Certificate Root Program, where "Summary" contains "Add [CA Name] Root". Upload the root certificates as bug attachments, either in PEM or DER formats, and upload/attach to the bug any other required documentation that has not yet been made publicly available.

3) Information Verification (High-level Completeness)

Mozilla performs a high-level completeness review to ensure required data are present in the CCADB and Bugzilla, documents are public, links are stable, and basic tests have been run.

Bugzilla Whiteboard Tags (inclusion process)

(Stages may overlap or occur in different order depending on readiness.)

Reference: Root Inclusion Whiteboard Labels

  • [ca-initial] – Insufficient information to begin Information Verification, or not yet assigned.
  • [ca-verifying] – In Information Verification phase (checking completeness across CCADB and Bugzilla).
  • [ca-ready-for-discussion yyyy-mm-dd] – Verification complete; ready for public discussion.
  • [ca-in-discussion] – Under discussion on the CCADB Public mailing list.
  • [ca-cps-review] – Detailed CP/CPS and audit review. May occur before, after, or in parallel with discussion.
  • [ca-discussion-hold] – Discussion paused pending CA action.
  • [ca-hold] – Request on hold (for example, “super-CA” dependency).
  • [ca-pending-approval] – Final notice of intent to approve.
  • [ca-approved] – Approved, pending code changes in NSS (and possibly PSM).
  • [ca-denied] – Denied; CA may reapply with a fully compliant root.

Some of these whiteboard labels are used to generate the lists found in the Change Request Dashboard.

4) Verification by Root Store (Detailed Review)

Mozilla conducts detailed policy and technical review (CP/CPS, audits, key ceremony evidence, OCSP/CRL behavior, value jusitification, Self-Assessment mapping).

5) Public Discussion

  • Public discussion runs for six weeks on the CCADB Public List.
  • Reviewers and community members provide feedback.

6) Last Call, Decision, and NSS Landing

  • After discussion, Mozilla opens a seven-day “last call” on the m-d-s-p list for final input.
  • On approval, Mozilla files an NSS bug (Product: NSS → Component: CA Certificates Code), attaches the DER root and trust bits, and merges the patch (certdata.txt) in the next cycle.
  • Firefox then ships the update on the regular release trains. See https://whattrainisitnow.com/.

End-to-End Timing (approximate)

Ideal Processing Time: The following presents ideal timeframes, assuming that all required policy and practice documentation, audits, and attestations are current, complete, and correct; that all information is accurately entered in the CCADB; that the CA passes all applicable tests; and that it responds promptly to all requests. In this ideal case, for a CA operator with a P1 priority, the root inclusion process can proceed smoothly from submission to Firefox release within approximately four to six months. Actual processing times vary depending on available resources, prioritization, workload, and the complexity of the application.

  • CA preparation: 2–8 weeks
  • Initial completeness check: 1–3 weeks
  • Verification: 6–12 weeks
  • Public discussion: 6 weeks
  • Decision and NSS/Firefox rollout: 6–12 weeks

Total (ideal) duration: 4–8 months (depending on queue, completeness, and responsiveness).

Part B – Evaluation Criteria (What Reviewers Look For)

1) Program Policy and Scope

  • All evaluations are grounded in the MRSP (CA operations, validation, disclosure, and §8.4 for externally-operated sub-CAs).
  • Submissions must align with the MRSP and CA/Browser Forum requirements.
  • Externally-operated sub-CAs must follow MRSP §8.4 and the External Sub-CAs process before issuance.

2) Value to Mozilla Users

3) Completeness and Transparency

  • Public availability of CP/CPS, audits (including management assertion, auditor opinion, and team qualifications), key-ceremony attestations, incident reports, and stable URLs.
  • Completed CCADB Self-Assessment aligned with MRSP and BRs.

4) CP/CPS Quality and Alignment

  • Reviewers check CP/CPS consistency with Self-Assessment and policy requirements: validation practices, revocation timelines, CRL/OCSP updates, identity vetting (if applicable), and internal consistency.
  • Also see previous CPS reviews and the CCADB Self-Assessment template.

5) Audits (Independence, Scope, Timing)

  • Annual WebTrust or ETSI audits with full scope covering entire CA key lifecycle
  • Required elements: management assertion, auditor opinion, and audit team qualifications.
  • Root key generation must be witnessed and attested by an auditor.
  • Reviewers will look for audit coverage across the full CA key lifecycle (contiguous audits with no gaps).

6) Technical Operation Checks

  • OCSP and CRL availability and behavior match CP/CPS commitments.
  • Hierarchy correctness (purposes/EKUs, profiles).
  • Test sites demonstrating chaining to root, revocation behaviors, and automated domain validation and issuance.

7) Prioritization

Mozilla will prioritize requests that:

  • Replace an existing included root
  • Are complete and well-documented
  • Demonstrate strong responsiveness and alignment with program goals
  • Also see Prioritization

Useful Links

Retrieved from "https://wiki.mozilla.org/index.php?title=CA/Root_Inclusion_Overview&oldid=1255708"