<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=windows-1250">
</head>
<body>
<div dir="ltr">
<div dir="ltr" style="color: rgb(0, 0, 0); background-color: rgb(255, 255, 255);">
Hello,</div>
<div dir="ltr" style="color: rgb(0, 0, 0); background-color: rgb(255, 255, 255);">
<br>
</div>
<div dir="ltr" style="color: rgb(0, 0, 0); background-color: rgb(255, 255, 255);">
For multiple connections session- or ticket reuse would be much more efficient. </div>
<div dir="ltr" style="color: rgb(0, 0, 0); background-color: rgb(255, 255, 255);">
<br>
</div>
<div dir="ltr" style="color: rgb(0, 0, 0); background-color: rgb(255, 255, 255);">
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.</div>
<div dir="ltr" style="color: rgb(0, 0, 0); background-color: rgb(255, 255, 255);">
<br>
</div>
<div dir="ltr" style="color: rgb(0, 0, 0); background-color: rgb(255, 255, 255);">
(But I recon that’s not for this list to discuss, it’s just an argument against implementing a draft standard)</div>
<div dir="ltr" style="color: rgb(0, 0, 0); background-color: rgb(255, 255, 255);">
<br>
</div>
<div dir="ltr" style="color: rgb(0, 0, 0); background-color: rgb(255, 255, 255);">
<br>
</div>
<div dir="ltr" style="color: rgb(0, 0, 0); background-color: rgb(255, 255, 255);">
Gruss</div>
<div dir="ltr" style="color: rgb(0, 0, 0); background-color: rgb(255, 255, 255);">
Bernd</div>
<div id="ms-outlook-mobile-signature">
<div style="direction:ltr">-- </div>
<div style="direction:ltr">http://bernd.eckenfels.net</div>
</div>
</div>
<hr style="display:inline-block;width:98%" tabindex="-1">
<div id="divRplyFwdMsg" dir="ltr"><font face="Calibri, sans-serif" style="font-size:11pt" color="#000000"><b>Von:</b> security-dev <security-dev-retn@openjdk.java.net> im Auftrag von Daniel Jeliñski <djelinski1@gmail.com><br>
<b>Gesendet:</b> Wednesday, April 13, 2022 10:01:29 PM<br>
<b>An:</b> xueleifan(XueleiFan) <xueleifan@tencent.com><br>
<b>Cc:</b> OpenJDK Dev list <security-dev@openjdk.java.net><br>
<b>Betreff:</b> Re: JEP Review Request: TLS Certificate Compression</font>
<div> </div>
</div>
<div class="BodyFragment"><font size="2"><span style="font-size:11pt;">
<div class="PlainText">I like the idea of implementing certificate compression. Only one<br>
concern: TLS handshakes are generally a CPU-intensive operation, and<br>
certificate compression / decompression will only make it worse. Will<br>
it be possible to compress a certificate once and use it across<br>
multiple handshakes? Decompression has to be performed every time,<br>
obviously.<br>
<br>
Regards,<br>
Daniel<br>
<br>
pon., 21 mar 2022 o 16:49 xueleifan(XueleiFan) <xueleifan@tencent.com><br>
napisa³(a):<br>
><br>
> Hi,<br>
><br>
><br>
> The JDK Enhancement Proposal, TLS Certificate Compression, has been opened for community review. Detailed, please refer to the draft:<br>
><br>
> <a href="https://bugs.openjdk.java.net/browse/JDK-8281710">https://bugs.openjdk.java.net/browse/JDK-8281710</a><br>
><br>
> and the discussion of this potential feature at security-dev:<br>
><br>
> <a href="https://mail.openjdk.java.net/pipermail/security-dev/2022-March/029242.html">
https://mail.openjdk.java.net/pipermail/security-dev/2022-March/029242.html</a><br>
><br>
><br>
> Please feel free to make comments and review the JEP.<br>
><br>
> Thanks,<br>
> Xuelei<br>
</div>
</span></font></div>
</body>
</html>