RFR: 8341346: Add support for exporting TLS Keying Material [v10]

[Bradford Wetmore]

On Mon, 12 May 2025 15:07:20 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> Bradford Wetmore has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 13 commits:
>> 
>>  - Merge branch 'master' into JDK-8341346
>>  - Adjustments made for JDK-8350830
>>  - Merge branch 'master' into JDK-8341346
>>  - Rework to avoid PKCS11 data extraction problems, and enhanced input verification and unit testing
>>  - More Codereview comments
>>  - Updated to use the upcoming KDF (still in preview) + bits of JDK-8353578 for compilation)
>>  - Add in the SharedSecrets SecretKeySpec clearing mechanism
>>  - More codereview/CSR comments
>>  - Merge branch 'master' into JDK-8341346
>>  - Codereview comments.
>>  - ... and 3 more: https://git.openjdk.org/jdk/compare/68a11850...bd227aa8
>
> src/java.base/share/classes/javax/net/ssl/ExtendedSSLSession.java line 254:
> 
>> 252:      *
>> 253:      * @return a byte array of size {@code length} that contains the EKM
>> 254:      *         material, or null if the derived key material does not support
> 
> For "or null if the derived key material does not support encoding" why wouldn't an implementation throw UOE instead?

I was following the SecretKey.getEncoded() style.  I see now that KDF.deriveData() does do UOE.  

I could go either way on this.  I realize I need to make this consistent, I have TLSv1.3 using KDF style, and TLSv1-TLSv1.2 using the null.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24976#discussion_r2085932412