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/CADQzZqsw6yKjg5xW2vcdBWp%3D0ZY%2Bg%3DwMNBqpqHqF7N-Wn8Rozw%40mail.gmail.com.
