[cabf_validation] Adding Support for ACME Scoped DNS Challenges

[Aaron Gable]

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 <
validation at cabforum.org> 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 <validation-bounces at cabforum.org> *On Behalf Of *Wayne
> Thayer via Validation
> *Sent:* Thursday, February 22, 2024 2:04 PM
> *To:* CABforum3 <validation at cabforum.org>
> *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
> Validation at cabforum.org
> https://lists.cabforum.org/mailman/listinfo/validation
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/validation/attachments/20240226/b14d8fa8/attachment.html>