On Mon, 12 May 2025 15:07:20 GMT, Sean Mullan <mul...@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
