Re: Certificate Transparency—basic support for the TLS extension?

Jamil Nimeh jamil.j.nimeh at oracle.com
Sat Mar 1 17:36:34 UTC 2025


Hello Ivan,

You bring up an interesting idea, and it comes at a good time because 
we've been going back and taking another look at CT and SunJSSE.  What 
you are suggesting would be a useful addition, and could also be a step 
towards a full implementation.  I have created 
https://bugs.openjdk.org/browse/JDK-8351001 to track this.  It will need 
a CSR if we decide to go the ExtendedSSLSession route as you were 
suggesting.

A question, since we're on the topic: Is there any value to separating 
out somehow 1.0 and 2.0 SCTs?  Or would a simple List<byte[]> that just 
contains each SCT be sufficient?

Thanks,

--Jamil

On 2/28/2025 12:35 AM, Ivan Ristic wrote:
> Hello group,
>
> From what I can tell, it's currently not possible to consume CT 
> information from Java reliably because there is no way to indicate 
> support for the CT TLS extension [1] in the handshake as well as get 
> the data sent back by a compatible server.
>
> The work involved would be small, for example just grab the raw data 
> and expose it via ExtendedSSLSession, in the same way stapled OCSP 
> responses are currently handled.
>
> However, the improvements would be significant, as this change would 
> enable Java applications to use CT if they so wish.
>
> Apologies as I am not familiar with how things are done; what's the 
> process to make this happen?
>
> [1] https://datatracker.ietf.org/doc/html/rfc6962#section-3.3
>
> -- 
> Ivan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/security-dev/attachments/20250301/5161f117/attachment-0001.htm>


More information about the security-dev mailing list