I would like to add a new DNS-based validation method to the TLS BRs. This method is similar to the ACME dns-01 challenge, but it solves a significant automation challenge. Large organizations often run a service on multiple cloud providers, These cloud providers typically automate the 3.2.2.4.7 DNS validation method by asking the website operator to delegate a CNAME record to them. Unfortunately, the ACME dns-01 challenge hard-codes the prepended label on the validation domain name as “_acme-challenge”, and DNS standards only allow one CNAME per zone, thus creating the conflict that the new method solves.
A draft RFC that addresses this problem was originally proposed in 2022. It has gone through a few iterations, ending up at the current draft.[1] The mechanism for making the CNAME unique uses an additional prepended label that is calculated based on the ACME account ID. This approach aligns this method with similar domain name validation techniques documented by the DNS Operations WG [2] (note that the scoping mechanism in the DNSOP draft has been removed because it adds complexity and scope creep here).
The new dns-account-01 validation mechanism is [arguably] not permitted under the existing TLS BR 3.2.2.4.7 because of the second prepended label. The current language implies that only one label is allowed: “an Authorization Domain Name that is prefixed with a Domain Label that begins with an underscore character.”
Rather than solve this by modifying the existing DNS method, the Validation SC has previously discussed that we’d prefer to add a new method. The TLS BR language would look something like this:
3.2.2.4.21 DNS-ACCOUNT-01 - ACME
Confirming the Applicant's control over the FQDN by performing the procedure documented for a “dns-account-01” challenge in draft 00 of “Automated Certificate Management Environment (ACME) DNS Labeled With ACME Account ID Challenge,” available at https://datatracker.ietf.org/doc/draft-ietf-acme-dns-account-label/.
I would like to point out that there is precedence for incorporating a draft standard validation method into the BRs - this was done for both http-01 and tls-alpn-01 for IP addresses. I have waited to propose this ballot until the draft RFC stabilized. Given the minimal feedback received [3] since the latest version was published, I believe we can and should proceed to incorporate this method into the BRs.
Thanks,
Wayne
[1] https://datatracker.ietf.org/doc/draft-ietf-acme-dns-account-label/
[2] https://datatracker.ietf.org/doc/draft-ietf-dnsop-domain-verification-techniques/
[3] https://mailarchive.ietf.org/arch/msg/acme/C-seFRSmAjnxWQfh0RTjSxhCb0A/I would support this.
-Tim
--
You received this message because you are subscribed to the Google Groups "Validation Subcommittee (CA/B Forum)" group.
To unsubscribe from this group and stop receiving emails from it, send an email to validation+...@groups.cabforum.org.
To view this discussion visit https://groups.google.com/a/groups.cabforum.org/d/msgid/validation/CAPh8bk_ZA4_BG7es%2BaA8j4zuh3To8TgAPQ_uBDvr_dQF3g46Cw%40mail.gmail.com.
Hi Wayne,
I’d be happy to endorse.
Thanks,
Corey
Thank you Corey and Dustin. I will check to see if there is any limit on the number of endorsers and move this into the discussion period.