CA/CP-CPS Guidance

CP/CPS Documentation Guidance

Note:

This page provides guidance regarding compliance with Section 3.3 ("CPs and CPSes") of the Mozilla Root Store Policy (MRSP). This page is explanatory only. It does not modify the MRSP, create additional requirements, or replace applicable requirements in the CA/Browser Forum Requirements, RFCs, audit criteria, or other Mozilla policy documents. If this guidance conflicts with the MRSP, the MRSP controls.

Purpose of MRSP Section 3.3

Relevant MRSP Text

We rely on publicly disclosed documentation in a Certification Practice Statement (CPS) or a combined Certificate Policy/Certification Practice Statement (CP/CPS) ("CP/CPS Documentation") to ascertain that our requirements are met. Compliance with this Section SHALL be evaluated based on whether a technically competent reviewer can, from the CA operator's CP/CPS Documentation, determine the CA operator's implementation commitments, understand the scope and applicability of the documented practices, and assess conformance with applicable requirements.

Guidance

Mozilla relies on publicly disclosed Certification Practice Statements (CPSes) and combined Certificate Policy / Certification Practice Statements (CP/CPSes), collectively referred to in the MRSP as "CP/CPS Documentation," to understand how CA operators implement applicable requirements and to assess conformance with those requirements.

The purpose of MRSP Section 3.3 is to improve the clarity, consistency, transparency, auditability, maintainability, and long-term accessibility of CP/CPS Documentation. The revisions adopted in MRSP v3.1 are intended to improve the ability of Mozilla, auditors, relying parties, researchers, and other interested parties to understand how a CA operator implements applicable requirements and how those implementation commitments evolve over time.

Mozilla's focus is not on drafting style, document length, preferred wording, or a particular document-management platform. Rather, the focus is whether a technically competent reviewer can, from the CA operator's CP/CPS Documentation:

• determine the CA operator's implementation commitments;
• understand the scope and applicability of the documented practices;
• determine which practices apply to which root CA and subordinate CA certificates;
• understand how the CA operator implements applicable requirements; and
• assess conformance with applicable requirements.

Effective Date and Transition

Relevant MRSP Text

CA operators SHALL comply with item 2 below, and Sections 3.3.1 through 3.3.6, no later than July 1, 2027. Existing CP/CPS Documentation MAY be revised prior to July 1, 2027, to achieve compliance with these requirements.

Guidance

MRSP Section 3.3 provides a transition period for implementation of the new CP/CPS Documentation requirements.

CA operators are expected to comply with MRSP Section 3.3 item 2 and Sections 3.3.1 through 3.3.6 no later than July 1, 2027.

Existing CP/CPS Documentation may be revised before July 1, 2027, to achieve compliance.

Mozilla encourages CA operators to begin planning early, especially where implementation may require migration to structured text formats, publication repositories, version-history systems, revised document organization, hierarchy mapping mechanisms, or companion documents such as certificate profile specifications.

General Compliance Objective

A CA operator should evaluate its CP/CPS Documentation by asking:

• Can a technically competent reviewer determine what the CA operator actually does?
• Can a reviewer determine which requirements, procedures, profiles, and supporting documents apply to a particular certificate hierarchy?
• Can a reviewer identify CA-specific implementation commitments rather than merely restatements of external requirements?
• Can a reviewer determine where the CA operator has made implementation choices?
• Can a reviewer understand material operational parameters, constraints, thresholds, and timelines?
• Can an auditor or other reviewer verify the disclosed practices through documentation review, audit procedures, certificate analysis, system review, or other objective evidence?

If the answer to these questions is generally "yes," the documentation likely satisfies the objectives of MRSP Section 3.3.

MRSP Section 3.3, Item 1: Sufficiency of Disclosure

Relevant MRSP Text

1. CP/CPS Documentation MUST provide information in a manner that is explicit, bounded, auditable, and in a manner that is sufficient for Mozilla to determine whether and how the CA operator complies with this policy and other applicable requirements;

Guidance

MRSP Section 3.3, Item 1 requires CP/CPS Documentation to provide information in a manner that is explicit, bounded, auditable, and sufficient for Mozilla to determine whether and how the CA operator complies with applicable requirements.

The objective is not to require a particular writing style or document format. The objective is to ensure that a technically competent reviewer can understand the CA operator's implementation commitments and evaluate conformance with applicable requirements.

MRSP Section 3.3, Item 2: Structured Text Formats and Public Version History

Relevant MRSP Text

