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

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
>