Subject: [Acme] [Technical Errata Reported] RFC8555 (6030)

From: RFC Errata System <[email-masked]>
Date: Wed, 25 Mar 2020 15:25:57 -0700 (PDT)

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/eid6030

--------------------------------------
Type: Technical
Reported by: Matt Palmer <[email-masked]>

Section: 7.2

Original Text
-------------
To get a fresh nonce, the client sends a HEAD request to the newNonce
resource on the server.  The server's response MUST include a Replay-
Nonce header field containing a fresh nonce and SHOULD have status
code 200 (OK).  The server MUST also respond to GET requests for this
resource, returning an empty body (while still providing a Replay-
Nonce header) with a status code of 204 (No Content).

Corrected Text
--------------
To get a fresh nonce, the client sends a HEAD request to the newNonce
resource on the server.  The server's response MUST include a Replay-
Nonce header field containing a fresh nonce and SHOULD have status
code 204 (No Content).  The server MUST also respond to GET requests for this
resource, returning an empty body (while still providing a Replay-
Nonce header) with a status code of 204 (No Content).

Notes
-----
RFC7321 s4.3.2, says "The server SHOULD send the same header fields in response to a HEAD request as it would have sent if the request had been a GET".  I can't see any rationale for violating this SHOULD in the discussion in the GH issue which introduced the discrepancy in response code between GET and HEAD (https://github.com/ietf-wg-acme/acme/pull/371), thus (IMHO) it violates the tenets of a SHOULD, as "the full implications" do not appear to have "be[en] understood and carefully weighed before choosing a different course" (RFC2119, of course).

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

---

From: Roland Shoemaker <[email-masked]>
Date: Wed, 25 Mar 2020 21:03:23 -0700

To save people some confusion, I think the reporter is referring to RFC
7231 (Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content) rather
than 7321 (Cryptographic Algorithm Implementation Requirements and Usage
Guidance).

On Wed, Mar 25, 2020 at 3:44 PM RFC Errata System <[email-masked]>
wrote:

> RFC7321 s4.3.2, says "The server SHOULD send the same header fields in
> response to a HEAD request as it would have sent if the request had been a
> GET".  I can't see any rationale for violating this SHOULD in the
> discussion in the GH issue which introduced the discrepancy in response
> code between GET and HEAD (https://github.com/ietf-wg-acme/acme/pull/371),
> thus (IMHO) it violates the tenets of a SHOULD, as "the full implications"
> do not appear to have "be[en] understood and carefully weighed before
> choosing a different course" (RFC2119, of course).
>
> Instructions:
> -------------
> _______________________________________________
> Acme mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/acme
>

---

From: Benjamin Kaduk <[email-masked]>
Date: Tue, 31 Mar 2020 17:11:19 -0700

That does seem quite likely, thanks for pointing it out, Roland.

With respect to the report itself (noting that the proposed change is from
"200 (OK)" to "204 (No Content)"), I note that the response status code is
not considered to be a "header field" and so the quoted text from RFC 7231
does not seem to directly apply.  Since HEAD is defined to not return any
body content, 204 does not convey any additional information, and 200 in
fact seems to be conventional.

While, I'm happy to ask for more discussion/confirmation on the httpbis WG
list if requested, it seems likely that this report is destined for status
"Rejected".  Does anyone disagree?

Thanks,

Ben