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 On Tue, Jun 10, 2025, at 09:09, 'Roman Fischer' via [email protected] wrote: > 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. -- 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/df7f90cd-1649-4daf-8310-30fe1f73ac04%40app.fastmail.com.
