CA/CPS-FAQs

CP/CPS Documentation Frequently Asked Questions

Note:

This page provides additional explanatory guidance regarding Section 3.3 ("CPs and CPSes") of the Mozilla Root Store Policy (MRSP). It is intended to answer common implementation questions and provide practical guidance for CA operators.

This FAQ 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 FAQ conflicts with the MRSP, the MRSP controls.

Purpose

Mozilla developed this FAQ to accompany the CP/CPS Documentation Guidance for MRSP Section 3.3.

The Guidance explains the objectives and interpretation of the policy requirements. This FAQ answers common implementation questions that CA operators may encounter while preparing, maintaining, or revising their CP/CPS Documentation.

The answers are intended to explain the reasoning behind Mozilla's policy, illustrate acceptable approaches, and provide practical implementation advice. They should not be interpreted as creating additional policy requirements.

Mozilla expects this set of FAQs to evolve over time as implementation experience develops and additional questions arise.

General Questions

Does Mozilla require GitHub?

No. GitHub is just one example of a platform that satisfies the MRSP requirement for a publicly accessible repository with publicly available version history. Mozilla does not require GitHub specifically.

Other platforms may also satisfy the requirement provided they preserve version history, permit retrieval of prior versions, identify publication dates and version identifiers, and allow reviewers to determine how the documentation has changed over time.

Does Mozilla require Markdown or AsciiDoc?

No. The MRSP requires publication in a structured, text-based format. Markdown and AsciiDoc are examples of acceptable formats because they are widely supported, easy to review, and work well with version-control systems.

Other structured text formats may also be acceptable if they provide similar transparency, accessibility, and maintainability.

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

No. The MRSP applies to the published form of CP/CPS Documentation. It does not prescribe the CA operator's internal authoring tools, review process, approval workflow, or document-management system.

A CA operator may continue drafting documentation in Microsoft Word, Google Docs, or another internal system, provided the published documentation satisfies the MRSP requirements.

Is longer documentation always better?

No. Mozilla is not attempting to encourage longer CP/CPS Documentation.

The objective is documentation that is sufficiently clear, complete, accurate, and understandable for a technically competent reviewer to determine the CA operator's implementation commitments and evaluate conformance with applicable requirements.

Concise documentation that accurately describes the CA operator's practices is generally more useful than lengthy documentation that primarily repeats external requirements.

How much implementation detail is enough?

There is no fixed amount of detail required.

The appropriate level of detail depends upon whether a technically competent reviewer can understand how the CA operator implements applicable requirements without needing to infer or reconstruct material implementation commitments.

In general, implementation details should be sufficiently specific to describe the CA operator's operational choices where discretion exists, while avoiding unnecessary disclosure of security-sensitive information.

Should implementation commitments use normative language such as "SHALL"?

Generally, no.

The purpose of CP/CPS Documentation is to describe how the CA operator actually performs its activities, rather than to restate requirements imposed on other parties.

Descriptive language such as "The CA performs...", "The CA verifies...", or "The CA reviews..." will often communicate implementation commitments more clearly than normative statements.

Normative language is appropriate when CP/CPS Documentation states the performance obligations of Subscribers, Relying Parties, or other participants.

What information should not be included in publicly available CP/CPS Documentation?

The MRSP is intended to improve transparency regarding CA operations, not to require disclosure of information that would reasonably be expected to materially increase risk to the security of CA systems or facilities.

Examples of information that generally should not be disclosed publicly include private cryptographic material, authentication secrets, detailed network security configurations, exploit-sensitive system information, or physical security details that could facilitate unauthorized access.

However, withholding security-sensitive implementation details does not eliminate the need to describe the corresponding implementation commitments. A reviewer should still be able to understand how the CA operator satisfies applicable requirements without exposing information that would materially weaken security.

Document Organization

This section answers common questions regarding the organization, structure, and scope of CP/CPS Documentation. Mozilla does not prescribe a single documentation architecture (but see information related to RFC 3647 below). Instead, the objective is that a technically competent reviewer can readily determine which practices apply to which CA certificates and understand the CA operator's implementation commitments without unnecessary effort.

Can a CA operator use multiple CP/CPS documents?

Yes. Mozilla does not require a CA operator to consolidate all information into a single document. A CA operator may maintain multiple CP/CPS documents, provided that the overall documentation set remains coherent and understandable. For example, a CA operator might maintain separate documentation for different certificate types (TLS Server and S/MIME Email certificates). Regardless of the organizational approach, reviewers should be able to determine which documents apply to which CA certificates and how the documents relate to one another.

Can different certificate hierarchies have different documentation?

Yes. Different root CA certificates or subordinate CA hierarchies may legitimately operate under different practices, provided those differences are clearly documented.

For example, a CA operator may maintain separate documentation for publicly trusted TLS hierarchies, S/MIME hierarchies, code signing hierarchies, or legacy hierarchies that continue to operate under different implementation commitments.

The documentation should clearly identify the scope and applicability of each document so that reviewers can determine which practices apply to a particular hierarchy.

May one CP/CPS cover both TLS and S/MIME operations?

Yes. Mozilla does not require separate CP/CPS documents solely because a CA operator issues different certificate types. A single document may describe multiple certificate types provided that the applicability of each section is clearly identified and reviewers can readily determine which implementation commitments apply to TLS certificates, S/MIME certificates, or other certificate types.

Some CA operators may find separate documents easier to maintain, while others may prefer a unified documentation set.

How should shared procedures across multiple certificate hierarchies be documented?

Where operational practices are common across multiple hierarchies, Mozilla encourages documenting those shared practices once rather than unnecessarily repeating the same text in multiple locations. Shared procedures may be incorporated by reference or maintained in companion documents, provided that the documentation clearly identifies which hierarchies rely upon those procedures. The objective should be to improve maintainability without losing clarity. Importantly, any supporting document should supplement the CP/CPS, not substitute for it.

How can a CA operator demonstrate which documents apply to which hierarchies?

Mozilla does not require a particular mapping methodology.

Examples of approaches that may assist reviewers include:

