Hello, For multiple connections session- or ticket reuse would be much more efficient.
In fact I think cert compression looks like the wrong solution. Having a immutable certificate download Chain would be a cool alternative solution - especially with future large postquantumcrypto certificates. That’s also easy to cache. (But I recon that’s not for this list to discuss, it’s just an argument against implementing a draft standard) Gruss Bernd -- http://bernd.eckenfels.net ________________________________ Von: security-dev <security-dev-r...@openjdk.java.net> im Auftrag von Daniel Jeliński <djelins...@gmail.com> Gesendet: Wednesday, April 13, 2022 10:01:29 PM An: xueleifan(XueleiFan) <xuelei...@tencent.com> Cc: OpenJDK Dev list <security-dev@openjdk.java.net> Betreff: Re: JEP Review Request: TLS Certificate Compression I like the idea of implementing certificate compression. Only one concern: TLS handshakes are generally a CPU-intensive operation, and certificate compression / decompression will only make it worse. Will it be possible to compress a certificate once and use it across multiple handshakes? Decompression has to be performed every time, obviously. Regards, Daniel pon., 21 mar 2022 o 16:49 xueleifan(XueleiFan) <xuelei...@tencent.com> napisał(a): > > Hi, > > > The JDK Enhancement Proposal, TLS Certificate Compression, has been opened > for community review. Detailed, please refer to the draft: > > https://bugs.openjdk.java.net/browse/JDK-8281710 > > and the discussion of this potential feature at security-dev: > > > https://mail.openjdk.java.net/pipermail/security-dev/2022-March/029242.html > > > Please feel free to make comments and review the JEP. > > Thanks, > Xuelei
