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

[Mike Ounsworth <[e-mail]>]

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=[e-mail]> 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 <[e-mail]> On Behalf Of Tim Hollebeek
Sent: Wednesday, July 12, 2023 3:03 PM
To: Seo Suchan <[e-mail]>; [e-mail]
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 <[e-mail]<mailto:[e-mail]>> On Behalf Of Seo Suchan
Sent: Wednesday, July 12, 2023 3:29 PM
To: [e-mail]<mailto:[e-mail]>
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 <tim.hollebeek=[e-mail]><mailto:tim.hollebeek=[e-mail]>
Sent: Wednesday, July 12, 2023 19:32
To: Paul van Brouwershaven <[e-mail]><mailto:[e-mail]>; Q Misell <[e-mail]><mailto:[e-mail]>
Cc: [e-mail]<mailto:[e-mail]> <[e-mail]><mailto:[e-mail]>
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 <Paul.vanBrouwershaven=[e-mail]><mailto:Paul.vanBrouwershaven=[e-mail]>
Sent: Wednesday, July 12, 2023 1:01 PM
To: Tim Hollebeek <[e-mail]><mailto:[e-mail]>; Q Misell <[e-mail]><mailto:[e-mail]>
Cc: [e-mail]<mailto:[e-mail]>
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 <tim.hollebeek=[e-mail]<mailto:tim.hollebeek=[e-mail]>>
Sent: Wednesday, July 12, 2023 6:43:21 PM
To: Paul van Brouwershaven <[e-mail]<mailto:[e-mail]>>; Q Misell <[e-mail]<mailto:[e-mail]>>
Cc: [e-mail]<mailto:[e-mail]> <[e-mail]<mailto:[e-mail]>>
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 <[e-mail]<mailto:[e-mail]>> On Behalf Of Paul van Brouwershaven
Sent: Wednesday, July 12, 2023 9:52 AM
To: Q Misell <[e-mail]<mailto:[e-mail]>>
Cc: [e-mail]<mailto:[e-mail]>
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 <[e-mail]<mailto:[e-mail]>>
Sent: Wednesday, July 12, 2023 15:06
To: Paul van Brouwershaven <[e-mail]<mailto:[e-mail]>>
Cc: [e-mail]<mailto:[e-mail]> <[e-mail]<mailto:[e-mail]>>
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 № UK00003718474 and № UK00003718468, respectively.





On Fri, 7 Jul 2023 at 14:32, Salz, Rich <rsalz=[e-mail]<mailto:[e-mail]>> 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
[e-mail]<mailto:[e-mail]>
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

[e-mail]<mailto:[e-mail]>

https://www.ietf.org/mailman/listinfo/acme<https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/acme__;!!FJ-Y8qCqXTj2!e2ahcjHxpBm0DbNAyyiXQOSvyGXiiprYJeT7WWoAb0jKC4V8Ej-5FkVLT2ANFjUiCbXDMuctgsbRX7K6XZkgCBy-F0LN8gbEBBfZ$>