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

[Xue-Lei Andrew Fan]

On Thu, 29 Jan 2026 18:15:07 GMT, Artur Barashev <abarashev at openjdk.org> wrote:

>> src/java.base/share/classes/sun/security/ssl/CompressedCertificate.java line 148:
>> 
>>> 146:         // the deflated certificate data in a memory cache statically and avoid
>>> 147:         // compressing local certificates repeatedly for every handshake.
>>> 148:         private static final Cache<CompCertCacheKey, byte[]> CACHE =
>> 
>> I was just wondering about the multiple tenant systems, where one JVM may be used by multiple users with different key and certificates.  The system may run many weeks, and the tenants sign on and off, new and old tenants come in and out.  Will this CACHE keep the record for each key-cert for each tenant?  Could it be a potential problem?  Does it sound like a direction to cache the compressed certificate in where the certificate come from, for example key manager instance or SSLContext instance, without using static field?
>
> Yes, I'm actually currently thinking whether to attach this cache to SSLContext instance or not. Not sure about it. This cache implementation has LRU mechanism, so it will simply keep the last 12 compressed certs in memory which should be fine for most scenarios. It's also an easier to maintain code where we have all the pieces in a single file. Currently we have only session caches attached to SSLContext and quite a few static caches like this one in JSSE code.

I had a quick search of the existing cache.  There are some global cache for default security parameters and configuration.  For example, default trust anchor, default context and default managers.   I think it is fine as default one always use the same configuration and can be shared.

The compressed certificate cache looks different, as it is not for default key/cert configuration.  Basically, the identity certificate is a property of key manager. It may be safer to manage the cache in key manager level instances.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28682#discussion_r2747291754