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 > <http://acme-challenge_cd9dtbvvknxwz1mg.example.org/> 300 IN CNAME > "example.org.googletrustservice.acme-delegate.cloudflare.com > <http://example.org.googletrustservice.acme-delegate.cloudflare.com/>", for > Google Trust Service > - _acme-challenge_on0ikkqoklpbadex.example.org > <http://acme-challenge_on0ikkqoklpbadex.example.org/> 300 IN CNAME > "example.org.letsencrypt.acme-delegate.cloudflare.com > <http://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 >> <http://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 >> <http://acme-challenge_cd9dtbvvknxwz1mg.example.org/> 300 IN CNAME >> "example.org.googletrustservice.acme-delegate.cloudflare.com >> <http://example.org.googletrustservice.acme-delegate.cloudflare.com/>", for >> Let's Encrypt >> - _acme-challenge_on0ikkqoklpbadex.example.org >> <http://acme-challenge_on0ikkqoklpbadex.example.org/> 300 IN CNAME >> "example.org.letsencrypt.acme-delegate.cloudflare.com >> <http://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] > <mailto:[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/3CCF5437-1548-43DA-A94B-2DE054DDF01E%40aaomidi.com.
