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 -----Original Message----- From: [email protected] <[email protected]> On Behalf Of Matt Palmer Sent: Samstag, 7. Juni 2025 05:53 To: [email protected] Subject: Mitigations needed for legal action imposing delayed revocation 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 "[email protected]" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion visit https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/64eae317-2760-4d7f-8546-5f20d7b7fbba%40mtasv.net. -- You received this message because you are subscribed to the Google Groups "[email protected]" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion visit https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/ZRAP278MB017460FE058376769FAB1134FA6AA%40ZRAP278MB0174.CHEP278.PROD.OUTLOOK.COM.