2. CA operators MUST ensure that CP/CPS Documentation is made available in a structured, text-based format (e.g. Markdown, AsciiDoc, or equivalent) and is hosted in a publicly accessible repository or equivalent system that provides publicly accessible version history. An "equivalent system" is a publicly accessible document management or publication system that preserves version history, permits retrieval of prior versions, and identifies publication dates and version identifiers. Historic versions are not required to be converted to a structured text format retroactively, provided that they remain publicly accessible and their publication dates can be determined. This requirement applies to the published form of the documentation and does not prescribe the CA operator’s internal authoring tools or processes;

Guidance

MRSP Section 3.3, Item 2 requires CP/CPS Documentation to be published in a structured, text-based format and hosted in a publicly accessible repository or equivalent system that provides publicly accessible version history.

The purpose of this requirement is to improve transparency, reviewability, version comparison, public change tracking, accessibility, long-term maintainability, and ease of analysis by Mozilla and other reviewers.

Structured Text-Based Format

Structured text formats make it easier for reviewers to compare versions, identify changes, perform searches, maintain links, and evaluate documentation over time.

Examples of potentially acceptable structured text formats include:

• Markdown;
• AsciiDoc;
• reStructuredText;
• HTML generated from structured source files;
• plain text formats with clear structure; or
• other structured text-based formats that support public review and version comparison.

PDF may remain useful as a rendered publication format. However, the MRSP expects the published CP/CPS Documentation itself to be available in a structured, text-based format.

Public Repositories and Equivalent Systems

MRSP Section 3.3, Item 2 does not require use of a particular platform.

An "equivalent system" is a publicly accessible document management or publication system that:

• preserves version history;
• permits retrieval of prior versions;
• identifies publication dates;
• identifies version identifiers; and
• allows reviewers to determine what changed over time.

Examples of potentially acceptable systems include:

• GitHub;
• GitLab;
• Bitbucket;
• public source repositories;
• public documentation repositories;
• static websites generated from version-controlled source files; or
• other public systems with comparable version-history functionality.

Mozilla does not require use of GitHub specifically.

Internal Authoring Tools

MRSP Section 3.3, Item 2 does not prescribe the CA operator's internal authoring tools or internal document-management workflow.

CA operators may continue using:

• Microsoft Word;
• Google Docs;
• internal document-management systems;
• approval workflows;
• ticketing systems;
• governance platforms; or
• other internal drafting and approval processes.

The requirement applies to the published form of the documentation, not necessarily to the internal drafting tool.

For example, a CA operator may draft internally using Microsoft Word and publish the approved version in Markdown or AsciiDoc in a public repository. The repository should preserve version history, allow retrieval of prior versions, identify publication dates and version identifiers, and allow reviewers to understand how the documentation has changed over time.

Purpose of Public Version History

The repository and version-history requirements are intended to improve transparency and reviewability of CP/CPS Documentation.

Mozilla, auditors, researchers, relying parties, and other interested parties should be able to determine:

• what changes have been made;
• when those changes occurred;
• which version of the documentation was in effect at a particular point in time; and
• how the CA operator's implementation commitments have evolved over time.

Reviewers should be able to retrieve historical versions, identify publication dates and version numbers, and compare revisions without requiring direct assistance from the CA operator.

MRSP Section 3.3, Item 3: Licensing

Relevant MRSP Text

3. CP/CPS Documentation MUST be made available to Mozilla under one of the following Creative Commons licenses (or later versions):

• Attribution ([CC-BY]) 4.0;
• Attribution-ShareAlike ([CC-BY-SA]) 4.0;
• Attribution-NoDerivs ([CC-BY-ND]) 4.0; or
• Public Domain Dedication ([CC-0]) 1.0;

or a set of equally permissive licensing terms accepted by Mozilla in writing. If no such license is indicated, the fact of application for root inclusion is considered permission from the CA operator to allow Mozilla and the public to deal with CP/CPS Documentation under CC-BY-ND 4.0;

Guidance

MRSP Section 3.3, Item 3 requires CP/CPS Documentation to be made available under one of the Creative Commons licenses identified in the MRSP, or under equally permissive licensing terms accepted by Mozilla in writing.

The purpose of this requirement is to ensure that Mozilla and the public can access, quote, compare, archive, analyze, discuss, and preserve CP/CPS Documentation for root program oversight, public review, compliance analysis, research, and related purposes.

CA operators should clearly identify the applicable license in their CP/CPS Documentation, repository, or publication system.

