Hi Amir, Thank you for post expanding contents.
> I don't doubt this, but most of what we do in this space is planning for worst case scenarios. As ACME is meant to facilitate short-lived credentials, I don't think it would be responsible to build features that rely on long (forever?) lived keys. How do we solve this problem? - Let's encrypt returns account URI: https://acct.acme-v02.letsencrypt.org/acct/tjvsrsls89gu9ssu (Just an example and does not represent the actual content.) - base32(SHA-256( https://acct.acme-v02.letsencrypt.org/acct/tjvsrsls89gu9ssu)[0:9]) - GTS returns a different account URI: https://acme-02.pki.google/account/ilctdkn9ifnueocs (Just an example and does not represent the actual content.) - base32(SHA-256(https://acme-02.pki.google/account/ilctdkn9ifnueocs )[0:9]) This situation (scenario of Cloudflare's multiple backup certificate) CA requires two different dnshostname, and Cloudflare customers need to create DNS record twice. Is there other way to reduce configuration overhead for users? Thank you. 在2025年5月15日星期四 UTC+8 00:01:57<Amir Omidi> 写道： > > Based on my experience, instances of ACME account key compromise are > extremely rare. I also have full confidence in Cloudflare’s robust security > operations capability - such account key compromises are highly unlikely to > occur internally at Cloudflare. > > I don't doubt this, but most of what we do in this space is planning for > worst case scenarios. As ACME is meant to facilitate short-lived > credentials, I don't think it would be responsible to build features that > rely on long (forever?) lived keys. > > Furthermore, the issue isn't only key compromise. There are many > circumstances why this key might change. For example: > > 1. Regulatory requirements on not having long-lived keys. > 2. There being a runtime problem during generation of this ACME account > key that is discovered in the future. > 3. Moving away from ECC/RSA keys in the future. > > I feel very strongly that we should not be building a feature that takes a > strong dependency on the life of a key, where it doesn't really need to. > > Thanks! > > On Wed, May 14, 2025 at 11:57 AM Xiaohui Lam <inao...@gmail.com> wrote: > >> Hi Amir, >> >> Thank you for your response, specially posted here, your concern when >> drafting the RFC. >> >> Based on my experience, instances of ACME account key compromise are >> extremely rare. I also have full confidence in Cloudflare’s robust security >> operations capability - such account key compromises are highly unlikely to >> occur internally at Cloudflare. >> >> My suggestion is to draft the document to retain both the current account >> URI-generated suffix and add an account key-generated suffix. This would >> allow delegate operators (such as Cloudflare) to implement the optimal >> approach for their customers. >> >> Thank you. >> >> 在2025年5月14日星期三 UTC+8 23:17:12<Amir Omidi> 写道： >> >>> Hi! >>> >>> However, wouldn’t it be more logical to generate this host from the >>> account public key instead? >>> >>> >>> If we think about the entire lifecycle of the ACME account, using the >>> public key makes less sense. The workflow that I’ve imagined for this is as >>> follows: >>> >>> 1. Large provider creates ACME accounts on ACME enabled CAs. >>> 2. Large provider ensures that the CA’s have rate limits in place to >>> allow them to do large number of issuances. >>> 3. Large provider communicates these stable strings to the customer to >>> set as CNAME records for DCV delegation. >>> >>> Now, if we use the public key, these are no longer stable URLs. We >>> effectively have a long lived key, where replacing that key ends up >>> requiring every single customer to change their CNAME records. >>> >>> With the design that is currently in place, we can use >>> https://datatracker.ietf.org/doc/html/rfc8555#section-7.3.5 to rollover >>> the account keys, without causing disruptions to the end users. >>> >>> Hope this answers the inquiry! >>> >>> On May 14, 2025, at 10:42 AM, Xiaohui Lam <inao...@gmail.com> wrote: >>> >>> It should be following: >>> >>> - _acme-challenge_cd9dtbvvknxwz1mg.example.org 300 IN CNAME " >>> example.org.googletrustservice.acme-delegate.cloudflare.com", for >>> Google Trust Service >>> - _acme-challenge_on0ikkqoklpbadex.example.org 300 IN CNAME " >>> example.org.letsencrypt.acme-delegate.cloudflare.com", for Let's Encrypt >>> >>> Sorry for my typo >>> 在2025年5月14日星期三 UTC+8 22:39:59<Xiaohui Lam> 写道： >>> >>>> Hi all, >>>> >>>> I came across Cloudflare’s blog ( >>>> https://blog.cloudflare.com/zh-cn/introducing-dcv-delegation), which >>>> mentions an RFC draft Automated Certificate Management Environment (ACME) >>>> DNS Labeled With ACME Account ID Challenge. This draft proposes a new >>>> domain control verification (DCV) method using following DNS record: >>>> _acme-challenge_ujmmovf2vn55tgye.www.example.org 300 IN TXT >>>> "LoqXcYV8...jxAjEuX0.9jg46WB3...fm21mqTI" >>>> >>>> Key concern of mine revolves around how the validation domain name is >>>> constructed by prepending the label: >>>> "_acme-challenge" || base32(SHA-256(Account Resource URL)[0:9]) >>>> The verification DNS host _acme-challenge_[suffix]'s suffix is >>>> generated from the ACME account URI (account resource URL). However, >>>> wouldn’t it be more logical to generate this host from the account public >>>> key instead? >>>> >>>> Let’s contextualize this with Cloudflare’s use case: they aim to allow >>>> users to delegate _acme-challenge_[suffix] via CNAME records. If we use >>>> the >>>> account URI to generate the DNS host suffix, and Cloudflare users need to >>>> enroll certificates from two CAs - such as >>>> >>>> - Let’s Encrypt, and >>>> - Google Trust Service >>>> >>>> Cloudflare will give two CNAME records, e. g: >>>> >>>> - _acme-challenge_cd9dtbvvknxwz1mg.example.org 300 IN CNAME " >>>> example.org.googletrustservice.acme-delegate.cloudflare.com", for >>>> Let's Encrypt >>>> - _acme-challenge_on0ikkqoklpbadex.example.org 300 IN CNAME " >>>> example.org.letsencrypt.acme-delegate.cloudflare.com", for Google >>>> Trust Service >>>> >>>> They would have to create two separate CNAME records (due to different >>>> DNS hosts and values for every CA). >>>> >>>> In contrast, if the DNS host suffix is generated from the account >>>> public key, Cloudflare users would only need to create one CNAME record >>>> for >>>> delegation. This streamlines the process, enhanced security(publickey is >>>> far secure than an url string) and reduces configuration overhead for >>>> users. >>>> >>>> Thoughts? >>>> >>> >>> -- >>> You received this message because you are subscribed to the Google >>> Groups "dev-secur...@mozilla.org" group. >>> To unsubscribe from this group and stop receiving emails from it, send >>> an email to dev-security-po...@mozilla.org. >>> To view this discussion visit >>> https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/c8a84911-53fa-418f-b742-9109157c1997n%40mozilla.org >>> >>> <https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/c8a84911-53fa-418f-b742-9109157c1997n%40mozilla.org?utm_medium=email&utm_source=footer> >>> . >>> >>> >>> -- You received this message because you are subscribed to the Google Groups "dev-security-policy@mozilla.org" group. To unsubscribe from this group and stop receiving emails from it, send an email to dev-security-policy+unsubscr...@mozilla.org. To view this discussion visit https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/7ea62291-2e4c-4500-a4b2-d0d7ed7a43d7n%40mozilla.org.
