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

I have a couple of concerns with this draft so far:

   1. As far as I understand from the BRs, the subscriber is effectively
   the entity that controls the private key of the certificate that was
   issued. The subscriber is not the owner of the domain. The subscriber is
   the cloud provider. The draft needs to expand on this more than it has, and
   I believe the language of the BRs need to change to accommodate this.
   -
      https://github.com/cabforum/servercert/blob/main/docs/BR.md#161-definitions
      - See Applicant and Subscriber
      -
      https://github.com/cabforum/servercert/blob/main/docs/BR.md#612-private-key-delivery-to-subscriber
   2. Large providers aren't able to just start using any CA that the
   client requests. For example, Let's Encrypt has very strict rate limits.
   Effectively every cloud provider that integrates with Let's Encrypt end up
   having to go through a rate limit increase procedure, and that is usually
   tied to the account of the subscriber (the cloud provider). For CAs that
   allow anonymous issuance, IP based rate limits are going to be common
   place. The draft needs to write some guidance for CA servers on how to go
   about this problem.
   - https://letsencrypt.org/docs/rate-limits/
      - https://isrg.formstack.com/forms/rate_limit_adjustment_request -
      Rate limit increase form for Let's Encrypt
   3. (not certain about this) CAA has so far been a ACME server side
   value, rather than client side. If that is the case, does it make sense to
   extend CAA to handle client side behavior as well? I want to avoid a
   situation where CAA is a hammer and everything is a nail. There is also the
   situation to consider that some providers that also take control of the DNS
   automatically set a temporary CAA record to get the certificate they need.
   For example, I believe cloudflare will just override any existing CAA
   record to get a certificate from the various providers they use.
   4.
   https://www.ietf.org/archive/id/draft-vanbrouwershaven-acme-auto-discovery-01.html#section-5-3.4
   - I'm concerned about the language used in step 4 of this. There is a
   situation where the user has a bad CAA record with specifically the
   extensions defined in this draft, and ends up with a domain that fails to
   obtain a certificate. Is there a reason that the provider shouldn't just
   pick whatever CA they can to get a certificate for the domain in question?
   5. I understand the draft wants to avoid changing the UI/UX of these
   public providers. However, the draft is still asking for these providers to
   implement various new UI/UX functionality. For example in #4, the user is
   supposed to be notified for failures. If the public provider is already
   implementing this notification pipeline, why wouldn't they be able to
   implement a drop down of "Pick your own CA" in the UI exposed to the user.
   I think if I was a hosting provider, I would have more difficulty
   implementing this correctly, and handling all the edge cases in the client
   compared to exposing a "Pick your own CA" in the UI. If the goal was
   ultimate flexibility, I think it would be easier for me to implement a pick
   your own CA with a textbox for the directory of that CA than it would be to
   change my client to get that information through CAA.
   - Exposing this information in the UI also avoids the subscriber
      agreement issue and the rate limit issue. These large providers can
      establish the relationships with the CAs they want to use, and
use them in
      the issuance pipeline.

Thanks!

On Thu, Jul 20, 2023 at 9:08 AM Mike Ounsworth <Mike.Ounsworth=
40entrust.com@dmarc.ietf.org> wrote:

