[Errata Verified] RFC7030 (5904)

RFC Errata System <[email protected]>
Newsgroups gmane.ietf.x509
Message-ID <[email protected]>
The following errata report has been verified for RFC7030,
"Enrollment over Secure Transport". 

--------------------------------------
You may review the report below and at:
https://www.rfc-editor.org/errata/eid5904

--------------------------------------
Status: Verified
Type: Technical

Reported by: Justin Cranford <[email protected]>
Date Reported: 2019-11-12
Verified by: Roman Danyliw (IESG)

Section: 4.1.3

Original Text
-------------
Content-Transfer-Encoding: base64

Corrected Text
--------------
Transfer-Encoding: base64

Notes
-----
Verifier Notes: Marked verified by the RFC Editor at the request of Roman Danyliw.
--------------------

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.

--------------------------------------
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
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.