Yes, the source is important as different policy rules can apply, depending on the source.
I think that, if aiming for a complete SCT support, it would be absolutely prudent to include a reference to the relevant certificate from the handshake. That said, I don't think anyone is including SCTs in CA certificates at present. In fact, I have a collection of roots and intermediates extracted from CT and, checking just now, I didn't find any SCTs. If you'd like to do a sanity check at some point, a good collection of intermediates can be downloaded from https://www.ccadb.org/resources AFAIK, CT policies all apply only to end-entity certificates. Interemediates are "logged" implicitly as they're supplied by CAs in the chain with the leaves. I am not sure of anyone is using OCSP for delivery of SCTs, but, IIRC, Cloudflare uses the TLS extension. Google might, too. On Tue, Mar 4, 2025 at 4:53 PM Jamil Nimeh <jamil.j.ni...@oracle.com> wrote: > 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 > > -- Ivan
