Re: [Acme] [Technical Errata Reported] RFC8555 (6317)

While looks sensible I wonder if how many clients pulling on auth instead of challanges:
Those client will pull without limit if this behavior applied to CA

For example this client do watch auths status instead of challenge itself.
https://github.com/diafygi/acme-tiny/blob/c29c0f36cedbca2a7117169c6a9e1f166c501899/acme_tiny.py#L151 

On 2024년 1월 3일 오후 9시 30분 5초 GMT+09:00, Deb Cooley <debcooley1@gmail.com> 작성함:
>This is the last errata I'll pester you with today.  This one seems
>sensible.  Please confirm or enlighten me.
>
>Deb
>
>On Fri, Oct 23, 2020 at 7:07 PM RFC Errata System <rfc-editor@rfc-editor.org>
>wrote:
>
>> The following errata report has been submitted for RFC8555,
>> "Automatic Certificate Management Environment (ACME)".
>>
>> --------------------------------------
>> You may review the report below and at:
>> https://www.rfc-editor.org/errata/eid6317
>>
>> --------------------------------------
>> Type: Technical
>> Reported by: Matthew Holt <matt@lightcodelabs.com>
>>
>> Section: 7.5.1
>>
>> Original Text
>> -------------
>> The server is said to "finalize" the authorization when it has
>> completed one of the validations.
>>
>> Corrected Text
>> --------------
>> The server is said to "finalize" the authorization when it has
>> successfully completed one of the validations or failed all of
>> them.
>>
>> Notes
>> -----
>> The current handling of failed challenges is ambiguous, or at least
>> inefficient.
>>
>> To get a certificate, a client creates an Order. The client then has to
>> validate all Authorizations ("authzs"). For each Authorization, the client
>> needs to successfully complete one of the offered Challenges. One
>> successful Challenge is sufficient to validate the authz. However,
>> currently in practice, one failed Challenge is sufficient to invalidate the
>> authz, and thus the entire Order. To try another Challenge, the client then
>> has to first deactivate the other Authorizations (expensive) and create a
>> new Order (also expensive), then repeat the whole process, remembering what
>> was already tried.
>>
>> It is proposed that an Authorization MUST NOT be finalized until all
>> possible challenges have failed. The client could then simply try the next
>> Challenge. In other words, a single failed Challenge should not invalidate
>> an authz; an authz should be "pending" until all offered challenges have
>> failed or one has succeeded.
>>
>> The spec should be clear that a single failed challenge is not sufficient
>> to finalize an authz which has multiple possible challenges.
>>
>> ACME servers see many, many failed validations. ACME clients need to keep
>> more state. This change will speed up ACME transactions, lower costs for
>> CAs, reduce code complexity, and make ACME more reliable on the whole.
>>
>> Real-world experience:
>> https://github.com/mholt/acmez/commit/80adb6d5e64a3d36a56c58c66965b131ea366b8c
>> Mailing list discussion:
>> https://mailarchive.ietf.org/arch/msg/acme/wIHaqikTCZ59zrWsUUus8lZ4VSg/
>>
>> Instructions:
>> -------------
>> This erratum is currently posted as "Reported". If necessary, please
>> use "Reply All" to discuss whether it should be verified or
>> rejected. When a decision is reached, the verifying party
>> can log in to change the status and edit the report, if necessary.
>>
>> --------------------------------------
>> RFC8555 (draft-ietf-acme-acme-18)
>> --------------------------------------
>> Title               : Automatic Certificate Management Environment (ACME)
>> Publication Date    : March 2019
>> Author(s)           : R. Barnes, J. Hoffman-Andrews, D. McCarney, J. Kasten
>> Category            : PROPOSED STANDARD
>> Source              : Automated Certificate Management Environment
>> Area                : Security
>> Stream              : IETF
>> Verifying Party     : IESG
>>
>> _______________________________________________
>> Acme mailing list
>> Acme@ietf.org
>> https://www.ietf.org/mailman/listinfo/acme
>>