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 <tim.hollebeek= 40digicert....@dmarc.ietf.org> 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 <acme-boun...@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.vanbrouwersha...@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 > <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 № UK00003718474 and № > UK00003718468, respectively. > > > > > > On Fri, 7 Jul 2023 at 14:32, Salz, Rich <rsalz=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 > 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 > -- Amir Omidi (he/them)
_______________________________________________ Acme mailing list Acme@ietf.org https://www.ietf.org/mailman/listinfo/acme
