Re: [Acme] FW: [EXTERNAL] New Version Notification for draft-vanbrouwershaven-acme-auto-discovery-00.txt

Hi all,

Paul, Mike, thank you for publishing the draft.  I am happy to see
ACME service discovery being discussed again.

For compare/contrast, I'd like to bring attention to my draft from a
couple years ago, which proposed a DNS-SD profile for ACME service
discovery, and which I presented at IETF 109:

- https://www.ietf.org/archive/id/draft-tweedale-acme-discovery-01.html
- https://datatracker.ietf.org/meeting/109/materials/slides-109-acme-service-discovery-00

Broadly contrasting the approaches, I note the following:

- Use of CAA means that this mechanism is only useful for
  discovering ACME servers for DNS identifiers.  There are ways you
  could work around this but they would use CAA records in improper
  ways.

- The main problem solved in my draft was: "in this /network
  environment/, what ACME servers can/should I use?"  The CAA-based
  proposal answers a different question: "for this /domain/, what
  ACME server should I use?"  But (a) why would a domain owner need
  to control this, and (b) it doesn't actually solve the problem
  stated in the abstract:

  > This often leaves domain owners at the mercy of their hosting
  > provider as to which Certification Authorities (CAs) can be used.

  The hosting provider can still control which ACME servers can be
  reached, regardless of the preferences expressed via CAA records.

Regarding registration of CAA attributes (IANA considerations): they
need to be registered in the "Certification Authority Restriction
Properties" registry:
https://www.iana.org/assignments/pkix-parameters/pkix-parameters.xhtml#caa-properties

Cheers,
Fraser

