Hi Max,
In this example, we want certificates validation from SUN but signature
verification from SunPKCS11 (only). The problem with the current design
is that there could be a signature algorithm implemented in SUN but not
in SunPKCS11. If that is the case, there is no way to prevent SUN from
verifying the signature: any order of security providers preference
(i.e. SUN -> SunPKCS11 or SunPKCS11 -> SUN) would lead to SUN bringing
the implementation. What we propose is a way to cherry-pick what we want
(or what we don't) from each security provider in a configurable way.
Regards,
Martin.-
On 5/24/23 18:30, Wei-Jun Wang wrote:
On May 24, 2023, at 5:03 PM, Martin Balao <mba...@redhat.com> wrote:
To better illustrate, let's say that the user requires that all cryptographic
operations are performed in a Hardware Security Module (HSM). On the OpenJDK
side, this means that the implementation for Cipher, Signature, Mac and other
cryptographic services must be the one in the SunPKCS11 security provider.
Let's also suppose that other non-cryptographic services such as those for
certificates validation and TLS are required, and their implementation is in
the SUN and SunJSSE security providers respectively. Setting SunPKCS11 at the
highest priority of the list is not a strong guarantee to ensure that all
cryptographic operations come from it: it's possible that an algorithm for
Signature is not implemented in SunPKCS11 or in its underlying token but in the
SUN security provider. Disabling the SUN security provider wouldn't be an
option in this case because we need its certificates validation service.
You listed "Signature" as one of the "cryptographic services", but signature verification is also
used in "certificates validation" which is a "non-cryptographic service". Do you mean signing must
be in SunPKCS11 but verification needn't be? How do you configure that?
Thanks,
Max