Examples of acceptable approaches include:

• including a license notice within the document;
• maintaining a license file within the repository;
• including license information in repository metadata; or
• other mechanisms that clearly communicate the applicable license terms.

MRSP Section 3.3, Item 4: Review, Versioning, and Change Logs

Relevant MRSP Text

4. CP/CPS Documentation MUST be reviewed and updated as necessary at least once every 365 days, as required by the S/MIME BRs or TLS BRs. CA operators MUST indicate that this has happened by incrementing the version number and adding a dated changelog entry, even if no other changes are made to the document;

Guidance

MRSP Section 3.3, Item 4 requires CP/CPS Documentation to be reviewed and updated as necessary at least once every 365 days, as required by the TLS Baseline Requirements or S/MIME Baseline Requirements.

CA operators must indicate that the review occurred by:

• incrementing the version number; and
• adding a dated changelog entry.

This applies even if no substantive changes are made to the document.

Annual Reviews

The purpose of the annual review requirement is to ensure that CP/CPS Documentation continues to accurately reflect the CA operator's practices, systems, operational constraints, and implementation commitments.

Annual review should include consideration of:

• changes to applicable requirements;
• changes to CA operations;
• changes to certificate profiles;
• changes to delegated functions;
• changes to validation practices;
• changes to revocation practices;
• changes to repositories;
• changes to supporting documentation; and
• other changes that may affect the accuracy of the documentation.

Changelog Examples

Examples of acceptable changelog entries include:

Annual Review with No Substantive Changes

2027-05-15 — Annual review completed. No substantive changes.

Annual Review with Updates

2027-05-15 — Updated certificate profile references and revised domain validation procedures.

Operational Change

2027-09-01 — Added automated CAA checking procedures for TLS issuance.

Material changes to implementation commitments should be reflected through appropriate version increments and changelog entries so that external parties can determine when substantive changes occurred.

MRSP Section 3.3, Item 5: RFC 3647 Structure

Relevant MRSP Text

5. CP/CPS Documentation MUST be structured according to the common outline set forth in section 6 of RFC 3647, as may be amended by the CA/Browser Forum's TLS BRs or its S/MIME BRs, and MUST:

• include at least every section and subsection defined in section 6 of RFC 3647;
• only use the words "No Stipulation" to mean that the particular document imposes no requirements related to that section; and
• contain no sections that are entirely blank, having no text or subsections;

Guidance

MRSP Section 3.3, Item 5 requires CP/CPS Documentation to be structured according to the common outline set forth in Section 6 of RFC 3647, as amended by applicable CA/Browser Forum Requirements.

The purpose of this requirement is to improve consistency, reviewability, and comparability across CA operators.

Required Sections and Subsections

CP/CPS Documentation must include at least every section and subsection defined in Section 6 of RFC 3647.

Mozilla does not prescribe a particular writing style or level of detail for each section. However, each section should contain sufficient information for a reviewer to understand the CA operator's practices, implementation commitments, and scope of applicability.

Use of No Stipulation

The phrase No Stipulation should be used only when the CA operator does not impose any requirements, policies, constraints, commitments, or practices that are specific to the corresponding RFC 3647 section.

In CP/CPS Documentation, No Stipulation may be appropriate where:

• the section is not applicable to the CA's operations; or
• the CA has no practices to describe for that topic.

However, No Stipulation should not be used as a substitute for describing practices that are material to understanding the CA operator's implementation commitments.

Where doing so would improve reviewer understanding, CA operators are encouraged to briefly explain why No Stipulation is used.

Examples:

No Stipulation. The CA does not issue certificates of this type.

No Stipulation. There are no CA-specific practices applicable to this section.

Blank Sections

MRSP Section 3.3, Item 5 prohibits sections that are entirely blank.

The purpose of this requirement is to distinguish between:

• sections that are not applicable;
• sections where no CA-specific practices exist; and
• sections that were inadvertently left incomplete.

Where a section is not applicable, a brief explanatory statement is generally preferable to leaving the section blank.

MRSP Section 3.3, Item 6: Applicability, Scope, and Hierarchy Mapping

Relevant MRSP Text

6. CP/CPS Documentation MUST provide a way to clearly determine with sufficient clarity which operational practices and profiles apply to which root CA and intermediate CA certificates; and

Guidance

MRSP Section 3.3, Item 6 requires CP/CPS Documentation to provide a way to determine which operational practices and profiles apply to which root CA and intermediate CA certificates.

