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 <[email protected]>
Sent: Wednesday, July 12, 2023 16:20
To: Paul van Brouwershaven <[email protected]>
Cc: [email protected] <[email protected]>
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 â„– UK00003718474 and â„– UK00003718468, respectively.
On Wed, 12 Jul 2023 at 14:52, Paul van Brouwershaven
<[email protected]<mailto:[email protected]>>
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 <[email protected]<mailto:[email protected]>>
Sent: Wednesday, July 12, 2023 15:06
To: Paul van Brouwershaven
<[email protected]<mailto:[email protected]>>
Cc: [email protected]<mailto:[email protected]> <[email protected]<mailto:[email protected]>>
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
<[email protected]<mailto:[email protected]>> 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
[email protected]<mailto:[email protected]>
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
[email protected]
https://www.ietf.org/mailman/listinfo/acme
