"As Matt mentioned, I really really hope there are no CAs that think they shouldn't revoke by default, given the events of the past few months. "
But we should not forget there are some CAs who feel that they can delay revocation of over 80.000 certificates just because of a problem with 70 of them. I welcome this proposal from Mozilla. JR Sent with [Proton Mail](https://proton.me/mail/home) secure email. On Friday, 20 September 2024 at 02:26, Walt <[email protected]> wrote: > I think broadly this is a good decision. > > As Matt mentioned, I really really hope there are no CAs that think they > shouldn't revoke by default, given the events of the past few months. > > I'd go a step further than that proposal however and suggest that each and > every delayed revocation request requires a separate action to be made. > > For example, if I had: > > - acme.example.com > - example.com > - *.example.com > > as three separate certificates that I needed delayed revocation on, I as the > officer of Acme would need to submit three separate signed requests as Ben > mentioned on the critical nature of the system etc. The goal here is to avoid > a process where a company just goes "critical services, don't revoke" on a > certificate set that is hundreds or thousands of certs. There's a potentially > separate conversation to be had about subscribers not understanding the > meaning of "CA can revoke within 24/120h" in the subscription agreement > they're all agreeing to (at least I hope), but that's somewhat out of scope > for this discussion. > > Maybe a bit of a stretch goal here (especially since this would generally run > counter to the incentives of the average CA [in that profit is more or less > the priority by virtue of them being a for profit business) is that not only > do any of these limited domains only allow a 90 day certificate, but a CA can > only issue them using ACME or other fully automated protocols for x amount of > time. Since this also has downstream impact in terms of EV/DV certs, this is > a much harder sell, but as a counter point on why this may not be necessary > if the 90 day max lifespan is implemented, a 90 day long certificate is > rotating frequently enough that just from pure hassle alone it may make sense > to switch to automating the certificates, whether or not enforcing ACME or > similar is a mandated part of that list. > > On Thursday, September 19, 2024 at 5:44:15 PM UTC-7 Matt Palmer wrote: > >> On Thu, Sep 19, 2024 at 03:53:16PM -0600, 'Ben Wilson' via >> [email protected] wrote: >>> 1. >>> >>> Clarification of existing requirements >>> We would be more explicit about what would be required for delayed >>> revocation. Some ideas include: >>> 1. >>> >>> Explicitly clarifying that CAs must revoke certificates by default, >>> that any delayed revocation must be the result of an explicit request by >>> the subscriber, containing the necessary information, and meeting the >>> requirements under such interim policy; >> >> If there are any CAs that currently think that they *shouldn't* revoke >> certificates by default, I would be very deeply concerned. >> >>> 2. >>> >>> That subscriber requests contain a clear claim or explanation about >>> the critical nature of the system and why timely revocation is >>> not possible >>> (more detailed requirements to be discussed); >>> 3. >>> >>> That the requests are signed by a company officer, or similar legal >>> representative, stating that the information in the request is >>> accurate to >>> the best of their knowledge; >>> 4. >>> >>> That the information contained in the subscriber’s request be >>> accurate to the CA’s understanding (e.g. not materially contradicted by >>> other facts known to the CA); >>> 5. >>> >>> That each granted request be published for the community (and >>> Mozilla) to scrutinize (allowing CAs to redact PII prior to publication); >>> and >> >> Requiring publication of the detailed reasons for delayed revocation as >> part of a delayed revocation report would be a great benefit to the >> WebPKI, I believe. >> >>> 6. >>> >>> That CAs be required to produce summary statistics in their reports >>> (alongside the individual granted requests) detailing how many requests >>> were received, how many were well-formed, how many were granted, etc. >> >> This, too, would be valuable information to improve the visibility and >> resilience of the WebPKI. >> >>> Consequences of Delayed Revocation >>> We believe that if a domain hosts critical infrastructure that cannot >>> tolerate timely revocation, then it is deeply damaging to the web PKI. In >>> order to help these domains transition to effective certificate management >>> practices and automated tooling, we propose that domains that are granted >>> delayed revocation must then be limited to shorter-lifetime certificates as >>> a consequence of such decision. This also ensures that future revocations >>> impacting such domains have much less impact. >> >> I believe this would be an admirable improvement, because as you say, a >> shorter lifetime for such certificates reduces the period of time in >> which a known-flawed certificate could be misused, if revocation were >> significantly delayed for some reason. >> >> Taking this thought to its logical conclusion, if a certificate is so >> important that revocation is too dangerous to execute within the >> strictures of the WebPKI, it should be moved to a seven-day lifetime, >> which as I understand it means that the CA is no longer required to >> revoke. >> >>> Concretely, the domains accepted for delayed revocation by a CA are >>> already public. If this proposal were to be adopted, root programs would >>> manage a shared list of such domains (e.g. via the CCADB) and require CAs >>> to limit the lifetimes of certificates issued to these domains (e.g. to 90 >>> days). >> >> By "domain", are you referring to FQDN (ie sAN values) or the associated >> eTLD+1? I would expect it to be FQDN, based on my understanding of the >> intent, but it's worth clarifying, IMO, to ensure everyone's on the same >> page. >> >> - Matt > > -- > 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/7325aa62-c3b0-41b0-962d-5d44e0847c9an%40mozilla.org. -- 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/9LVR5T82ke3B8Yva4gCGWmPT9-jwRbAvgZD7zUvgShakfBfPyL1gJK2bcGrzYm98zQXBSPl0KuYpZFhaj7MCUzt6SWJyAJh2yJyYhEBD28s%3D%40protonmail.com.