> Thanks Deb.
>
> I’ll be presenting.
>
>
>
> The discussion on-list was pretty comprehensive; I can give a blitz
> overview in 10 mins or less.
>
>
>
> ---
>
> *Mike* Ounsworth
>
>
>
> *From:* Acme <acme-bounces@ietf.org> *On Behalf Of * Deb Cooley
> *Sent:* Thursday, July 20, 2023 5:38 AM
> *To:* Mike Ounsworth <Mike.Ounsworth=40entrust.com@dmarc.ietf.org>; IETF
> ACME <acme@ietf.org>
> *Subject:* Re: [Acme] FW: [EXTERNAL] New Version Notification for
> draft-vanbrouwershaven-acme-auto-discovery-00.txt
>
>
>
> Apologies for missing this ask.  Indeed I can add you to the agenda.  Who
> is briefing and how long do you think you need?
>
>
>
> Deb
>
>
>
> On Tue, Jul 18, 2023 at 7:54 PM Mike Ounsworth <Mike.Ounsworth=
> 40entrust.com@dmarc.ietf.org> wrote:
>
> @chairs since the agenda doesn't look particularly full, and we asked
> before the cutoff, could we get this on the agenda please?
>
> ---
> Mike Ounsworth
>
> -----Original Message-----
> From: Acme <acme-bounces@ietf.org> On Behalf Of Mike Ounsworth
> Sent: Thursday, July 6, 2023 9:54 AM
> To: acme@ietf.org
> Cc: Paul van Brouwershaven <Paul.vanBrouwershaven@entrust.com>
> Subject: [Acme] FW: [EXTERNAL] New Version Notification for
> draft-vanbrouwershaven-acme-auto-discovery-00.txt
>
> 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 <internet-drafts@ietf.org>
> Sent: Thursday, July 6, 2023 9:39 AM
> To: Mike Ounsworth <Mike.Ounsworth@entrust.com>; Paul van Brouwershaven <
> 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://urldefense.com/v3/__https://www.ietf.org/archive/id/draft-vanbrouwershaven-acme-auto-discovery-00.txt__;!!FJ-Y8qCqXTj2!d0ZjHZK3lFPhUQfdjAxymn-H3OhnRAb4rcV3IIj5JYeqEaYfSa9Kl0wLB66UtTUn9f4M43NSwZ0dnFc0JtwNW0dZY9AH3yeoTcrC$
> <https://urldefense.com/v3/__https:/www.ietf.org/archive/id/draft-vanbrouwershaven-acme-auto-discovery-00.txt__;!!FJ-Y8qCqXTj2!d0ZjHZK3lFPhUQfdjAxymn-H3OhnRAb4rcV3IIj5JYeqEaYfSa9Kl0wLB66UtTUn9f4M43NSwZ0dnFc0JtwNW0dZY9AH3yeoTcrC$>
> Status:
> https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-vanbrouwershaven-acme-auto-discovery/__;!!FJ-Y8qCqXTj2!d0ZjHZK3lFPhUQfdjAxymn-H3OhnRAb4rcV3IIj5JYeqEaYfSa9Kl0wLB66UtTUn9f4M43NSwZ0dnFc0JtwNW0dZY9AH39B9nSJz$
> <https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/draft-vanbrouwershaven-acme-auto-discovery/__;!!FJ-Y8qCqXTj2!d0ZjHZK3lFPhUQfdjAxymn-H3OhnRAb4rcV3IIj5JYeqEaYfSa9Kl0wLB66UtTUn9f4M43NSwZ0dnFc0JtwNW0dZY9AH39B9nSJz$>
> Html:
> https://urldefense.com/v3/__https://www.ietf.org/archive/id/draft-vanbrouwershaven-acme-auto-discovery-00.html__;!!FJ-Y8qCqXTj2!d0ZjHZK3lFPhUQfdjAxymn-H3OhnRAb4rcV3IIj5JYeqEaYfSa9Kl0wLB66UtTUn9f4M43NSwZ0dnFc0JtwNW0dZY9AH3-CaBB-W$
> <https://urldefense.com/v3/__https:/www.ietf.org/archive/id/draft-vanbrouwershaven-acme-auto-discovery-00.html__;!!FJ-Y8qCqXTj2!d0ZjHZK3lFPhUQfdjAxymn-H3OhnRAb4rcV3IIj5JYeqEaYfSa9Kl0wLB66UtTUn9f4M43NSwZ0dnFc0JtwNW0dZY9AH3-CaBB-W$>
> Htmlized:
> https://urldefense.com/v3/__https://datatracker.ietf.org/doc/html/draft-vanbrouwershaven-acme-auto-discovery__;!!FJ-Y8qCqXTj2!d0ZjHZK3lFPhUQfdjAxymn-H3OhnRAb4rcV3IIj5JYeqEaYfSa9Kl0wLB66UtTUn9f4M43NSwZ0dnFc0JtwNW0dZY9AH37daXF_h$
> <https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/html/draft-vanbrouwershaven-acme-auto-discovery__;!!FJ-Y8qCqXTj2!d0ZjHZK3lFPhUQfdjAxymn-H3OhnRAb4rcV3IIj5JYeqEaYfSa9Kl0wLB66UtTUn9f4M43NSwZ0dnFc0JtwNW0dZY9AH37daXF_h$>
>
>
> 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://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/acme__;!!FJ-Y8qCqXTj2!d0ZjHZK3lFPhUQfdjAxymn-H3OhnRAb4rcV3IIj5JYeqEaYfSa9Kl0wLB66UtTUn9f4M43NSwZ0dnFc0JtwNW0dZY9AH39SGJXVL$
> <https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/acme__;!!FJ-Y8qCqXTj2!d0ZjHZK3lFPhUQfdjAxymn-H3OhnRAb4rcV3IIj5JYeqEaYfSa9Kl0wLB66UtTUn9f4M43NSwZ0dnFc0JtwNW0dZY9AH39SGJXVL$>
>
> _______________________________________________
> Acme mailing list
> Acme@ietf.org
> https://www.ietf.org/mailman/listinfo/acme
> <https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/acme__;!!FJ-Y8qCqXTj2!dkA-aNZjWJ2iRA710YhwS2Q8Wp5eO8PSucEpnW-QJYXUqL3HYw_IDr94J6khGxIm7FloPwjZZbvYWdEIbTRP_6WN$>
>
> _______________________________________________
> Acme mailing list
> Acme@ietf.org
> https://www.ietf.org/mailman/listinfo/acme
>