This requirement is particularly important for CA operators with multiple root hierarchies, multiple certificate types, externally operated subordinate CAs, or different operational models.

A reviewer should be able to determine which practices apply to which CA certificates.

A useful mapping may identify:

• root CA certificate name;
• root CA certificate SHA-256 fingerprint;
• subordinate CA certificate name;
• subordinate CA certificate SHA-256 fingerprint;
• applicable CP/CPS;
• applicable certificate profile document;
• applicable audit scope;
• applicable certificate types;
• applicable repository location; and
• effective dates.

Mozilla does not require a specific mapping format.

MRSP Section 3.3, Item 7: Historic Versions

Relevant MRSP Text

7. CA operators SHALL maintain links to all historic versions of CP/CPS Documentation from the creation of included CA certificates, regardless of changes in ownership or control of such CA certificates, until the entire CA certificate hierarchies (i.e. end entity certificates, intermediate CA certificates, and cross-certificates) operated in accordance with such documents are no longer trusted by the Mozilla root store. For CA certificates that were included in Mozilla's root store before December 31, 2022, the CA Operator shall maintain links in their online repositories to all reasonably available historic versions of CP/CPS Documentation from creation of the included CA certificates.

Guidance

The purpose of maintaining historic versions is to allow Mozilla, auditors, researchers, relying parties, and other reviewers to understand the practices under which certificates were issued or managed at a particular point in time.

Historic versions are not required to be retroactively converted to Markdown, AsciiDoc, or another structured text-based format if they remain publicly accessible and their publication dates can be determined.

Historical PDF versions may remain in PDF format, provided they remain publicly accessible and their publication dates and version identifiers can be determined.

MRSP Section 3.3.1: Sufficiency of Disclosure

Relevant MRSP Text

To satisfy item 1 of Section 3.3 above, CP/CPS Documentation MUST contain sufficient CA-specific detail to allow a technically competent reviewer to understand how the CA operator implements applicable requirements and to evaluate conformance without requiring a reviewer to assemble material operational commitments from multiple external documents whose applicability is unclear.

CP/CPS Documentation MUST describe the CA operator’s implementation commitments, including relevant operational parameters, constraints, and design choices, particularly in areas where applicable requirements permit discretion or variation.

CP/CPS Documentation is not required to disclose information that would reasonably be expected to materially increase risk to the security of CA systems or facilities, provided that sufficient information remains available for a technically competent reviewer to understand the CA operator's implementation commitments and assess conformance with applicable requirements.

Guidance

An implementation commitment is a statement describing how the CA operator implements a requirement or performs an operational activity.

Implementation commitments are particularly important where applicable requirements permit discretion, alternative methods, configurable parameters, CA-specific procedures, or different operational approaches.

The goal is not necessarily to increase the length of CP/CPS Documentation. Rather, the goal is to ensure that material implementation commitments are sufficiently clear to be understood and evaluated.

Less Helpful Examples

• "The CA periodically reviews validation procedures."
• "Revocation requests are processed promptly."
• "The CA performs security monitoring as appropriate."
• "The CA may conduct additional verification."
• "The CA complies with the TLS Baseline Requirements."

While these statements may be true, standing alone they often do not explain what the CA operator actually does.

More Helpful Examples

• "The CA reviews validation procedures at least annually and whenever material changes are made to validation systems or applicable requirements."
• "Revocation requests are processed within the timelines required by section 4.9.1.1 of the TLS Baseline Requirements."
• "Security events affecting certificate issuance systems are monitored continuously by the Security Operations Center."
• "For organization validation, the CA verifies the Applicant's legal existence using government registry records or a Qualified Independent Information Source."
• "The CA performs CAA checking using the procedures described in Appendix X."

MRSP Section 3.3.2: Normative References and Incorporation by Reference

Relevant MRSP Text

To avoid duplication, divergence, and staleness, incorporation by reference SHOULD be used for shared definitions and externally defined normative requirements (e.g., CA/Browser Forum Requirements, RFCs, documents incorporated by reference therein, corresponding WebTrust or ETSI audit criteria, and other applicable policies).

However, incorporation by reference MUST NOT be used as a substitute for describing CA-specific implementation practices. CP/CPS Documentation MUST clearly identify incorporated documents.

CP/CPS Documentation MAY reference operational, contractual, informational, repository, or technical materials maintained outside the CP/CPS Documentation by the CA operator, Root Programs, the CCADB, standards bodies, or the CA/Browser Forum (e.g., webpages, Subscriber Agreements, validation procedures, or technical appendices), provided that:

