RFC Errata


Errata Search

 
Source of RFC  
Summary Table Full Records

Found 3 records.

Status: Verified (1)

RFC 7030, "Enrollment over Secure Transport", October 2013

Source of RFC: pkix (sec)

Errata ID: 5904
Status: Verified
Type: Technical
Publication Format(s) : TEXT

Reported By: Justin Cranford
Date Reported: 2019-11-12
Verifier Name: Roman Danyliw
Date Verified: 2020-11-13

Section 4.1.3 says:

Content-Transfer-Encoding: base64

It should say:

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.

Status: Reported (2)

RFC 7030, "Enrollment over Secure Transport", October 2013

Source of RFC: pkix (sec)

Errata ID: 5926
Status: Reported
Type: Technical
Publication Format(s) : TEXT

Reported By: Justin Cranford
Date Reported: 2019-12-03

Section A.1 to A.4 says:

   HTTP/1.1 200 OK
   Status: 200 OK
   Content-Type: application/pkcs7-mime
   Content-Transfer-Encoding: base64
   Content-Length: 4246

It should say:

   HTTP/1.1 200 OK
   Status: 200 OK
   Content-Type: application/pkcs7-mime
   Transfer-Encoding: base64

Notes:

EST examples in appendix A.1 through A.4 have incorrect "Content-Length". That header is mutually exclusive with "Transfer-Encoding" according to HTTP 1.1 RFC 2616. If a clients receives both headers, "Transfer-Encoding" header takes precedence and the erroneous "Content-Length" header must be ignored.

HTTP 1.1 RFC 2616 Section 4.4 (https://tools.ietf.org/html/rfc2616#section-4.4)

3.If a Content-Length header field (section 14.13) is present, its
decimal value in OCTETs represents both the entity-length and the
transfer-length. The Content-Length header field MUST NOT be sent
if these two lengths are different (i.e., if a Transfer-Encoding
header field is present). If a message is received with both a
Transfer-Encoding header field and a Content-Length header field,
the latter MUST be ignored.


EST RFC 7030 is non-compliant with HTTP 1.1 RFC 2616.

Please remove erroneous "Content-Length" header from all affected EST response examples in Appendixes A.1 through to A.4. This is incorrect and misleading.

Please make this fix at same time the erroneous "Content-Transfer-Encoding" header is corrected to be "Transfer-Encoding", as reported in a different errata.

Errata ID: 5779
Status: Reported
Type: Editorial
Publication Format(s) : TEXT

Reported By: Simon Edänge
Date Reported: 2019-07-13

Section A.4 says:

 Because the DecryptKeyIdentifier attribute is not included in this
   request, the response does not include additional encryption beyond
   the TLS session.  The EST server response is:

   HTTP/1.1 200 OK
   Status: 200 OK
   Content-Type: multipart/mixed ; boundary=estServerExampleBoundary
   Content-Length: 3219

   This is the preamble.  It is to be ignored, though it
   is a handy place for estServer to include an explanatory note,
   including contact or support information.
   --estServerExampleBoundary
   Content-Type: application/pkcs8
   Content-Transfer-Encoding: base64

It should say:

 Because the DecryptKeyIdentifier attribute is not included in this
   request, the response does not include additional encryption beyond
   the TLS session.  The EST server response is:

   HTTP/1.1 200 OK
   Status: 200 OK
   Content-Type: multipart/mixed; boundary=estServerExampleBoundary
   Content-Length: 3219

   This is the preamble.  It is to be ignored, though it
   is a handy place for estServer to include an explanatory note,
   including contact or support information.
   --estServerExampleBoundary
   Content-Type: application/pkcs8
   Content-Transfer-Encoding: base64

Notes:

Content-Type: multipart/mixed ; boundary=estServerExampleBoundary

The ; has a space, believe it or not, we implemented it that way.

Content-Type: multipart/mixed; boundary=estServerExampleBoundary

Report New Errata