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님이 작성: > 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/c4c26611-9cba-49f8-91f9-f40f183a620bn%40mozilla.org.
