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
