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

Note: This RFC has been updated by RFC 8951, RFC 8996

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.

Report New Errata