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

[Mike Ounsworth]

At 117, I spoke with Phillip Hallam-Baker (the IANA Designated Expert for the 
CAA registry) and he’s ok with creating whatever registries for whatever 
parameters we need to make this work.

---
Mike Ounsworth

From: Q Misell 
Sent: Tuesday, August 22, 2023 10:12 AM
To: Paul van Brouwershaven 
Cc: Fraser Tweedale ; Richard Barnes ; Mike 
Ounsworth ; acme@ietf.org
Subject: Re: [Acme] FW: [EXTERNAL] New Version Notification for 
draft-vanbrouwershaven-acme-auto-discovery-00.txt

I think another RFC defining the existence of this registry would be the best 
approach. Any statements contained in this email are personal to the author and 
are not necessarily the statements of the company unless specifically stated. 
AS207960

I think another RFC defining the existence of this registry would be the best 
approach.


Any statements contained in this email are personal to the author and are not 
necessarily the statements of the company unless specifically stated. AS207960 
Cyfyngedig, having a registered office at 13 Pen-y-lan Terrace, Caerdydd, 
Cymru, CF23 9EU, trading as Glauca Digital, is a company registered in Wales 
under № 
12417574<https://urldefense.com/v3/__https:/find-and-update.company-information.service.gov.uk/company/12417574__;!!FJ-Y8qCqXTj2!cq6PNdD0buWytA9oZExMWf-8K7lmk_kwPaVriQS6hjZYizFKrT0vItOARebexN5I-bBjjduvvC8nU02b7PWtr2tpXmzCAgWB5sva$>,
 LEI 875500FXNCJPAPF3PD10. ICO register №: 
ZA782876<https://urldefense.com/v3/__https:/ico.org.uk/ESDWebPages/Entry/ZA782876__;!!FJ-Y8qCqXTj2!cq6PNdD0buWytA9oZExMWf-8K7lmk_kwPaVriQS6hjZYizFKrT0vItOARebexN5I-bBjjduvvC8nU02b7PWtr2tpXmzCApQFJXKj$>.
 UK VAT №: GB378323867. EU VAT №: EU372013983. Turkish VAT №: 0861333524. South 
Korean VAT №: 522-80-03080. AS207960 Ewrop OÜ, having a registered office at 
Lääne-Viru maakond, Tapa vald, Porkuni küla, Lossi tn 1, 46001, trading as 
Glauca Digital, is a company registered in Estonia under № 16755226. Estonian 
VAT №: EE102625532. Glauca Digital and the Glauca logo are registered 
trademarks in the UK, under № UK3718474 and № UK3718468, respectively.


On Fri, 18 Aug 2023 at 17:13, Paul van Brouwershaven 
mailto:40entrust@dmarc.ietf.org>>
 wrote:
Hi Fraser,

I have not replied to this part of your message:

> 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<https://urldefense.com/v3/__https:/www.iana.org/assignments/pkix-parameters/pkix-parameters.xhtml*caa-properties__;Iw!!FJ-Y8qCqXTj2!cq6PNdD0buWytA9oZExMWf-8K7lmk_kwPaVriQS6hjZYizFKrT0vItOARebexN5I-bBjjduvvC8nU02b7PWtr2tpXmzCAgEezh8x$>

In the draft we are defining a parameter and not a property, I don't think 
there is a registry for parameters as these can be CA specific.

However, I think it could be valuable to define a registry as we know have 
multiple documents (such as RFC 8657) defining parameters, but I'm not sure how 
we would initiate that.

Paul

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!cq6PNdD0buWytA9oZExMWf-8K7lmk_kwPaVriQS6hjZYizFKrT0vItOARebexN5I-bBjjduvvC8nU02b7PWtr2tpXmzCAv69t6Kl$>
___
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme

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

[Q Misell]

I think another RFC defining the existence of this registry would be the
best approach.
--

Any statements contained in this email are personal to the author and are
not necessarily the statements of the company unless specifically stated.
AS207960 Cyfyngedig, having a registered office at 13 Pen-y-lan Terrace,
Caerdydd, Cymru, CF23 9EU, trading as Glauca Digital, is a company
registered in Wales under № 12417574
,
LEI 875500FXNCJPAPF3PD10. ICO register №: ZA782876
. UK VAT №: GB378323867. EU
VAT №: EU372013983. Turkish VAT №: 0861333524. South Korean VAT №:
522-80-03080. AS207960 Ewrop OÜ, having a registered office at Lääne-Viru
maakond, Tapa vald, Porkuni küla, Lossi tn 1, 46001, trading as Glauca
Digital, is a company registered in Estonia under № 16755226. Estonian VAT
№: EE102625532. Glauca Digital and the Glauca logo are registered
trademarks in the UK, under № UK3718474 and № UK3718468,
respectively.


On Fri, 18 Aug 2023 at 17:13, Paul van Brouwershaven  wrote:

> Hi Fraser,
>
> I have not replied to this part of your message:
>
> > 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
>
> In the draft we are defining a parameter and not a property, I don't think
> there is a registry for parameters as these can be CA specific.
>
> However, I think it could be valuable to define a registry as we know have
> multiple documents (such as RFC 8657) defining parameters, but I'm not sure
> how we would initiate that.
>
> Paul
>
> 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

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

[Paul van Brouwershaven]

Hi Fraser,

I have not replied to this part of your message:

> 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

In the draft we are defining a parameter and not a property, I don't think 
there is a registry for parameters as these can be CA specific.

However, I think it could be valuable to define a registry as we know have 
multiple documents (such as RFC 8657) defining parameters, but I'm not sure how 
we would initiate that.

Paul

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

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

[Aaron Gable]

