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
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
>
> --
> Type: Technical
> Reported by: jonathan vanasco
>
> 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
