On Thu, 3 Sep 2026 07:39:29 GMT, Andreas Chmielewski <[email protected]>
wrote:
>> src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11TlsExtendedMasterSecretGenerator.java
>> line 84:
>>
>>> 82:
>>> 83: int tlsVersion = (spec.getMajorVersion() << 8) |
>>> spec.getMinorVersion();
>>> 84: if (tlsVersion != 0x0303) {
>>
>> Hmm, the same-named impl from SunJCE provider supports older TlsVersion.
>> Also RFC7627 does not limit this to TLS 1.2 only. Since this is used by JSSE
>> implementations, maybe you should not put extra limitation here?
>
> That's correct. RFC 7627 clearly defines EMS for TLS versions prior to TLS
> 1.2 as well.
>
> https://docs.oasis-open.org/pkcs11/pkcs11-spec/v3.2/pkcs11-spec-v3.2.html
>
> However, this implementation is backed by PKCS#11 EMS derivation mechanisms
> (CKM_TLS12_EXTENDED_MASTER_KEY_DERIVE and
> CKM_TLS12_EXTENDED_MASTER_KEY_DERIVE_DH), which are specified as TLS 1.2
> mechanisms in PKCS#11 v3.2. Since no corresponding non-TLS-1.2 EMS derivation
> mechanisms are defined by PKCS#11, this provider implementation can only
> support TLS 1.2 EMS derivation. So we should not remove this limitation here.
I see. Then checking the TLS version makes sense here. However, if this is TLS
1.2 specific, it should be under an algorithm with the version info, e.g.
"SunTlsExtendedMasterSecret" vs "SunTls12ExtendedMasterSecret"? Maybe it's
time to update JSSE side to separate the usage into different algorithms?
-------------
PR Review Comment: https://git.openjdk.org/jdk/pull/32081#discussion_r3928668737
