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 <[email protected]> 작성함: >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 <[email protected]> >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 <[email protected]> >> >> 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 >> [email protected] >> https://www.ietf.org/mailman/listinfo/acme >>
_______________________________________________ Acme mailing list [email protected] https://www.ietf.org/mailman/listinfo/acme
