Revise Item 1 in MRSP 3.3 - Documentation Detail

[BenWilson-Mozilla]

Problem Statement

Experience over the past several years shows that §3.3 of the Mozilla Root Store Policy is frequently interpreted by CA operators as permitting minimal and generic CP/CPS disclosures, so long as the document nominally references applicable standards. In practice, this has led to CPs and CPSes that technically exist, but do not function as meaningful, auditable records of a CA’s operational behavior.

Common patterns include:

• Boilerplate policy language that mirrors industry standards without describing how the CA actually implements those requirements.
• Compliance-by-reference, where CA/Browser Forum Requirements or other external policies are cited wholesale, with little or no CA-specific explanation.
• Subjective or non-measurable language (e.g., “may,” “as appropriate,” “a few,” “periodically”) in areas where operational discretion exists and objective limits could be stated.
• Omission of certificate, CRL, and OCSP profiles, leaving relying parties, auditors, and researchers unable to determine the precise technical characteristics of certificates and revocation artifacts issued by the CA.

These approaches now fall short of the current need for sufficient information for Mozilla and others to understand whether and how a CA complies with applicable policies, and this lack of specificity creates several ecosystem risks:

• It reduces auditability, as auditors cannot reliably test conformance against vague or purely referential commitments.
• It undermines accountability, since ambiguous language allows operational deviations to be rationalized as compliant.
• It impedes automation and independent monitoring, which increasingly rely on machine-verifiable expectations rather than interpretive judgment.
• It creates a perverse incentive to minimize disclosure in order to reduce exposure, rather than to document actual practices transparently.

As the Web PKI ecosystem moves toward shorter certificate lifetimes, increased automation, and greater reliance on third-party analysis tools, CP/CPS documents must evolve from high-level policy summaries into precise, operationally meaningful records.

Proposed Direction
To address these issues, §3.3 of the Mozilla Root Store Policy should be clarified and strengthened to explicitly require that CP/CPS documentation:

• Affirmatively describe how the CA implements applicable requirements, rather than relying solely on incorporation by reference to external standards.
• Use objective, measurable, and auditable language wherever operational discretion exists, avoiding subjective or open-ended descriptors.
• Accurately reflect current, real-world practices, systems, and constraints, rather than aspirational or theoretical processes.
• Provide certificate profiles, either directly in the CP/CPS or via clearly referenced, CA-maintained profile documents, describing at a minimum:
• Extensions
  -- Extended Key Usages (EKUs)
  -- Name constraints
  -- Revocation mechanisms and signaling
  -- Provide CRL and OCSP profiles, including:
  -- Update cadence
  -- Validity periods
  -- Timing characteristics
• Any intentional deviations from nominal behavior (e.g., backdating practices)

We should also add language in Item 1 of Section 3.3 to more clearly identify all relevant requirements that need to be in scope (e.g., specific CA/Browser Forum Requirements, CCADB policies, etc.), rather than referring generically to “this policy” alone.

Clarifying these expectations will help align CP/CPS documentation with Mozilla’s transparency goals, support more effective audits and independent review, and reduce ambiguity about what constitutes acceptable disclosure for publicly trusted CAs.