• tables or diagrams of CA hierarchies (see table below under 'Can implementation commitments be expressed in tables instead of prose?');
• certificate profile matrices;
• appendices identifying covered hierarchies; or
• other equivalent methods.

The objective is that a technically competent reviewer can readily determine which documentation governs a particular root CA, subordinate CA, certificate profile, or operational practice.

For instance:

Root CA	Intermediate CA	Certificate Type	CP/CPS	Certificate Profile	Validation Procedures	Audit Scope
Example Root A	TLS ICA 1	TLS	CP/CPS v5.2	TLS Profile 3.1	Validation Guide v4	WebTrust TLS
Example Root A	TLS ICA 2	EV TLS	CP/CPS v5.2	EV TLS Profile 2.0	EV Validation Guide	WebTrust TLS
Example Root B	S/MIME ICA	S/MIME	S/MIME CPS v2.0	S/MIME Profile 4.0	S/MIME Validation Guide	WebTrust S/MIME

This example is illustrative only. Mozilla does not require this specific format, set of columns, or level of detail. The table should include the information necessary for reviewers to determine which documentation, profile, audit, etc. applies to the relevant CA certificates, certificate types, operational practice, etc.

How should companion documents be organized?

Companion documents should have clearly defined purposes and relationships to the primary CP/CPS Documentation.

Examples of companion documents include:

• certificate profile specifications;
• validation procedure documents;
• technical appendices;
• subscriber agreements;
• repository information;
• audit scope descriptions; and
• operational reference materials.

The CP/CPS Documentation should clearly identify these companion documents, describe their purpose, and explain their applicability where such is necessary to explain the CA operator's implementation commitments.

How should a CA operator decide what belongs in the CP/CPS versus a companion document?

Mozilla does not prescribe a rigid boundary between the CP/CPS and supporting documentation.

In general, the CP/CPS should provide the primary description of the CA operator's implementation commitments, while companion documents may provide detailed technical specifications, procedures, reference material, or supporting information.

For example:

• implementation commitments generally belong in the CP/CPS;
• detailed certificate formats may be maintained in certificate profile documents;
• validation workflows may be maintained in validation procedure documents;
• subscriber obligations may be maintained in subscriber agreements; and
• repository information may be maintained in repository documentation.

Regardless of where information is maintained, the documentation needs to function as a coherent whole, allowing reviewers to understand the CA operator's practices without unnecessary reconstruction.

Can implementation commitments appear in appendices rather than the main body of the CP/CPS?

Yes. Mozilla does not require implementation commitments to appear exclusively within the body of the CP/CPS. Appendices may contain detailed technical information, certificate profiles, applicability tables, mappings, or other supporting material. Still, reviewers should not have to search extensively across numerous appendices or unrelated documents to understand fundamental implementation commitments.

Can implementation commitments be expressed in tables instead of prose?

Yes. Tables, matrices, diagrams, and other structured formats may improve clarity and reduce unnecessary repetition.

For example, mapping tables of document applicability, certificate profile matrices, and CA hierarchy tables may communicate information more effectively than lengthy narrative descriptions. Mozilla encourages documentation formats that improve reviewer understanding, remain sufficiently complete, and accurately reflect the CA operator's implementation commitments.

What if different operational teams follow different procedures?

Where different operational teams, business units, delegated organizations, etc. perform materially different activities, those differences should be reflected in the documentation where they affect implementation commitments. CP/CPS documentation does not need to describe internal organizational structure in detail. However, reviewers should be able to determine when different practices apply to different certificate hierarchies, certificate types, or operational environments.

Should documentation be organized around RFC 3647 or around operational processes?

The MRSP requires that CP/CPS Documentation follow Section 6 of RFC 3647, as modified by applicable CA/Browser Forum Requirements. Within that framework, CA operators can organize supporting companion documents, appendices, tables, diagrams, and cross-references in a way that improves readability and maintainability, provided the overall documentation remains coherent and reviewers can readily locate relevant implementation commitments.

Is there a preferred documentation architecture?

The objective is not to require more than what may already be required, such as following the RFC 3647 framework. Mozilla recognizes that CA operators differ in size, organizational structure, certificate offerings, and operational complexity. We seek documentation that is understandable, well organized, appropriately scoped, and capable of supporting meaningful compliance review. If a technically competent reviewer can readily determine which documents apply to which certificate hierarchies, understand the CA operator's implementation commitments, and evaluate conformance with applicable requirements, the documentation architecture is likely consistent with these objectives.

Incorporation by Reference

This section answers common questions regarding the concept of "incorporation by reference" in CP/CPS Documentation.

As explained in the questions and answers below, Mozilla encourages the careful use of incorporation by reference because it can improve consistency, reduce duplication, simplify maintenance, and reduce the likelihood that externally defined requirements become outdated or inconsistent when copied into CP/CPS Documentation. However, incorporation by reference is not a substitute for describing the CA operator's own implementation commitments.

Is incorporation by reference preferred?

For the right kinds of things, yes. Mozilla encourages incorporation by reference for externally defined normative requirements, common definitions, and other materials that are maintained by recognized standards bodies or other authoritative organizations. Appropriate incorporation by reference can reduce duplication, simplify document maintenance, and help ensure that references remain aligned with evolving external requirements. However, incorporation by reference should be used thoughtfully. A CP/CPS should remain understandable on its own and should clearly explain the CA operator's implementation commitments.

Can a CA operator rely extensively on cross-references among its own documents?

Generally, no. While cross-references are often useful for avoiding unnecessary duplication, they should not require reviewers to continually navigate among multiple CPs, CPSes, appendices, validation procedures, certificate profiles, or other companion documents in order to understand the CA operator's implementation commitments. A reviewer should be able to read the primary CP/CPS Documentation in a reasonably linear manner and understand the CA operator's operational practices without having to repeatedly or continually navigate among numerous cross-referenced documents in order to reconstruct the CA operator's implementation commitments. Cross-references are generally most effective when they provide supporting detail or technical specifications rather than replacing the primary description of the CA operator's implementation commitments. If understanding operational practices requires repeatedly moving among several documents whose relationships or applicability are unclear, the documentation may not satisfy the objectives of MRSP Section 3.3.