(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  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 
> Sent: Thursday, July 6, 2023 9:39 AM
> To: Mike Ounsworth ; 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 serv

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

[Michael Richardson]

tl;dr> I haven't read the document yet, but based upon the presentation, it
   looks like it fits into the ACME charter, and we should work on it.

Amir Omidi  wrote:
> CAA
> has so far been a ACME server side value, rather than client side. If

"Well actually,"
It's not specific to ACME, but to any CA.

> 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.

I think that this is a concern, and I hope DNSOP will weigh in here as to the
value of a new RR vs using this one.  So far, I'm not seeing nails.

> 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.

override... remove and replace, or just extend?
I know many semi-technical managers like one-stop shopping, but it scares me,
and there are many services where I remain a product rather than a customer

> #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 because the provider wants to be able to try the backups in an
orderly (intime) fashion.   Many small sites are basically on auto-pilot for
the durations (<30 days) involved.   While some round-the-world blogger might
be able to get emails while travelling, they might not be able to do HTTPS
safely to reach the "drop-down"

> 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.

All good points.
I think that there should be some more applicability scope.

I think there is a difference between hosting-providers-at-scale vs foo.com
who has 37 horizontally scaled micro-services that they have automated.

--
Michael Richardson. o O ( IPv6 IøT consulting )
   Sandelman Software Works Inc, Ottawa and Worldwide






signature.asc
Description: PGP signature
___
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme

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

[Amir Omidi]

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  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  *On Behalf Of * Deb Cooley
> *Sent:* Thursday, July 20, 2023 5:38 AM
> *To:* Mike Ounsworth ; IETF
> ACME 
> *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  40entrust@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  On Behalf Of Mike Ounsworth
> Sent: Thursday, July 6, 2023 9:54 AM
> To: acme@ietf.org
> Cc: Paul van Brouwershaven 
> Subject: [Acme] FW: [EXTERNAL] New Version Notification for
> draft-vanbrouwershaven-acme-auto-discovery-00.txt
>
> Hi AC

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

[Mike Ounsworth]

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  On Behalf Of Deb Cooley
Sent: Thursday, July 20, 2023 5:38 AM
To: Mike Ounsworth ; IETF ACME 

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 
mailto:40entrust@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 mailto:acme-boun...@ietf.org>> On Behalf Of 
Mike Ounsworth
Sent: Thursday, July 6, 2023 9:54 AM
To: acme@ietf.org<mailto:acme@ietf.org>
Cc: Paul van Brouwershaven 
mailto:paul.vanbrouwersha...@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-dra...@ietf.org<mailto:internet-dra...@ietf.org> 
mailto:internet-dra...@ietf.org>>
Sent: Thursday, July 6, 2023 9:39 AM
To: Mike Ounsworth 
mailto:mike.ounswo...@entrust.com>>; Paul van 
Brouwershaven 
mailto: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://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

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

[Deb Cooley]

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  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  On Behalf Of Mike Ounsworth
> Sent: Thursday, July 6, 2023 9:54 AM
> To: acme@ietf.org
> Cc: Paul van Brouwershaven 
> 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-dra...@ietf.org 
> Sent: Thursday, July 6, 2023 9:39 AM
> To: Mike Ounsworth ; 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://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$
> Html:
> 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$
>
>
> 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$
>
> ___
> 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

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

[Mike Ounsworth]

Personally, I like the way “no priority” is currently handled in 3.1.2:
“In the case that this parameter is not specified, the entry will be considered 
to have a lower priority than all entries which specify any priority.”


Thinking out loud here: @Tim 
Hollebeek<mailto:tim.hollebeek=40digicert@dmarc.ietf.org> how do you feel 
about treating multiple entries of the same priority as random-round-robin? The 
justification is that it enables load-balancing. But it’s also a source of 
complexity and I’m curious if it feels “necessary” to you. It could instead be 
left to the discretion of the implementer of the ACME client and we could say 
“for example selected randomly, or in the order they appear in the DNS record”.

---
Mike Ounsworth

From: Acme  On Behalf Of Tim Hollebeek
Sent: Wednesday, July 12, 2023 3:03 PM
To: Seo Suchan ; acme@ietf.org
Subject: Re: [Acme] FW: [EXTERNAL] New Version Notification for 
draft-vanbrouwershaven-acme-auto-discovery-00.txt

The problem with inverting things like that is that the highest priority is 
important, and so identifying a value that corresponds to the highest priority 
(like 1) is very useful.  Having an explicit value for the lowest priority is 
very low priority.

If you use zero for the lowest priority, then the highest priority value is a 
very inconvenient number (MAXINT or similar).

I agree with Rich Salz: priorities are positive integers, and 1 is the highest. 
 That’s a pretty standard way of expressing priorities.  Anything beyond that 
is an unnecessary complication.

-Tim

From: Acme mailto:acme-boun...@ietf.org>> On Behalf Of 
Seo Suchan
Sent: Wednesday, July 12, 2023 3:29 PM
To: acme@ietf.org<mailto:acme@ietf.org>
Subject: Re: [Acme] FW: [EXTERNAL] New Version Notification for 
draft-vanbrouwershaven-acme-auto-discovery-00.txt


I think make priority descending order removes such headache: default is 0 and 
so it has lowest priority than any other integer, make no reason to treat 0 
exceptionally.


2023-07-13 오전 3:34에 Paul van Brouwershaven 이(가) 쓴 글:
I have to agree that 0 is not a positive integer and reverted the prior change:

> In the case that this parameter is not specified or contains the value "0", 
> the entry will be considered to have a lower priority than all entries which 
> specify any priority.

So, setting "0" would invalidate the parameter, causing the ACME client to 
ignore the CAA record all together.

Does this also make sense to you Q?


From: Tim Hollebeek 
<mailto:tim.hollebeek=40digicert@dmarc.ietf.org>
Sent: Wednesday, July 12, 2023 19:32
To: Paul van Brouwershaven 
<mailto:paul.vanbrouwersha...@entrust.com>; 
Q Misell <mailto:q...@as207960.net>
Cc: acme@ietf.org<mailto:acme@ietf.org> <mailto:acme@ietf.org>
Subject: RE: [Acme] FW: [EXTERNAL] New Version Notification for 
draft-vanbrouwershaven-acme-auto-discovery-00.txt


If priority is defined as a positive integer (which makes sense to me), then 
zero is an error, yes.



If it’s desirable to have a “no priority” value, then zero might be a 
reasonable choice for such a value.  But it’s hard to reason about whether “no 
priority” is higher or lower than items that do have priorities, so I think “no 
priority” adds additional complexity that should not be added unnecessarily.  I 
think it’s simpler to stick to a single, ordered list of priority numbers, and 
ordinal numbers (a.k.a positive integers) are the best way to express that.



-Tim



From: Paul van Brouwershaven 
<mailto:Paul.vanBrouwershaven=40entrust@dmarc.ietf.org>
Sent: Wednesday, July 12, 2023 1:01 PM
To: Tim Hollebeek 
<mailto:tim.holleb...@digicert.com>; Q Misell 
<mailto:q...@as207960.net>
Cc: acme@ietf.org<mailto:acme@ietf.org>
Subject: Re: [Acme] FW: [EXTERNAL] New Version Notification for 
draft-vanbrouwershaven-acme-auto-discovery-00.txt



> Anyone who argues that zero is a positive integer should be referred to the 
> standard math textbook of positive.  Zero is a non-negative integer, but I’m 
> not aware of any definition of “positive” that makes it a positive integer.



Do you argue that "0" should be threatened as an error instead of equal to no 
priority?





From: Tim Hollebeek 
mailto:tim.hollebeek=40digicert@dmarc.ietf.org>>
Sent: Wednesday, July 12, 2023 6:43:21 PM
To: Paul van Brouwershaven 
mailto:paul.vanbrouwersha...@entrust.com>>; 
Q Misell mailto:q...@as207960.net>>
Cc: acme@ietf.org<mailto:acme@ietf.org> mailto:acme@ietf.org>>
Subject: RE: [Acme] FW: [EXTERNAL] New Version Notification for 
draft-vanbrouwershaven-acme-auto-discovery-00.txt



Anyone who argues that zero is a positive integer should be referred to the 
standard math textbook of positive.  Zero is a non-negative integer, but I’m 
not aware of any definition of “positive” that makes it a p

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

[Mike Ounsworth]

@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  On Behalf Of Mike Ounsworth
Sent: Thursday, July 6, 2023 9:54 AM
To: acme@ietf.org
Cc: Paul van Brouwershaven 
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-dra...@ietf.org 
Sent: Thursday, July 6, 2023 9:39 AM
To: Mike Ounsworth ; Paul van Brouwershaven 

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$
 
Status: 
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$
 
Htmlized:
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$
 

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

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

[Paul van Brouwershaven]

I have rewritten items 3.x in section 
5.1<https://vanbroup.github.io/acme-auto-discovery/draft-vanbrouwershaven-acme-auto-discovery.html#section-5.1>
 and hope this makes it easier to understand, the 
example<https://vanbroup.github.io/acme-auto-discovery/draft-vanbrouwershaven-acme-auto-discovery.html#section-5.1.1>
 is also slightly updated but might no longer be needed, what do you think?



From: Carl Wallace 
Sent: Wednesday, July 12, 2023 22:02
To: Paul van Brouwershaven ; Mike Ounsworth 
; acme@ietf.org 
Subject: Re: [Acme] FW: [EXTERNAL] New Version Notification for 
draft-vanbrouwershaven-acme-auto-discovery-00.txt


The example is good, but it doesn’t quite get at the issue. I think the 
problematic text is “if no common CA is found.” In the example, there is a 
common CA, there are just different priorities. It does help clarify the “as 
few domains” part though. Maybe something like “if all domains do not prefer 
the same CA, the ACME client tries…” would be more clear.



From: Paul van Brouwershaven 
Date: Wednesday, July 12, 2023 at 2:30 PM
To: Carl Wallace , Mike Ounsworth 
, "acme@ietf.org" 
Subject: Re: [Acme] FW: [EXTERNAL] New Version Notification for 
draft-vanbrouwershaven-acme-auto-discovery-00.txt



>> - In 5.1, what does 3.b mean? Can you add an example?
> I will try to add an example here.



Does this example help to clarify the intend of 3.b?

https://vanbroup.github.io/acme-auto-discovery/draft-vanbrouwershaven-acme-auto-discovery.html#name-selecting-a-common-ca-throu<https://urldefense.com/v3/__https://vanbroup.github.io/acme-auto-discovery/draft-vanbrouwershaven-acme-auto-discovery.html*name-selecting-a-common-ca-throu__;Iw!!FJ-Y8qCqXTj2!eFlTAJDn4_qEQIeBFBPRukY5rsKusH5eWmPHWn-2zCmUOmW1e-UCZqS9B6bv14wTuIKceVYqwHIfr2LDsFnGtha72nkijTE$>



The other changes have also been incorporated.





From: Paul van Brouwershaven 
Sent: Wednesday, July 12, 2023 18:16
To: Carl Wallace ; Mike Ounsworth 
; acme@ietf.org 
Subject: Re: [Acme] FW: [EXTERNAL] New Version Notification for 
draft-vanbrouwershaven-acme-auto-discovery-00.txt



Thanks for your detailed review!

- Why is the draft informational and not standards track?

Most people I spoke to, while discussing the idea, thought that it would need 
to be information, but if people here feel that this needs to be changed to 
standards track, I'm fine with that too. I'm relatively new to the drafting 
process.

- Why does absence turn the feature on? Wouldn't this invite sending spurious 
requests for ACME information to CAs configured before this draft existed that 
do not support ACME?

The reason is that with the move to shorter live certificates, automation will 
become essential. If we default to off, we will likely only see CAA records 
with this option enabled.



The benefit of these spurious requests is that it would give a clear signal to 
these CAs that they might need to adopt ACME and/or auto discovery, something 
that is also pushed by the root programs.



If an account binding is required (which is the case for most commercial CAs) 
the user will be asked to establish this binding, but no certificates will be 
issued until the account binding is established. When no account binding is 
required, the certificate will automatically be replaced by the authorized CA.



See also the security considerations in section 8.1.

- Is a boolean the right type for discovery or should it be a string that 
indicates the protocol that is the target of auto-discovery?

The protocol is already indicated by the property (i.e., issue, issuewild, vmc, 
issuemail, etc.)


- Do/ought parent domains apply (as they do in CAA)? If not, it might be worth 
a few words since the usage here is different.

Yes they do, section 5 states "The ACME client initiates a DNS lookup to 
retrieve the CAA record(s) according to [RFC8659]", which specifies how CAA 
lookups need to be performed.

- In the next to last example in 3.2, why does EV without priority go first?

It should not, we updated the logic later, I will get this corrected by 
including a priority here as well.

- In 5.1, you might want to replace the long paragraph with bullets.

This is fixed on 
GitHub<https://urldefense.com/v3/__https://vanbroup.github.io/acme-auto-discovery/draft-vanbrouwershaven-acme-auto-discovery.html__;!!FJ-Y8qCqXTj2!eFlTAJDn4_qEQIeBFBPRukY5rsKusH5eWmPHWn-2zCmUOmW1e-UCZqS9B6bv14wTuIKceVYqwHIfr2LDsFnGtha7wgu46ys$>
 and will be included in the next release.

- In 5.1, what does 3.b mean? Can you add an example?

I will try to add an example here.

- You should expand QWAC on first use and maybe add an informational reference.

Yes, I will add the meaning of the abbreviations and maybe a reference there.



Thanks,



Paul





From: Carl Wallace 
Sent: Wednesday, July 12, 2023 17:48
To: Mike Ounsworth 

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

[Paul van Brouwershaven]

While it's not as explicit as stating that you can't use 0, this will make it 
easier to understand for some.

I updated this in the draft.



From: Salz, Rich 
Sent: Wednesday, July 12, 2023 9:38:36 PM
To: Paul van Brouwershaven ; Q Misell 

Cc: Tim Hollebeek ; acme@ietf.org 
Subject: Re: [Acme] FW: [EXTERNAL] New Version Notification for 
draft-vanbrouwershaven-acme-auto-discovery-00.txt


I added the following note:



Maybe just say the priority is an integer greater than zero.  No notes needed.

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

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

[Tim Hollebeek]

The problem with inverting things like that is that the highest priority is 
important, and so identifying a value that corresponds to the highest priority 
(like 1) is very useful.  Having an explicit value for the lowest priority is 
very low priority.

If you use zero for the lowest priority, then the highest priority value is a 
very inconvenient number (MAXINT or similar).

I agree with Rich Salz: priorities are positive integers, and 1 is the highest. 
 That’s a pretty standard way of expressing priorities.  Anything beyond that 
is an unnecessary complication.

-Tim

From: Acme  On Behalf Of Seo Suchan
Sent: Wednesday, July 12, 2023 3:29 PM
To: acme@ietf.org
Subject: Re: [Acme] FW: [EXTERNAL] New Version Notification for 
draft-vanbrouwershaven-acme-auto-discovery-00.txt


I think make priority descending order removes such headache: default is 0 and 
so it has lowest priority than any other integer, make no reason to treat 0 
exceptionally.


2023-07-13 오전 3:34에 Paul van Brouwershaven 이(가) 쓴 글:
I have to agree that 0 is not a positive integer and reverted the prior change:

> In the case that this parameter is not specified or contains the value "0", 
> the entry will be considered to have a lower priority than all entries which 
> specify any priority.

So, setting "0" would invalidate the parameter, causing the ACME client to 
ignore the CAA record all together.

Does this also make sense to you Q?


From: Tim Hollebeek 
<mailto:tim.hollebeek=40digicert@dmarc.ietf.org>
Sent: Wednesday, July 12, 2023 19:32
To: Paul van Brouwershaven 
<mailto:paul.vanbrouwersha...@entrust.com>; 
Q Misell <mailto:q...@as207960.net>
Cc: acme@ietf.org<mailto:acme@ietf.org> <mailto:acme@ietf.org>
Subject: RE: [Acme] FW: [EXTERNAL] New Version Notification for 
draft-vanbrouwershaven-acme-auto-discovery-00.txt


If priority is defined as a positive integer (which makes sense to me), then 
zero is an error, yes.



If it’s desirable to have a “no priority” value, then zero might be a 
reasonable choice for such a value.  But it’s hard to reason about whether “no 
priority” is higher or lower than items that do have priorities, so I think “no 
priority” adds additional complexity that should not be added unnecessarily.  I 
think it’s simpler to stick to a single, ordered list of priority numbers, and 
ordinal numbers (a.k.a positive integers) are the best way to express that.



-Tim



From: Paul van Brouwershaven 
<mailto:Paul.vanBrouwershaven=40entrust@dmarc.ietf.org>
Sent: Wednesday, July 12, 2023 1:01 PM
To: Tim Hollebeek 
<mailto:tim.holleb...@digicert.com>; Q Misell 
<mailto:q...@as207960.net>
Cc: acme@ietf.org<mailto:acme@ietf.org>
Subject: Re: [Acme] FW: [EXTERNAL] New Version Notification for 
draft-vanbrouwershaven-acme-auto-discovery-00.txt



> Anyone who argues that zero is a positive integer should be referred to the 
> standard math textbook of positive.  Zero is a non-negative integer, but I’m 
> not aware of any definition of “positive” that makes it a positive integer.



Do you argue that "0" should be threatened as an error instead of equal to no 
priority?





From: Tim Hollebeek 
mailto:tim.hollebeek=40digicert@dmarc.ietf.org>>
Sent: Wednesday, July 12, 2023 6:43:21 PM
To: Paul van Brouwershaven 
mailto:paul.vanbrouwersha...@entrust.com>>; 
Q Misell mailto:q...@as207960.net>>
Cc: acme@ietf.org<mailto:acme@ietf.org> mailto:acme@ietf.org>>
Subject: RE: [Acme] FW: [EXTERNAL] New Version Notification for 
draft-vanbrouwershaven-acme-auto-discovery-00.txt



Anyone who argues that zero is a positive integer should be referred to the 
standard math textbook of positive.  Zero is a non-negative integer, but I’m 
not aware of any definition of “positive” that makes it a positive integer.



Also, ignoring failures in CAA records is probably not the right answer.  CAA 
should fail closed, not open.



-Tim



From: Acme mailto:acme-boun...@ietf.org>> On Behalf Of 
Paul van Brouwershaven
Sent: Wednesday, July 12, 2023 9:52 AM
To: Q Misell mailto:q...@as207960.net>>
Cc: acme@ietf.org<mailto:acme@ietf.org>
Subject: Re: [Acme] FW: [EXTERNAL] New Version Notification for 
draft-vanbrouwershaven-acme-auto-discovery-00.txt



Hi Q,



Thanks, this is great and really helpful!

Is priority=0 an error coditition, some might argue 0 is a positive integer?

Any suggestion? maybe we should simply start counting at 0 instead of 1

What about discovery=foobar?

"foobar" is not a Boolean, the text is clear that this parameter MUST be a 
Boolean, so this should invalidate the parameter.

Should the client ignore invalid issue records and process the rest, or fail 
outright?

We should ignore the failure of a single CAA record and continue with the next, 
similar to when the client encounter

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

[Carl Wallace]

The example is good, but it doesn’t quite get at the issue. I think the 
problematic text is “if no common CA is found.” In the example, there is a 
common CA, there are just different priorities. It does help clarify the “as 
few domains” part though. Maybe something like “if all domains do not prefer 
the same CA, the ACME client tries…” would be more clear.

 

From: Paul van Brouwershaven 
Date: Wednesday, July 12, 2023 at 2:30 PM
To: Carl Wallace , Mike Ounsworth 
, "acme@ietf.org" 
Subject: Re: [Acme] FW: [EXTERNAL] New Version Notification for 
draft-vanbrouwershaven-acme-auto-discovery-00.txt

 

>> - In 5.1, what does 3.b mean? Can you add an example?
> I will try to add an example here.

 

Does this example help to clarify the intend of 3.b?

https://vanbroup.github.io/acme-auto-discovery/draft-vanbrouwershaven-acme-auto-discovery.html#name-selecting-a-common-ca-throu

 

The other changes have also been incorporated.

 

From: Paul van Brouwershaven 
Sent: Wednesday, July 12, 2023 18:16
To: Carl Wallace ; Mike Ounsworth 
; acme@ietf.org 
Subject: Re: [Acme] FW: [EXTERNAL] New Version Notification for 
draft-vanbrouwershaven-acme-auto-discovery-00.txt 

 

Thanks for your detailed review!

- Why is the draft informational and not standards track?

Most people I spoke to, while discussing the idea, thought that it would need 
to be information, but if people here feel that this needs to be changed to 
standards track, I'm fine with that too. I'm relatively new to the drafting 
process.

- Why does absence turn the feature on? Wouldn't this invite sending spurious 
requests for ACME information to CAs configured before this draft existed that 
do not support ACME?

The reason is that with the move to shorter live certificates, automation will 
become essential. If we default to off, we will likely only see CAA records 
with this option enabled.



The benefit of these spurious requests is that it would give a clear signal to 
these CAs that they might need to adopt ACME and/or auto discovery, something 
that is also pushed by the root programs.



If an account binding is required (which is the case for most commercial CAs) 
the user will be asked to establish this binding, but no certificates will be 
issued until the account binding is established. When no account binding is 
required, the certificate will automatically be replaced by the authorized CA.



See also the security considerations in section 8.1.

- Is a boolean the right type for discovery or should it be a string that 
indicates the protocol that is the target of auto-discovery?

The protocol is already indicated by the property (i.e., issue, issuewild, vmc, 
issuemail, etc.)

- Do/ought parent domains apply (as they do in CAA)? If not, it might be worth 
a few words since the usage here is different.

Yes they do, section 5 states "The ACME client initiates a DNS lookup to 
retrieve the CAA record(s) according to [RFC8659]", which specifies how CAA 
lookups need to be performed.

- In the next to last example in 3.2, why does EV without priority go first?

It should not, we updated the logic later, I will get this corrected by 
including a priority here as well.

- In 5.1, you might want to replace the long paragraph with bullets.

This is fixed on GitHub and will be included in the next release.

- In 5.1, what does 3.b mean? Can you add an example?

I will try to add an example here.

- You should expand QWAC on first use and maybe add an informational reference.

Yes, I will add the meaning of the abbreviations and maybe a reference there.



Thanks,



Paul



From: Carl Wallace 
Sent: Wednesday, July 12, 2023 17:48
To: Mike Ounsworth ; acme@ietf.org 

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

 

This looks like a useful addition. Here are a few comments and questions:

- Why is the draft informational and not standards track?

- Why does absence turn the feature on? Wouldn't this invite sending spurious 
requests for ACME information to CAs configured before this draft existed that 
do not support ACME? 

- Is a boolean the right type for discovery or should it be a string that 
indicates the protocol that is the target of auto-discovery?

- Do/ought parent domains apply (as they do in CAA)? If not, it might be worth 
a few words since the usage here is different.

- In the next to last example in 3.2, why does EV without priority go first?

- In 5.1, you might want to replace the long paragraph with bullets. 

- In 5.1, what does 3.b mean? Can you add an example?

- You should expand QWAC on first use and maybe add an informational reference. 


On 7/6/23, 10:54 AM, "Acme on behalf of Mike Ounsworth" mailto:acme-boun...@ietf.org> on behalf of 
Mike.Ounsworth=40entrust@dmarc.ietf.org 
<mailto:40entrust@dmarc.ietf.org>> wrote:


Hi ACME!

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

[Salz, Rich]

I added the following note:

Maybe just say the priority is an integer greater than zero.  No notes needed.
___
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme

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

[Paul van Brouwershaven]

I added the following note:

To adhere to the definition of a positive integer, the value "0" should not be 
used as it does not meet the criteria of a positive value. Therefore, any 
occurrence of "0" as the value for the priority attribute MUST be rejected as 
invalid.


From: Q Misell 
Sent: Wednesday, July 12, 2023 9:04:29 PM
To: Paul van Brouwershaven 
Cc: Tim Hollebeek ; acme@ietf.org 

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

Yes, it does. I think an explicit note that 0 is not allowed should be made 
however.


Any statements contained in this email are personal to the author and are not 
necessarily the statements of the company unless specifically stated. AS207960 
Cyfyngedig, having a registered office at 13 Pen-y-lan Terrace, Caerdydd, 
Cymru, CF23 9EU, trading as Glauca Digital, is a company registered in Wales 
under № 
12417574<https://urldefense.com/v3/__https://find-and-update.company-information.service.gov.uk/company/12417574__;!!FJ-Y8qCqXTj2!eaLuZBGwdMIIaL4r0pOmweZ_8bKpKo-9r2nHSSTKvc8tcdi3P1JI7hbvF9V7jiroeNYy6XAOxOLoRBNdgniAwdOe$>,
 LEI 875500FXNCJPAPF3PD10. ICO register №: 
ZA782876<https://urldefense.com/v3/__https://ico.org.uk/ESDWebPages/Entry/ZA782876__;!!FJ-Y8qCqXTj2!eaLuZBGwdMIIaL4r0pOmweZ_8bKpKo-9r2nHSSTKvc8tcdi3P1JI7hbvF9V7jiroeNYy6XAOxOLoRBNdgs4oDAGz$>.
 UK VAT №: GB378323867. EU VAT №: EU372013983. Turkish VAT №: 0861333524. South 
Korean VAT №: 522-80-03080. AS207960 Ewrop OÜ, having a registered office at 
Lääne-Viru maakond, Tapa vald, Porkuni küla, Lossi tn 1, 46001, trading as 
Glauca Digital, is a company registered in Estonia under № 16755226. Estonian 
VAT №: EE102625532. Glauca Digital and the Glauca logo are registered 
trademarks in the UK, under № UK3718474 and № UK3718468, respectively.


On Wed, 12 Jul 2023 at 19:34, Paul van Brouwershaven 
mailto:paul.vanbrouwersha...@entrust.com>> 
wrote:
I have to agree that 0 is not a positive integer and reverted the prior change:

> In the case that this parameter is not specified or contains the value "0", 
> the entry will be considered to have a lower priority than all entries which 
> specify any priority.

So, setting "0" would invalidate the parameter, causing the ACME client to 
ignore the CAA record all together.

Does this also make sense to you Q?


From: Tim Hollebeek 
mailto:40digicert@dmarc.ietf.org>>
Sent: Wednesday, July 12, 2023 19:32
To: Paul van Brouwershaven 
mailto:paul.vanbrouwersha...@entrust.com>>; 
Q Misell mailto:q...@as207960.net>>
Cc: acme@ietf.org<mailto:acme@ietf.org> mailto:acme@ietf.org>>
Subject: RE: [Acme] FW: [EXTERNAL] New Version Notification for 
draft-vanbrouwershaven-acme-auto-discovery-00.txt


If priority is defined as a positive integer (which makes sense to me), then 
zero is an error, yes.



If it’s desirable to have a “no priority” value, then zero might be a 
reasonable choice for such a value.  But it’s hard to reason about whether “no 
priority” is higher or lower than items that do have priorities, so I think “no 
priority” adds additional complexity that should not be added unnecessarily.  I 
think it’s simpler to stick to a single, ordered list of priority numbers, and 
ordinal numbers (a.k.a positive integers) are the best way to express that.



-Tim



From: Paul van Brouwershaven 
mailto:40entrust@dmarc.ietf.org>>
Sent: Wednesday, July 12, 2023 1:01 PM
To: Tim Hollebeek 
mailto:tim.holleb...@digicert.com>>; Q Misell 
mailto:q...@as207960.net>>
Cc: acme@ietf.org<mailto:acme@ietf.org>
Subject: Re: [Acme] FW: [EXTERNAL] New Version Notification for 
draft-vanbrouwershaven-acme-auto-discovery-00.txt



> Anyone who argues that zero is a positive integer should be referred to the 
> standard math textbook of positive.  Zero is a non-negative integer, but I’m 
> not aware of any definition of “positive” that makes it a positive integer.



Do you argue that "0" should be threatened as an error instead of equal to no 
priority?





From: Tim Hollebeek 
mailto:tim.hollebeek=40digicert@dmarc.ietf.org>>
Sent: Wednesday, July 12, 2023 6:43:21 PM
To: Paul van Brouwershaven 
mailto:paul.vanbrouwersha...@entrust.com>>; 
Q Misell mailto:q...@as207960.net>>
Cc: acme@ietf.org<mailto:acme@ietf.org> mailto:acme@ietf.org>>
Subject: RE: [Acme] FW: [EXTERNAL] New Version Notification for 
draft-vanbrouwershaven-acme-auto-discovery-00.txt



Anyone who argues that zero is a positive integer should be referred to the 
standard math textbook of positive.  Zero is a non-negative integer, but I’m 
not aware of any definition of “positive” that makes it a positive integer.



Also, ignoring failures in C

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

[Seo Suchan]

I think make priority descending order removes such headache: default is 
0 and so it has lowest priority than any other integer, make no reason 
to treat 0 exceptionally.



2023-07-13 오전 3:34에 Paul van Brouwershaven 이(가) 쓴 글:
I have to agree that 0 is not a positive integer and reverted the 
prior change:


/> In the case that this parameter is not specified*_or contains the 
value "0"_*, the entry will be considered to have a lower priority 
than all entries which specify any priority./

/
/
So, setting "0" would invalidate the parameter, causing the ACME 
client to ignore the CAA record all together.


Does this also make sense to you Q?


*From:* Tim Hollebeek 
*Sent:* Wednesday, July 12, 2023 19:32
*To:* Paul van Brouwershaven ; Q 
Misell 

*Cc:* acme@ietf.org 
*Subject:* RE: [Acme] FW: [EXTERNAL] New Version Notification for 
draft-vanbrouwershaven-acme-auto-discovery-00.txt


If priority is defined as a positive integer (which makes sense to 
me), then zero is an error, yes.


If it’s desirable to have a “no priority” value, then zero might be a 
reasonable choice for such a value.  But it’s hard to reason about 
whether “no priority” is higher or lower than items that do have 
priorities, so I think “no priority” adds additional complexity that 
should not be added unnecessarily.  I think it’s simpler to stick to a 
single, ordered list of priority numbers, and ordinal numbers (a.k.a 
positive integers) are the best way to express that.


-Tim

*From:* Paul van Brouwershaven 


*Sent:* Wednesday, July 12, 2023 1:01 PM
*To:* Tim Hollebeek ; Q Misell 


*Cc:* acme@ietf.org
*Subject:* Re: [Acme] FW: [EXTERNAL] New Version Notification for 
draft-vanbrouwershaven-acme-auto-discovery-00.txt


> Anyone who argues that zero is a positive integer should be referred 
to the standard math textbook of positive.  Zero is a non-negative 
integer, but I’m not aware of any definition of “positive” that makes 
it a positive integer.


Do you argue that "0" should be threatened as an error instead of 
equal to no priority?




*From:*Tim Hollebeek 
*Sent:* Wednesday, July 12, 2023 6:43:21 PM
*To:* Paul van Brouwershaven ; Q 
Misell 

*Cc:* acme@ietf.org 
*Subject:* RE: [Acme] FW: [EXTERNAL] New Version Notification for 
draft-vanbrouwershaven-acme-auto-discovery-00.txt


Anyone who argues that zero is a positive integer should be referred 
to the standard math textbook of positive.  Zero is a non-negative 
integer, but I’m not aware of any definition of “positive” that makes 
it a positive integer.


Also, ignoring failures in CAA records is probably not the right 
answer.  CAA should fail closed, not open.


-Tim

*From:* Acme  *On Behalf Of *Paul van Brouwershaven
*Sent:* Wednesday, July 12, 2023 9:52 AM
*To:* Q Misell 
*Cc:* acme@ietf.org
*Subject:* Re: [Acme] FW: [EXTERNAL] New Version Notification for 
draft-vanbrouwershaven-acme-auto-discovery-00.txt


Hi Q,

Thanks, this is great and really helpful!

Is priority=0 an error coditition, some might argue 0 is a
positive integer?

Any suggestion? maybe we should simply start counting at 0 instead of 1

What about discovery=foobar?

"foobar" is not a Boolean, the text is clear that this parameter MUST 
be a Boolean, so this should invalidate the parameter.


Should the client ignore invalid issue records and process the
rest, or fail outright?

We should ignore the failure of a single CAA record and continue with 
the next, similar to when the client encounters ACME errors.


I will clarify this with the following change:

/The ACME client analyzes the CAA records - > The ACME client
analyzes the *_valid _*CAA records /

It looks like you implemented discovery as a pre-condition while 3.1.1 
specifies:


/When this parameter is not specified the client MUST assume that
discovery is enabled./

There is however a comment in the examples that this behavior might 
need to change if deemed necessary.


Paul



*From:*Q Misell 
*Sent:* Wednesday, July 12, 2023 15:06
*To:* Paul van Brouwershaven 
*Cc:* acme@ietf.org 
*Subject:* Re: [Acme] FW: [EXTERNAL] New Version Notification for 
draft-vanbrouwershaven-acme-auto-discovery-00.txt


Hi all,

I happened to be poking around the certbot codebase today and decided 
to try and implement this draft.


It turned out to be a much simpler task than I had expected, however I 
felt the draft was a bit lacking in details for what the ACME client 
should consider an error.


For example:

  * Is priority=0 an error coditition, some might argue 0 is a
positive integer?
  * What about discovery=foobar?
  * Should the client ignore invalid issue records and process the
rest, or fail outright?

My fork of certbot with the i

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

[Paul van Brouwershaven]

>>You are correct, to facilitate account binding it's important that each 
>>customer is using its own ACME key.

> I will create an issue to spell this out more clearly in the document.

I have added the need for unique ACME key to the security considerations:
https://vanbroup.github.io/acme-auto-discovery/draft-vanbrouwershaven-acme-auto-discovery.html#name-acme-keys

From: Paul van Brouwershaven 
Sent: Friday, July 7, 2023 10:56
To: Q Misell 
Cc: acme@ietf.org 
Subject: Re: [Acme] FW: [EXTERNAL] New Version Notification for 
draft-vanbrouwershaven-acme-auto-discovery-00.txt

Hi Q,

You are correct, to facilitate account binding it's important that each 
customer is using its own ACME key.

I will create an issue to spell this out more clearly in the document.

Paul


From: Q Misell 
Sent: Friday, July 7, 2023 10:50:04 AM
To: Paul van Brouwershaven 
Cc: acme@ietf.org 
Subject: Re: [Acme] FW: [EXTERNAL] New Version Notification for 
draft-vanbrouwershaven-acme-auto-discovery-00.txt

Hi,

Reading the draft I think it is the author's intention (correct me if wrong) 
that each customer of a hosting provider would have a new ACME account created 
for them, and for the contact details on the ACME account to be that of the 
customer, not the hosting provider.

I know it is common with hosting providers at the present time to have one ACME 
account for all customers, and for the contact details to be that of the 
hosting provider. Might it be worth spelling out in the I-D the author's 
intentions about who is the holder of the account. This would also help clarify 
who is actually agreeing to the CA ToS.

Thanks,
Q


Any statements contained in this email are personal to the author and are not 
necessarily the statements of the company unless specifically stated. AS207960 
Cyfyngedig, having a registered office at 13 Pen-y-lan Terrace, Caerdydd, 
Cymru, CF23 9EU, trading as Glauca Digital, is a company registered in Wales 
under № 
12417574<https://urldefense.com/v3/__https://find-and-update.company-information.service.gov.uk/company/12417574__;!!FJ-Y8qCqXTj2!c7XYcqfuEqSdOdkjQ0F2h1p8h_jBL5-aD8KCIDGefelG2Ug4epJsYVUuNkPdJ81OO-sYR_6f8adUvZCApdYEAbi1LdzfL9owygcfPGBKLQ$>,
 LEI 875500FXNCJPAPF3PD10. ICO register №: 
ZA782876<https://urldefense.com/v3/__https://ico.org.uk/ESDWebPages/Entry/ZA782876__;!!FJ-Y8qCqXTj2!c7XYcqfuEqSdOdkjQ0F2h1p8h_jBL5-aD8KCIDGefelG2Ug4epJsYVUuNkPdJ81OO-sYR_6f8adUvZCApdYEAbi1LdzfL9owygfUo261AA$>.
 UK VAT №: GB378323867. EU VAT №: EU372013983. Turkish VAT №: 0861333524. South 
Korean VAT №: 522-80-03080. AS207960 Ewrop OÜ, having a registered office at 
Lääne-Viru maakond, Tapa vald, Porkuni küla, Lossi tn 1, 46001, trading as 
Glauca Digital, is a company registered in Estonia under № 16755226. Estonian 
VAT №: EE102625532. Glauca Digital and the Glauca logo are registered 
trademarks in the UK, under № UK3718474 and № UK3718468, respectively.


On Fri, 7 Jul 2023 at 09:23, Paul van Brouwershaven 
mailto:40entrust@dmarc.ietf.org>>
 wrote:
Adding, that I agree that it would be great if service providers would all 
provide an option to configure ACME clients with a custom server and account 
binding, but I do not see how this would solve the problem of rate limiting.


From: Paul van Brouwershaven 
mailto:paul.vanbrouwersha...@entrust.com>>
Sent: Friday, July 7, 2023 10:16:55 AM
To: Seo Suchan mailto:tjtn...@gmail.com>>; 
acme@ietf.org<mailto:acme@ietf.org> mailto:acme@ietf.org>>
Subject: Re: [Acme] FW: [EXTERNAL] New Version Notification for 
draft-vanbrouwershaven-acme-auto-discovery-00.txt

I expect that rate limiting is main the problem for a CA that is configured as 
default. If there would be thousands of users setting the same CAA records this 
CA would need to identify that the rate limit is hit and adjust accordingly if 
these requests seem to be legit.

This would be less of a problem for a commercial CA who would be bound by 
service level agreements and can identify the customers through the account 
binding so apply a rate limit per customer instead of per IP address/block.

Paul

From: Seo Suchan mailto:tjtn...@gmail.com>>
Sent: Friday, July 7, 2023 10:07:27 AM
To: Paul van Brouwershaven 
mailto:paul.vanbrouwersha...@entrust.com>>; 
acme@ietf.org<mailto:acme@ietf.org> mailto:acme@ietf.org>>
Subject: Re: [Acme] FW: [EXTERNAL] New Version Notification for 
draft-vanbrouwershaven-acme-auto-discovery-00.txt


how about ratelimit? for large hosting they will hit CA's default API ratelimit 
fast, so they contract with a specific CA for ratelimit increase. feels like 
entire automatic CA loadbearing doesn't work without hosting provider having 
eab/acme account from domain holder: if it already ha

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

[Q Misell]

Yes, it does. I think an explicit note that 0 is not allowed should be made
however.
--

Any statements contained in this email are personal to the author and are
not necessarily the statements of the company unless specifically stated.
AS207960 Cyfyngedig, having a registered office at 13 Pen-y-lan Terrace,
Caerdydd, Cymru, CF23 9EU, trading as Glauca Digital, is a company
registered in Wales under № 12417574
<https://find-and-update.company-information.service.gov.uk/company/12417574>,
LEI 875500FXNCJPAPF3PD10. ICO register №: ZA782876
<https://ico.org.uk/ESDWebPages/Entry/ZA782876>. UK VAT №: GB378323867. EU
VAT №: EU372013983. Turkish VAT №: 0861333524. South Korean VAT №:
522-80-03080. AS207960 Ewrop OÜ, having a registered office at Lääne-Viru
maakond, Tapa vald, Porkuni küla, Lossi tn 1, 46001, trading as Glauca
Digital, is a company registered in Estonia under № 16755226. Estonian VAT
№: EE102625532. Glauca Digital and the Glauca logo are registered
trademarks in the UK, under № UK3718474 and № UK3718468,
respectively.


On Wed, 12 Jul 2023 at 19:34, Paul van Brouwershaven <
paul.vanbrouwersha...@entrust.com> wrote:

> I have to agree that 0 is not a positive integer and reverted the prior
> change:
>
> *> In the case that this parameter is not specified or contains the value
> "0", the entry will be considered to have a lower priority than all entries
> which specify any priority.*
>
> So, setting "0" would invalidate the parameter, causing the ACME client to
> ignore the CAA record all together.
>
> Does this also make sense to you Q?
>
> --
> *From:* Tim Hollebeek 
> *Sent:* Wednesday, July 12, 2023 19:32
> *To:* Paul van Brouwershaven ; Q
> Misell 
> *Cc:* acme@ietf.org 
> *Subject:* RE: [Acme] FW: [EXTERNAL] New Version Notification for
> draft-vanbrouwershaven-acme-auto-discovery-00.txt
>
>
> If priority is defined as a positive integer (which makes sense to me),
> then zero is an error, yes.
>
>
>
> If it’s desirable to have a “no priority” value, then zero might be a
> reasonable choice for such a value.  But it’s hard to reason about whether
> “no priority” is higher or lower than items that do have priorities, so I
> think “no priority” adds additional complexity that should not be added
> unnecessarily.  I think it’s simpler to stick to a single, ordered list of
> priority numbers, and ordinal numbers (a.k.a positive integers) are the
> best way to express that.
>
>
>
> -Tim
>
>
>
> *From:* Paul van Brouwershaven  40entrust@dmarc.ietf.org>
> *Sent:* Wednesday, July 12, 2023 1:01 PM
> *To:* Tim Hollebeek ; Q Misell  >
> *Cc:* acme@ietf.org
> *Subject:* Re: [Acme] FW: [EXTERNAL] New Version Notification for
> draft-vanbrouwershaven-acme-auto-discovery-00.txt
>
>
>
> > Anyone who argues that zero is a positive integer should be referred to
> the standard math textbook of positive.  Zero is a non-negative integer,
> but I’m not aware of any definition of “positive” that makes it a positive
> integer.
>
>
>
> Do you argue that "0" should be threatened as an error instead of equal to
> no priority?
>
>
> ------
>
> *From:* Tim Hollebeek 
> *Sent:* Wednesday, July 12, 2023 6:43:21 PM
> *To:* Paul van Brouwershaven ; Q
> Misell 
> *Cc:* acme@ietf.org 
> *Subject:* RE: [Acme] FW: [EXTERNAL] New Version Notification for
> draft-vanbrouwershaven-acme-auto-discovery-00.txt
>
>
>
> Anyone who argues that zero is a positive integer should be referred to
> the standard math textbook of positive.  Zero is a non-negative integer,
> but I’m not aware of any definition of “positive” that makes it a positive
> integer.
>
>
>
> Also, ignoring failures in CAA records is probably not the right answer.
> CAA should fail closed, not open.
>
>
>
> -Tim
>
>
>
> *From:* Acme  *On Behalf Of *Paul van Brouwershaven
> *Sent:* Wednesday, July 12, 2023 9:52 AM
> *To:* Q Misell 
> *Cc:* acme@ietf.org
> *Subject:* Re: [Acme] FW: [EXTERNAL] New Version Notification for
> draft-vanbrouwershaven-acme-auto-discovery-00.txt
>
>
>
> Hi Q,
>
>
>
> Thanks, this is great and really helpful!
>
> Is priority=0 an error coditition, some might argue 0 is a positive
> integer?
>
> Any suggestion? maybe we should simply start counting at 0 instead of 1
>
> What about discovery=foobar?
>
> "foobar" is not a Boolean, the text is clear that this parameter MUST be
> a Boolean, so this should invalidate the parameter.
>
> Should the client ignore invalid issue records and process the rest, or
> fail outright?
>
> We should ignore 

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

[Paul van Brouwershaven]

I have to agree that 0 is not a positive integer and reverted the prior change:

> In the case that this parameter is not specified or contains the value "0", 
> the entry will be considered to have a lower priority than all entries which 
> specify any priority.

So, setting "0" would invalidate the parameter, causing the ACME client to 
ignore the CAA record all together.

Does this also make sense to you Q?


From: Tim Hollebeek 
Sent: Wednesday, July 12, 2023 19:32
To: Paul van Brouwershaven ; Q Misell 

Cc: acme@ietf.org 
Subject: RE: [Acme] FW: [EXTERNAL] New Version Notification for 
draft-vanbrouwershaven-acme-auto-discovery-00.txt


If priority is defined as a positive integer (which makes sense to me), then 
zero is an error, yes.



If it’s desirable to have a “no priority” value, then zero might be a 
reasonable choice for such a value.  But it’s hard to reason about whether “no 
priority” is higher or lower than items that do have priorities, so I think “no 
priority” adds additional complexity that should not be added unnecessarily.  I 
think it’s simpler to stick to a single, ordered list of priority numbers, and 
ordinal numbers (a.k.a positive integers) are the best way to express that.



-Tim



From: Paul van Brouwershaven 

Sent: Wednesday, July 12, 2023 1:01 PM
To: Tim Hollebeek ; Q Misell 
Cc: acme@ietf.org
Subject: Re: [Acme] FW: [EXTERNAL] New Version Notification for 
draft-vanbrouwershaven-acme-auto-discovery-00.txt



> Anyone who argues that zero is a positive integer should be referred to the 
> standard math textbook of positive.  Zero is a non-negative integer, but I’m 
> not aware of any definition of “positive” that makes it a positive integer.



Do you argue that "0" should be threatened as an error instead of equal to no 
priority?





From: Tim Hollebeek 
mailto:tim.hollebeek=40digicert@dmarc.ietf.org>>
Sent: Wednesday, July 12, 2023 6:43:21 PM
To: Paul van Brouwershaven 
mailto:paul.vanbrouwersha...@entrust.com>>; 
Q Misell mailto:q...@as207960.net>>
Cc: acme@ietf.org<mailto:acme@ietf.org> mailto:acme@ietf.org>>
Subject: RE: [Acme] FW: [EXTERNAL] New Version Notification for 
draft-vanbrouwershaven-acme-auto-discovery-00.txt



Anyone who argues that zero is a positive integer should be referred to the 
standard math textbook of positive.  Zero is a non-negative integer, but I’m 
not aware of any definition of “positive” that makes it a positive integer.



Also, ignoring failures in CAA records is probably not the right answer.  CAA 
should fail closed, not open.



-Tim



From: Acme mailto:acme-boun...@ietf.org>> On Behalf Of 
Paul van Brouwershaven
Sent: Wednesday, July 12, 2023 9:52 AM
To: Q Misell mailto:q...@as207960.net>>
Cc: acme@ietf.org<mailto:acme@ietf.org>
Subject: Re: [Acme] FW: [EXTERNAL] New Version Notification for 
draft-vanbrouwershaven-acme-auto-discovery-00.txt



Hi Q,



Thanks, this is great and really helpful!

Is priority=0 an error coditition, some might argue 0 is a positive integer?

Any suggestion? maybe we should simply start counting at 0 instead of 1

What about discovery=foobar?

"foobar" is not a Boolean, the text is clear that this parameter MUST be a 
Boolean, so this should invalidate the parameter.

Should the client ignore invalid issue records and process the rest, or fail 
outright?

We should ignore the failure of a single CAA record and continue with the next, 
similar to when the client encounters ACME errors.



I will clarify this with the following change:



The ACME client analyzes the CAA records - > The ACME client analyzes the valid 
CAA records



It looks like you implemented discovery as a pre-condition while 3.1.1 
specifies:



When this parameter is not specified the client MUST assume that discovery is 
enabled.



There is however a comment in the examples that this behavior might need to 
change if deemed necessary.



Paul







From: Q Misell mailto:q...@as207960.net>>
Sent: Wednesday, July 12, 2023 15:06
To: Paul van Brouwershaven 
mailto:paul.vanbrouwersha...@entrust.com>>
Cc: acme@ietf.org<mailto:acme@ietf.org> mailto:acme@ietf.org>>
Subject: Re: [Acme] FW: [EXTERNAL] New Version Notification for 
draft-vanbrouwershaven-acme-auto-discovery-00.txt



Hi all,



I happened to be poking around the certbot codebase today and decided to try 
and implement this draft.

It turned out to be a much simpler task than I had expected, however I felt the 
draft was a bit lacking in details for what the ACME client should consider an 
error.



For example:

  *   Is priority=0 an error coditition, some might argue 0 is a positive 
integer?
  *   What about discovery=foobar?
  *   Should the client ignore invalid issue records and process the rest, or 
fail outright?

My fork of certb

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

[Paul van Brouwershaven]

>> - In 5.1, what does 3.b mean? Can you add an example?
> I will try to add an example here.

Does this example help to clarify the intend of 3.b?
https://vanbroup.github.io/acme-auto-discovery/draft-vanbrouwershaven-acme-auto-discovery.html#name-selecting-a-common-ca-throu

The other changes have also been incorporated.


From: Paul van Brouwershaven 
Sent: Wednesday, July 12, 2023 18:16
To: Carl Wallace ; Mike Ounsworth 
; acme@ietf.org 
Subject: Re: [Acme] FW: [EXTERNAL] New Version Notification for 
draft-vanbrouwershaven-acme-auto-discovery-00.txt

Thanks for your detailed review!
- Why is the draft informational and not standards track?
Most people I spoke to, while discussing the idea, thought that it would need 
to be information, but if people here feel that this needs to be changed to 
standards track, I'm fine with that too. I'm relatively new to the drafting 
process.
- Why does absence turn the feature on? Wouldn't this invite sending spurious 
requests for ACME information to CAs configured before this draft existed that 
do not support ACME?
The reason is that with the move to shorter live certificates, automation will 
become essential. If we default to off, we will likely only see CAA records 
with this option enabled.

The benefit of these spurious requests is that it would give a clear signal to 
these CAs that they might need to adopt ACME and/or auto discovery, something 
that is also pushed by the root programs.

If an account binding is required (which is the case for most commercial CAs) 
the user will be asked to establish this binding, but no certificates will be 
issued until the account binding is established. When no account binding is 
required, the certificate will automatically be replaced by the authorized CA.

See also the security considerations in section 8.1.
- Is a boolean the right type for discovery or should it be a string that 
indicates the protocol that is the target of auto-discovery?
The protocol is already indicated by the property (i.e., issue, issuewild, vmc, 
issuemail, etc.)
- Do/ought parent domains apply (as they do in CAA)? If not, it might be worth 
a few words since the usage here is different.
Yes they do, section 5 states "The ACME client initiates a DNS lookup to 
retrieve the CAA record(s) according to [RFC8659]", which specifies how CAA 
lookups need to be performed.
- In the next to last example in 3.2, why does EV without priority go first?
It should not, we updated the logic later, I will get this corrected by 
including a priority here as well.
- In 5.1, you might want to replace the long paragraph with bullets.
This is fixed on 
GitHub<https://vanbroup.github.io/acme-auto-discovery/draft-vanbrouwershaven-acme-auto-discovery.html>
 and will be included in the next release.
- In 5.1, what does 3.b mean? Can you add an example?
I will try to add an example here.
- You should expand QWAC on first use and maybe add an informational reference.
Yes, I will add the meaning of the abbreviations and maybe a reference there.

Thanks,

Paul


From: Carl Wallace 
Sent: Wednesday, July 12, 2023 17:48
To: Mike Ounsworth ; acme@ietf.org 

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

This looks like a useful addition. Here are a few comments and questions:

- Why is the draft informational and not standards track?

- Why does absence turn the feature on? Wouldn't this invite sending spurious 
requests for ACME information to CAs configured before this draft existed that 
do not support ACME?

- Is a boolean the right type for discovery or should it be a string that 
indicates the protocol that is the target of auto-discovery?

- Do/ought parent domains apply (as they do in CAA)? If not, it might be worth 
a few words since the usage here is different.

- In the next to last example in 3.2, why does EV without priority go first?

- In 5.1, you might want to replace the long paragraph with bullets.

- In 5.1, what does 3.b mean? Can you add an example?

- You should expand QWAC on first use and maybe add an informational reference.


On 7/6/23, 10:54 AM, "Acme on behalf of Mike Ounsworth" mailto:acme-boun...@ietf.org> on behalf of 
Mike.Ounsworth=40entrust@dmarc.ietf.org 
<mailto: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 <mailto:internet-dra...@ietf.org> 
mailto:internet-dra...@ietf.org>>
Sent: Thursday, July 6, 2023 9:39 AM
To: Mike Ounsworth mailto:mike.ounswo...@entrust.com>>; Paul van Brouwershaven 
mailto:paul.vanbrouwersha...@entrust.com>>
Subject: [EXTERNAL] New Version Notification for 
draft-vanbrouw

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

[Tim Hollebeek]

If priority is defined as a positive integer (which makes sense to me), then 
zero is an error, yes.

If it’s desirable to have a “no priority” value, then zero might be a 
reasonable choice for such a value.  But it’s hard to reason about whether “no 
priority” is higher or lower than items that do have priorities, so I think “no 
priority” adds additional complexity that should not be added unnecessarily.  I 
think it’s simpler to stick to a single, ordered list of priority numbers, and 
ordinal numbers (a.k.a positive integers) are the best way to express that.

-Tim

From: Paul van Brouwershaven 

Sent: Wednesday, July 12, 2023 1:01 PM
To: Tim Hollebeek ; Q Misell 
Cc: acme@ietf.org
Subject: Re: [Acme] FW: [EXTERNAL] New Version Notification for 
draft-vanbrouwershaven-acme-auto-discovery-00.txt

> Anyone who argues that zero is a positive integer should be referred to the 
> standard math textbook of positive.  Zero is a non-negative integer, but I’m 
> not aware of any definition of “positive” that makes it a positive integer.

Do you argue that "0" should be threatened as an error instead of equal to no 
priority?


From: Tim Hollebeek 
mailto:tim.hollebeek=40digicert@dmarc.ietf.org>>
Sent: Wednesday, July 12, 2023 6:43:21 PM
To: Paul van Brouwershaven 
mailto:paul.vanbrouwersha...@entrust.com>>; 
Q Misell mailto:q...@as207960.net>>
Cc: acme@ietf.org<mailto:acme@ietf.org> mailto:acme@ietf.org>>
Subject: RE: [Acme] FW: [EXTERNAL] New Version Notification for 
draft-vanbrouwershaven-acme-auto-discovery-00.txt


Anyone who argues that zero is a positive integer should be referred to the 
standard math textbook of positive.  Zero is a non-negative integer, but I’m 
not aware of any definition of “positive” that makes it a positive integer.



Also, ignoring failures in CAA records is probably not the right answer.  CAA 
should fail closed, not open.



-Tim



From: Acme mailto:acme-boun...@ietf.org>> On Behalf Of 
Paul van Brouwershaven
Sent: Wednesday, July 12, 2023 9:52 AM
To: Q Misell mailto:q...@as207960.net>>
Cc: acme@ietf.org<mailto:acme@ietf.org>
Subject: Re: [Acme] FW: [EXTERNAL] New Version Notification for 
draft-vanbrouwershaven-acme-auto-discovery-00.txt



Hi Q,



Thanks, this is great and really helpful!

Is priority=0 an error coditition, some might argue 0 is a positive integer?

Any suggestion? maybe we should simply start counting at 0 instead of 1

What about discovery=foobar?

"foobar" is not a Boolean, the text is clear that this parameter MUST be a 
Boolean, so this should invalidate the parameter.

Should the client ignore invalid issue records and process the rest, or fail 
outright?

We should ignore the failure of a single CAA record and continue with the next, 
similar to when the client encounters ACME errors.



I will clarify this with the following change:



The ACME client analyzes the CAA records - > The ACME client analyzes the valid 
CAA records



It looks like you implemented discovery as a pre-condition while 3.1.1 
specifies:



When this parameter is not specified the client MUST assume that discovery is 
enabled.



There is however a comment in the examples that this behavior might need to 
change if deemed necessary.



Paul







From: Q Misell mailto:q...@as207960.net>>
Sent: Wednesday, July 12, 2023 15:06
To: Paul van Brouwershaven 
mailto:paul.vanbrouwersha...@entrust.com>>
Cc: acme@ietf.org<mailto:acme@ietf.org> mailto:acme@ietf.org>>
Subject: Re: [Acme] FW: [EXTERNAL] New Version Notification for 
draft-vanbrouwershaven-acme-auto-discovery-00.txt



Hi all,



I happened to be poking around the certbot codebase today and decided to try 
and implement this draft.

It turned out to be a much simpler task than I had expected, however I felt the 
draft was a bit lacking in details for what the ACME client should consider an 
error.



For example:

  *   Is priority=0 an error coditition, some might argue 0 is a positive 
integer?
  *   What about discovery=foobar?
  *   Should the client ignore invalid issue records and process the rest, or 
fail outright?

My fork of certbot with the implementation is available at 
https://github.com/as207960/certbot/tree/auto-discovery<https://urldefense.com/v3/__https:/github.com/as207960/certbot/tree/auto-discovery__;!!FJ-Y8qCqXTj2!cZZsOZ0v5-kwi0u2XFbPWT2ddKQUeoKDOKjmTA0uStA0dZuwoAFoA5bphSBDyICkcF08SK8ddsv-a3_g84d3UvJ3$>.



Thanks,

Q



Any statements contained in this email are personal to the author and are not 
necessarily the statements of the company unless specifically stated. AS207960 
Cyfyngedig, having a registered office at 13 Pen-y-lan Terrace, Caerdydd, 
Cymru, CF23 9EU, trading as Glauca Digital, is a company registered in Wales 
under № 
12417574<https://urldefen

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

[Q Misell]

> For a backup mechanism to work, you don't want to fail if one of your 3
records contains an error.

I agree with Paul on this point.
--

Any statements contained in this email are personal to the author and are
not necessarily the statements of the company unless specifically stated.
AS207960 Cyfyngedig, having a registered office at 13 Pen-y-lan Terrace,
Caerdydd, Cymru, CF23 9EU, trading as Glauca Digital, is a company
registered in Wales under № 12417574
<https://find-and-update.company-information.service.gov.uk/company/12417574>,
LEI 875500FXNCJPAPF3PD10. ICO register №: ZA782876
<https://ico.org.uk/ESDWebPages/Entry/ZA782876>. UK VAT №: GB378323867. EU
VAT №: EU372013983. Turkish VAT №: 0861333524. South Korean VAT №:
522-80-03080. AS207960 Ewrop OÜ, having a registered office at Lääne-Viru
maakond, Tapa vald, Porkuni küla, Lossi tn 1, 46001, trading as Glauca
Digital, is a company registered in Estonia under № 16755226. Estonian VAT
№: EE102625532. Glauca Digital and the Glauca logo are registered
trademarks in the UK, under № UK3718474 and № UK3718468,
respectively.


On Wed, 12 Jul 2023 at 17:58, Paul van Brouwershaven <
paul.vanbrouwersha...@entrust.com> wrote:

>
> *Tim Hollebeek* Wednesday, 12 July, 18:43
> Also, ignoring failures in CAA records is probably not the right answer.
> CAA should fail closed, not open.
>
> For a backup mechanism to work, you don't want to fail if one of your 3
> records contains an error. You want to ignore that record only and use the
> valid ones.
>
>
>
> --
> *From:* Tim Hollebeek 
> *Sent:* Wednesday, July 12, 2023 6:43:21 PM
> *To:* Paul van Brouwershaven ; Q
> Misell 
> *Cc:* acme@ietf.org 
> *Subject:* RE: [Acme] FW: [EXTERNAL] New Version Notification for
> draft-vanbrouwershaven-acme-auto-discovery-00.txt
>
>
> Anyone who argues that zero is a positive integer should be referred to
> the standard math textbook of positive.  Zero is a non-negative integer,
> but I’m not aware of any definition of “positive” that makes it a positive
> integer.
>
>
>
> Also, ignoring failures in CAA records is probably not the right answer.
> CAA should fail closed, not open.
>
>
>
> -Tim
>
>
>
> *From:* Acme  *On Behalf Of * Paul van
> Brouwershaven
> *Sent:* Wednesday, July 12, 2023 9:52 AM
> *To:* Q Misell 
> *Cc:* acme@ietf.org
> *Subject:* Re: [Acme] FW: [EXTERNAL] New Version Notification for
> draft-vanbrouwershaven-acme-auto-discovery-00.txt
>
>
>
> Hi Q,
>
>
>
> Thanks, this is great and really helpful!
>
> Is priority=0 an error coditition, some might argue 0 is a positive
> integer?
>
> Any suggestion? maybe we should simply start counting at 0 instead of 1
>
> What about discovery=foobar?
>
> "foobar" is not a Boolean, the text is clear that this parameter MUST be
> a Boolean, so this should invalidate the parameter.
>
> Should the client ignore invalid issue records and process the rest, or
> fail outright?
>
> We should ignore the failure of a single CAA record and continue with the
> next, similar to when the client encounters ACME errors.
>
>
>
> I will clarify this with the following change:
>
>
>
> *The ACME client analyzes the CAA records - > The ACME client analyzes the
> valid CAA records *
>
>
>
> It looks like you implemented discovery as a pre-condition while 3.1.1
> specifies:
>
>
>
> *When this parameter is not specified the client MUST assume that
> discovery is enabled.*
>
>
>
> There is however a comment in the examples that this behavior might need
> to change if deemed necessary.
>
>
>
> Paul
>
>
>
>
> --
>
> *From:* Q Misell 
> *Sent:* Wednesday, July 12, 2023 15:06
> *To:* Paul van Brouwershaven 
> *Cc:* acme@ietf.org 
> *Subject:* Re: [Acme] FW: [EXTERNAL] New Version Notification for
> draft-vanbrouwershaven-acme-auto-discovery-00.txt
>
>
>
> Hi all,
>
>
>
> I happened to be poking around the certbot codebase today and decided to
> try and implement this draft.
>
> It turned out to be a much simpler task than I had expected, however I
> felt the draft was a bit lacking in details for what the ACME client should
> consider an error.
>
>
>
> For example:
>
>- Is priority=0 an error coditition, some might argue 0 is a positive
>integer?
>- What about discovery=foobar?
>- Should the client ignore invalid issue records and process the rest,
>or fail outright?
>
> My fork of certbot with the implementation is available at
> https://github.com/as207960/certbot/tree/auto-discovery
> <https:/

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

[Paul van Brouwershaven]

> Anyone who argues that zero is a positive integer should be referred to the 
> standard math textbook of positive.  Zero is a non-negative integer, but I’m 
> not aware of any definition of “positive” that makes it a positive integer.

Do you argue that "0" should be threatened as an error instead of equal to no 
priority?


From: Tim Hollebeek 
Sent: Wednesday, July 12, 2023 6:43:21 PM
To: Paul van Brouwershaven ; Q Misell 

Cc: acme@ietf.org 
Subject: RE: [Acme] FW: [EXTERNAL] New Version Notification for 
draft-vanbrouwershaven-acme-auto-discovery-00.txt


Anyone who argues that zero is a positive integer should be referred to the 
standard math textbook of positive.  Zero is a non-negative integer, but I’m 
not aware of any definition of “positive” that makes it a positive integer.



Also, ignoring failures in CAA records is probably not the right answer.  CAA 
should fail closed, not open.



-Tim



From: Acme  On Behalf Of Paul van Brouwershaven
Sent: Wednesday, July 12, 2023 9:52 AM
To: Q Misell 
Cc: acme@ietf.org
Subject: Re: [Acme] FW: [EXTERNAL] New Version Notification for 
draft-vanbrouwershaven-acme-auto-discovery-00.txt



Hi Q,



Thanks, this is great and really helpful!

Is priority=0 an error coditition, some might argue 0 is a positive integer?

Any suggestion? maybe we should simply start counting at 0 instead of 1

What about discovery=foobar?

"foobar" is not a Boolean, the text is clear that this parameter MUST be a 
Boolean, so this should invalidate the parameter.

Should the client ignore invalid issue records and process the rest, or fail 
outright?

We should ignore the failure of a single CAA record and continue with the next, 
similar to when the client encounters ACME errors.



I will clarify this with the following change:



The ACME client analyzes the CAA records - > The ACME client analyzes the valid 
CAA records



It looks like you implemented discovery as a pre-condition while 3.1.1 
specifies:



When this parameter is not specified the client MUST assume that discovery is 
enabled.



There is however a comment in the examples that this behavior might need to 
change if deemed necessary.



Paul







From: Q Misell mailto:q...@as207960.net>>
Sent: Wednesday, July 12, 2023 15:06
To: Paul van Brouwershaven 
mailto:paul.vanbrouwersha...@entrust.com>>
Cc: acme@ietf.org<mailto:acme@ietf.org> mailto:acme@ietf.org>>
Subject: Re: [Acme] FW: [EXTERNAL] New Version Notification for 
draft-vanbrouwershaven-acme-auto-discovery-00.txt



Hi all,



I happened to be poking around the certbot codebase today and decided to try 
and implement this draft.

It turned out to be a much simpler task than I had expected, however I felt the 
draft was a bit lacking in details for what the ACME client should consider an 
error.



For example:

  *   Is priority=0 an error coditition, some might argue 0 is a positive 
integer?
  *   What about discovery=foobar?
  *   Should the client ignore invalid issue records and process the rest, or 
fail outright?

My fork of certbot with the implementation is available at 
https://github.com/as207960/certbot/tree/auto-discovery<https://urldefense.com/v3/__https:/github.com/as207960/certbot/tree/auto-discovery__;!!FJ-Y8qCqXTj2!cZZsOZ0v5-kwi0u2XFbPWT2ddKQUeoKDOKjmTA0uStA0dZuwoAFoA5bphSBDyICkcF08SK8ddsv-a3_g84d3UvJ3$>.



Thanks,

Q



Any statements contained in this email are personal to the author and are not 
necessarily the statements of the company unless specifically stated. AS207960 
Cyfyngedig, having a registered office at 13 Pen-y-lan Terrace, Caerdydd, 
Cymru, CF23 9EU, trading as Glauca Digital, is a company registered in Wales 
under № 
12417574<https://urldefense.com/v3/__https:/find-and-update.company-information.service.gov.uk/company/12417574__;!!FJ-Y8qCqXTj2!cZZsOZ0v5-kwi0u2XFbPWT2ddKQUeoKDOKjmTA0uStA0dZuwoAFoA5bphSBDyICkcF08SK8ddsv-a3_g8-o0EXCj$>,
 LEI 875500FXNCJPAPF3PD10. ICO register №: 
ZA782876<https://urldefense.com/v3/__https:/ico.org.uk/ESDWebPages/Entry/ZA782876__;!!FJ-Y8qCqXTj2!cZZsOZ0v5-kwi0u2XFbPWT2ddKQUeoKDOKjmTA0uStA0dZuwoAFoA5bphSBDyICkcF08SK8ddsv-a3_g86EYmrmH$>.
 UK VAT №: GB378323867. EU VAT №: EU372013983. Turkish VAT №: 0861333524. South 
Korean VAT №: 522-80-03080. AS207960 Ewrop OÜ, having a registered office at 
Lääne-Viru maakond, Tapa vald, Porkuni küla, Lossi tn 1, 46001, trading as 
Glauca Digital, is a company registered in Estonia under № 16755226. Estonian 
VAT №: EE102625532. Glauca Digital and the Glauca logo are registered 
trademarks in the UK, under № UK3718474 and № UK3718468, respectively.





On Fri, 7 Jul 2023 at 14:32, Salz, Rich 
mailto:40akamai@dmarc.ietf.org>> wrote:



  *   how about ratelimit? for large hosting they will hit CA's default API 
ratelimit fast



The HTTPAP

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

[Tim Hollebeek]

That’s a fair point and one we’re going to have to work through.  I suspect 
failure handling will need some subtle analysis.  It did for some of the other 
CAA record types.

-Tim

From: Paul van Brouwershaven 

Sent: Wednesday, July 12, 2023 12:59 PM
To: Tim Hollebeek ; Q Misell 
Cc: acme@ietf.org
Subject: Re: [Acme] FW: [EXTERNAL] New Version Notification for 
draft-vanbrouwershaven-acme-auto-discovery-00.txt


Tim Hollebeek Wednesday, 12 July, 18:43
Also, ignoring failures in CAA records is probably not the right answer.  CAA 
should fail closed, not open.
For a backup mechanism to work, you don't want to fail if one of your 3 records 
contains an error. You want to ignore that record only and use the valid ones.




From: Tim Hollebeek 
mailto:tim.hollebeek=40digicert@dmarc.ietf.org>>
Sent: Wednesday, July 12, 2023 6:43:21 PM
To: Paul van Brouwershaven 
mailto:paul.vanbrouwersha...@entrust.com>>; 
Q Misell mailto:q...@as207960.net>>
Cc: acme@ietf.org<mailto:acme@ietf.org> mailto:acme@ietf.org>>
Subject: RE: [Acme] FW: [EXTERNAL] New Version Notification for 
draft-vanbrouwershaven-acme-auto-discovery-00.txt


Anyone who argues that zero is a positive integer should be referred to the 
standard math textbook of positive.  Zero is a non-negative integer, but I’m 
not aware of any definition of “positive” that makes it a positive integer.



Also, ignoring failures in CAA records is probably not the right answer.  CAA 
should fail closed, not open.



-Tim



From: Acme mailto:acme-boun...@ietf.org>> On Behalf Of 
Paul van Brouwershaven
Sent: Wednesday, July 12, 2023 9:52 AM
To: Q Misell mailto:q...@as207960.net>>
Cc: acme@ietf.org<mailto:acme@ietf.org>
Subject: Re: [Acme] FW: [EXTERNAL] New Version Notification for 
draft-vanbrouwershaven-acme-auto-discovery-00.txt



Hi Q,



Thanks, this is great and really helpful!

Is priority=0 an error coditition, some might argue 0 is a positive integer?

Any suggestion? maybe we should simply start counting at 0 instead of 1

What about discovery=foobar?

"foobar" is not a Boolean, the text is clear that this parameter MUST be a 
Boolean, so this should invalidate the parameter.

Should the client ignore invalid issue records and process the rest, or fail 
outright?

We should ignore the failure of a single CAA record and continue with the next, 
similar to when the client encounters ACME errors.



I will clarify this with the following change:



The ACME client analyzes the CAA records - > The ACME client analyzes the valid 
CAA records



It looks like you implemented discovery as a pre-condition while 3.1.1 
specifies:



When this parameter is not specified the client MUST assume that discovery is 
enabled.



There is however a comment in the examples that this behavior might need to 
change if deemed necessary.



Paul







From: Q Misell mailto:q...@as207960.net>>
Sent: Wednesday, July 12, 2023 15:06
To: Paul van Brouwershaven 
mailto:paul.vanbrouwersha...@entrust.com>>
Cc: acme@ietf.org<mailto:acme@ietf.org> mailto:acme@ietf.org>>
Subject: Re: [Acme] FW: [EXTERNAL] New Version Notification for 
draft-vanbrouwershaven-acme-auto-discovery-00.txt



Hi all,



I happened to be poking around the certbot codebase today and decided to try 
and implement this draft.

It turned out to be a much simpler task than I had expected, however I felt the 
draft was a bit lacking in details for what the ACME client should consider an 
error.



For example:

  *   Is priority=0 an error coditition, some might argue 0 is a positive 
integer?
  *   What about discovery=foobar?
  *   Should the client ignore invalid issue records and process the rest, or 
fail outright?

My fork of certbot with the implementation is available at 
https://github.com/as207960/certbot/tree/auto-discovery<https://urldefense.com/v3/__https:/github.com/as207960/certbot/tree/auto-discovery__;!!FJ-Y8qCqXTj2!cZZsOZ0v5-kwi0u2XFbPWT2ddKQUeoKDOKjmTA0uStA0dZuwoAFoA5bphSBDyICkcF08SK8ddsv-a3_g84d3UvJ3$>.



Thanks,

Q



Any statements contained in this email are personal to the author and are not 
necessarily the statements of the company unless specifically stated. AS207960 
Cyfyngedig, having a registered office at 13 Pen-y-lan Terrace, Caerdydd, 
Cymru, CF23 9EU, trading as Glauca Digital, is a company registered in Wales 
under № 
12417574<https://urldefense.com/v3/__https:/find-and-update.company-information.service.gov.uk/company/12417574__;!!FJ-Y8qCqXTj2!cZZsOZ0v5-kwi0u2XFbPWT2ddKQUeoKDOKjmTA0uStA0dZuwoAFoA5bphSBDyICkcF08SK8ddsv-a3_g8-o0EXCj$>,
 LEI 875500FXNCJPAPF3PD10. ICO register №: 
ZA782876<https://urldefense.com/v3/__https:/ico.org.uk/ESDWebPages/Entry/ZA782876__;!!FJ-Y8qCqXTj2!cZZsOZ0v5-kwi0u2XFbPWT2ddKQUeoKDOKjmTA0uStA0dZuwoAFoA5bphSBDyICkcF08SK8ddsv-a3_g86EYmrmH$>.
 UK VAT №

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

[Amir Omidi]

CAA failing closed would hurt https rather than help it though. How many
people wouldn’t realize they need that configured to get an https
certificate and just give up?

On Wed, Jul 12, 2023 at 12:43 Tim Hollebeek  wrote:

> Anyone who argues that zero is a positive integer should be referred to
> the standard math textbook of positive.  Zero is a non-negative integer,
> but I’m not aware of any definition of “positive” that makes it a positive
> integer.
>
>
>
> Also, ignoring failures in CAA records is probably not the right answer.
> CAA should fail closed, not open.
>
>
>
> -Tim
>
>
>
> *From:* Acme  *On Behalf Of * Paul van
> Brouwershaven
> *Sent:* Wednesday, July 12, 2023 9:52 AM
> *To:* Q Misell 
> *Cc:* acme@ietf.org
> *Subject:* Re: [Acme] FW: [EXTERNAL] New Version Notification for
> draft-vanbrouwershaven-acme-auto-discovery-00.txt
>
>
>
> Hi Q,
>
>
>
> Thanks, this is great and really helpful!
>
> Is priority=0 an error coditition, some might argue 0 is a positive
> integer?
>
> Any suggestion? maybe we should simply start counting at 0 instead of 1
>
> What about discovery=foobar?
>
> "foobar" is not a Boolean, the text is clear that this parameter MUST be
> a Boolean, so this should invalidate the parameter.
>
> Should the client ignore invalid issue records and process the rest, or
> fail outright?
>
> We should ignore the failure of a single CAA record and continue with the
> next, similar to when the client encounters ACME errors.
>
>
>
> I will clarify this with the following change:
>
>
>
> *The ACME client analyzes the CAA records - > The ACME client analyzes the
> valid CAA records *
>
>
>
> It looks like you implemented discovery as a pre-condition while 3.1.1
> specifies:
>
>
>
> *When this parameter is not specified the client MUST assume that
> discovery is enabled.*
>
>
>
> There is however a comment in the examples that this behavior might need
> to change if deemed necessary.
>
>
>
> Paul
>
>
>
>
> ----------
>
> *From:* Q Misell 
> *Sent:* Wednesday, July 12, 2023 15:06
> *To:* Paul van Brouwershaven 
> *Cc:* acme@ietf.org 
> *Subject:* Re: [Acme] FW: [EXTERNAL] New Version Notification for
> draft-vanbrouwershaven-acme-auto-discovery-00.txt
>
>
>
> Hi all,
>
>
>
> I happened to be poking around the certbot codebase today and decided to
> try and implement this draft.
>
> It turned out to be a much simpler task than I had expected, however I
> felt the draft was a bit lacking in details for what the ACME client should
> consider an error.
>
>
>
> For example:
>
>- Is priority=0 an error coditition, some might argue 0 is a positive
>integer?
>- What about discovery=foobar?
>- Should the client ignore invalid issue records and process the rest,
>or fail outright?
>
> My fork of certbot with the implementation is available at
> https://github.com/as207960/certbot/tree/auto-discovery
> <https://urldefense.com/v3/__https:/github.com/as207960/certbot/tree/auto-discovery__;!!FJ-Y8qCqXTj2!cZZsOZ0v5-kwi0u2XFbPWT2ddKQUeoKDOKjmTA0uStA0dZuwoAFoA5bphSBDyICkcF08SK8ddsv-a3_g84d3UvJ3$>
> .
>
>
>
> Thanks,
>
> Q
> --
>
> Any statements contained in this email are personal to the author and are
> not necessarily the statements of the company unless specifically stated.
> AS207960 Cyfyngedig, having a registered office at 13 Pen-y-lan Terrace,
> Caerdydd, Cymru, CF23 9EU
> <https://www.google.com/maps/search/13+Pen-y-lan%0D%0A+Terrace,+Caerdydd,+Cymru,+CF23+9EU?entry=gmail&source=g>,
> trading as Glauca Digital, is a company registered in Wales under №
> 12417574
> <https://urldefense.com/v3/__https:/find-and-update.company-information.service.gov.uk/company/12417574__;!!FJ-Y8qCqXTj2!cZZsOZ0v5-kwi0u2XFbPWT2ddKQUeoKDOKjmTA0uStA0dZuwoAFoA5bphSBDyICkcF08SK8ddsv-a3_g8-o0EXCj$>,
> LEI 875500FXNCJPAPF3PD10. ICO register №: ZA782876
> <https://urldefense.com/v3/__https:/ico.org.uk/ESDWebPages/Entry/ZA782876__;!!FJ-Y8qCqXTj2!cZZsOZ0v5-kwi0u2XFbPWT2ddKQUeoKDOKjmTA0uStA0dZuwoAFoA5bphSBDyICkcF08SK8ddsv-a3_g86EYmrmH$>.
> UK VAT №: GB378323867. EU VAT №: EU372013983. Turkish VAT №: 0861333524.
> South Korean VAT №: 522-80-03080. AS207960 Ewrop OÜ, having a registered
> office at Lääne-Viru maakond, Tapa vald, Porkuni küla, Lossi tn 1, 46001,
> trading as Glauca Digital, is a company registered in Estonia under №
> 16755226. Estonian VAT №: EE102625532. Glauca Digital and the Glauca logo
> are registered trademarks in the UK, under № UK3718474 and №
> UK3718468, respectively.
>

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

[Paul van Brouwershaven]

Tim Hollebeek Wednesday, 12 July, 18:43
Also, ignoring failures in CAA records is probably not the right answer.  CAA 
should fail closed, not open.
For a backup mechanism to work, you don't want to fail if one of your 3 records 
contains an error. You want to ignore that record only and use the valid ones.




From: Tim Hollebeek 
Sent: Wednesday, July 12, 2023 6:43:21 PM
To: Paul van Brouwershaven ; Q Misell 

Cc: acme@ietf.org 
Subject: RE: [Acme] FW: [EXTERNAL] New Version Notification for 
draft-vanbrouwershaven-acme-auto-discovery-00.txt


Anyone who argues that zero is a positive integer should be referred to the 
standard math textbook of positive.  Zero is a non-negative integer, but I’m 
not aware of any definition of “positive” that makes it a positive integer.



Also, ignoring failures in CAA records is probably not the right answer.  CAA 
should fail closed, not open.



-Tim



From: Acme  On Behalf Of Paul van Brouwershaven
Sent: Wednesday, July 12, 2023 9:52 AM
To: Q Misell 
Cc: acme@ietf.org
Subject: Re: [Acme] FW: [EXTERNAL] New Version Notification for 
draft-vanbrouwershaven-acme-auto-discovery-00.txt



Hi Q,



Thanks, this is great and really helpful!

Is priority=0 an error coditition, some might argue 0 is a positive integer?

Any suggestion? maybe we should simply start counting at 0 instead of 1

What about discovery=foobar?

"foobar" is not a Boolean, the text is clear that this parameter MUST be a 
Boolean, so this should invalidate the parameter.

Should the client ignore invalid issue records and process the rest, or fail 
outright?

We should ignore the failure of a single CAA record and continue with the next, 
similar to when the client encounters ACME errors.



I will clarify this with the following change:



The ACME client analyzes the CAA records - > The ACME client analyzes the valid 
CAA records



It looks like you implemented discovery as a pre-condition while 3.1.1 
specifies:



When this parameter is not specified the client MUST assume that discovery is 
enabled.



There is however a comment in the examples that this behavior might need to 
change if deemed necessary.



Paul







From: Q Misell mailto:q...@as207960.net>>
Sent: Wednesday, July 12, 2023 15:06
To: Paul van Brouwershaven 
mailto:paul.vanbrouwersha...@entrust.com>>
Cc: acme@ietf.org<mailto:acme@ietf.org> mailto:acme@ietf.org>>
Subject: Re: [Acme] FW: [EXTERNAL] New Version Notification for 
draft-vanbrouwershaven-acme-auto-discovery-00.txt



Hi all,



I happened to be poking around the certbot codebase today and decided to try 
and implement this draft.

It turned out to be a much simpler task than I had expected, however I felt the 
draft was a bit lacking in details for what the ACME client should consider an 
error.



For example:

  *   Is priority=0 an error coditition, some might argue 0 is a positive 
integer?
  *   What about discovery=foobar?
  *   Should the client ignore invalid issue records and process the rest, or 
fail outright?

My fork of certbot with the implementation is available at 
https://github.com/as207960/certbot/tree/auto-discovery<https://urldefense.com/v3/__https:/github.com/as207960/certbot/tree/auto-discovery__;!!FJ-Y8qCqXTj2!cZZsOZ0v5-kwi0u2XFbPWT2ddKQUeoKDOKjmTA0uStA0dZuwoAFoA5bphSBDyICkcF08SK8ddsv-a3_g84d3UvJ3$>.



Thanks,

Q



Any statements contained in this email are personal to the author and are not 
necessarily the statements of the company unless specifically stated. AS207960 
Cyfyngedig, having a registered office at 13 Pen-y-lan Terrace, Caerdydd, 
Cymru, CF23 9EU, trading as Glauca Digital, is a company registered in Wales 
under № 
12417574<https://urldefense.com/v3/__https:/find-and-update.company-information.service.gov.uk/company/12417574__;!!FJ-Y8qCqXTj2!cZZsOZ0v5-kwi0u2XFbPWT2ddKQUeoKDOKjmTA0uStA0dZuwoAFoA5bphSBDyICkcF08SK8ddsv-a3_g8-o0EXCj$>,
 LEI 875500FXNCJPAPF3PD10. ICO register №: 
ZA782876<https://urldefense.com/v3/__https:/ico.org.uk/ESDWebPages/Entry/ZA782876__;!!FJ-Y8qCqXTj2!cZZsOZ0v5-kwi0u2XFbPWT2ddKQUeoKDOKjmTA0uStA0dZuwoAFoA5bphSBDyICkcF08SK8ddsv-a3_g86EYmrmH$>.
 UK VAT №: GB378323867. EU VAT №: EU372013983. Turkish VAT №: 0861333524. South 
Korean VAT №: 522-80-03080. AS207960 Ewrop OÜ, having a registered office at 
Lääne-Viru maakond, Tapa vald, Porkuni küla, Lossi tn 1, 46001, trading as 
Glauca Digital, is a company registered in Estonia under № 16755226. Estonian 
VAT №: EE102625532. Glauca Digital and the Glauca logo are registered 
trademarks in the UK, under № UK3718474 and № UK3718468, respectively.





On Fri, 7 Jul 2023 at 14:32, Salz, Rich 
mailto:40akamai@dmarc.ietf.org>> wrote:



  *   how about ratelimit? for large hosting they will hit CA's default API 
ratelimit fast



The HTTPAPI working group is working on standard

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

[Tim Hollebeek]

Anyone who argues that zero is a positive integer should be referred to the 
standard math textbook of positive.  Zero is a non-negative integer, but I’m 
not aware of any definition of “positive” that makes it a positive integer.

Also, ignoring failures in CAA records is probably not the right answer.  CAA 
should fail closed, not open.

-Tim

From: Acme  On Behalf Of Paul van Brouwershaven
Sent: Wednesday, July 12, 2023 9:52 AM
To: Q Misell 
Cc: acme@ietf.org
Subject: Re: [Acme] FW: [EXTERNAL] New Version Notification for 
draft-vanbrouwershaven-acme-auto-discovery-00.txt

Hi Q,

Thanks, this is great and really helpful!
Is priority=0 an error coditition, some might argue 0 is a positive integer?
Any suggestion? maybe we should simply start counting at 0 instead of 1
What about discovery=foobar?
"foobar" is not a Boolean, the text is clear that this parameter MUST be a 
Boolean, so this should invalidate the parameter.
Should the client ignore invalid issue records and process the rest, or fail 
outright?
We should ignore the failure of a single CAA record and continue with the next, 
similar to when the client encounters ACME errors.

I will clarify this with the following change:

The ACME client analyzes the CAA records - > The ACME client analyzes the valid 
CAA records

It looks like you implemented discovery as a pre-condition while 3.1.1 
specifies:

When this parameter is not specified the client MUST assume that discovery is 
enabled.

There is however a comment in the examples that this behavior might need to 
change if deemed necessary.

Paul



From: Q Misell mailto:q...@as207960.net>>
Sent: Wednesday, July 12, 2023 15:06
To: Paul van Brouwershaven 
mailto:paul.vanbrouwersha...@entrust.com>>
Cc: acme@ietf.org<mailto:acme@ietf.org> mailto:acme@ietf.org>>
Subject: Re: [Acme] FW: [EXTERNAL] New Version Notification for 
draft-vanbrouwershaven-acme-auto-discovery-00.txt

Hi all,

I happened to be poking around the certbot codebase today and decided to try 
and implement this draft.
It turned out to be a much simpler task than I had expected, however I felt the 
draft was a bit lacking in details for what the ACME client should consider an 
error.

For example:

  *   Is priority=0 an error coditition, some might argue 0 is a positive 
integer?
  *   What about discovery=foobar?
  *   Should the client ignore invalid issue records and process the rest, or 
fail outright?
My fork of certbot with the implementation is available at 
https://github.com/as207960/certbot/tree/auto-discovery<https://urldefense.com/v3/__https:/github.com/as207960/certbot/tree/auto-discovery__;!!FJ-Y8qCqXTj2!cZZsOZ0v5-kwi0u2XFbPWT2ddKQUeoKDOKjmTA0uStA0dZuwoAFoA5bphSBDyICkcF08SK8ddsv-a3_g84d3UvJ3$>.

Thanks,
Q


Any statements contained in this email are personal to the author and are not 
necessarily the statements of the company unless specifically stated. AS207960 
Cyfyngedig, having a registered office at 13 Pen-y-lan Terrace, Caerdydd, 
Cymru, CF23 9EU, trading as Glauca Digital, is a company registered in Wales 
under № 
12417574<https://urldefense.com/v3/__https:/find-and-update.company-information.service.gov.uk/company/12417574__;!!FJ-Y8qCqXTj2!cZZsOZ0v5-kwi0u2XFbPWT2ddKQUeoKDOKjmTA0uStA0dZuwoAFoA5bphSBDyICkcF08SK8ddsv-a3_g8-o0EXCj$>,
 LEI 875500FXNCJPAPF3PD10. ICO register №: 
ZA782876<https://urldefense.com/v3/__https:/ico.org.uk/ESDWebPages/Entry/ZA782876__;!!FJ-Y8qCqXTj2!cZZsOZ0v5-kwi0u2XFbPWT2ddKQUeoKDOKjmTA0uStA0dZuwoAFoA5bphSBDyICkcF08SK8ddsv-a3_g86EYmrmH$>.
 UK VAT №: GB378323867. EU VAT №: EU372013983. Turkish VAT №: 0861333524. South 
Korean VAT №: 522-80-03080. AS207960 Ewrop OÜ, having a registered office at 
Lääne-Viru maakond, Tapa vald, Porkuni küla, Lossi tn 1, 46001, trading as 
Glauca Digital, is a company registered in Estonia under № 16755226. Estonian 
VAT №: EE102625532. Glauca Digital and the Glauca logo are registered 
trademarks in the UK, under № UK3718474 and № UK3718468, respectively.


On Fri, 7 Jul 2023 at 14:32, Salz, Rich 
mailto:40akamai@dmarc.ietf.org>> wrote:



  *   how about ratelimit? for large hosting they will hit CA's default API 
ratelimit fast



The HTTPAPI working group is working on standard HTTP headers for specifying 
rate limits.  See


https://datatracker.ietf.org/doc/draft-ietf-httpapi-ratelimit-headers/<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/draft-ietf-httpapi-ratelimit-headers/__;!!FJ-Y8qCqXTj2!cZZsOZ0v5-kwi0u2XFbPWT2ddKQUeoKDOKjmTA0uStA0dZuwoAFoA5bphSBDyICkcF08SK8ddsv-a3_g81_OWtQS$>
___
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!cZZsOZ0v5-kwi0u2XFbPWT2ddKQUeoKDOKjmTA0uStA0dZuwoAFoA5bphS

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

[Carl Wallace]

- Do/ought parent domains apply (as they do in CAA)? If not, it might be worth 
a few words since the usage here is different.

Yes they do, section 5 states "The ACME client initiates a DNS lookup to 
retrieve the CAA record(s) according to [RFC8659]", which specifies how CAA 
lookups need to be performed.

 

[CW] Thanks. Geez, I missed that despite looking explicitly for it. I think 
this makes the spurious request tendency worse, but maybe you’re right that 
pelting a CA with such requests is a clue. Thanks for the quick reply.





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

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

[Paul van Brouwershaven]

Thanks for your detailed review!
- Why is the draft informational and not standards track?
Most people I spoke to, while discussing the idea, thought that it would need 
to be information, but if people here feel that this needs to be changed to 
standards track, I'm fine with that too. I'm relatively new to the drafting 
process.
- Why does absence turn the feature on? Wouldn't this invite sending spurious 
requests for ACME information to CAs configured before this draft existed that 
do not support ACME?
The reason is that with the move to shorter live certificates, automation will 
become essential. If we default to off, we will likely only see CAA records 
with this option enabled.

The benefit of these spurious requests is that it would give a clear signal to 
these CAs that they might need to adopt ACME and/or auto discovery, something 
that is also pushed by the root programs.

If an account binding is required (which is the case for most commercial CAs) 
the user will be asked to establish this binding, but no certificates will be 
issued until the account binding is established. When no account binding is 
required, the certificate will automatically be replaced by the authorized CA.

See also the security considerations in section 8.1.
- Is a boolean the right type for discovery or should it be a string that 
indicates the protocol that is the target of auto-discovery?
The protocol is already indicated by the property (i.e., issue, issuewild, vmc, 
issuemail, etc.)
- Do/ought parent domains apply (as they do in CAA)? If not, it might be worth 
a few words since the usage here is different.
Yes they do, section 5 states "The ACME client initiates a DNS lookup to 
retrieve the CAA record(s) according to [RFC8659]", which specifies how CAA 
lookups need to be performed.
- In the next to last example in 3.2, why does EV without priority go first?
It should not, we updated the logic later, I will get this corrected by 
including a priority here as well.
- In 5.1, you might want to replace the long paragraph with bullets.
This is fixed on 
GitHub<https://vanbroup.github.io/acme-auto-discovery/draft-vanbrouwershaven-acme-auto-discovery.html>
 and will be included in the next release.
- In 5.1, what does 3.b mean? Can you add an example?
I will try to add an example here.
- You should expand QWAC on first use and maybe add an informational reference.
Yes, I will add the meaning of the abbreviations and maybe a reference there.

Thanks,

Paul


From: Carl Wallace 
Sent: Wednesday, July 12, 2023 17:48
To: Mike Ounsworth ; acme@ietf.org 

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

This looks like a useful addition. Here are a few comments and questions:

- Why is the draft informational and not standards track?

- Why does absence turn the feature on? Wouldn't this invite sending spurious 
requests for ACME information to CAs configured before this draft existed that 
do not support ACME?

- Is a boolean the right type for discovery or should it be a string that 
indicates the protocol that is the target of auto-discovery?

- Do/ought parent domains apply (as they do in CAA)? If not, it might be worth 
a few words since the usage here is different.

- In the next to last example in 3.2, why does EV without priority go first?

- In 5.1, you might want to replace the long paragraph with bullets.

- In 5.1, what does 3.b mean? Can you add an example?

- You should expand QWAC on first use and maybe add an informational reference.


On 7/6/23, 10:54 AM, "Acme on behalf of Mike Ounsworth" mailto:acme-boun...@ietf.org> on behalf of 
Mike.Ounsworth=40entrust@dmarc.ietf.org 
<mailto: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 <mailto:internet-dra...@ietf.org> 
mailto:internet-dra...@ietf.org>>
Sent: Thursday, July 6, 2023 9:39 AM
To: Mike Ounsworth mailto:mike.ounswo...@entrust.com>>; Paul van Brouwershaven 
mailto: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 Submis

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

[Paul van Brouwershaven]

I think priority=0 should be the same as specifying no priority at all. That is 
priority defaults to 0 unless otherwise specified.
That makes sense to me, I have included this in section 3.1.2:

In the case that this parameter is not specified or contains the value "0", the 
entry will be considered to have a lower priority than all entries which 
specify any priority.

I will update my implementation to do this. I would also suggest the wording:
"The ACME client analyzes the valid CAA records, ignoring any it cannot process"
Thanks for the suggestion, I updated the sections 5 (2) and 5.1 (3) accordingly.

I appreciate my code may not be the clearest, being quickly thrown together, 
but the following lines get the value of the discovery parameter, defaulting to 
"true" if not set.

if rr.get_property(b"discovery", b"true") != b"true":
continue

My fault 🙂

One final suggestion I've thought of is defining an 'Auto Discovery Critical' 
flag, that a client must be able to understand all parameters before proceeding 
with using this record, in case breaking parameters are added in future.
Humm, what if we change the discovery parameter so that instead of a Boolean 
that it can be "enabled", "disabled", "strict" or something? I just don't like 
to overload CAA with even more parameters.

I have incorporated these updates in the GitHub repository but have not 
released a new version for the datatracker yet.
https://vanbroup.github.io/acme-auto-discovery/draft-vanbrouwershaven-acme-auto-discovery.html



From: Q Misell 
Sent: Wednesday, July 12, 2023 16:20
To: Paul van Brouwershaven 
Cc: acme@ietf.org 
Subject: Re: [Acme] FW: [EXTERNAL] New Version Notification for 
draft-vanbrouwershaven-acme-auto-discovery-00.txt

Hi Paul,

Thanks for the feedback.

> Any suggestion? maybe we should simply start counting at 0 instead of 1.

I think priority=0 should be the same as specifying no priority at all. That is 
priority defaults to 0 unless otherwise specified.

> We should ignore the failure of a single CAA record and continue with the 
> next, similar to when the client encounters ACME errors.

I will update my implementation to do this. I would also suggest the wording:
"The ACME client analyzes the valid CAA records, ignoring any it cannot process"

> It looks like you implemented discovery as a pre-condition while 3.1.1 
> specifies

I appreciate my code may not be the clearest, being quickly thrown together, 
but the following lines get the value of the discovery parameter, defaulting to 
"true" if not set.

if rr.get_property(b"discovery", b"true") != b"true":
continue

One final suggestion I've thought of is defining an 'Auto Discovery Critical' 
flag, that a client must be able to understand all parameters before proceeding 
with using this record, in case breaking parameters are added in future.

Thanks,
Q


Any statements contained in this email are personal to the author and are not 
necessarily the statements of the company unless specifically stated. AS207960 
Cyfyngedig, having a registered office at 13 Pen-y-lan Terrace, Caerdydd, 
Cymru, CF23 9EU, trading as Glauca Digital, is a company registered in Wales 
under № 
12417574<https://urldefense.com/v3/__https://find-and-update.company-information.service.gov.uk/company/12417574__;!!FJ-Y8qCqXTj2!bkz4yiPB5OaEdcjmDJrINOJYsFlzGYRXaZkeiSeAMzecRVPWEC-yYfxfDU26QoqWUTfw8phfj00VbfS38AOCURWx$>,
 LEI 875500FXNCJPAPF3PD10. ICO register №: 
ZA782876<https://urldefense.com/v3/__https://ico.org.uk/ESDWebPages/Entry/ZA782876__;!!FJ-Y8qCqXTj2!bkz4yiPB5OaEdcjmDJrINOJYsFlzGYRXaZkeiSeAMzecRVPWEC-yYfxfDU26QoqWUTfw8phfj00VbfS38NrZTO-K$>.
 UK VAT №: GB378323867. EU VAT №: EU372013983. Turkish VAT №: 0861333524. South 
Korean VAT №: 522-80-03080. AS207960 Ewrop OÜ, having a registered office at 
Lääne-Viru maakond, Tapa vald, Porkuni küla, Lossi tn 1, 46001, trading as 
Glauca Digital, is a company registered in Estonia under № 16755226. Estonian 
VAT №: EE102625532. Glauca Digital and the Glauca logo are registered 
trademarks in the UK, under № UK3718474 and № UK3718468, respectively.


On Wed, 12 Jul 2023 at 14:52, Paul van Brouwershaven 
mailto:paul.vanbrouwersha...@entrust.com>> 
wrote:
Hi Q,

Thanks, this is great and really helpful!
Is priority=0 an error coditition, some might argue 0 is a positive integer?
Any suggestion? maybe we should simply start counting at 0 instead of 1
What about discovery=foobar?
"foobar" is not a Boolean, the text is clear that this parameter MUST be a 
Boolean, so this should invalidate the parameter.
Should the client ignore invalid issue records and process the rest, or fail 
outright?
We should ignore the failure of a single CAA record and

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

[Carl Wallace]

This looks like a useful addition. Here are a few comments and questions:

- Why is the draft informational and not standards track?

- Why does absence turn the feature on? Wouldn't this invite sending spurious 
requests for ACME information to CAs configured before this draft existed that 
do not support ACME? 

- Is a boolean the right type for discovery or should it be a string that 
indicates the protocol that is the target of auto-discovery?

- Do/ought parent domains apply (as they do in CAA)? If not, it might be worth 
a few words since the usage here is different.

- In the next to last example in 3.2, why does EV without priority go first?

- In 5.1, you might want to replace the long paragraph with bullets. 

- In 5.1, what does 3.b mean? Can you add an example?

- You should expand QWAC on first use and maybe add an informational reference. 


On 7/6/23, 10:54 AM, "Acme on behalf of Mike Ounsworth" mailto:acme-boun...@ietf.org> on behalf of 
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  
mailto:internet-dra...@ietf.org>>
Sent: Thursday, July 6, 2023 9:39 AM
To: Mike Ounsworth mailto:mike.ounswo...@entrust.com>>; Paul van Brouwershaven 
mailto: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

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

[Q Misell]

Hi Paul,

Thanks for the feedback.

> Any suggestion? maybe we should simply start counting at 0 instead of 1.

I think priority=0 should be the same as specifying no priority at all.
That is priority defaults to 0 unless otherwise specified.

> We should ignore the failure of a single CAA record and continue with the
next, similar to when the client encounters ACME errors.

I will update my implementation to do this. I would also suggest the
wording:
"The ACME client analyzes the valid CAA records, ignoring any it cannot
process"

> It looks like you implemented discovery as a pre-condition while 3.1.1
specifies

I appreciate my code may not be the clearest, being quickly thrown
together, but the following lines get the value of the discovery parameter,
defaulting to "true" if not set.

if rr.get_property(b"discovery", b"true") != b"true":
continue

One final suggestion I've thought of is defining an 'Auto Discovery
Critical' flag, that a client must be able to understand all parameters
before proceeding with using this record, in case breaking parameters are
added in future.

Thanks,
Q
--

Any statements contained in this email are personal to the author and are
not necessarily the statements of the company unless specifically stated.
AS207960 Cyfyngedig, having a registered office at 13 Pen-y-lan Terrace,
Caerdydd, Cymru, CF23 9EU, trading as Glauca Digital, is a company
registered in Wales under № 12417574
<https://find-and-update.company-information.service.gov.uk/company/12417574>,
LEI 875500FXNCJPAPF3PD10. ICO register №: ZA782876
<https://ico.org.uk/ESDWebPages/Entry/ZA782876>. UK VAT №: GB378323867. EU
VAT №: EU372013983. Turkish VAT №: 0861333524. South Korean VAT №:
522-80-03080. AS207960 Ewrop OÜ, having a registered office at Lääne-Viru
maakond, Tapa vald, Porkuni küla, Lossi tn 1, 46001, trading as Glauca
Digital, is a company registered in Estonia under № 16755226. Estonian VAT
№: EE102625532. Glauca Digital and the Glauca logo are registered
trademarks in the UK, under № UK3718474 and № UK3718468,
respectively.


On Wed, 12 Jul 2023 at 14:52, Paul van Brouwershaven <
paul.vanbrouwersha...@entrust.com> wrote:

> Hi Q,
>
> Thanks, this is great and really helpful!
>
> Is priority=0 an error coditition, some might argue 0 is a positive
> integer?
>
> Any suggestion? maybe we should simply start counting at 0 instead of 1
>
> What about discovery=foobar?
>
> "foobar" is not a Boolean, the text is clear that this parameter MUST be
> a Boolean, so this should invalidate the parameter.
>
> Should the client ignore invalid issue records and process the rest, or
> fail outright?
>
> We should ignore the failure of a single CAA record and continue with the
> next, similar to when the client encounters ACME errors.
>
> I will clarify this with the following change:
>
> *The ACME client analyzes the CAA records - > The ACME client analyzes the
> valid CAA records *
>
>
> It looks like you implemented discovery as a pre-condition while 3.1.1
> specifies:
>
> *When this parameter is not specified the client MUST assume that
> discovery is enabled.*
>
>
> There is however a comment in the examples that this behavior might need
> to change if deemed necessary.
>
> Paul
>
>
> ------
> *From:* Q Misell 
> *Sent:* Wednesday, July 12, 2023 15:06
> *To:* Paul van Brouwershaven 
> *Cc:* acme@ietf.org 
> *Subject:* Re: [Acme] FW: [EXTERNAL] New Version Notification for
> draft-vanbrouwershaven-acme-auto-discovery-00.txt
>
> Hi all,
>
> I happened to be poking around the certbot codebase today and decided to
> try and implement this draft.
> It turned out to be a much simpler task than I had expected, however I
> felt the draft was a bit lacking in details for what the ACME client should
> consider an error.
>
> For example:
>
>- Is priority=0 an error coditition, some might argue 0 is a positive
>integer?
>- What about discovery=foobar?
>- Should the client ignore invalid issue records and process the rest,
>or fail outright?
>
> My fork of certbot with the implementation is available at
> https://github.com/as207960/certbot/tree/auto-discovery
> <https://urldefense.com/v3/__https://github.com/as207960/certbot/tree/auto-discovery__;!!FJ-Y8qCqXTj2!cZZsOZ0v5-kwi0u2XFbPWT2ddKQUeoKDOKjmTA0uStA0dZuwoAFoA5bphSBDyICkcF08SK8ddsv-a3_g84d3UvJ3$>
> .
>
> Thanks,
> Q
> --
>
> Any statements contained in this email are personal to the author and are
> not necessarily the statements of the company unless specifically stated.
> AS207960 Cyfyngedig, having a registered office at 13 Pen

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

[Paul van Brouwershaven]

Hi Q,

Thanks, this is great and really helpful!
Is priority=0 an error coditition, some might argue 0 is a positive integer?
Any suggestion? maybe we should simply start counting at 0 instead of 1
What about discovery=foobar?
"foobar" is not a Boolean, the text is clear that this parameter MUST be a 
Boolean, so this should invalidate the parameter.
Should the client ignore invalid issue records and process the rest, or fail 
outright?
We should ignore the failure of a single CAA record and continue with the next, 
similar to when the client encounters ACME errors.

I will clarify this with the following change:

The ACME client analyzes the CAA records - > The ACME client analyzes the valid 
CAA records

It looks like you implemented discovery as a pre-condition while 3.1.1 
specifies:

When this parameter is not specified the client MUST assume that discovery is 
enabled.

There is however a comment in the examples that this behavior might need to 
change if deemed necessary.

Paul



From: Q Misell 
Sent: Wednesday, July 12, 2023 15:06
To: Paul van Brouwershaven 
Cc: acme@ietf.org 
Subject: Re: [Acme] FW: [EXTERNAL] New Version Notification for 
draft-vanbrouwershaven-acme-auto-discovery-00.txt

Hi all,

I happened to be poking around the certbot codebase today and decided to try 
and implement this draft.
It turned out to be a much simpler task than I had expected, however I felt the 
draft was a bit lacking in details for what the ACME client should consider an 
error.

For example:

  *   Is priority=0 an error coditition, some might argue 0 is a positive 
integer?
  *   What about discovery=foobar?
  *   Should the client ignore invalid issue records and process the rest, or 
fail outright?

My fork of certbot with the implementation is available at 
https://github.com/as207960/certbot/tree/auto-discovery<https://urldefense.com/v3/__https://github.com/as207960/certbot/tree/auto-discovery__;!!FJ-Y8qCqXTj2!cZZsOZ0v5-kwi0u2XFbPWT2ddKQUeoKDOKjmTA0uStA0dZuwoAFoA5bphSBDyICkcF08SK8ddsv-a3_g84d3UvJ3$>.

Thanks,
Q


Any statements contained in this email are personal to the author and are not 
necessarily the statements of the company unless specifically stated. AS207960 
Cyfyngedig, having a registered office at 13 Pen-y-lan Terrace, Caerdydd, 
Cymru, CF23 9EU, trading as Glauca Digital, is a company registered in Wales 
under № 
12417574<https://urldefense.com/v3/__https://find-and-update.company-information.service.gov.uk/company/12417574__;!!FJ-Y8qCqXTj2!cZZsOZ0v5-kwi0u2XFbPWT2ddKQUeoKDOKjmTA0uStA0dZuwoAFoA5bphSBDyICkcF08SK8ddsv-a3_g8-o0EXCj$>,
 LEI 875500FXNCJPAPF3PD10. ICO register №: 
ZA782876<https://urldefense.com/v3/__https://ico.org.uk/ESDWebPages/Entry/ZA782876__;!!FJ-Y8qCqXTj2!cZZsOZ0v5-kwi0u2XFbPWT2ddKQUeoKDOKjmTA0uStA0dZuwoAFoA5bphSBDyICkcF08SK8ddsv-a3_g86EYmrmH$>.
 UK VAT №: GB378323867. EU VAT №: EU372013983. Turkish VAT №: 0861333524. South 
Korean VAT №: 522-80-03080. AS207960 Ewrop OÜ, having a registered office at 
Lääne-Viru maakond, Tapa vald, Porkuni küla, Lossi tn 1, 46001, trading as 
Glauca Digital, is a company registered in Estonia under № 16755226. Estonian 
VAT №: EE102625532. Glauca Digital and the Glauca logo are registered 
trademarks in the UK, under № UK3718474 and № UK3718468, respectively.


On Fri, 7 Jul 2023 at 14:32, Salz, Rich 
mailto:40akamai@dmarc.ietf.org>> wrote:



  *   how about ratelimit? for large hosting they will hit CA's default API 
ratelimit fast



The HTTPAPI working group is working on standard HTTP headers for specifying 
rate limits.  See


https://datatracker.ietf.org/doc/draft-ietf-httpapi-ratelimit-headers/<https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-ietf-httpapi-ratelimit-headers/__;!!FJ-Y8qCqXTj2!cZZsOZ0v5-kwi0u2XFbPWT2ddKQUeoKDOKjmTA0uStA0dZuwoAFoA5bphSBDyICkcF08SK8ddsv-a3_g81_OWtQS$>

___
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!cZZsOZ0v5-kwi0u2XFbPWT2ddKQUeoKDOKjmTA0uStA0dZuwoAFoA5bphSBDyICkcF08SK8ddsv-a3_g8yXgZATe$>
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

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

[Salz, Rich]

I happened to be poking around the certbot codebase today and decided to try 
and implement this draft.
It turned out to be a much simpler task than I had expected, however I felt the 
draft was a bit lacking in details for what the ACME client should consider an 
error.

That is great!  And the things you found are exactly why implementations are 
very useful.
___
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme

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

[Q Misell]

Hi all,

I happened to be poking around the certbot codebase today and decided to
try and implement this draft.
It turned out to be a much simpler task than I had expected, however I felt
the draft was a bit lacking in details for what the ACME client should
consider an error.

For example:

   - Is priority=0 an error coditition, some might argue 0 is a positive
   integer?
   - What about discovery=foobar?
   - Should the client ignore invalid issue records and process the rest,
   or fail outright?

My fork of certbot with the implementation is available at
https://github.com/as207960/certbot/tree/auto-discovery.

Thanks,
Q
--

Any statements contained in this email are personal to the author and are
not necessarily the statements of the company unless specifically stated.
AS207960 Cyfyngedig, having a registered office at 13 Pen-y-lan Terrace,
Caerdydd, Cymru, CF23 9EU, trading as Glauca Digital, is a company
registered in Wales under № 12417574
,
LEI 875500FXNCJPAPF3PD10. ICO register №: ZA782876
. UK VAT №: GB378323867. EU
VAT №: EU372013983. Turkish VAT №: 0861333524. South Korean VAT №:
522-80-03080. AS207960 Ewrop OÜ, having a registered office at Lääne-Viru
maakond, Tapa vald, Porkuni küla, Lossi tn 1, 46001, trading as Glauca
Digital, is a company registered in Estonia under № 16755226. Estonian VAT
№: EE102625532. Glauca Digital and the Glauca logo are registered
trademarks in the UK, under № UK3718474 and № UK3718468,
respectively.


On Fri, 7 Jul 2023 at 14:32, Salz, Rich 
wrote:

>
>
>- how about ratelimit? for large hosting they will hit CA's default
>API ratelimit fast
>
>
>
> The HTTPAPI working group is working on standard HTTP headers for
> specifying rate limits.  See
>
>
> https://datatracker.ietf.org/doc/draft-ietf-httpapi-ratelimit-headers/
> ___
> 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

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

[Salz, Rich]

  *   how about ratelimit? for large hosting they will hit CA's default API 
ratelimit fast

The HTTPAPI working group is working on standard HTTP headers for specifying 
rate limits.  See

https://datatracker.ietf.org/doc/draft-ietf-httpapi-ratelimit-headers/
___
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme

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

[Paul van Brouwershaven]

Hi Q,

You are correct, to facilitate account binding it's important that each 
customer is using its own ACME key.

I will create an issue to spell this out more clearly in the document.

Paul


From: Q Misell 
Sent: Friday, July 7, 2023 10:50:04 AM
To: Paul van Brouwershaven 
Cc: acme@ietf.org 
Subject: Re: [Acme] FW: [EXTERNAL] New Version Notification for 
draft-vanbrouwershaven-acme-auto-discovery-00.txt

Hi,

Reading the draft I think it is the author's intention (correct me if wrong) 
that each customer of a hosting provider would have a new ACME account created 
for them, and for the contact details on the ACME account to be that of the 
customer, not the hosting provider.

I know it is common with hosting providers at the present time to have one ACME 
account for all customers, and for the contact details to be that of the 
hosting provider. Might it be worth spelling out in the I-D the author's 
intentions about who is the holder of the account. This would also help clarify 
who is actually agreeing to the CA ToS.

Thanks,
Q


Any statements contained in this email are personal to the author and are not 
necessarily the statements of the company unless specifically stated. AS207960 
Cyfyngedig, having a registered office at 13 Pen-y-lan Terrace, Caerdydd, 
Cymru, CF23 9EU, trading as Glauca Digital, is a company registered in Wales 
under № 
12417574<https://urldefense.com/v3/__https://find-and-update.company-information.service.gov.uk/company/12417574__;!!FJ-Y8qCqXTj2!c7XYcqfuEqSdOdkjQ0F2h1p8h_jBL5-aD8KCIDGefelG2Ug4epJsYVUuNkPdJ81OO-sYR_6f8adUvZCApdYEAbi1LdzfL9owygcfPGBKLQ$>,
 LEI 875500FXNCJPAPF3PD10. ICO register №: 
ZA782876<https://urldefense.com/v3/__https://ico.org.uk/ESDWebPages/Entry/ZA782876__;!!FJ-Y8qCqXTj2!c7XYcqfuEqSdOdkjQ0F2h1p8h_jBL5-aD8KCIDGefelG2Ug4epJsYVUuNkPdJ81OO-sYR_6f8adUvZCApdYEAbi1LdzfL9owygfUo261AA$>.
 UK VAT №: GB378323867. EU VAT №: EU372013983. Turkish VAT №: 0861333524. South 
Korean VAT №: 522-80-03080. AS207960 Ewrop OÜ, having a registered office at 
Lääne-Viru maakond, Tapa vald, Porkuni küla, Lossi tn 1, 46001, trading as 
Glauca Digital, is a company registered in Estonia under № 16755226. Estonian 
VAT №: EE102625532. Glauca Digital and the Glauca logo are registered 
trademarks in the UK, under № UK3718474 and № UK3718468, respectively.


On Fri, 7 Jul 2023 at 09:23, Paul van Brouwershaven 
mailto:40entrust@dmarc.ietf.org>>
 wrote:
Adding, that I agree that it would be great if service providers would all 
provide an option to configure ACME clients with a custom server and account 
binding, but I do not see how this would solve the problem of rate limiting.


From: Paul van Brouwershaven 
mailto:paul.vanbrouwersha...@entrust.com>>
Sent: Friday, July 7, 2023 10:16:55 AM
To: Seo Suchan mailto:tjtn...@gmail.com>>; 
acme@ietf.org<mailto:acme@ietf.org> mailto:acme@ietf.org>>
Subject: Re: [Acme] FW: [EXTERNAL] New Version Notification for 
draft-vanbrouwershaven-acme-auto-discovery-00.txt

I expect that rate limiting is main the problem for a CA that is configured as 
default. If there would be thousands of users setting the same CAA records this 
CA would need to identify that the rate limit is hit and adjust accordingly if 
these requests seem to be legit.

This would be less of a problem for a commercial CA who would be bound by 
service level agreements and can identify the customers through the account 
binding so apply a rate limit per customer instead of per IP address/block.

Paul

From: Seo Suchan mailto:tjtn...@gmail.com>>
Sent: Friday, July 7, 2023 10:07:27 AM
To: Paul van Brouwershaven 
mailto:paul.vanbrouwersha...@entrust.com>>; 
acme@ietf.org<mailto:acme@ietf.org> mailto:acme@ietf.org>>
Subject: Re: [Acme] FW: [EXTERNAL] New Version Notification for 
draft-vanbrouwershaven-acme-auto-discovery-00.txt


how about ratelimit? for large hosting they will hit CA's default API ratelimit 
fast, so they contract with a specific CA for ratelimit increase. feels like 
entire automatic CA loadbearing doesn't work without hosting provider having 
eab/acme account from domain holder: if it already have menu for upload such 
that menu could have a box for acme directory Uri too.



2023-07-07 오후 4:54에 Paul van Brouwershaven 이(가) 쓴 글:
Hi Seo,
a. ) CAs may want to put list of acme endpoints at well-known, for
example one each for DV/OV/EV like sectigo did with 
https://acme.sectigo.com/v2/EV<https://urldefense.com/v3/__https://acme.sectigo.com/v2/EV__;!!FJ-Y8qCqXTj2!fOwwhASnPzBhTF0h_VK_hIwZsD3TU3aktKzTejf2fcZQY8dC5SasEv0izXw6vrG49jAHmrONh9Hn2QpK64AdFctM2w$>
This could be solved by setting a CAA record to for example 
"ev.sectigo.com<https://urldefense.com/v3/__http://ev.sectigo.com__;!!FJ-Y8qCqXTj2!c7XYcqfuEqSdOdkjQ0F2h1p8

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

