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

[Sean Mullan]

On Tue, 13 May 2025 05:13:42 GMT, Bradford Wetmore <wetmore at openjdk.org> wrote:

>> 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 do need to make this consistent, I have TLSv1.3 using KDF style, and TLSv1-TLSv1.2 using the null.

It seems like it should be an exception, whatever you decide to do. The caller is asking for the keying material data, and the provider cannot fulfill that request, so I think explaining why it could not be done would be best represented in an exception.

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

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