Perhaps it would be better to look at each delayed revocation bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1945389 - No comments so far https://bugzilla.mozilla.org/show_bug.cgi?id=1943528 - Entrust was distrusted so no need to keep it open https://bugzilla.mozilla.org/show_bug.cgi?id=1942879 - Issue identified and the delay was unintentional https://bugzilla.mozilla.org/show_bug.cgi?id=1942877 - Issued identified and delay was unintentional https://bugzilla.mozilla.org/show_bug.cgi?id=1922572 - No comments after KIRs explanation https://bugzilla.mozilla.org/show_bug.cgi?id=1916478 - Delay appears unintentional and was an operational issue https://bugzilla.mozilla.org/show_bug.cgi?id=1910805 - Delay was explained in more detail than other bugs https://bugzilla.mozilla.org/show_bug.cgi?id=1903066 - Comment 6 acknowledges the delay was wrong https://bugzilla.mozilla.org/show_bug.cgi?id=1898848 - Entrust is distrusted https://bugzilla.mozilla.org/show_bug.cgi?id=1898848 - Acknowleded that it was a mistake to delay yet Tim keeps pushing https://bugzilla.mozilla.org/show_bug.cgi?id=1891331 - Netlock talks about the EU difficulties in revocation https://bugzilla.mozilla.org/show_bug.cgi?id=1889062 - Acknowledges that it was against the BRs to delay https://bugzilla.mozilla.org/show_bug.cgi?id=1888882 - Comment 28 pretty much states that will ensure awareness of teh 5 day requirement https://bugzilla.mozilla.org/show_bug.cgi?id=1887888 - This one never answered the question of what they will do going forward. https://bugzilla.mozilla.org/show_bug.cgi?id=1887110 - Acknowledges it was a violation https://bugzilla.mozilla.org/show_bug.cgi?id=1886665 - States that htey will not delay revocation https://bugzilla.mozilla.org/show_bug.cgi?id=1886532 - Entrust was distrusted https://bugzilla.mozilla.org/show_bug.cgi?id=1885568 - Remediation provided https://bugzilla.mozilla.org/show_bug.cgi?id=1872738 - Remediation provided
Given the bugs, the lengthy discussion on the bugs, and the revised language in the Mozilla revocation expectation document, what is the value to the community in keeping these open? The value to Sectigo and the Sectigo podcast is pretty obvious, but why would Mozilla or the Mozilla community want to keep going on these items? If there is a clear ask on what should be done, what is it? If we want each CA to say "We will never delay revocation" again, we could say that must be stated in the closing. As that is expressly not stated as a requirement, I'm baffled on what more most of the bugs need before closing. On Thu, Feb 6, 2025 at 2:32 PM Jeremy Rowley <[email protected]> wrote: > I disagree. I think the language was unclear before, and, based on my > previous work. I think the public language did lead to confusion on what > circumstances delayed revocation could occur, but I have not seen anyone > state that the delay was in compliance with the BRs. This seems like a > misrepresentation of most of the CAs, and a misrepresentation that is > particular sus given that it is coming from a competitor to the other CAs. > I think you should close the current bugs given that the language has > changed, even if the expectations around delayed revocation remain > constant. > > Keeping a bug open just to make a CA look bad for Sectigo seems like an > improper purpose for having a bug reporting mechanism. Isn't the purpose to > learn why it happened and rectify the issue? Seems like this has happened > on all of the bugs I've seen and Mozilla policy has become better for it. > > > > On Thu, Feb 6, 2025 at 2:18 PM Tim Callan <[email protected]> wrote: > >> Ben, >> >> You may see from my recent posts on a few of these individual bugs that >> at least some of these incidents in my opinion aren’t ready to close. >> There has been and continues to be a problem with CAs failing to recognize >> that BR-mandated revocation deadlines are not theirs to take or leave, and >> we still have CAs, sometimes nearly a year later, who have not acknowledged >> this fact nor taken steps to fix their errors. I appreciate your response >> to one of my recent posts in which you say that a hard commitment to never >> delay revocation is too much. Though I do not agree, I understand your >> viewpoint and am taking your guidance. >> >> That said, my recollection is that some of these CAs have simply never >> publicly accepted any culpability nor made an earnest show of changing >> their priorities. I put it to you that a CA who refuses to accept >> responsibility for its free choice to ignore the BRs and has no expressed >> intention to change its decision making has not remediated the problem. I >> believe such a bug should remain open until the message sinks in. >> >> If you concur on this last point, then I request you leave these bugs >> open just a little longer so the community has a chance to review them and >> weigh in on which are ready to close and which are not. I don’t imagine >> this requires a great deal of time, but I don’t see it getting done by >> tomorrow either. >> >> Cheers, >> >> -tlc >> >> On Sunday, February 2, 2025 at 2:25:39 PM UTC-5 Ben Wilson wrote: >> >>> All, >>> >>> I am considering closing the following delayed revocation Bugzilla >>> incidents later this week (Friday, 7-Feb-2025), as listed in meta Bug >>> 1911183 <https://bugzilla.mozilla.org/show_bug.cgi?id=1911183>: >>> >>> 1872738 <https://bugzilla.mozilla.org/show_bug.cgi?id=1872738>, 1877388 >>> <https://bugzilla.mozilla.org/show_bug.cgi?id=1877388>, 1884568 >>> <https://bugzilla.mozilla.org/show_bug.cgi?id=1884568>, 1885568 >>> <https://bugzilla.mozilla.org/show_bug.cgi?id=1885568>, 1886110 >>> <https://bugzilla.mozilla.org/show_bug.cgi?id=1886110>, 1886532 >>> <https://bugzilla.mozilla.org/show_bug.cgi?id=1886532>, 1886665 >>> <https://bugzilla.mozilla.org/show_bug.cgi?id=1886665>, 1887110 >>> <https://bugzilla.mozilla.org/show_bug.cgi?id=1887110>, 1887888 >>> <https://bugzilla.mozilla.org/show_bug.cgi?id=1887888>, 1888882 >>> <https://bugzilla.mozilla.org/show_bug.cgi?id=1888882>, 1889062 >>> <https://bugzilla.mozilla.org/show_bug.cgi?id=1889062>, 1890685 >>> <https://bugzilla.mozilla.org/show_bug.cgi?id=1890685>, 1891331 >>> <https://bugzilla.mozilla.org/show_bug.cgi?id=1891331>, 1892419 >>> <https://bugzilla.mozilla.org/show_bug.cgi?id=1892419>, 1896053 >>> <https://bugzilla.mozilla.org/show_bug.cgi?id=1896053>, 1896553 >>> <https://bugzilla.mozilla.org/show_bug.cgi?id=1896553>, 1898848 >>> <https://bugzilla.mozilla.org/show_bug.cgi?id=1898848>, 1903066 >>> <https://bugzilla.mozilla.org/show_bug.cgi?id=1903066>, 1910805 >>> <https://bugzilla.mozilla.org/show_bug.cgi?id=1910805>, 1916478 >>> <https://bugzilla.mozilla.org/show_bug.cgi?id=1916478>, and 1924385 >>> <https://bugzilla.mozilla.org/show_bug.cgi?id=1924385>, >>> >>> *provided that the CA operator has completed its stated Action Items and >>> filed a Closure Summary*. >>> >>> My reasoning is as follows: >>> >>> I kept these bugs open while we navigated towards a solution for >>> handling delayed revocations going forward. I believe that the new language >>> in Mozilla Root Store Policy (MRSP) 3.0, effective March 1, 2025, >>> introduces significant measures to improve compliance with revocation >>> requirements and enhance delayed revocation incident reporting. >>> >>> Under MRSP section 6.1.3, CA operators will be explicitly required to >>> engage in proactive subscriber communication, more specific contractual >>> provisions, and mass revocation preparedness to ensure timely certificate >>> revocation. Additionally, CAs must undergo third-party assessments to >>> validate their readiness for large-scale revocations and that they have >>> documented the outcomes of the testing of their mass revocation plans. >>> >>> MRSP section 2.4 incorporates the updated incident reporting >>> requirements of the CCADB, and mandates that CAs provide detailed and >>> substantiated justifications in incident reports, explaining delays and >>> impacts on third parties. It notes that Mozilla does not have any >>> exceptions for delayed revocation, and that repeated unjustified delays >>> will result in heightened scrutiny and potential removal from the Mozilla >>> Root Store. >>> >>> Also, MRSP section 7.1 will require that new TLS-issuing root >>> certificates have at least the ability for automated domain control >>> validation, certificate issuance, and retrieval. This ensures that >>> certificate management processes are efficient, scalable, and less prone to >>> human error, aligning with modern security best practices. >>> >>> CAs and stakeholders should recognize these changes only as first, yet >>> important, steps in addressing delayed revocation and reporting. >>> >>> Thoughts? >>> >>> Thanks, >>> >>> Ben >>> >>> -- >> 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/16701b3c-e0f1-4bfe-9123-79d2273cc4b9n%40mozilla.org >> <https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/16701b3c-e0f1-4bfe-9123-79d2273cc4b9n%40mozilla.org?utm_medium=email&utm_source=footer> >> . >> > -- 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/CAFK%3DoS852rUODe%3Dis%2BQnsA12dUyqAuq%2BNFtdbJAv0Q2xZysa0g%40mail.gmail.com.
