While I agree that having detailed use-case environments that result in subscribers requesting delayed revocation might be fascinating to read, I think it will be in practice very difficult to gather given the lack of specificity that seems to be publicly provided:
https://bugzilla.mozilla.org/show_bug.cgi?id=1886442 https://bugzilla.mozilla.org/show_bug.cgi?id=1887888 https://bugzilla.mozilla.org/show_bug.cgi?id=1889062 https://bugzilla.mozilla.org/show_bug.cgi?id=1896053 https://bugzilla.mozilla.org/show_bug.cgi?id=1872738 https://bugzilla.mozilla.org/show_bug.cgi?id=1896553 None of these (or others) have the level of detail needed to really understand what the use-case is, or why that use case is critical (not critical to revenue generation activities of the subscriber, but to society/the webPKI community),. Very few report the specific details of why certificates cannot be replaced in the 24hr/5 day timeline. Generalities involving "we need to get permission from a government agency" or "we need to provide the certificate to all relying parties on the other end" or "we do not have full time IT and need time to get our MSP to do it" seem common. But when pushed for details (such as which specific regulations or which regulators), all we see is... silence. A rare example of a more specific reason is: "we are contractually required to notify those who depend on it 90 days in advance of replacement," but that seems like an obvious place where the CA should then refuse to issue new certs to the subscriber. Having manually inspected the entire certificate list for several of the recent entrust bugs, my own assessment is that 0.0% of them meet the critical bar. Sure, there are many examples of it being critical for the subscriber 's operations (e.g. Delta ticketing machines), and examples that fall under a very general "critical infrastructure" criteria as defined by CISA or others, but none that are "something really bad for society in general or the webPKI community in particular will happen if these are revoked on time." In fact, Tim Callan's comment over in [email protected] rings very true to me: "...but when the CA simply offers that this revocation will occur in a specified timeframe, the Subscribers miraculously get the new certificates deployed. Every time. We see this miracle occur over and over again." Miracles indeed. Especially as, as far as I can tell, most government regulations are not actually in conflict with fast revocation timelines, and in fact for cases where the use is "revenue generation critical," trade bodies seem to take great pains to make clear certs can be revoked in as little as 24 hr, and businesses should plan accordingly. For example, page 9 of: https://www.openbanking.exchange/wp-content/uploads/eidas-qualified-certificates-faq.pdf . So while I agree that some understanding of what is being considered critical will be fascinating to read, I don't think it is necessary to determine a path forward. My specific suggestion is to remove entirely the Mozilla carve-out for revocation delays. There are plenty of CAs who get things revoked on time without society crashing down. If there is then a truly exceptional case (like if we didn't the reactors melted down making a continent a wasteland), a CA can still choose to delay, and put their fate in the hands of the community. Tyrel On Wednesday, June 26, 2024 at 5:19:45 PM UTC-4 Mike Shaver wrote: > On Wed, Jun 26, 2024 at 5:11 PM Ben Wilson <[email protected]> wrote: > >> I think it would be good to collect and analyze use-case environments >> from subscribers who have requested delayed revocation, if anyone has >> bandwidth. >> > > I’m not sure that I have bandwidth, but I *am* sure that I don’t know how > to go about effectively contacting subscribers to find out the details. > There have been a *lot* of such subscribers lately, even if only counting > the ones who had their request granted. > > Do you propose that CAs provide contact information for subscribers who > made that request? > > Sadly, that level of detail is generally not provided in the CA incident > report, although my reading of the Mozilla incident policy says that it > should be… > > Mike > > -- 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 on the web visit https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/0235c306-f8f2-4fa0-be7d-16bc8355d638n%40mozilla.org.
