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 <[email protected]> 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 " > [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/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 "[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/dd4ebf3c-8217-4e55-a27b-1f2d38e8f242n%40mozilla.org.