• such materials are clearly identified and publicly accessible where necessary to understand the CA operator’s practices;
• their scope and applicability are clearly described;
• the CP/CPS Documentation remains sufficiently complete and coherent for a reviewer to understand how the CA operator complies with applicable requirements; and
• such references do not alter or supersede applicable requirements.

Guidance

Mozilla encourages incorporation by reference where appropriate.

Incorporation by reference can:

• reduce duplication;
• avoid divergence from external requirements; and
• minimize document maintenance burden.

Appropriate incorporated materials may include:

• CA/Browser Forum Requirements;
• RFCs;
• WebTrust or ETSI criteria;
• certificate profile documents;
• validation procedure documents;
• subscriber agreements;
• repository materials; and
• technical appendices.

However, incorporation by reference should not be used as a substitute for describing CA-specific implementation practices.

A reviewer should not be required to reconstruct material implementation commitments from numerous external documents whose applicability is unclear.

Examples

Less Helpful

"The CA complies with applicable CA/Browser Forum Requirements."

More Helpful

"The CA performs domain validation using the methods identified in Table X. The CA's implementation of each method is described in Appendix Y."

Less Helpful

"Validation is performed in accordance with internal procedures."

More Helpful

"Validation is performed in accordance with the publicly available Validation Procedures document, version 3.2, referenced in Appendix A."

MRSP Section 3.3.3: Implementation Commitments

Relevant MRSP Text

CP/CPS Documentation MUST explicitly describe those aspects of the CA operator’s practices that materially affect certificate issuance, validation, revocation, and status services.

Such disclosures MUST be:

• Explicit (clearly stating what the CA does),
• Bounded (defining limits, thresholds, or constraints where applicable), and
• Verifiable (capable of being independently evaluated through documentation review, audit procedures, or other objective evidence).

Subjective or non-measurable language (e.g., "as appropriate," "periodically," "a few," "promptly") MUST NOT be used in place of defined operational parameters where those parameters can reasonably be specified.

Guidance

This requirement focuses on the operational areas that most directly affect public trust: certificate issuance, validation, revocation, and certificate status services.

Explicit

A disclosure is explicit when it clearly states what the CA operator does.

Less Helpful

"The CA may perform additional verification."

More Helpful

"Before issuing EV TLS certificates, the CA verifies the Applicant's legal existence, physical existence, operational existence, domain authorization, and authority of the certificate requester."

Bounded

A disclosure is bounded when limits, thresholds, timelines, conditions, or constraints are identified where applicable.

Less Helpful

"Audit logs are retained for an appropriate period."

More Helpful

"Audit logs for certificate issuance systems are retained for at least seven years."

Less Helpful

"The CA reviews access rights periodically."

More Helpful

"The CA reviews logical access rights to certificate issuance systems at least quarterly."

Verifiable

A disclosure is verifiable when an independent reviewer can evaluate the statement through documentation review, audit procedures, technical testing, certificate analysis, or other objective evidence.

Less Helpful

"The CA maintains strong security controls."

More Helpful

"Multi-factor authentication is required for all personnel with administrative access to certificate issuance systems."

Use of Subjective Language

Subjective or non-measurable language should not be used in place of defined operational parameters where those parameters can reasonably be specified.

Examples of terms that may require additional context include:

• "periodically";
• "promptly";
• "as appropriate";
• "as necessary";
• "regularly";
• "from time to time";
• "a few";
• "reasonable"; and
• "sufficient."

These words are not prohibited in all circumstances. However, where the CA operator can reasonably define a timeline, threshold, condition, or procedure, the CP/CPS Documentation should do so.

MRSP Section 3.3.4: Organization and Scope

Relevant MRSP Text

CP/CPS Documentation MUST be organized and scoped such that a reviewer can determine:

• which legal entity and CA operator are responsible for the described practices;
• which root certificates, subordinate CAs, and certificate types or profiles are covered; and
• how related documents, if any, apply to specific hierarchies.

Documentation MUST not require a reviewer to assemble material operational commitments from numerous disparate documents that lack clear scoping, applicability, or cross-reference.

Guidance

CP/CPS Documentation should be organized so that a reviewer can determine:

• the legal entity responsible for the documented practices;
• the CA operator responsible for the relevant operations;
• which root CA certificates are covered;
• which subordinate CA certificates are covered;
• which certificate types are covered;
• which certificate profiles are covered;
• which policies and procedures apply to each hierarchy; and
• how related documents apply.

