On Fri, 11 Sep 2026 13:45:08 GMT, Andreas Chmielewski
<[email protected]> wrote:
>> makes sense! Thx
>
> There might be some issues I will have to think about .... I have copied
> this piece of code from SSLConfiguration.java
>
>
> // Is the extended_master_secret extension supported?
> static {
> boolean supportExtendedMasterSecret = Utilities.getBooleanProperty(
> "jdk.tls.useExtendedMasterSecret", true);
> if (supportExtendedMasterSecret) {
> try {
> KeyGenerator.getInstance("SunTlsExtendedMasterSecret");
> } catch (NoSuchAlgorithmException nae) {
> supportExtendedMasterSecret = false;
> }
> }
> useExtendedMasterSecret = supportExtendedMasterSecret;
> }
>
>
> If SunPKCS11 is the only available provider, this check will fail. I have not
> yet found a better solution, but my first thought was to introduce an alias:
>
>
> d(KG, "SunTls12ExtendedMasterSecret",
> "sun.security.pkcs11.P11TlsExtendedMasterSecretGenerator",
> List.of("SunTlsExtendedMasterSecret"),
> m(CKM_TLS12_EXTENDED_MASTER_KEY_DERIVE,
> CKM_TLS12_EXTENDED_MASTER_KEY_DERIVE_DH));
>
>
> What do you think?
Well, if SunPKCS11 provider is the only available provider and the TLS version
is 1.0 and 1.1, then it should fail. With this TLS1.2 EMS algorithm naming,
some adjustments are needed at the TLS layer so it uses the right EMS
implementation.
-------------
PR Review Comment: https://git.openjdk.org/jdk/pull/32081#discussion_r4007922480