[Q Misell]

Hi,

Reading the draft I think it is the author's intention (correct me if
wrong) that each customer of a hosting provider would have a new ACME
account created for them, and for the contact details on the ACME account
to be that of the customer, not the hosting provider.

I know it is common with hosting providers at the present time to have one
ACME account for all customers, and for the contact details to be that of
the hosting provider. Might it be worth spelling out in the I-D the
author's intentions about who is the holder of the account. This would also
help clarify who is actually agreeing to the CA ToS.

Thanks,
Q
--

Any statements contained in this email are personal to the author and are
not necessarily the statements of the company unless specifically stated.
AS207960 Cyfyngedig, having a registered office at 13 Pen-y-lan Terrace,
Caerdydd, Cymru, CF23 9EU, trading as Glauca Digital, is a company
registered in Wales under № 12417574
<https://find-and-update.company-information.service.gov.uk/company/12417574>,
LEI 875500FXNCJPAPF3PD10. ICO register №: ZA782876
<https://ico.org.uk/ESDWebPages/Entry/ZA782876>. UK VAT №: GB378323867. EU
VAT №: EU372013983. Turkish VAT №: 0861333524. South Korean VAT №:
522-80-03080. AS207960 Ewrop OÜ, having a registered office at Lääne-Viru
maakond, Tapa vald, Porkuni küla, Lossi tn 1, 46001, trading as Glauca
Digital, is a company registered in Estonia under № 16755226. Estonian VAT
№: EE102625532. Glauca Digital and the Glauca logo are registered
trademarks in the UK, under № UK3718474 and № UK3718468,
respectively.


