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

[Ivan Ristic]

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.nimeh at 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.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
>
>

-- 
Ivan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/security-dev/attachments/20250305/0117f3e5/attachment-0001.htm>