On Wed, 28 Jan 2026 16:53:59 GMT, Artur Barashev <[email protected]> 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:[email protected]) on > [security-dev](mailto:[email protected]):_ > > On Tue, Jan 27, 2026 at 9:27?AM Artur Barashev <abarashev at openjdk.org> > wrote: > > > On Tue, 27 Jan 2026 16:54:28 GMT, Xue-Lei Andrew Fan <xuelei at openjdk.org> > > wrote: > > > > Artur Barashev has updated the pull request incrementally with one > > > > additional commit since the last revision: > > > > Allocate 24 bits for input size in cache key. Add unit tests. > > > > > > > > > src/java.base/share/classes/javax/net/ssl/SSLParameters.java line 982: > > > > 980: boolean enableCertificateCompression) { > > > > 981: this.enableCertificateCompression = > > > > enableCertificateCompression; > > > > 982: } > > > > > > > > > Is there a plan to support brotli compression algorithm in OpenJDK? It > > > is the only supported algorithm in browser Chrome. > > > If there is a need to support more than one compression algorithms in > > > the future, it might be better to provide an option to customize the > > > algorithms selection, including preferences. The flexibility could > > > provide > > > better interoperability if a vendor does not support compression algorithm > > > properly. > > > > > > 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. We may add support for more algorithms in > > the future, but for now it's zlib only. > > Once there is a need to support more algorithms, this API may not be > applicable for some cases especially when there are compatibility impact. It > might be good to consider the API to support multiple algorithms from day > zero. > > Just my $0.02. > > Thanks, Xuelei > > > Generally speaking, it's the certificate's metadata that is being > > compressed, the keys are high-entropy data difficult to compress. PQC > > certificates don?t compress well, most likely because of lower metadata to > > keys ratio. > > -------------- next part -------------- An HTML attachment was scrubbed... > URL: > <https://mail.openjdk.org/pipermail/security-dev/attachments/20260128/7e41c352/attachment.htm> I know original design had callback functions for custom deflators/inflators, but it was decided to support only internally implemented ZLIB for now. We may add callbacks at the later time if there is a demand for it. Current API only enables/disables the certificate compression overall, there shouldn't be any compatibly issues with future callback function mechanism if we decide to support it. ------------- PR Comment: https://git.openjdk.org/jdk/pull/28682#issuecomment-3812904883
