<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40"><head><meta http-equiv=Content-Type content="text/html; charset=utf-8"><meta name=Generator content="Microsoft Word 15 (filtered medium)"><style><!--
/* Font Definitions */
@font-face
{font-family:"Cambria Math";
panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
{font-family:Aptos;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0in;
font-size:12.0pt;
font-family:"Aptos",sans-serif;}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:blue;
text-decoration:underline;}
span.EmailStyle18
{mso-style-type:personal-reply;
font-family:"Aptos",sans-serif;
color:windowtext;}
.MsoChpDefault
{mso-style-type:export-only;
font-size:11.0pt;}
@page WordSection1
{size:8.5in 11.0in;
margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
{page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]--></head><body lang=EN-US link=blue vlink=purple style='word-wrap:break-word'><div class=WordSection1><p class=MsoNormal><span style='font-size:11.0pt'>Hi Wayne,<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt'>I think that’s a great idea and would be willing to endorse if/when we get to that stage.<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt'>Doug<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt'><o:p> </o:p></span></p><div style='border:none;border-top:solid #E1E1E1 1.0pt;padding:3.0pt 0in 0in 0in'><p class=MsoNormal><b><span style='font-size:11.0pt;font-family:"Calibri",sans-serif'>From:</span></b><span style='font-size:11.0pt;font-family:"Calibri",sans-serif'> Validation <validation-bounces@cabforum.org> <b>On Behalf Of </b>Wayne Thayer via Validation<br><b>Sent:</b> Friday, April 5, 2024 7:13 PM<br><b>To:</b> CA/Browser Forum Validation SC List <validation@cabforum.org><br><b>Subject:</b> Re: [cabf_validation] Adding Support for ACME Scoped DNS Challenges<o:p></o:p></span></p></div><p class=MsoNormal><o:p> </o:p></p><div><div><p class=MsoNormal>My assessment of the current dns-account-01 draft [1] is that it is not yet stable enough to reference directly in the BRs. In particular, the approach to specifying scope appears likely to change [2]. The good news is that the use of two prepended labels isn't being debated, so we could update TLS BR 3.2.2.4.7 to allow that in the short term, then go back and add the fully specified dns-account-01 method by reference once it becomes an RFC.<o:p></o:p></p></div><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal>The CNAME delegation issue addressed by this proposal is a significant barrier to ACME adoption for some Subscribers, so I think there is value in proceeding with an interim solution. Would there be objections to a ballot to modify 3.2.2.4.7 to clearly permit one or two prepended labels in the Authorization Domain Name?<o:p></o:p></p></div><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal>Thanks,<o:p></o:p></p></div><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal>Wayne<o:p></o:p></p></div><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal>[1] <a href="https://datatracker.ietf.org/doc/draft-ietf-acme-scoped-dns-challenges/">https://datatracker.ietf.org/doc/draft-ietf-acme-scoped-dns-challenges/</a><o:p></o:p></p></div><div><p class=MsoNormal>[2] <a href="https://mailarchive.ietf.org/arch/browse/acme/?q=dns-account-01">https://mailarchive.ietf.org/arch/browse/acme/?q=dns-account-01</a><o:p></o:p></p></div><p class=MsoNormal><o:p> </o:p></p></div><p class=MsoNormal><o:p> </o:p></p><div><div><p class=MsoNormal>On Mon, Mar 4, 2024 at 10:00<span style='font-family:"Arial",sans-serif'> </span>AM Aaron Gable <<a href="mailto:aaron@letsencrypt.org">aaron@letsencrypt.org</a>> wrote:<o:p></o:p></p></div><blockquote style='border:none;border-left:solid #CCCCCC 1.0pt;padding:0in 0in 0in 6.0pt;margin-left:4.8pt;margin-right:0in'><div><p class=MsoNormal>Thanks Wayne, I think the approach in your PR makes sense and looks good to me. The only change that springs to mind is around the phrasing of the "domain" and "wildcard" scopes in the last paragraph: I believe that the method should be suitable for validation Wildcard Domain Names if the scope of the challenge is either "wildcard" <i>or</i> "domain", since the <a href="https://datatracker.ietf.org/doc/html/draft-ietf-dnsop-domain-verification-techniques-03#name-scope-indication" target="_blank">dnsop draft</a> defines the "domain" scope as a superset of the "wildcard" scope.<o:p></o:p></p><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal>DNS-02 is an interesting question. On the one hand, it structurally falls under the existing 3.2.2.4.7 "DNS Change" (since it only uses a single underscore-prefixed label) and doesn't strictly need a new validation method to be defined in order to be used. On the other hand, it allows scoping down the validation to just host validation, or scoping it up to wildcard, and so ideally should have a paragraph at the bottom similar to the one you've included for dns-account-01. On the whole, I think it is preferable to include a new validation method for dns-02, but could be swayed either way.<o:p></o:p></p></div><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal>Aaron<o:p></o:p></p></div></div><p class=MsoNormal><o:p> </o:p></p><div><div><p class=MsoNormal>On Thu, Feb 29, 2024 at 9:05<span style='font-family:"Arial",sans-serif'> </span>AM Wayne Thayer <<a href="mailto:wthayer@gmail.com" target="_blank">wthayer@gmail.com</a>> wrote:<o:p></o:p></p></div><blockquote style='border:none;border-left:solid #CCCCCC 1.0pt;padding:0in 0in 0in 6.0pt;margin-left:4.8pt;margin-right:0in'><div><div><p class=MsoNormal>Thanks Tim and Aaron for the feedback. I've drafted a PR for a new dns-account-01 validation method: <a href="https://github.com/wthayer/servercert/pull/2/files" target="_blank">https://github.com/wthayer/servercert/pull/2/files</a>.<o:p></o:p></p></div><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal>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.<o:p></o:p></p></div><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal>- Wayne<o:p></o:p></p></div></div><p class=MsoNormal><o:p> </o:p></p><div><div><p class=MsoNormal>On Mon, Feb 26, 2024 at 11:31<span style='font-family:"Arial",sans-serif'> </span>AM Aaron Gable <<a href="mailto:aaron@letsencrypt.org" target="_blank">aaron@letsencrypt.org</a>> wrote:<o:p></o:p></p></div><blockquote style='border:none;border-left:solid #CCCCCC 1.0pt;padding:0in 0in 0in 6.0pt;margin-left:4.8pt;margin-right:0in'><div><p class=MsoNormal>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.<o:p></o:p></p><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal>The IETF draft (<a href="https://datatracker.ietf.org/doc/draft-ietf-acme-scoped-dns-challenges/" target="_blank">https://datatracker.ietf.org/doc/draft-ietf-acme-scoped-dns-challenges/</a>) 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.<o:p></o:p></p></div><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal>Aaron<o:p></o:p></p></div></div><p class=MsoNormal><o:p> </o:p></p><div><div><p class=MsoNormal>On Thu, Feb 22, 2024 at 11:31<span style='font-family:"Arial",sans-serif'> </span>AM Tim Hollebeek via Validation <<a href="mailto:validation@cabforum.org" target="_blank">validation@cabforum.org</a>> wrote:<o:p></o:p></p></div><blockquote style='border:none;border-left:solid #CCCCCC 1.0pt;padding:0in 0in 0in 6.0pt;margin-left:4.8pt;margin-right:0in'><div><div><div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>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). <o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'> <o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>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.<o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'> <o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>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.<o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'> <o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>-Tim<o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'> <o:p></o:p></p><div style='border:none;border-left:solid windowtext 1.5pt;padding:0in 0in 0in 4.0pt;border-color:currentcolor currentcolor currentcolor blue'><div><div style='border:none;border-top:solid windowtext 1.0pt;padding:3.0pt 0in 0in 0in;border-color:currentcolor currentcolor'><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><b>From:</b> Validation <<a href="mailto:validation-bounces@cabforum.org" target="_blank">validation-bounces@cabforum.org</a>> <b>On Behalf Of </b>Wayne Thayer via Validation<br><b>Sent:</b> Thursday, February 22, 2024 2:04 PM<br><b>To:</b> CABforum3 <<a href="mailto:validation@cabforum.org" target="_blank">validation@cabforum.org</a>><br><b>Subject:</b> [cabf_validation] Adding Support for ACME Scoped DNS Challenges<o:p></o:p></p></div></div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'> <o:p></o:p></p><div><div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>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.<o:p></o:p></p></div><div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'> <o:p></o:p></p></div><div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>Background:<o:p></o:p></p></div><div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>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.<o:p></o:p></p></div><div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'> <o:p></o:p></p></div><div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>Solution:<o:p></o:p></p></div><div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>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."<o:p></o:p></p></div><div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'> <o:p></o:p></p></div><div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>Proposal:<o:p></o:p></p></div><div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>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:<o:p></o:p></p></div><div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>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)<o:p></o:p></p></div><div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>2. Tweak the existing 3.2.2.4.7 language to allow one or two labels to be prepended to an ADN.<o:p></o:p></p></div><div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'> <o:p></o:p></p></div><div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>I would appreciate everyone's feedback on how best to approach this and any concerns that you may have.<o:p></o:p></p></div><div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'> <o:p></o:p></p></div><div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>Thanks,<o:p></o:p></p></div><div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'> <o:p></o:p></p></div><div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>Wayne<o:p></o:p></p></div><div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'> <o:p></o:p></p></div><div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>[1] Note that Michael Slaughter is working on a ballot that will clarify the requirements for DNS delegation to CAs: <a href="https://url.avanan.click/v2/___https:/github.com/slghtr-says/servercert/pull/1___.YXAzOmRpZ2ljZXJ0OmE6bzo5ODRmZWNhNGYxMDRjMzhlMTM2NmZjNTNiM2IyZDRkNDo2OmVlMDM6Y2MzMDJjZjM1NWY4NjQ0NDMzMGFiYzA2OTFjN2FiZjczYzUzY2FiZTU1N2Y2YTY4YjRmYTcwMzY5MTM1NzM2NTpoOkY" target="_blank" title="Protected by Avanan: https://github.com/slghtr-says/servercert/pull/1">https://github.com/slghtr-says/servercert/pull/1</a><o:p></o:p></p></div><div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>[2] <a href="https://url.avanan.click/v2/___https:/datatracker.ietf.org/doc/draft-ietf-acme-scoped-dns-challenges/___.YXAzOmRpZ2ljZXJ0OmE6bzo5ODRmZWNhNGYxMDRjMzhlMTM2NmZjNTNiM2IyZDRkNDo2OmQxNzk6MTQzMzEzOGUwMzQ2MWNlZTY0N2UyOWVlMjM1OGQwNmM2MTcxYTJmNDE2ZjM3NDhkMjhiZjgzNTM2YzkzNDM3ZTpoOkY" target="_blank" title="Protected by Avanan: https://datatracker.ietf.org/doc/draft-ietf-acme-scoped-dns-challenges/">https://datatracker.ietf.org/doc/draft-ietf-acme-scoped-dns-challenges/</a> <o:p></o:p></p></div><div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>[3] <a href="https://url.avanan.click/v2/___https:/datatracker.ietf.org/doc/draft-ietf-dnsop-domain-verification-techniques/___.YXAzOmRpZ2ljZXJ0OmE6bzo5ODRmZWNhNGYxMDRjMzhlMTM2NmZjNTNiM2IyZDRkNDo2OmE1OWY6NTA4NGUzZDQ2NTllMzAwYWI3NDg1MDAwYTI4ZWU2Y2U4YTZhMDY4YTQyYjRkZWYzZmQ3MzBjZTZmYjA5OWMzYzpoOkY" target="_blank" title="Protected by Avanan: https://datatracker.ietf.org/doc/draft-ietf-dnsop-domain-verification-techniques/">https://datatracker.ietf.org/doc/draft-ietf-dnsop-domain-verification-techniques/</a><o:p></o:p></p></div><div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>This is issue 486: <a href="https://url.avanan.click/v2/___https:/github.com/cabforum/servercert/issues/486___.YXAzOmRpZ2ljZXJ0OmE6bzo5ODRmZWNhNGYxMDRjMzhlMTM2NmZjNTNiM2IyZDRkNDo2OjA0MmQ6MTFlMzQyOTZiZDgzNWRlZTk4NmY5M2Y1YmYzYTI0ZTEyNTQ0NWM3NGU0ZWM2OWMzNTJlNjZmMTk0MDNhMmZjZDpoOkY" target="_blank" title="Protected by Avanan: https://github.com/cabforum/servercert/issues/486">https://github.com/cabforum/servercert/issues/486</a><o:p></o:p></p></div></div></div></div></div><p class=MsoNormal>_______________________________________________<br>Validation mailing list<br><a href="mailto:Validation@cabforum.org" target="_blank">Validation@cabforum.org</a><br><a href="https://lists.cabforum.org/mailman/listinfo/validation" target="_blank">https://lists.cabforum.org/mailman/listinfo/validation</a><o:p></o:p></p></div></blockquote></div></blockquote></div></blockquote></div></blockquote></div></div></body></html>