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

[Jamil Nimeh]

Hi Ivan,

Thanks for the feedback.  Yes, it was my intent to include extensions 
that come in from all potential sources, be it via the hello extension, 
embedded in certs, or via OCSP responses.  The source did seem 
important.  And I did want to be sensitive to 1.0 and 2.0 formats since 
both are in RFC form, not drafts.  Or at least design things with 
forward compatibility in mind.

I had one other question in going through both RFCs (6962 and 9162).  
Both of those specifications seem to focus on the end-entity TLS 
certificate.  In looking at the CAB baseline requirements, it appears 
that signed certificate timestamp lists can exist in subordinate CA 
certificates too.  I just don't know how common that is, since it is a 
"MAY" in the baseline requirements.  So I'm wondering if it will be 
helpful in presenting to the Java consumer the list of SCTs also grouped 
by certificate in some fashion.  Do you think that would be helpful? It 
could be simply ordered in the same ordering as the chain is presented, 
or it could be ordered by X509Certificate or maybe a certificate hash.  
Not sure.  I would love to hear your thoughts on that.

I wasn't thinking along the lines of including the raw extension bytes.  
That certainly would be one way to expose 1.0 vs. 2.0, but there may be 
other ways to present the data to the user that lessens the work on the 
user's side in terms of parsing the data. I'm still chewing on that one 
because presenting the SCTs as objects rather than opaque byte arrays 
means a larger API change. But I'm also looking at how much we can pave 
the way with this RFE towards a full implementation in the future.  The 
CSR would be explicit about all of these public, API changes and while 
in draft form there can be discussion and changes/improvements to any 
proposed API.

Thanks,

--Jamil

On 3/4/2025 7:39 AM, Ivan Ristic wrote:
> 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
>>     <https://urldefense.com/v3/__https://datatracker.ietf.org/doc/html/rfc6962*section-3.3__;Iw!!ACWV5N9M2RV99hQ!KIjWS6IHmhoDGv9tfyCSWMgzO-npdeXAxxTQG_s33nlcSE-1pfSaJwn8VVfEWUCHr3yHRBCy0GRmUkTxqSBjvmSW$>
>>
>>     -- 
>>     Ivan
>
>
>
> -- 
> Ivan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/security-dev/attachments/20250304/de431b80/attachment-0001.htm>