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/98eb36af-60bc-43a8-8ef3-61175959b63bn%40mozilla.org.