On Fri, 7 Jul 2023 at 09:23, Paul van Brouwershaven  wrote:

> Adding, that I agree that it would be great if service providers would all
> provide an option to configure ACME clients with a custom server and
> account binding, but I do not see how this would solve the problem of rate
> limiting.
>
> --
> *From:* Paul van Brouwershaven 
> *Sent:* Friday, July 7, 2023 10:16:55 AM
> *To:* Seo Suchan ; acme@ietf.org 
> *Subject:* Re: [Acme] FW: [EXTERNAL] New Version Notification for
> draft-vanbrouwershaven-acme-auto-discovery-00.txt
>
> I expect that rate limiting is main the problem for a CA that is
> configured as default. If there would be thousands of users setting the
> same CAA records this CA would need to identify that the rate limit is hit
> and adjust accordingly if these requests seem to be legit.
>
> This would be less of a problem for a commercial CA who would be bound by
> service level agreements and can identify the customers through the account
> binding so apply a rate limit per customer instead of per IP address/block.
>
> Paul
> --
> *From:* Seo Suchan 
> *Sent:* Friday, July 7, 2023 10:07:27 AM
> *To:* Paul van Brouwershaven ;
> acme@ietf.org 
> *Subject:* Re: [Acme] FW: [EXTERNAL] New Version Notification for
> draft-vanbrouwershaven-acme-auto-discovery-00.txt
>
>
> how about ratelimit? for large hosting they will hit CA's default API
> ratelimit fast, so they contract with a specific CA for ratelimit increase.
> feels like entire automatic CA loadbearing doesn't work without hosting
> provider having eab/acme account from domain holder: if it already have
> menu for upload such that menu could have a box for acme directory Uri too.
>
>
> 2023-07-07 오후 4:54에 Paul van Brouwershaven 이(가) 쓴 글:
>
> Hi Seo,
>
> a. ) CAs may want to put list of acme endpoints at well-known, for
> example one each for DV/OV/EV like sectigo did with
> https://acme.sectigo.com/v2/EV
> <https://urldefense.com/v3/__https://acme.sectigo.com/v2/EV__;!!FJ-Y8qCqXTj2!fOwwhASnPzBhTF0h_VK_hIwZsD3TU3aktKzTejf2fcZQY8dC5SasEv0izXw6vrG49jAHmrONh9Hn2QpK64AdFctM2w$>
>
> This could be solved by setting a CAA record to for example "
> ev.sectigo.com" who could have its own ACME server.
>
> b. ) I think hosting provider wouldn't want to visit a random CA without human
> intervention, not only due to potential Malicious one but an open acme
> endpoint may not allowed to use, for example CA having noncommercial use
> only limit on that endpoint, and likely stick to CA they know even if
> it's low priority from CAA.
>
> If the terms of service limit usage to non-commercial use, the domain
> owner should not set the CAA record if they run a commercial service, the
> domain owner is the entity giving the instruction to the ACME client and
> thus requests the certificate from the CA and be bound to the terms of
> service.
>
> Paul
>
>
> --
> *From:* Acme   on behalf of
> Seo Suchan  
> *Sent:* Friday, July 7, 2023 04:29
> *To:* acme@ietf.org  
> *Subject:* Re: [Acme] FW: [EXTERNAL] New 

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

