Draft: draft-ietf-tls-certificate-compression

Commentary: When running idnits , it reports a couple of issues : RFC1950 and RfC7932 are the zlib and brotli RFCs . I 'm guessing the way to fix this would to remove the related MUSTs and downgrade the references , though I have n't come up with appropriate wording yet . /cc ( any suggestion ? ) 
 fixes a couple more errors that are not listed here btw . 
 Note that downref " nits " can be handled via documented procedures in . In summary , we can identify them in the IETF LC ( when we get there ) and see who objects to referring to an informative RFC from this draft , which is intended for standards track . For zlib there are a ton of these already and it looks like somebody just did n't update the downref registry ( i.e. , I suspect there will be no strenuous objections from anybody ) . For brotli , it 's newer but I am not too worried about the uproar . I 'd just leave the MUST and the normative references in . 
 Ok , thanks I 'll close this then .
This document defines a new extension type
(compress_certificate(27)), 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
(I-D.ietf-tls-tls13, Section 4.1.2), 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.
This document defines a new extension type
(compress_certificate(27)), 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
(RFC8446, Section 4.1.2), it indicates the support for compressed
server certificates.  Whenever it is sent by the server as a
CertificateRequest extension (RFC8446, Section 4.3.2), it indicates
the support for compressed client certificates.
It's been observed that a significant number of middleboxes intercept
and try to validate the Certificate message exchanged during a TLS
handshake.  This means that middleboxes that don't understand the
CompressedCertificate message might misbehave and drop connections
that adopt certificate compression.  Because of that, the extension
is only supported in the versions of TLS where the certificate
message is encrypted in a way that prevents middleboxes from
intercepting it, that is, TLS version 1.3 I-D.ietf-tls-tls13 and
higher.
Create an entry, compress_certificate(27), in the existing registry
for ExtensionType (defined in I-D.ietf-tls-tls13), with "TLS 1.3"
column values being set to "CH, CR", and "Recommended" column being
set to "Yes".
Create an entry, compressed_certificate(25), in the existing registry
for HandshakeType (defined in RFC5246).
It's been observed that a significant number of middleboxes intercept
and try to validate the Certificate message exchanged during a TLS
handshake.  This means that middleboxes that don't understand the
CompressedCertificate message might misbehave and drop connections
that adopt certificate compression.  Because of that, the extension
is only supported in the versions of TLS where the certificate
message is encrypted in a way that prevents middleboxes from
intercepting it, that is, TLS version 1.3 RFC8446 and higher.
Create an entry, compress_certificate(27), in the existing registry
for ExtensionType (defined in RFC8446), with "TLS 1.3" column values
being set to "CH, CR", and "Recommended" column being set to "Yes".
Create an entry, compressed_certificate(25), in the existing registry
for HandshakeType (defined in RFC8446).