All, The purpose of this email is to start discussion of Mozilla GitHub Issue #276 <https://github.com/mozilla/pkipolicy/issues/276> ("Address Delayed Revocation"). We would like to collect comments and feedback on a proposal to address delayed certificate revocation from a Mozilla perspective. It builds on prior discussions and feedback regarding delayed revocation, and the proposal is meant to replace guidance currently provided on the Mozilla CA wiki <https://wiki.mozilla.org/CA/Responding_To_An_Incident#Revocation>.
Here is the comparison link for a proposed new section 6.1.3 in the MRSP: https://github.com/mozilla/pkipolicy/compare/51b2f702accd54cb70d52081a9e814298433495b%E2%80%A6efa8ac40ac341fb813620938ef72328a53858038 *Summary* Here are the highlights of the proposal: - Revocation must occur promptly in compliance with the timelines set in section 4.9.1 of the TLS Baseline Requirements (TLS BRs). Mozilla does not grant exceptions to these timelines. - New CA Obligations: - Educate subscribers on revocation timelines and discourage reliance on certificates in systems that cannot tolerate timely revocation. - Include contractual language requiring subscriber cooperation with revocation timelines. - Maintain and test mass revocation plans annually, including the revocation of 30 randomly chosen certificates within a 5-day period. - Beginning April 15, 2026, CA audit reports must attest to compliance with the mass revocation planning requirements. - Delayed revocation incidents must be reported per version 2.1 of the CCADB's Incident Reporting Guidelines (as currently proposed <https://github.com/mozilla/www.ccadb.org/pull/187>) - Repeated delayed revocation incidents will result in heightened scrutiny or sanctions, which may include root removal. *Background* Earlier this year, on this list, I proposed an Interim Policy to Address Delayed Revocation <https://groups.google.com/a/mozilla.org/g/dev-security-policy/c/hXr43W3c4Gs/m/J1OAktIaAwAJ>. While the proposed interim policy provided clarity, it faced criticism regarding implementation complexity, burden on subscribers and CAs, and the feasibility of associated measures, such as transitioning delayed revocation domains to 90-day certificates. Also, there were subsequent proposals aimed at reducing certificate lifetimes and encouraging automation. See e.g. https://github.com/cabforum/servercert/pull/553. This new proposal drops proposed measures such as domain-specific tracking and subscriber attestations and instead focuses on subscriber education, mass revocation preparedness, and robust incident reporting as the primary mechanisms for improving agility and transparency regarding delayed revocation. If adopted, the proposed MRSP § 6.1.3 would replace the current guidance on delayed revocation in Mozilla’s wiki and ensure consistency with the CCADB's Incident Reporting Guidelines. I welcome your feedback on this draft proposal. Please share your thoughts, questions, or concerns to help us refine and improve it further. Thanks, Ben Wilson Mozilla Root Store -- 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%2B1gtaYD-3KxULSHxsFcc%3Dn95x0C0Ycbj_y%2BVSJwT5HLQ8VYGw%40mail.gmail.com.
