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
