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
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
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
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
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).
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
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
* DH and ECDH key derivation for 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
>
> *
* DH and ECDH key derivation for 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
>
> *
On Wed, 18 Dec 2024 16:38:39 GMT, Weijun Wang wrote:
> I have never been a PKCS11 expert, but the code looks fine to me. The
> `import` line at the beginning of `CK_HKDF_PARAMS.java` is useless.
Thanks for your review. Unused import removed.
> src/jdk.crypto.cryptoki/share/classes/sun/security
On Wed, 18 Dec 2024 00:35:38 GMT, Xue-Lei Andrew Fan wrote:
> Not to mention the performance impact.
I am not sure if you mean the performance impact of having to make sure that
the Filter is not set, or the performance impact of having the Filter disabled.
For the latter, there won't be any i
On Tue, 17 Dec 2024 21:24:16 GMT, Xue-Lei Andrew Fan wrote:
> Then, please redefine the scope and purpose of this feature. It is just a
> part of the solution. Xuelei
I see it differently. It's a solution for the problem that we think it is worth
addressing from the JDK/JCA perspective. It's n
On Tue, 17 Dec 2024 22:13:09 GMT, Xue-Lei Andrew Fan wrote:
> Sorry, I meant BCFIPS provider as linked in the URL I provided. Which may not
> be able to use putService as it needs to support back to Java 1.5, IIRC.
> Xuelei
BCFIPS works too (tested on `bc-fips-2.0.0.jar`). In this case, the fi
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
On Sun, 15 Dec 2024 07:18:02 GMT, Xue-Lei Andrew Fan wrote:
> > It's only the combination of a Provider that overrides
> > getService/getServices + does not call putService/put + overrides
> > newInstance without calling its parent + uses a non-Java SE service type
> > that would be unfiltered
On Fri, 6 Dec 2024 19:56:07 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
On Thu, 12 Dec 2024 20:53:17 GMT, Xue-Lei Andrew Fan wrote:
> > For third-party providers that override java.security.Provider::getService
> > or java.security.Provider::getServices to return services that have not
> > been evaluated against the filter or are evaluated and not allowed, a
> > s
On Thu, 12 Dec 2024 03:08:30 GMT, Weijun Wang wrote:
>> For Expand, `salt` should be `null`. Do you mean adding or hitting an
>> assertion?
>
> Assertion on line 162 will throw an NPE.
Ah, you're right, the assertion throws an NPE. Fixed.
-
PR Review Comment: https://git.openjdk.o
* DH and ECDH key derivation for 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
>
> *
On Thu, 12 Dec 2024 01:10:04 GMT, Weijun Wang wrote:
>> Martin Balao has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Make EMPTY_KEY static.
>>
>> Co-authored-by: Martin Balao Alonso
>> C
* DH and ECDH key derivation for 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
>
> *
* DH and ECDH key derivation for 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
>
> *
On Fri, 6 Dec 2024 18:40:04 GMT, Weijun Wang wrote:
> I set CKA_EXTRACTABLE = false and generate an AES key and its `getEncoded` is
> null. Then I use it as an IKM for HKDF and the `deriveKey` output is still
> unextractable. So far so good, but if I call `deriveData` on the same input
> spec,
On Fri, 6 Dec 2024 18:34:00 GMT, Weijun Wang wrote:
>> Martin Balao has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Algorithms renamed for alignment with SunJCE.
>>
>> Co-authored-by: Mart
On Fri, 6 Dec 2024 18:03:40 GMT, Weijun Wang wrote:
>> Martin Balao has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Algorithms renamed for alignment with SunJCE.
>>
>> Co-authored-by: Mart
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
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
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
On Mon, 2 Dec 2024 00:37:45 GMT, Xue-Lei Andrew Fan wrote:
>> Martin Balao has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Undo SunNativeProvider provider changes. They will be implemented in
>> JDK-
On Sat, 30 Nov 2024 18:56:31 GMT, Xue-Lei Andrew Fan wrote:
>> Hi @XueleiFan,
>>
>> Is not a goal of this proposal to allow different filter implementations,
>> for this reason, there isn't a pluggable filter API design. The only
>> publicly API exposed by the filter is the `jdk.security.provi
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
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
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
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
* DH and ECDH key derivation for 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
>
> *
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/JDK-8189808)).
This implementation will be under the _Preview_ umbrella until the K
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
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
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
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
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
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
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
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
On Fri, 1 Sep 2023 15:13:46 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 decisions taken during the implementat
introduced to make the SunNativeProvider security provider use the
Provider::putService API to register services, instead of the legacy
Provider::putAll. This was the only security provider in OpenJDK using a
non-Provider::putService API. While this change does not have any observable
implications,
46 matches
Mail list logo
