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.
