Here is a non-normative template based on requests from CAs for guidance on
the upcoming MRSP section 6.1.3. requirement that CAs maintain and test a
mass revocation plan. The following is informational and illustrative only,
and provided here for discussion and suggestions on its improvement. I
also uploaded it to GitHub as a mark-down document here:
https://github.com/BenWilson-Mozilla/pkipolicy/blob/mass-revocation-plan-template/rootstore/Mass-Revocation-Template.md
.
Ben
Certification Authority (CA) Operator
Mass Revocation Incident Preparation and Testing Plan (MRIP&TP)
Version History
Date
Description of Changes
Version
2025
Original
1.0
------------------------------
CA Operator Contact Information
[Company Name]
[Address]
[Telephone]
[Email]
------------------------------
1. Introduction
The management of [CA Operator] recognizes that the continuity of essential
CA services depends on effective certificate revocation and replacement
processes. These processes are dependent on robust IT infrastructure,
effective customer communication, and rapid response capabilities.
To mitigate risks associated with a Mass Revocation Event (MRE)—which could
cause disruption to customers, financial losses, and damage to
trust—management has authorized the development, implementation, and
maintenance of this Mass Revocation Incident Preparation and Testing Plan
(MRIP&TP).
The MRIP&TP is aligned with [CA Operator] policies, compliance obligations,
and industry best practices. It provides a framework for MRE response,
customer communication, certificate replacement, revocation, and plan
testing in advance of an MRE. This plan also aims to ensure compliance with
industry and root store requirements, such as the CA/Browser Forum TLS
Baseline Requirements and Mozilla Root Store Policy.
2. Mission and Objectives
The mission of this plan is to ensure a well-coordinated, rapid, and
effective response to a Mass Revocation Event while maintaining compliance
and minimizing disruptions.
Plan objectives are to:
-
Define clear roles and responsibilities for the teams assigned with
handling MREs;
-
Identify critical processes and time-sensitive milestones for mass
revocation preparedness;
-
Provide timely, clear communication to customers and other stakeholders
to minimize disruptions to the ecosystem and third parties;
-
Develop and document certificate revocation strategies and procedures to
ensure swift certificate replacement and compliance with revocation
deadlines;
-
Report any delayed revocations to Bugzilla; and
-
Improve readiness through effective training, testing, and continuous
improvement of mass revocation procedures.
3. Scope
This plan applies to the scoping, implementation, execution, review,
training, testing, and improvement of mass revocation processes at [CA
Operator]. It supports compliance with Mozilla Root Store Policy Section
6.1.3 and covers:
-
Maintenance of a well-documented and actionable mass revocation plan;
-
Rapid communication with customer and affected third parties;
-
Certificate replacement strategies;
-
Revocation execution and publication of certificate status;
-
Operational coordination and team responsibilities;
-
Compliance with CA/Browser Forum requirements;
-
Demonstrating implementation and feasibility through annual testing
consisting of simulations, tabletop exercises, or controlled test
environments;
-
Incorporating lessons learned by making plan improvements; and
-
Third-party assessment and external compliance evaluation.
4. Definition and Declaration of an MRE
A Mass Revocation Event (MRE) is defined as:
The revocation of a substantial number of certificates within a relatively
short timeframe due to a common cause, compliance requirement, or security
incident. The impact threshold is based on the CA’s total issuance volume
and operational scale.
A Mass Revocation Event would be triggered, and this plan will be
activated, based on:
-
Absolute Volume Impact – Affects ≥ 100 certificates;
-
Relative Issuance Impact – Affects ≥1% of the CA’s active TLS
certificates;
-
Timeframe Impact – Requires revocation within timeframes set forth in
section 4.9.1.1 of the TLS Baseline Requirements; or
-
Operational Burden – Requires major customer outreach, urgent
operational changes, or compliance reporting;
Or in response to any of the following:
-
Compromise or suspected compromise of a CA private key;
-
Compliance failures affecting a significant number of certificates; or
-
Discovery of a major vulnerability impacting server private keys (e.g.,
HeartBleed).
The Management Team will assess and declare a Mass Revocation Event based
on these criteria.
5. Decision Points and Strategies5.1 Initial Assessment and Activation
Upon identification of a potential MRE, the Management Team will:
1.
Assess the incident’s scope and severity against the defined MRE
criteria;
2.
Issue an internal alert to notify team members of possible activation;
3.
Determine affected certificate population and impacted customers;
4.
Estimate timelines required to perform notification, replacement, and
revocation;
5.
Initiate a conference call to validate findings and coordinate response;
and
6.
Mobilize internal teams and notify external stakeholders as needed.
[Note: If event categorization will help identify different response
strategies, then a section can be inserted here to outline different event
types and the specific response procedures that follow the Response Phases
outlined below.]
5.2 Response Phases
An MRE will be managed in four structured phases:
Phase 1 – Customer Communication
-
Issue early notification to affected customers.
-
Provide guidance on certificate replacement timelines and procedures.
-
Engage technical support teams for high-priority customers.
Phase 2 – Certificate Replacement
[Important Note: Because past delayed revocation incidents have revealed
that certificate replacement is often the most troublesome, complex, and
time-sensitive aspect of a mass revocation event, this section of the plan
must be carefully developed, with detailed procedures that address
automation, customer support, prioritization of critical systems, and
fallback strategies. The CA operator should ensure that this part of the
plan accounts for potential bottlenecks, customer challenges, and any
necessary tooling improvements to facilitate timely replacement and
certificate revocation.]
-
Automate renewal or reissuance where possible.
-
Offer manual assistance for complex cases.
-
Monitor progress and address replacement delays.
Phase 3 – Certificate Revocation
-
Execute mass revocation in compliance with industry timelines.
-
Publish updated CRLs and OCSP responses within expected timeframes.
-
Report delayed revocations if necessary.
Phase 4 – Post-Mortem and Improvement
-
Conduct an internal review of response effectiveness.
-
Document lessons learned and areas for improvement.
-
Update MRIP&TP based on findings.
6. Response Team Organization and Responsibilities
Effective execution of this plan depends on clear team roles.
6.1 Organizational Chart
Team and Team Leader
Role
Responsibilities
Management Team -
[Name]
Senior Leadership
Approves, monitors, and authorizes mass revocation responses.
Customer Relations Team - [Name]
Public Relations and Support
Communicates with customers and handles inquiries.
Certificate Replacement Team - [Name]
Validation and Technical Support
Assists customers with certificate replacement.
Certificate Revocation Team - [Name]
Compliance and Operations
Executes revocation and publishes status updates.
External Communications - [Name]
Legal and Policy
Notifies root stores, regulators, and stakeholders.
Compliance and Legal Teams - [Name]
Risk and Governance
Ensures adherence to legal and compliance obligations.
7. Plan Training, Testing, and Continuous Improvement7.1 Training and
Awareness
-
All team members must undergo annual training on mass revocation
response procedures.
-
Regular testing exercises will be conducted to evaluate readiness.
7.2 Training Responsibilities
The Plan Owner and Compliance Team are responsible for:
-
Training all relevant CA personnel on MRIP&TP execution and updates.
-
Providing specialized training for the Certificate Revocation, Customer
Relations, and Technical Support Teams.
-
Ensuring that personnel understand their roles in a mass revocation
event.
-
Conducting annual refresher training and testing exercises to maintain
readiness.
7.3 Plan Testing and Simulation
The Plan Owner and Compliance Team are responsible for:
-
Testing the MRIP&TP (through simulations, tabletop exercises, or using
controlled test environments) at least once every 12 months
-
Simulated revocation scenarios to assess:
-
Effectiveness of customer communication.
-
Speed and accuracy of certificate replacement.
-
Efficiency of revocation execution.
-
Team coordination and response times.
7.4 Post-Incident Review
The Plan Owner, in coordination with the Compliance Team, will:
-
Document testing processes, results, and remediation steps.
-
Conduct a post-mortem after every Mass Revocation Event or test.
-
Document findings and use them to update this plan.
7.5 Continuous Improvement and Plan Maintenance
The Plan Owner, in coordination with the Compliance Team, will:
-
Implement plan improvements based on test findings.
-
Update the MRIP&TP as needed based on test results, external audits, and
policy changes.
-
Review governance processes to ensure they align with policy updates.
-
Maintain version control and document significant changes.
-
Ensure the updated plan is distributed to all relevant personnel.
8. Third-Party Assessment
In accordance with Mozilla Root Store Policy Section 6.1.3, CA Operator
will:
-
Engage a third-party assessor annually, beginning with the CA’s next
audit cycle occurring on or after June 1, 2025.
-
Provide documentation to the assessor demonstrating that:
-
The MRIP&TP is well-documented and actionable.
-
Testing exercises have been conducted and properly documented.
-
Feedback from testing has been incorporated into this plan to enhance
revocation readiness.
-
Work with the assessor to address any gaps or findings from the
assessment.
9. Conclusion
This Mass Revocation Incident Preparation and Testing Plan is a critical
component of [CA Operator]’s commitment to operational resilience and
compliance. By ensuring clear roles, effective response strategies, and
continuous improvement, [CA Operator] will uphold trust and security in the
Web PKI ecosystem.
--
You received this message because you are subscribed to the Google Groups
"[email protected]" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To view this discussion visit
https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/CA%2B1gtab4UqhdMrTju34h6teuNUsP7kJjGM1JaF0AECeh8KEt%3Dg%40mail.gmail.com.
