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 On Fri, Jun 6, 2025 at 8:53 PM Matt Palmer <mpal...@hezmatt.org> wrote: > 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 > > -- > You received this message because you are subscribed to the Google Groups " > dev-security-policy@mozilla.org" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to dev-security-policy+unsubscr...@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 > . > -- You received this message because you are subscribed to the Google Groups "dev-security-policy@mozilla.org" group. To unsubscribe from this group and stop receiving emails from it, send an email to dev-security-policy+unsubscr...@mozilla.org. To view this discussion visit https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/CALVZKwZG6ygzoDd4sJ3pyss0s_8a-seAFjOMuL6TniBS4kyrug%40mail.gmail.com.
