<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">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"><u></u>

  
  <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">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://datatracker.ietf.org/doc/html/rfc6962#section-3.3" target="_blank">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>