Re: [Technical Errata Reported] RFC7030 (5904)
Sean Turner <[email protected]>
| Newsgroups | gmane.ietf.x509 |
|---|---|
| Message-ID | <[email protected]> |
So there was this errata filed way back in 2013 when EST Extensions (RFC 8295) was working its way through the IESG, i.e., this addressed a directorate review and a discuss held by Alexey: https://www.rfc-editor.org/errata/eid5107 Does errata 5107 not address the same issue? spt > On Mar 30, 2020, at 10:52, Benjamin Kaduk <[email protected]> wrote: > > 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 > > _______________________________________________ > pkix mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/pkix