1950144 - DigiCert: Threat of legal action to stifle Bugzilla discourse

Status: RESOLVED FIXED

(CA Program :: CA Certificate Root Program, task)

Description

[Brian Holland]

Attachment: 2024-11-11 DigiCert Letter to Sectigo.pdf

In bug 1910322 comment 74 DigiCert wrote,

“We have not used a legal team as a shield against accountability.”

Contrary to this statement, I received a letter from DigiCert’s lawyers, Wilson Sonsini, regarding posts made by Sectigo’s Chief Compliance Officer in bug 1910322. The upshot of the letter was that DigiCert expected Sectigo to “ensure that Mr. Callan’s statements do not continue and will not be repeated by any other member of Sectigo’s organization.”

I’m Brian Holland, General Counsel for Sectigo, and this is my first time posting on Bugzilla. I’m posting because at Sectigo we believe that the WebPKI is best served by open, transparent, and honest debate about issues that impact our community. Attempts to shut down these conversations, through lawyers or otherwise, are harmful to our collective core mission.

In its opening passages, this letter reads (emphasis mine),

We ask for your prompt cooperation and assistance in taking corrective action and forcing Mr. Callan to cease his disparaging public statements. We hope your assistance in this matter will render unnecessary legal action by DigiCert against Sectigo.

After three pages of detail about specific Bugzilla posts and references to the Lanham Act, deceptive trade practices, corporate disparagement, and tortious interference, the letter (the full letter is included as an attachment to this bug) goes on to say (emphasis mine):

At this point, we are bringing this situation to your attention on behalf of DigiCert because we are hopeful that Mr. Callan’s actions were the actions of one individual and were not part of an organized plan or institutional practice. We also hope that, upon receiving this information, Sectigo will recognize the impropriety of Mr. Callan’s statements and the substantial public, industry, and browser scrutiny and legal risk such statements would prompt if they were to continue. To that end, we expect that Sectigo will investigate this incident promptly and take the appropriate corrective actions, confirm that this situation was not part of an institutional practice, and ensure that Mr. Callan’s statements do not continue and will not be repeated by any other member of Sectigo’s organization. We hope we can resolve this situation as soon as possible before DigiCert is compelled to seek legal action.

On December 10, 2024 I sent this response in email to my contact at Wilson Sonsini:

I have reviewed your letter and the Bugzilla thread referenced therein. In that letter, you suggest that DigiCert has various legal claims against Sectigo and/or its COO [sic], Tim Callan, for what you call “false and misleading statements about DigiCert” made on the Bugzilla forum. We strongly disagree. The statements you point to are questions and/or statements of opinion that are not actionable statements of fact. Moreover, those comments were made with the intent of facilitating discussion and debate about important questions of first impression for our industry. They were made by Tim Callan in good faith, are fully protected by the First Amendment, and cannot, as a matter of law, form the basis for any of the causes of action mentioned in your letter.

As you are aware, the PKI community is a self-regulating group that, as set out in the bylaws of the Certificate Authority Browser Forum, works “closely together in defining the guidelines and means of implementation for best practices as a way of providing a heightened security for Internet transactions and creating a more intuitive method of displaying secure sites to Internet users.” For the community to self-regulate, there needs to be open, uninhibited, and robust discussion and debate about best practices in the industry. Any litigation threats that chill or stifle such debate undermine the self-regulatory system that has worked so well for the industry.

Certificate Authorities post incident reports on Bugzilla to “provide lessons learned and transparency about the steps the CA Owner takes to address the immediate issue and prevent future issues.” As the Common CA Database goes on to state “incident reports help the Web PKI ecosystem as a whole because they promote continuous improvement, information sharing, and highlight opportunities to define and adopt improved practices, policies, and controls” of all parties.

The TRO involved in this incident report, as one Bugzilla commenter noted, is “an unprecedented event in the WebPKI, and . . . if allowed to proliferate, it would potentially be used by subscribers en masse to do an end-run around important technical security controls.”

The PKI Community has never considered how it should respond to TROs and now needs to do so. Understanding the situation faced by your client and why it made certain decisions is important to improving the WebPKI ecosystem. This is why Mr. Callan, and many others, have been asking questions – some of which have been critical questions designed to achieve a consensus as to how best handle situations like this in the future. In any such discussion, there will be differences of opinion, but open, uninhibited, robust, and transparent discussion is essential for the industry to learn how to best move forward.

I hope that your client will, on deeper reflection, realize that as a leader in the PKI Community, it should be driving, rather than stifling, discussion of this topic. Your client’s threat of litigation is, in our view, both misguided and without merit. We will strive to be respectful in our tone, but neither Mr. Callan nor Sectigo will be silenced or prevented from asking critical questions and/or engaging in critical discussion about issues of substantial concern to the public and the industry.

We find the threat of legal action to stifle scrutiny and discussion of public CA practices to be deeply troubling and entirely at odds with the transparent, blameless post-mortem culture that the CCADB incident report guidelines expect CAs to embrace. Even for a company like Sectigo, the threat of a lawsuit from a well-resourced organization like DigiCert is worrisome, regardless of our confidence that Mr. Callan’s speech was proper, legally protected, and in the best interest of the WebPKI. Another party challenging DigiCert’s behavior, faced with this same threat, might choose simply to stop asking uncomfortable questions.

No CA should be allowed to intimidate its critics into silence. This would irreparably damage the integrity and quality of the WebPKI.

I am sharing this incident to bring attention to DigiCert’s actions and allow the community to evaluate this approach. What began as a discussion of the threat posed by certificate subscribers using the legal system to circumvent WebPKI security controls needs, in my opinion, to be broadened.

Comment 1

[DigiCert]

DigiCert is committed to the ideals that underpin this forum and the CA community. Interactions between competitors can sometimes be prickly, but we applaud your statement that “the WebPKI is best served by open, transparent, and honest debate about issues that impact our community.” We strive to be consistent with this ideal in our statements and actions.

We find ourselves in the strange position of having to publicly explain a private letter we sent to you and Sectigo last November. Like any private correspondence between individuals, it is difficult for others to have the full context to understand the interaction, particularly if only reading passages excerpted and emphasized to make a particular point. In reality, our letter to you was consistent with our desire to promote open and honest dialogue. We encourage all participants in this forum to read the entire letter and be familiar with the activity in this forum that gave rise to our concerns.

For a debate to be both open and honest, we have to trust that participants in our community have the best interest of the community and industry at heart. No doubt that industry competitors, like Sectigo and DigiCert, are tempted to seek business advantage wherever they can. But we discipline ourselves to set that aside when we come together to discuss issues that matter to our whole industry. We believe you and Sectigo feel the same way as we do about this.

Our reason for sending you this letter was not to chill debate, far from it. We were worried that some, encouraged by the Entrust distrust, may have been abusing the forum by posting misleading information and half-truths in an attempt to negatively sway public opinion and keep bugs open past their useful lifecycle. We are committed to preserving this forum for honest, as well as open, discussion and that it should not be used merely as a means for business competitors to foil each other. This was the reason we sent you and Sectigo the letter.

About a month later, you sent us back the response that you quote in your bug report. We were satisfied with your response. As you know we have not responded further or taken any other action on this matter, despite the ongoing discussion on the relevant bugs. Until you drew this out again we had thought the matter was closed.

In short, we fully agree with you that this community is best served by open discussion. But the discussion must also be honest, factually accurate, and focus on a fair review of important and relevant issues. Think how a business acting in bad faith could abuse this forum to undermine and harm a competitor in the CA industry—raising hearsay, reporting malicious rumors, asking leading and endless questions, etc. If this forum becomes merely a venue for gaining competitive advantage or for shaming our business rivals then it will fail its intended purpose and lose all value. Our aim in sending the letter was simply to defend the integrity of this forum.

Despite the occasional sharpness of business rivalry, we do trust your and Sectigo’s good faith, and above all the public spirit of this forum and its moderators. We hope we can put these concerns behind us and continue monitoring and discussing matters truly of interest to the WebPKI community.

Comment 2

[Wayne]

The very first thing I did on seeing this incident was not to read Sectigo's allegations, but the letter that DigiCert wrote. On those facts, as disclosed, it certainly reads poorly that this is consistent to DigiCert's desire to promote open and honest dialogue.

Worryingly, it is a targeted legal threat at a named, singular, employee bolstered by baseless legal arguments. I was particularly amused when the Lanham act was butchered to breaking point to try and imply participation on Bugzilla by your competitors is considered commercial advertising or promotion. Try to lead by example and have your team talk on other incidents publicly, try to see where shortcomings exist in other CAs, and how to push the community as a whole forward.

If we're going to be open, transparent, and honest then we need to acknowledge that in November someone made a terrible call and authorized that letter in the first place. I appreciate that in the timeframe that DigiCert were dealing with the fallout of a TRO impacting their revocation. I would not be surprised if potential scenarios discussed, and were perhaps leapt upon without proper understanding of the repercussions.

It's already an embarrassing letter, but please do everyone a favor and admit some fault here. In the interests of transparency, and with DigiCert highlighting the Entrust distrust, I want to make clear that nothing even close to this was sent from Entrust's side during the past year. Or at least no one who's talked to me has hinted at anything close to it ever existing.

Please consider this internally and try to improve your communications going forward.

Comment 3

[JSaares]

I personally see no way to read the full and complete letter as anything other than an intentional and blatant legal threat to discourage further scrutiny of DigiCerts actions, views and interpretations that much of the broader community have understandably held much interest in. Even if we assume, arguendo, that DigiCert did not intend for the letter to come off as a legal threat (which, I'll note, is rather difficult to do), surely they must have understood that it absolutely would be taken as one. I'll just note that an argument premised on DigiCert not following up on the threat does not make it any less of a one, but merely a bad legal threat.

Reading DigiCert's response in comment #1 above makes it even more difficult to assume good faith on the part of the letter: the response vacillates between vaguely reconciliatory language and what read as badly-veiled accusations in a way that just makes it further sounds like the interpretation of the letter as a legal threat is the intended one. As a consequence, there is only one way I am able to interpret the reply in Comment #1: that in DigiCert's view the only problems here are 1) the scrutiny they are under and 2) that Sectigo brought the legal threats to the eyes of the broader community. Especially wrapping up with "We hope we can put these concerns behind us and continue monitoring and discussing matters truly of interest to the WebPKI community." makes it nigh-impossible to read the reply as anything else.

Against this background, DigiCert's statement that “[DigiCert] have not used a legal team as a shield against accountability.” is quite troubling. It either indicates a lack of communication within DigiCert (i.e. the party making said statement did not know of the letter), or alternatively a failure of everyone involved to appreciate that a natural reading of a formal letter by a legal firm, including the phrase "before DigiCert is compelled to seek legal action" is as a legal threat. The most charitable possible interpretation I can come up with -- assuming again, arguendo, that the letter was not meant as a legal threat even if interpreted by one -- is that DigiCert has good intentions, but struggles massively in written communication, not being able to appreciate how negative, hostile and "corporate PR" (i.e. uncandid) what they actually put down on the digital paper comes off to the readers.

I'll mirror Wayne in calling for DigiCert to "do everyone a favor and admit some fault here", as well to "consider this internally and try to improve your communications going forward".

Comment 4

[ryan_hurst]

As someone who’s spent a lot of time thinking about how we handle incidents, I’ve been following this discussion closely. I agree with Wayne and JSaares that empathy, humility, and clear communication are vital in moments like this—both for maintaining trust and for pushing our community forward.

It’s tough to see how a letter like the one DigiCert sent could avoid being read as a legal threat, intentional or not, and I think acknowledging that perception (even if it wasn’t the intent) could go a long way toward rebuilding goodwill here.

