Since there is a conflict with deployments with extension code point 26 IANA has now assigned the compress_certificate extension code point 27 from the TLS extensionType values registry.
On Wed, May 23, 2018 at 6:23 PM, Sean Turner <s...@sn3rd.com> wrote: > IANA has assigned the following values: > > 1) In the ExtensionType Values registry, the following entry was added: > > 26 compress_certificate (TEMPORARY - registered 2018-05-23, expires > 2019-05-23) [draft-ietf-tls-certificate-compression] > > Please see > https://www.iana.org/assignments/tls-extensiontype-values > > 2) In the TLS HandshakeType Registry, the following entry was added: > > 25 compressed_certificate (TEMPORARY - registered 2018-05-23, expires > 2018-05-23) DTLS-OK: Y [draft-ietf-tls-certificate-compression] > > Please see > https://www.iana.org/assignments/tls-parameters > > > > NOTE: IANA can’t create the registry for the compression algorithms until > the document is approved by the IESG, but Ben (and the chairs) figured we > didn’t really need that to get this going. If additional compression > algorithms start to get used, let’s make sure to note what they are. > > spt > > >> From: Sean Turner <s...@sn3rd.com> > >> Subject: early code point assignment for draft-ietf-tls-certificate- > compression > >> Date: April 23, 2018 at 12:33:08 EDT > >> To: TLS WG <tls@ietf.org> > >> > >> All, > >> > >> tl;dr: If you object to the following early code point assignments 1) > add the compress_certificate in the TLS ExtensionType Registry and 2) > compressed_certificate in the TLS HandshakeType Registry, then please let > the list know why by 2359UTC on 10 May 2018. The Certificate Compression > Algorithm IDs will be populated with two values: zlib and brotli. > >> > >> At IETF101, we discussed beginning the process of getting an early code > point assignment for the extension defined in > draft-ietf-tls-certificate-compression. > The one technical comments raised at the meeting was extending the > compression code point space from 1 byte to 2 might be a good idea. The > authors have merged a PR to address this in the gh repo and once they > submit a new version of the draft the process for an early code point > assignment will begin. The rules for this are specified in RFC7120, and > the four criteria for a draft to be eligible for early code point > assignment are: > >> > >> Criteria A > >> > >> The code points must be from a space designated as "RFC > >> Required", "IETF Review", or "Standards Action". Additionally, > >> requests for early assignment of code points from a > >> "Specification Required" registry are allowed if the > >> specification will be published as an RFC. > >> > >> The Transport Layer Security (TLS) Extensions and TLS HandshakeType > Registry registries are both RFC Required. While we’re changing that > registry’s rules with draft-ietf-tls-iana-registry-updates, there’s still > every intention to publish draft-ietf-tls-certificate-compression as an > RFC so we’re still good to go. > >> > >> Criteria B > >> > >> The format, semantics, processing, and other rules related to > >> handling the protocol entities defined by the code points > >> (henceforth called "specifications") must be adequately described > >> in an Internet-Draft. > >> > >> When asked at IETF101 what other outstanding comments there were on the > draft the only one identified was increasing the code point size for the > compression algorithms. Version -05 will address this point. > >> > >> Criteria C > >> > >> The specifications of these code points must be stable; i.e., if > >> there is a change, implementations based on the earlier and later > >> specifications must be seamlessly interoperable. > >> > >> At IETF101, it was noted that this specification was stable enough. > Implementation issues might be identifier later, but, well, that’s the > point. > >> > >> Criteria D > >> > >> The Working Group chairs and Area Directors (ADs) judge that > >> there is sufficient interest in the community for early (pre-RFC) > >> implementation and deployment, or that failure to make an early > >> allocation might lead to contention for the code point in the > >> field. > >> > >> 5 WG participants all from different organizations indicated their > interest in implementing this draft (even if it was just for > experimentation). > >> > >> > >> There are also 6 steps identified in RFC 7120 for early assignment, but > only four involve the chairs: > >> > >> 1. The authors (editors) of the document submit a request for early > >> allocation to the Working Group chairs, specifying which code > >> points require early allocation and to which document they should > >> be assigned. > >> > >> An in-person request was made at IETF 101 for the early code point > assignments. There was also an earlier on-list request. > >> > >> 2. The WG chairs determine whether the conditions for early > >> allocations described in Section 2 are met, particularly > >> conditions (c) and (d). > >> > >> The chairs agree that the four conditions have been met. > >> > >> 3. The WG chairs gauge whether there is consensus within the WG that > >> early allocation is appropriate for the given document. > >> > >> The sense of the room at IETF 101 was that yes early allocation is > appropriate, but this email is verifying that. > >> > >> 4. If steps 2) and 3) are satisfied, the WG chairs request approval > >> from the Area Director(s). The Area Director(s) may apply > >> judgement to the request, especially if there is a risk of > >> registry depletion. > >> > >> Once the chairs have determined WG consensus, we’ll pass it to Ben. > >> > >> spt > > > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls >
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
