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

Roland Shoemaker <roland@letsencrypt.org> Thu, 26 March 2020 04:03 UTC

Return-Path: <roland@letsencrypt.org>
X-Original-To: acme@ietfa.amsl.com
Delivered-To: acme@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 297A83A0755 for <acme@ietfa.amsl.com>; Wed, 25 Mar 2020 21:03:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.099
X-Spam-Level:
X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=letsencrypt.org
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cpvdOsrt5N_7 for <acme@ietfa.amsl.com>; Wed, 25 Mar 2020 21:03:36 -0700 (PDT)
Received: from mail-wr1-x42b.google.com (mail-wr1-x42b.google.com [IPv6:2a00:1450:4864:20::42b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7D5AB3A0418 for <acme@ietf.org>; Wed, 25 Mar 2020 21:03:35 -0700 (PDT)
Received: by mail-wr1-x42b.google.com with SMTP id t7so6037670wrw.12 for <acme@ietf.org>; Wed, 25 Mar 2020 21:03:35 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=letsencrypt.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=riag23aS8CNnwzG0IVOd7FwrabAD5Jg83acLel4zwT4=; b=AS2PxCpJ0E08tuZuHqwyjNaXbyhe2h14Q+50P02NdweY+yOm9YU4/ADAmqRGC1sCuG Ez0TZ+7WHq0D33SpBCYbRA4QZcElZglRdJN+avzVYqFvy6DL+mJbO0DgjNTjFF6EcuUv jF5K7PrRK+7+WMNykp1dT4F3idRsPPr9PdC9Q=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=riag23aS8CNnwzG0IVOd7FwrabAD5Jg83acLel4zwT4=; b=j15q10J+jW0sCaC84tG6PeeM0J1soP1MALTpIFb6J5pq5i0zXdyv1aBnesTrxVeDf/ 9iW5+0cF3Y1vj2WENUb4xqlwIA1MAlV7Z5IpmFjvAnVhlyh9TSjXaJfLNmbjZE/y0qMN gfIbqkfgEGd/GNB2aBdFeq1R84GLy177jthUVU81PM4GVrVkjs6UAumQBIr1kmB1gI1W VZ8agiUwseGTQqwvx+spmhDuN/DMY9b47XFEEplwPipDgbW4LygLotn0X0cERP8JXG6T IybANG/m2Uw3c+d/frlAMdmP+0Ll1zG9VaXsD98PZOnz9D/T8yZjdD4Mq0Sm1TuH9tEF vh+w==
X-Gm-Message-State: ANhLgQ0ubLIBeYOlniat6AMtmIjerP92oGxR7gwJM9cMWGCM1VNdIJ5B vhrpJTv3JUlP8j+TnxWNbWafIw16Ve148Pf4SjYjSQ==
X-Google-Smtp-Source: ADFU+vt40ny6vimnYiUsFy/rjrlDpyzOYRlaij/CGSPpFaNAR2ebD1SUZd2I3RpH5z7c73uVsHKBaOkRx1YjEf2L800=
X-Received: by 2002:a5d:604a:: with SMTP id j10mr6787168wrt.126.1585195413901; Wed, 25 Mar 2020 21:03:33 -0700 (PDT)
MIME-Version: 1.0
References: <20200325222557.82D38F406F7@rfc-editor.org>
In-Reply-To: <20200325222557.82D38F406F7@rfc-editor.org>
From: Roland Shoemaker <roland@letsencrypt.org>
Date: Wed, 25 Mar 2020 21:03:23 -0700
Message-ID: <CAF1ySfHbh8JdBVev4PoZ8qYFiBAJETJigjchBK7etE7trM9_0A@mail.gmail.com>
To: RFC Errata System <rfc-editor@rfc-editor.org>
Cc: Richard Barnes <rlb@ipv.sx>, Jacob Hoffman-Andrews <jsha@eff.org>, Daniel McCarney <cpu@letsencrypt.org>, James Kasten <jdkasten@umich.edu>, Roman Danyliw <rdd@cert.org>, Benjamin Kaduk <kaduk@mit.edu>, "Salz, Rich" <rsalz@akamai.com>, Yoav Nir <ynir.ietf@gmail.com>, mp+ietf@hezmatt.org, IETF ACME <acme@ietf.org>
Content-Type: multipart/alternative; boundary="0000000000008bb31205a1ba1149"
Archived-At: <https://mailarchive.ietf.org/arch/msg/acme/otWBoIWKcYC2WjfbW48eZ59rXm0>
X-Mailman-Approved-At: Thu, 26 Mar 2020 06:28:08 -0700
Subject: Re: [Acme] [Technical Errata Reported] RFC8555 (6030)
X-BeenThere: acme@ietf.org
X-Mailman-Version: 2.1.29
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, 26 Mar 2020 04:03:39 -0000

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 <rfc-editor@rfc-editor.org>
wrote:

> 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 <mp+ietf@hezmatt.org>
>
> 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
>
> _______________________________________________
> Acme mailing list
> Acme@ietf.org
> https://www.ietf.org/mailman/listinfo/acme
>