Mitigations needed for legal action imposing delayed revocation

[Matt Palmer]

Given the impending closure of
https://bugzilla.mozilla.org/show_bug.cgi?id=1910805, it would be
disappointing if one of the more novel aspects of that incident (which
has not been mentioned at all in the closure request summary) were left
completely unaddressed. Given the desire expressed in the recent
roundtable that policy questions should be discussed here, rather than
in Bugzilla issues, I'm starting this thread.

The specific policy issue I wish to discuss is the use of a Temporary
Restraining Order (TRO) or other legal action to prevent the CA from
performing a necessary security function by revoking misissued
certificates. The closure summary for the incident in question makes no
mention of this aspect of the incident, for reasons about which I can
only speculate, but I believe that it is of crucial importance that it
be addressed, lest TROs become the weapon of choice for ill-prepared
subscribers to do an end-run around revocation as a security control.

Those who wish the full context can read the issue (and its progenitor,
https://bugzilla.mozilla.org/show_bug.cgi?id=1910322), but in brief:

* Alegeus Technologies, a customer of DigiCert, was issued several
certificates (the legal filings indicate the number was 72) which
required, under the BRs, revocation within 24 hours.

* Within that 24 hour period, Alegeus filed a TRO blocking DigiCert from
revoking those misissued certificates.

* Some time after the 24 hour period had passed, the parties agreed to
drop the TRO and the revocation took place, at substantially the same
time as the other 80k+ misissued certificates were revoked.

Given that all the misissued certificates were revoked at around the
same time, there is no public indication that the TRO caused DigiCert to
specifically delay revocation of the Alegeus certificates. However,
given the references to "future legal strategy to combat such actions"
(https://bugzilla.mozilla.org/show_bug.cgi?id=1910322#c33), I think it's
reasonable to assume, prima facie, that a TRO would have been an
effective means to block DigiCert from revoking the Alegeus
certificates, even if DigiCert had intended to revoke the other
misissued certificates on time.

Which brings us to the crux of the problem. The certificates were
misissued. For various good security reasons, they were required to be
revoked within 24 hours. The legal system was used in an attempt to
prevent that, risking harm to relying parties by the continued validity
of those misissued certificates.

The parties on the "front line" of this problem, the CAs, have not
provided any meaningful public information (that I've seen, anyway) on
how they might avoid this problem. Thus, it devolves to relying parties
(in the form of their representitives, the trust stores, and
specifically Mozilla) to take action to prevent this problem from
recurring.

Thus, the question is: what can the WebPKI do to prevent such things from
happening in the future, and mitigating the risk inherent in such
actions?

In https://bugzilla.mozilla.org/show_bug.cgi?id=1910805#c40, I made a
couple of off-the-cuff suggestions, which I will expand upon to provide,
if nothing else, a basis for discussion. I don't claim any of these are
part of a "right" answer, but I do assert that they are all *possible*
answers. As I acknowledged in my original comment, these suggestions
impose some potentially unpleasant consequences for CAs, but the
available options for trust stores and relying parties are rather
limited.

Firstly, the time limit for revocation could be reduced to such a period
that revocation would be required before any subscriber could manage to
obtain a legal order preventing revocation (which, for the ease of
reading, I will refer to hereafter as a TRO, even though various legal
means could be used). As a TRO cannot prevent something that has
already happened, it becomes a moot point even if a subscriber managed
to get one.

Of course, this change would have significant consequences for CAs and
subscribers. CAs would be required to have sufficient staff to handle
problem reports on a much shorter timescale, and staff would need to be
trained better to be able to handle them quickly enough. Subscribers
would get much less notice, and would have to improve their processes to
be able to receive and respond to "pending revocation" notices much
quicker. Automated systems, such as ARI, would need to be
over-provisioned and updated such that they were able to handle the much
greater load of clients checking (and possibly requesting reissuance) on
a much shorter timescale.

Another option would be to make the consequences for delayed revocation
severe and mandatory. In short, fail to revoke within the specified
time period, and you're out of the trust store, no exceptions. This
would change the calculus for a CA which received a TRO requiring
delayed revocation -- they can either obey the TRO, and _know_ that
they're going to be removed from trust stores (with the consequent
impacts on their business), or they can breach the TRO and take
their chances with the court.

Again, this would have significant consequences. I recognise that there
are (extremely limited) circumstances in which a delayed revocation
_may_ not warrant immediate distrust. However, attempts to codify these
circumstances would inevitably lead to attempts to "rules-lawyer"
revocations into one of the "acceptable" circumstances, and if CAs
believed there was a chance of being able to argue their way out of a
delayed-revocation distrust action, they may choose that route rather
than choosing to maintain the security of the WebPKI. Thus, the only
reasonable option is for the rule to be "delaying revocation means
distrust", and live with the consequences of such a rule.

I'd like to reiterate that these ideas are not necessarily "the answer".
However, it would be extremely disappointing if this loophole were not
closed. Ill-prepared subscribers will use any means they can to avoid
the consequences of their (lack of) actions, and if a TRO will do the
trick, I'm confident that it will be used again in the future.

Thanks,
- Matt

[Ryan Hurst]

Matt,

I've been thinking about this issue as well. I think the underlying problem is that many in the ecosystem have forgotten that we're operating critical infrastructure for billions of people, not just running certificate businesses.

The TRO situation you've described illustrates a really important governance gap. When a subscriber can use legal mechanisms to interfere with security controls, it reveals how our current framework wasn't designed for the stakes we're actually managing.

This is exactly why I've been arguing that we need to fundamentally rethink how we approach root program governance. Here's a post I wrote on this topic https://unmitigatedrisk.com/?p=923

Your scenario highlights the kind of systemic challenge that emerges when we treat WebPKI governance as voluntary industry coordination instead of managing critical infrastructure. With clear mission/vision/values centered on protecting billions of users, the TRO question becomes straightforward: subscriber convenience never trumps ecosystem security.

We have CAs caught between conflicting authorities with technical requirements on one side and legal orders on the other, with no clear governance framework to resolve the conflict coherently. And most are not technical enough or resourced enough to do the legwork to proactively address these issues, so they hide behind vague, unsupported "it's hard" statements instead of investing in proper solutions.

To address this issue holistically, we need clear mission, vision, and strategy with threat models that are continuously updated. Playing whack-a-mole issue by issue, which is what we do today, won't get us there.

This isn't about any individual CA's response. It's about the fact that our governance model creates these impossible situations in the first place. When my kids and future grandkids go online, their safety should be minimally impacted by jurisdictional conflicts between courts, technical standards, and business pressures.

We need structural solutions that recognize both this infrastructure's global critical nature and the economic realities of running it.

Ryan

--
You received this message because you are subscribed to the Google Groups "dev-secur...@mozilla.org" group.
To unsubscribe from this group and stop receiving emails from it, send an email to dev-security-po...@mozilla.org.
To view this discussion visit https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/64eae317-2760-4d7f-8546-5f20d7b7fbba%40mtasv.net.

[Suchan Seo]

Wouldn't court just force CA to unrevoke TRO'ed certificate in that case? Revoking a cert is just publiching a CRL/OCSP response, and I thing court can forbid CA to publich CRL/OSCP that says cert X is revoked as part of TRO. un-revoke is just publishing new CRL without that cert/send "Good" on OCSP, both of which aren't impossible in technicall sense, just being another BR violation which court doesn't care.

2025년 6월 7일 토요일 오후 12시 53분 29초 UTC+9에 Matt Palmer님이 작성:

[Matt Palmer]

On Sun, Jun 08, 2025 at 04:37:24AM -0700, Suchan Seo wrote:
> Wouldn't court just force CA to unrevoke TRO'ed certificate in that case?

An order to take an action is a very different beast from an order to
_not_ take an action. The hint is in the name: a _restraining_ order.
It stops an entity from doing something which may potentially cause the
plaintiff harm, to give a court time to consider the situation more
carefully. For more information, consult your friendly neighbourhood
lawyer.

However, I'd be more than happy for Mozilla to close that loophole, too,
by making it clear that any "unrevocation" is another insta-kick action.
That should be less controversial than my other suggestions, because (as
far as I'm aware) there's no historical precedent of a CA ever
unrevoking a certificate in contravention of the BRs, so there's no
"inertia" of previous unsanctioned bad behaviour to overcome.

- Matt

[Seo Suchan]

CRL/OCSP reposne is only valid for about a week, and writing new
CRL/OCSP response by itself a new action, even if it has same set of
certificates in it, which TRO can forbid.

I think this is something can closeable, at worst case it'd just cause
court send officers to forbid CA people from touch HSM

2025-06-09 오전 9:03에 Matt Palmer 이(가) 쓴 글:

[Roman Fischer]

Dear Community,

My professional ethic guidelines prohibit me from putting contracts over the law. Forcing people (CAs are still run by humans) to knowingly ignore the law just because otherwise their business will be destroyed by exclusion from root stores, is IMHO unethical.

Kind regards
Roman

[Pierre Barre]

Hi Roman,

> My professional ethic guidelines prohibit me from putting contracts
> over the law. Forcing people (CAs are still run by humans) to knowingly
> ignore the law just because otherwise their business will be destroyed
> by exclusion from root stores, is IMHO unethical.

The fundamental challenge is that there is no unified "global law" governing certificate authorities. CAs operate across multiple jurisdictions with vastly different, and sometimes conflicting, legal frameworks. What's legally required in one country may be prohibited in another. More concerningly, some jurisdictions have laws that could actively undermine the security of the global web PKI.

Countries and their legal frameworks are not static, they evolve over time, and not always in directions that support internet freedom or security. A jurisdiction that today respects privacy and security principles might tomorrow pass laws requiring backdoors or surveillance capabilities.

We've seen democracies slide toward authoritarianism, implementing increasingly intrusive requirements on technology companies. A CA that commits to "always follow local law" could find itself gradually forced to compromise security as the legal landscape shifts beneath it.
Consider this scenario: If a CA were required to comply with every local law, they might be legally obligated to:

- Issue certificates that bypass security checks in certain authoritarian regimes.
- Maintain backdoors or weak encryption in some jurisdictions.
- Share private keys with government entities in others.

Best,
Pierre

> https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/ZRAP278MB017460FE058376769FAB1134FA6AA%40ZRAP278MB0174.CHEP278.PROD.OUTLOOK.COM.

[Dimitris Zacharopoulos]

In case people have missed it, this particular topic was discussed at the last CA/B Forum F2F meeting. I believe you will find useful information about the TRO process, especially in the United States, in Brian Holland's presentation.

One thing I recall from that discussion is that when a TRO is dismissed, the reasons of that dismissal are documented, especially if the TRO was granted on wrong basis, making it unlikely that another court will issue a TRO with the same justification as the previous one that got dismissed.

The fact that a TRO was issued to prevent certificates from being revoked doesn't necessarily mean that it will be an event that can be reproduced, especially if a court later reviews the case and dismisses the TRO after considering all the facts.

Dimitris.

[Matt Palmer]

On Tue, Jun 10, 2025 at 10:20:26AM +0300, 'Dimitris Zacharopoulos' via dev-secur...@mozilla.org wrote:
> In case people have missed it, this particular topic was discussed at the

> last CA/B Forum F2F meeting <https://cabforum.org/2025/03/27/minutes-of-the-f2f-64-meeting-in-tokyo-japan-forum-level-march-25-26-2025/#panel-qa-with-all-guest-speakers>.

> I believe you will find useful information about the TRO process, especially

> in the United States, in Brian Holland's presentation <https://cabforum.org/2025/03/27/minutes-of-the-f2f-64-meeting-in-tokyo-japan-forum-level-march-25-26-2025/1-CABF%20-%20Dealing%20with%20TROs%2020250325.pdf>.

Hey look, I'm CABF-famous! (I don't know that I've ever been quoted in
a presentation before)

> One thing I recall from that discussion is that when a TRO is dismissed, the
> reasons of that dismissal are documented, especially if the TRO was granted
> on wrong basis, making it unlikely that another court will issue a TRO with
> the same justification as the previous one that got dismissed.

Your recollection is at odds with the minutes you linked to; "Brian"
(presumably Brian Holland, although there is ambiguity) is recorded to
have said "*Some* opinions are published" (emphasis added). That same
point also says that "a judge *might* get mad enough that they talk to
the other judges" (again, emphasis added). In other words, there's
still the possibility that a TRO might still be granted, and that's even
before we consider the many and varied jurisdictions that might be used.

> The fact that a TRO was issued to prevent certificates from being revoked
> doesn't necessarily mean that it will be an event that can be reproduced,
> especially if a court later reviews the case and dismisses the TRO after
> considering all the facts.

Well, if there's never another TRO incident, then there need never be
another delayed revocation, and the "delayed revocation ==
insta-distrust" rule need never be invoked, which means there's no
reason not to put it in the policy.

- Matt

[Antonios Chariton]

I’d like to add a few points to this discussion that stem from things already mentioned here by Ryan, Seo, Roman, Matt, et al:

1) As there’s no single legal framework under which all CAs operate, I don’t think Mozilla or any other Trust Store can implement a single rule that fits everyone. However:

What CAs can do is study their jurisdiction and prepare for future events: for example, amend the Subscriber Agreement and other documents (Procurement Proposals / Marketing Material / …) to set expectations accordingly. If every Subscriber is informed and agrees upon these rules then perhaps there’s a weaker case here by a Subscriber. In many places it would become their failure that they ask others to pay for, which looks bad. Incident Reports can then take into account the degree of preparation by the CA for such events. Someone that took reasonable precautions but sat before a judge having a bad day should not be treated equally as someone that chose willingly to remain open to this risk (or even encouraged their customers to request TROs against them(!)) to profit from it.

What Trust Stores can do is make the CAs’ cases stronger: after reviewing this specific TRO, for example, someone may decide that the cost to the Subscriber is higher than the cost to the CA. If the cost of the CA is also high, and probably comparable, and the Subscriber understood and agreed to the expectations, then maybe we can minimize the grants of such restrictions.

2) We may be opening up the ecosystem here to more legal issues, which our governance model may not be able to accommodate: what if a CA gets a TRO against a Trust Store to keep them in the list? What if a restriction is granted in a single jurisdiction? Can a CA only revoke a certificate within a US state or within Germany? Can a Browser remove a CA only in a specific location? Or only keep it as unrevoked / trusted just there?

