All, I have posted a replacement wiki page and created a GitHub commit to address this issue.
https://wiki.mozilla.org/CA/Responding_To_An_Incident#Revocation https://github.com/BenWilson-Mozilla/pkipolicy/commit/76d7e31f00581c6b9cad38b08e125932b8b2828e Please let me know of any comments or suggestions. Thanks, Ben On Monday, January 13, 2025 at 11:31:36 AM UTC-7 [email protected] wrote: > > 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]. > 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/900a8d21-21ef-433a-ba95-4402a59f1e28n%40mozilla.org.
