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.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
<https://urldefense.com/v3/__https://datatracker.ietf.org/doc/html/rfc6962*section-3.3__;Iw!!ACWV5N9M2RV99hQ!KIjWS6IHmhoDGv9tfyCSWMgzO-npdeXAxxTQG_s33nlcSE-1pfSaJwn8VVfEWUCHr3yHRBCy0GRmUkTxqSBjvmSW$>
--
Ivan
--
Ivan
