On Wed, 7 May 2025 16:28:27 GMT, Weijun Wang <wei...@openjdk.org> wrote:
>> Bradford Wetmore has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Updated to use the upcoming KDF (still in preview) + bits of JDK-8353578
>> for compilation)
>
> src/java.base/share/classes/sun/security/ssl/SSLSessionImpl.java line 1694:
>
>> 1692:
>> 1693: // ...now the final expand.
>> 1694: SecretKey key = hkdf.deriveKey(label,
>
> PKCS #11 is picky about key algorithm names and I'm not sure if `label` is
> always accepted. The KDF API has the algorithm in the method arguments so
> it's left to user to specify one. I'm not sure how the export keying material
> will be used. If it is used in encryption, the algorithm may need to be
> something like "AES".
IIUC, the exported keying material can be used for any purpose or algorithm, so
we really can't make an good educated guess what it might be. They could be
Keys (Ciphers), byte array/value challenges, or even just data that will be
signed. This is just doing a quick read of some of the IANA definitions which
link to some of the known use cases:
https://www.iana.org/assignments/tls-parameters/tls-parameters.xhtml#exporter-labels
Thus the type needs to be something generic. The label sounded good initially,
but there is no specific prohibition against non-null/empty label in the TLS
Exporters, but KDF prohibits null/empty labels.
Maybe a label like "ExportKeyingMaterial"?
-------------
PR Review Comment: https://git.openjdk.org/jdk/pull/24976#discussion_r2078948256