As Roman said, I don’t think ignoring the laws and the court system is the answer anyone wants to see, and I also understand that not every CA has the resources to put up a high quality case in a short amount of time, but there are certainly things I would believe are possible to mitigate the impact of future events that people can collaboratively work towards.

3) Delayed revocations may also happen because of a CA’s management decision from someone outside the CA. For example, there are many large companies that have a CA and also use that CA’s certificates in their infrastructure. If such a CA misissues and revocation is required within 24 hours or 7 days, yet operationally it may not be possible, how do we know that the company’s management won’t crunch the numbers and find out that n hours of downtime cost more than their entire CA times the probability of being distrusted? If I remember correctly, Ryan Sleevi was the one to first bring this up as a risk, but no action was taken since. Should a company that’s willing to burn $10M to save e.g. $50M be in a more privileged position?

Antonis

> --
> You received this message because you are subscribed to the Google Groups "dev-secur...@mozilla.org" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to dev-security-po...@mozilla.org.

> To view this discussion visit https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/addbf1e4-ccdd-4002-bfb3-8ba23ed9cbbc%40mtasv.net.

[Mike Shaver]

On Tue, Jun 10, 2025 at 5:45 AM Antonios Chariton <dakno...@gmail.com> wrote:

1) As there’s no single legal framework under which all CAs operate, I don’t think Mozilla or any other Trust Store can implement a single rule that fits everyone.

