Hi all,
Thanks Ben for this proposal. Overall I find it well thought out and it moves things in the right direction. Publishing the requests received from customers will do a lot to help with what has until now been a series of vague justifications from CAs on why revocation was delayed. I agree with Walt that every FQDN should be a separate request with its own justification; excess paperwork is a great way to drive a point home with some corporates. Moving delayed FQDNs to shorter term certificates is a nice tradeoff, a clever idea! I think 90 days in the first instance is about right, but if it happens again the FQDN should be moved to STAR certificates. If it happens a third time then I'm not quite sure what to do other than say 'are we absolutely positively sure WebPKI is right for this application?' I don't think specific technical standards, such as ACME, as Walt suggested should be written into this proposal. A customer should generally be free to manage their certificates however they like. If they choose to manage 90 day (or even 7 day) certs manually, that's on them. Q ------------------------------ Any statements contained in this email are personal to the author and are not necessarily the statements of the company unless specifically stated. AS207960 Cyfyngedig, having a registered office at 13 Pen-y-lan Terrace, Caerdydd, Cymru, CF23 9EU, trading as Glauca Digital, is a company registered in Wales under № 12417574 <https://find-and-update.company-information.service.gov.uk/company/12417574>, LEI 875500FXNCJPAPF3PD10. ICO register №: ZA782876 <https://ico.org.uk/ESDWebPages/Entry/ZA782876>. UK VAT №: GB378323867. EU VAT №: EU372013983. Turkish VAT №: 0861333524. South Korean VAT №: 522-80-03080. AS207960 Ewrop OÜ, having a registered office at Lääne-Viru maakond, Tapa vald, Porkuni küla, Lossi tn 1, 46001, trading as Glauca Digital, is a company registered in Estonia under № 16755226. Estonian VAT №: EE102625532. Glauca Digital and the Glauca logo are registered trademarks in the UK, under № UK00003718474 and № UK00003718468, respectively. On Fri, 20 Sept 2024 at 07:25, Suchan Seo <[email protected]> wrote: > > I think 90 days max can stop it, because curreny proposal makes each and > all domains included in delayed certificate have 90 days max, so clients > likely wouldn't add domain unless it's required. > 2024년 9월 20일 금요일 오전 10시 26분 5초 UTC+9에 Walt님이 작성: > >> >> 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://e.as207960.net/w4bdyj/PyegO5KebCsVQRJ7 > <https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/07e2ef29-85ed-4080-b8c9-a542770a294en%40mozilla.org?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 on the web visit https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/CAMEWqGujUpEGkz8hKmQBupe3D%2BgZ84F8GVWbiQtrJtR6CKLt4A%40mail.gmail.com.
smime.p7s
Description: S/MIME Cryptographic Signature