Can a CA operator simply incorporate Baseline Requirements by reference?

No. The CA/Browser Forum's Baseline Requirements establish what Certification Authorities are required to do. The CP/CPS Documentation should explain how the CA operator implements those requirements. Simply stating that the CA complies with the Baseline Requirements generally does not provide sufficient information for a technically competent reviewer to understand the CA operator's implementation choices, operational practices, or areas where the Baseline Requirements permit discretion.

Must every applicable requirement appear in the CP/CPS?

No. Mozilla does not expect CA operators to reproduce every applicable requirement from the TLS Baseline Requirements, the S/MIME Baseline Requirements, RFCs, or other external standards. Indeed, unnecessary duplication may increase maintenance effort and create inconsistencies when external requirements change. Instead, the CP/CPS should describe the CA operator's implementation commitments while incorporating externally defined requirements where appropriate.

What kinds of information are generally appropriate to incorporate by reference?

Examples include:

• CA/Browser Forum Requirements;
• RFCs;
• WebTrust or ETSI criteria;
• certificate policy object identifier (OID) definitions;
• publicly available repository information;
• Subscriber Agreements;
• Relying Party Agreements;
• definitions;
• technical standards; and
• other authoritative reference materials.

The appropriateness of any particular reference depends upon whether reviewers can still understand the CA operator's implementation commitments without unnecessary reconstruction.

Can a CA operator reference companion documents?

Yes. CA operators may maintain companion documents such as certificate profile specifications, validation procedures, technical appendices, repository documentation, or Subscriber Agreements. These documents may be incorporated by reference provided that they are clearly identified, their scope and applicability are apparent, and reviewers can readily determine how they relate to the primary CP/CPS Documentation.

Can a CA operator reference internal procedures to describe its implementation commitments?

Generally, no. Internal procedures that are not publicly available should not be the sole source of information needed for a technically competent reviewer to understand the CA operator's implementation commitments. Where implementation commitments are necessary for reviewers to understand how the CA operator complies with applicable requirements, those implementation commitments should be described in publicly available CP/CPS Documentation or other publicly available companion documents. Internal procedures may still exist and may contain additional operational detail beyond what is appropriate for public documentation. References to those procedures may be appropriate for informational purposes, provided the publicly available documentation remains sufficient for reviewers to understand the CA operator's implementation commitments without requiring access to the internal procedures.

Can incorporation by reference be used to reduce document length?

Yes. Reducing unnecessary duplication is one of the intended benefits of incorporation by reference. However, shorter documentation should not come at the expense of clarity. Reviewers should not be required to assemble material implementation commitments from numerous loosely connected documents whose applicability is unclear. The objective is not shorter documentation, but more maintainable and understandable documentation.

How many referenced documents are too many?

There is no fixed limit. The appropriate number depends upon whether a technically competent reviewer can reasonably understand the documentation as a coherent whole. A small number of clearly organized companion documents may be easier to understand than a single lengthy document. Conversely, numerous documents with unclear relationships may make implementation commitments unnecessarily difficult to understand. Mozilla encourages CA operators to organize referenced documents so that reviewers can easily determine:

• why each document exists;
• what information it contains;
• to which certificate hierarchies it applies; and
• how it relates to the rest of the documentation set.

Should incorporated documents be publicly accessible?

Generally, yes. Where an incorporated document is necessary for a technically competent reviewer to understand the CA operator's implementation commitments or evaluate conformance with applicable requirements, that document should be publicly accessible. Documents that serve only internal operational purposes need not necessarily be made public, provided that sufficient implementation information is available elsewhere in the published documentation.

Can the same companion document be referenced by multiple CP/CPS documents?

Yes. Many CA operators maintain common validation procedures, certificate profile specifications, or repository documentation that apply across multiple certificate hierarchies. A shared companion document may improve consistency and reduce maintenance effort, provided that each CP/CPS clearly identifies the document and explains where it applies.

Should incorporated documents have their own version numbers?

Yes. Version identifiers help reviewers determine which version of a referenced document was applicable at a particular point in time and facilitate meaningful review of historical implementation commitments. Mozilla encourages version management practices that support transparency, change tracking, and long-term maintainability throughout the documentation set.

What happens if a referenced document changes?

Material changes to referenced documents should be managed in a manner that preserves the accuracy of the overall documentation set. Where changes affect the CA operator's implementation commitments, the corresponding CP/CPS Documentation should also be updated as appropriate so that reviewers can understand when implementation changes occurred and how they affect the CA operator's practices.

Can external web pages be incorporated by reference?

Yes, provided they are sufficiently stable, publicly accessible, and appropriate for the information being referenced. CA operators should exercise care when referencing web pages that are likely to change without version history or that may disappear over time. Where practical, version-controlled repositories or documents generally provide greater transparency and long-term reviewability.

What are examples of good and poor incorporation by reference?

Less Helpful

"The CA complies with the TLS Baseline Requirements."

This statement tells the reviewer very little about how the CA actually performs validation, certificate issuance, revocation, or other operational activities.

More Helpful

"The CA performs domain validation using the method identified in Section 3.2.2.4.X of the TLS Baseline Requirements. Details of the CA's implementation of that method, including operational constraints and supporting procedures, are described in the corresponding section of the CA's publicly available Validation Procedures document."

The second example identifies both the external requirement and the CA operator's implementation, allowing reviewers to understand how the requirement is implemented in practice.

What is Mozilla's overall objective regarding incorporation by reference?

Mozilla encourages incorporation by reference where it improves clarity, consistency, maintainability, and efficiency. The goal is neither to maximize nor minimize references. Rather, the objective is documentation that enables a technically competent reviewer to efficiently understand the CA operator's implementation commitments without unnecessary duplication, unnecessary reconstruction, or uncertainty regarding the applicability of referenced materials.

Profiles

This section answers common questions regarding the profiles described in MRSP Section 3.3.5.

