EC and RSA Key validations fail with Sun PKCS11 Provider

[Bradley Hess]

As an example, in RsaUsingShaAlgorithm:

    public void validatePrivateKey(PrivateKey privateKey) throws InvalidKeyException
    {
        KeyValidationSupport.checkRsaKeySize((RSAKey) privateKey);
    }

A PKCS11 PrivateKey instance with algorithm type RSA will not be of type RSAKey, so this fails with a ClassCastException. Furthermore, the calling code in BaseSignatureAlgorithm swallows the exception stack trace.

I suggest that the validation check the declared type on the provided key using getType(), and perhaps validating modulus length iff the provided key actually implements an interface that allows this check to be performed.

[Brian Campbell]

I've tried to be careful with interfaces but I've not really had the opportunity to test things with PKCS11 and I guess that cast assumed too much. I'll look into changing the validation towards your suggestions. I don't see a getType() on Key or PrivateKey - did you mean getAlgorithm() or something else?

As a workaround you can use setDoKeyValidation(false) on JsonWebSignature, which will result in the problematic code being skipped when doing the signing (or verification). There's also setRelaxVerificationKeyValidation() and setRelaxDecryptionKeyValidation() on JwtConsumerBuilder, if working with that API.

[Bradley Hess]

Sorry, yes, meant getAlgorithm. That's what I get for relying on my memory. ;)

[Brian Campbell]

ba7374f -> address issue #77 'EC and RSA Key validations fail with Sun PKCS11 Provider' in the validate key checks by only checking RSA key length and EC curve parameters if the key is an instance of the type that has those methods. Otherwise just skip over the check as some provider keys (Sun PKCS11 according the issue) don’t implement the interfaces.

[Bradley Hess]

Awesome! Thanks, Brian.

[Benjamin Oommen]

Hi all, Is there any problem or risk in using setRelaxVerificationKeyValidation() ?
What exactly we are losing while setting this flag?

@Bradley Hess