This is true for the current population of CAs. It would be possible, AIUI, for a root program to say “we will only admit CAs that are governed by law which honour the choice-of-law provision in our policies”. (That might require root programs to *have* contracts with CAs—I think only one major root program has such things, and they add other kinds of complexity. Would be an interesting legal exploration, I think!)

That might mean that not all current or aspirant root CAs continue to be trusted, but I don’t think anyone has a moral right to operate a trusted CA. CAs should be chosen according to their impact on the security and accessibility of the web, IMO, not simply on the basis of having completed some paperwork successfully. If a CA cannot or does not operate according to the trust principles of a root program—be that because of legal injunction or mere incompetence—then they should not be trusted irrespective of how fulsomely their chosen WebTrust auditor sings their praises.

(In the history of distrust events, has an auditor ever identified and raised an issue before it impacted the public web?)

Mike

[Matt Palmer]

On Tue, Jun 10, 2025 at 11:44:34AM +0200, Antonios Chariton wrote:
> 1) As there’s no single legal framework under which all CAs operate, I
> don’t think Mozilla or any other Trust Store can implement a single
> rule that fits everyone.

Counterpoint: they absolutely can, should, and indeed _must_.
Special-casing CAs based on the legal behaviour of their applicable
jurisdictions is a short path to madness.

