RFD: Services lockdown for security providers

[Martin Balao]

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 <mbalao at 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
>