TLS Certificate Compression
Extracted elements (23)
Certificate compression is limited to TLS 1.3+ specifically because middlebox interference is known to be widespread with older TLS versions. Only restricting to versions where the Certificate is encrypted avoids breaking deployments that have middleboxes performing certificate validation.
The compress_certificate extension is unidirectional: a node advertises what it can decompress, not what it will compress. No corresponding response extension is needed, keeping the negotiation asymmetric and simple.
The uncompressed_length field is included in CompressedCertificate to allow receivers to preallocate a buffer for the decompressed Certificate message and to enforce size limits before performing decompression, preventing decompression bomb attacks.
This mechanism complements RFC 7924 (TLS Cached Information Extension), which avoids retransmitting known certificates but does not help on first connection. Certificate compression reduces data on all handshakes, including first connections where the client has no prior knowledge of the server's certificate chain.
A significant number of middleboxes intercept and validate Certificate messages in TLS handshakes. CompressedCertificate messages may cause such middleboxes to drop connections. Certificate compression is therefore restricted to TLS 1.3 and higher, where the Certificate message is encrypted and cannot be intercepted.
If the format of the Certificate message is altered using the server_certificate_type or client_certificate_type extensions (RFC 7250), the resulting altered message is what is compressed, not the standard Certificate message format.
After decompression, the Certificate message MUST be processed as if it were encoded without being compressed, ensuring parsing and verification retain the same security properties as in standard TLS.
If after decompression the specified uncompressed_length does not match the actual decompressed length, the receiving party MUST abort the connection with the 'bad_certificate' alert.
If the received CompressedCertificate message cannot be decompressed, the connection MUST be terminated with the 'bad_certificate' alert.
If the specified compression algorithm is zlib, the Certificate message MUST be compressed with the ZLIB compression algorithm (RFC 1950); brotli uses the Brotli algorithm (RFC 7932); zstd uses the Zstandard algorithm (RFC 8478).
If TLS 1.2 or earlier is negotiated, peers MUST ignore the compress_certificate extension. The extension is only supported with TLS 1.3 and newer.
Implementations MUST limit the size of the resulting decompressed chain to the specified uncompressed_length and MUST abort the connection if the decompression output exceeds that limit. The TLS framing 16777216-byte ceiling applies; implementations MUST apply the same limit as if no compression were used.
Implementations SHOULD bound memory usage when decompressing the CompressedCertificate message to prevent resource exhaustion attacks.
Server and client MAY compress their Certificate messages and send them as CompressedCertificate, provided the peer has indicated support via the compress_certificate extension.
The algorithm field in CompressedCertificate MUST be one of the algorithms listed in the peer's compress_certificate extension.
A new TLS extension compress_certificate(27) signals the compression algorithms the sender is willing to use for decompressing Certificate messages. Sent in ClientHello to indicate support for compressed server certificates, or in CertificateRequest to indicate support for compressed client certificates.
IANA has registered compress_certificate(27) in the 'TLS ExtensionType Values' registry with TLS 1.3 column set to 'CH, CR' and Recommended set to 'Yes'.
IANA has registered compressed_certificate(25) in the 'TLS Handshake Type' registry with DTLS-OK set to 'Yes'.
This document establishes the 'TLS Certificate Compression Algorithm IDs' registry under 'Transport Layer Security (TLS) Extensions', with initial entries: 0 (Reserved), 1 (zlib), 2 (brotli), 3 (zstd), 16384-65535 (Reserved for Experimental Use). Allocation policy: IETF Review for values < 256, Specification Required for 256-16383, Experimental Use for 16384-65535.
Certificate compression alters the observable on-wire length of the Certificate message. Any padding scheme (per TLS 1.3 Sections 5.4 and E.3 of RFC 8446) that covers the Certificate message must account for compression within its design or disable compression altogether, as the length change depends on actual certificate contents.
The underlying compression algorithm MUST output the same data as provided by the peer; any deviation is a security violation. Since certificate chains are per-server-name or per-user, a malicious application cannot control individual Certificate message fragments and cannot leak information by modifying plaintext.
CertificateCompressionAlgorithms is a struct containing a list of CertificateCompressionAlgorithm enum values (zlib=1, brotli=2, zstd=3) encoded as a variable-length vector of 2 to 254 bytes (algorithms<2..2^8-2>).
CompressedCertificate message contains: algorithm (CertificateCompressionAlgorithm, 2 bytes), uncompressed_length (uint24, 3 bytes), and compressed_certificate_message (opaque variable-length field, 1 to 2^24-1 bytes). It replaces the Certificate message when compression is in use.