RFR: 8349849: PKCS11 SunTlsKeyMaterial crashes when used with TLS1.2 TlsKeyMaterialParameterSpec

[Daniel Jeliński]

On Wed, 19 Feb 2025 22:11:07 GMT, Valerie Peng <valeriep at openjdk.org> wrote:

>> TLS 1.3 uses HKDF, and doesn't work with SunPKCS11 yet, see [JDK-8278640](https://bugs.openjdk.org/browse/JDK-8278640)
>
> I'd like to clarify the usage of `SunTlsKeyMaterial` and `SunTls12KeyMaterial` KGs first.
> 
> Is `SunTlsKeyMaterial` KG expected to handle specs indicating TLS1.2 version?
> Is `SunTls12KeyMaterial` KeyGenerator expected to handle specs indicating SSL3.0 version?
> 
> Looking at SunJCE provider's impls, `SunTlsKeyMaterial` and `SunTls12KeyMaterial` KGs are considered equivalent, e.g. one being the alias of the other. SunPKCS11 provider defines them separately mapping to different native mechs, however sharing the same impl class. Looking at the current code, it seems that `SunTls12KeyMaterial` will always set `supportSSLv3` to false which should reject specs indicating SSL3.0 version. 
> 
> There seems to be an inconsistency between SunJCE provider and SunPKCS11 provider?
> 
> In addition, we should check that the particular mechanism is supported?

`SunTls12KeyMaterial` is only expected to handle TLS 1.2, and `SunTlsKeyMaterial` is only expected to handle earlier versions (SSL 3.0, TLS 1.0, and TLS 1.1), at least that's how they are used by SunJSSE. 

The implementation does not verify that the KG name matches the TLS version provided in the algorithm parameters, which in one case can lead to a crash. We could add code to perform that verification instead, but that would involve more code than the fix I proposed.

`KeyGenerator.getInstance` verifies that at the necessary mechanisms are present. If incorrect TLS version is used, we may get a ProviderException if the mechanism corresponding to the selected TLS version is unavailable.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23583#discussion_r1968038713