> What CAs can do is study their jurisdiction and prepare for future
> events: for example, amend the Subscriber Agreement and other
> documents (Procurement Proposals / Marketing Material / …) to set
> expectations accordingly.

They're supposed to be doing that already.

> If every Subscriber is informed and agrees upon these rules then
> perhaps there’s a weaker case here by a Subscriber.

"Weaker" does not mean "too weak to sustain a TRO".

> Incident Reports can then take into account the degree of preparation
> by the CA for such events.

That can (and I'm sure does) already happen. At the limits, a CA that
takes a sufficient degree of preparation probably won't have to file an
incident report at all.

> What Trust Stores can do is make the CAs’ cases stronger: after
> reviewing this specific TRO, for example, someone may decide that the
> cost to the Subscriber is higher than the cost to the CA. If the cost
> of the CA is also high, and probably comparable, and the Subscriber
> understood and agreed to the expectations, then maybe we can minimize
> the grants of such restrictions.

That is a side-effect of the insta-distrust sanction I proposed: it
gives CAs a clear piece of data they can use to argue that a TRO will be
unduly harmful to them. It's not helpful if the order is granted ex
parte, but nothing's perfect.

> 2) We may be opening up the ecosystem here to more legal issues, which
> our governance model may not be able to accommodate: what if a CA gets
> a TRO against a Trust Store to keep them in the list?

