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