I agree. From: Richard Barnes <[email protected]> Date: Tuesday, February 11, 2020 at 9:49 PM To: RFC Errata System <[email protected]> Cc: Jacob Hoffman-Andrews <[email protected]>, "[email protected]" <[email protected]>, James Kasten <[email protected]>, Roman Danyliw <[email protected]>, Benjamin Kaduk <[email protected]>, Rich Salz <[email protected]>, Yoav Nir <[email protected]>, "[email protected]" <[email protected]>, "[email protected]" <[email protected]> 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 <[email protected]<mailto:[email protected]>> 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 <[email protected]<mailto:[email protected]>> 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 [email protected] https://www.ietf.org/mailman/listinfo/acme
