Yeah - that was some hyperbole, but you'll get broader adoption of automation with short-lived certificates and requiring ACME (or some automation in general) rather than randomly breaking sites. The general public will not know this a random sampling of revocations and this plan re-inserts the education part of the plan, which does not work. For random revocations to promote faster replacement, the public would need to know a) that the revocations are happening randomly and b) know that they need automation to help deal with the random revocations. If education hasn't worked to date, adding a layer of complexity won't help much.
On Thu, Dec 19, 2024 at 11:15 AM Mike Shaver <[email protected]> wrote: > No, limiting issuance to ACME and requiring ARI support would not really > give us 100% automation adoption in a meaningful way. It would mean that > the CAs just handled API traffic, but ultimately there remain a large > number of TLS-performing systems that will simply never get updated to have > direct ACME support. Instead, each time ARI twigs a renewal, The Cert > Person will still have to pull the new cert from /var/certbot/renewal-inbox > and go jam it in the 2010-vintage LB or the partner systems that have it > pinned for dumb-to-us reasons or whatever else. Declaring victory on cert > management automation (and what we really want, which is practical > certificate agility) simply because all subscriber<->CA interaction was > mediated by an API would be quite naive IMO. > > Mik > > > On Thu, Dec 19, 2024 at 1:07 PM Jeremy Rowley <[email protected]> wrote: > >> I agree that educating subscribers has been largely ineffective. However, >> randomly causing outages won't solve the issue . Random revocations will >> just make people hate the browsers and CAs more. It's a strange solution to >> the objective of faster certificate replacement when short-lived >> certificates force automation as does simply requiring CAs to mandate >> automation. Only allow CAs to deliver certificates via an automated >> solution and all of a sudden you have 100% automation adoption. >> >> On Thu, Dec 19, 2024 at 9:59 AM Mike Shaver <[email protected]> >> wrote: >> >>> Pressure that causes more frequent cert issuance and installation is >>> pretty much the only thing that will incentivize adoption of things that >>> make issuance and installation easier, I think. Certainly many CAs, per >>> their incident Action Items, have been “educating subscribers” about the >>> merits of automation for some time, with what I would say are >>> unsatisfactory results. >>> >>> Mike >>> >>> On Thu, Dec 19, 2024 at 11:45 AM Andrew Chen <[email protected]> wrote: >>> >>>> Mike -- that's a reasonable point. I suppose making it a date OR >>>> percentage of ARI adoption isn't likely to change things, either. It would >>>> be nice if we could incentivize ARI adoption and make random revocation a >>>> non-event for many? most? people. >>>> >>>> Andrew >>>> >>>> On Thu, Dec 19, 2024 at 8:30 AM Mike Shaver <[email protected]> >>>> wrote: >>>> >>>>> Do you mean that CAs could avoid having to do random revocation by >>>>> discouraging ARI adoption among their subscribers? >>>>> >>>>> The point is that right now revocation is so painful that it’s causing >>>>> CAs to side with subscriber convenience over the integrity of the web PKI. >>>>> Sampled, controlled revocations let us identify points of pain before they >>>>> have security implications, and motivate Subscribers to prepare their >>>>> systems—whether through automation or not, up to them, I’m not their >>>>> dad—to >>>>> tolerate on-time revocation. We care about the likely outcomes of >>>>> automation, such as tolerance of short revocation or expiry timelines, >>>>> really, but if BigSlowCo wants to staff a 24-hour cert maintenance squad >>>>> such that they don’t (successfully) pressure their CA into blowing >>>>> revocation deadlines, that’s their opex choice. Directly evaluating >>>>> ecosystem capability around prompt revocation is the only way I can think >>>>> of to identify areas of danger or weakness before they become issues for >>>>> the web. >>>>> >>>>> Mike >>>>> >>>>> On Thu, Dec 19, 2024 at 11:00 AM 'Andrew Chen' via >>>>> [email protected] <[email protected]> >>>>> wrote: >>>>> >>>>>> Ben -- thanks for the proposal. Random revocation is likely to be >>>>>> painful for subscribers without automation around eminent revocation, >>>>>> which >>>>>> ARI is expected to address. Would it make sense to couple this proposal >>>>>> to >>>>>> a specific adoption rate of ARI amongst subscribers? >>>>>> >>>>>> Andrew >>>>>> >>>>>> On Wed, Dec 18, 2024 at 7:48 PM 'Ben Wilson' via >>>>>> [email protected] <[email protected]> >>>>>> wrote: >>>>>> >>>>>>> Dear Rich, >>>>>>> >>>>>>> Thank you for your question. >>>>>>> >>>>>>> I think it would be advisable for a CA operator’s mass-revocation >>>>>>> testing plan to include an immediate notice to all customers whose >>>>>>> certificates were randomly selected because we would want to minimize >>>>>>> disruption to server operations while testing the CA’s ability to revoke >>>>>>> and replace certificates promptly. >>>>>>> >>>>>>> That said, CAs should consider performing occasional tests that go >>>>>>> beyond providing pre-generated replacement certificates, in which >>>>>>> subscribers generate and submit new public keys. That would address the >>>>>>> risks from a widespread incident, like Heartbleed, where the potential >>>>>>> compromise of private keys necessitated key pair replacement. Preparing >>>>>>> for >>>>>>> such scenarios ensures that subscribers will be able to quickly perform >>>>>>> the >>>>>>> tasks of key pair generation, public key submission, and certificate >>>>>>> installation. >>>>>>> >>>>>>> Much to discuss. >>>>>>> >>>>>>> Thanks again, >>>>>>> >>>>>>> Ben >>>>>>> >>>>>>> On Wed, Dec 18, 2024 at 12:44 PM Rich Salz <[email protected]> >>>>>>> wrote: >>>>>>> >>>>>>>> As part of the discussions on this proposal, namely that CAs >>>>>>>>> “maintain and test mass revocation plans annually, including the >>>>>>>>> revocation >>>>>>>>> of 30 randomly chosen certificates within a 5-day period,” I’ve >>>>>>>>> received a >>>>>>>>> few comments via private channels, and to ensure transparency and >>>>>>>>> foster >>>>>>>>> discussion, I am sharing them here anonymously: >>>>>>>>> >>>>>>>> Would a CA be allowed to pre-notify customers whose certs were >>>>>>>> randomly selected and {pre/re}-issue them replacements? >>>>>>>> >>>>>>> -- >>>>>>> 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/CA%2B1gtaZjqvpanXnx-eX7_%3D3E3jE5isKW1h4cD9-_jCmmBS8DCQ%40mail.gmail.com >>>>>>> <https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/CA%2B1gtaZjqvpanXnx-eX7_%3D3E3jE5isKW1h4cD9-_jCmmBS8DCQ%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/CAPdVL6UdzMNOC7DKX1De5VpYh604ge6u7cCBwqMSSphCChs1Kg%40mail.gmail.com >>>>>> <https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/CAPdVL6UdzMNOC7DKX1De5VpYh604ge6u7cCBwqMSSphCChs1Kg%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/CADQzZqvuqw_odOeona27nmKpn%3DSFhKGrOT24Tkt0XvcG3apuyg%40mail.gmail.com >>> <https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/CADQzZqvuqw_odOeona27nmKpn%3DSFhKGrOT24Tkt0XvcG3apuyg%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/CAFK%3DoS9XKO1EfW5R3H-C%3D%3DmeKo5tzxJvt3Tpwxx-w%2Bshx%2BQChg%40mail.gmail.com.
