PKCS#11
|
| Cryptographic Token Interface Standard |
PKCS#11 |
The CMS mechanism, denoted CKM_CMS_SIG, is a multi-purpose mechanism based on the structures defined in PKCS #7 and RFC 2630. It supports single- or multiple-part signatures with and without message recovery. The mechanism is intended for use with, e.g., PTDs (see MeT-PTD) or other capable tokens. The token will construct a CMS SignedAttributes value and compute a signature on this value. The content of the SignedAttributes value is decided by the token, however the caller can suggest some attributes in the parameter pRequestedAttributes. The caller can also require some attributes to be present through the parameters pRequiredAttributes. The signature is computed in accordance with the parameter pSigningMechanism.
When this mechanism is used in successful calls to C_Sign or C_SignFinal, the pSignature return value will point to a DER-encoded value of type SignerInfo. SignerInfo is defined in ASN.1 as follows (for a complete definition of all fields and types, see RFC 2630):
SignerInfo ::= SEQUENCE {
version CMSVersion,
sid SignerIdentifier,
digestAlgorithm DigestAlgorithmIdentifier,
signedAttrs [0] IMPLICIT SignedAttributes OPTIONAL,
signatureAlgorithm SignatureAlgorithmIdentifier,
signature SignatureValue,
unsignedAttrs [1] IMPLICIT UnsignedAttributes OPTIONAL }
The certificateHandle parameter, when set, helps the token populate the sid field of the SignerInfo value. If certificateHandle is NULL_PTR the choice of a suitable certificate reference in the SignerInfo result value is left to the token (the token could, e.g., interact with the user).
This mechanism shall not be used in calls to C_Verify or C_VerifyFinal (use the pSigningMechanism mechanism instead).
In order for an application to find out what attributes are supported by a token, what attributes that will be added by default, and what attributes that always will be added, it shall analyze the contents of the CKH_CMS_ATTRIBUTES hardware feature object.
For the pRequiredAttributes field, the token may have to interact with the user to find out whether to accept a proposed value or not. The token should never accept any proposed attribute values without some kind of confirmation from its owner (but this could be through, e.g., configuration or policy settings and not direct interaction). If a user rejects proposed values, or the signature request as such, the value CKR_FUNCTION_REJECTED shall be returned.
When possible, applications should use the CKM_CMS_SIG mechanism when generating CMS-compatible signatures rather than lower-level mechanisms such as CKM_SHA1_RSA_PKCS. This is especially true when the signatures are to be made on content that the token is able to present to a user. Exceptions may include those cases where the token does not support a particular signing attribute. Note however that the token may refuse usage of a particular signature key unless the content to be signed is known (i.e. the CKM_CMS_SIG mechanism is used).
When a token does not have presentation capabilities, the PKCS #11-aware application may avoid sending the whole message to the token by electing to use a suitable signature mechanism (e.g. CKM_RSA_PKCS) as the pSigningMechanism value in the CKM_CMS_SIG_PARAMS structure, and digesting the message itself before passing it to the token.
PKCS #11-aware applications making use of tokens with presentation capabilities, should attempt to provide messages to be signed by the token in a format possible for the token to present to the user. Tokens that receive multipart MIME-messages for which only certain parts are possible to present may fail the signature operation with a return value of CKR_DATA_INVALID, but may also choose to add a signing attribute indicating which parts of the message that were possible to present.