RFC Errata
Found 6 records.
Status: Verified (1)
RFC 7030, "Enrollment over Secure Transport", October 2013
Note: This RFC has been updated by RFC 8951, RFC 8996
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
Note: This RFC has been updated by RFC 8951, RFC 8996
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
Status: Held for Document Update (3)
RFC 7030, "Enrollment over Secure Transport", October 2013
Note: This RFC has been updated by RFC 8951, RFC 8996
Source of RFC: pkix (sec)
Errata ID: 4384
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Pierce Leonberger
Date Reported: 2015-06-02
Held for Document Update by: Roman Danyliw
Date Held: 2020-08-19
Section 4.5.2 says:
CsrAttrs ::= SEQUENCE SIZE (0..MAX) OF AttrOrOID
AttrOrOID ::= CHOICE (oid OBJECT IDENTIFIER, attribute Attribute }
Attribute { ATTRIBUTE:IOSet } ::= SEQUENCE {
type ATTRIBUTE.&id({IOSet}),
values SET SIZE(1..MAX) OF ATTRIBUTE.&Type({IOSet}{@type}) }
It should say:
AttrOrOID ::= CHOICE {
oid OBJECT IDENTIFIER,
attribute Attribute{YouNeedToDefineOrReferenceAnObjectSet}
}
Notes:
1. The AttrOrOID CHOICE was started with a '(' versus a '{'.
2. Attribute{} is a parameterized type and you are missing the parameter reference within the AttrOrOID CHOICE for "attribute".
3. You need to define or reference the object set to be used in #2.
Highly recommend you create an ASN.1 Module as part of this specification. This will make it clear which specifications (and the versions there of) you are importing types from (i.e. Attribute{}) and the tagging that should be used (module level). If you need to define a new object set for #3 then this new module would be the perfect home for it.
Errata ID: 5107
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Sean Turner
Date Reported: 2017-09-07
Held for Document Update by: Roman Danyliw
Date Held: 2020-08-19
Section 3.2.1 says:
It should say:
Add the following is as the last paragraph of Section 3.2.1: [RFC2616] indicates "HTTP does not use the Content-Transfer-Encoding (CTE) field of RFC 2045”; nevertheless, this document was published specifying the use of the Content-Transfer-Encoding header with a value of ‘base64' in Sections 4.1.3, 4.3.1, 4.3.2, 4.4.2, 4.5.2, as well as in the examples in Appendices A.1-A.4. As HTTP is binary-clean transport, there is no need to indicate this for HTTP-based protocols like EST. EST server implementations SHOULD omit the Content-Transfer-Encoding header if they know a priori that EST clients do not rely this field. EST Clients SHOULD expect that the Content-Transfer-Encoding header will be absent unless they have an a priori agreement with the EST server. The mechanism to establish this client dependency is out-of-scope.
Notes:
EST, which is an HTTP-based protocol, erroneous used CTE. This errata addresses this error.
Note that the text was reviewed by a RAI AD as well as multiple EST implementors.
Errata ID: 5108
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Sean Turner
Date Reported: 2017-09-07
Held for Document Update by: Roman Danyliw
Date Held: 2020-08-19
Section 4.2.3, 4.4.2 says:
OLD from s.4.2.3: If the content-type is not set, the response data MUST be a plaintext human-readable error message containing explanatory information describing why the request was rejected (for example, indicating that CSR attributes are incomplete). OLD from s4.4.2: If the content-type is not set, the response data MUST be a plaintext human-readable error message.
It should say:
NEW for s4.2.3: If the content-type is not set, the response data must be a plaintext human-readable error message containing explanatory information describing why the request was rejected (for example, indicating that CSR attributes are incomplete). Servers MAY use the "text/plain” content-type [RFC2046] for human-readable errors. NEW for s4.4.2: If the content-type is not set, the response data must be a plaintext human-readable error message. Servers MAY use the "text/plain” content-type [RFC2046] for human-readable errors.
Notes:
The current text is somewhat unclear as to what content-type needs to be used for the human-readable error. There are many human-readable content-types, but "text/plain" seems to be the most sensible.
Note that the MUST was reduced to a must because no content-type is specified.