[Servercert-wg] Fw: New Version Notification for draft-vanbrouwershaven-acme-auto-discovery-00.txt

[Aaron Gable]

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 8:21 AM Paul van Brouwershaven via Servercert-wg <
servercert-wg at cabforum.org> wrote:

> 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.
>
> 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.
>
> Thanks,
>
> Paul
>
> ------------------------------
> *From:* internet-drafts at ietf.org <internet-drafts at ietf.org>
> *Sent:* Thursday, July 6, 2023 16:39
> *To:* Mike Ounsworth <Mike.Ounsworth at entrust.com>; Paul van Brouwershaven
> <Paul.vanBrouwershaven at 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.*
> _______________________________________________
> Servercert-wg mailing list
> Servercert-wg at cabforum.org
> https://lists.cabforum.org/mailman/listinfo/servercert-wg
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/servercert-wg/attachments/20230731/cb4dcec8/attachment.html>