[Paul van Brouwershaven]

Adding, that I agree that it would be great if service providers would all 
provide an option to configure ACME clients with a custom server and account 
binding, but I do not see how this would solve the problem of rate limiting.


From: Paul van Brouwershaven 
Sent: Friday, July 7, 2023 10:16:55 AM
To: Seo Suchan ; acme@ietf.org 
Subject: Re: [Acme] FW: [EXTERNAL] New Version Notification for 
draft-vanbrouwershaven-acme-auto-discovery-00.txt

I expect that rate limiting is main the problem for a CA that is configured as 
default. If there would be thousands of users setting the same CAA records this 
CA would need to identify that the rate limit is hit and adjust accordingly if 
these requests seem to be legit.

This would be less of a problem for a commercial CA who would be bound by 
service level agreements and can identify the customers through the account 
binding so apply a rate limit per customer instead of per IP address/block.

Paul

From: Seo Suchan 
Sent: Friday, July 7, 2023 10:07:27 AM
To: Paul van Brouwershaven ; acme@ietf.org 

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


how about ratelimit? for large hosting they will hit CA's default API ratelimit 
fast, so they contract with a specific CA for ratelimit increase. feels like 
entire automatic CA loadbearing doesn't work without hosting provider having 
eab/acme account from domain holder: if it already have menu for upload such 
that menu could have a box for acme directory Uri too.



