Re: [Technical Errata Reported] RFC7030 (5904)

Forwarding to the LAMPS WG list since the original seems to have not made
it into the PKIX archives.

-Ben

On Tue, Nov 12, 2019 at 12:48:40PM -0800, RFC Errata System wrote:
> The following errata report has been submitted for RFC7030,
> "Enrollment over Secure Transport".
> 
> --------------------------------------
> You may review the report below and at:
> https://www.rfc-editor.org/errata/eid5904
> 
> --------------------------------------
> Type: Technical
> Reported by: Justin Cranford <[email protected]>
> 
> Section: 4.1.3
> 
> Original Text
> -------------
> Content-Transfer-Encoding: base64
> 
> Corrected Text
> --------------
> Transfer-Encoding: base64
> 
> Notes
> -----
> Content-Transfer-Encoding is not a valid HTTP header. RFC 7030 is not compliant with RFC 2616.
> 
> - "MIME Content-Transfer-Encoding: base64" => Base64 Basic with CRLFs
> - "HTTP Transfer-Encoding: base64" => Base64 Basic without CRLFs
> 
> This is traceable from RFC 7030 (EST) through RFC 2818 (TLS) to RFC 2616 (HTTP).
> 
> - RFC 7030 (EST): EST specifies how to transfer messages securely via HTTP over TLS (HTTPS) [RFC2818]
> - RFC 2818 (TLS): HTTP [RFC2616] was originally used in the clear on the Internet.
> - RFC 2616 (HTTP): HTTP does not use the Content-Transfer-Encoding (CTE) field of RFC 2045.
> - RFC 2616 (HTTP): HTTP/1.1 introduces the Transfer-Encoding header field (section 14.41).
> 
> RFC 7030 sections affected are:
> 
> - All references to Content-Transfer-Encoding are not valid: Sections 4.1.3, 4.3.1, 4.3.2, 4.4.2, 4.5.2, A.1, A.2, A.3, and A.4.
> - All references to RFC 2045 are not valid: Sections 4.1.3, 4.3.1, 4.3.2, 4.4.2, 4.5.2, and 7.1.
> - All references to "base64" need to be updated or removed: Sections 3.5, 4.1.3, 4.3.1, 4.3.2, 4.4.2, 4.5.2, and 7.1.
> 
> RFC 7030 fix options:
> 
> Option #1: Change all references from Content-Transfer-Encoding to Transfer-Encoding. A caveat is that "base64" has a different meaning in HTTP (no CRLFs) vs MIME (includes CRLFs).
> 
> Option #2: Remove all references to Content-Transfer-Encoding and base64. Responses would be transmitted as binary. This allows the response to be transported more efficiently without base64 size bloat, and it allows optional use of Content-Length header so the response can be parsed more efficiently knowing the length ahead of time.
> 
> 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. 
> 
> --------------------------------------
> RFC7030 (draft-ietf-pkix-est-09)
> --------------------------------------
> Title               : Enrollment over Secure Transport
> Publication Date    : October 2013
> Author(s)           : M. Pritikin, Ed., P. Yee, Ed., D. Harkins, Ed.
> Category            : PROPOSED STANDARD
> Source              : Public-Key Infrastructure (X.509)
> Area                : Security
> Stream              : IETF
> Verifying Party     : IESG