(Apologies if you're receiving this twice; I originally sent it only to the CABForum list, instead of this IETF list.)
Hi Paul, 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. 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. I have some editorial notes to tighten up this draft and make it easier to digest: 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." 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." 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: https://someca.com/api/directory"; in an on-disk config file, and setting a "CAA 0 issue someca.com; 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? Thanks, Aaron On Thu, Jul 6, 2023 at 7:55 AM Mike Ounsworth <Mike.Ounsworth= 40entrust....@dmarc.ietf.org> wrote: > Hi ACME! > > This is new business that we would like to add to the agenda for 117. > > Thanks, > --- > Mike Ounsworth & Paul van Brouwershaven > > -----Original Message----- > From: internet-dra...@ietf.org <internet-dra...@ietf.org> > Sent: Thursday, July 6, 2023 9:39 AM > To: Mike Ounsworth <mike.ounswo...@entrust.com>; Paul van Brouwershaven < > paul.vanbrouwersha...@entrust.com> > Subject: [EXTERNAL] New Version Notification for > draft-vanbrouwershaven-acme-auto-discovery-00.txt > > WARNING: This email originated outside of Entrust. > DO NOT CLICK links or attachments unless you trust the sender and know the > content is safe. > > ______________________________________________________________________ > > A new version of I-D, draft-vanbrouwershaven-acme-auto-discovery-00.txt > has been successfully submitted by Paul van Brouwershaven and posted to > the IETF repository. > > Name: draft-vanbrouwershaven-acme-auto-discovery > Revision: 00 > Title: Auto-discovery mechanism for ACME client configuration > Document date: 2023-07-06 > Group: Individual Submission > Pages: 16 > URL: > https://www.ietf.org/archive/id/draft-vanbrouwershaven-acme-auto-discovery-00.txt > Status: > https://datatracker.ietf.org/doc/draft-vanbrouwershaven-acme-auto-discovery/ > Html: > https://www.ietf.org/archive/id/draft-vanbrouwershaven-acme-auto-discovery-00.html > Htmlized: > https://datatracker.ietf.org/doc/html/draft-vanbrouwershaven-acme-auto-discovery > > > Abstract: > A significant impediment to the widespread adoption of the Automated > Certificate Management Environment (ACME) [RFC8555] is that ACME > clients need to be pre-configured with the URL of the ACME server to > be used. This often leaves domain owners at the mercy of their > hosting provider as to which Certification Authorities (CAs) can be > used. This specification provides a mechanism to bootstrap ACME > client configuration from a domain's DNS CAA Resource Record > [RFC8659], thus giving control of which CA(s) to use back to the > domain owner. > > Specifically, this document specifies two new extensions to the DNS > CAA Resource Record: the "discovery" and "priority" parameters. > Additionally, it registers the URI "/.well-known/acme" at which all > compliant ACME servers will host their ACME directory object. By > retrieving instructions for the ACME client from the authorized > CA(s), this mechanism allows for the domain owner to configure > multiple CAs in either load-balanced or fallback prioritizations > which improves user preferences and increases diversity in > certificate issuers. > > > > > The IETF Secretariat > > > 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. Please notify Entrust immediately > and delete the message from your system. > _______________________________________________ > Acme mailing list > Acme@ietf.org > https://www.ietf.org/mailman/listinfo/acme >
_______________________________________________ Acme mailing list Acme@ietf.org https://www.ietf.org/mailman/listinfo/acme
