1.Summary
Sean Turner is the document shepherd.
Ben Kaduk is the very responsible Area Director.
This draft defines a TLS extension to compress certificate chains to reduce the
amount of data transmitted and avoid some round trips. The compression
algorithms defined, zlib, brotli, and zstd, are all documented in RFCs.
The draft is intended for standards track; the WG supports this track as well
as marking to Recommended column “Yes”.
2. Review and Consensus
This draft has been around for roughly two years though the idea has been
around longer because certificates are a large part of the TLS handshake
messages. The authors have presented this draft at numerous TLS WG meetings.
There were no WGLC comments received, but this is due to the draft being stable
for a while (early IANA code points were requested on 2018-05-23). The only
major change introduced since then was the addition of zstd, which was itself
published in October 2018.
There were no major sources of conflict for this draft.
Google, Cloudflare, Apple, and FaceBook [0] have implemented this extension.
Firefox has also indicated they intend to prototype it. It should also be
noted that others. eg., the EMU WG, are interested in this feature.
[0] https://mailarchive.ietf.org/arch/msg/tls/idYj6mgvrlYBbdSfAOcw19pOv4A
3. Intellectual Property
I have confirmed with each author that to their direct, personal knowledge any
IPR related to this document has already been disclosed.
4. Other Points
4.1. DOWNREFS!!!
The draft includes three downrefs:
** Downref: Normative reference to an Informational RFC: RFC 1950
** Downref: Normative reference to an Informational RFC: RFC 7932
** Downref: Normative reference to an Informational RFC: RFC 8478
NOTE: I have no idea why RFC 1950 is not in the downref registry - it’s been
normatively referred to by a bunch of standards track RFCs:
https://datatracker.ietf.org/doc/rfc1950/referencedby/
4.2. IANA Considerations
As noted earlier, an early code point assignments were made for both the
extension codepoint and for the handshake message type. The compression
algorithms listed in 7.3 are all well known and documented in RFCs. The DEs
for the specification required rules are the same as they are for the rest of
the TLS registries. The DE procedures are as noted in RFC 8447.