CA/Responding To An Incident: Difference between revisions

CA operators MUST revoke misissued or otherwise problematic TLS server certificates within 24 hours or 5 days, depending on the circumstances set forth in [https://cabforum.org/working-groups/server/baseline-requirements/requirements/#491-circumstances-for-revocation section 4.9.1] of the CA/Browser Forum’s TLS Baseline Requirements (TLS BRs). Mozilla does not grant exceptions to the revocation requirements of the TLS BRs.  

To ensure compliance with the TLS BRs, Mozilla requires that CA operators:

* engage in proactive communication and advise subscribers well in advance about the revocation timelines and explicitly warn them against using publicly-trusted TLS server certificates on systems that cannot tolerate timely revocation;

* include appropriate language in customer agreements requiring subscribers’ timely cooperation in meeting revocation timelines and acknowledging the CA’s obligations to adhere to applicable policies and standards;

* prepare and maintain credible plans to address mass revocation events, including detailed procedures for handling mass revocations effectively, including rapid communication with affected parties and conducting annual plan testing; and

* engage a third party assessor to evaluate whether the CA Operator has:

** credible plans to handle mass revocation events; 

** tested the operational effectiveness of the plans, including the accuracy and adequacy of documentation of plan testing, including timelines, results, and remediation steps; and 

** incorporated feedback from such exercises to improve future readiness.

The [https://www.ccadb.org/cas/incident-report CCADB incident reporting process] ensures the Web PKI community is informed and that issues are tracked and resolved effectively. Clear and timely communication fosters trust and accountability, mitigating risks to the ecosystem.

If a CA operator determines that it might delay revocation of certificates beyond the time period required by the TLS BRs, it MUST file a preliminary incident report with a Summary section immediately in Bugzilla, even if the delay has not yet occurred.

 

 

* the number of certificates that have been revoked; 

* the number of certificates planned for revocation that have expired; and

 

Consistent with CCADB incident reporting requirements, in the “Analysis” section, the CA operator SHALL explain in the Analysis section of the incident report those factors and rationales behind the decision to delay revocation (including detailed and substantiated explanations of how extensive harm would result to third parties–such as essential public services or widely relied-upon systems–and why the situation is exceptionally rare and unavoidable).

 

Also, the Timeline section should include the time(s) at which the CA Operator actually completed revocation of affected certificates, and the Action Items list MUST include steps reasonably calculated to prevent or reduce future revocation delays.

 

 

Failing to meet the standards of timely revocation erodes trust in the Web PKI and poses risks to global internet security.  Delayed revocation is a measure of last resort and MUST NOT be used routinely.  Repeated incidents of delayed revocation without sufficient justification will result in heightened scrutiny and sanctions, including removal of the CA from the Mozilla Root Store. CA operators must also adhere to the policies and revocation requirements of other Root Store Programs that include their CA certificates.  Additionally, all delayed revocation incidents MUST be listed as findings in the CA operator’s next TLS BR audit statement.