All,
Thanks for your responses thus far. We agree about the need to ensure that our messaging around timely revocation remains clear and unambiguous. In response to your comments, we might want to develop and adopt a graduated list of proportionate penalties that CA operators will face in response to delayed revocation (rather than imposing across-the-board requirements on all CAs). This approach will not only be more effective, but also will provide CA operators with clear expectations about the consequences of delayed revocation. A structured list of enforcement measures would create a strong incentive for CAs to adhere to revocation timelines. A "menu of measures" could graduate from minor, first-time incidents to more stringent measures for repeated or egregious violations. I invite the community to revisit and review all previously suggested measures, suggest new ones, and advise us about this idea of adopting a structured, ordered list of sanctions for CAs that delay revocation. I look forward to your additional comments and suggestions. Thanks again, Ben On Thursday, January 9, 2025 at 2:45:36 AM UTC-7 [email protected] wrote: > [Posting in a personal capacity, per > https://wiki.mozilla.org/CA/Policy_Participants] > Ben wrote: > > 1. “Mozilla does not grant exceptions…” -- this is the most important > signal that Mozilla can provide. > I feel compelled to express the view that Mozilla should not provide > any guidance beyond this “Mozilla does not grant exceptions” statement. In > other words, I think that the non-policy language at > *https://wiki.mozilla.org/CA/Responding_To_An_Incident#Revocation > <https://wiki.mozilla.org/CA/Responding_To_An_Incident#Revocation>* should > be *completely removed*. Not updated, not improved, and certainly not > incorporated into the MRSP in some way. Completely Removed. > I have formed this opinion somewhat reluctantly and primarily because I've > observed one CA, despite their error being pointed out multiple times by > multiple community members, continually misrepresent the non-policy > language at *https://wiki.mozilla.org/CA/Responding_To_An_Incident#Revocation > <https://wiki.mozilla.org/CA/Responding_To_An_Incident#Revocation>* as > "Mozilla policy". In one comment, that CA made the bogus claim that "the > current Mozilla policy has language that allows for delayed revocation" > <https://bugzilla.mozilla.org/show_bug.cgi?id=1910805#c37>. Despite now > recognizing that delayed revocation "violates the Mozilla policy based on > the fact that Mozilla states that CAs are expected to comply with the BRs" > <https://bugzilla.mozilla.org/show_bug.cgi?id=1910805#c49>, that CA seems > to want to bury that uncomfortable truth of the "most important signal" > beneath Issue #276 <https://github.com/mozilla/pkipolicy/issues/276>, > writing "We continue to appreciate Ben's efforts to lead a productive > discussion on potential policy changes in this area, and would prefer that > people spend their efforts on moving such discussions forward" > <https://bugzilla.mozilla.org/show_bug.cgi?id=1910805#c49>. > Furthermore, by my count there were 30 "leaf-revocation-delay" bugs opened > against 20 CA Owners during 2024. My recollection is that most of these > revocations were delayed by choice rather than by accident. I wonder how > many of these CAs have misinterpreted > *https://wiki.mozilla.org/CA/Responding_To_An_Incident#Revocation > <https://wiki.mozilla.org/CA/Responding_To_An_Incident#Revocation>* as a > "get out of jail free card", despite the already clear assertion on that > wiki page that "Mozilla does not grant exceptions to the BR revocation > requirements"? > Based on events so far, my conclusion is this: however well intentioned it > might be, the mere existence of any language that attempts to regulate CA > responses to delayed revocation incidents drowns out that "most important > signal" and consequently risks doing more harm than good. IMHO, that risk > can only be mitigated if that language is Completely Removed. > > New CA Obligations: > > - Maintain and test mass revocation plans annually, including the > revocation of 30 randomly chosen certificates within a 5-day period. > Please note that there are CAs that do correctly understand that "Mozilla > does not grant exceptions" and that do always strive to adhere to the > mandatory BR revocation deadlines. Why should these rule-abiding CAs and > their subscribers be burdened with this proposed random revocation > requirement? This seems unfair, in my view. > Martijn asked if it would be "fairer to only impose this random > revocation requirement on those CAs that have actually had delayed > revocation incidents" > <https://www.mail-archive.com/[email protected]/msg01951.html>. > I think that this would not only be fairer but might also act as a > deterrent against CAs delaying revocations in the first place! > > ------------------------------ > *From:* 'Ben Wilson' via [email protected] < > [email protected]> > *Sent:* 18 December 2024 17:17 > *To:* [email protected] <[email protected]> > > *Subject:* Re: MRSP 3.0: Issue #276: Delayed Revocation > > This Message Is From an External Sender > This message came from outside your organization. > Report Suspicious > <https://us-phishalarm-ewt.proofpoint.com/EWT/v1/J5K_pWsD!CSYXMG01XQA4y_OqOfidY0g7uunnGU1GkQaJ8UyhVOg36f0VpEc-cVC8HebmxOMdCrBj9Uh_vQhJZ37JwDQygxNn39p3XsETIQ$> > > > All, > > As part of the discussions on this proposal, namely that CAs “maintain and > test mass revocation plans annually, including the revocation of 30 > randomly chosen certificates within a 5-day period,” I’ve received a few > comments via private channels, and to ensure transparency and foster > discussion, I am sharing them here anonymously: > > 1. “Mozilla does not grant exceptions…” -- this is the most important > signal that Mozilla can provide. > > 2. If certificate consumers want to prohibit delayed revocation, then they > need to make it clear to CAs that they won't accept it and that they will > kick them out of the root stores if they still do it. Don't try to solve > this issue with indirect measures like random revocations. Just be straight > about it and make it clear that there will be consequences for the very > first delayed revocation and onward. > > 3. We will face big problems in revoking productive customer certificates > just to test our mass-revocation plan and procedures. Our current customer > contracts do not foresee this. While we can revoke at any time for security > or compliance reasons, this authorization should not be used just to test > mass-revocation. This will also require us to push out contract changes to > our complete TLS customer base, which will take a considerable amount of > time and effort. > > 4. This part of the proposal should occur within the CA/Browser Forum > through amendments to the TLS Baseline Requirements, and not via Mozilla > Root Store Policy. > > 5. Why was the number 30 chosen as a sample? Some CA operators issue very > few certificates, while some CAs issue millions of certificates. > > I welcome your feedback on these points, the random sampling proposal, and > any others. > > Thanks, > > Ben > On Monday, December 16, 2024 at 3:02:35 AM UTC-7 [email protected] wrote: > > Hi Ben, > About " annual plan testing by revoking 30 randomly chosen certificates > within a 5-day timeframe; and"... > We understand that this mean that a CA will need to randomly revoke 30 > certificates that most likely don't have other reason for being revoked > than being randomly chosen and customers will just need to "happily" accept > the situation... Harsh, but doable... > > About "audit report submitted under section 3.1 SHALL include an > attestation that the CA operator has met these mass revocation planning > requirements", it must be considered that the attestation letters of > Webtrust audit reports have a fixed format, so such addition would be added > most likely as a "Other matters" section, that audits can take each > differently. > > My question here would be if you think it's there any chance that these > requirements become part of the TLS BRs instead of the Mozilla Policy, I > see several benefits here: > - Checking the mass-revocation plan would be integral part of the audit > scope, so auditors don't need to figure out how to include it in the > reports... it just needs to be added to the audit criteria. > - The "inverse-lottery" thing could be added in the revocation timelines > of the BR, so there's an entry in the 5-day deadline adding a new category > "The certificate has been randomly chosen for revocation during an internal > audit". This should facilitate the contractual language to add in the > subscriber agreement. > > El domingo, 15 de diciembre de 2024 a las 21:51:43 UTC+1, Ben Wilson > escribió: > > All, > > The purpose of this email is to start discussion of Mozilla GitHub Issue > #276 > <https://urldefense.com/v3/__https://github.com/mozilla/pkipolicy/issues/276__;!!J5K_pWsD!06eCiH-z9p5yhGa9Bgvk0E4usFSOxLD34_mw2rgfrCsDCHV0wNZcjxMPgPRh3Gcm9DLRYYkoCu9Iqrz2PhIAWoJh9g$> > ("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://urldefense.com/v3/__https://wiki.mozilla.org/CA/Responding_To_An_Incident*Revocation__;Iw!!J5K_pWsD!06eCiH-z9p5yhGa9Bgvk0E4usFSOxLD34_mw2rgfrCsDCHV0wNZcjxMPgPRh3Gcm9DLRYYkoCu9Iqrz2PhKQ7b-mrQ$> > . > > 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 > > <https://urldefense.com/v3/__https://github.com/mozilla/pkipolicy/compare/51b2f702accd54cb70d52081a9e814298433495b**Befa8ac40ac341fb813620938ef72328a53858038__;4oCm!!J5K_pWsD!06eCiH-z9p5yhGa9Bgvk0E4usFSOxLD34_mw2rgfrCsDCHV0wNZcjxMPgPRh3Gcm9DLRYYkoCu9Iqrz2PhJ_T6DLbA$>* > > *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://urldefense.com/v3/__https://github.com/mozilla/www.ccadb.org/pull/187__;!!J5K_pWsD!06eCiH-z9p5yhGa9Bgvk0E4usFSOxLD34_mw2rgfrCsDCHV0wNZcjxMPgPRh3Gcm9DLRYYkoCu9Iqrz2PhLuTONaHw$> > ) > - 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://urldefense.com/v3/__https://groups.google.com/a/mozilla.org/g/dev-security-policy/c/hXr43W3c4Gs/m/J1OAktIaAwAJ__;!!J5K_pWsD!06eCiH-z9p5yhGa9Bgvk0E4usFSOxLD34_mw2rgfrCsDCHV0wNZcjxMPgPRh3Gcm9DLRYYkoCu9Iqrz2PhLzvBpyuQ$>*. > > 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 > <https://urldefense.com/v3/__https://github.com/cabforum/servercert/pull/553__;!!J5K_pWsD!06eCiH-z9p5yhGa9Bgvk0E4usFSOxLD34_mw2rgfrCsDCHV0wNZcjxMPgPRh3Gcm9DLRYYkoCu9Iqrz2PhLDbgvh4g$> > . > > 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/71b07640-d425-4f2f-8da4-d97a9475b9f6n%40mozilla.org > > <https://urldefense.com/v3/__https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/71b07640-d425-4f2f-8da4-d97a9475b9f6n*40mozilla.org?utm_medium=email&utm_source=footer__;JQ!!J5K_pWsD!06eCiH-z9p5yhGa9Bgvk0E4usFSOxLD34_mw2rgfrCsDCHV0wNZcjxMPgPRh3Gcm9DLRYYkoCu9Iqrz2PhLC_gsh3A$> > . > -- 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/6e8eb5aa-85eb-405d-9134-f3d9d770faafn%40mozilla.org.
