Original text:
3. This document defines a new extension type <del> (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. By sending the compress_certificates extension, the client indicates to the server the certificate compression algorithms it supports. The "extension_data" field of this extension in the ClientHello SHALL contain a CertificateCompressionAlgorithms value: 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. </del>  4. <del> 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 </del>  Certificate message). The CompressedCertificate message is formed as follows:  The length of the Certificate message once it is uncompressed.  If after decompression the specified length does not match the actual length, the party receiving the invalid message MUST abort the defines how the bytes in the compressed_certificate_message field are converted into the Certificate message. <del> 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 </del>  message MUST be compressed with the ZLIB compression algorithm, as <del> defined in RFC1950.  If the negotiated compression algorithm is </del>  brotli, the Certificate message MUST be compressed with the Brotli compression algorithm as defined in RFC7932. server_certificate_type extension RFC7250, the resulting altered message is compressed instead. <del> 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. </del> 5. After decompression, the Certificate message MUST be processed as if CompressedCertificate message might misbehave and drop connections that adopt certificate compression. <del> 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 </del>  the CompressedCertificate) message is encrypted, preventing middleboxes from intercepting it. 7.1. <del> Create an entry, compress_certificates(TBD), in the existing registry for ExtensionType (defined in RFC5246). </del>  7.2.

Reviewer comments:
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, added just a couple of small nits.
Looks good to me.

Revised text:
3. This document defines a new extension type  <ins> (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. By sending a compress_certificate extension, the sender indicates to the peer the certificate compression algorithms it is willing to use for decompression.  The "extension_data" field of this extension SHALL contain a CertificateCompressionAlgorithms value: There is no ServerHello extension that the server is required to echo back. </ins> 4.  <ins> 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 </ins> Certificate message). The CompressedCertificate message is formed as follows: <ins> The algorithm used to compress the certificate.  The algorithm MUST be one of the algorithms listed in the peer's compress_certificate message. </ins> The length of the Certificate message once it is uncompressed.  If after decompression the specified length does not match the actual length, the party receiving the invalid message MUST abort the defines how the bytes in the compressed_certificate_message field are converted into the Certificate message.  <ins> If the specified compression algorithm is zlib, then the Certificate </ins> message MUST be compressed with the ZLIB compression algorithm, as  <ins> defined in RFC1950.  If the specified compression algorithm is </ins> brotli, the Certificate message MUST be compressed with the Brotli compression algorithm as defined in RFC7932. server_certificate_type extension RFC7250, the resulting altered message is compressed instead.  5. After decompression, the Certificate message MUST be processed as if CompressedCertificate message might misbehave and drop connections that adopt certificate compression.  <ins> 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 </ins> the CompressedCertificate) message is encrypted, preventing middleboxes from intercepting it. 7.1.  <ins> 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". </ins> 7.2.