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/CADQzZqtHh1vQmhQzf_gDDAwBBJgPqAuRj%3DE38uums6CzueEFYw%40mail.gmail.com.