A distrust does not have the same degree of time-sensitivity as a
certificate revocation, so a TRO is not a meaningful blocker to
distrust. A TRO is typically only useful for a few days/weeks; a
hearing on the merits is usually scheduled very quickly after the TRO is
issued, at which point the trust store gets to present the evidence that
demonstrates they are entirely within their rights to distrust the CA.
I would expect such a hearing to go in the favour of the trust store,
simply because Actual Lawyers are involved in operating trust stores,
and if a trust store _doesn't_ have the ability to manage its own list,
there are much bigger problems going on.

> As Roman said, I don’t think ignoring the laws and the court system is
> the answer anyone wants to see

Nobody is proposing ignoring laws and the court system. Rather, we're
discussing strategies to protect the integrity of the WebPKI from errant
legal decisions.

This is no different to a situation in which a court or law-making body
requires a CA to issue a certificate in violation of the CA's validation
processes. Are you (and Roman) suggesting that, just because a court or
law-making body required the certificate issuance, that there's nothing
that trust stores can do, and the CA should continue to operate as
though nothing had happened?

> I also understand that not every CA has the resources to put up a high
> quality case in a short amount of time

Lack of resources is not be a valid argument against effective CA
operation. "We didn't have the money to buy a HSM"...

> but there are certainly things I would believe are possible to
> mitigate the impact of future events that people can collaboratively
> work towards.

Then feel free to propose them, if you feel that my options aren't
appropriate.

> 3) Delayed revocations may also happen because of a CA’s management
> decision from someone outside the CA. For example, there are many
> large companies that have a CA and also use that CA’s certificates in
> their infrastructure. If such a CA misissues and revocation is
> required within 24 hours or 7 days, yet operationally it may not be
> possible, how do we know that the company’s management won’t crunch
> the numbers and find out that n hours of downtime cost more than their
> entire CA times the probability of being distrusted? If I remember
> correctly, Ryan Sleevi was the one to first bring this up as a risk,
> but no action was taken since. Should a company that’s willing to burn
> $10M to save e.g. $50M be in a more privileged position?

At the limit, there's not a lot that can be done a priori to prevent
such events, absent requiring CAs to not issue to any organisation that
shares control with the CA. I get the impression that would be a
requirement that CAs would not relish.

Rather, probably the best lever trust stores can apply is contained in
your problem statement:

> the numbers and find out that n hours of downtime cost more than their
> entire CA times the probability of being distrusted?

At present, this calculus comes out very much in favour of "don't
revoke", since the probability of being distrusted is so low. If that
probability were increased to ~1, the cost of downtime would have to be
much higher before it were deemed reasonable to take such an action.
Also bear in mind that with p(distrust) ~ 1, the controlling
organisation only gets to play that card once -- they're unlikely to get
a controlled CA back into trust stores any time soon thereafter.

- Matt

[Matt Palmer]

On Tue, Jun 10, 2025 at 08:38:44AM -0400, Mike Shaver wrote:
> (In the history of distrust events, has an auditor ever identified and
> raised an issue before it impacted the public web?)

I'm sure that auditors have found problems, and CAs have fixed them, but
we never get to find out because it's a nice, secret little arrangement
between auditors and those who pay them.

- Matt