<!DOCTYPE html><html><head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body>
<p>Hi Ivan,</p>
<p>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.<br>
</p>
<p>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.</p>
<p>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.<br>
</p>
<p>Thanks,</p>
<p>--Jamil<br>
</p>
<div class="moz-cite-prefix">On 3/4/2025 7:39 AM, Ivan Ristic wrote:<br>
</div>
<blockquote type="cite" cite="mid:CANHgQ8E4+aTL_bx-VG15gZMh0SbVnPuVsvwafdZNVUz4EL0KHQ@mail.gmail.com">
<div dir="ltr">Hi Jamil,
<div><br>
</div>
<div>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.</div>
<div><br>
</div>
<div>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.</div>
<div><br>
</div>
<div>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.)</div>
<div><br>
</div>
</div>
<br>
<div class="gmail_quote gmail_quote_container">
<div dir="ltr" class="gmail_attr">On Sat, Mar 1, 2025 at 5:43 PM
Jamil Nimeh <<a href="mailto:jamil.j.nimeh@oracle.com" moz-do-not-send="true" class="moz-txt-link-freetext">jamil.j.nimeh@oracle.com</a>>
wrote:<br>
</div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">
<div>
<p>Hello Ivan,</p>
<p>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 <a href="https://bugs.openjdk.org/browse/JDK-8351001" target="_blank" moz-do-not-send="true" class="moz-txt-link-freetext">https://bugs.openjdk.org/browse/JDK-8351001</a>
to track this. It will need a CSR if we decide to go the
ExtendedSSLSession route as you were suggesting.<br>
</p>
<p>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?</p>
<p>Thanks,</p>
<p>--Jamil<br>
</p>
<div>On 2/28/2025 12:35 AM, Ivan Ristic wrote:<br>
</div>
<blockquote type="cite">
<div dir="ltr">
<div>Hello group,</div>
<div><br>
</div>
<div>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.</div>
<div><br>
</div>
<div>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.</div>
<div><br>
</div>
<div>However, the improvements would be significant, as
this change would enable Java applications to use CT
if they so wish.</div>
<div><br>
</div>
<div>Apologies as I am not familiar with how things are
done; what's the process to make this happen?</div>
<div><br>
</div>
<div>[1] <a href="https://urldefense.com/v3/__https://datatracker.ietf.org/doc/html/rfc6962*section-3.3__;Iw!!ACWV5N9M2RV99hQ!KIjWS6IHmhoDGv9tfyCSWMgzO-npdeXAxxTQG_s33nlcSE-1pfSaJwn8VVfEWUCHr3yHRBCy0GRmUkTxqSBjvmSW$" target="_blank" moz-do-not-send="true">https://datatracker.ietf.org/doc/html/rfc6962#section-3.3</a><br clear="all">
</div>
<div><br>
</div>
<span class="gmail_signature_prefix">-- </span><br>
<div dir="ltr" class="gmail_signature">Ivan</div>
</div>
</blockquote>
</div>
</blockquote>
</div>
<div><br clear="all">
</div>
<div><br>
</div>
<span class="gmail_signature_prefix">-- </span><br>
<div dir="ltr" class="gmail_signature">Ivan</div>
</blockquote>
</body>
</html>