For purposes of this guidance, the term profile refers collectively to certificate profiles, Certificate Revocation List (CRL) profiles, Online Certificate Status Protocol (OCSP) response profiles, and other comparable technical specifications maintained by the CA operator to describe the artifacts it issues or publishes.

Mozilla encourages CA operators to view profile documentation as more than just an aid to compliance. Well-maintained profile documentation serves as an authoritative technical specification for the artifacts a CA operator issues or publishes. Accurate profiles support software development, operational consistency, auditing, compliance review, and may help prevent certificate misissuance and other forms of non-compliance.

Can profiles be maintained outside the CP/CPS?

Yes. MRSP Section 3.3.5 expressly permits profiles to be maintained in separately versioned appendices or companion documents, provided they are publicly accessible, clearly identified, appropriately versioned, and sufficiently describe the artifacts issued or published by the CA operator. Many CA operators find separate profile documents easier to maintain than embedding detailed technical specifications within the primary CP/CPS.

What level of detail is expected for profiles?

Mozilla does not prescribe a particular documentation format or level of detail. The objective is that a technically competent reviewer can understand the intended structure, content, constraints, and technical characteristics of the artifacts issued or published by the CA operator. At the same time, profile documentation should serve as an authoritative technical specification that helps the CA operator implement, maintain, test, and continuously improve its issuance and revocation processes. In general, profile documentation should contain sufficient information to support implementation, operational consistency, software development, auditor testing, compliance assessment, operational validation, independent verification, and the prevention of certificate misissuance and other forms of non-compliance.

Must profiles include ASN.1 or field-by-field layouts?

No. Mozilla does not require any particular documentation methodology. Acceptable approaches may include:

• ASN.1 specifications;
• field-by-field profile tables;
• structured technical specifications;
• profile matrices;
• automatically generated profile documentation;
• implementation specifications;
• diagrams; or
• other formats that accurately describe the intended artifacts.

The documentation format is less important than whether reviewers can readily understand the technical characteristics of the artifacts being issued or published. Profile documentation should also be detailed enough that an engineer responsible for implementing or maintaining the CA's issuance or revocation systems could use it as an authoritative technical specification.

Should profiles accurately describe the artifacts issued or published by the CA operator?

Yes. Profiles should serve as authoritative descriptions of the artifacts the CA operator intends to issue or publish. If reviewers compare an issued certificate, published CRL, or OCSP response with the corresponding profile, they should generally be able to determine whether the artifact conforms to the documented profile. Material discrepancies between documented profiles and operational artifacts may indicate outdated documentation or operational issues that warrant investigation.

Should profiles align with issuance systems, publication systems, and linting configurations?

Ideally, yes. Many CA operators use profiles as the basis for configuring certificate issuance systems, CRL generation, OCSP responders, pre-issuance linting, automated testing, and quality assurance activities. Keeping profiles, operational systems, and validation tools aligned helps reduce the likelihood of unintended behavior and promotes operational consistency. Mozilla does not prescribe any particular implementation approach but encourages maintaining consistency among these operational artifacts.

Can profile documentation be generated automatically?

Yes. Automatically generated documentation may improve consistency and reduce maintenance effort, provided that the resulting documentation remains understandable, accurate, version-controlled, and publicly accessible. CA operators should verify that automatically generated documentation accurately reflects the artifacts actually issued or published.

How should profile changes be documented?

Material changes should be reflected through appropriate version management and change documentation.

Reviewers should be able to determine:

• when the profile changed;
• what changed;
• why the change occurred, where appropriate; and
• which version of the profile applied at a particular point in time.

Version history supports auditability and facilitates investigation of historical operational practices.

How should deprecated profiles be handled?

Mozilla encourages retaining historical profile documentation for profiles governing artifacts that remain trusted or continue to exist within the Web PKI. Maintaining historical profile documentation helps reviewers understand the technical characteristics of artifacts issued or published under earlier operational practices and facilitates historical compliance review, audits, and incident investigations. Where profile documentation forms part of the CA operator's CP/CPS Documentation, Mozilla encourages managing historical profile documentation in a manner that is consistent with the versioning and historical availability of the associated CP/CPS Documentation. Historical profiles need not remain actively maintained once retired, but they should generally remain publicly available alongside the corresponding historical documentation so that reviewers can determine which profile governed a particular artifact at a particular point in time.

Should optional fields or elements be documented?

Yes. Where fields, extensions, policy identifiers, constraints, response elements, or other aspects of a profile may vary depending upon certificate type, operational circumstances, or applicable requirements, those variations should be clearly described. Reviewers should be able to determine when optional content may appear and under what conditions.

Should omitted fields or elements be documented?

Not necessarily. Mozilla does not expect profile documentation to enumerate every possible field or element that is intentionally omitted. However, where omission of a field or element is significant to understanding the profile or demonstrating conformance with applicable requirements, documenting that omission may improve reviewer understanding.

Should profile documentation identify its scope and applicability?

Yes. Each profile should clearly identify the artifacts, certificate hierarchies, certificate types, or operational environments to which it applies.

Reviewers should readily determine, as applicable, which root CA certificates, subordinate CA certificates, certificate types, CRLs, OCSP response types, or operational environment the profile governs. This may be accomplished using document applicability tables, hierarchy mappings, profile identifiers, diagrams, or other equivalent mechanisms.

Can multiple artifact types share a single profile document?

Yes. A single document may contain multiple profiles, provided each profile is clearly identified and its applicability is readily understood. Many CA operators maintain consolidated profile documents containing profiles for TLS certificates, S/MIME certificates, subordinate CA certificates, CRLs, OCSP responses, and related operational artifacts.

Should certificate, CRL, and OCSP profiles be documented to the same level of detail?

Not necessarily. MRSP Section 3.3.5 applies equally to certificates, CRLs, and OCSP responses. However, the appropriate level of detail will naturally vary depending upon the complexity and purpose of the artifact being documented. The objective is that reviewers can understand the intended technical characteristics and implementation commitments associated with each profile.

Should profiles describe implementation choices or merely technical syntax?