Acceptable approaches may include:

• applicability tables;
• hierarchy diagrams;
• profile matrices;
• document cross-reference tables;
• root and subordinate CA mapping tables;
• separate sections for different certificate types;
• separate appendices for TLS and S/MIME practices; or
• other equivalent methods.

The primary CP/CPS Documentation must remain structured according to the RFC 3647 framework required by the MRSP. Within that framework, CA operators may use a variety of approaches to organize supporting materials.

Documentation Sets and Supporting Documents

Mozilla does not require all relevant information to appear in a single CP/CPS document.

CA operators may choose to maintain:

• certificate profile specifications;
• validation procedure documents;
• technical appendices;
• repository materials;
• subscriber agreements; or
• other companion documents.

However, the CP/CPS Documentation should function as a coherent and understandable documentation set.

A technically competent reviewer should be able to begin with the CP/CPS Documentation and readily determine:

• which supporting documents are relevant;
• which CA certificates or hierarchies they apply to;
• where particular implementation commitments are described; and
• how the documents relate to one another.

The use of multiple documents does not relieve the CA operator of the responsibility to provide a clear, complete, and understandable description of its practices.

Less helpful documentation structures are those that require reviewers to perform extensive cross-referencing or interpretive reconstruction in order to understand how the CA operates.

For example, a CPS that repeatedly refers readers to a separate CP for substantive operational details, while the CP in turn references profile documents, validation manuals, or other materials without clearly identifying their applicability, may make it difficult for reviewers to determine which practices apply to which CA certificates.

More helpful documentation structures clearly identify the role, scope, and applicability of each document within the overall documentation set.

MRSP Section 3.3.5: Certificate and Revocation Profiles

Relevant MRSP Text

CP/CPS Documentation MUST describe, or clearly reference, the certificate, CRL, and OCSP profiles used by the CA operator.

Such profiles MAY be maintained in a separately versioned CA-maintained appendix or companion document, provided that the referenced material is publicly accessible, clearly in-scope, versioned, and sufficient to describe the technical characteristics and constraints of issued certificates and revocation artifacts.

Guidance

MRSP Section 3.3.5 requires CP/CPS Documentation to describe, or clearly reference, certificate, CRL, and OCSP profiles used by the CA operator.

Profiles may be maintained outside the primary CPS or CP/CPS if the referenced materials are:

• publicly accessible;
• clearly in scope;
• versioned;
• maintained by or under the responsibility of the CA operator; and
• sufficient to describe the technical characteristics and constraints of issued certificates and revocation artifacts.

A reviewer should be able to determine which certificate, CRL, and OCSP profiles apply to each relevant CA hierarchy.

Examples of acceptable profile documentation may include:

• certificate profile appendices;
• profile matrices;
• ASN.1 profile specifications;
• linting profile documentation;
• public Git repositories containing profile definitions;
• technical appendices; or
• equivalent public documentation.

MRSP Section 3.3.6: Accuracy and Currency

Relevant MRSP Text

CP/CPS Documentation MUST accurately reflect the CA operator’s current practices, systems, and operational constraints.

Material changes to implementation commitments MUST be reflected through appropriate updates, including version increments and changelog entries, so that external parties can determine when substantive changes have occurred.

Guidance

CP/CPS Documentation should accurately reflect the CA operator's current practices, systems, operational constraints, and implementation commitments.

Documentation that is technically correct but materially outdated may fail to achieve the objectives of MRSP Section 3.3.

When operational practices change, the corresponding documentation should be updated within a reasonable period of time so that reviewers can continue to rely upon the published documentation as an accurate description of the CA operator's practices.

Material changes to implementation commitments should be reflected through appropriate version increments and changelog entries so that external parties can determine when substantive changes occurred.

Security-Sensitive Information

MRSP Section 3.3 is intended to improve transparency regarding CA operations and implementation commitments. It is not intended to require disclosure of information that would reasonably be expected to materially increase risk to the security of CA systems, facilities, personnel, or cryptographic assets.

CA operators should disclose sufficient information to allow a technically competent reviewer to understand and evaluate the CA operator's implementation commitments, while exercising reasonable judgment regarding information that could materially weaken the security of CA operations if publicly disclosed.

Examples of information that generally should not be disclosed publicly include:

