Re: [Acme] A single failed challenge should not invalidate an entire order

Benjamin Kaduk <> Thu, 20 August 2020 05:57 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id A76CB3A0813 for <>; Wed, 19 Aug 2020 22:57:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id xVJ93MmQBA00 for <>; Wed, 19 Aug 2020 22:57:47 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 0E3CF3A0802 for <>; Wed, 19 Aug 2020 22:57:46 -0700 (PDT)
Received: from ([]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by (8.14.7/8.12.4) with ESMTP id 07K5vghY006117 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 20 Aug 2020 01:57:45 -0400
Date: Wed, 19 Aug 2020 22:57:42 -0700
From: Benjamin Kaduk <>
To: Matt Holt <>
Cc: Acme <>
Message-ID: <>
References: <>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <>
User-Agent: Mutt/1.12.1 (2019-06-15)
Archived-At: <>
Subject: Re: [Acme] A single failed challenge should not invalidate an entire order
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Automated Certificate Management Environment <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 20 Aug 2020 05:57:49 -0000

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 (, 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:
> 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 --
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 :-/