RFR: 8372526: Add support for ZLIB TLS Certificate Compression [v10]

[Artur Barashev]

On Wed, 28 Jan 2026 16:53:59 GMT, Artur Barashev <abarashev at openjdk.org> wrote:

>> Implement certificate compression in TLS 1.3 using internally supported ZLIB compression algorithm. See RFC 8879 for more details:
>> https://datatracker.ietf.org/doc/html/rfc8879
>
> Artur Barashev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Force cache limit per compression algorithm

> _Mailing list message from [Xuelei Fan](mailto:xuelei.f at gmail.com) on [security-dev](mailto:security-dev at mail.openjdk.org):_
> 
> > > Yes, strangely Chrome supports only brotli although I didn't see any
> > > difference in compression ration between zlib and brotli when manually
> > > testing certificate compression.
> 
> Did you have a chance to compress certification path with multiple certificates? It is said Brotli has better ratio.
> 
> It is said decompression is fas for Brotli. An entry may cache certificate compression and thus decompression performance could play a role for the algorithm selection in practice.
> 
> Xuelei
> 
> > 
> 
> -------------- next part -------------- An HTML attachment was scrubbed... URL: <https://mail.openjdk.org/pipermail/security-dev/attachments/20260128/82032b40/attachment.htm>

- Yes, I tested 3-certificate "EC" and "ML-DSA" chains in DER format. There is no significant difference with default compression settings between gzip and brotli:
   -  1771  EC_chain.der
   -  1029  EC_chain.der.br
   -  1006  EC_chain.der.gz
   - 16992  ML-DSA_chain.der
   - 16487  ML-DSA_chain.der.br
   - 16555  ML-DSA_chain.der.gz
- Decompression is generally much faster than compression for any algorithm, so while brotli decompression is faster than ZLIB it's not going to be a major performance factor.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/28682#issuecomment-3812856696