I concur, I think Option #1 is preferable. Adding a new validation method with reference to an existing document is a much easier and more self-contained change to the BRs.
The IETF draft ( https://datatracker.ietf.org/doc/draft-ietf-acme-scoped-dns-challenges/) has just been given a major overhaul and renamed, and the updated version will be presented at IETF 119 in mid-March. We'll get a really good sense of whether there will be additional major changes to the document at that time, so I think it would be appropriate to draft a ballot adding this new validation method now, but we should probably wait to vote until after that meeting. Aaron On Thu, Feb 22, 2024 at 11:31 AM Tim Hollebeek via Validation < [email protected]> wrote: > Yeah, I remember pointing out at the ACME working group a few times that > the BRs would have to be changed to allow two labels (but also suggesting > this is fine, I think two labels is actually superior and advocated that > for the draft). > > > > The approach #2 that Wayne is suggesting here is the one I suggested at > the mike line, but I think I like #1 better. It’s easier to just say “do > it the RFC way” instead of allowing two labels without any guidance on how > or why. > > > > The question does come up whether the draft is mature enough to adopt > right now … IMO the answer might be yes, as I seem to recall the document > was pretty close to working group last call. > > > > -Tim > > > > *From:* Validation <[email protected]> *On Behalf Of *Wayne > Thayer via Validation > *Sent:* Thursday, February 22, 2024 2:04 PM > *To:* CABforum3 <[email protected]> > *Subject:* [cabf_validation] Adding Support for ACME Scoped DNS Challenges > > > > There has been an effort underway for some time in the IETF ACME working > group that resolves a significant hurdle to ACME adoption for some > Applicants. The decision has been made to implement this in a way that > requires a BR change. > > > > Background: > > It is common for Cloud Service Providers (CSPs) to ask their customers to > delegate domain control to the CSP via a CNAME record that points to a > domain name controlled by the CSP [1]. CSPs in general, and Fastly in > particular, have found that Applicants often request certificates for the > same domain name from multiple CAs. Because (unlike TXT records) only a > single CNAME record is permitted for a particular FQDN, and because RFC > 8555 requires the use of "_acme-challenge" as the DNS validation prefix, > Applicants are unable to automate issuance via ACME dns-01 in this scenario. > > > > Solution: > > A new ACME challenge originally called dns-account-01 was proposed back in > 2022. Last week, the fourth draft was published [2]. The scope of this > draft has expanded to include two new challenges, but I believe that the > more relevant change is that the Authorization Domain Name (ADN) is now > prefixed with TWO labels instead of one. My understanding is that this > change was made to align with the work being done to standardize domain > verification techniques [3] in the dnsop working group. Unfortunately, I > think it's reasonable to interpret BR 3.2.2.4.7 as only permitting a single > label to be prepended to an ADN: "an Authorization Domain Name that is > prefixed with a Domain Label that begins with an underscore character." > > > > Proposal: > > I would like to remove this barrier to automation as soon as possible, and > prior to RFC publication. I can see two ways to accomplish this: > > 1. Add the current draft spec for dns-account-01 to the BRs as a new > validation method. There is precedent for supporting draft versions of ACME > validation methods in the BRs (3.2.2.5.6 originally referenced a draft RFC) > > 2. Tweak the existing 3.2.2.4.7 language to allow one or two labels to be > prepended to an ADN. > > > > I would appreciate everyone's feedback on how best to approach this and > any concerns that you may have. > > > > Thanks, > > > > Wayne > > > > [1] Note that Michael Slaughter is working on a ballot that will clarify > the requirements for DNS delegation to CAs: > https://github.com/slghtr-says/servercert/pull/1 > <https://url.avanan.click/v2/___https:/github.com/slghtr-says/servercert/pull/1___.YXAzOmRpZ2ljZXJ0OmE6bzo5ODRmZWNhNGYxMDRjMzhlMTM2NmZjNTNiM2IyZDRkNDo2OmVlMDM6Y2MzMDJjZjM1NWY4NjQ0NDMzMGFiYzA2OTFjN2FiZjczYzUzY2FiZTU1N2Y2YTY4YjRmYTcwMzY5MTM1NzM2NTpoOkY> > > [2] > https://datatracker.ietf.org/doc/draft-ietf-acme-scoped-dns-challenges/ > <https://url.avanan.click/v2/___https:/datatracker.ietf.org/doc/draft-ietf-acme-scoped-dns-challenges/___.YXAzOmRpZ2ljZXJ0OmE6bzo5ODRmZWNhNGYxMDRjMzhlMTM2NmZjNTNiM2IyZDRkNDo2OmQxNzk6MTQzMzEzOGUwMzQ2MWNlZTY0N2UyOWVlMjM1OGQwNmM2MTcxYTJmNDE2ZjM3NDhkMjhiZjgzNTM2YzkzNDM3ZTpoOkY> > > [3] > https://datatracker.ietf.org/doc/draft-ietf-dnsop-domain-verification-techniques/ > <https://url.avanan.click/v2/___https:/datatracker.ietf.org/doc/draft-ietf-dnsop-domain-verification-techniques/___.YXAzOmRpZ2ljZXJ0OmE6bzo5ODRmZWNhNGYxMDRjMzhlMTM2NmZjNTNiM2IyZDRkNDo2OmE1OWY6NTA4NGUzZDQ2NTllMzAwYWI3NDg1MDAwYTI4ZWU2Y2U4YTZhMDY4YTQyYjRkZWYzZmQ3MzBjZTZmYjA5OWMzYzpoOkY> > > This is issue 486: https://github.com/cabforum/servercert/issues/486 > <https://url.avanan.click/v2/___https:/github.com/cabforum/servercert/issues/486___.YXAzOmRpZ2ljZXJ0OmE6bzo5ODRmZWNhNGYxMDRjMzhlMTM2NmZjNTNiM2IyZDRkNDo2OjA0MmQ6MTFlMzQyOTZiZDgzNWRlZTk4NmY5M2Y1YmYzYTI0ZTEyNTQ0NWM3NGU0ZWM2OWMzNTJlNjZmMTk0MDNhMmZjZDpoOkY> > _______________________________________________ > Validation mailing list > [email protected] > https://lists.cabforum.org/mailman/listinfo/validation >
_______________________________________________ Validation mailing list [email protected] https://lists.cabforum.org/mailman/listinfo/validation