They should describe both, where appropriate. Useful profile documentation explains not only the technical structure of the artifacts, but also the operational intent behind configurable, optional, or conditional elements where necessary to understand the CA operator's implementation commitments. For example, profile documentation may explain when particular certificate policies are asserted, when specific extensions are included, when optional CRL extensions are published, or under what circumstances particular OCSP response characteristics may vary.

Are profiles primarily compliance documentation?

No. While profiles support compliance review and auditing, Mozilla encourages CA operators to view them as operational documentation as well.

Accurate profile documentation can support:

• software development;
• issuance system configuration;
• revocation service implementation;
• lint development;
• quality assurance;
• auditor testing;
• incident investigation;
• operational change management; and
• personnel training.

Well-maintained profiles can therefore reduce certificate misissuance, improve operational consistency, and reduce other forms of non-compliance.

What is Mozilla's overall objective regarding profiles?

Mozilla encourages CA operators to maintain profiles as authoritative technical specifications that accurately describe the artifacts the CA operator intends to issue or publish. The objective is not to standardize profile formats or prescribe a particular documentation methodology. Rather, Mozilla seeks profile documentation that improves transparency, supports meaningful compliance review, facilitates auditing, promotes operational consistency, and serves as a reliable operational reference throughout the lifecycle of the artifacts it describes.

Publication and Versioning

This section answers common questions regarding publication, version management, document maintenance, and historical availability of CP/CPS Documentation.

Mozilla's publication and versioning requirements are intended to improve transparency, facilitate meaningful review, preserve historical implementation commitments, and help reviewers determine which documentation was in effect when particular certificates were issued.

Must historical PDF versions be converted to Markdown or AsciiDoc?

No. The MRSP does not require that historic versions of CP/CPS Documentation be converted retroactively to a structured text format. Historic PDF documents may remain in PDF format, provided they remain publicly accessible and reviewers can determine their publication dates and version identifiers. The structured text requirement applies to the published form of documentation beginning July 1, 2027.

How quickly should documentation be updated after operational changes?

The MRSP does not prescribe a fixed timeframe. However, documentation should be updated within a reasonable period after material changes to implementation commitments so that it continues to accurately reflect the CA operator's current practices. Reviewers should be able to rely upon the published documentation as an accurate description of CA operations.

What should be included in a changelog?

Mozilla does not prescribe a specific changelog format. However, a changelog should enable reviewers to understand how the documentation has evolved over time. Depending upon the nature of the change, useful information may include:

• the publication date;
• the document version (reversioned at least annually, even if there are no substantive changes);
• a summary of material changes;
• references to affected sections; and
• implementation changes reflected by the update.

How should annual review with no substantive changes be documented?

The MRSP requires the version number to be incremented and a dated changelog entry to be added, even when no substantive changes have been made.

For example:

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

This demonstrates that the required review occurred and that the documentation was evaluated for continued accuracy.

Should companion documents have their own version numbers?

Generally, yes. Version identifiers help reviewers determine which version of a companion document applied at a particular point in time. Independent versioning may also simplify document maintenance where companion documents evolve at different rates than the primary CP/CPS.

What happens if a supporting document changes?

Where changes affect the CA operator's implementation commitments, the overall documentation set should continue to accurately describe current operational practices. Depending upon the nature of the change, updates to the CP/CPS, companion documents, changelog, or applicability references may all be appropriate. The objective is to ensure that reviewers can readily determine when implementation commitments changed and which documentation was applicable at a particular time.

Must every document within the documentation set share the same version number?

No. Mozilla does not require a common version numbering scheme across all documents. Many CA operators maintain separate version histories for companion documents such as certificate profiles, validation procedures, or technical appendices. Whatever versioning approach is used, reviewers should be able to understand the relationships among the documents and determine which versions were in effect together.

Should publication dates always be shown?

Yes. Publication dates are an important part of understanding historical implementation commitments. Reviewers should be able to determine when documentation became effective and when subsequent revisions were published.

Should effective dates also be identified?

Where publication and implementation occur on different dates, identifying both dates may improve reviewer understanding. Mozilla does not require separate effective dates in every circumstance, but encourages documenting them where they help explain when operational practices changed.

What if a typographical error is discovered after publication?

Minor editorial corrections that do not affect implementation commitments may generally be handled through normal document maintenance practices. However, changes affecting operational practices, implementation commitments, applicability, or technical specifications should be reflected through appropriate version management and documented in the change history.

Should obsolete documentation remain publicly available?

Generally, yes. Historic versions help reviewers understand the practices under which certificates were issued and facilitate audits, incident investigations, and historical compliance review. The MRSP therefore requires historic documentation to remain publicly accessible "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."

Can documents be removed after a hierarchy is no longer trusted?

The MRSP specifies the minimum period during which historic documentation must remain available. Once those requirements no longer apply, Mozilla does not prescribe how CA operators manage archival materials. Nevertheless, long-term preservation may continue to provide value for historical research, audits, or organizational recordkeeping.

What if a CA operator changes document management systems?

Migration to a new publication platform is acceptable, provided that the objectives of the MRSP continue to be satisfied. Reviewers should continue to have access to historic documentation, publication dates, version identifiers, and version history where required. Mozilla encourages careful planning to avoid broken references or loss of historical information during migration.

Is a specific versioning format required?

No. Mozilla does not prescribe any particular version numbering convention. Simple sequential version numbers, semantic versioning, date-based version identifiers, or other reasonable approaches may all be appropriate provided they consistently identify document revisions.

Should each companion document maintain its own changelog?

Generally, yes. Where companion documents evolve independently, maintaining individual changelogs may improve transparency and simplify review. Alternatively, a centralized changelog that clearly identifies changes across all documents may also satisfy the objectives of the MRSP. Mozilla does not prescribe a particular approach.

Can documentation be published on a static website?

Yes. The publication platform is not important. A static website, documentation portal, source-code repository, or equivalent publication system may all satisfy the MRSP, provided reviewers can access the documentation, determine its version history, and retrieve historical versions where required.

How should broken links or relocated documents be handled?