• authentication secrets;
• private keys;
• internal passwords;
• private cryptographic material;
• detailed network security configurations;
• internal IP addressing schemes;
• vulnerability details that would facilitate compromise;
• detailed exploit paths;
• physical security details that would facilitate unauthorized access;
• sensitive incident response procedures; or
• other information that would materially weaken the security of CA systems or facilities.

However, withholding security-sensitive details does not eliminate the need to disclose implementation commitments.

For example, a CA operator need not disclose a detailed network diagram of its certificate issuance environment. However, a reviewer should still be able to determine that logical access controls exist, that multi-factor authentication is required where applicable, that privileged actions are logged, and that monitoring controls are in place.

The focus should remain on disclosure of implementation commitments rather than disclosure of exploit-sensitive operational details.

Information Commonly Expected to Be Disclosed

The specific content required in CP/CPS Documentation will vary depending on the CA operator's business model, certificate types, operational environment, delegated functions, and applicable requirements.

However, reviewers would generally expect CP/CPS Documentation to describe, or clearly reference, information such as:

• certificate types issued;
• certificate issuance processes;
• validation methods used;
• domain validation procedures;
• organization validation procedures;
• individual identity validation procedures, where applicable;
• authorization of certificate requests;
• certificate profile applicability;
• certificate profiles;
• CRL profiles;
• OCSP profiles;
• pre-issuance controls;
• CAA checking procedures;
• linting practices;
• revocation request intake;
• revocation decision-making processes;
• revocation timelines;
• certificate status service operation;
• delegated functions;
• externally operated subordinate CAs;
• key management practices;
• repository publication practices;
• audit coverage and audit scope descriptions;
• document applicability;
• hierarchy mapping;
• annual review processes; and
• version management practices.

This list is illustrative rather than exhaustive.

The appropriate level of disclosure depends on whether the information is necessary for a technically competent reviewer to understand the CA operator's implementation commitments and assess conformance with applicable requirements.

What Mozilla Is Not Seeking

The provisions of MRSP Section 3.3 are intended to improve clarity, transparency, and reviewability. They are not intended to impose unnecessary burdens or require disclosure of information that is not useful for evaluating compliance.

Mozilla is not seeking:

• a single drafting style;
• a single document-management platform;
• a single repository platform;
• a single hierarchy mapping methodology;
• a single certificate profile format;
• disclosure of sensitive information that would materially increase risk to CA systems or facilities;
• abandonment of internal authoring tools such as Microsoft Word or Google Docs;
• retroactive conversion of historic PDF documents into Markdown or AsciiDoc;
• consolidation of all supporting materials into a single document; or
• unnecessarily lengthy documentation.

Longer documentation is not necessarily better documentation.

Mozilla's objective is documentation that is clear, understandable, appropriately scoped, reasonably current, and sufficiently detailed to allow reviewers to understand the CA operator's implementation commitments and evaluate conformance with applicable requirements.

Suggested Implementation Plan

CA operators preparing for compliance with MRSP Section 3.3 may find it useful to perform the following activities.

Documentation Inventory

1. Inventory all current CP/CPS documents.

2. Inventory all historic CP/CPS versions that remain reasonably available.

3. Identify all root CA and subordinate CA certificates covered by each document.

4. Identify all certificate, CRL, and OCSP profile documents.

5. Identify all supporting documents incorporated by reference.

Documentation Review

1. Determine whether current documentation clearly identifies implementation commitments.

2. Determine whether current documentation clearly maps practices and profiles to specific hierarchies.

3. Determine whether supporting documents are clearly identified and scoped.

4. Identify sections that merely restate external requirements without describing CA-specific implementation practices.

5. Identify sections containing subjective language that could be replaced with defined operational parameters.

Publication Review

1. Confirm that documentation is available in a structured text-based format.

2. Confirm that documentation is published in a publicly accessible repository or equivalent system.

3. Confirm that public version history is available.

4. Confirm that publication dates and version identifiers are clearly visible.

5. Confirm that historical versions remain accessible.

Governance Review

1. Confirm that annual review procedures exist.

2. Confirm that version numbering practices are documented.

3. Confirm that changelog practices are documented.

4. Confirm that licensing information is properly displayed.

5. Confirm that documentation ownership and maintenance responsibilities are defined.

Frequently Asked Questions

Does Mozilla require GitHub?

No.

GitHub is one possible way to satisfy the repository and version-history requirements, but Mozilla does not require use of GitHub specifically. Other public systems may be acceptable if they preserve version history, permit retrieval of prior versions, identify publication dates and version identifiers, and allow reviewers to understand how documentation has changed over time.

