[cabf_validation] Adding Support for ACME Scoped DNS Challenges

Thu Feb 29 17:05:06 UTC 2024

Thanks Tim and Aaron for the feedback. I've drafted a PR for a new
dns-account-01 validation method:
https://github.com/wthayer/servercert/pull/2/files.

Do either of you (or anyone else) have an opinion about including the
dns-02 challenge from the draft RFC in the scope of this work? I don't have
a particular need for it, but I don't mind including it for completeness.

- Wayne

On Mon, Feb 26, 2024 at 11:31 AM Aaron Gable <aaron at letsencrypt.org> wrote:

> 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/20240229/1219e6bf/attachment.html>