CA operators should make reasonable efforts to preserve stable references to documentation. Where documents are relocated, redirects, repository indexes, or other mechanisms should be used where practical to help reviewers locate both current and historical documentation. Maintaining continuity of access improves transparency and reduces confusion during audits or historical review.

Should publication be integrated into operational change management?

Mozilla encourages CA operators to treat documentation updates as part of normal operational governance. Many organizations find it beneficial to review whether implementation commitments remain accurate whenever operational procedures, certificate profiles, validation systems, or other material practices change. Integrating documentation maintenance into existing change-management processes may improve long-term accuracy and reduce the likelihood that documentation becomes outdated.

What is Mozilla's overall objective regarding publication and versioning?

Mozilla's publication and versioning requirements are intended to ensure that CP/CPS Documentation remains accurate, transparent, reviewable, and historically traceable throughout the lifetime of a CA hierarchy. The objective is not to prescribe a particular publication platform or document-management methodology. Rather, Mozilla seeks documentation that allows reviewers to understand how implementation commitments have evolved over time and to determine which practices governed certificate issuance at any particular point in history.

Operational Practices

This section answers common questions regarding the disclosure of operational practices in CP/CPS Documentation.

MRSP Section 3.3 is intended to improve transparency regarding how a CA operator implements applicable requirements. It is not intended to require publication of every operational procedure or internal process. Rather, the objective is that a technically competent reviewer can understand the CA operator's implementation commitments and evaluate conformance with applicable requirements.

Does every operational procedure need to be public?

No. Mozilla does not expect CA operators to publish every internal procedure, work instruction, or operational manual. Instead, the CP/CPS Documentation should describe the implementation commitments that are necessary for a technically competent reviewer to understand how the CA operator satisfies the applicable requirements. Internal procedures may remain confidential where appropriate, provided the publicly available documentation remains sufficient for meaningful review.

Can security-sensitive information be omitted?

Yes. The MRSP does not require disclosure of information that would reasonably be expected to materially increase risk to the security of CA systems, facilities, personnel, or cryptographic assets.

Examples include:

• private cryptographic material;
• authentication secrets;
• internal passwords;
• detailed network security configurations;
• exploit-sensitive technical information;
• internal IP addressing schemes;
• detailed physical security measures; and
• other information whose disclosure would materially weaken security.

However, the CA operator should still describe the corresponding implementation commitments without revealing sensitive implementation details.

How much operational detail should be disclosed?

The appropriate level of detail depends upon whether a technically competent reviewer can understand how the CA operator performs the activity being described. Implementation commitments should generally identify operational practices, applicable constraints, significant implementation choices, and relevant parameters where they materially affect certificate issuance, validation, revocation, or status services. The objective is to describe what the CA operator does, not necessarily every internal step used to accomplish it.

Should every implementation decision be documented?

Not necessarily. Mozilla is primarily interested in implementation decisions that materially affect certificate issuance, validation, revocation, certificate status services, key management, or other activities relevant to evaluating conformance with applicable requirements. Minor implementation details that do not affect reviewer understanding generally need not be documented.

Can different operational teams follow different procedures?

Yes. Different business units, operational teams, or delegated organizations may legitimately perform different activities. Where those differences materially affect implementation commitments, they should be reflected in the documentation so that reviewers can determine which practices apply to which certificate hierarchies or operational environments.

How should delegated functions be documented?

Delegated functions should be described sufficiently for reviewers to understand:

• which activities are delegated;
• which organizations perform those activities;
• the scope of the delegation;
• the CA operator's oversight responsibilities; and
• where applicable, which certificate hierarchies are affected.

Mozilla does not prescribe a particular documentation format.

How should the operations of externally-operated subordinate CAs be documented?

Where a subordinate CA is operated by an organization other than the CA operator, the documentation should clearly identify the operational relationship between the parties.

Reviewers should be able to determine:

• which activities are performed directly by the CA operator;
• which activities are performed by the subordinate CA operator;
• which implementation commitments are documented by the CA operator;
• which implementation commitments are documented by the subordinate CA operator; and
• which documentation applies to each operational activity.

Where the subordinate CA maintains its own publicly available CP/CPS Documentation or other companion documents, the superior CA operator may reference those materials where appropriate. Such references should clearly identify the applicable documents and explain their relationship to the superior CA operator's own documentation.

The objective is that a technically competent reviewer can readily determine which organization performs each operational function and where the corresponding implementation commitments are documented, without requiring extensive reconstruction from multiple unrelated documentation sets.

Should implementation commitments describe operational constraints?

Generally, yes. Where operational constraints materially affect implementation, reviewers should be able to understand those constraints.

Examples include:

• certificate lifetime limitations;
• issuance restrictions;
• validation prerequisites;
• automation requirements;
• revocation timelines;
• profile applicability; and
• other operational conditions that affect implementation.

The objective is to describe meaningful implementation choices rather than every operational detail.

Should subjective terms such as "periodically" or "promptly" be avoided?

Such terms are not necessarily prohibited. However, where a timeline, threshold, condition, or measurable parameter can reasonably be specified, Mozilla encourages providing that information instead of relying solely on subjective terminology. For example, "The CA reviews validation procedures monthly" generally provides greater clarity than "The CA periodically reviews validation procedures."

How should operational changes be reflected in the documentation?

Material operational changes should be reflected through appropriate documentation updates so that the published documentation continues to accurately describe current implementation commitments. Version history and changelog entries should help reviewers understand when implementation changes occurred.

Should the CP/CPS describe software, products, or vendors?

Only where doing so is necessary to materially assist the reviewer's understanding. Mozilla does not expect the CP/CPS Documentation to function as a system inventory. Descriptions should focus on implementation commitments rather than specific commercial products unless product identification is necessary to understand the CA operator's practices.

Should automation be described?

Yes, where automation materially affects implementation commitments. For example, documentation may explain that certificate issuance is automated, that pre-issuance linting occurs automatically, or that automated CAA checking is performed. The objective is not to document software implementation details, but to explain how automation supports the CA operator's operational practices.

Should implementation commitments describe exception handling?

