[Acme] [Technical Errata Reported] RFC8555 (7826)

RFC Errata System <rfc-editor@rfc-editor.org> Wed, 28 February 2024 20:25 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 1763DC14F699 for <acme@ietfa.amsl.com>; Wed, 28 Feb 2024 12:25:24 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.958
X-Spam-Status: No, score=-3.958 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.249, RCVD_IN_DNSWL_MED=-2.3, 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=unavailable autolearn_force=no
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id SqPOBcIPASvN for <acme@ietfa.amsl.com>; Wed, 28 Feb 2024 12:25:20 -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 44013C14F6AB for <acme@ietf.org>; Wed, 28 Feb 2024 12:25:20 -0800 (PST)
Received: by rfcpa.amsl.com (Postfix, from userid 499) id 0589A1F57D8E; Wed, 28 Feb 2024 12:25:20 -0800 (PST)
To: rlb@ipv.sx, jsha@eff.org, cpu@letsencrypt.org, jdkasten@umich.edu, rdd@cert.org, paul.wouters@aiven.io, debcooley1@gmail.com, ynir.ietf@gmail.com
From: RFC Errata System <rfc-editor@rfc-editor.org>
Cc: rob@sectigo.com, acme@ietf.org, rfc-editor@rfc-editor.org
Content-Type: text/plain; charset="UTF-8"
Message-Id: <20240228202520.0589A1F57D8E@rfcpa.amsl.com>
Date: Wed, 28 Feb 2024 12:25:20 -0800
Archived-At: <https://mailarchive.ietf.org/arch/msg/acme/WrnrbYJaUJL3fx9kha6SiW3SP5o>
X-Mailman-Approved-At: Thu, 29 Feb 2024 03:07:20 -0800
Subject: [Acme] [Technical Errata Reported] RFC8555 (7826)
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: Wed, 28 Feb 2024 20:25:24 -0000

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

You may review the report below and at:

Type: Technical
Reported by: Rob Stradling <rob@sectigo.com>

Section: 8.2

Original Text
The server MUST provide information about its retry state to the client via the "error" field in the challenge and the Retry-After HTTP header field in response to requests to the challenge resource.

Corrected Text
In responding to requests to the challenge resource while the status of the challenge remains "processing", the server MUST provide information about its retry state to the client via the "error" field in the challenge and the Retry-After HTTP header field.

The current text seems to require the server to include the "error" field and Retry-After HTTP header in all responses to requests for a challenge resource, even before that challenge has moved from "pending" to "processing", and even after that challenge has moved from "processing" to "valid" or "invalid".  However, the "State Transitions for Challenge Objects" diagram in Section 7.1.6 shows that it only makes sense for the server to communicate "its retry state" to the client when the challenge is "processing".

I've modelled the structure of my suggested Corrected Text on similar language in Section 7.5.1: "In responding to poll requests while the validation is still in progress, the server MUST...".

This erratum is currently posted as "Reported". (If it is spam, it 
will be removed shortly by the RFC Production Center.) Please
use "Reply All" to discuss whether it should be verified or
rejected. When a decision is reached, the verifying party  
will 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