I think this statement from Ben makes it clear that the expectation is not that delayed revocation will never happen: https://bugzilla.mozilla.org/show_bug.cgi?id=1877388#c72
You are right that I should not have made the statement alleging that sectigo might have ulterior motives. I apologize for that and retract that statement. I do think think it would be helpful to know which exact bugs Tim is objecting to closing and why? There are a couple that don’t have statements but some of them have been open for a year with non additional action items of note On Thu, Feb 6, 2025 at 6:12 PM Amir Omidi <a...@aaomidi.com> wrote: > > I think the public language did lead to confusion on what circumstances > delayed revocation could occur, > > Did it though? One of the expectations for CAs has been to watch and > monitor Bugzilla. If they had done so, I don't think this confusion would > exist. > > > 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 > > What do you mean that is not a requirement? As far as I know practically > all the root programs and the BRs are clear about this being a requirement. > > > Keeping a bug open just to make a CA look bad for Sectigo seems like an > improper purpose for having a bug reporting mechanism. > > The value to Sectigo and the Sectigo podcast is pretty obvious > > These statements do not belong in this mailing list. > > > On Thu, Feb 6, 2025 at 4:58 PM Jeremy Rowley <rowley...@gmail.com> wrote: > >> 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 <rowley...@gmail.com> 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 <ptimcal...@gmail.com> 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 "dev-security-policy@mozilla.org" group. >>>> To unsubscribe from this group and stop receiving emails from it, send >>>> an email to dev-security-policy+unsubscr...@mozilla.org. >>>> 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 >> "dev-security-policy@mozilla.org" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to dev-security-policy+unsubscr...@mozilla.org. >> > 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 >> <https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/CAFK%3DoS852rUODe%3Dis%2BQnsA12dUyqAuq%2BNFtdbJAv0Q2xZysa0g%40mail.gmail.com?utm_medium=email&utm_source=footer> >> . >> > -- You received this message because you are subscribed to the Google Groups "dev-security-policy@mozilla.org" group. To unsubscribe from this group and stop receiving emails from it, send an email to dev-security-policy+unsubscr...@mozilla.org. To view this discussion visit https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/CAFK%3DoS8BQc77JKgH5MEBmL_%3DbsgLVmb8-vpeY6cgOvUDdbVOyg%40mail.gmail.com.