Does Mozilla require CA operators to stop using Microsoft Word internally?

No.

The requirement applies to the published form of the documentation. CA operators may continue using Microsoft Word, Google Docs, internal document-management systems, or other internal drafting and approval tools.

Must historical PDF versions be converted to Markdown or AsciiDoc?

No.

Historic versions are not required to be retroactively converted to a structured text-based format if they remain publicly accessible and their publication dates and version identifiers can be determined.

Can certificate profiles be maintained outside the CP/CPS?

Yes.

Certificate, CRL, and OCSP profiles may be maintained in separately versioned appendices, repositories, companion documents, or similar supporting materials, provided they are publicly accessible, clearly in scope, versioned, and sufficiently identified.

What level of detail is expected for certificate profiles in CP/CPS Documentation?

Mozilla does not prescribe a specific format for certificate profiles. Certificate profile information may be presented using field-by-field profile tables, structured profile specifications, references to externally maintained profile documentation, or other formats that clearly describe the certificates issued by the CA.

The objective is not to standardize documentation style, but to ensure that certificate profile information is sufficiently clear, complete, and accurate to allow a technically competent reviewer to understand the certificates issued by the CA and evaluate conformance with applicable requirements.

Certificate profiles should be maintained as authoritative descriptions of the certificates the CA intends to issue. Profile documentation should accurately reflect the certificates currently issued by the CA and should be updated when certificate content changes. A reviewer should be able to compare an issued certificate against the documented profile and determine whether the certificate conforms to the CA's documented practices.

Mozilla encourages CA operators to view certificate profiles not only as compliance documentation, but also as an important preventive control. Many certificate misissuance incidents have involved unexpected or incorrectly configured certificate fields, extensions, constraints, policy identifiers, or other certificate content. Accurate and sufficiently detailed certificate profiles help reduce the risk of such incidents by providing a clear specification against which issuance systems, linting tools, auditors, and compliance personnel can validate certificate content.

Certificate profiles should therefore contain sufficient detail to support implementation review, auditor testing, compliance assessment, and operational validation. In general, profiles should identify the certificate type to which they apply and describe the fields, extensions, constraints, policy identifiers, and other certificate content relevant to demonstrating conformance with applicable requirements. Any optional, conditional, or profile-specific variations should be clearly identified.

Mozilla does not require every profile to be documented at the same level of granularity. However, profile documentation should be sufficiently detailed that it can serve as a reliable reference for understanding the certificate content the CA intends to issue and for identifying unintended deviations between documented practices and actual certificates.

In short, the profile should match the certificate, and the certificate should match the profile.

Can a CA operator use multiple CP/CPS documents?

Yes.

Multiple documents are acceptable if their scope, applicability, and relationship to specific CA certificate hierarchies are clear and the documentation set remains coherent and understandable.

Does every procedure need to be public?

No.

MRSP Section 3.3 does not require publication of information that would reasonably be expected to materially increase risk to CA systems or facilities.

However, sufficient implementation commitments should remain publicly disclosed to permit meaningful review and evaluation.

Is longer documentation always better?

No.

Longer documentation is not necessarily better documentation.

Clear, accurate, understandable, appropriately scoped, and reasonably current documentation is generally more useful than documentation that is lengthy but difficult to understand.

Can a CA operator simply incorporate the TLS Baseline Requirements by reference?

External requirements may be incorporated by reference where appropriate.

However, incorporation by reference is not a substitute for describing CA-specific implementation practices.

Reviewers should still be able to understand how the CA operator implements applicable requirements.

What should a CA operator do if different practices apply to different subordinate CAs?

The documentation should clearly identify which practices apply to which subordinate CAs.

This may be accomplished through:

• applicability tables;
• hierarchy diagrams;
• profile matrices;
• appendices;
• mapping tables; or
• other equivalent mechanisms.

How should annual review with no substantive changes be documented?

The CA operator should increment the version number and add a dated changelog entry indicating that annual review was completed and that no substantive changes were made.

For example:

2027-05-15 — Annual review completed. No substantive changes.

Continuing Feedback

Mozilla welcomes feedback regarding implementation of MRSP Section 3.3.

As implementation experience develops, Mozilla may revise this guidance to address common questions, clarify expectations, provide additional examples, and improve consistency of interpretation.

CA operators are encouraged to raise questions through established Mozilla Root Program communication channels when additional clarification would be helpful.