All, Today I'll go through all delayed revocation bugs, and starting from the information provided here, begin to triage them for closure. Thanks, Ben
On Fri, Feb 7, 2025 at 8:41 AM Mike Shaver <[email protected]> wrote: > Hi Jeremy, > > I don't agree with your listed reasoning for these bugs all being suitable > for closure, though I do genuinely appreciate you taking the time to > enumerate them like this. Some responses to selected entries below! > > On Thu, Feb 6, 2025 at 4:58 PM Jeremy Rowley <[email protected]> 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 >> > > To me this doesn't mean "there is nothing to do with this bug" but more > likely "in the 5 days since it opened, nobody has bothered to ask anything > ahead of the full incident report". These days I'm trying to focus my > limited root-meddling time on inadequate action items, so I generally don't > bother with preliminary incident reports because I would have to guess what > the flaws in the future action items would be. > > >> 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> >> > > The purpose of a delayed revocation incident is not only to provide root > programs with visibility into the practices and reliability of CAs. It is > also to ensure that all (ahem, remaining) CAs have the opportunity to learn > from the incident such that they might avoid a similar incident in the > future. Entrust being distrusted does not necessarily mean that there is no > value in further discussion of the incident, and indeed I think generally > many incidents are pretty poorly reasoned and explained in those matters. > > >> https://bugzilla.mozilla.org/show_bug.cgi?id=1942879 - Issue identified >> and the delay was unintentional >> > > Note that in this case the issue was "malware filtering blocked CPR", > which was sufficiently distinct from "spam filter blocked CPR" that > multiple CAs did not extrapolate from the latter to the former when > monitoring previous incidents. This makes me feel that perhaps more > attention could be paid by the root programs to explaining how they expect > CAs to address classes of issue, rather than just the most > narrowly-interpreted case specifically implicated in an incident. Closing > the bug ahead of that clarity coming from root programs or, failing that, > peer CAs or other community members, seems like a missed opportunity to > avoid future incidents like "we block things that have a non-ASCII sender > name" or whatever the next fine speciation would be. > > >> https://bugzilla.mozilla.org/show_bug.cgi?id=1916478 - Delay appears >> unintentional and was an operational issue >> > > This is a great example of where the work hasn't been done to make the > incident useful for other CAs. It contains the old canards about "improving > procedures" and "training staff", but doesn't detail exactly what was wrong > with the previous policies or training, or—more importantly—what caused the > training or policies to have those defects in the first place. Without > that, all a CA can take away is "have procedures and train staff" which, I > still permit myself to hope, they all understand at that level of detail > already. > > >> https://bugzilla.mozilla.org/show_bug.cgi?id=1898848 - Acknowleded that >> it was a mistake to delay yet Tim keeps pushing >> > > I don't see Tim continuing to push in this bug at all. The last comment > was some time ago, and the discussion seems to mostly have been between > Entrust representatives and Wayne. > > >> https://bugzilla.mozilla.org/show_bug.cgi?id=1889062 - Acknowledges that >> it was against the BRs to delay >> > > This one is definitely not done, given that the subscriber rationale was > given as "these agencies take too long to replace stuff and they're very > important in some way", and there was nothing specific in the action items > or otherwise to indicate how GDCA will navigate that tension in the future > other than "encouragement" or "make a policy (of unspecified contents)". > > >> https://bugzilla.mozilla.org/show_bug.cgi?id=1888882 - Comment 28 pretty >> much states that will ensure awareness of teh 5 day requirement >> > > Yep, for sure *this* time, "customer education" will be sufficient. :P > "When users apply for or obtain certificates, they will be clearly informed > of the revocation scenarios and time limits" is the sort of thing that's > hard for me to take seriously when the BRs already required that the > Subscriber make a legally binding commitment to that effect. > > Also, that report describes an action item (maybe? a commitment at least) > that was to be completed a month ago, and for which no status has been > given: > > > This action plan will take a long time, but we will still accelerate the > progress to encourage as many of our existing customers with larger > certificate volumes to use the automated certificate deployment system as > much as possible by 2025. > > Unless the goal is just to complete the *encouragement* by 2025, in which > case it's a nothing-burger again. > > https://bugzilla.mozilla.org/show_bug.cgi?id=1887888 - This one never >> answered the question of what they will do going forward. >> > > Indeed. Seems like closing in that situation would send an unfortunate > message that you can just wait it out and the awkward questions will go > away. > > >> The value to Sectigo and the Sectigo podcast is pretty obvious, >> > > This is bullshit, unwelcome on the list, and quite surprising. I know you > apologized but I still can't let it just go by when I'm replying to the > message. > > Mike > > -- 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%2B1gtaYK9nt3T69yxVXrEefOEyyJJ8SheoX%3D7d3V3aN_4-kyyA%40mail.gmail.com.
