> Delayed revocation is a measure of last resort and MUST not be used routinely.
Hi Ben. One nit: That "not" should be capitalized. ________________________________ From: 'Ben Wilson' via [email protected] <[email protected]> Sent: 13 January 2025 17:00 To: [email protected] <[email protected]> Subject: Re: MRSP 3.0: Issue #276: Delayed Revocation All, It has been recommended that Mozilla replace its wiki page on delayed revocation incident reporting. Here is a draft for your review and comment. Ben URL: https: //wiki. mozilla. org/CA/Responding_To_An_Incident#Revocation Goals: Mozilla’s All, It has been recommended that Mozilla replace its wiki page on delayed revocation incident reporting. Here is a draft for your review and comment. Ben URL: https://wiki.mozilla.org/CA/Responding_To_An_Incident#Revocation<https://urldefense.com/v3/__https://wiki.mozilla.org/CA/Responding_To_An_Incident*Revocation__;Iw!!J5K_pWsD!w0cRRnDtbjC3g_ZEH3BY2O71Hym6p7KAodvveMc4cdDTkDwbb5rmvRRhS3-k8T6KigRjWDS5855ZjhHPST8fRcbOYw$> Goals: Mozilla’s goals are: to ensure that revocation occurs as swiftly as possible while maintaining the overall security and stability of the web; to reduce delayed revocation incidents to the greatest extent possible; to improve delayed revocation incident reports; and to gather better information on those cases where delayed revocation occurs. Date to Go Live: January 17, 2025 Revocation Mozilla’s Expectations on Revocation CA operators MUST revoke misissued or otherwise problematic TLS server certificates within 24 hours or 5 days, depending on the circumstances set forth in section 4.9.1<https://urldefense.com/v3/__https://cabforum.org/working-groups/server/baseline-requirements/requirements/*491-circumstances-for-revocation__;Iw!!J5K_pWsD!w0cRRnDtbjC3g_ZEH3BY2O71Hym6p7KAodvveMc4cdDTkDwbb5rmvRRhS3-k8T6KigRjWDS5855ZjhHPST-gAzsjGw$> 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. Incident Reporting The CCADB incident reporting process<https://urldefense.com/v3/__https://www.ccadb.org/cas/incident-report__;!!J5K_pWsD!w0cRRnDtbjC3g_ZEH3BY2O71Hym6p7KAodvveMc4cdDTkDwbb5rmvRRhS3-k8T6KigRjWDS5855ZjhHPST89bo_N9g$> 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. Such delayed revocation incident reports SHOULD be updated at least every 3 days and MUST be updated no less frequently than every 7 days to describe a summary of: * the number of certificates that have been revoked; * the number of certificates that have not yet been revoked; * the number of certificates planned for revocation that have expired; and * an estimate for when all remaining revocations will be completed. 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. Consequences of Delayed Revocations 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. On Saturday, January 11, 2025 at 8:04:43 PM UTC-7 Matt Palmer wrote: On Fri, Jan 10, 2025 at 06:21:02PM -0800, Suchan Seo wrote: > Wouldn't fixed 30 certificates per CA cause smaller CA just spam load > genenrate test certificates on production envirement to delude chance to it > actually hit acutal client? It is certainly a possibility. However, that sort of thing leaves extensive evidence (which, I will note, a CA-driven "random" choice protocol does not), and if such evidence was found and brought to light publicly, I expect it would not reflect well on the CA involved. Also, in the protocol I proposed, as Mozilla has full discretion over the the criteria by which certificates are chosen for a revocation test, it does not have to select those certificates entirely at random. It could identify certificates issued for the purposes you describe, and just not include such certificates in the list of those to be revoked. - Matt -- 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]<mailto:[email protected]>. To view this discussion visit https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/fcff6b2b-605c-4cea-8e56-310e1e3edd21n%40mozilla.org<https://urldefense.com/v3/__https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/fcff6b2b-605c-4cea-8e56-310e1e3edd21n*40mozilla.org?utm_medium=email&utm_source=footer__;JQ!!J5K_pWsD!w0cRRnDtbjC3g_ZEH3BY2O71Hym6p7KAodvveMc4cdDTkDwbb5rmvRRhS3-k8T6KigRjWDS5855ZjhHPST-9dRKW0A$>. -- 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/MW4PR17MB47297F0EF2ADF73EE5E6ED72AA1F2%40MW4PR17MB4729.namprd17.prod.outlook.com.
