On Tue, 13 May 2025 05:13:42 GMT, Bradford Wetmore <wetm...@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
