<div dir="ltr">Hi Paul,<div><br></div><div>I'm sorry that I wasn't able to be at the ACME session last week; I've enjoyed reading the presentation slides and the draft notes that were taken during the session.</div><div><br></div><div>In general, I'm very in favor of a system that allows for natural configuration of and fallback between multiple ACME CAs for a given domain. I think that the core concepts here of leveraging CAA records, adding a "priority" field, and declaring a new well-known path where ACME directory info can be found, combine to make a compelling system.</div><div><br></div><div>I have some editorial notes to tighten up this draft and make it easier to digest:</div><div><br></div><div>1. I believe Section 4 should be rewritten to be more clearly normative. I think it can be condensed to just one or two paragraphs, which basically state "Compliant CAs MUST expose a copy of or a redirect to their ACME Directory resource [RFC 8555 Section 7.1.1] at the .well-known/acme path (see Section 7 IANA Considerations) under the CA's issuer-domain-name [RFC 8659 Section 4.2] hostname."</div><div><br></div><div>2. Section 5 can be similarly simplified; for example, steps 5-9 do not interact with the new CAA records or the new well-known URL at all and are an unnecessary recapitulation of RFC 8555 Section 7.4. I believe that this section should restrict itself to describing the process by which a client queries CAA records, does priority ordering, and resolves potential conflicts between records for different domain names. The goal is just to derive a directory URL. Then it can simply hand things off to RFC 8555 Section 7.1.1, which begins "This should be the only URL needed to configure clients."</div><div><br></div><div>3. I'm confused by the inclusion of Section 6 at all. What about this proposal interacts with External Account Binding in a sufficiently new way as to merit this whole section? As far as I can tell, the point of this draft is that there will be no difference between setting "directory: <a href="https://someca.com/api/directory">https://someca.com/api/directory</a>" in an on-disk config file, and setting a "CAA 0 issue <a href="http://someca.com">someca.com</a>; discovery=true" DNS record. In either case, handling any other requirements for external account binding is incumbent on the ACME client operator, so I'm not sure why it gets a call-out here. Specifically, it seems telling that the whole of Section 6 contains a single normative requirement: "Clients SHOULD provide users with the ability to configure and utilize external account binding". How does this differ from RFC 8555 Section 7.3.4, which describes the client behavior necessary to conduct external account binding?</div><div><br></div><div>Thanks,</div><div>Aaron</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Jul 6, 2023 at 8:21 AM Paul van Brouwershaven via Servercert-wg <<a href="mailto:servercert-wg@cabforum.org">servercert-wg@cabforum.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div class="msg8586789911291264090">




<div dir="ltr">
<div style="font-family:Calibri,Arial,Helvetica,sans-serif;font-size:12pt;color:rgb(0,0,0)">
<span style="font-size:12pt;font-family:Calibri,Arial,Helvetica,sans-serif"></span></div>
<div><span style="font-family:Calibri,Arial,Helvetica,sans-serif;font-size:12pt;font-weight:400">I just submitted the initial draft for ACME auto-discovery to the ACME working group as discussed during the latest face-to-face
 meeting at the IETF. </span></div>
<div><br>
</div>
<div><span style="font-family:Calibri,Arial,Helvetica,sans-serif;font-size:12pt;font-weight:400">We encourage everyone to provide feedback on the draft and to consider showing their support for this draft within the IETF. Your
 active participation and endorsement will contribute to the advancement and adoption of this proposal that is needed for the broader adoption of automation through ACME.</span></div>
