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%3DoS8oyKxrxDWntTuzF5pXi7v41%3DH5%3DELdqKMmG2OKdg-nPQ%40mail.gmail.com.

Reply via email to