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

[Ivan Ristic]

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.nimeh at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/security-dev/attachments/20250304/7e29e0d6/attachment.htm>