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://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 № UK00003718474 and № UK00003718468,
respectively.

On Wed, 12 Jul 2023 at 19:34, Paul van Brouwershaven <
Paul.vanBrouwershaven@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 <tim.hollebeek=40digicert.com@dmarc.ietf.org>
> *Sent:* Wednesday, July 12, 2023 19:32
> *To:* Paul van Brouwershaven <Paul.vanBrouwershaven@entrust.com>; Q
> Misell <q@as207960.net>
> *Cc:* acme@ietf.org <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 <Paul.vanBrouwershaven=
> 40entrust.com@dmarc.ietf.org>
> *Sent:* Wednesday, July 12, 2023 1:01 PM
> *To:* Tim Hollebeek <tim.hollebeek@digicert.com>; Q Misell <q@as207960.net
> >
> *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 <tim.hollebeek=40digicert.com@dmarc.ietf.org>
> *Sent:* Wednesday, July 12, 2023 6:43:21 PM
> *To:* Paul van Brouwershaven <Paul.vanBrouwershaven@entrust.com>; Q
> Misell <q@as207960.net>
> *Cc:* acme@ietf.org <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 <acme-bounces@ietf.org> *On Behalf Of *Paul van Brouwershaven
> *Sent:* Wednesday, July 12, 2023 9:52 AM
> *To:* Q Misell <q@as207960.net>
> *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 <q@as207960.net>
> *Sent:* Wednesday, July 12, 2023 15:06
> *To:* Paul van Brouwershaven <Paul.vanBrouwershaven@entrust.com>
> *Cc:* acme@ietf.org <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 № UK00003718474 and №
> UK00003718468, respectively.
>
>
>
>
>
> On Fri, 7 Jul 2023 at 14:32, Salz, Rich <rsalz=40akamai.com@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
> 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.*
>