RFC Errata


Errata Search

 
Source of RFC  
Summary Table Full Records

Found 6 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

Status: Held for Document Update (3)

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

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.

Report New Errata