2023-07-07 오후 4:54에 Paul van Brouwershaven 이(가) 쓴 글:
Hi Seo,
a. ) CAs may want to put list of acme endpoints at well-known, for
example one each for DV/OV/EV like sectigo did with 
https://acme.sectigo.com/v2/EV<https://urldefense.com/v3/__https://acme.sectigo.com/v2/EV__;!!FJ-Y8qCqXTj2!fOwwhASnPzBhTF0h_VK_hIwZsD3TU3aktKzTejf2fcZQY8dC5SasEv0izXw6vrG49jAHmrONh9Hn2QpK64AdFctM2w$>
This could be solved by setting a CAA record to for example "ev.sectigo.com" 
who could have its own ACME server.
b. ) I think hosting provider wouldn't want to visit a random CA without human 
intervention, not only due to potential Malicious one but an open acme endpoint 
may not allowed to use, for example CA having noncommercial use only limit on 
that endpoint, and likely stick to CA they know even if it's low priority from 
CAA.
If the terms of service limit usage to non-commercial use, the domain owner 
should not set the CAA record if they run a commercial service, the domain 
owner is the entity giving the instruction to the ACME client and thus requests 
the certificate from the CA and be bound to the terms of service.

Paul



From: Acme <mailto:acme-boun...@ietf.org> on behalf of 
Seo Suchan <mailto:tjtn...@gmail.com>
Sent: Friday, July 7, 2023 04:29
To: acme@ietf.org<mailto:acme@ietf.org> <mailto:acme@ietf.org>
Subject: Re: [Acme] FW: [EXTERNAL] New Version Notification for 
draft-vanbrouwershaven-acme-auto-discovery-00.txt