On Thu, Jul 06, 2023 at 06:33:01PM +0000, Paul van Brouwershaven wrote:
> Hi Richard,
> 
> Thanks for your feedback!
> So if I understand this correctly, the idea is that an ACME client that intends to obtain a certificate for example.com<https://urldefense.com/v3/__http://example.com__;!!FJ-Y8qCqXTj2!eD7c6YkKC17mdQGlDcEaGTQbmEgU6N2THkaQbM6RXa0FwMd1w2P8dNkfeej-TpOZBOANOymbB6sV_LXTPH7OoA$> will look up CAA records for example.com<https://urldefense.com/v3/__http://example.com__;!!FJ-Y8qCqXTj2!eD7c6YkKC17mdQGlDcEaGTQbmEgU6N2THkaQbM6RXa0FwMd1w2P8dNkfeej-TpOZBOANOymbB6sV_LXTPH7OoA$> and follow the guidance there as to which CA to contact?
> Correct
> Couple of observations on a quick skim:
> 
> A brief "protocol overview" section might be helpful to capture the intended happy-path flow.
> Have you looked at the diagram in chapter 5, ACME Client Behavior?
> https://www.ietf.org/archive/id/draft-vanbrouwershaven-acme-auto-discovery-01.html#name-acme-client-behavior
> 
> Would you suggest renaming this chapter?
> If folks are annoyed about the .well-known parts (as I am, a little): Since you're going to extend CAA anyway, you could just put a URL in there instead of overloading the CAA domain name.  For example, instead of the `discover` parameter being a boolean, you could just put the URL of the ACME server directory there.  (That would introduce a risk of divergence in the multiple-domain case, different ACME servers for the same CA domain, but that seems like it fails safely.)
> We have indeed considered putting the ACME server directly in the CAA record, as stated in paragraph 4 of chapter 4, ACME Client Configuration:
> 
> While an alternative consideration was to include the ACME server address directly as an attribute parameter in the CAA record, it was determined that this approach could introduce clutter and significantly increase the size of the record. Additionally, a rigid binding between the CAA record and the ACME server address may present challenges if the CA needs to change its server address in the future.
> 
> https://www.ietf.org/archive/id/draft-vanbrouwershaven-acme-auto-discovery-01.html#name-acme-client-configuration
> 
> In addition to the above, I would argue that the issuer domain name is much easier for users to configure.
> Section 3.1.2 says "the value "1" represents the highest priority", but Section 3.2 includes "the highest priority of 0".  In general, the document should be clear on how the default interacts with explicit priorities.
> Aaron Gable identified the same issue and created a pull request to address and clarify the priorities. I just released a 01 version with these changes.
> 
> ________________________________
> From: Richard Barnes <rlb@ipv.sx>
> Sent: Thursday, July 6, 2023 19:29
> To: Mike Ounsworth <Mike.Ounsworth=40entrust.com@dmarc.ietf.org>
> Cc: acme@ietf.org <acme@ietf.org>; Paul van Brouwershaven <Paul.vanBrouwershaven@entrust.com>
> Subject: Re: [Acme] FW: [EXTERNAL] New Version Notification for draft-vanbrouwershaven-acme-auto-discovery-00.txt
> 
> Hi Mike, Paul,
> 
> So if I understand this correctly, the idea is that an ACME client that intends to obtain a certificate for example.com<https://urldefense.com/v3/__http://example.com__;!!FJ-Y8qCqXTj2!eD7c6YkKC17mdQGlDcEaGTQbmEgU6N2THkaQbM6RXa0FwMd1w2P8dNkfeej-TpOZBOANOymbB6sV_LXTPH7OoA$> will look up CAA records for example.com<https://urldefense.com/v3/__http://example.com__;!!FJ-Y8qCqXTj2!eD7c6YkKC17mdQGlDcEaGTQbmEgU6N2THkaQbM6RXa0FwMd1w2P8dNkfeej-TpOZBOANOymbB6sV_LXTPH7OoA$> and follow the guidance there as to which CA to contact?
> 
> Couple of observations on a quick skim:
> 
> A brief "protocol overview" section might be helpful to capture the intended happy-path flow.
> 
> If folks are annoyed about the .well-known parts (as I am, a little): Since you're going to extend CAA anyway, you could just put a URL in there instead of overloading the CAA domain name.  For example, instead of the `discover` parameter being a boolean, you could just put the URL of the ACME server directory there.  (That would introduce a risk of divergence in the multiple-domain case, different ACME servers for the same CA domain, but that seems like it fails safely.)
> 
> Section 3.1.2 says "the value "1" represents the highest priority", but Section 3.2 includes "the highest priority of 0".  In general, the document should be clear on how the default interacts with explicit priorities.
> 
> Cheers,
> --RLB
> 
> 
> 
> On Thu, Jul 6, 2023 at 10:55 AM Mike Ounsworth <Mike.Ounsworth=40entrust.com@dmarc.ietf.org<mailto:40entrust.com@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-drafts@ietf.org<mailto:internet-drafts@ietf.org> <internet-drafts@ietf.org<mailto:internet-drafts@ietf.org>>
> Sent: Thursday, July 6, 2023 9:39 AM
> To: Mike Ounsworth <Mike.Ounsworth@entrust.com<mailto:Mike.Ounsworth@entrust.com>>; Paul van Brouwershaven <Paul.vanBrouwershaven@entrust.com<mailto:Paul.vanBrouwershaven@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<https://urldefense.com/v3/__https://www.ietf.org/archive/id/draft-vanbrouwershaven-acme-auto-discovery-00.txt__;!!FJ-Y8qCqXTj2!eD7c6YkKC17mdQGlDcEaGTQbmEgU6N2THkaQbM6RXa0FwMd1w2P8dNkfeej-TpOZBOANOymbB6sV_LVAiwKnsg$>
> Status:         https://datatracker.ietf.org/doc/draft-vanbrouwershaven-acme-auto-discovery/<https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-vanbrouwershaven-acme-auto-discovery/__;!!FJ-Y8qCqXTj2!eD7c6YkKC17mdQGlDcEaGTQbmEgU6N2THkaQbM6RXa0FwMd1w2P8dNkfeej-TpOZBOANOymbB6sV_LWMR1hgRw$>
> Html:           https://www.ietf.org/archive/id/draft-vanbrouwershaven-acme-auto-discovery-00.html<https://urldefense.com/v3/__https://www.ietf.org/archive/id/draft-vanbrouwershaven-acme-auto-discovery-00.html__;!!FJ-Y8qCqXTj2!eD7c6YkKC17mdQGlDcEaGTQbmEgU6N2THkaQbM6RXa0FwMd1w2P8dNkfeej-TpOZBOANOymbB6sV_LUJBCXjeQ$>
> Htmlized:    https://datatracker.ietf.org/doc/html/draft-vanbrouwershaven-acme-auto-discovery<https://urldefense.com/v3/__https://datatracker.ietf.org/doc/html/draft-vanbrouwershaven-acme-auto-discovery__;!!FJ-Y8qCqXTj2!eD7c6YkKC17mdQGlDcEaGTQbmEgU6N2THkaQbM6RXa0FwMd1w2P8dNkfeej-TpOZBOANOymbB6sV_LWo1Szs0A$>
> 
> 
> 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<mailto:Acme@ietf.org>
> https://www.ietf.org/mailman/listinfo/acme<https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/acme__;!!FJ-Y8qCqXTj2!eD7c6YkKC17mdQGlDcEaGTQbmEgU6N2THkaQbM6RXa0FwMd1w2P8dNkfeej-TpOZBOANOymbB6sV_LWRYQnK_A$>

> _______________________________________________
> Acme mailing list
> Acme@ietf.org
> https://www.ietf.org/mailman/listinfo/acme