Hi Jamil, Thanks for opening that ticket. I notice that the wording is generic to SCTs, which might indicate that you want to include the ones embedded in certificates and OCSP responses. Did you meant that? If so, they will absolutely need a wrapper to indicate the source. In that case, you must just as well include a version number so that the wrapper is generic and future-compatible.
It probably makes sense to include all SCTs because—I am guessing—it will not be possible for non-JDK code to observe OCSP responses that are not stapled by obtained as part of TLS auth? In this case the source would not be a stapled OCSP response, but one fetched directly from the responder. If we're talking only about the TLS extension, if you include the raw extension bytes they will contain the extension ID, which may be sufficient if CT 2.0 is ever implemented. (CT 2.0 uses the transparency_info extension.) On Sat, Mar 1, 2025 at 5:43 PM Jamil Nimeh <jamil.j.ni...@oracle.com> wrote: > 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 > > -- Ivan