For what it’s worth, I recently wrote a blog post about incident response best practices, inspired in part by threads like this one. It digs into how we can approach these situations with transparency and a learning mindset—and offers some practical steps for CAs to handle incidents constructively. If folks are interested, it’s posted here: [https://unmitigatedrisk.com/?p=982]

Comment 5

[Mike Shaver (:shaver emeritus)]

This is obviously a very challenging situation for the WebPKI community to be in. Two influential CAs are at legal odds with each other, on the specific topic of how Web PKI self-governance is performed in one of its primary venues. It's easy to imagine that even the memory of these events will have a chilling effect on discourse here, and prevent some from making valuable contributions. That's a shame, and I think a waste of the effort that has gone into making Bugzilla and incident reports a force for industry improvement and collaboration (which is not always, by any means, industry agreement.)

To state it that way, of course, is perhaps to imply an equality of responsibility for the present situation, which is not at all my intent. DigiCert's letter is either a legal threat intended to have exactly the sort of chilling effect I bemoan above, or it is some of the clumsiest legal writing to ever surface in this industry. In either case, I believe that an apology is owed not only to Sectigo—who I hope will not be deterred from frank comments on incident practices in the future—but indeed to the entire root-Bugzilla and Web PKI community. This is an attack on the norms and values of a diverse community of participants who perform an essential role for the safety and integrity of the web. It is grotesquely disappointing to see it from a participant as storied and experienced as DigiCert, and to see the dancing around "context" and false camaraderie in DigiCert's response here merely adds insult to injury.

If DigiCert is to act responsibly regarding this matter, from this point forward, I think that they would do well to not only apologize, but to produce an incident-style reporting on the organizational failures that led to the original letter and the terrible subsequent response in this bug, as well as the steps that are being taken to keep them from recurring to the detriment of the web. DigiCert, will you commit to this?

I'd also like to thank Sectigo for bringing this conduct to light. In my opinion, it unfortunately reads on DigiCert's credibility as a member of this community, and is important information to have when dealing with them in the future.

Comment 6

[J. Bentham]

Wayne wrote:

Please consider this internally and try to improve your communications going forward.

JSaares wrote:

I'll mirror Wayne in calling for DigiCert to "do everyone a favor and admit some fault here," as well as to "consider this internally and try to improve your communications going forward."

Mike wrote:

If DigiCert is to act responsibly regarding this matter, from this point forward — snip — is important information to have when dealing with them in the future.

The three of you believe there is a way forward.

Entrust was distrusted for far less.
Symantec was distrusted for far less.

Why would anyone believe DigiCert has a future in public PKI? Even from DigiCert’s poorly written response above, it is clear as day that they fall into the category of CAs that should be distrusted. DigiCert’s actions do not foster trust—double-digit bugs over the past year, numerous delayed revocations without adequate justification, and now this legal letter.

Their responses to community questions have been inadequate, with updates that fail to inspire trust or confidence that they are genuinely addressing root causes. Instead, their replies feel more like legal maneuvering than sincere efforts to fix the issues.

This is not the behavior of a CA that wants to do the right thing and be an upstanding member of the community. Instead, they seem to be using every available lever—including legal tactics—to avoid accountability.

That being said, is the general sentiment of the community that "DigiCert is too big to fail"?

I would like to hear what the browser representatives think about this situation and whether they feel DigiCert genuinly engenders the proper CA trusted by their programs.

The community and public at large is listening...

Comment 7

[Mike Shaver (:shaver emeritus)]

I definitely did not mean to indicate that I was specifically in favour of DigiCert remaining trusted, or to give any opinion of their conduct in other incidents. Whether or not they remain trusted is up to the root programs, and I think that DigiCert should provide a full accounting of cause and remediation even if distrust is on the table for this or other reasons. Entrust is still finishing up its outstanding incident reports, after all.

Comment 8

[Ben Wilson]

One of Mozilla’s core principles is the importance of transparent community-based processes. A healthy certificate ecosystem requires open discussion and debate, as well as robust, constructive and respectful engagement from all sides. Actions that chill participation in these discussions are deeply damaging to our community, whether they take place in private or in public.

Similarly, while discussions can be robust, participants should be careful not to cross the line into aggressive or adversarial behavior. Even when “asking questions”, participants should endeavor to be respectful and fairly characterize other’s views. Constructive collaboration and open dialogue are one of the most effective ways to support and contribute to a healthy and secure certificate ecosystem.

We welcome the continued constructive discussion. If contributing, please be mindful of Mozilla’s Community Participation Guidelines (CPG).

Comment 9

[J. Bentham]

Ben, perhaps you should recuse yourself due to your long history with DigiCert. People are aware of your private conversations with them, and there is a noticeable degree of favoritism in how you handle bug closures.

This was meant to be an open fact based dialogue, not adversarial nor aggressive.

The public has a growing concern how these matters are being handled behind closed doors.

Comment 10

[Dimitris Zacharopoulos]

I believe Ben Wilson has been very careful with running the Mozilla Root Program in a fair and impartial manner, so comments like https://bugzilla.mozilla.org/show_bug.cgi?id=1950144#c9 are disrespectful to Ben's work in Mozilla over the last years.

Even in the strictest no-compete contracts, when a person leaves a company, the conflicts of interest are no longer considered valid after 2-3 years.

"Closed doors" are in some cases essential to protect business relations and pursue faster progress. Browsers have been known to discuss with auditors "behind closed doors" and that's for the benefit of the public interest. Browsers have also been know to discuss "behind closed doors" with Regulators and EU officials, in order to get a better position in the interest of Relying Parties. None of that is wrong or problematic.

"The Public" (sic) is very pleased with the balance Browser representatives have exercised historically in this ecosystem, and I can't recall a single moment in time where "The Public" has raised strong concerns about the Browser representative's behavior breaking that balance.

Comment 11

[u654666]

(In reply to J. Bentham from comment #9)

Ben, perhaps you should recuse yourself due to your long history with DigiCert. People are aware of your private conversations with them, and there is a noticeable degree of favoritism in how you handle bug closures.

This was meant to be an open fact based dialogue, not adversarial nor aggressive.

The public has a growing concern how these matters are being handled behind closed doors.

---

I find it concerning that what feels to me like a reasonable reminder in comment #8 of Mozilla's Community Participation Guidelines (CPG) then receives this response, which I personally feel does not meet those guidelines.

Recusal Suggestion
"Ben, perhaps you should recuse yourself due to your long history with DigiCert."

Suggesting recusal due to a perceived conflict of interest can be seen as a legitimate concern if presented respectfully. However, it should be backed by evidence and not imply wrongdoing without proof.

Accusation of Favoritism
"People are aware of your private conversations with them, and there is a noticeable degree of favoritism in how you handle bug closures."

This statement could be construed as a personal attack, as it accuses Ben of favoritism without providing concrete evidence.

Comment 12

[DigiCert]

DigiCert voluntarily disclosed the TRO in its incident response. The TRO affected only 1 certificate, which ended up being handled exactly the same way as all the rest. And all the information about the TRO is in the public record. Despite this, our competitor both publicly and privately repeatedly asked our representatives about it, so we wanted to make their management aware of the behavior. We need to take the steps we feel are necessary to protect our business from attack from our competitors and we felt circumstances warranted sending the November 11 letter to Sectigo. As we note above, Sectigo responded and we were satisfied with the response and that was the end of the matter as far as we were concerned. Since there is no allegation of a violation of a compliance requirement here, please close this issue.

Comment 13

[Wayne]

(In reply to DigiCert from comment #12)

DigiCert voluntarily disclosed the TRO in its incident response. The TRO affected only 1 certificate, which ended up being handled exactly the same way as all the rest. And all the information about the TRO is in the public record. Despite this, our competitor both publicly and privately repeatedly asked our representatives about it, so we wanted to make their management aware of the behavior. We need to take the steps we feel are necessary to protect our business from attack from our competitors and we felt circumstances warranted sending the November 11 letter to Sectigo. As we note above, Sectigo responded and we were satisfied with the response and that was the end of the matter as far as we were concerned. Since there is no allegation of a violation of a compliance requirement here, please close this issue.

Will DigiCert be sending more letters to other parties in the future? That a subject makes DigiCert uncomfortable to discuss does not change that there were questions raised and unanswered.

Whoever is making these decisions at DigiCert needs to understand that "our desire to promote open and honest dialogue", should not stop at being asked to explain issues that make the company uncomfortable. Nor, indeed, are incidents as narrowly defined as your CA seems to be misunderstanding. For example from the Chrome Root Program Policy:

The failure of a Chrome Root Program Participant to meet the commitments of this policy is considered an incident, as is any other situation that may impact the CA's integrity, trustworthiness, or compatibility.

Incidents are not just certificate issues, but are broad enough to raise incidents where a CA's integrity, trustworthiness, or compatibility require a discussion, and remediation. Does DigiCert have a different interpretation?

I appreciate the DigiCert have not actually answered any point raised so far, and look forward to them actually answering any questions. Furthermore as Ben has already stated:
(In reply to Ben Wilson from comment #8)

One of Mozilla’s core principles is the importance of transparent community-based processes. A healthy certificate ecosystem requires open discussion and debate, as well as robust, constructive and respectful engagement from all sides. Actions that chill participation in these discussions are deeply damaging to our community, whether they take place in private or in public.

One strange individual aside, we are all trying to figure out a way forward here so please try to involve yourself in this discussion in a positive way. The repeated focus on competitors gives a very unfortunate perception of DigiCert's views on interacting with CAs in this space. I personally am very curious as to what DigiCert's actions would be if a 'competitor' sent a similar letter to a named employee at your company.

Comment 14

[Zacharias]

The use of a TRO by a subscriber to prevent revocation was unprecedented, and it should not be surprising that any CA and their staff would be very interested in such an incident, and of course any legal precedent it could result in. In the past year there has been numerous delayed revocation incidents and a key lesson learned across many of them has been how manual procedures has prevented prompt action. If the use of the legal system by subscribers to delay or prevent revocation becomes an accepted practice then it undermines not only all the work that has been done to spread automation, the agency of CAs, and the BRs.

Having read through https://bugzilla.mozilla.org/show_bug.cgi?id=1910322 again I want to highlight something that I have not seen addressed by others and that I find worrying. Before the comments that prompted the legal threat, the discussion was about the appropriateness of an individual resigning as the result of an incident, the importance of “blamenessness”, and the negative consequences which this could have in the future.

While Jeremy Rowley states that it was his voluntary choice to resign, I cannot help but connect this with DigiCert making an individual the target of their legal threats.

I take Mr. Rowley on his word that the resignation was voluntary, but DigiCert had a choice in one of their employees posting that the root cause of an incident was them; personally. And they had a choice in that persons resignation being included in the post mortem of a bug. I understand feeling personal responsibility for an incident and wanting to resign, but an organization should understand that the true root cause of an issue is not a specific individual. I hope that the move to non-personal CA accounts on Bugzilla will help in preventing others from “martyring” themselves in the future.

I think it was a mistake by DigiCert to allow blame to be placed on a specific individual (even if it is done by themselves), and I also think it is a mistake to target a specific individual (through their employer) with these legal threats.

While it might not be much to me it is enough to wonder if there is a pattern here and I’m curious if others see the same thing.

When reading comments to the referenced bug I do not think that any of them are disparaging. And I am confident that most share my sentiment because when comments cross the line of what is acceptable on Bugzilla they are called out, as evidenced in the comments on this bug.

We should be able to trust the community and Mozilla to call out and act against unacceptable behavior. Surely Mozilla would act if they believed that a CA was using Bugzilla to disparage their competitors. This is what I believe.

I am troubled that DigiCert has restated in their latest comment that they believe that the legal threats were justified, framed as “protecting themselves from a competitor”. The specificity makes me, personally, feel a little bit safer as an individual contributor (representing no one but myself as a relying party).

We also find ourselves yet again in the situation that has happened quite often in the past year: a CA in disagreement with everyone else on Bugzilla (willing to engage publicly).

I ask that this bug not be closed and instead that DigiCert takes this opportunity build trust with the community by taking responsibility for their mistakes and learning from them.

Comment 15

[Wayne]

Do we have a timeline for when the preliminary incident report will be posted?

Comment 16

[Ben Wilson]

I'm not sure that this is your typical incident. We moved this bug from the CA Compliance to the CA Certificate Root Program component. Let's discuss this further before making any decisions in that regard.

Comment 17

[DigiCert]

As explained in Comments 1 and 12, we believed it was appropriate to address statements from a competitor that we considered misleading about our company, by sending the letter attached to this bug report. However, we also understand and empathize with the comments that expressed concerns that these types of letters could have the effect of chilling open discussion in this forum. We were surprised Sectigo shared this letter as the legal team had thought the issue resolved. Our first response was to explain our reasons for sending the letter. On reflection, we acknowledge that the letter was not in the best interest of transparency and this community. The Mozilla forum has a code of conduct policy, which would have been a much better avenue for dealing with any perceived unfairness.

Open discussion is very important to DigiCert and the industry standards team. We regret sending the letter. We would not have sent a letter like this to just any member of this forum. The letter was sent in the normal course of business from one large company to a comparably large competitor who has similarly sophisticated legal resources. Even in this context, sending the letter was not a good idea, and if we could go back to November, we would not send this letter again. We are committed to open discussion with the community to resolve concerns, even when the community members are competitors. Going forward, we will limit ourselves to the Community Participation Guidelines rather than external legal process for questions of abuse of the forum. We take responsibility for what we admit was a mistake.

Comment 18

[Wayne]

I appreciate that DigiCert were willing to acknowledge that a mistake has been made. However I'm still missing answers to a question posed over 7 days ago in Comment 13:

Whoever is making these decisions at DigiCert needs to understand that "our desire to promote open and honest dialogue", should not stop at being asked to explain issues that make the company uncomfortable. Nor, indeed, are incidents as narrowly defined as your CA seems to be misunderstanding. For example from the Chrome Root Program Policy:

The failure of a Chrome Root Program Participant to meet the commitments of this policy is considered an incident, as is any other situation that may impact the CA's integrity, trustworthiness, or compatibility.

Incidents are not just certificate issues, but are broad enough to raise incidents where a CA's integrity, trustworthiness, or compatibility require a discussion, and remediation. Does DigiCert have a different interpretation?

I am glad we are now starting on the right steps going forward.

Comment 19

[DigiCert]

Wayne, we acknowledged that it was a mistake to send the letter, but we don’t believe that it represented a failure to meet the commitments of the root program policies or that this represents an incident.

Comment 20

[DigiCert]

DigiCert has no additional comments on this matter. Can we consider this resolved?

Comment 21

[JR Moir]

I do not think this can be 'resolved' yet - Wayne provided clear proof from The Chrome Root Program Policy that this is really an incident. Digicerts integrity and 'trustworthiness' is under question in this place.

I would hope some reprezentative from Chrome could comment here, and this Bugzilla should stay open until we have comment from them if it is Chrome considering incident or it is not.

Comment 22

[chrome-root-program]

We believe continuing this discussion in this bug provides an opportunity for DigiCert to directly address the community's interests and demonstrate its commitment to consistently upholding the standards we must consider essential for publicly-trusted CA Owners.

To be clear, behavior that intimidates, discourages, or otherwise undermines a member's good-faith participation in this community is at odds with the core values of the Web PKI ecosystem, unacceptable, and detrimental to the ecosystem's best interests.

The community's feedback demonstrates that there's a strong desire to understand DigiCert's efforts in rebuilding trust and restoring goodwill following the activities detailed in this bug. We believe that this discussion, not a separate incident report, is the most effective way to achieve these goals.

We appreciate DigiCert's acknowledgment that their past behavior fell short of their standards. However, the acknowledgment does not foreclose further discussion, and we need a clear path forward to ensure such behavior is not repeated by any member of the community.

Comment 23

[DigiCert]

Thank you, Chrome Root Program, for your engagement in this discussion and emphasizing the importance of transparency, collaboration, and open dialogue within the Web PKI. DigiCert is committed to upholding these values and ensuring our participation on Bugzilla fosters both trust and constructive engagement.

DigiCert will not threaten legal action against any member of this forum solely for comments made in this forum, unless under exceptional circumstances where DigiCert’s legal rights are clearly abused or threatened and community redress mechanisms are ineffective. Such “exceptional circumstances” will only be found after extensive and careful internal review.

We appreciate the opportunity to work with the community and reinforce the foundational principles of trust, transparency, and open and respectful communication. We remain committed to constructive dialogue and welcome continued engagement that benefits all stakeholders.

Comment 24

[Wayne]

I'm glad that DigiCert have acknowledged that this is an incident. To figure out a way forward can they please fill out the incident report as required.

The multiple caveats over threatening legal action are less than helpful. Would this be at least some acknowledgement that the original letter was received as a legal threat, even though it was somehow not intended to be? The incident report explaining how this happened and what steps are being taken to make sure this will not happen again will help clarify matters.

Comment 25

[DigiCert]

Wayne, we agree that this discussion, not a separate incident report, is the most effective way to address the community’s concerns.

To that end, we welcome any additional discussion and are willing to answer any additional questions the community may have.

Comment 26

[mpalmer]

I'd like to echo Wayne's observation that the caveats applied to the assertion around legal action do not provide any meaningful assurances regarding DigiCert's future behaviour. I, for one, am hesitant to participate in discussions until such time as the now-evident legal risk is mitigated, one way or another. Having been the recipient of baseless legal threats in the past, I know the legal costs involved in responding to them, and as an individual, I cannot afford to risk incurring those costs if a CA happens to take a dislike to my questions and comments.

My question for DigiCert comes from the Chrome Root Program's previous post: what steps does DigiCert recommend root programs take "to ensure such behavior is not repeated by any member of the community"?

Comment 27

[Wayne]

I did provide an additional question in Comment 24 that is unanswered:

The multiple caveats over threatening legal action are less than helpful. Would this be at least some acknowledgement that the original letter was received as a legal threat, even though it was somehow not intended to be? The incident report explaining how this happened and what steps are being taken to make sure this will not happen again will help clarify matters.

My point of producing an incident report is that a series of missteps have occurred for that letter to be created, approved, and sent out in the first place. While the community does not dispute that a company needs to discuss public relations issues with their legal counsel, that does not extend to - even inadvertently - creating a sense that participation in these discussions can cause legal threats to be received.

It is not clear at all what occurred at DigiCert last November, and what has changed to date that would allow Comment 23 to stand as a statement of DigiCert's internal review standards going forward. An idea of how the original issues causing that letter met such internal standards, and how they would match against a newer standard would help address these concerns.

To wit from Comment 1:

But the discussion must also be honest, factually accurate, and focus on a fair review of important and relevant issues. Think how a business acting in bad faith could abuse this forum to undermine and harm a competitor in the CA industry—raising hearsay, reporting malicious rumors, asking leading and endless questions, etc. If this forum becomes merely a venue for gaining competitive advantage or for shaming our business rivals then it will fail its intended purpose and lose all value.

No recent case of a CA sending a legal threat, as received albeit perhaps not as intended, comes to mind. I hope DigiCert understands how that could be perceived by the community as a potentially bad faith act. This isn't about motives or intent however, but that an internal decision was made that caused integrity issues on this public forum. No one particularly cares to see two CAs throwing disparaging remarks at one another in public, but the move to involving legal is a major misstep.

To that end can we get an update on where DigiCert are with creating an incident report to explain what went wrong, and what steps have been put in place to stop this from reoccurring? CAs are generally self-regulated, but do take guidance from each other. Without a clear statement of how DigiCert's processes have improved since sending it, that letter risks lowering the standards that CAs are held to.

Comment 28

[DigiCert]

Matt and Wayne, thank you both for your comments. We are working on a post which we hope will address both your concerns and will post tomorrow.

Comment 29

[DigiCert]

Full Incident Report

Summary

• CA Owner CCADB unique ID: “DigiCert” A000021

• Incident description: On November 11, 2024, a law firm retained by DigiCert sent a Cease & Desist letter (C&D) to Sectigo based on comments made by a Sectigo representative related to the Temporary Restraining Order (TRO) in relation to Bugzilla 1910805.

The C&D specified that Sectigo’s Tim Callan made several false or misleading statements with respect to the TRO and DigiCert’s operations. Statements cited in the C&D include allegations by Sectigo, a direct business competitor, that DigiCert failed to address the TRO, that DigiCert did not have language in its contracts allowing for termination, and that DigiCert indicated that the BRs were not applicable or binding.

As none of these statements were factual, DigiCert decided to send the C&D, seeking to improve accuracy in how the issues are represented. The team sending the C&D underestimated the potential effect that a C&D could have on the community’s communication on Bugzilla and other forums.

Because the C&D closely overlapped the discussion occurring on Bugzilla, sending the C&D could have had a dampening effect on public discussion. DigiCert acknowledges that a more transparent and community-friendly path should have been taken. In hindsight, a better approach would be to address the perceived Sectigo misrepresentations publicly in the context of Bugzilla, rather than pursuing the private path with the C&D.

• Timeline summary:

Our timeline deviates from the normal Bugzilla format as this incident report deals with a legal communication rather than a period of non-compliant issuance. Compliance and engineering issues are tracked in JIRA, giving us accurate time information. The C&D activity was not documented in the same way.

Date	Activity
2024-07-30	11:33 DigiCert Legal receives notice that a TRO has been filed. Afterwards there is a discussion on the TRO with multiple questions from Tim Callan, including comment 36 on Bugzilla 1910322.
2024-11-11	C&D letter sent to Sectigo by Wilson Sonsini on behalf of DigiCert following comments made by Sectigo representatives in Bugzillas 1910805 and 1910322.
2024-12-10	Sectigo Legal responds; matter considered resolved by DigiCert Legal.
2025-02-24	Brian Holland, Sectigo Legal representative, files Bugzilla 1950144.

• Relevant policies:

Chrome policy 1.6 section 5 states: “The failure of a Chrome Root Program Participant to meet the commitments of this policy is considered an incident, as is any other situation that may impact the CA's integrity, trustworthiness, or compatibility.”

Community members are concerned that the use of C&D letters “may impact the CA’s integrity, trustworthiness, or compatibility.”

• Source of incident disclosure:
  Third party reported in Bugzilla 1950144.

Impact

• Total number of certificates: None

• Total number of "remaining valid" certificates: None

• Affected certificate types: None

• Incident heuristic: This incident does not deal with certificates.

• Was issuance stopped in response to this incident, and why or why not?: No – this report does not deal with certificates.

• Analysis: Responses to Bugzilla incident reports are treated with great gravity by DigiCert, particularly those with such large impact as the mass revocation in Bugzilla 1910805. DigiCert acknowledges that its response in that incident faced important challenges, and that the chilling effect of sending a C&D letter from a law firm can be real. Instead of responding with a C&D letter to perceived misinformation, a better approach for a CA to take is to simply quote the inaccurate statement followed by the true statement. The community participants regularly read posts, and correcting misinformation publicly has a more powerful effect on ensuring bug accuracy than private dialogue between legal departments.

For example, in comment 36, Tim commented “Question 1: Please elaborate on your rationale here. Where in Mozilla policy does it require that CAs encourage Subscribers to request active disobedience to BR requirements?”

DigiCert Legal felt this comment, and similar comments, were positioning statements designed to portray DigiCert as dishonest, and designed to complicate the process of dealing with the actual issues at the heart of the bug. Mozilla policy clearly does not require that CAs encourage Subscribers to request disobedience to BR requirements, nor did DigiCert portray such a sentiment. However, DigiCert should have addressed that in public discourse rather than through legal means.

• Additional considerations: No additional comment.

Timeline

DigiCert tracks precisely security, engineering, and compliance activities that are subject to normal CCADB and Root Program obligations. As this was a legal matter, creating an exact timeline is difficult as it is not tracked in the same manner. Also, key individuals involved in the decision are either on previously scheduled extended leave, or have left the company for unrelated reasons or are out on medical leave that began before this bug was filed.

Date	Activity
2024-07-29	DigiCert files preliminary report for Bugzilla 1910322.
2024-07-30	11:33 DigiCert Legal receives notice that a TRO has been filed.
2024-08-02	Tim Callan makes comment 28 on Bugzilla 1910322 related to the TRO.
2024-08-03	20:47 DigiCert completes the mass revocation.
2024-10-04	Tim Callan comment 36 implies that DigiCert willfully encouraged customers to defy Mozilla policy.
2024-11-11	C&D letter sent to Sectigo by Wilson Sonsini on behalf of DigiCert.
2024-12-10	Sectigo Legal responds; matter considered resolved by DigiCert Legal.
2025-02-24	Brian Holland, Sectigo Legal representative, filed Bugzilla 1950144.

Related Incidents

The C&D was sent by the DigiCert Legal team, which independently monitors Bugzilla comments on DigiCert incident reports, following Tim Callan’s involvement in the public discussion on the following Bugzilla reports:

• Bugzilla 1910805: DigiCert: Delayed revocation of 1910322
• Bugzilla 1910322: DigiCert: Random value in CNAME without underscore prefix

Root Cause Analysis

Contributing Factor #1: Novelty of TRO

• Description: The mass revocation event covered in Bugzilla 1910805 was a significant event for DigiCert, which led to an overall re-stating in the industry of deadlines for revocations and the fact that there are no extenuating circumstances allowing extension of revocation deadlines.

DigiCert was faced with many such claims of extenuating circumstances during that revocation, including the TRO. This was the first such court activity that the company had received in a revocation. The TRO played a limited role in the mass revocation but was disclosed as part of DigiCert’s commitment to transparency. The DigiCert team participating in the bug was unsure on the motives behind the continuous questions about the TRO given its limited role.

• Timeline: No additional comment.
• Detection: No additional comment.
• Interaction with other factors: No additional comment.
• **Root Cause Analysis methodology used:**No additional comment.

Contributing Factor #2: Competition

• Description: DigiCert and Sectigo are direct competitors. While CCADB policy encourages individuals affiliated with publicly-trusted CAs to participate in Bugzillas, this participation can contribute to competitive tensions. This is particularly true where comments appear to be made for purposes beyond repairing incidents and focus primarily on the trustworthiness of a CA.

On 2025-01-25, Entrust announced that Sectigo, who regularly commented on the bugs leading to Entrust’s distrust, acquired the Entrust client base. The pattern of events confirmed the validity of the Legal team’s concern as it showed that CAs can profit from their participation on a competitor’s bugs on Bugzilla and may have a direct adverse interest in the trust of other CAs.

Of Tim Callan’s 24 Bugzilla comments in the period covered by this incident report, 18 were directed towards DigiCert bugs. For right or wrong, the frequency of Tim Callan’s DigiCert-directed comments were viewed in light of this competitive sensitivity. In particular, the phrasing of some of those comments were perceived by the DigiCert Legal team as attempts to position DigiCert as acting irresponsibly or contrary to the rules or intent of the Mozilla community.

To the contrary, DigiCert is committed to the standards and requirements of this community. As DigiCert was already struggling with the fallout of the mass revocation and implementing the corrective actions needed to ensure that such circumstances did not reoccur, there was a sensitivity that Bugzilla was being weaponized for competitive purposes.

At the time, there was also significant disruption in leadership at DigiCert as the executive responsible for compliance and standards had resigned as a result of the mass revocation incident. This led to a major reorganization that disrupted DigiCert’s typical compliance workflows and approval process.

Our action plan lays out our intent to foster transparency when legal activities intersect with incident reports. In addition, Bugzilla may consider policies requiring participants making comments on Bugzilla incidents to state their potential conflicting interests.

• Timeline: No additional comment.
• Detection: No additional comment.
• Interaction with other factors: No additional comment.
• Root Cause Analysis methodology used: No additional comment.

Lessons Learned

• What went well:

• This mass revocation event, and the discussion surrounding it, has made it explicitly clear to users of TLS that delayed revocation is never acceptable.
• This was the first time a TRO has played a role in a mass revocation event.

Now, DigiCert and other CAs should have a clearer view how to deal with such court orders. In addition, Brian Holland of Sectigo recently presented a workshop on dealing with legal challenges during revocations during the recent CAB Forum meeting in late March.

• What didn’t go well:

• More information about the TRO should have been disclosed to the community and in a timely manner.
• The C&D was not the best action in this instance and a public and transparent correction of perceived incorrect allegations would be preferred.

• Where we got lucky: No additional comment.

• Additional: No additional comment.

Action Items

Action Item	Kind	Corresponding Root Cause(s)	Evaluation Criteria	Due Date	Status
Technical-First Dispute Resolution: During incident reports, concerns about technical issues, misrepresentations, or policy violations related to compliance issues must be addressed on the corresponding Bugzilla and not through legal channels. The Legal team may address items related to misrepresentations, fraud, and trademark abuse that are not part of an active incident.<p>If legal steps are necessary related to an active incident, the decision and action will be disclosed in the corresponding Bugzilla.	Prevent	Overall	NA	2025-04-04	Done
Community Transparency Pledge: Communication related to incidents will be handled in the open, using community forums (e.g., MDSP, CCADB, CAB Forum, Bugzilla) to provide traceability and prevent misunderstandings. This includes important mass customer communication related to the incident. <p>Outreach to commenters about statements or allegations should be documented and posted to incidents as appropriate to avoid surprises or perceived retaliation.	Mitigate	Overall	NA	2025-04-04	Done
Legal Review Gate: Executive-level review and approval will be sought for legal actions that intersect with an incident, which shall include an analysis showing the legal action is necessary and appropriate. <p>Public notice will be provided of legal actions related to an incident where possible. Where immediate public notice is not possible, DigiCert will provide private notification to root programs with a later public follow-up.	Prevent	Overall	NA	2025-04-04	Done
Ombudsperson Role for WebPKI Concerns: DigiCert will designate an independent ombudsperson within DigiCert that community members can use to confidentially raise concerns about DigiCert’s conduct in the WebPKI especially around fairness, openness, or perceived intimidation.	Prevent	Mitigate	NA	2025-05-01	Underway

Appendix

Responding to specific Comments:

We appreciate DigiCert's acknowledgment that their past behavior fell short of their standards. However, the acknowledgment does not foreclose further discussion, and we need a clear path forward to ensure such behavior is not repeated by any member of the community. Comment 22.

We proposed an action plan in the incident report that we hope clarifies DigiCert’s support for open communication and community interaction while protecting our legal interests if needed. There are circumstances where legal action may be necessary to defend DigiCert’s legal rights, and thus it may be necessary to send a letter to advise that someone’s actions threaten those legal rights, but those circumstances need to be balanced against the potential to stifle communication. Our action plan seeks to achieve the correct balance with a strong preference towards open dialogue in the Bugzilla process rather than legal process.

The multiple caveats over threatening legal action are less than helpful. Would this be at least some acknowledgement that the original letter was received as a legal threat, even though it was somehow not intended to be? The incident report explaining how this happened and what steps are being taken to make sure this will not happen again will help clarify matters. Comment 24.

Yes – the original letter was a threat that DigiCert would consider taking legal action based on statements made by Tim Callan that were deemed by the DigiCert Legal team to be misrepresentations and designed to have an unfair competitive impact. We believe our action items emphasize DigiCert’s support for open and transparent communication, while retaining the right to pursue disclosed legal options when the activity intersects with a Bugzilla. We acknowledge again that this C&D in this circumstance was not an appropriate response.

I'd like to echo Wayne's observation that the caveats applied to the assertion around legal action do not provide any meaningful assurances regarding DigiCert's future behaviour. I, for one, am hesitant to participate in discussions until such time as the now-evident legal risk is mitigated, one way or another. Having been the recipient of baseless legal threats in the past, I know the legal costs involved in responding to them, and as an individual, I cannot afford to risk incurring those costs if a CA happens to take a dislike to my questions and comments. Comment 26.

We are sorry to hear that, Matt. We hope that this incident report assures you that DigiCert believes strongly in open dialogue. The C&D was not sent because the DigiCert Legal team disliked the topics in question but because they believed the questions were primarily designed to portray DigiCert in a negative light and were made in the context of intense competition between DigiCert and Sectigo. These comments should have been addressed more straightforwardly within the Bugzilla itself and not through threatening legal action.

My question for DigiCert comes from the Chrome Root Program's previous post: what steps does DigiCert recommend root programs take "to ensure such behavior is not repeated by any member of the community"? Comment 26.

Balancing constructive community input while acknowledging that commenters may have “other relationships” outside the current Bugzilla is a difficult topic. Frankly, some commentors have competing agendas and conscious or unconscious motives to use the forum to advance their own business and competitive interests. We believe transparency is the best option and all communication related to comments made on an incident should be posted to that incident.

My point of producing an incident report is that a series of missteps have occurred for that letter to be created, approved, and sent out in the first place. While the community does not dispute that a company needs to discuss public relations issues with their legal counsel, that does not extend to - even inadvertently - creating a sense that participation in these discussions can cause legal threats to be received. Comment 27.

DigiCert acknowledges the need and value of incident reports. We hope the incident report explains the missteps that occurred with the C&D. The intent was not intended to stifle community dialogue but to prevent a perceived leveraging of the Bugzilla process for competitive purposes. We acknowledge that would have been better handled within the Bugzilla process.

It is not clear at all what occurred at DigiCert last November, and what has changed to date that would allow Comment 23 to stand as a statement of DigiCert's internal review standards going forward. An idea of how the original issues causing that letter met such internal standards, and how they would match against a newer standard would help address these concerns. Comment 27.

DigiCert’s Bugzilla process has undergone a major reconfiguration since the letter was sent. This includes a modified approach to responding to Bugzillas and tracking follow through on both questions and action items. We believe that our new process, when applied to all departments within DigiCert, should dispel concerns of threatened legal action being used to stifle valid community interaction.

No recent case of a CA sending a legal threat, as received albeit perhaps not as intended, comes to mind. I hope DigiCert understands how that could be perceived by the community as a potentially bad faith act. This isn't about motives or intent however, but that an internal decision was made that caused integrity issues on this public forum. No one particularly cares to see two CAs throwing disparaging remarks at one another in public, but the move to involving legal is a major misstep. Comment 27.

We don’t know how often CAs send letters alleging violations of legal rights to each other as they are not publicly posted. We acknowledge this C&D was not a useful response to the concerns that triggered the letter. The incident report lays out our action plan to prevent a reccurrence.

To that end can we get an update on where DigiCert are with creating an incident report to explain what went wrong, and what steps have been put in place to stop this from reoccurring? CAs are generally self-regulated, but do take guidance from each other. Without a clear statement of how DigiCert's processes have improved since sending it, that letter risks lowering the standards that CAs are held to. Comment 27.

We have provided an action plan and incident report here. Please let us know if you have any additional suggestions.

Comment 30

[Wayne]

Thank you for providing the incident report which helps everyone understand the situation more thoroughly and avoids similar mistakes by other CAs.

For the contributing factors they seem to focus on external pressure (CF #1, Novelty of TRO), and perceived bias issues of a commenter (CF #2, Competition). As far a root cause analysis goes, it seems to lack any discussion of internal checks that were missed - but such issues are hinted at later in the report. Parargraph 4 of CF #2 states:

At the time, there was also significant disruption in leadership at DigiCert as the executive responsible for compliance and standards had resigned as a result of the mass revocation incident. This led to a major reorganization that disrupted DigiCert’s typical compliance workflows and approval process.

To me this sounds like one of the major root causes moreso than the TRO or the perception of a commenter at the time. Missteps in an organization happening while a major reorganization is occurring makes some sense. That it involved legal taking novel measures, and not just a missed step in procedural compliance or a missed reporting element is an oddity to me though. Perhaps other people can weigh in there.

The action items and plan going forward look promising. The main thing that jumps out to me is:

The C&D was sent by the DigiCert Legal team, which independently monitors Bugzilla comments on DigiCert incident reports

There is further mention of a decision to send the aforementioned letter.

From the perspective of another CA handling compliance, was this an issue of a legal team talking with - say - executive leadership and decisions being made without involving Compliance? I can't imagine that local counsel decided to look into this issue deeper without a hint of it existing, but in the context of the report given an unfortunate impression is made that they're acting on their own initiative.

I appreciate that DigiCert have changed their approach going forward, but in the context of a similar CA with DigiCert's processes 6 months ago what pitfalls existed internally that led to this scenario? Was it a lack of communication, or mixed signals that led to the initiative being taken? I presume this is the only letter sent, and there aren't any more surprises for anyone at DigiCert checking on their legal team for that time period?

I could see an off-hand comment in a monthly meeting leading to legal taking an overenthusiastic approach, and Compliance being blindsided to an extent. What I am curious about, however, is how other CAs can have similar issues in their decision-making structures and what DigiCert can inform us of ways to avoid it. Any opinion that can be stated on this front would be greatly appreciated.

Comment 31

[DigiCert]

Thanks Wayne. We appreciate the questions, in the hope of establishing clearer guidance for the community.

Question 1:  From the perspective of another CA handling compliance, was this an issue of a legal team talking with - say - executive leadership and decisions being made without involving Compliance?

Our Legal team already actively monitors Bugs generally, but was particularly sensitive to the revocation Bug because of the TRO and other legal issues that arose from the mass revocation. As noted in our earlier discussion, there were concerns by the Legal team of competitive targeting given the unusual frequency of Tim Callan’s comments on DigiCert’s Bugs and the fact that these comments elevated the TRO to a greater importance than it in fact played in the mass revocation. The Legal team did discuss sending the C&D with members of the Standards/Compliance teams, and members of these teams expressed reservations about sending it; but the Legal team made the decision to send it despite internal objections.

Question 2:  I appreciate that DigiCert have changed their approach going forward, but in the context of a similar CA with DigiCert's processes 6 months ago what pitfalls existed internally that led to this scenario? Was it a lack of communication, or mixed signals that led to the initiative being taken? I presume this is the only letter sent, and there aren't any more surprises for anyone at DigiCert checking on their legal team for that time period?

As previously noted, this event occurred during a change in leadership and a subsequent reorganization of roles, leading to a short-term disruption in communication and reporting lines. The changing roles and authority contributed to the C&D letter not being halted.

It should come as no surprise that DigiCert takes compliance and responses to Bugzilla seriously and shows concern when a competitor actively engages in our compliance reports, seemingly seeking to expand dialogue beyond the compliance issues at the heart of the reports.

Legal confirms that to our knowledge DigiCert has not sent other C&D letters to address activity on this forum. There have been other C&D letters sent by DigiCert to Sectigo in the past on other non-compliance subjects such as alleged misrepresentation in marketing.

Question 3:  What I am curious about, however, is how other CAs can have similar issues in their decision-making structures and what DigiCert can inform us of ways to avoid it. Any opinion that can be stated on this front would be greatly appreciated.

Our advice is that during incident reports, concerns about technical issues, misrepresentations, or policy violations related to compliance issues must be addressed on the corresponding Bugzilla and not through legal channels. Keep all relevant communication about the Bug in the Bug. If steps by any department are necessary outside of Bugzilla related to an active incident, the decision and action should be disclosed in the corresponding Bug and the community should be given a chance to participate in the discussion. The Mozilla community operates best when there is transparency of the facts and events related to incidents.

Comment 32

[DigiCert]

As noted in {Comment 29](https://bugzilla.mozilla.org/show_bug.cgi?id=1950144#c29), DigiCert is setting up an independent ombudsperson contact process within DigiCert that community members may use to confidentially raise concerns about DigiCert’s conduct in the WebPKI. We are in the process of investigating the best model for this implementation and will report when complete.

Comment 33

[mpalmer]

We hope that this incident report assures you that DigiCert believes strongly in open dialogue.

I'm afraid it does not. This legal threats bell, now that it has been rung, cannot be unrung. The only controls DigiCert is proposing to prevent future recurrence are DigiCert-internal policies, and I'm confident we're all aware of the significant limitations of policy-based controls on managing risk.

This gets to the heart of the question I asked previously, and which I don't consider to have been answered:

what steps does DigiCert recommend root programs take "to ensure such behavior is not repeated by any member of the community"?

I'd like to emphasise my interest in the "root programs" and "ensure" parts of that question.

If there are no steps DigiCert is willing to recommend, then I would prefer that the answer clearly express that, rather than attempt to deflect blame with insinuations of "competing agendas and conscious or unconscious motives to use the forum to advance their own business and competitive interests".

Some questions and observations on other aspects of DigiCert's recent responses:

As previously noted, this event occurred during a change in leadership and a subsequent reorganization of roles, leading to a short-term disruption in communication and reporting lines. The changing roles and authority contributed to the C&D letter not being halted.

The degree to which this one person's departure appears to have shaken DigiCert to its very foundations, and allowed lawyers to roam freely with no effective check on their activities, is somewhat concerning. What concrete steps has DigiCert taken to reduce the "bus factor" within the organisation, both in the immediate term, and to ensure that organisational changes in the future do not reintroduce such a weakness?

It should come as no surprise that DigiCert takes compliance and responses to Bugzilla seriously and shows concern when a competitor actively engages in our compliance reports

Competitors are the best people to actively engage in compliance reports, as they're the people who are most informed as to the nuances of the industry. The rest of us are mere dilettantes. I'd strongly recommend that DigiCert actively engage in other CAs' compliance reports. I'm sure DigiCert's experience in handling incidents could be put to good use.

On 2025-01-25, Entrust announced that Sectigo, who regularly commented on the bugs leading to Entrust’s distrust, acquired the Entrust client base. The pattern of events confirmed the validity of the Legal team’s concern as it showed that CAs can profit from their participation on a competitor’s bugs on Bugzilla and may have a direct adverse interest in the trust of other CAs.

I hate to be flippant here, but I can't think of a more politic way of putting this: was this entire chain of reasoning based on anything more than vibes and paranoia?

I have trouble seeing how comments on issues would cause a distrusted CA to decide to sell their customer base to the employer of the individual making the comments. If anything, I would have expected any resulting animus to have reduced the willingness to sell to that particular organisation.

Further, the suggestion that the distrust of Entrust was based on anything other than sound technical and procedural reasoning is astonishingly disrespectful to everyone involved in making the decision. Taking this statement at face value, it would seem that DigiCert believed that, if there were baseless accusations and bad-faith engagement in Bugzilla, that the WebPKI community and root programs would not be able to recognise it as such and either call it out or, at the very least, disregard it.

As far as I can see, the only entity involved in creating "a direct adverse interest in the trust of [Entrust]" was... Entrust! To the degree that others may have contributed, it could only be by identifying and highlighting Entrust's own actions.

DigiCert is setting up an independent ombudsperson contact process within DigiCert [...] We are in the process of investigating the best model for this implementation and will report when complete.

I look forward to seeing DigiCert's progress in this area. Given the extensive history of organisations being manifestly unable to maintain simultaneously the effectiveness and independence of an "internal affairs" or "whistleblower" type of unit, DigiCert's success in this endeavour would be a landmark in organisational accountability extending far beyond the realms of the WebPKI.

Given the nature of what has been given as one of the major contributors to this incident -- the unexpected departure of a single person -- I expect that the ombudsperson role will not be undertaken by a single person, but will be a shared responsibility.

Comment 34

[DigiCert]

Thanks for the feedback, Matt.

If there are no steps DigiCert is willing to recommend, then I would prefer that the answer clearly express that, rather than attempt to deflect blame with insinuations of "competing agendas and conscious or unconscious motives to use the forum to advance their own business and competitive interests".

This Bug was opened by Brian Holland. Questions from the community asked for information about why Legal sent the letter. The RCA explains why Legal believed that Sectigo’s active involvement in our incident reports was impermissible under applicable law, particularly in light of Tim Callan’s contemporaneous podcasts and public speeches. Our response was not to deflect blame but to answer the questions asked by the community about Legal sent the letter. While broad involvement is encouraged in the Mozilla community, we also recognize the potential for CAs to have conflicts of interest in doing so. That is what Legal believed was happening, so they sent the letter.

We have laid out clearly our commitments in Comment 31. If, as you request, we were to make suggestions for root policy, they would be aligned with our answer to Question 3 in that Comment.

The degree to which this one person's departure appears to have shaken DigiCert to its very foundations, and allowed lawyers to roam freely with no effective check on their activities, is somewhat concerning. What concrete steps has DigiCert taken to reduce the "bus factor" within the organization, both in the immediate term, and to ensure that organizational changes in the future do not reintroduce such a weakness?

The resignation of an Executive (and the primary driver of DigiCert’s incident reporting process) did require a reorganization that impacted several departments involved in this process, including Industry Standards and Compliance. Based on the reorganization, we updated our formal incident process, which includes a project manager and incident commander who track incidents and their remediations. Comments and dates are closely tracked by both roles. We have added formatting requirements to our incident response plan prefer a format for responses that first quotes the question and then provides the answer. This will help track answers across multiple posts. We’ve set additional internal SLAs for responding to questions and gathering information to better engage with the active discussion. In short, incident handling has been further formalized as a team process to avoid individual dependencies.

Our lawyers do not roam freely, though they are tasked with protecting the company, including the mitigation of meaningful risks. Sometimes their perspective and strategic preferences differ from individual teams like Standards. In that light, we described the concrete steps we are taking in Comment 31.

I hate to be flippant here, but I can't think of a more politic way of putting this: was this entire chain of reasoning based on anything more than vibes and paranoia?

Clearly the mass revocation event was a difficult situation which required the deep involvement of our entire management, including Legal. As we’ve noted, the reasoning behind the letter was not “vibes” but included consideration of Sectigo’s comments about Entrust on both Sectigo’s podcast and Entrust’s Bugs:

• https://www.sectigo.com/resource-library/root-causes-370-drama-on-bugzilla
• https://www.sectigo.com/resource-library/root-causes-372-bugzilla-bloodbath
• https://www.sectigo.com/resource-library/root-causes-377-is-cps-issuance-misalignment-a-revocation-event
• https://www.sectigo.com/resource-library/root-causes-378-why-are-forced-revocations-so-difficult
• https://www.sectigo.com/resource-library/root-causes-383-delayed-revocation-events-by-the-numbers
• https://www.sectigo.com/resource-library/root-causes-399-entrust-distrusted
• https://www.sectigo.com/resource-library/root-causes-409-mozilla-distrusts-entrust

Similarly, comments like Bugzilla 189848 Comment 11 concerned Legal regarding the intentions behind comments from representatives of Sectigo.

Given the nature of what has been given as one of the major contributors to this incident -- the unexpected departure of a single person -- I expect that the ombudsperson role will not be undertaken by a single person but will be a shared responsibility.

We will soon provide more details on the Ombudsperson approach. However, we confirm that the task will be handled by a group, shared across different functions within DigiCert.

Comment 35

[DigiCert]

Action Item Update

We have finalized implementation of our Ombudsperson program. We will have a four person team which can be reached at [e-mail]. This group is currently made up of representatives from the Program Management, Compliance and Legal departments.

Comment 36

[DigiCert]

Report Closure Summary

Incident description: On November 11, 2024, a law firm retained by DigiCert sent a Cease & Desist letter (C&D) to Sectigo based on comments made by a Sectigo representative related to the Temporary Restraining Order (TRO) in relation to Bugzilla 1910805.

The C&D specified that Sectigo’s Tim Callan made several false or misleading statements with respect to the TRO and DigiCert’s operations. DigiCert Legal sent the C&D but did not sufficiently consider the potential effect that a C&D could have on the community’s communication on Bugzilla and other forums.

DigiCert acknowledges that a more transparent and community-friendly path would be preferred to address the perceived Sectigo misrepresentations publicly in the context of Bugzilla, rather than pursuing the private path with the C&D.

Legal confirms that DigiCert has not sent other C&D letters to address activity on this forum. There may have been other C&D letters sent by DigiCert to Sectigo in the past on other subjects such as alleged misrepresentation in marketing.

Incident Root Cause(s):

Contributing Factor #1: Novelty of TRO

The revocation event covered in Bugzilla 1910805 was a significant event for DigiCert, which led to an overall re-stating in the industry of deadlines for revocations and clarification that there are no exceptional circumstances allowing for extension of the revocation deadlines defined in the BR.

DigiCert was faced with many claims of exceptional circumstances during the revocation, including the TRO. The TRO played a limited role in the mass revocation but was disclosed as part of DigiCert’s commitment to transparency.

Contributing Factor #2: Competition

While CCADB policy encourages individuals affiliated with publicly-trusted CAs to participate in Bugzilla, this participation can contribute to competitive tension.

Of Tim Callan’s 24 Bugzilla comments in the period covered by this incident report, 18 were directed towards DigiCert Bugs. DigiCert Legal viewed the frequency of Tim Callan’s DigiCert-directed comments as potentially competitively motivated.

At the time, there was also disruption in leadership at DigiCert as the executive responsible for compliance and standards had voluntarily resigned as a result of the mass revocation incident. This led to a reorganization that disrupted DigiCert’s typical compliance workflows and approval process.

Remediation description:

Our action plan lays out our intent to foster transparency when legal activities intersect with incident reports. In addition, Bugzilla may consider policies requiring participants making comments on Bugzilla incidents to state their potential conflicting interests.

Action Items 

 

 | Action Item | Kind    | Corresponding Root Cause(s) | Evaluation Criteria | Due Date   | Status | 

| ----------- | ----    | --------------------------- | ------------------- | -----------| ------ | 

| Technical-First Dispute Resolution: During incident reports, concerns about technical issues, misrepresentations, or policy violations related to compliance issues must be addressed on the corresponding Bugzilla and not through legal channels. The Legal team may address items related to misrepresentations, fraud, and trademark abuse that are not part of an active incident.<p>If legal steps are necessary related to an active incident, the decision and action will be disclosed in the corresponding Bugzilla. | Prevent | Overall | NA | 2025-04-04 | Done  | 

| Community Transparency Pledge: Communication related to incidents will be handled in the open, using community forums (e.g., MDSP, CCADB, CAB Forum, Bugzilla) to provide traceability and prevent misunderstandings. This includes important mass customer communication related to the incident. <p>Outreach to commenters about statements or allegations should be documented and posted to incidents as appropriate to avoid surprises or perceived retaliation.| Mitigate | Overall | NA | 2025-04-04 | Done  | 

| Legal Review Gate: Executive-level review and approval will be sought for legal actions that intersect with an incident, which will include an analysis showing the legal action is appropriate. <p>Public notice will be provided of legal actions related to an incident where possible. Where immediate public notice is not possible, DigiCert will provide private notification to root programs with a later public follow-up. | Prevent | Overall | NA | 2025-04-04 | Done  | 

| Ombudsperson Role for WebPKI Concerns: DigiCert will designate an independent ombudsperson team within DigiCert that community members may contact confidentially to raise concerns about DigiCert’s conduct in the WebPKI especially around fairness, openness, or perceived intimidation. | Prevent | Mitigate | NA | 2025-05-01 | Done  | 

 

Commitment summary:

Despite the actions above being listed as “done”, they are intended to represent a different path forward that DigiCert will use in the future for similar disputes that may arise within the WebPKI community.

All Action Items disclosed in this report have been completed as described, and we request its closure.

Comment 37

[J. Bentham]

It’s widely known that the “executive” who supposedly took "accountability" and resigned never actually severed ties with DigiCert, making it difficult to believe there was any genuine confusion as written above.

Concealing that fact and presenting the "resignation" as genuine is simply dishonest.

Given that the CEO, Amit Sinha—who is this executive’s direct manager—allowed him to remain involved while giving the impression that he had stepped away, and also permitted the questionable letter to be released, the Ombudsperson proposal is effectively dead on arrival. Unless the Ombudsperson includes a member from an external entity—ideally from this community—and has no financial ties to DigiCert, it will lack any credibility.

The only thing that’s certain is that the attempts to close the bug without offering a substantive solution have become a recurring pattern.

Comment 38

[Jeremy]

It’s widely known that the “executive” who supposedly took "accountability" and resigned never actually severed ties with DigiCert, making it difficult to believe there was any genuine confusion as written above.

As the “executive” I think you’re referring to, I’ll say that this “widely known” source is wrong. For transparency, in July 2024, I resigned, effective immediately. At that time, my responsibilities included security, customer relationships, compliance, industry standards, and some internal operations (like key ceremonies). These teams were assigned to other executives, which I imagine was at least somewhat disruptive. DigiCert also asked me to stay temporarily as a contractor to assist with customers that I had a relationship with and to provide domain knowledge on internal operations. As an independent contractor my focus was to transition all responsibilities to other employees.

At the end of the transition period, DigiCert requested that I return in a different role. This new role is not an executive role and has two different responsibilities: addressing customer satisfaction with DigiCert’s services and DigiCert’s internal PKI operations. I am not part of the incident response team and all posts on Bugzilla and MDSP are in my personal capacity. I participate here because I like Mozilla and its mission. I haven’t reported to Amit or been on the executive team since I originally resigned last year.

This comment also seems extremely off-topic for this bug (and a possible code of conduct violation). If you want to know more about what I did during those six months (it involves a board game and culinary school) or why I decided to rejoin DigiCert as an employee, feel free to ping me on separate channel or LinkedIn. I like to be transparent in what I do.

Comment 39

[DigiCert]

In response to comment 37

Hi J. Bentham – Thank you for sharing your concerns. I’d like to correct a few misconceptions in your post above.

The executive in charge of compliance and security tendered his resignation in July 2024. On September 2, 2024, he began a contractor role with significantly reduced scope compared to his prior executive position. In this new consulting arrangement, he no longer had a reporting relationship to CEO, Amit Sinha.

On March 10th, 2025, the same person rejoined DigiCert as an fullnew, this time employee in a different role. His focus is on customer engagement and internal PKI activities and does not report to the CEO.

Additionally, the CEO had not read nor “permitted the questionable letter to be released” before it was sent. To reiterate what’s already been communicated: “The C&D was sent by the DigiCert Legal team, which independently monitors Bugzilla comments on DigiCert incident reports." comment 29.

Supporting our goals of transparency and positive engagement in the webPKI, we are open to considering the inclusion of a third-party community member as part of the Ombudsperson team.

Comment 40

[mpalmer]

On April 16, DigiCert wrote:

We will soon provide more details on the Ombudsperson approach.

On April 23, DigiCert wrote:

We have finalized implementation of our Ombudsperson program. We will have a four person team which can be reached at [e-mail]. This group is currently made up of representatives from the Program Management, Compliance and Legal departments.

After prompting from a member of the community, and after requesting closure of this incident, on May 2, DigiCert wrote:

we are open to considering the inclusion of a third-party community member as part of the Ombudsperson team.

So far as I can see, these two statements are the only new information that DigiCert has presented regarding this new Ombudsperson role.

Whilst it is technically true that these do "provide more details" (insofar as DigiCert had not previously disclosed the contact email address, participant count, or departmental affiliation) does DigiCert really expect that the community will be satisfied with such scant information about what is the closest thing to a meaningful protection that DigiCert has offered, against further legal threats and other methods of stifling participation in the Mozilla trust store community?

Further, can DigiCert explain how the process by which this Ombudsperson role was setup can be in any way considered trustworthy by the community, when this process did not even apparently go as far as to consider whether a person from outside DigiCert might be a valuable inclusion, until it was suggested by a member of the community?

I've participated in numerous Bugzilla and mdsp conversations over the years, and read many, many more, and there's a consistent theme I've identified that separates trustworthy CAs from untrustworthy CAs (particularly those who later went on to be distrusted): the trustworthy CAs volunteered information and went out of their way to share -- perhaps even overshare -- information, in a way that was still comprehensible to the audience. The untrustworthy CAs either info-dumped in formats that were difficult to read and understand (for reasons of formatting or information architecture), or did not volunteer information and needed to be repeatedly prompted for even the most basic additional information, and were generally reticent to share anything, often failing to answer even the most simple questions in a helpful fashion.

Comment 41

[J. Bentham]

(In reply to Jeremy from comment #38)

As the “executive” I think you’re referring to, I’ll say that this “widely known” source is wrong. For transparency, in July 2024, I resigned, effective immediately. At that time, my responsibilities included security, customer relationships, compliance, industry standards, and some internal operations (like key ceremonies).

You were in a role that could have minimized the disruption as a contractor, yet DigiCert kept that fact secret until now and is now citing your departure as the cause of the disruption.

I am not part of the incident response team and all posts on Bugzilla and MDSP are in my personal capacity. I participate here because I like Mozilla and its mission.

If DigiCert permits you to participate in this community, your comments are no longer purely personal. And if, as you claim, you are merely “freely roaming” this community, then DigiCert clearly has a governance problem—especially given how crucial this community is to its business. Frankly, that’s hard to believe.

This comment also seems extremely off-topic for this bug (and a possible code of conduct violation).

I’m not concerned with why you returned or what your current role is—that’s off-topic. What matters is that Amit reinstated you despite knowing what happened; that decision is directly relevant and warrants scrutiny. And yes, any violations of the code of conduct or ethics should be discussed openly here.

feel free to ping me on separate channel or LinkedIn. I like to be transparent in what I do.

I have no interest in discussing this privately. This conversation must remain public so the community is fully informed about what actually happened. Your notion of transparency seems rather misplaced.

Comment 42

[J. Bentham]

(In reply to DigiCert from comment #39)

Thank you for the belated transparency. This should have been explained sooner, though I understand you withheld it because it served as an excuse for the disruption.

On March 10th, 2025, the same person rejoined DigiCert as an fullnew, this time employee in a different role. His focus is on customer engagement and internal PKI activities and does not report to the CEO.

It seems a great deal of that “focus” is directed at this forum.

Additionally, the CEO had not read nor “permitted the questionable letter to be released” before it was sent. To reiterate what’s already been communicated: “The C&D was sent by the DigiCert Legal team, which independently monitors Bugzilla comments on DigiCert incident reports." comment 29.

Thank you for clarifying. Unfortunately, this also exposes a broader governance problem: if a cease-and-desist letter can be sent to one of your largest competitors without the CEO’s knowledge, DigiCert has a serious governance issue—casting doubt on whether the Ombudsperson programme can function as intended.

Simply “monitoring” Bugzilla comments and unilaterally sending a C&D are two very different actions.

Supporting our goals of transparency and positive engagement in the webPKI, we are open to considering the inclusion of a third-party community member as part of the Ombudsperson team.

That is a welcome gesture, but—as Matt pointed out—the real issue is DigiCert’s attitude. Superficial fixes and empty promises do nothing to build trust; far more substantive effort is required.

On that note, comment #38 came across as an attempt to silence and intimidate—with phrases like “extremely off-topic,” “code-of-conduct violation,” and “ping me on a separate channel.” That made me uncomfortable. DigiCert representative, are you truly comfortable with this approach? I assume not, given how quickly you stepped in.

Comment 43

[DigiCert]

… does DigiCert really expect that the community will be satisfied with such scant information about what is the closest thing to a meaningful protection that DigiCert has offered, against further legal threats and other methods of stifling participation in the Mozilla trust store community?

The process by which DigiCert will handle legal activity pertaining to Bugs moving forward is described in detail in our Report Closure Summary. We believe that the transparency described in that approach is a meaningful commitment to the Mozilla community.

Further, can DigiCert explain how the process by which this Ombudsperson role was setup can be in any way considered trustworthy by the community, when this process did not even apparently go as far as to consider whether a person from outside DigiCert might be a valuable inclusion, until it was suggested by a member of the community?

Bugzilla serves as an external accountability mechanism for CAs working in the WebPKI, and is the best forum for identifying systemic issues and providing recommendations. The Bugzilla forum provides transparency and allows the participation of a broad spectrum of opinions and interests.

In addition, the DigiCert Ombudsman will offer a structured mechanism for raising concerns specifically about DigiCert’s conduct in the Mozilla community. It is designed to ensure concerns are reviewed with appropriate visibility and seriousness across senior leadership—not dismissed or narrowly categorized.

Summary of the DigiCert Ombudsman Process:

1. Contact Method: Community members will be able to contact the Ombudsman at [e-mail]. This contact information will be documented in the DigiCert Certificate Practice Statement (CPS) in a future update. Submissions will be acknowledged within 24 hours.

2. Scope: The Ombudsman process will specifically address DigiCert's corporate conduct within the Bugzilla community relating to fairness and transparency matters. The Ombudsman will not handle matters outside this scope. Additionally, the Ombudsman is not intended to replace or limit other dialogue occurring on Bugzilla.

Submissions to the Ombudsman should include specific details regarding the concern, including dates, relevant interactions, individuals involved, supporting documentation or evidence, the perceived impact of the issue, any prior attempts at resolution, and the correspondent’s desired outcome.

Communications to the Ombudsman will not constitute official legal notice or a customer support channel. However, correspondents may be referred internally as needed.

3. Team Composition: The Ombudsman team includes senior representatives from DigiCert's Legal, Compliance, and Industry Standards departments. DigiCert is evaluating the addition of an external representative to strengthen the independence of the Ombudsman. The team will address:

   • Review and clarification of the submission;

   • Interviews as needed;

   • Preparation of a final report.

4. Resolution Methods: The Ombudsman may recommend resolution through mediation, a written recommendation, or formal findings. The Ombudsman will typically coordinate this within 30 business days of the initial report, or agreement between parties.

5. Confidentiality: The identities of correspondents will be kept confidential within the Ombudsman team. If public statements are made in response to concerns, no identifying information will be disclosed without explicit permission.

Comment 44

[DigiCert]

Responding to J. Bentham’s Comment 41

On the topic of Jeremy’s participation in industry conversations, it is important to emphasize that Mozilla has a long-established tradition of encouraging affiliated individuals to also participate in their personal capacity, as described here.

Responding to J. Bentham’s Comment 42

It seems a great deal of that “focus” is directed at this forum.

Please see our response to Comment 41.

Thank you for clarifying. Unfortunately, this also exposes a broader governance problem: if a cease-and-desist letter can be sent to one of your largest competitors without the CEO’s knowledge, DigiCert has a serious governance issue.

DigiCert’s Chief Legal Officer is tasked with directing legal activities of the company. We have described in Comment 36 how we will handle these legal activities when they intersect with current Bugzilla reports going forward.

On that note, comment #38 came across as an attempt to silence and intimidate—with phrases like “extremely off-topic,” “code-of-conduct violation,” and “ping me on a separate channel.” That made me uncomfortable. DigiCert representative, are you truly comfortable with this approach? I assume not, given how quickly you stepped in.

We believe Jeremy attempted to constructively answer questions that were posed, from his personal perspective.

Comment 45

[DigiCert]

We are currently working through the logistics of exactly how we could include an external person as part of our ombudsman team. This is a non-trivial effort, as to the best of our knowledge no other Certification Authority has ever previously set up such a process to resolve external inquiries, even without including an external member.

We are planning to have a proposal ready by the end of June, so we would like to request a next update date around then to allow us to concentrate on refining the proposal.

Comment 46

[JR Moir]

(In reply to DigiCert from comment #45)

We are currently working through the logistics of exactly how we could include an external person as part of our ombudsman team. This is a non-trivial effort, as to the best of our knowledge no other Certification Authority has ever previously set up such a process to resolve external inquiries, even without including an external member.

We are planning to have a proposal ready by the end of June, so we would like to request a next update date around then to allow us to concentrate on refining the proposal.

Yes, no other CA has this 'ombudsman' because no other CA has needed it. No other CA has tried to silence another, no other CA repeatedly attempts to ignore questions or offer policitian-like excuses to simple questions.
No other currently-trusted CA is large and yet still failing as much as Digicert are, and I hope and trust that Mozilla and other trust programms are paying attention and considering action to ensure you cannot carry on operating as you do.

Comment 47

[DigiCert]

We have a different perspective. We are working on the ombudsman process because we think this is something that all CAs should have. We are even considering introducing such a proposal at the CA/Browser Forum, so that all CAs have appropriate mechanisms to resolve disputes like this.

We take our responsibilities to the forum very seriously, and so we carefully review all our answers for accuracy and aim to provide the highest quality answers possible.

Comment 48

[amir]

I hope other CAs and root programs introduce proposals that puts a CA on a fast path for distrust when that CA uses legal threats to silence scrutiny of a CA.

I think that proposal would have a significantly better outcome for trust in WebPKI. Unfortunately, since I’m only an interested third party, I won’t be able to put this proposal forward. I hope this message acts a catalyst to consider options to strongly discourage a CA from pursuing legal pathways in WebPKI and compliance related disputes.

Comment 49

[JR Moir]

(In reply to DigiCert from comment #47)

We have a different perspective. We are working on the ombudsman process because we think this is something that all CAs should have. We are even considering introducing such a proposal at the CA/Browser Forum, so that all CAs have appropriate mechanisms to resolve disputes like this.

We take our responsibilities to the forum very seriously, and so we carefully review all our answers for accuracy and aim to provide the highest quality answers possible.

Could Digicert help us understand why they think it would be a good idea to propose to the CA./BrowserForum that all CAs have to have a 'ombudsman' contact?
Only one CA seems to feel it was 'needed'.
That CA caused the problem, 100% of their own fault, that made them feel the ombudsman was 'needed'.

I think Digicert must better explain why they feel every CA must add an additional process which currently has no proven value, and for a problem entirely the fault of Digicert.

(In reply to amir from comment #48)

I hope other CAs and root programs introduce proposals that puts a CA on a fast path for distrust when that CA uses legal threats to silence scrutiny of a CA.

I think that proposal would have a significantly better outcome for trust in WebPKI. Unfortunately, since I’m only an interested third party, I won’t be able to put this proposal forward. I hope this message acts a catalyst to consider options to strongly discourage a CA from pursuing legal pathways in WebPKI and compliance related disputes.

I agree with Amir.
Browsers only have one choice for punish for CAs like Digicert who are failing the webpki.
A distrust of Digicert like Entrust seem like a 'too big to fail' concern. I have felt disruption with my clients from distrust and I think a distrust of Digicert would be bad for many and not a good idea.
But the bad practices and avoiding of answers by Digicert cannot go with no action.
I hope the browsers have plans to build process to make CAs better with less problems for millions of subscribers.

Comment 50

[J. Bentham]

(In reply to DigiCert from comment #47)

We have a different perspective. We are working on the ombudsman process because we think this is something that all CAs should have. We are even considering introducing such a proposal at the CA/Browser Forum, so that all CAs have appropriate mechanisms to resolve disputes like this.

We take our responsibilities to the forum very seriously, and so we carefully review all our answers for accuracy and aim to provide the highest quality answers possible.

You might claim to aim for high-quality answers, but the results speak for themselves—and they fall noticeably short.

The statement “all CAs should have” an ombudsman process comes across as a diversion tactic. DigiCert hasn’t even proven its own process works, let alone earned the credibility to propose it as a model for others.

If you truly took your responsibilities here seriously, you wouldn't need to be repeatedly corrected by the community. The pattern of evasive and poorly substantiated responses undermines any claim of careful review or good faith.

The word "distrust" has an original meaning, and that meaning still applies—even without capital-D "Distrust"—regardless of how the ruling turns out.

I also agree with Amir.

Comment 51

[mpalmer]

On the 19th of May, DigiCert wrote:

We are currently working through the logistics of exactly how we could include an external person as part of our ombudsman team. [...] We are planning to have a proposal ready by the end of June, so we would like to request a next update date around then to allow us to concentrate on refining the proposal.

Assuming "the end of June" means "June 30", then that indicates that DigiCert estimates it will take their full concentration for 42 calendar days to work through the logistics of including an external person in their ombudsperson team.

Further, the inclusion of an external member in the ombudsperson role was first mentioned by DigiCert on the 2nd of May, so it's not unreasonable to assume that there had been at least some measure of evaluation of such a possibility as of that date -- 59 calendar days, by my count, before DigiCert believes they will be able to deliver such an outcome.

The first mention of any sort of Ombudsperson was on the 4th of April, when the creation of such a role was listed as "Underway". The team was reported as having been "finalised" on the 29th of April. The duration between these two dates is, if I'm counting correctly, 25 calendar days.

Whilst it is certainly possible that DigiCert had been working diligently on such a role for some time prior to the posting of the incident report, I can find no evidence in this bug of such work prior to the 3rd of April, in which DigiCert says that they are "working on a post". I certainly don't think it credible to assume that DigiCert were working on an ombudsperson role before March 19, as they asked for the bug to be resolved, with the statement "DigiCert has no additional comments on this matter".

Assuming, to be maximally generous, that DigiCert had a change of heart immediately after March 19, and immediately started working on the ombudsperson role, that would mean they had, by my count, 41 days to go from "hey, maybe we should have an ombudsperson" to a complete, functional ombudsperson role, with all processes and procedures fully defined and tested.

My question for DigiCert is thus: please explain how DigiCert is able to fully conceive, define and implement an entire ombudsperson role -- a function that, by DigiCert's own assertion, has never previously existed at any WebPKI CA -- in no more than 41 calendar days (and possibly as few as 25 calendar days), and yet it will require DigiCert somewhere between 42 and 59 calendar days to adjust that role to include an external person?

Also, I call on DigiCert to publicly provide all documented policies and procedures relating to the ombudsperson role, as currently constituted, with annotated redactions where absolutely necessary, to allow the WebPKI community to satisfy themselves that the role, as it currently exists, can deliver on the assertions made by DigiCert. Given that such documentation must already exist, produced as part of the work required to properly define and implement an ombudsperson role, I believe this documentation should be able to be presented within a few days, and should not significantly detract from the effort being devoted to modifying the role to include an external person.

Comment 52

[DigiCert]

With respect to the time required to create an ombudsman process, we want to create a productive process that remediates concerns identified on this bug. We are taking the ombudsman program seriously. We have been consulting a number of sources and case studies for information, looking for best practices. One of the sources we’ve found extremely valuable is Frank Fowlie’s PhD thesis research on the ICANN Ombudsman office: https://www.icann.org/en/system/files/files/blueprint-for-evaluation-of-an-ombudsman-nov08.pdf. Here, ICANN created a process to address issues in a similar space, showing that something like this can be done and has provided value. However, it is a fair amount of work to distill the relevant information and determine how it can be appropriately applied to this context.

We’ve started the process of doing some dry runs to make sure there are no kinks or unexpected challenges with the processes and infrastructure we have already set up. As mentioned in the thesis, an iterative approach involving continuous improvement is essential to the success of a program like this, so we are first focused on getting the infrastructure set up, personnel assigned, and making sure that any requests we receive can be handled within the SLAs we are putting in place.

With respect to the suggestion that DigiCert is the only CA that needs this process, most of us who have been in the industry quite a while know that is unfortunately not true. Even the TLS working group at IETF has recognized that behavior in the PKI and encryption industry is not where it needs to be, and is working on improving the nature of the dialogue there to be more professional and respectful. We support the emerging trend towards more constructive dialogue in our industry, and regret cases like this one where we have fallen short of being a positive contributor towards making the industry better. We are building out this ombudsman program because we strongly believe that a healthy relationship with the community and strong, positive contributions are the way forward, and we would love to collaborate and share our experiences with other CAs who would like to set up a similar program voluntarily or otherwise.

Comment 53

[JR Moir]

I still do not believe an ombudsman process is needed. To repeat: this incident was caused entirely by DigiCert, and affects only DigiCert.
Saying industry-wide ombudsmen is an over-reaktion.

The comparison to ICANN or other groups is incorrect, as none of those have public forum and incident reporting like CCADB, here Bugzilla.

Question: When did DigiCert decide an ombudsman was a good idea for the web-PKI? Before or after they sent a legal note to start this problem and this incident?

I also think direct replies to mpalmer's questions are required in the next day.

Comment 54

[mpalmer]

Like JR Moir, I don't consider DigiCert's reply to be responsive to my question -- a pattern which is nearly universally repeated throughout this incident. Failing to even provide an attempt at answering a direct question does not, to my mind, "aim to provide the highest quality answers possible", as DigiCert has claimed to do.

I also find it difficult to find relevance in DigiCert's assertion that creating an ombudsperson is "a fair amount of work to distill the relevant information and determine how it can be appropriately applied to this context". I would have expected that this "fair amount of work" was already completed, given that DigiCert stated that the creation of an ombudsperson role was "done" on April 29. Is that not the case? If it is, what is the purpose of making that statement at this time? Otherwise, why was this work not undertaken prior to claiming that the creation of an ombudsperson role was "done" over a month ago?

Comment 55

[DigiCert]

Response to Questions

Hi Matt,
We hear your concerns and appreciate you bringing them up in this forum. We believe our previous response addressed your questions. However, in the interest of being specific, here is a response structure we plan to adopt moving forward that attributes clearly to the comments and questions it addresses.

Header of Response: Response addresses Comment 51 and Mpalmer’s questions within the comment

Q1
please explain how DigiCert is able to fully conceive, define and implement an entire ombudsperson role -- a function that, by DigiCert's own assertion, has never previously existed at any WebPKI CA -- in no more than 41 calendar days (and possibly as few as 25 calendar days), and yet it will require DigiCert somewhere between 42 and 59 calendar days to adjust that role to include an external person?

DigiCert Response #1

In implementing the ombudsman process, we are using a phased approach based on continuous improvement, as we do for all our processes. The initial phase includes testing the intake triage, investigation and response stages and we will continue to evaluate the readiness of the process for external member inclusion. As we noted in comment 45, working with an external third-party needs a formalized process with logistics and other considerations.

Q2
Also, I call on DigiCert to publicly provide all documented policies and procedures relating to the ombudsperson role, as currently constituted, with annotated redactions where absolutely necessary, to allow the WebPKI community to satisfy themselves that the role, as it currently exists, can deliver on the assertions made by DigiCert. Given that such documentation must already exist, produced as part of the work required to properly define and implement an ombudsperson role, I believe this documentation should be able to be presented within a few days, and should not significantly detract from the effort being devoted to modifying the role to include an external person.

DigiCert Response #2

We have been able to test our ombudsman SOP by simulating a few situations where the process may be leveraged. Should we receive any requests for intake in the future, the process will be further utilized and optimized.

Here is the latest version of the operating procedures:

DigiCert Ombudsman Office Operating Procedures
Background and Program Introduction
In response to Bug 1950144, DigiCert is implementing a comprehensive Ombuds program to address community concerns and enhance transparency within the WebPKI ecosystem.

This program creates an essential bridge between DigiCert and offers a confidential, impartial channel for addressing concerns about DigiCert’s conduct. The Ombuds office ensures DigiCert remains accountable to community interests and responds proactively to community concerns. The Ombuds office is distinctly different from the Bugzilla forum. It has been created to review community concerns about our conduct in public forums.

The four foundational principles for the Ombudsman program include:

• Accountability – Taking responsibility for our actions and their impact on the community

• Responsiveness – Providing timely attention to concerns and meaningful follow-through

• Effectiveness – Delivering concrete resolutions that address root causes

• Neutrality – Taking an unbiased approach to proactively solving community concerns regarding conduct

The Ombuds office represents DigiCert’s commitment to fostering genuine dialogue, rebuilding trust and driving continuous improvement through unfiltered community feedback.

Scope

The DigiCert Ombudsman Program is a transparent, and community-responsive mechanism for handling reported issues with DigiCert’s conduct within the WEBPKI community as a Certificate Authority (CA) but excluding technical issues better suited for Bugzilla. This process enables any stakeholder—be it a customer, browser vendor, security researcher, or member of the public—to submit a complaint or concern regarding DigiCert’s conduct. The ombudsman's office investigates such concerns and recommends remedial actions where necessary.

Standard Operating Procedures
The DigiCert Ombudsman submission process has been designed to collect community concerns and ensure quality documentation. Complaints, concerns or feedback can be submitted to the dedicated email address [e-mail]. This email address is operational during standard business hours (9 am to 5 pm CT) Monday through Friday.

• Initial intake and acknowledgement: All concerns submitted through [e-mail] receive acknowledgement within one business day of receipt. This acknowledgement confirms that the submission has been received and outlines initial process expectations. Acceptable submitters include DigiCert customers, browser vendors, industry stakeholders, and the public. Anonymous complaints may be accepted but may limit the scope of the investigation. Submissions must include:

  • A description of the issue

  • Relevant supporting evidence or documents (if available)

  • Potential outcome or resolution sought

• Transparent case tracking: Each concern will receive a unique case identification number. This tracking number will serve as the primary reference number through the resolution process and will be included in all communication.

• Documentation: During intake, DigiCert will populate a formatted template with the information given. Template will include fields for parties involved, description, relevant dates and timelines, supporting documentation, potential outcome and initial severity level. Additional fields for previous related incidents and relevant policy or procedural references are also included.

• Initial classification and routing: Following documentation, each case will be classified based on complexity, subject matter expertise, and potential community impact. Investigator will be assigned.

• Investigation: Investigations are conducted by the ombudsman's office. The assigned investigator may:

  • Interview with relevant parties

  • Review internal documents and logs

  • Compare conduct to industry standards and policy requirements (e.g., CA/B Forum, Mozilla Root Store Policy)

  All proceedings are confidential unless disclosure is needed for resolution or public accountability. Investigation duration is estimated at 30 calendar days, with possible extension if complexity requires it.

• Communication: Within 48 hours of initial submission, submitters will receive a communication outlining the assigned case number, expected timeline for initial assessment and next steps in the investigation process. Until resolution, the submitter will receive a case update every 7 days. Submitters can contact DigiCert through the [e-mail] alias at any time to ask for case updates or provide additional information.

• Resolution: The ombudsman issues a written report with findings of fact, analysis of relevant standards or policies and recommendations for remedial action (if warranted. The report is shared with:

  • The submitter (full or redacted version)

  • DigiCert’s senior management

  Remedies may include:

  • Apology or explanation

  • Process or policy changes.

  • Public correction or transparency report update.

  • Submitters can submit feedback on how the case was handled, as part of continuous improvement.

Comment 56

[DigiCert]

This response is for Comment 53 and addresses questions within that comment.

JR Moir asked in Comment 53:

Question: When did DigiCert decide an ombudsman was a good idea for the web-PKI? Before or after they sent a legal note to start this problem and this incident?

The “legal note” you mention we assume refers to the letter we sent to Sectigo, which was attached by Brian Holland to the original report of this Bug. If that is the correct reference, DigiCert proposed the Ombudsman after sending that letter, in its response to this incident. For the evolution of the subject, please see Comment 29 with further detail in Comment 43 and Comment 55.

This response is for Comment 54 and addresses questions within that comment.

mpalmer asked in Comment 54:

I would have expected that this "fair amount of work" was already completed, given that DigiCert stated that the creation of an ombudsperson role was "done" on April 29. Is that not the case? If it is, what is the purpose of making that statement at this time? Otherwise, why was this work not undertaken prior to claiming that the creation of an ombudsperson role was "done" over a month ago?

The execution of the concept, as described in Comment 55, has progressed considerably, and we believe has improved, based on feedback received from the community, including from mpalmer and others.

Indeed, in Comment 35, we noted that we had finalized implementation of the Ombudsman program. To clarify that report, we had implemented the internal mechanisms such as tasking personnel with the Ombudsman function, and setting up the intake process for receiving, dealing with, and responding to concerns.

After that report, there has been subsequent dialogue on this Forum, and we have further developed the Ombudsman program based on our research and that community feedback. To specifically answer your questions:

(1) “Is that not the case?”

As noted, the Ombudsman program was internally implemented at the time of Comment 35, but has further developed since then;

(2) “... what is the purpose of making that statement at this time?”

We made the statement in Comment 35 to reflect the internal processes we had set up by the time of that report: to inform the community that an Ombudsman function had been created, with responsible personnel and a process for handling concerns, along with a contact email address to initiate a concern;

(2) “... why was this work not undertaken prior to claiming that the creation of an ombudsman role was ‘done’ over a month ago?”

This work was not undertaken before our report of the implementation of the program because it resulted from subsequent discussions that led to an improvement of the program.

Comment 57

[mpalmer]

We believe our previous response addressed your questions.

On what basis does DigiCert hold that belief? For the avoidance of doubt, that is not a rhetorical question -- I would like a meaningful response. (I was going to write that I "expect" a meaningful response, but that wouldn't be accurate; expecting a meaningful response at this point would be bordering on delusional, given the evidence so far)

There are several questions I have asked in this issue that DigiCert has not even responded to, and the questions that have some sort of response have not, on the whole, been addressed in any meaningful fashion. The "answers" given have been, for the most part, entirely in the style of a politician at a press conference: ignore the substance of the actual question, and just saying something vaguely pleasing to the ear, in the hope that the questioner will not be willing or able to press the question.

Overall, the behaviour of DigiCert in this issue has not been that of an organisation worthy of trust. Whilst I don't expect Mozilla to actually impose any meaningful sanctions on DigiCert as a result of their behaviour, I feel it is important to make it abundantly clear that, as a relying party, I am of the opinion that DigiCert's behaviour is unacceptable.

Comment 58

[Max D]

I would like to test the 'transparency' ombudsman.
I have emaield them. We will see how they reply. My information will be posted here publicly soon.

Comment 59

[DigiCert]

In response to comment 57:
We believe your question in comment 57 is referencing our response in [comment 55]:

We believe our previous response (referring to comment 52) addressed your questions.

The question in 57 asks:

On what basis does DigiCert hold that belief?

Comment 55 was a reply to your comment 54, which was in turn a response to our Comment 52 which was in response to a single question you asked in comment 51:

My question for DigiCert is thus: please explain how DigiCert is able to fully conceive, define and implement an entire ombudsperson role -- a function that, by DigiCert's own assertion, has never previously existed at any WebPKI CA -- in no more than 41 calendar days (and possibly as few as 25 calendar days), and yet it will require DigiCert somewhere between 42 and 59 calendar days to adjust that role to include an external person?

We don’t have an additional response beyond the one provided in comment 52, which we believe answers your question. Additional details were provided in [comment 55] (https://bugzilla.mozilla.org/show_bug.cgi?id=1950144#c55).

Comment 60

[mpalmer]

I wish to make it clear that I still feel I have not received information from DigiCert sufficient to address the questions I have asked in this issue. However, given DigiCert's assertion that they "don't have an additional response", I am going to cease asking any more questions, or pressing for answers to my existing questions, as I have formed the opinion that further participation in this issue will not yield useful information.

Comment 61

[J. Bentham]

(In reply to mpalmer from comment #60)

I wish to make it clear that I still feel I have not received information from DigiCert sufficient to address the questions I have asked in this issue. However, given DigiCert's assertion that they "don't have an additional response", I am going to cease asking any more questions, or pressing for answers to my existing questions, as I have formed the opinion that further participation in this issue will not yield useful information.

Matt, that’s been DigiCert’s playbook all along—and exactly what they’re counting on.

Not to provide real answers, but to exhaust the inquirer. The strategy is simple: respond with verbose, substance-light commentary to drain momentum and stall any real progress.

Then, after a few days of silence, politely circle back with,
“Can we close this bug?”

Comment #59 is a textbook example.
Despite knowing your concerns remain unresolved, shamelessly points to the same inadequate answers from earlier—as if repetition might somehow substitute for resolution.

Comment 62

[DigiCert]

We received communication to our Ombudsman program and we are following the standard operating procedures in addressing it, including providing updates.

Comment 63

[DigiCert]

We continue to follow our ombudsman process according to the standard operating procedures we posted. We continue to evaluate the effectiveness of the procedures and will provide updates as we make improvements to them.

Comment 64

[DigiCert]

We have some updates we are making to our standard operating procedures, which we hope to post next week.

Comment 65

[mpalmer]

Apropos of nothing in particular, from comment 45:

We are planning to have a proposal ready by the end of June

Comment 66

[DigiCert]

Updated Submission Process

We have made improvements to our Ombudsman program based on community feedback and operational experience. Key updates include:

Updated Accessibility

Inquiries, concerns or feedback can now be filed through the DigiCert Ombudsman transparency form available at: digicert.com/transparencyform

This web-based form provides a more accessible and structured way for community members to submit concerns.

Clarified Submitter Response Procedures

Section 3.3 Submitter Response Procedures has been added to address questions about anonymous submissions and follow-up requirements:

• Identified Inquiries: Submitters who provide contact information make it more feasible for the DigiCert Ombudsman to carry out a full investigation. The DigiCert Ombudsman may request clarifying information to ensure a thorough investigation.

• Anonymous Inquiries: By their nature, anonymous inquiries can make it more challenging to fully investigate claims made due to difficulty in obtaining clarification.

• Response Timeframes: If an inquiry is submitted with contact information and the DigiCert Ombudsman requests additional clarifying information, the submitter has fourteen (14) days to provide the requested information. This timeframe ensures timely resolution while information remains fresh, though extensions are available upon request when circumstances warrant additional time. The DigiCert Ombudsman team will work with submitters to clarify what information is most helpful and can provide guidance on structuring responses. If the requested information is not provided within the agreed timeframe, the inquiry will be closed.

• Anonymous Inquiry Limitations: If an inquiry is submitted without contact information and additional information is required to substantiate or clarify the inquiry, the inquiry will be closed immediately due to the inability to seek clarification. To minimize this risk, we encourage anonymous submitters to provide comprehensive detail in their initial submission using our structured web form.

Continuous Improvement

We remain committed to maintaining an effective Ombudsman process while setting clear expectations for both submitters and our investigation procedures. We continue to evaluate the effectiveness of our procedures based on actual case experience and community feedback and will adjust timeframes and processes as needed to ensure the program serves its intended purpose of addressing legitimate community concerns.

Comment 67

[DigiCert]

Status Update:

We’d like to take the opportunity to summarize what we’ve done so far and highlight the remaining tasks.

Our goals for this bug were stated in our initial response:

“In short, we fully agree with you that this community is best served by open discussion. But the discussion must also be honest, factually accurate, and focus on a fair review of important and relevant issues.”

We think our ombudsman program is a significant step forward in helping us know when people think we have failed to meet that standard, so we can take corrective action.

The full incident report posted in Comment 29 highlights four remediation actions, all of which have already been completed:

1. Technical-First Dispute Resolution: Our legal team has already been informed to let our standards and compliance folks attempt to resolve these kinds of technical and policy issues through public Bugzilla discussions.
2. Community Transparency Pledge: This makes it clear that it isn’t only our legal team that is re-affirming our commitment to public discussions and transparency, but we are extending the lesson to all aspects of incident handling.
3. Legal Review Gate: Legal issues which arise during incidents will require executive review and approval.
4. Ombudsperson Role for WebPKI Concerns: Initially proposed as just a single individual. Our implementation has been expanded to be a comprehensive program within DigiCert.

Completion of these actions was summarized in the Closing Summary posted two months ago in Comment 36.

Since then, we have provided additional information about the Ombudsman program, including publicly posting the team’s Standard Operating Procedures in their entirety.

In addition, we are currently in discussions to include a well-respected and independent expert on CA compliance to assist with our Ombudsman reviews on an as needed basis.

Next Steps

We believe the improvements made are significant changes to how we operate, not temporary measures. We are committed to:

• Maintaining the highest standards of transparency and accountability
• Contributing positively to the collaborative WebPKI ecosystem
• Continuously improving our processes based on community feedback

We appreciate the community's patience and constructive feedback throughout this process.

Comment 68

[DigiCert]

As we noted in our previous update, we have decided to add an external third-party to the DigiCert Ombudsman program. We are going through the onboarding process currently and anticipate providing an update when that is completed. In the meantime, we would like to request a next update date of August 15th as we handle the negotiations on this last remaining action item.

Comment 69

[DigiCert]

We noted in our previous update that we were going through the onboarding process to bring an external third party into our Ombudsman team. We are in the final stages of that onboarding process with a highly-respected independent third party who is well-known in the PKI industry. Terms have been agreed and the contract is working its way through final approvals on both sides. We expect to finalize the contract soon and will continue to provide updates as the process concludes.

Comment 70

[DigiCert]

We are very happy to announce that Don Sheehy has joined our ombudsman team as an independent third party. He will assist with the ombudsman program on an as-needed basis.

Don Sheehy is well-known and respected in the WebPKI industry:

• Provided strategic oversight and co-led the Task Force guiding WebTrust assurance frameworks across Canada, the U.S., and internationally.
• Spearheaded initiatives to converge audit practices across jurisdictions, including remote testing and detailed reporting enhancements.
• One of the few independent experts nominated by the CA/B Forum to oversee elections, ensuring transparency, procedural fairness, and trust integrity within CA community governance.
• Acted as the principal link between CPA Canada (WebTrust) and the CA/B Forum, elevating audit standards and compliance dialogue including collaborating with browser Root Programs.

We are thankful for, and greatly appreciate, Don’s willingness to assist in these matters.

Comment 71

[DigiCert]

We have no additional comments at this time.

Comment 72

[DigiCert]

Report Closure Summary

Incident description:

On November 11, 2024, a law firm retained by DigiCert sent a Cease & Desist letter (C&D) to Sectigo based on comments made by a Sectigo representative related to the Temporary Restraining Order (TRO) in relation to Bugzilla 1910805.

The C&D specified that Sectigo’s representative made several false or misleading statements with respect to the TRO and to DigiCert’s operations. DigiCert did not sufficiently consider the potential effect that a C&D could have on the community’s communication on Bugzilla and other forums.

DigiCert acknowledges that a more transparent and community-friendly path would be preferred to address the perceived Sectigo misrepresentations publicly in the context of Bugzilla, rather than pursuing private communications through the C&D.

Incident root cause(s):

The root causes identified through community dialogue and DigiCert's acknowledgments include:

1. Perceived Misinformation about TRO: DigiCert was faced with many claims of “exceptional circumstances” during the Bugzilla 1910805 revocation, including the unexpected TRO, which quickly took on a disproportionate role in the public dialogue. In reality, the TRO played a limited role in the mass revocation but was disclosed as part of DigiCert’s commitment to transparency.

2. Competition: While CCADB policy encourages individuals affiliated with publicly-trusted CAs to participate in Bugzilla, this participation can contribute to competitive tension. DigiCert viewed the frequency and focus of Sectigo’s DigiCert-directed comments as potentially competitively motivated.

3. Overreaction: In the course of the Bugzilla 1910805 event, the executive responsible for compliance and standards voluntarily resigned, leading to a reorganization that disrupted DigiCert’s typical compliance workflows and approval process. This led to a reactive rather than proactive response mechanism when addressing perceived misinformation, which underestimated the potential effect of the C&D on community communication.

Remediation description:

DigiCert implemented comprehensive remediation measures including:

1. Public acknowledgment and formal apology to both Sectigo and the broader WebPKI community;

2. Establishment of an Ombudsperson program reachable at [e-mail] comprised of representatives from Industry Standards, Compliance, and Legal departments;

3. Addition of Don Sheehy as an independent member to the Ombudsman team following community dialogue to ensure external perspective and accountability;

See Comment 55 for more information.

4. Establishment of mandatory review protocols for legal communications related to competitor statements in industry forums, including prioritization of public correction of misinformation rather than legal action.

Commitment summary:

DigiCert has committed to:

1. Maintain independent oversight through the expanded Ombudsman team including an external independent member;

2. Renewed commitment to collaborative problem-solving within established WebPKI community frameworks;

3. Implementation of enhanced approval processes for legal communications affecting industry discourse; placing priority on direct, transparent communication to address concerns rather than legal remedies.

4. Specifically, during incident reports, concerns about technical issues, misrepresentations, or policy violations related to compliance issues will be addressed on the corresponding Bugzilla and not through legal channels. DigiCert may address through other legal channels items related to misrepresentations, fraud, and trademark abuse that are not part of an active incident. If DigiCert feels it necessary to work through other legal channels on issues related to an active incident, the decision and action will be disclosed in the corresponding Bugzilla. 

All Action Items disclosed in this report have been completed as described, and we respectfully request its closure.

Comment 73

[DigiCert]

We have posted our closing summary. As we have no additional comments at this time and there have been no additional comments or questions from the community we request that this bug be closed, or please set an appropriate nextUpdate date.

Comment 74

[incident-reporting]

This is a final call for comments or questions on this Incident Report.

Otherwise, it will be closed on approximately 2025-09-17.