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 -- 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 on the web visit https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/eb78e148-28cb-4c93-870c-1da09bd04cd3%40mtasv.net.
