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
