Draft: draft-ietf-tls-certificate-compression

Commentary: This allows for stateless parsers to easily understand the contents of the message without having to keep track of the handshake state . This also decouples client and server compression parameters , allowing compression being negotiated in only one direction . 
 LGTM , just a couple of small nits . 
 Looks good to me .
This document defines a new extension type
(compress_certificates(TBD)), which is used by the client and the
server to negotiate the use of compression for their certificate
chains, as well as the choice of the compression algorithm.
If the server supports any of the algorithms offered in the
ClientHello, it MAY respond with an extension indicating which
compression algorithm it chose.  In that case, the "extension_data"
SHALL be a CertificateCompressionAlgorithm value corresponding to the
chosen algorithm.  If the server has chosen to not use any
compression, it MUST NOT send the compress_certificates extension.
If a compression algorithm has been negotiated, server and client MAY
compress their corresponding Certificate messages and send them in
the form of the CompressedCertificate message (replacing the
Certificate message).
This document defines a new extension type
(compress_certificate(TBD)), which can be used to signal the
supported compression formats for the Certificate message to the
peer.  Whenever it is sent by the client as a ClientHello message
extension (RFC5246, Section 7.4.1.4), it indicates the support for
compressed server certificates.  Whenever it is sent by the server as
a CertificateRequest extension (I-D.ietf-tls-tls13, Section 4.3.2),
it indicates the support for compressed client certificates.  Note
that CertificateRequest messages are not supported by TLS versions
prior to 1.3.
There is no ServerHello extension that the server is required to echo
back.
If the peer has indicated that it supports compression, server and
client MAY compress their corresponding Certificate messages and send
them in the form of the CompressedCertificate message (replacing the
Certificate message).
The algorithm used to compress the certificate.  The algorithm
MUST be one of the algorithms listed in the peer's
compress_certificate message.
A peer is not required to compress their own Certificate messages
even if the compress_certficates extension has been negotiated, but
MUST be able to decompress a received CompressedCertificate message.
If the negotiated compression algorithm is zlib, then the Certificate
message MUST be compressed with the ZLIB compression algorithm, as
defined in RFC1950.  If the negotiated compression algorithm is
brotli, the Certificate message MUST be compressed with the Brotli
compression algorithm as defined in RFC7932.
If the specified compression algorithm is zlib, then the Certificate
message MUST be compressed with the ZLIB compression algorithm, as
defined in RFC1950.  If the specified compression algorithm is
brotli, the Certificate message MUST be compressed with the Brotli
compression algorithm as defined in RFC7932.
If the server chooses to use the cached_info extension RFC7924 to
replace the Certificate message with a hash, it MUST NOT send the
compress_certificates extension.
However this is not a problem when using TLS version 1.3 [draft-ietf-
tls-tls13] and higher, due to the fact that the Certificate (and thus
the CompressedCertificate) message is encrypted, preventing
middleboxes from intercepting it.
However this is not a problem when using TLS version 1.3 I-D.ietf-
tls-tls13 and higher, due to the fact that the Certificate (and thus
the CompressedCertificate) message is encrypted, preventing
middleboxes from intercepting it.
Create an entry, compress_certificates(TBD), in the existing registry
for ExtensionType (defined in RFC5246).
Create an entry, compress_certificate(TBD), in the existing registry
for ExtensionType (defined in I-D.ietf-tls-tls13), with "TLS 1.3"
column values being set to "CH, CR".