Subject: [TLS] [Technical Errata Reported] RFC7250 (5013)

From: RFC Errata System <[email-masked]>
Date: Tue, 9 May 2017 23:45:22 -0700 (PDT)

The following errata report has been submitted for RFC7250,
"Using Raw Public Keys in Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS)".

--------------------------------------
You may review the report below and at:
http://www.rfc-editor.org/errata/eid5013

--------------------------------------
Type: Technical
Reported by: i <[email-masked]>

Section: 7

Original Text
-------------
   IANA has allocated two new TLS extensions, client_certificate_type
   and server_certificate_type, from the "TLS ExtensionType Values"
   subregistry defined in [RFC5246].

Corrected Text
--------------
   IANA has allocated two new code points, 19 (0x13) and 20 (0x14), for
   client_certificate_type and server_certificate_type, respectively,
   in the "TLS ExtensionType Values" subregistry defined in [RFC5246].

Notes
-----

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. 

--------------------------------------
RFC7250 (draft-ietf-tls-oob-pubkey-11)
--------------------------------------
Title               : Using Raw Public Keys in Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS)
Publication Date    : June 2014
Author(s)           : P. Wouters, Ed., H. Tschofenig, Ed., J. Gilmore, S. Weiler, T. Kivinen
Category            : PROPOSED STANDARD
Source              : Transport Layer Security
Area                : Security
Stream              : IETF
Verifying Party     : IESG

---

From: Sean Turner <[email-masked]>
Date: Wed, 10 May 2017 09:42:07 -0400

I would definitively re-categorize this “editorial”; there’s no 2119-changes proposed and there’s no bits on the wire changes.  And, I’d either reject this one because technically the existing text is correct (i.e., they are two extensions) and this really ought not of caused an interoperability problem or mark it HFDU (hold for document update).  The new text does include the code points, but those can be obtained from the registry and don’t absolutely have to be included.

spt

> On May 10, 2017, at 02:45, RFC Errata System <[email-masked]> wrote:
>

---

From: Paul Wouters <[email-masked]>
Date: Wed, 10 May 2017 09:51:05 -0400 (EDT)

> I would definitively re-categorize this “editorial”; there’s no 2119-changes proposed and there’s no bits on the wire changes.  And, I’d either reject this one because technically the existing text…

Sounds right to me.

Paul

---

From: John Gilmore <[email-masked]>
Date: Wed, 10 May 2017 13:15:55 -0700

I agree that the erratum is an editorial, not technical, change.

It is a slight improvement on the current wording, but is in no way
required for interoperability, since the same information is available
at the source already cited in the paragraph (the TLS ExtensionType
Values subregistry at IANA).

I recommend that we keep it in the editorial queue for folding
in if/when the RFC is ever revised for other reasons.

	John