[Acme] [Errata Held for Document Update] RFC8555 (6317)

RFC Errata System <rfc-editor@rfc-editor.org> Thu, 11 January 2024 21:32 UTC

Return-Path: <wwwrun@rfcpa.amsl.com>
X-Original-To: acme@ietfa.amsl.com
Delivered-To: acme@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id 525EDC14F61C; Thu, 11 Jan 2024 13:32:02 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.657
X-Spam-Status: No, score=-1.657 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.249, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=no autolearn_force=no
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id fH7G55mysbdz; Thu, 11 Jan 2024 13:31:58 -0800 (PST)
Received: from rfcpa.amsl.com (rfcpa.amsl.com []) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 05E2FC14F60E; Thu, 11 Jan 2024 13:31:58 -0800 (PST)
Received: by rfcpa.amsl.com (Postfix, from userid 499) id B24ED1A2161C; Thu, 11 Jan 2024 13:31:57 -0800 (PST)
To: matt@lightcodelabs.com, rlb@ipv.sx, jsha@eff.org, cpu@letsencrypt.org, jdkasten@umich.edu
From: RFC Errata System <rfc-editor@rfc-editor.org>
Cc: rdd@cert.org, iesg@ietf.org, acme@ietf.org, rfc-editor@rfc-editor.org
Content-Type: text/plain; charset="UTF-8"
Message-Id: <20240111213157.B24ED1A2161C@rfcpa.amsl.com>
Date: Thu, 11 Jan 2024 13:31:57 -0800
Archived-At: <https://mailarchive.ietf.org/arch/msg/acme/jufiw7-c9EOfwPos-VsGdajSBDI>
Subject: [Acme] [Errata Held for Document Update] RFC8555 (6317)
X-BeenThere: acme@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: Automated Certificate Management Environment <acme.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/acme>, <mailto:acme-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/acme/>
List-Post: <mailto:acme@ietf.org>
List-Help: <mailto:acme-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/acme>, <mailto:acme-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 11 Jan 2024 21:32:02 -0000

The following errata report has been held for document update 
for RFC8555, "Automatic Certificate Management Environment (ACME)". 

You may review the report below and at:

Status: Held for Document Update
Type: Technical

Reported by: Matthew Holt <matt@lightcodelabs.com>
Date Reported: 2020-10-23
Held by: Roman Danyliw (IESG)

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

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/

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