> 2. If certificate consumers want to prohibit delayed revocation, then they > need to make it clear to CAs that they won't accept it and that they will > kick them out of the root stores if they still do it. Don't try to solve > this issue with indirect measures like random revocations. Just be straight > about it and make it clear that there will be consequences for the very > first delayed revocation and onward.
> I do believe that clearly spelled-out consequences for non-compliance > would go some way to encouraging good behaviour. The current approach, > where non-compliance may or may not have any repercussions for the CA, > doesn't help those within the CA who are fighting the good fight to push > back against terrible ideas. "It might lead to bad things happening" is > a very weak argument compared to "if we do this, Mozilla will definitely > remove us from their trust store". +1000 to this. The current framework is to let the CAs guess what will happen if they delay revocation or violate the BRs. When you talk to subscribers with the browsers, there is a weird tension from both sides to have the CA allow a delay or allow a violation but then accept responsibility. Having been in the middle of "exceptional circumstances" before, I can tell you that knowing whether a violation is a distrust-worthy event or just a bad idea is difficult. Understanding clear consequences will make every internal discussion and external discussion far easier. > 3. We will face big problems in revoking productive customer certificates > just to test our mass-revocation plan and procedures. Our current customer > contracts do not foresee this. While we can revoke at any time for security > or compliance reasons, > What is "Mozilla makes us revoke 30 randomly-chosen certificates, > RNJesus has decided that today's your turn in the barrel" if not a > compliance reason? I agree with Matt - it is a compliance-based revocation. Plus, Section 4.9.1.1 states: "Revocation is required by the CA’s Certificate Policy and/or Certification Practice Statement for a reason that is not otherwise required to be specified by this section 4.9.1.1 (CRLReason “unspecified (0)” which results in no reasonCode extension being provided in the CRL);". Just add the revocation reason of "random sampling" to the CPS and the problem is solved. > 5. Why was the number 30 chosen as a sample? Some CA operators issue very > few certificates, while some CAs issue millions of certificates. > I was considering responding to this part of the original proposal, to > suggest "30 or 0.N% of annual issuance volume, whichever is lower" type > of language, but when I thought about it further, if an entire CA is > issuing so few certificates that revoking 30 is an unreasonable burden, > I'd be very concerned about their operational practices in general, > given how little practice they get with them. > On the subject of the selection of certificates, I'd like to echo the > other comments expressing concerns about the degree to which CAs might > seek to "game" the random selection. It's one of those "it's too easy > to do, and too hard to get caught" situations where shenanigans (or even > the appearance of shenanigans) like to live. I agree that if a CA isn't issuing 30 certificates a year, they probably shouldn't be a publicly trusted CA for TLS. At that point, the CA has limited value to the Mozilla community compared to the risks of mis-issuance (imo). However, 30 does seem awfully low considering the volume of issuance for some CAs. With only 30 certificates, some CAs will revoke only certs from 1 large client, even if the sample is randomly pulled (for example, Cloudflare is a huge number of certificates for whomever has that agreement). With 30 certificates, you won't get the sampling you hope. On Thu, Dec 19, 2024 at 11:23 AM Jeremy Rowley <[email protected]> wrote: > 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%3DoS_GN_Sbf6S6vgit%3D%3DiayFpz34GFEfJ_Rweyyv2oXkjZYQ%40mail.gmail.com.
