In general, when a Cryptoki call is made, error codes from Section (other than CKR_OK) take precedence over error codes from Section , which take precedence over error codes from Section , which take precedence over error codes from Section . One minor implication of this is that functions that use a session handle (i.e., most functions!) never return the error code CKR_TOKEN_NOT_PRESENT (they return CKR_SESSION_HANDLE_INVALID instead). Other than these precedences, if more than one error code applies to the result of a Cryptoki call, any of the applicable error codes may be returned. Exceptions to this rule will be explicitly mentioned in the descriptions of functions.
10.1.8. Error code “gotchas”
Here is a short list of a few particular things about return values that Cryptoki developers might want to be aware of:
As mentioned in Sections and , a Cryptoki library may not be able to make a distinction between a token being removed before a function invocation and a token being removed during a function invocation.
As mentioned in Section , an application should never count on getting a CKR_SESSION_CLOSED error.
The difference between CKR_DATA_INVALID and CKR_DATA_LEN_RANGE can be somewhat subtle. Unless an application needs to be able to distinguish between these return values, it is best to always treat them equivalently.
Similarly, the difference between CKR_ENCRYPTED_DATA_INVALID and CKR_ENCRYPTED_DATA_LEN_RANGE, and between CKR_WRAPPED_KEY_INVALID and CKR_WRAPPED_KEY_LEN_RANGE, can be subtle, and it may be best to treat these return values equivalently.
Even with the guidance of Section , it can be difficult for a Cryptoki library developer to know which of CKR_ATTRIBUTE_VALUE_INVALID, CKR_TEMPLATE_INCOMPLETE, or CKR_TEMPLATE_INCONSISTENT to return. When possible, it is recommended that application developers be generous in their interpretations of these error codes.