Where exceptions materially affect implementation commitments, yes. Reviewers should understand when normal procedures may differ, who is authorized to approve exceptions where applicable, and how such situations remain consistent with applicable requirements. The documentation need not enumerate every conceivable operational contingency.

Should quality assurance activities be described?

Where quality assurance activities materially contribute to implementation commitments, documenting them may improve reviewer understanding.

Examples include:

• pre-issuance linting;
• certificate profile validation;
• periodic quality reviews;
• automated compliance testing; and
• operational verification processes.

Mozilla encourages describing these practices where they help reviewers understand how implementation commitments are achieved.

Should incident response procedures be documented?

General implementation commitments relating to incident response may appropriately be documented. However, Mozilla does not expect disclosure of detailed response procedures, escalation mechanisms, internal contact information, or other information that would reasonably be expected to weaken security or impair incident response capabilities.

Should implementation commitments be written for auditors?

The intended audience includes not just auditors, but also Mozilla, researchers, relying parties, software developers, compliance personnel, and other technically competent reviewers. Well-written implementation commitments also benefit the CA operator by serving as operational documentation that supports consistent implementation, training, quality assurance, and change management.

Can implementation commitments evolve over time?

Yes. As operational practices evolve, implementation commitments should evolve accordingly. Maintaining accurate documentation is an ongoing responsibility rather than a one-time exercise. Version history allows reviewers to understand how implementation commitments have changed throughout the lifetime of a CA hierarchy.

What is Mozilla's overall objective regarding operational practices?

Mozilla's objective is not to require publication of every operational procedure or internal process. Rather, Mozilla seeks documentation that accurately describes the CA operator's implementation commitments in sufficient detail for a technically competent reviewer to understand how applicable requirements are implemented and to evaluate conformance with those requirements. Effective operational documentation benefits not only external reviewers but also the CA operator by supporting consistency, accountability, maintainability, and the prevention of certificate misissuance.

RFC 3647 Compliance

This section answers common questions regarding compliance with the Mozilla Root Store Policy (MRSP) requirements concerning the organization of CP/CPS Documentation according to RFC 3647.

RFC 3647 establishes a common framework for organizing Certificate Policies (CPs) and Certification Practice Statements (CPSes). Mozilla requires use of this framework because it improves consistency, reviewability, and comparability across Certification Authorities while allowing flexibility regarding the amount of CA-specific information included within each section.

Why does Mozilla require compliance with RFC 3647?

Mozilla's requirement to organize CP/CPS Documentation according to RFC 3647 is consistent with the CA/Browser Forum's TLS and S/MIME Baseline Requirements, which also require Certification Authorities to structure their CP/CPS Documentation using the RFC 3647 framework. Mozilla believes that this common organizational structure benefits both CA operators and reviewers. Using a common outline allows reviewers to locate information more efficiently, compare documentation across CA operators, determine whether important topics have been addressed, and better understand differences in implementation. The objective is not merely to require compliance with RFC 3647, but to improve consistency, transparency, comparability, and reviewability while allowing CA operators flexibility in writing style and operational practices.

Must every section defined by RFC 3647 be included?

Yes. The MRSP requires CP/CPS Documentation to include at least every section and subsection defined by Section 6 of RFC 3647, as amended by applicable CA/Browser Forum Requirements. Additional sections or appendices may be included where appropriate, provided the RFC 3647 framework and CA/Browser requirements are followed.

Must every section contain CA-specific text?

Not necessarily. Some sections may legitimately have no CA-specific implementation commitments. Where this occurs, the section should not be left blank. Instead, the documentation should clearly indicate that no CA-specific requirements or practices apply.

When is "No Stipulation" appropriate?

The phrase No Stipulation should be used only where the CP/CPS imposes no requirements, policies, constraints, implementation commitments, or practices relating to the corresponding RFC 3647 section. It should not be used merely to avoid describing practices that are relevant to understanding the CA operator's implementation. Where helpful, Mozilla suggests adding a brief explanation after No Stipulation. For example:

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

or

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

May sections simply refer readers to another section?

Yes, where doing so improves organization and avoids unnecessary duplication. However, reviewers should still be able to understand the CA operator's implementation commitments without repeatedly navigating through numerous cross-references. Extensive cross-referencing that obscures the applicability of implementation commitments may reduce the clarity of the documentation.

Are blank sections permitted?

No. The MRSP prohibits sections that are entirely blank. A blank section makes it difficult for reviewers to determine whether the omission was intentional, whether the section is not applicable, or whether information was inadvertently omitted. A brief explanatory statement is generally preferable.

May additional subsections be added?

Yes. RFC 3647 establishes a minimum organizational framework. CA operators may add additional sections, subsections, appendices, diagrams, tables, or companion documents where they improve clarity or better describe implementation commitments. Mozilla encourages documentation that enhances reviewer understanding.

May the order of RFC 3647 sections be changed?

Generally, no. Maintaining the common RFC 3647 structure improves consistency across CA operators and helps reviewers locate information efficiently. Additional material may certainly be inserted where appropriate, but the overall framework should remain recognizable.

May implementation commitments appear in appendices?

Yes. Detailed technical material, applicability tables, hierarchy mappings, certificate profiles, and similar supporting information may appropriately appear in appendices or companion documents. However, the primary CP/CPS should continue to function as the central document describing the CA operator's implementation commitments.

May implementation commitments be presented using tables instead of narrative text?

Yes. Mozilla encourages formats that improve clarity and reduce unnecessary repetition. Tables, matrices, diagrams, flowcharts, and structured specifications may communicate implementation commitments more effectively than lengthy narrative descriptions. The important consideration is whether a technically competent reviewer can understand the CA operator's practices.

Must every RFC 3647 section have the same level of detail?

No. Different sections naturally require different amounts of information. For example, sections describing certificate issuance, validation, revocation, or repository operations will often require substantially more implementation detail than sections that have limited applicability to a particular CA operator. Mozilla does not expect artificial uniformity across all sections.

Should RFC 3647 headings be renamed?

Generally, no (unless modified by the Baseline Requirements). Retaining the standard RFC 3647 headings improves consistency across CA operators and facilitates review. Additional descriptive headings or explanatory text may certainly be added beneath the standard headings.

