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/CAPdVL6Vy_S0dZ2f%3DWJJFOTO_q%3DKhvPozGmzcc0bR8uEzBMON1g%40mail.gmail.com.
