There are certainly CAs who could improve the overall state of the Web PKI by being more responsive to their commitments. We had an example this year of a CA sitting on revocation of invalid certs for more than a month because the vendor of their CA-management software said it would take that long to get the fix to their issuance (rather than directing their subscribers to get certs from another CA who could correctly issue certificates at that time—because it would cause inconvenience for the subscribers).
However, in many delayed revocation cases, it is indeed the Subscriber who needs to be more responsive to their (legally binding, as required per the BRs) commitments to tolerate prompt revocation. CAs in these circumstances are pressured to violate their covenants under the BRs and related policies, and defer revocation to accommodate Subscriber convenience (both immediate and historical, in the form of underinvestment in certificate management or automation). A random revocation test is really a test of the *Subscriber* population, and how they are influenced by the policies and (more importantly) actions of their chosen CA. To emphasize, as a customer of the CA operating under the TLS BRs, you have legally agreed that the CA can blow away the cert in 24/120 hours and that you will tolerate that without unacceptable-to-the-world-and-the-web consequences. That legal commitment is often not reflected operationally, unfortunately, and the desired result of a random revocation audit is to smoke out those cases, and if that results in some operational distress for underprepared Subscribers, then hopefully their distress is helpful /pour encourager les autres/ as well as motivating the Subscribers in question to improve their operations. IMO the random revocation should take exactly the same operational form as a real revocation under the 5-day clock: CA is notified that they need to revoke, identically to a CPR being filed, and then they inform the subscriber and the clock has started. When the clock expires, the certificate is revoked. I don't think that the process of issuing the replacement certificate is typically the long pole, and rather it's available as soon as the Subscriber asks for it. If the DCV is still in its validity period then the CA could proactively reissue at the point of the CPR arriving, if that proves to be a meaningful assistance to the Subscriber in replacing things. Mike On Thu, Dec 19, 2024 at 8:24 PM Rich Salz <[email protected]> wrote: > > > On Thu, Dec 19, 2024, 6:59 PM Matt Palmer <[email protected]> wrote: > >> Oh, I don't know... ransomware has been far more effective at improving >> DR practices than several decades of education was. >> > > An important difference is that I am a customer of the CA, and often > paying for a service. I'm not paying you to DoS me. > > In the venues where I mainly work( the ietf) we often say that revocation > does not work on the web. Which part of the Web PKI needs to become more > responsive? My hunch is that it is not the CAs. > >> -- > 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/CAFH29trsULk%3D%2BTjyMkZBkr716vkXomrq0mOD0_Tpb8TMLF7-AQ%40mail.gmail.com > <https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/CAFH29trsULk%3D%2BTjyMkZBkr716vkXomrq0mOD0_Tpb8TMLF7-AQ%40mail.gmail.com?utm_medium=email&utm_source=footer> > . > -- 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/CADQzZqtjanuDV1GEMhXzuEFG%2BnaC5ZVKfDgchYX4UfuxRtpwFA%40mail.gmail.com.
