I agree.

From: Richard Barnes <r...@ipv.sx>
Date: Tuesday, February 11, 2020 at 9:49 PM
To: RFC Errata System <rfc-edi...@rfc-editor.org>
Cc: Jacob Hoffman-Andrews <j...@eff.org>, "c...@letsencrypt.org" 
<c...@letsencrypt.org>, James Kasten <jdkas...@umich.edu>, Roman Danyliw 
<r...@cert.org>, Benjamin Kaduk <ka...@mit.edu>, Rich Salz <rs...@akamai.com>, 
Yoav Nir <ynir.i...@gmail.com>, "jonat...@findmeon.com" 
<jonat...@findmeon.com>, "acme@ietf.org" <acme@ietf.org>
Subject: Re: [Technical Errata Reported] RFC8555 (5979)

ADs: This seems like a nice clarification, but not really an error.  Suggest 
HFDU.

On Tue, Feb 11, 2020 at 4:49 PM RFC Errata System 
<rfc-edi...@rfc-editor.org<mailto:rfc-edi...@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/eid5979<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.rfc-2Deditor.org_errata_eid5979&d=DwMFaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=4LM0GbR0h9Fvx86FtsKI-w&m=MMQj9_sfha5evr4GH273LeuhOmY6tvtBrC1WMtBe5IQ&s=xy31cbf-zGvz2x7X2PVMRXH5DbioSjZwYbPYLlytw3U&e=>

--------------------------------------
Type: Technical
Reported by: jonathan vanasco 
<jonat...@findmeon.com<mailto:jonat...@findmeon.com>>

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.

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

Reply via email to