Lawyers, (no) Guns, and Money and the CA system

[Watson Ladd]

https://www.courtlistener.com/docket/68995396/alegeus-technologies-llc-v-digicert/

Gratuitous Warren Zevon references aside, and it still being early
days I don't think there is much to discuss yet, but it is
disconcerting. I cannot imagine an auditor receiving a similar notice
if they needed to qualify a previously unqualified opinion, despite
far more dire consequences for a company involved.

Between this and the delays happening because of the volume of
requests we might have to rethink the realistic ability to achieve
widespread 24 hour revocations in practice.

Sincerely,
Watson

--
Astra mortemque praestare gradatim

[Tyrel]

I don't see an issue here, or why there is any relevance to certificate revocation lifetimes. 

It looks like the TRO was granted because the provided exhibits mention nothing about DigiCerts ability and authority to revoke certificates (or, indeed, about any of the subscriber requirements to meet BR expectations, etc.). Presumably this is due to "selective" document exhibition by the complainant through including the MSA but not the attached appendices, addenda, or other components where that language presumably currently resides.

Even with the granted TRO, Digicert should have revoked the certificates from all other customers within the 24 hour deadline (which did not happen). They then should have filed a delayed revocation incident, citing the above case as an "exceptional" circumstance. I would then expect their "how we will avoid this happening in the future" action items to include updating their MSA to explicitly state that Digicert can revoke certs for any time for any reason without notice, so that such "selective" information provision to a court of law is no longer possible, and to also state they will drop any customer that attempts to use legal action against them, and refuse to take on customers that have attempted legal action against other CAs in the past. 

All of this puts the burden of maintaining flexibility back where it should be -- on subscribers. Indeed, if anything, this incident suggests that instead of 24 hr or 5 days, the timeline should be "as soon as the list of affected certs is assembled, revoke them all."  Systems that are not critical will have outages (which is OK). Systems that are critical will also have outages in the short term, which is also OK because it incentivizes hot spares, automation, lifecycle management, and other best practices to make for an agile ecosystem.

Tyrel

[Matt Palmer]

On Wed, Jul 31, 2024 at 03:56:12PM -0700, Watson Ladd wrote:
> https://www.courtlistener.com/docket/68995396/alegeus-technologies-llc-v-digicert/
>
> Gratuitous Warren Zevon references aside, and it still being early
> days I don't think there is much to discuss yet, but it is
> disconcerting. I cannot imagine an auditor receiving a similar notice
> if they needed to qualify a previously unqualified opinion, despite
> far more dire consequences for a company involved.

It is very disconcerting. When the dust on this settles, and there is
more visibility into the actual issues at play, I think it is necessary
for there to be a full and frank discussion around what can be done to
adjust subscriber agreements (including MSAs) so that any attempt to
obtain a TRO to prevent revocation will be rejected by courts in the
first instance.

> Between this and the delays happening because of the volume of
> requests we might have to rethink the realistic ability to achieve
> widespread 24 hour revocations in practice.

On the contrary, CAs need to rethink what they need to do to achieve

widespread 24 hour revocations in practice.

An invalid certificate needs to be revoked as soon as possible, to limit
the damage that can be caused. If someone is found to be egregiously
unfit to drive a motor vehicle, they typically have their permission to
drive suspended immediately -- they don't get to drive around for a
month or two until it's deemed convenient for them to relinquish their
licence.

One may argue that the certificates that are being revoked are only
"theoretically" invalid, that the likelihood is that there are
few-to-none actually malicious certificates in the set of certificates
to be revoked. That is fallacious thinking, however -- the burden of
proof is on those who wish to claim that the certificates are still
safe. That is ultimately what the BRs are: the consensus description of
"how to produce safe WebPKI certificates". Step outside those
boundaries, and all the security guarantees are moot, and have to be
reproven. To continue the previous analogy, though, people lose their
permission to drive for engaging in risky behaviours (speeding, reckless
driving, DUI), not only when they *actually* cause an accident.

Loosening revocation timelines would not improve security in any way, it
would only reduce the rate of reported incidents. "We haven't heard of
any problems, therefore there's no problem" is not good engineering, or
good risk management.

It is possible for CAs to rethink how to achieve 24 hour revocation
timelines.

I think back to the large Let's Encrypt delayed revocation incident, in
which millions of certificates needed to be revoked, and Let's Encrypt
delayed revocation due to an inability to do an automatic
mass-reissuance in the timeframe required. As a result of this, ISRG
has put significant resources into creating a new extention to the ACME
protocol (ARI) to provide automated notification of revocation, and
implemented it in their freely-available server and client software, so
that certificates can be reissued in bulk if they need to be revoked --
for *any* CA in the ecosystem (should they choose to implement the
specification).

Conversely, Entrust had multiple delayed revocation incidents, and as
best I recall their sole attempt at improvement was, to paraphrase,
"we'll try to do better next time". No demonstration of meaningful
change, or contribution to improving the ecosystem.

I hope that this DigiCert incident causes a more "Let's Encrypt"-like
reaction, where DigiCert comes up with some ecosystem-wide mechanisms
for improvement, based on lessons learned.

- Matt

[Mike Shaver]

On Wed, Jul 31, 2024 at 8:45 PM Tyrel <tmcque...@gmail.com> wrote:

Even with the granted TRO, Digicert should have revoked the certificates from all other customers within the 24 hour deadline (which did not happen).

I mean I’m sort of a Delayed Revocation Has Consequences guy,  but I think “hmm, a judge says we shouldn’t revoke this one, maybe we should chill on the others too” is a reasonable position to take while counsel sorts the parameters out.

I have questions about how BRs 9.6.3(8) manifests in DigiCert’s subscriber agreement/contract chain, but I have high confidence that they will be submitting all of that stuff into evidence here and then 9.16.3 means that it’ll be very clear if it has any effect on their future issuance or revocation.

As my therapist says, let’s not “should” all over ourselves here.

All of this puts the burden of maintaining flexibility back where it should be -- on subscribers. Indeed, if anything, this incident suggests that instead of 24 hr or 5 days, the timeline should be "as soon as the list of affected certs is assembled, revoke them all."  Systems that are not critical will have outages (which is OK). Systems that are critical will also have outages in the short term, which is also OK because it incentivizes hot spares, automation, lifecycle management, and other best practices to make for an agile ecosystem.

I think this is basically right, unless we discover that the cost of a TRO is lower (in some jurisdictions?) than the cost of rotating certs. That would motivate some contemplation of how the incentives line up, I think.

Mike

[Amir Omidi]

There is an argument to be made that every other CA should definitely look into their legal playbooks on if they can issue certs for Alegeus at this point or not. Alegeus as a subscriber has shown that they're probably not going to be in compliance with any CA's Subscriber Agreement.

For example, Let's Encrypt issues some certs for them - is Let's Encrypt okay being served a TRO to block revocation if it needs to happen?

--
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 on the web visit https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/CADQzZqvjoov_BgXWuuQggwCOitu2r9-vu%3Dkrey_XR%3Dd9frc%2B3A%40mail.gmail.com.