Subject: Re: [pkix] [Technical Errata Reported] RFC7030 (5904)

From: Benjamin Kaduk <[email-masked]>
Date: Mon, 30 Mar 2020 07:52:29 -0700

Forwarding to the LAMPS WG list since the original seems to have not made
it into the PKIX archives.

-Ben

On Tue, Nov 12, 2019 at 12:48:40PM -0800, RFC Errata System wrote:
> The following errata report has been submitted for RFC7030,
> "Enrollment over Secure Transport".
> 
> --------------------------------------
> You may review the report below and at:
> https://www.rfc-editor.org/errata/eid5904
> 
> --------------------------------------
> Type: Technical
> Reported by: Justin Cranford <[email-masked]>
> 
> Section: 4.1.3
> 
> Original Text
> -------------
> Content-Transfer-Encoding: base64
> 
> Corrected Text
> --------------
> Transfer-Encoding: base64
> 
> Notes
> -----
> 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.
> 
> Instructions:
> -------------
> This erratum is currently posted as "Reported". If necessary, please
> use "Reply All" to discuss whether it should be verified or
> rejected. When a decision is reached, the verifying party  
> can log in to change the status and edit the report, if necessary. 
> 
> --------------------------------------
> 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
> Verifying Party     : IESG

---

From: Eliot Lear <[email-masked]>
Date: Mon, 30 Mar 2020 17:14:16 +0200

> On 30 Mar 2020, at 16:52, Benjamin Kaduk <[email-masked]> wrote:
> 

For interoperability purposes in the erratum, we might advise that both should be tolerated, but one needs to be preferred.  Adding Max, Michael, Stefan, and Panos who have implemented, for discussion.

>> 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…

If this is the direction, then I would hold for update because more work would need to be done, and it would not be interoperable with existing implementations.

Elio

---

From: Michael Richardson <[email-masked]>
Date: Mon, 30 Mar 2020 13:27:58 -0400

Eliot Lear <[email-masked]> wrote:
    >> 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).

    > For interoperability purposes in the erratum, we might advise that both
    > should be tolerated, but one needs to be preferred.  Adding Max,
    > Michael, Stefan, and Panos who have implemented, for discussion.

Unless someone with a deployed product comes forward claiming that they
accept non-base64 encoded content when there is no CTE header *AND* they have
interoperated with some other product, then the feedback from implementers
that I was able to reach last spring is that they:
  1) didn't insert CTE, (and ignored it), because it was junk.
  2) base64 encoded all content.

Changing it to Transfer-Encoding does not make sense.

{This is in the archives somewhere}

    >> 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.
    >>

    > If this is the direction, then I would hold for update because more
    > work would need to be done, and it would not be interoperable with
    > existing implementations.

This would be an incompatible change on the wire.

--
Michael Richardson <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-