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

From: Sean Turner <[email-masked]>
Date: Thu, 7 Sep 2017 16:39:50 -0400

Note that this issue was discovered during IESG review of draft-turner-est-extensions.  Alexey, Panos, Dan, Max, and myself worked on the wording.  I’m hoping it can stew for a couple of days and then be marked as accepted.

spt

> On Sep 7, 2017, at 16:16, RFC Errata System <[email-masked]> wrote:
> 
> The following errata report has been submitted for RFC7030,
> "Enrollment over Secure Transport".
> 
> --------------------------------------
> You may review the report below and at:
> http://www.rfc-editor.org/errata/eid5107
> 
> --------------------------------------
> Type: Technical
> Reported by: Sean Turner <[email-masked]>
> 
> Section: 3.2.1
> 
> Original Text
> -------------
> 
> 
> Corrected Text
> --------------
> 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.
> 
> 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