RFC 8879 has recently been published. The RFC describes a way to compress the TLS certificate chain when using TLS 1.3.

Compressing the certificate chain reduces the number of bytes exchanged during the handshake. While sending fewer bytes is always a win for performance, this becomes especially important for QUIC, where due to the lack of the TCP 3-way handshake, the server's first flight (which contains the certificate chain) is limited to 3x the number of bytes that it received from the client, see https://www.fastly.com/es/blog/quic-handshake-tls-compression-certificates-extension-study for real world data.

Since the Certificate message is encrypted in TLS 1.3, it is not possible to implement certificate compression without access to the keys derived during the handshake, i.e. outside of the standard library.

The RFC describes 3 different compression algorithms that TLS endpoints can advertise support for: zlib, zstd and brotli.

Chrome has had support for this extension since version 69 using the brotli algorithm: https://www.chromestatus.com/feature/5696925844111360.

Implementation-wise, there are a few options here:

1. Add support for zlib compression first. zlib is already a part of the standard library, so support could be added without any API changes to crypto/tls and without any changes outside of that package.
2. Also add support for brotli, to get the performance benefits when serving a Chrome client. brotli is not implemented in the standard library though. One could:
   1. include brotli in the standard library (either as an internal package, or an exposed package), then use it in crypto/tls
   2. define a callback for the tls.Config: GetCertificateCompressor(enum int) CertificateCompressor