May a CA operator combine related RFC 3647 subsections?

Where the resulting organization remains clear and reviewers can readily locate the required information, combining closely related material may be appropriate. However, reviewers should still be able to determine that every required RFC 3647 topic has been addressed.

How should references to CA/Browser Forum Requirements fit within the RFC 3647 structure?

The RFC 3647 outline serves as the organizational framework for the documentation. Within that framework, CA operators may incorporate applicable CA/Browser Forum Requirements by reference while describing their own implementation commitments. The MRSP does not require external requirements to be copied into every corresponding RFC 3647 section.

Can one RFC 3647 section reference a companion document?

Yes. A section may appropriately reference companion documentation such as certificate profile specifications, validation procedures, or repository documentation. The referenced document should be clearly identified, publicly accessible where necessary, and its applicability should be apparent to reviewers.

Should every RFC 3647 section describe implementation commitments?

Where implementation commitments exist, yes. One of the principal objectives of MRSP Section 3.3 is to ensure that CP/CPS Documentation explains how the CA operator implements applicable requirements rather than merely restating those requirements. Reviewers should be able to understand the CA operator's operational choices, constraints, and practices wherever they materially affect certificate issuance, validation, revocation, or related activities.

Does Mozilla review compliance based on document structure or content?

Both. Mozilla expects CP/CPS Documentation to follow the RFC 3647 organizational framework while also providing sufficient CA-specific information to allow a technically competent reviewer to understand the CA operator's implementation commitments. A document that follows the RFC 3647 outline but contains little meaningful implementation information may not satisfy the objectives of MRSP Section 3.3. Likewise, documentation containing extensive implementation detail but lacking the required RFC 3647 organization may make review unnecessarily difficult.

What is Mozilla's overall objective regarding RFC 3647?

Mozilla does not view RFC 3647 as merely a formatting requirement. Rather, the RFC provides a common organizational framework that supports consistency, transparency, comparability, and efficient review across the Web PKI. By combining the familiar RFC 3647 structure with sufficiently detailed CA-specific implementation commitments, CA operators can produce documentation that is easier to maintain, easier to review, and more useful to auditors, researchers, relying parties, and other technically competent reviewers.

Mozilla Review and Implementation Guidance

This section is not part of the Frequently Asked Questions. Instead, it summarizes Mozilla's overall approach to reviewing CP/CPS Documentation and offers observations that may assist CA operators as they prepare documentation to comply with MRSP Section 3.3.

These observations are explanatory only. They do not establish additional policy requirements.

Mozilla Reviews Documentation as a Whole

Mozilla reviews CP/CPS Documentation in light of the objectives of MRSP Section 3.3. While Mozilla may use outlines, guidance documents, Annual Self-Assessments, checklists, or other review aids during its evaluation, those tools are intended to assist the review rather than determine its outcome. The ultimate consideration is whether the documentation, viewed as a whole, enables a technically competent reviewer to understand the CA operator's implementation commitments, determine the scope and applicability of the documented practices, and evaluate conformance with applicable requirements.

Documentation Should Describe Implementation, Not Merely Requirements

One of the principal objectives of MRSP Section 3.3 is to encourage documentation that explains how a CA operator implements applicable requirements. Restating external requirements is often less helpful than explaining the operational choices, implementation decisions, constraints, and procedures adopted by the CA operator. Reviewers should finish reading the documentation with a clear understanding of how the CA actually operates.

Think Like a Reviewer

When preparing documentation, CA operators may find it useful to consider questions such as:

• Could a technically competent reviewer understand how this CA operates without contacting us?
• Is it clear which documentation applies to each certificate hierarchy?
• Would an auditor know where to find information about a particular operational practice?
• Can someone determine which implementation commitments were in effect when a certificate was issued?

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

Think Beyond Compliance

CP/CPS Documentation serves purposes beyond demonstrating compliance with external requirements. Well-maintained documentation can also support:

• software development;
• certificate profile development;
• operational consistency;
• quality assurance;
• auditor review;
• incident investigation;
• personnel training;
• organizational knowledge transfer; and
• change management.

Mozilla encourages CA operators to view documentation as an operational asset rather than merely an audit artifact.

Documentation Should Evolve With Operations

Operational practices naturally evolve over time. CP/CPS Documentation should evolve as well. Maintaining accurate documentation is generally easier when updates occur as part of normal operational governance rather than being deferred until the next annual review. Many organizations find it beneficial to include documentation updates as part of their normal change-management process.

Use Documentation to Help Prevent Misissuance

Accurate documentation is not simply evidence of compliance. It can also help reduce operational errors. Certificate profiles, implementation commitments, validation procedures, and applicability mappings provide authoritative references that software developers, compliance personnel, auditors, and operational staff can use to verify that certificates are issued as intended. Well-maintained documentation may therefore reduce the likelihood of certificate misissuance and simplify investigation if an incident does occur.

Clarity Is More Important Than Length

Mozilla does not seek longer documentation. Long documents that are repetitive or difficult to navigate may be less useful than concise documentation that clearly explains implementation commitments. The objective is documentation that is understandable, appropriately organized, reasonably current, and sufficiently detailed for meaningful review.

There Is No Single Correct Documentation Architecture

Mozilla recognizes that CA operators differ significantly in size, organizational structure, operational complexity, certificate offerings, and historical practices. Accordingly, Mozilla does not prescribe a single documentation architecture. Different organizational approaches may all satisfy the objectives of MRSP Section 3.3, provided reviewers can readily understand the CA operator's implementation commitments and determine the applicability of the documentation.

Continuous Improvement

Mozilla expects implementation experience to continue informing both this guidance and the CP/CPS Documentation maintained by CA operators. As common implementation questions arise, Mozilla may publish additional examples, FAQs, explanatory material, or implementation guidance to promote consistent interpretation of the MRSP and improve the transparency and reviewability of CA documentation.

CA operators are encouraged to share implementation experience, ask questions through established Mozilla Root Program communication channels, and suggest improvements that may benefit the Web PKI community as a whole.