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

RFC Errata System <rfc-editor@rfc-editor.org> Mon, 24 February 2020 17:45 UTC

Return-Path: <wwwrun@rfc-editor.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 036713A0FA7; Mon, 24 Feb 2020 09:45:32 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
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 G0j6Lec1Yezx; Mon, 24 Feb 2020 09:45:30 -0800 (PST)
Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AA8913A0FA5; Mon, 24 Feb 2020 09:45:30 -0800 (PST)
Received: by rfc-editor.org (Postfix, from userid 30) id 49102F4071A; Mon, 24 Feb 2020 09:45:20 -0800 (PST)
To: jonathan@findmeon.com, rlb@ipv.sx, jsha@eff.org, cpu@letsencrypt.org, jdkasten@umich.edu
X-PHP-Originating-Script: 30:errata_mail_lib.php
From: RFC Errata System <rfc-editor@rfc-editor.org>
Cc: kaduk@mit.edu, iesg@ietf.org, acme@ietf.org, rfc-editor@rfc-editor.org
Content-Type: text/plain; charset="UTF-8"
Message-Id: <20200224174520.49102F4071A@rfc-editor.org>
Date: Mon, 24 Feb 2020 09:45:20 -0800
Archived-At: <https://mailarchive.ietf.org/arch/msg/acme/Ne9Gmkl2xyfnb8rZngg9YedY0SU>
Subject: [Acme] [Errata Held for Document Update] RFC8555 (5979)
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: Mon, 24 Feb 2020 17:45:32 -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:
https://www.rfc-editor.org/errata/eid5979

--------------------------------------
Status: Held for Document Update
Type: Technical

Reported by: jonathan vanasco <jonathan@findmeon.com>
Date Reported: 2020-02-11
Held by: Benjamin Kaduk (IESG)

Section: 7.4

Original Text
-------------
 If the server is willing to issue the requested certificate, it
   responds with a 201 (Created) response.  The body of this response is
   an order object reflecting the client's request and any
   authorizations the client must complete before the certificate will
   be issued.



Corrected Text
--------------
 If the server is willing to issue the requested certificate, it
   responds with a 201 (Created) response.  The body of this response is
   an order object reflecting the client's request and any
   authorizations the client must complete before the certificate will
   be issued. The server returns an order URL in a Location header field.


Notes
-----
The RFC does not specify/require where the "order URL" is presented.  The RFC is very explicit about where other URLs are obtained, and the common understanding is that the URL appears in a Location header after a new-order. 

For example: 

In 7.3; 7.3.1; 7.3.5, the RFC explicitly declares the account URL is in the Location header field.

In 7.4.1 the RFC is explicit that authorization URLs in pre-authorization appear in the Location header field.

But the order URL is only mentioned by example:

In 7.4, the RFC illustrates the order URL appearing in the Location header field (All clients seem to implement this).  In 7.1, the RFC shows a table with "a typical sequence of requests" that note the "account" and "order" URLs appear in the location header field.

The specification should state something to the effect of "The server returns an order URL in a Location header field." making this functionality explicit.

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