Quoting the PKCS#11 specification:
Certificate objects (object class CKO_CERTIFICATE) hold public-key or attribute certificates. Other than providing access to certificate objects, Cryptoki does not attach any special meaning to certificates. (§4.6.2)
So no, you can't do anything with a certificate object other than store it and retrieve its attributes.
This is confirmed in the specification of C_VerifyInit
:
The CKA_VERIFY
attribute of the verification key, which indicates whether the key supports verification where the signature is an appendix to the data, MUST be CK_TRUE
.
A certificate object is not a key and CKA_VERIFY
is not listed as a permitted attribute, so it can't be used for C_VerifyInit
.
The ability to store a certificate in a token is primarily useful when it's stored together with the private key. You use the private key to sign data (including authentication challenges) and send the certificate signed by a CA as part of authentication. It's useful to store the private key in a cryptographic token because this offers better protection against a compromise of the key. It isn't particularly useful to store a public key or a certificate in a cryptographic token because it isn't confidential¹. The point of putting the certificate in the token is that it's easier to manage the key lifecycle (creation, enrollment, destruction, …) if the key and the corresponding certificate(s) are stored in the same location.
¹ Putting the certificate in a cryptographic token guarantees its integrity, but that's usually pointless because the code using the certificate is outside the token. You don't gain anything by preventing modifications to the certificate if you can change the code that uses the certificate to use a different one or ignore the verification result.