RFR: 8350661: PKCS11 HKDF throws ProviderException when requesting a 31-byte AES key [v2]

[Martin Balao]

On Tue, 15 Apr 2025 16:04:26 GMT, Francisco Ferrari Bihurriet <fferrari at openjdk.org> wrote:

>> BTW, I don't like the partial "Tls" string comparison much because it's making an assumption about the algorithm name.
>
> A new `PCKK_TLSKEY` pseudo key type looks good to me. Alternatively, and just thinking out loud, how about introducing a new `TlsKeyInfo` and using `ki instanceof TlsKeyInfo` in `P11KDF::getDerivedKeyType`?
> 
> Perhaps we could also add a new `KeyInfo.supportsHKDF` boolean field and store that information in the map, replacing the whole `P11KDF::getDerivedKeyType` call by a `ki.supportsHKDF` check. This would also solve the `PBEWithHmacSHA224AndAES_256` case.

`KeyInfo.supportsHKDF` could be a valid approach. My only concern would be overloading the map/map-objects with information that is specific to each use of a key type. For example, the same criteria could be applied to store whether a key is suitable for `C_CreateObject` in `P11SecretKeyFactory::createKey`. What I liked about storing the key gen mech is that we have different users benefiting from the same information. If there is interest in exploring this idea, I can propose something.

I liked the `TlsKeyInfo` idea to remove `PCKK_TLS*` completely. We can create these keys and assign GENERIC, same as HMACKeyInfo.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24526#discussion_r2045160880