a. ) CAs may want to put list of acme endpoints at well-known, for
example one each for DV/OV/EV like sectigo did with
https://urldefense.com/v3/__https://acme.sectigo.com/v2/EV__;!!FJ-Y8qCqXTj2!brMU-rWmiKuQ6G5EN8Ns5JEESSjbP9myZLjFfF9ISFYfPkLxgoTVs-Vuaaw80lPbmpqojB3H7KCIz7G4NTvjUpZ_0A$

b. ) I think hosting provider wouldn't want to visit a random CA without
human intervention, not only due to potential Malicious one but an open
acme endpoint may not allowed to use, for example CA having
noncommercial use only limit on that endpoint, and likely stick to CA
they know even if it's low priority from CAA.

2023-07-06 오후 11:54에 Mike Ounsworth 이(가) 쓴 글:
> 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<mailto:internet-dra...@ietf.org> 
> <mailto:internet-dra...@ietf.org>
> Sent: Thursday, July 6, 2023 9:39 AM
> To: Mike Ounsworth 
> <mailto:mike.ounswo...@entrust.com>; Paul van 
> Brouwershaven 
> <mailto: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-

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

[Paul van Brouwershaven]

I expect that rate limiting is main the problem for a CA that is configured as 
default. If there would be thousands of users setting the same CAA records this 
CA would need to identify that the rate limit is hit and adjust accordingly if 
these requests seem to be legit.

This would be less of a problem for a commercial CA who would be bound by 
service level agreements and can identify the customers through the account 
binding so apply a rate limit per customer instead of per IP address/block.

Paul

From: Seo Suchan 
Sent: Friday, July 7, 2023 10:07:27 AM
To: Paul van Brouwershaven ; acme@ietf.org 

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


how about ratelimit? for large hosting they will hit CA's default API ratelimit 
fast, so they contract with a specific CA for ratelimit increase. feels like 
entire automatic CA loadbearing doesn't work without hosting provider having 
eab/acme account from domain holder: if it already have menu for upload such 
that menu could have a box for acme directory Uri too.



2023-07-07 오후 4:54에 Paul van Brouwershaven 이(가) 쓴 글:
Hi Seo,
a. ) CAs may want to put list of acme endpoints at well-known, for
example one each for DV/OV/EV like sectigo did with 
https://acme.sectigo.com/v2/EV<https://urldefense.com/v3/__https://acme.sectigo.com/v2/EV__;!!FJ-Y8qCqXTj2!fOwwhASnPzBhTF0h_VK_hIwZsD3TU3aktKzTejf2fcZQY8dC5SasEv0izXw6vrG49jAHmrONh9Hn2QpK64AdFctM2w$>
This could be solved by setting a CAA record to for example "ev.sectigo.com" 
who could have its own ACME server.
b. ) I think hosting provider wouldn't want to visit a random CA without human 
intervention, not only due to potential Malicious one but an open acme endpoint 
may not allowed to use, for example CA having noncommercial use only limit on 
that endpoint, and likely stick to CA they know even if it's low priority from 
CAA.
If the terms of service limit usage to non-commercial use, the domain owner 
should not set the CAA record if they run a commercial service, the domain 
owner is the entity giving the instruction to the ACME client and thus requests 
the certificate from the CA and be bound to the terms of service.

Paul



From: Acme <mailto:acme-boun...@ietf.org> on behalf of 
Seo Suchan <mailto:tjtn...@gmail.com>
Sent: Friday, July 7, 2023 04:29
To: acme@ietf.org<mailto:acme@ietf.org> <mailto:acme@ietf.org>
Subject: Re: [Acme] FW: [EXTERNAL] New Version Notification for 
draft-vanbrouwershaven-acme-auto-discovery-00.txt

a. ) CAs may want to put list of acme endpoints at well-known, for
example one each for DV/OV/EV like sectigo did with
https://urldefense.com/v3/__https://acme.sectigo.com/v2/EV__;!!FJ-Y8qCqXTj2!brMU-rWmiKuQ6G5EN8Ns5JEESSjbP9myZLjFfF9ISFYfPkLxgoTVs-Vuaaw80lPbmpqojB3H7KCIz7G4NTvjUpZ_0A$

b. ) I think hosting provider wouldn't want to visit a random CA without
human intervention, not only due to potential Malicious one but an open
acme endpoint may not allowed to use, for example CA having
noncommercial use only limit on that endpoint, and likely stick to CA
they know even if it's low priority from CAA.

2023-07-06 오후 11:54에 Mike Ounsworth 이(가) 쓴 글:
> 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<mailto:internet-dra...@ietf.org> 
> <mailto:internet-dra...@ietf.org>
> Sent: Thursday, July 6, 2023 9:39 AM
> To: Mike Ounsworth 
> <mailto:mike.ounswo...@entrust.com>; Paul van 
> Brouwershaven 
> <mailto: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://urldefense.com/v3/__https://www.ietf.org/archive/id/draft-vanbrouwershaven-acme-auto-discovery-00.txt__;!!FJ-Y8qCqXTj2!brMU-rWmiKuQ6G5EN8Ns5JEESSjbP9myZLjFfF9ISFYfPkLxgoTVs-Vuaaw80lPbmpqojB3H7KCIz7G4NTtFe7gh7Q$
> Status: 
> https://urldefense.com/v3/__https://datatracker.ietf.

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

[Seo Suchan]

how about ratelimit? for large hosting they will hit CA's default API 
ratelimit fast, so they contract with a specific CA for ratelimit 
increase. feels like entire automatic CA loadbearing doesn't work 
without hosting provider having eab/acme account from domain holder: if 
it already have menu for upload such that menu could have a box for acme 
directory Uri too.




2023-07-07 오후 4:54에 Paul van Brouwershaven 이(가) 쓴 글:

Hi Seo,

a. ) CAs may want to put list of acme endpoints at well-known, for
example one each for DV/OV/EV like sectigo did with
https://acme.sectigo.com/v2/EV <https://acme.sectigo.com/v2/EV>

This could be solved by setting a CAA record to for example 
"ev.sectigo.com" who could have its own ACME server.


b. ) I think hosting provider wouldn't want to visit a random CA
without human intervention, not only due to potential Malicious
one but an open acme endpoint may not allowed to use, for example
CA having noncommercial use only limit on that endpoint, and
likely stick to CA they know even if it's low priority from CAA.

If the terms of service limit usage to non-commercial use, the domain 
owner should not set the CAA record if they run a commercial service, 
the domain owner is the entity giving the instruction to the ACME 
client and thus requests the certificate from the CA and be bound to 
the terms of service.


Paul



*From:* Acme  on behalf of Seo Suchan 


*Sent:* Friday, July 7, 2023 04:29
*To:* acme@ietf.org 
*Subject:* Re: [Acme] FW: [EXTERNAL] New Version Notification for 
draft-vanbrouwershaven-acme-auto-discovery-00.txt

a. ) CAs may want to put list of acme endpoints at well-known, for
example one each for DV/OV/EV like sectigo did with
https://urldefense.com/v3/__https://acme.sectigo.com/v2/EV__;!!FJ-Y8qCqXTj2!brMU-rWmiKuQ6G5EN8Ns5JEESSjbP9myZLjFfF9ISFYfPkLxgoTVs-Vuaaw80lPbmpqojB3H7KCIz7G4NTvjUpZ_0A$ 



b. ) I think hosting provider wouldn't want to visit a random CA without
human intervention, not only due to potential Malicious one but an open
acme endpoint may not allowed to use, for example CA having
noncommercial use only limit on that endpoint, and likely stick to CA
they know even if it's low priority from CAA.

2023-07-06 오후 11:54에 Mike Ounsworth 이(가) 쓴 글:
> 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 
> Sent: Thursday, July 6, 2023 9:39 AM
> To: Mike Ounsworth ; Paul van 
Brouwershaven 
> 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!brMU-rWmiKuQ6G5EN8Ns5JEESSjbP9myZLjFfF9ISFYfPkLxgoTVs-Vuaaw80lPbmpqojB3H7KCIz7G4NTtFe7gh7Q$ 

> Status: 
https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-vanbrouwershaven-acme-auto-discovery/__;!!FJ-Y8qCqXTj2!brMU-rWmiKuQ6G5EN8Ns5JEESSjbP9myZLjFfF9ISFYfPkLxgoTVs-Vuaaw80lPbmpqojB3H7KCIz7G4NTuBIoUWfg$ 

> Html: 
https://urldefense.com/v3/__https://www.ietf.org/archive/id/draft-vanbrouwershaven-acme-auto-discovery-00.html__;!!FJ-Y8qCqXTj2!brMU-rWmiKuQ6G5EN8Ns5JEESSjbP9myZLjFfF9ISFYfPkLxgoTVs-Vuaaw80lPbmpqojB3H7KCIz7G4NTvXjxu71A$ 

> Htmlized: 
https://urldefense.com/v3/__https://datatracker.ietf.org/doc/html/draft-vanbrouwershaven-acme-auto-discovery__;!!FJ-Y8qCqXTj2!brMU-rWmiKuQ6G5EN8Ns5JEESSjbP9myZLjFfF9ISFYfPkLxgoTVs-Vuaaw80lPbmpqojB3H7KCIz7G4NTt9chylcg$ 


>
>
> 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 R

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

[Paul van Brouwershaven]

Hi Seo,
a. ) CAs may want to put list of acme endpoints at well-known, for
example one each for DV/OV/EV like sectigo did with 
https://acme.sectigo.com/v2/EV
This could be solved by setting a CAA record to for example "ev.sectigo.com" 
who could have its own ACME server.
b. ) I think hosting provider wouldn't want to visit a random CA without human 
intervention, not only due to potential Malicious one but an open acme endpoint 
may not allowed to use, for example CA having noncommercial use only limit on 
that endpoint, and likely stick to CA they know even if it's low priority from 
CAA.
If the terms of service limit usage to non-commercial use, the domain owner 
should not set the CAA record if they run a commercial service, the domain 
owner is the entity giving the instruction to the ACME client and thus requests 
the certificate from the CA and be bound to the terms of service.

