Re: [Technical Errata Reported] RFC7030 (5107)
Sean Turner <[email protected]>
| Newsgroups | gmane.ietf.x509 |
|---|---|
| Message-ID | <[email protected]> |
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 protected]> 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 protected]> > > 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 _______________________________________________ pkix mailing list [email protected] https://www.ietf.org/mailman/listinfo/pkix