Re: RFR: 8315487: Security Providers Filter [v22]

list of rules, returned by the parser, that represents filter > patterns from left to right (see the filter syntax for reference). At the end > of this list, a match-all and deny rule is added for default behavior. When a > service is evaluated against the filter, each filter rule is chec

Integrated: 8350661: PKCS11 HKDF throws ProviderException when requesting a 31-byte AES key

On Tue, 8 Apr 2025 20:02:56 GMT, Martin Balao wrote: > Hi, > > I would like to request a review for the fix of JDK-8350661. In this fix, we > translate the native PKCS 11 error code into an > `InvalidAlgorithmParameterException`, as documented in the `KDF::deriveKey` > A

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

On Fri, 18 Apr 2025 21:18:04 GMT, Valerie Peng wrote: >> The separation can remove 1 conditional block, so only 1 extra line and the >> flow looks cleaner in my opinion, e.g. >> Suggestion: >> >> case (int) CKK_DES, (int) CKK_DES3 -> { >> keyLength = P11KeyGe

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

w different errors > and may even (in theory) delay the error until the key is used, as _SunJCE_ > does. I believe that this is an improvement but further adjustments may be > needed in the future. > > No regressions observed in `test/jdk/sun/security/pkcs11/KDF/TestHKDF.java`. >

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

w different errors > and may even (in theory) delay the error until the key is used, as _SunJCE_ > does. I believe that this is an improvement but further adjustments may be > needed in the future. > > No regressions observed in `test/jdk/sun/security/pkcs11/KDF/TestHKDF.java`. >

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

On Thu, 17 Apr 2025 23:52:56 GMT, Valerie Peng wrote: >> Martin Balao has updated the pull request incrementally with one additional >> commit since the last revision: >> >> Inform key sizes in the exception when failing check. > > src/jdk.crypto.cryptoki/sha

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

On Thu, 17 Apr 2025 22:59:49 GMT, Valerie Peng wrote: >> Martin Balao has updated the pull request incrementally with one additional >> commit since the last revision: >> >> Inform key sizes in the exception when failing check. > > src/jdk.crypto.cryptoki/sha

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

On Thu, 17 Apr 2025 20:52:52 GMT, Valerie Peng wrote: >> Martin Balao has updated the pull request incrementally with one additional >> commit since the last revision: >> >> Inform key sizes in the exception when failing check. > > src/jdk.crypto.cryptoki/sha

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

w different errors > and may even (in theory) delay the error until the key is used, as _SunJCE_ > does. I believe that this is an improvement but further adjustments may be > needed in the future. > > No regressions observed in `test/jdk/sun/security/pkcs11/KDF/TestHKDF.java`. >

Re: RFR: 8352728: InternalError loading java.security due to Windows parent folder permissions [v2]

On Tue, 15 Apr 2025 18:38:20 GMT, Francisco Ferrari Bihurriet wrote: >> Hi, this is a proposal to fix 8352728. >> >> The main idea is to replace >> [`java.nio.file.Path::toRealPath`](https://docs.oracle.com/en/java/javase/24/docs/api/java.base/java/nio/file/Path.html#toRealPath(java.nio.file.L

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

On Thu, 17 Apr 2025 00:22:14 GMT, Martin Balao wrote: >> Hi, >> >> I would like to request a review for the fix of JDK-8350661. In this fix, we >> translate the native PKCS 11 error code into an >> `InvalidAlgorithmParameterException`, as documented in the `KDF:

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

On Thu, 17 Apr 2025 00:47:00 GMT, Valerie Peng wrote: >> Martin Balao has updated the pull request incrementally with two additional >> commits since the last revision: >> >> - TLS keys added to the map. >> - Key type check refactoring (derivation). > > s

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

w different errors > and may even (in theory) delay the error until the key is used, as _SunJCE_ > does. I believe that this is an improvement but further adjustments may be > needed in the future. > > No regressions observed in `test/jdk/sun/security/pkcs11/KDF/TestHKDF.java`. >

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

On Tue, 15 Apr 2025 16:04:26 GMT, Francisco Ferrari Bihurriet 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 lou

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

On Tue, 15 Apr 2025 13:20:34 GMT, Martin Balao wrote: >> src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11SecretKeyFactory.java >> line 240: >> >>> 238: putKeyInfo(new KeyInfo("TlsPremasterSecret", >>> PCKK_TLSPREMAS

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

On Fri, 11 Apr 2025 23:46:49 GMT, Martin Balao wrote: >>> What I have found with Tls* keys is that they are in the map but we need to >>> translate their pseudo-mechanism to a valid one (`CKK_GENERIC_SECRET`). Is >>> that enough for #24393? >> >> What

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

On Mon, 14 Apr 2025 18:53:12 GMT, Francisco Ferrari Bihurriet wrote: >> Martin Balao has updated the pull request incrementally with two additional >> commits since the last revision: >> >> - Algorithm and key size checking before derivation. Mechanism >> norm

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

On Mon, 14 Apr 2025 17:44:53 GMT, Francisco Ferrari Bihurriet wrote: >> Martin Balao has updated the pull request incrementally with two additional >> commits since the last revision: >> >> - Algorithm and key size checking before derivation. Mechanism >> norm

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

On Fri, 11 Apr 2025 21:32:47 GMT, Valerie Peng wrote: >> Martin Balao has updated the pull request incrementally with two additional >> commits since the last revision: >> >> - Algorithm and key size checking before derivation. Mechanism >> normalizati

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

On Fri, 11 Apr 2025 19:47:38 GMT, Valerie Peng wrote: > > What I have found with Tls* keys is that they are in the map but we need to > > translate their pseudo-mechanism to a valid one (`CKK_GENERIC_SECRET`). Is > > that enough for #24393? > > What I found is that there are more "TlsXXX" than

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

On Fri, 11 Apr 2025 21:28:30 GMT, Valerie Peng wrote: >> Martin Balao has updated the pull request incrementally with two additional >> commits since the last revision: >> >> - Algorithm and key size checking before derivation. Mechanism >> normalizati

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

On Thu, 10 Apr 2025 23:54:03 GMT, Martin Balao wrote: >> Hi, >> >> I would like to request a review for the fix of JDK-8350661. In this fix, we >> translate the native PKCS 11 error code into an >> `InvalidAlgorithmParameterException`, as documented in the `KDF:

Re: RFR: 8350661: PKCS11 HKDF throws ProviderException when requesting a 31-byte AES key

On Thu, 10 Apr 2025 03:27:19 GMT, Valerie Peng wrote: >> Hi, >> >> I would like to request a review for the fix of JDK-8350661. In this fix, we >> translate the native PKCS 11 error code into an >> `InvalidAlgorithmParameterException`, as documented in the `KDF::deriveKey` >> API. With that s

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

w different errors > and may even (in theory) delay the error until the key is used, as _SunJCE_ > does. I believe that this is an improvement but further adjustments may be > needed in the future. > > No regressions observed in `test/jdk/sun/security/pkcs11/KDF/TestHKDF.java`. >

Re: RFR: 8350661: PKCS11 HKDF throws ProviderException when requesting a 31-byte AES key

On Thu, 10 Apr 2025 03:08:32 GMT, Valerie Peng wrote: >> Hi, >> >> I would like to request a review for the fix of JDK-8350661. In this fix, we >> translate the native PKCS 11 error code into an >> `InvalidAlgorithmParameterException`, as documented in the `KDF::deriveKey` >> API. With that s

Re: RFR: 8350661: PKCS11 HKDF throws ProviderException when requesting a 31-byte AES key

On Tue, 8 Apr 2025 20:02:56 GMT, Martin Balao wrote: > Hi, > > I would like to request a review for the fix of JDK-8350661. In this fix, we > translate the native PKCS 11 error code into an > `InvalidAlgorithmParameterException`, as documented in the `KDF::deriveKey` > A

Re: RFR: 8350661: PKCS11 HKDF throws ProviderException when requesting a 31-byte AES key

On Wed, 9 Apr 2025 11:03:52 GMT, Mikhail Yankelevich wrote: >> Hi, >> >> I would like to request a review for the fix of JDK-8350661. In this fix, we >> translate the native PKCS 11 error code into an >> `InvalidAlgorithmParameterException`, as documented in the `KDF::deriveKey` >> API. With

Re: RFR: 8350661: PKCS11 HKDF throws ProviderException when requesting a 31-byte AES key

On Wed, 9 Apr 2025 10:57:45 GMT, Mikhail Yankelevich wrote: >> Hi, >> >> I would like to request a review for the fix of JDK-8350661. In this fix, we >> translate the native PKCS 11 error code into an >> `InvalidAlgorithmParameterException`, as documented in the `KDF::deriveKey` >> API. With

Re: RFR: 8350661: PKCS11 HKDF throws ProviderException when requesting a 31-byte AES key

On Wed, 9 Apr 2025 06:45:14 GMT, Daniel Jeliński wrote: > I think the usual way to handle this is by calling > `P11KeyGenerator.checkKeySize` We discussed calling `P11KeyGenerator::checkKeySize` with @franferrax but were not sure of taking this approach. We found that for DES(3) cases some fix

Re: RFR: 8350661: PKCS11 HKDF throws ProviderException when requesting a 31-byte AES key

On Tue, 8 Apr 2025 20:02:56 GMT, Martin Balao wrote: > Hi, > > I would like to request a review for the fix of JDK-8350661. In this fix, we > translate the native PKCS 11 error code into an > `InvalidAlgorithmParameterException`, as documented in the `KDF::deriveKey` > A

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

Hi, I would like to request a review for the fix of JDK-8350661. In this fix, we translate the native PKCS 11 error code into an `InvalidAlgorithmParameterException`, as documented in the `KDF::deriveKey` API. With that said, different PKCS 11 libraries may throw different errors and may even

Re: RFR: 8345139: Fix bugs and inconsistencies in the Provider services map [v5]

On Tue, 4 Mar 2025 01:59:58 GMT, Valerie Peng wrote: >> Francisco Ferrari Bihurriet has updated the pull request incrementally with >> one additional commit since the last revision: >> >> Clear ServicesMap fields in the declared order >> >> Constructors assign the fields in the same orde

Re: RFR: 8345139: Fix bugs and inconsistencies in the Provider services map [v5]

On Tue, 25 Feb 2025 19:40:24 GMT, Valerie Peng wrote: >> Francisco Ferrari Bihurriet has updated the pull request incrementally with >> one additional commit since the last revision: >> >> Clear ServicesMap fields in the declared order >> >> Constructors assign the fields in the same ord

Re: RFR: 8345139: Fix bugs and inconsistencies in the Provider services map [v5]

On Thu, 6 Mar 2025 07:06:08 GMT, Valerie Peng wrote: >> Francisco Ferrari Bihurriet has updated the pull request incrementally with >> one additional commit since the last revision: >> >> Clear ServicesMap fields in the declared order >> >> Constructors assign the fields in the same orde

Re: RFR: 8345139: Fix bugs and inconsistencies in the Provider services map [v5]

On Thu, 6 Mar 2025 06:13:22 GMT, Valerie Peng wrote: >> Francisco Ferrari Bihurriet has updated the pull request incrementally with >> one additional commit since the last revision: >> >> Clear ServicesMap fields in the declared order >> >> Constructors assign the fields in the same orde

Re: RFR: 8345139: Fix bugs and inconsistencies in the Provider services map [v5]

On Thu, 3 Apr 2025 00:27:50 GMT, Martin Balao wrote: >> src/java.base/share/classes/java/security/Provider.java line 1037: >> >>> 1035: } >>> 1036: >>> 1037: if (mi.isLegacy) { >> >> For legacy entry, there is no che

Re: RFR: 8345139: Fix bugs and inconsistencies in the Provider services map [v5]

On Mon, 3 Mar 2025 18:31:19 GMT, Valerie Peng wrote: >> Francisco Ferrari Bihurriet has updated the pull request incrementally with >> one additional commit since the last revision: >> >> Clear ServicesMap fields in the declared order >> >> Constructors assign the fields in the same orde

Re: RFR: 8345139: Fix bugs and inconsistencies in the Provider services map [v5]

On Thu, 6 Mar 2025 06:10:09 GMT, Valerie Peng wrote: >> Francisco Ferrari Bihurriet has updated the pull request incrementally with >> one additional commit since the last revision: >> >> Clear ServicesMap fields in the declared order >> >> Constructors assign the fields in the same orde

Re: RFR: 8345139: Fix bugs and inconsistencies in the Provider services map [v5]

On Thu, 6 Mar 2025 06:15:17 GMT, Valerie Peng wrote: >> Francisco Ferrari Bihurriet has updated the pull request incrementally with >> one additional commit since the last revision: >> >> Clear ServicesMap fields in the declared order >> >> Constructors assign the fields in the same orde

Re: RFR: 8345139: Fix bugs and inconsistencies in the Provider services map [v5]

On Wed, 5 Mar 2025 01:40:55 GMT, Valerie Peng wrote: >> Francisco Ferrari Bihurriet has updated the pull request incrementally with >> one additional commit since the last revision: >> >> Clear ServicesMap fields in the declared order >> >> Constructors assign the fields in the same orde

Re: RFR: 8345139: Fix bugs and inconsistencies in the Provider services map [v5]

On Wed, 5 Mar 2025 07:06:45 GMT, Valerie Peng wrote: >> Francisco Ferrari Bihurriet has updated the pull request incrementally with >> one additional commit since the last revision: >> >> Clear ServicesMap fields in the declared order >> >> Constructors assign the fields in the same orde

Re: RFR: 8345139: Fix bugs and inconsistencies in the Provider services map [v5]

On Wed, 5 Mar 2025 01:02:15 GMT, Valerie Peng wrote: >> Francisco Ferrari Bihurriet has updated the pull request incrementally with >> one additional commit since the last revision: >> >> Clear ServicesMap fields in the declared order >> >> Constructors assign the fields in the same orde

Re: RFR: 8345139: Fix bugs and inconsistencies in the Provider services map [v5]

On Tue, 4 Mar 2025 01:55:06 GMT, Valerie Peng wrote: >> Francisco Ferrari Bihurriet has updated the pull request incrementally with >> one additional commit since the last revision: >> >> Clear ServicesMap fields in the declared order >> >> Constructors assign the fields in the same orde

Re: RFR: 8345139: Fix bugs and inconsistencies in the Provider services map [v5]

On Mon, 3 Mar 2025 23:24:29 GMT, Valerie Peng wrote: >> Francisco Ferrari Bihurriet has updated the pull request incrementally with >> one additional commit since the last revision: >> >> Clear ServicesMap fields in the declared order >> >> Constructors assign the fields in the same orde

Re: RFR: 8345139: Fix bugs and inconsistencies in the Provider services map [v5]

On Wed, 26 Feb 2025 01:56:58 GMT, Valerie Peng wrote: >> Francisco Ferrari Bihurriet has updated the pull request incrementally with >> one additional commit since the last revision: >> >> Clear ServicesMap fields in the declared order >> >> Constructors assign the fields in the same ord

Re: RFR: 8345139: Fix bugs and inconsistencies in the Provider services map [v5]

On Wed, 26 Feb 2025 01:44:26 GMT, Valerie Peng wrote: >> Francisco Ferrari Bihurriet has updated the pull request incrementally with >> one additional commit since the last revision: >> >> Clear ServicesMap fields in the declared order >> >> Constructors assign the fields in the same ord

Re: RFR: 8345139: Fix bugs and inconsistencies in the Provider services map [v5]

On Wed, 26 Feb 2025 01:09:55 GMT, Valerie Peng wrote: >> Francisco Ferrari Bihurriet has updated the pull request incrementally with >> one additional commit since the last revision: >> >> Clear ServicesMap fields in the declared order >> >> Constructors assign the fields in the same ord

Re: RFR: 8345139: Fix bugs and inconsistencies in the Provider services map [v5]

On Wed, 26 Feb 2025 00:50:39 GMT, Valerie Peng wrote: >> Francisco Ferrari Bihurriet has updated the pull request incrementally with >> one additional commit since the last revision: >> >> Clear ServicesMap fields in the declared order >> >> Constructors assign the fields in the same ord

Re: RFR: 8345139: Fix bugs and inconsistencies in the Provider services map [v5]

On Wed, 26 Feb 2025 00:45:13 GMT, Valerie Peng wrote: >> Francisco Ferrari Bihurriet has updated the pull request incrementally with >> one additional commit since the last revision: >> >> Clear ServicesMap fields in the declared order >> >> Constructors assign the fields in the same ord

Re: RFR: 8345139: Fix bugs and inconsistencies in the Provider services map [v5]

On Wed, 26 Feb 2025 00:26:43 GMT, Valerie Peng wrote: >> Francisco Ferrari Bihurriet has updated the pull request incrementally with >> one additional commit since the last revision: >> >> Clear ServicesMap fields in the declared order >> >> Constructors assign the fields in the same ord

Re: RFR: 8345139: Fix bugs and inconsistencies in the Provider services map [v5]

On Wed, 26 Feb 2025 00:21:48 GMT, Valerie Peng wrote: >> Francisco Ferrari Bihurriet has updated the pull request incrementally with >> one additional commit since the last revision: >> >> Clear ServicesMap fields in the declared order >> >> Constructors assign the fields in the same ord

Re: RFR: 8345139: Fix bugs and inconsistencies in the Provider services map [v5]

On Tue, 25 Feb 2025 19:45:47 GMT, Valerie Peng wrote: >> Francisco Ferrari Bihurriet has updated the pull request incrementally with >> one additional commit since the last revision: >> >> Clear ServicesMap fields in the declared order >> >> Constructors assign the fields in the same ord

Re: RFR: 8315487: Security Providers Filter [v21]

list of rules, returned by the parser, that represents filter > patterns from left to right (see the filter syntax for reference). At the end > of this list, a match-all and deny rule is added for default behavior. When a > service is evaluated against the filter, each filter rul

Integrated: 8328119: Support HKDF in SunPKCS11 (Preview)

On Mon, 18 Nov 2024 18:05:34 GMT, Martin Balao wrote: > We would like to propose an implementation of the HKDF algorithms for > SunPKCS11, aligned with the KDF API proposed for JDK 24 (see [JEP 478: Key > Derivation Function API > (Preview)](https://bugs.openjdk.org/browse

Re: RFR: 8315487: Security Providers Filter [v20]

list of rules, returned by the parser, that represents filter > patterns from left to right (see the filter syntax for reference). At the end > of this list, a match-all and deny rule is added for default behavior. When a > service is evaluated against the filter, each filter rule is chec

Re: RFR: 8328119: Support HKDF in SunPKCS11 (Preview) [v14]

On Wed, 5 Feb 2025 23:06:54 GMT, Martin Balao wrote: >> We would like to propose an implementation of the HKDF algorithms for >> SunPKCS11, aligned with the KDF API proposed for JDK 24 (see [JEP 478: Key >> Derivation Function API >> (Preview)](https://bugs.openjd

Re: RFR: 8345139: Fix bugs and inconsistencies in the Provider services map [v2]

On Wed, 22 Jan 2025 00:53:13 GMT, Anthony Scarpino wrote: >> Francisco Ferrari Bihurriet has updated the pull request incrementally with >> one additional commit since the last revision: >> >> Copyright update. >> >> Co-authored-by: Martin Balao Al

Re: RFR: 8345139: Fix bugs and inconsistencies in the Provider services map [v4]

> base due to a merge or a rebase. The pull request now contains four commits: > > - Merge openjdk/master into JDK-8345139 > >Fix conflict caused by e20bd018c4046870d0cf632bb8e5440cb9f5c3c2: > 1. Ignore the change, as this had already been identified and fixed >

Re: RFR: 8345139: Fix bugs and inconsistencies in the Provider services map [v4]

On Tue, 21 Jan 2025 23:54:02 GMT, Anthony Scarpino wrote: >> Just to add some more semantic value but we don't have a strong opinion, we >> can replace it with boolean if you want. > > Yes, please do that. Done. - PR Review Comment: https://git.openjdk.org/jdk/pull/22613#discussi

Re: RFR: 8328119: Support HKDF in SunPKCS11 (Preview) [v14]

TLS checked >* Informative output for debugging purposes (shown automatically if there > is a test failure) > * Note: test failures do not prevent all tests for running >* Test integrated to the SunPKCS11 tests framework > > * No regressions observed in jdk/sun/sec

Re: RFR: 8328119: Support HKDF in SunPKCS11 (Preview) [v13]

TLS checked >* Informative output for debugging purposes (shown automatically if there > is a test failure) > * Note: test failures do not prevent all tests for running >* Test integrated to the SunPKCS11 tests framework > > * No regressions observed in jdk/sun/secu

Re: RFR: 8328119: Support HKDF in SunPKCS11 (Preview) [v12]

On Tue, 21 Jan 2025 18:13:04 GMT, Kevin Driver wrote: >> Martin Balao has updated the pull request incrementally with one additional >> commit since the last revision: >> >> Add test case with empty inputs >> >> Co-authored-by: Martin Balao Alonso &g

Re: RFR: 8328119: Support HKDF in SunPKCS11 (Preview) [v12]

TLS checked >* Informative output for debugging purposes (shown automatically if there > is a test failure) > * Note: test failures do not prevent all tests for running >* Test integrated to the SunPKCS11 tests framework > > * No regressions observed in jdk/sun/secu

Re: RFR: 8328119: Support HKDF in SunPKCS11 (Preview) [v11]

On Fri, 17 Jan 2025 19:59:22 GMT, Kevin Driver wrote: >> Martin Balao has updated the pull request incrementally with one additional >> commit since the last revision: >> >> Improve TestContext note about expectedOpOut >> >> Co-authored-by: Mart

Re: RFR: 8328119: Support HKDF in SunPKCS11 (Preview) [v11]

On Fri, 17 Jan 2025 20:17:41 GMT, Kevin Driver wrote: >> src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/wrapper/CK_HKDF_PARAMS.java >> line 71: >> >>> 69: * >>> 70: */ >>> 71: public final long prfHashMechanism; >> >> I'm assuming `CK_MECHANISM_TYPE` can safely map to

Re: RFR: 8328119: Support HKDF in SunPKCS11 (Preview) [v11]

On Fri, 17 Jan 2025 20:10:53 GMT, Kevin Driver wrote: >> In some cases we need to return a `SecretKey` (a `P11SecretKey` instance, >> internally) that represents a key inside the token. In some cases, we can >> extract its bytes and create a key again with key translation, but it's >> costly.

Re: RFR: 8328119: Support HKDF in SunPKCS11 (Preview) [v11]

On Fri, 17 Jan 2025 19:37:07 GMT, Kevin Driver wrote: >> src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11SecretKeyFactory.java >> line 198: >> >>> 196: CK_ATTRIBUTE.SIGN_TRUE}; >>> 197: >>> 198: P12MacPBEKeyInfo(String algo, long kdfMech, HMACKeyInfo >>> h

Re: RFR: 8328119: Support HKDF in SunPKCS11 (Preview) [v11]

On Fri, 17 Jan 2025 19:26:36 GMT, Kevin Driver wrote: >> Martin Balao has updated the pull request incrementally with one additional >> commit since the last revision: >> >> Improve TestContext note about expectedOpOut >> >> Co-authored-by: Mart

RFR: 8225739: sun/security/pkcs11/tls/tls12/FipsModeTLS12.java is not reliable

Hello, I would like to propose a solution for this test that makes it more clear when it's skipped. Regards, Martin.- - Commit messages: - 8225739: sun/security/pkcs11/tls/tls12/FipsModeTLS12.java is not reliable. Changes: https://git.openjdk.org/jdk/pull/23177/files Webrev: ht

Re: On 8346720: Support Generic keys in SunPKCS11 SecretKeyFactory

Done. Thanks, Martin.- On Mon, Jan 13, 2025 at 10:27 AM Sean Mullan wrote: > > > On 1/12/25 9:11 PM, Martin Balao wrote: > > Done. I removed the Generic name Specification update request and added > > a reference to your CSR instead. > > You should also change the s

Re: RFR: 8328119: Support HKDF in SunPKCS11 (Preview) [v11]

TLS checked >* Informative output for debugging purposes (shown automatically if there > is a test failure) > * Note: test failures do not prevent all tests for running >* Test integrated to the SunPKCS11 tests framework > > * No regressions observed in jdk/sun/secu

Re: On 8346720: Support Generic keys in SunPKCS11 SecretKeyFactory

remove yours. > > Thanks, > Weijun > > On Jan 9, 2025, at 10:06, Martin Balao wrote: > > If it's more clear or easier for you, we can do it. > > I've re-opened JDK-8346720. We will reference JDK-8346720 in PR #22215's > commit for the code changes par

Re: RFR: 8328119: Support HKDF in SunPKCS11 (Preview) [v10]

On Sat, 11 Jan 2025 01:44:06 GMT, Valerie Peng wrote: >> src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11HKDF.java line >> 230: >> >>> 228: } >>> 229: >>> 230: private abstract sealed class KeyMaterialMerger permits >> >> Hmm, instead of all these different sub-classes wh

Re: On 8346720: Support Generic keys in SunPKCS11 SecretKeyFactory

still needed because it has at least the > SunPKCS11 Provider change part. This is also the reason why JDK-8346720 > needs to be re-opened. > > Thanks, > Weijun > > > > On Jan 8, 2025, at 18:35, Martin Balao wrote: > > > > Hi Weijun, > > > > Happy

Re: On 8346720: Support Generic keys in SunPKCS11 SecretKeyFactory

Hi Weijun, Happy new year to you as well! Thanks for the heads up. My understanding is that the spec changes will be done in JDK-8346997 and the code changes will be integrated as part of "8328119: Support HKDF in SunPKCS11 (Preview) (PR #22215)", so

Re: RFR: 8315487: Security Providers Filter [v19]

list of rules, returned by the parser, that represents filter > patterns from left to right (see the filter syntax for reference). At the end > of this list, a match-all and deny rule is added for default behavior. When a > service is evaluated against the filter, each filter rul

Re: RFR: 8315487: Security Providers Filter [v18]

list of rules, returned by the parser, that represents filter > patterns from left to right (see the filter syntax for reference). At the end > of this list, a match-all and deny rule is added for default behavior. When a > service is evaluated against the filter, each filter rule is chec

Re: RFR: 8328119: Support HKDF in SunPKCS11 (Preview) [v9]

On Wed, 8 Jan 2025 00:54:02 GMT, Valerie Peng wrote: >> Martin Balao has updated the pull request incrementally with one additional >> commit since the last revision: >> >> Minor changes based on review. Copyright date adjustments. >> >> Co-autho

Re: RFR: 8328119: Support HKDF in SunPKCS11 (Preview) [v10]

TLS checked >* Informative output for debugging purposes (shown automatically if there > is a test failure) > * Note: test failures do not prevent all tests for running >* Test integrated to the SunPKCS11 tests framework > > * No regressions observed in jdk/sun/secu

Re: RFR: 8328119: Support HKDF in SunPKCS11 (Preview) [v9]

TLS checked >* Informative output for debugging purposes (shown automatically if there > is a test failure) > * Note: test failures do not prevent all tests for running >* Test integrated to the SunPKCS11 tests framework > > * No regressions observed in jdk/sun/secu

Re: RFR: 8328119: Support HKDF in SunPKCS11 (Preview) [v8]

On Fri, 20 Dec 2024 18:53:16 GMT, Martin Balao wrote: >>> I'll split this PR and clarify the intention for _Generic_ keys in the new >>> CSR. @seanjmullan, based on what we discussed with Weijun, would you be >>> open to making this PR dependent on the _Ge

Re: RFR: 8328119: Support HKDF in SunPKCS11 (Preview) [v8]

On Sat, 4 Jan 2025 01:18:01 GMT, Valerie Peng wrote: >> Martin Balao has updated the pull request incrementally with one additional >> commit since the last revision: >> >> Check disabled PKCS #11 mechanisms when concatenating keys and data. >> >>

Re: RFR: 8328119: Support HKDF in SunPKCS11 (Preview) [v8]

On Mon, 6 Jan 2025 22:20:23 GMT, Valerie Peng wrote: >> Martin Balao has updated the pull request incrementally with one additional >> commit since the last revision: >> >> Check disabled PKCS #11 mechanisms when concatenating keys and data. >> >>

Re: RFR: 8328119: Support HKDF in SunPKCS11 (Preview) [v8]

On Sat, 4 Jan 2025 01:20:31 GMT, Valerie Peng wrote: >> Martin Balao has updated the pull request incrementally with one additional >> commit since the last revision: >> >> Check disabled PKCS #11 mechanisms when concatenating keys and data. >> >>

Re: RFR: 8328119: Support HKDF in SunPKCS11 (Preview) [v8]

On Fri, 3 Jan 2025 02:15:31 GMT, Valerie Peng wrote: >> src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/wrapper/CK_KEY_DERIVATION_STRING_DATA.java >> line 53: >> >>> 51: * >>> 52: */ >>> 53: public byte[] pData; >> >> could be final. > > Same goes to those in CK_HKDF_P

Re: RFR: 8328119: Support HKDF in SunPKCS11 (Preview) [v8]

On Sat, 4 Jan 2025 00:57:45 GMT, Valerie Peng wrote: >> Martin Balao has updated the pull request incrementally with one additional >> commit since the last revision: >> >> Check disabled PKCS #11 mechanisms when concatenating keys and data. >> >>

Re: RFR: 8328119: Support HKDF in SunPKCS11 (Preview) [v8]

On Fri, 20 Dec 2024 17:50:12 GMT, Sean Mullan wrote: > > I'll split this PR and clarify the intention for _Generic_ keys in the new > > CSR. @seanjmullan, based on what we discussed with Weijun, would you be > > open to making this PR dependent on the _Generic_ one? Otherwise, I'll have > > to

Re: RFR: 8328119: Support HKDF in SunPKCS11 (Preview) [v6]

On Thu, 19 Dec 2024 17:43:20 GMT, Francisco Ferrari Bihurriet wrote: >> BTW, what else can this key be used? I tried in HmacSHA256 and there is a >> CKR_KEY_TYPE_INCONSISTENT error. > > Hi @wangweij, > > What test have you executed? I'm able to use "Generic" keys for HmacSHA256, > in a local

Re: RFR: 8328119: Support HKDF in SunPKCS11 (Preview) [v8]

On Fri, 20 Dec 2024 01:54:29 GMT, Weijun Wang wrote: > OK. I have a minor concern: this factory seems primarily useful for HSMs, and > it’s unlikely that software-based providers would support it. Users should be > mindful of its intended use. I noticed the CSR already references its > connect

Re: RFR: 8328119: Support HKDF in SunPKCS11 (Preview) [v8]

On Fri, 20 Dec 2024 00:58:31 GMT, Weijun Wang wrote: > > there will be part of the functionality difficult or impossible to use and > > untested. > > Show me a case that is impossible with this factory. IIUC, the only usage of > this factory is to convert a `SecretKeySpec` to a P11 key. Why ne

Re: RFR: 8328119: Support HKDF in SunPKCS11 (Preview) [v8]

On Thu, 19 Dec 2024 19:41:23 GMT, Martin Balao wrote: >> We would like to propose an implementation of the HKDF algorithms for >> SunPKCS11, aligned with the KDF API proposed for JDK 24 (see [JEP 478: Key >> Derivation Function API >> (Preview)](https://bugs.openjd

Re: RFR: 8328119: Support HKDF in SunPKCS11 (Preview) [v8]

On Thu, 19 Dec 2024 20:50:18 GMT, Sean Mullan wrote: > > Added a _Specification_ change to the CSR so the _Generic_ name is added to > > the Standard Names document. > > I think this should be done as a separate issue. By adding this to the CSR, > this Enhancement means it is now of SE scope.

Re: RFR: 8315487: Security Providers Filter [v17]

On Tue, 17 Dec 2024 17:57:02 GMT, Martin Balao wrote: >> In addition to the goals, scope, motivation, specification and requirement >> notes in [JDK-8315487](https://bugs.openjdk.org/browse/JDK-8315487), we >> would like to describe the most relevant decision

Re: RFR: 8328119: Support HKDF in SunPKCS11 (Preview) [v8]

On Thu, 19 Dec 2024 19:41:23 GMT, Martin Balao wrote: >> We would like to propose an implementation of the HKDF algorithms for >> SunPKCS11, aligned with the KDF API proposed for JDK 24 (see [JEP 478: Key >> Derivation Function API >> (Preview)](https://bugs.openjd

Re: RFR: 8328119: Support HKDF in SunPKCS11 (Preview) [v7]

On Thu, 19 Dec 2024 13:58:57 GMT, Weijun Wang wrote: > > However, we decided not to make `CKM_CONCATENATE_DATA_AND_BASE` a > > requirement for HKDF services in SunPKCS11. > > This sounds perfectly reasonable at token init time. Most HKDF cases do not > need multiple IKM or salt segments. > >

Re: RFR: 8328119: Support HKDF in SunPKCS11 (Preview) [v8]

TLS checked >* Informative output for debugging purposes (shown automatically if there > is a test failure) > * Note: test failures do not prevent all tests for running >* Test integrated to the SunPKCS11 tests framework > > * No regressions observed in jdk/sun/secu

Re: RFR: 8328119: Support HKDF in SunPKCS11 (Preview) [v7]

On Thu, 19 Dec 2024 02:29:07 GMT, Weijun Wang wrote: > Just curious, if I disable the `CKM_CONCATENATE_DATA_AND_BASE` mechanism in > the config file, then `addIKM(data).addIKM(key)` still works. I guess that's > because the config only applies to JCA/JCE algorithms but not internal > implement

Re: RFR: 8328119: Support HKDF in SunPKCS11 (Preview) [v6]

On Thu, 19 Dec 2024 00:11:34 GMT, Weijun Wang wrote: >> Generic is a native PKCS11 key type (`CKK_GENERIC_SECRET`) that could have >> been added to SunPKCS11 before, irrespective of HKDF. It's convenient for >> the test to have key material in the token and test consolidation (IKM or >> salt).

Re: RFR: 8328119: Support HKDF in SunPKCS11 (Preview) [v6]

On Wed, 18 Dec 2024 22:48:04 GMT, Weijun Wang wrote: >> Martin Balao has updated the pull request incrementally with one additional >> commit since the last revision: >> >> Unused import removed. >> >> Co-authored-by: Martin Balao Alonso >> C

Re: RFR: 8328119: Support HKDF in SunPKCS11 (Preview) [v5]

On Wed, 18 Dec 2024 21:33:29 GMT, Sean Mullan wrote: >> We included SHA1 because there could be a legacy use case to support and >> it's part of the test vectors for RFC 5869 (HMAC-based Extract-and-Expand >> Key Derivation Function (HKDF)). We don't recommend using it, and will >> probably fi

  1   2   3   4   >