To clarify, revocation within the prescribed timeline is a requirement of the BRs for sure, but does Mozilla expect that there will never be a violation of the BR revocation requirement? I don’t think that’s quite as clear given the comments from the browsers. I do agree with Tim that such a commitment should be a requirement though as it absolutely removes an potential future ambiguity.
On Thu, Feb 6, 2025 at 6:35 PM Jeremy Rowley <rowley...@gmail.com> wrote: > 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%3DoS8RN60B6byFJadG1sTosS7%3DboPVHabDvBFJwZbKF1yMqw%40mail.gmail.com.