<div></div>
<div><br>
</div>
<div><span style="font-family:Calibri,Arial,Helvetica,sans-serif;font-size:12pt;font-weight:400">Thanks,</span></div>
<div><br>
</div>
<div><span style="font-family:Calibri,Arial,Helvetica,sans-serif;font-size:12pt;font-weight:400">Paul</span><br>
</div>
<div style="font-family:Calibri,Arial,Helvetica,sans-serif;font-size:12pt;color:rgb(0,0,0)">
<br>
</div>
<div id="m_8586789911291264090appendonsend"></div>
<hr style="display:inline-block;width:98%">
<div id="m_8586789911291264090divRplyFwdMsg" dir="ltr"><font face="Calibri, sans-serif" style="font-size:11pt;color:rgb(0,0,0)"><b>From:</b> <a href="mailto:internet-drafts@ietf.org" target="_blank">internet-drafts@ietf.org</a> <<a href="mailto:internet-drafts@ietf.org" target="_blank">internet-drafts@ietf.org</a>><br>
<b>Sent:</b> Thursday, July 6, 2023 16:39<br>
<b>To:</b> Mike Ounsworth <<a href="mailto:Mike.Ounsworth@entrust.com" target="_blank">Mike.Ounsworth@entrust.com</a>>; Paul van Brouwershaven <<a href="mailto:Paul.vanBrouwershaven@entrust.com" target="_blank">Paul.vanBrouwershaven@entrust.com</a>><br>
<b>Subject:</b> [EXTERNAL] New Version Notification for draft-vanbrouwershaven-acme-auto-discovery-00.txt</font>
<div> </div>
</div>
<div><font size="2"><span style="font-size:11pt">
<div>WARNING: This email originated outside of Entrust.<br>
DO NOT CLICK links or attachments unless you trust the sender and know the content is safe.<br>
<br>
______________________________________________________________________<br>
<br>
A new version of I-D, draft-vanbrouwershaven-acme-auto-discovery-00.txt<br>
has been successfully submitted by Paul van Brouwershaven and posted to the<br>
IETF repository.<br>
<br>
Name:           draft-vanbrouwershaven-acme-auto-discovery<br>
Revision:       00<br>
Title:          Auto-discovery mechanism for ACME client configuration<br>
Document date:  2023-07-06<br>
Group:          Individual Submission<br>
Pages:          16<br>
URL:            <a href="https://www.ietf.org/archive/id/draft-vanbrouwershaven-acme-auto-discovery-00.txt" target="_blank">https://www.ietf.org/archive/id/draft-vanbrouwershaven-acme-auto-discovery-00.txt</a> 
<div>Status:         <a href="https://datatracker.ietf.org/doc/draft-vanbrouwershaven-acme-auto-discovery/" target="_blank">
https://datatracker.ietf.org/doc/draft-vanbrouwershaven-acme-auto-discovery/</a> </div>
<div>Html:           <a href="https://www.ietf.org/archive/id/draft-vanbrouwershaven-acme-auto-discovery-00.html" target="_blank">
https://www.ietf.org/archive/id/draft-vanbrouwershaven-acme-auto-discovery-00.html</a> </div>
Htmlized:    <a href="https://datatracker.ietf.org/doc/html/draft-vanbrouwershaven-acme-auto-discovery" target="_blank">https://datatracker.ietf.org/doc/html/draft-vanbrouwershaven-acme-auto-discovery</a>
<br>
<br>
<br>
Abstract:<br>
   A significant impediment to the widespread adoption of the Automated<br>
   Certificate Management Environment (ACME) [RFC8555] is that ACME<br>
   clients need to be pre-configured with the URL of the ACME server to<br>
   be used.  This often leaves domain owners at the mercy of their<br>
   hosting provider as to which Certification Authorities (CAs) can be<br>
   used.  This specification provides a mechanism to bootstrap ACME<br>
   client configuration from a domain's DNS CAA Resource Record<br>
   [RFC8659], thus giving control of which CA(s) to use back to the<br>
   domain owner.<br>
<br>
   Specifically, this document specifies two new extensions to the DNS<br>
   CAA Resource Record: the "discovery" and "priority" parameters.<br>
   Additionally, it registers the URI "/.well-known/acme" at which all<br>
   compliant ACME servers will host their ACME directory object.  By<br>
   retrieving instructions for the ACME client from the authorized<br>
   CA(s), this mechanism allows for the domain owner to configure<br>
   multiple CAs in either load-balanced or fallback prioritizations<br>
   which improves user preferences and increases diversity in<br>
   certificate issuers.<br>
<br>
                                                                                 
<br>
<br>
<br>
The IETF Secretariat<br>
<br>
<br>
</div>
</span></font></div>
<i>Any email and files/attachments transmitted with it are intended solely for the use of the individual or entity to whom they are addressed. If this message has been sent to you in error, you must not copy, distribute or disclose of the information it contains.
<u>Please notify Entrust immediately and delete the message from your system.</u></i>
</div>

_______________________________________________<br>
Servercert-wg mailing list<br>
<a href="mailto:Servercert-wg@cabforum.org" target="_blank">Servercert-wg@cabforum.org</a><br>
<a href="https://lists.cabforum.org/mailman/listinfo/servercert-wg" rel="noreferrer" target="_blank">https://lists.cabforum.org/mailman/listinfo/servercert-wg</a><br>
</div></blockquote></div>