Paul



From: Acme  on behalf of Seo Suchan 
Sent: Friday, July 7, 2023 04:29
To: acme@ietf.org 
Subject: Re: [Acme] FW: [EXTERNAL] New Version Notification for 
draft-vanbrouwershaven-acme-auto-discovery-00.txt

a. ) CAs may want to put list of acme endpoints at well-known, for
example one each for DV/OV/EV like sectigo did with
https://urldefense.com/v3/__https://acme.sectigo.com/v2/EV__;!!FJ-Y8qCqXTj2!brMU-rWmiKuQ6G5EN8Ns5JEESSjbP9myZLjFfF9ISFYfPkLxgoTVs-Vuaaw80lPbmpqojB3H7KCIz7G4NTvjUpZ_0A$

b. ) I think hosting provider wouldn't want to visit a random CA without
human intervention, not only due to potential Malicious one but an open
acme endpoint may not allowed to use, for example CA having
noncommercial use only limit on that endpoint, and likely stick to CA
they know even if it's low priority from CAA.

2023-07-06 오후 11:54에 Mike Ounsworth 이(가) 쓴 글:
> 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 
> Sent: Thursday, July 6, 2023 9:39 AM
> To: Mike Ounsworth ; Paul van Brouwershaven 
> 
> 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!brMU-rWmiKuQ6G5EN8Ns5JEESSjbP9myZLjFfF9ISFYfPkLxgoTVs-Vuaaw80lPbmpqojB3H7KCIz7G4NTtFe7gh7Q$
> Status: 
> https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-vanbrouwershaven-acme-auto-discovery/__;!!FJ-Y8qCqXTj2!brMU-rWmiKuQ6G5EN8Ns5JEESSjbP9myZLjFfF9ISFYfPkLxgoTVs-Vuaaw80lPbmpqojB3H7KCIz7G4NTuBIoUWfg$
> Html:   
> https://urldefense.com/v3/__https://www.ietf.org/archive/id/draft-vanbrouwershaven-acme-auto-discovery-00.html__;!!FJ-Y8qCqXTj2!brMU-rWmiKuQ6G5EN8Ns5JEESSjbP9myZLjFfF9ISFYfPkLxgoTVs-Vuaaw80lPbmpqojB3H7KCIz7G4NTvXjxu71A$
> Htmlized:
> https://urldefense.com/v3/__https://datatracker.ietf.org/doc/html/draft-vanbrouwershaven-acme-auto-discovery__;!!FJ-Y8qCqXTj2!brMU-rWmiKuQ6G5EN8Ns5JEESSjbP9myZLjFfF9ISFYfPkLxgoTVs-Vuaaw80lPbmpqojB3H7KCIz7G4NTt9chylcg$
>
>
> 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

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

[Paul van Brouwershaven]

Hi Amir,

We described this challenge in the Security Considerations, Terms of Service 
and Acceptance:

https://www.ietf.org/archive/id/draft-vanbrouwershaven-acme-auto-discovery-01.html#name-terms-of-service-and-accept

A similar problem exists today, in case the subscriber uploads the certificate 
to a service provider. While it would have agreed to the terms of service, it 
basically delegates some of its responsibilities.

In the security considerations we describe currently two mechanisms, implicit 
approval by setting the CAA record, or explicit approval by including a CAA 
parameter. I don't like an additional CAA parameter, but if a CA would like to 
get an explicit approval they could also send a request to the email of the 
ACME account to approve the terms of service before activating the ACME account.

Where a CA is using an external account binding the terms of service have 
already been agreed to for the CA account.

I will create an issue to update this section for further clarification.

Paul


From: Acme  on behalf of Amir Omidi 

Sent: Friday, July 7, 2023 04:32
To: Seo Suchan 
Cc: acme@ietf.org 
Subject: Re: [Acme] FW: [EXTERNAL] New Version Notification for 
draft-vanbrouwershaven-acme-auto-discovery-00.txt

In this flow, the subscriber is the hosting company. This means that the end 
domain would be expecting an entity (the hosting company) to agree to the CA 
terms of service without ever actually reading them.

Registering an account with a CA generally requires an affirmation to follow 
the terms of the agreement of the CA, and I think that could impose a problem 
with this draft.

On Thu, Jul 6, 2023 at 22:29 Seo Suchan 
mailto:tjtn...@gmail.com>> wrote:
a. ) CAs may want to put list of acme endpoints at well-known, for
example one each for DV/OV/EV like sectigo did with
https://acme.sectigo.com/v2/EV<https://urldefense.com/v3/__https://acme.sectigo.com/v2/EV__;!!FJ-Y8qCqXTj2!Zi5QbjzclZVHaiNkeCqijL-X7C8hsEOQ7QXmvlVOdW6GuK51gyKJzMxszaA0GkDN36Ev8DA9h7jfN0HO737mnJHDtNMAIJgXQsQhgK0vSw$>

b. ) I think hosting provider wouldn't want to visit a random CA without
human intervention, not only due to potential Malicious one but an open
acme endpoint may not allowed to use, for example CA having
noncommercial use only limit on that endpoint, and likely stick to CA
they know even if it's low priority from CAA.

2023-07-06 오후 11:54에 Mike Ounsworth 이(가) 쓴 글:
> 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<mailto:internet-dra...@ietf.org> 
> mailto:internet-dra...@ietf.org>>
> Sent: Thursday, July 6, 2023 9:39 AM
> To: Mike Ounsworth 
> mailto:mike.ounswo...@entrust.com>>; Paul van 
> Brouwershaven 
> mailto: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<https://urldefense.com/v3/__https://www.ietf.org/archive/id/draft-vanbrouwershaven-acme-auto-discovery-00.txt__;!!FJ-Y8qCqXTj2!Zi5QbjzclZVHaiNkeCqijL-X7C8hsEOQ7QXmvlVOdW6GuK51gyKJzMxszaA0GkDN36Ev8DA9h7jfN0HO737mnJHDtNMAIJgXQsRANgFd8w$>
> 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!Zi5QbjzclZVHaiNkeCqijL-X7C8hsEOQ7QXmvlVOdW6GuK51gyKJzMxszaA0GkDN36Ev8DA9h7jfN0HO737mnJHDtNMAIJgXQsSXPaaA5Q$>
> 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!Zi5QbjzclZVHaiNkeCqijL-X7C8hsEOQ7QXmvlVOdW6GuK51gyKJzMxszaA0GkDN36Ev8DA9h7jfN0HO737mnJHDtNMAIJgXQsSkdJiMDg$>
> Htmlized:
> https://datatracker.ietf.org/doc/html/draft-vanbrouwershaven-acme-auto-discovery<https://urldefense.com/v3/_

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

[Paul van Brouwershaven]

Hi Fraser,

I did not see your earlier proposal and thanks for providing this history.
Can CAA be used?  Yes, but the number of CAA records to manage grows
with the number of domains for which certs must be issued.  This
could be a headache for some orgs.
I agree that it depends on the number of domain names and that this could cause 
some challenges if you manage thousands of domain names, on the other hand, 
this could be templated (depending on the DNS provider), and if you have 
thousands of domain names you might also have thousands of ACME capable 
servers. In case all thousand domain names use the same CNAME, CAA specifies 
that the record could be at the target domain name.

Each domain must indeed have at least one CAA record, but there is no need to 
change these records unless you want to change the CAs for this domain. This 
draft could make such a change easier, as instead of changing the ACME server 
configuration (which is not always possible in a shared environment) at each 
provider and/or at all your own servers, and potentially in CAA, you could now 
simply change this domain by domain.

CAA records should ideally be configured on all domains by organizations 
relying on certificates anyway, it restricts who can issue certificates for 
your domain name and significantly reduces the attack surface. All CAs are 
required to check CAA records according to the CA/Browser forum Baseline 
Requirements before issuing a certificate.

That said, adoption of CAA is not at the level where we would like to see it. 
This draft might create an additional incentive to configure CAA records.

Per published RFCs only the "dns" identifier type could be use with the CAA 
approach.  "ip" identifiers are important for many orgs, particuarly those 
managing their own cloud infrastructure.
Correct, this is not something we really considered, as when you manage your 
own infrastructure you can also manage your ACME configuration more easily. But 
like you stated, usage of CAA in the .arpa domain could be dealt with in a 
separate document.

Paul







From: Fraser Tweedale 
Sent: Friday, July 7, 2023 05:23
To: Mike Ounsworth 
Cc: Paul van Brouwershaven ; Richard Barnes 
; acme@ietf.org 
Subject: Re: [Acme] FW: [EXTERNAL] New Version Notification for 
draft-vanbrouwershaven-acme-auto-discovery-00.txt

On Fri, Jul 07, 2023 at 01:55:52AM +, Mike Ounsworth wrote:
> Thanks for the comments Fraser.
>
> Guilty as charged -- we were not thinking about private enterprise
> environments when we wrote it; we were thinking about
> publicly-reachable servers on public clouds getting certs from
> public CAs. In that context, the quote from the abstract "at the
> mercy of their hosting provider as to which Certification
> Authorities (CAs) can be used" is less about the ACME server being
> reachable in a network sense, and more about public hosting
> providers -- quite reasonably -- not wanting to maintain a
> dropdown menu of every ACME server on the internet. Typically if
> you want to use a CA other than the single one that your hosting
> provider knows how to ACME to, then your only option is to
> manually upload a PEM file. Yuck. The other assumption here is
> that this draft is really for domain owners who care enough about
> where their certs come from to have a "favourite CA" because
> people who don't care will be happy to use whatever default ACME
> server.
>
> That said, it's interesting to think about how this could apply to
> your enterprise problem of "find me /some/ ACME server that I can
> reach/use in this network zone". Assuming a private network with
> multiple DNS zones, you could configure your private DNS to slap
> on a constant CAA record across a DNS zone, and that gives you
> your "give me an ACME server, any one will do", right?
>
> Out of curiosity, what happened to draft-tweedale-acme-discovery?
> Did it just not have enough momentum to proceed? Searching on the
> ACME list archive did not turn up very much discussion.

I presented it at IETF 109.  There was broard agreement that it was
a problem that should be solved, but no appetite for the WG to adopt
it at that time.  I'm happy with the content of the proposal and
even implemented a working POC in certbot.

For context, I work at Red Hat and helped develop the ACME server
support in Red Hat Certificate System (upstream: Dogtag Certificate
System) and Identity Management in RHEL (upstream: FreeIPA).  So I
was thinking about how to further enable customers to use cert
automation within their environments.  We haven't implemented the
proposed DNS-SD records yet, because there is no client support (due
to lack of a standard to follow - a "chicken/egg" situation).

Can CAA be used?  Yes, but the number of CAA records to manage grows

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

[Fraser Tweedale]

On Fri, Jul 07, 2023 at 01:55:52AM +, Mike Ounsworth wrote:
> Thanks for the comments Fraser.
> 
> Guilty as charged -- we were not thinking about private enterprise
> environments when we wrote it; we were thinking about
> publicly-reachable servers on public clouds getting certs from
> public CAs. In that context, the quote from the abstract "at the
> mercy of their hosting provider as to which Certification
> Authorities (CAs) can be used" is less about the ACME server being
> reachable in a network sense, and more about public hosting
> providers -- quite reasonably -- not wanting to maintain a
> dropdown menu of every ACME server on the internet. Typically if
> you want to use a CA other than the single one that your hosting
> provider knows how to ACME to, then your only option is to
> manually upload a PEM file. Yuck. The other assumption here is
> that this draft is really for domain owners who care enough about
> where their certs come from to have a "favourite CA" because
> people who don't care will be happy to use whatever default ACME
> server.
> 
> That said, it's interesting to think about how this could apply to
> your enterprise problem of "find me /some/ ACME server that I can
> reach/use in this network zone". Assuming a private network with
> multiple DNS zones, you could configure your private DNS to slap
> on a constant CAA record across a DNS zone, and that gives you
> your "give me an ACME server, any one will do", right?
> 
> Out of curiosity, what happened to draft-tweedale-acme-discovery?
> Did it just not have enough momentum to proceed? Searching on the
> ACME list archive did not turn up very much discussion.

I presented it at IETF 109.  There was broard agreement that it was
a problem that should be solved, but no appetite for the WG to adopt
it at that time.  I'm happy with the content of the proposal and
even implemented a working POC in certbot.

For context, I work at Red Hat and helped develop the ACME server
support in Red Hat Certificate System (upstream: Dogtag Certificate
System) and Identity Management in RHEL (upstream: FreeIPA).  So I
was thinking about how to further enable customers to use cert
automation within their environments.  We haven't implemented the
proposed DNS-SD records yet, because there is no client support (due
to lack of a standard to follow - a "chicken/egg" situation).

Can CAA be used?  Yes, but the number of CAA records to manage grows
with the number of domains for which certs must be issued.  This
could be a headache for some orgs.

Per published RFCs only the "dns" identifier type could be use with
the CAA approach.  "ip" identifiers are important for many orgs,
particuarly those managing their own cloud infrastructure.  But how
to use CAA for ipAddress SAN is not defined.  (Perhaps use the
existing CAA attributes in _.in-addr.arpa and _.ip6.arpa zones).
There is a draft that defines how it would work for the "email"
identifier type[1].

[1] https://datatracker.ietf.org/doc/draft-ietf-lamps-caa-issuemail/

However, I think that the CAA approach is likely to get more
traction.  It uses DNS RR types that PKI people are already familiar
with.  It *can* be used in enterprise environments, albeit with more
administrative burden in scenarios that involve a lot of domain
names.

The gap of how CAA can be applied to ipAddress SAN names should be
dealt with in a separate document.  Such work will no doubt attract
interest from other groups (CAB Forum in particular).

The approaches are not mutually exclusive but I really can't imagine
clients would want to implement support for more than one mechanism.
Let's see where this new proposal leads!

Cheers,
Fraser

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

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

[Amir Omidi]

In this flow, the subscriber is the hosting company. This means that the
end domain would be expecting an entity (the hosting company) to agree to
the CA terms of service without ever actually reading them.

Registering an account with a CA generally requires an affirmation to
follow the terms of the agreement of the CA, and I think that could impose
a problem with this draft.

On Thu, Jul 6, 2023 at 22:29 Seo Suchan  wrote:

> a. ) CAs may want to put list of acme endpoints at well-known, for
> example one each for DV/OV/EV like sectigo did with
> https://acme.sectigo.com/v2/EV
>
> b. ) I think hosting provider wouldn't want to visit a random CA without
> human intervention, not only due to potential Malicious one but an open
> acme endpoint may not allowed to use, for example CA having
> noncommercial use only limit on that endpoint, and likely stick to CA
> they know even if it's low priority from CAA.
>
> 2023-07-06 오후 11:54에 Mike Ounsworth 이(가) 쓴 글:
> > 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 
> > Sent: Thursday, July 6, 2023 9:39 AM
> > To: Mike Ounsworth ; Paul van Brouwershaven
> 
> > 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
>
-- 
Amir Omidi (he/them)
___
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme

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

[Seo Suchan]

a. ) CAs may want to put list of acme endpoints at well-known, for 
example one each for DV/OV/EV like sectigo did with 
https://acme.sectigo.com/v2/EV


b. ) I think hosting provider wouldn't want to visit a random CA without 
human intervention, not only due to potential Malicious one but an open 
acme endpoint may not allowed to use, for example CA having 
noncommercial use only limit on that endpoint, and likely stick to CA 
they know even if it's low priority from CAA.


2023-07-06 오후 11:54에 Mike Ounsworth 이(가) 쓴 글:

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 
Sent: Thursday, July 6, 2023 9:39 AM
To: Mike Ounsworth ; Paul van Brouwershaven 

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

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

[Mike Ounsworth]

Thanks for the comments Fraser.

Guilty as charged -- we were not thinking about private enterprise environments 
when we wrote it; we were thinking about publicly-reachable servers on public 
clouds getting certs from public CAs. In that context, the quote from the 
abstract "at the mercy of their hosting provider as to which Certification 
Authorities (CAs) can be used" is less about the ACME server being reachable in 
a network sense, and more about public hosting providers -- quite reasonably -- 
not wanting to maintain a dropdown menu of every ACME server on the internet. 
Typically if you want to use a CA other than the single one that your hosting 
provider knows how to ACME to, then your only option is to manually upload a 
PEM file. Yuck. The other assumption here is that this draft is really for 
domain owners who care enough about where their certs come from to have a 
"favourite CA" because people who don't care will be happy to use whatever 
default ACME server.

That said, it's interesting to think about how this could apply to your 
enterprise problem of "find me /some/ ACME server that I can reach/use in this 
network zone". Assuming a private network with multiple DNS zones, you could 
configure your private DNS to slap on a constant CAA record across a DNS zone, 
and that gives you your "give me an ACME server, any one will do", right?

Out of curiosity, what happened to draft-tweedale-acme-discovery? Did it just 
not have enough momentum to proceed? Searching on the ACME list archive did not 
turn up very much discussion.

---
Mike Ounsworth

-Original Message-
From: Fraser Tweedale 
Sent: Thursday, July 6, 2023 7:40 PM
To: Paul van Brouwershaven 
Cc: Richard Barnes ; Mike Ounsworth ; 
acme@ietf.org
Subject: Re: [Acme] FW: [EXTERNAL] New Version Notification for 
draft-vanbrouwershaven-acme-auto-discovery-00.txt

On Fri, Jul 07, 2023 at 10:06:15AM +1000, Fraser Tweedale wrote:
> - 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.
>

With respect to (a) - never mind.  I thought about it some more and the answer 
is obvious.  Where a CA authorization (i.e. restriction) exists in the form of 
a CAA record, it is useful to be able to direct a client to the authorized 
issuer(s) for the affected domain(s).

I see that your draft solves a real problem.  But it does not help much in 
enterprise environments, where the question is often "find me /some/ ACME 
server that I can reach/use, or which the administrators prefer".  Two 
different problems, two complementary approaches.

Thanks,
Fraser
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

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

[Fraser Tweedale]

On Fri, Jul 07, 2023 at 10:06:15AM +1000, Fraser Tweedale wrote:
> - 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.
> 

With respect to (a) - never mind.  I thought about it some more and
the answer is obvious.  Where a CA authorization (i.e. restriction)
exists in the form of a CAA record, it is useful to be able to
direct a client to the authorized issuer(s) for the affected
domain(s).

I see that your draft solves a real problem.  But it does not help
much in enterprise environments, where the question is often "find
me /some/ ACME server that I can reach/use, or which the
administrators prefer".  Two different problems, two complementary
approaches.

Thanks,
Fraser

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

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

[Fraser Tweedale]

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 +, 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 
> Sent: Thursday, July 6, 2023 19:29
> To: Mike Ounsworth 
> Cc: acme@ietf.org ; Paul van Brouwershaven 
> 
> 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 AC

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

[Paul van Brouwershaven]

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 
Sent: Thursday, July 6, 2023 19:29
To: Mike Ounsworth 
Cc: acme@ietf.org ; Paul van Brouwershaven 

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 
mailto: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<mailto:internet-dra...@ietf.org> 
mailto:internet-dra...@ietf.org>>
Sent: Thursday, July 6, 2023 9:39 AM
To: Mike Ounsworth 
mailto:mike.ounswo...@entrust.com>>; Paul van 
Brouwershaven 
mailto:paul.vanbrouwersha...@entrust.com>>
Subject: [EXTERNAL] New Version Notification for 
draft-vanbrouwershaven-acme-auto-disc

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

[Richard Barnes]

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 will look up CAA records
for example.com 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  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 
> Sent: Thursday, July 6, 2023 9:39 AM
> To: Mike Ounsworth ; 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

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

[Mike Ounsworth]

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 
Sent: Thursday, July 6, 2023 9:39 AM
To: Mike Ounsworth ; Paul van Brouwershaven 

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