On Tue, Aug 18, 2020 at 02:16:12PM -0600, Matt Holt wrote: > Hi, > > After working heavily with ACME clients for the past 5 years (including > "ACMEv1" before RFC 8555) I've come to realize some unfortunate > ambiguities/inefficiencies in RFC 8555 with regards to server behavior after > a challenge is attempted and failed by the client. > > I recently implemented an RFC 8555-compliant client library in Go > (https://github.com/mholt/acmez), and am convinced that a simple revision to > the spec can both reduce costs for CAs *and* greatly simplify client > implementations, if only the handling of failed challenges is revised. > > My realizations are spelled out in this commit: > https://github.com/mholt/acmez/commit/80adb6d5e64a3d36a56c58c66965b131ea366b8c > > In summary: 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, one failed > challenge is apparently sufficient to invalidate the authz, and thus the > entire Order. To try another challenge, the client then has to deactivate the > other Authorizations (expensive) and create a new Order (also expensive), > repeating the whole process. Instead, the client should be able to 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.
I believe that this part of the spec does not have strong specific motivation, and in some sense stems from the last paragraph of the "DISCUSS" section of my ballot position (see thread at https://mailarchive.ietf.org/arch/msg/acme/YLYlBVdnv2VxllVCS8pF-QueLe8/) -- I just wanted clarity on what the actual behavior *was*, so that client and server were in agreement. It seems that we ended up at the "one failed challenge fails everything" out of expediency w.r.t. minimizing textual changes at the late stage, though I did not review the entire thread to confirm that. Presumably next steps on this front are to confirm that this is indeed the source of the behavior, and then consider how the reised semantics might be deployed (bearing in mind the continued need for client and server to agree on what the semantics are for any given order). It may be that a new version would be needed :-/ -Ben _______________________________________________ Acme mailing list [email protected] https://www.ietf.org/mailman/listinfo/acme
