Proposal to Close Delayed Revocation Incidents
Ben Wilson
All,
I am considering closing the following delayed revocation Bugzilla incidents later this week (Friday, 7-Feb-2025), as listed in meta Bug 1911183:
1872738, 1877388, 1884568, 1885568, 1886110, 1886532, 1886665, 1887110, 1887888, 1888882, 1889062, 1890685, 1891331, 1892419, 1896053, 1896553, 1898848, 1903066, 1910805, 1916478, and 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
Tim Callan
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
Ben Wilson
Jeremy Rowley
--
You received this message because you are subscribed to the Google Groups "dev-secur...@mozilla.org" group.
To unsubscribe from this group and stop receiving emails from it, send an email to dev-security-po...@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.
Jeremy Rowley
Amir Omidi
> 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
> Keeping a bug open just to make a CA look bad for Sectigo seems like an improper purpose for having a bug reporting mechanism.
Jeremy Rowley
Jeremy Rowley
Mike Shaver
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=1916478 - Delay appears unintentional and was an operational issue
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=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.
The value to Sectigo and the Sectigo podcast is pretty obvious,
Ben Wilson
Jeremy Rowley
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=1916478 - Delay appears unintentional and was an operational issue
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=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.
Tim Callan
I appreciate that this matter already has been discussed and accept Jeremy’s explanation and retraction, and I have no interest in reopening that conversation. Nonetheless, based on this thread it feels to me that we would be wise to articulate our motivations.
About five years ago, Sectigo was in a bad place as a public CA. The company’s commitment to quality of execution, accurate issuance, responsibility to the WebPKI, and continuous improvement was abysmal. This manifested itself in a series of severe errors that should not have occurred accompanied by terrible management of the resulting Bugzilla incidents.
I sincerely believe that had Sectigo continued down that path, our roots would be distrusted today. Fortunately, a few thought leaders inside the company had this epiphany, made their voices heard, and ultimately convinced those around them. This led to clear policy changes inside Sectigo and began a process that in the long term required widespread technical, cultural, procedural, and leadership reform. We forged new (for us at least) philosophies about information, quality control, operational efficiency, certificate morphology, policy governance, internal communication, external communication, automation, and the proper role of humans in our processes. There is pretty much no aspect of our public CA operation that we did not scrutinize and renovate in the past five years. While we don’t think we’re perfect by a long shot, we know beyond doubt that we have come a great distance.
It's been a lengthy, hard journey that has required deep thinking, unflinching self-examination, guts, persistence, and lots of sweat. So we appreciate that it can be difficult for a CA to commit to the kind of improvement that, unfortunately, many of us still clearly need.
Sectigo would like to help. Looking at the behaviors of the WebPKI CA community, we perceive a common tendency for CAs not to understand the importance of self-improvement, or know how to go about it, or even recognize the incredible privilege they have as stewards of public trust. We see CAs treating the short-term and short-sighted desires of their corporate owners and local governments as more important than five-and-a-half billion internet users around the globe. We routinely see CAs placing their Subscribers’ convenience over the good of the WebPKI.
We see these things, and we have chosen to act. We are trying to show CAs that self-improvement not only is possible but is an asset to the strength of your operation. We are trying to spur improvement through encouragement and information sharing and where necessary strong rhetoric. We try to provide concrete coaching while challenging our fellows to become their better selves.
This is a learning process for us. A sad fact is that many CAs appear quite intractable and unreceptive. But we also see wins, instances where some CA will experience an authentic “light bulb” moment or a change of heart. So we know it’s possible to connect in that way. At least on occasion we see the idea of “CAs helping CAs” actually work.
Doubtless we have made and will continue to make errors along the way, as we try to figure out how to be sherpas to other CAs who don’t have the benefit of our last five years’ experience. Surely some will never appreciate it, or value it, or care in any way. Or for that matter improve. But some already have. This makes us think that, however preliminary our efforts and inconsistent the results, there is something here worth pursuing.