PKCS#11 FIPS Indicator proposal review

Bob, all,

Dieter and I have reviewed and discussed the proposal extensively. Here is our feedback:

Section 4.13.2: Definition of CKA_VALIDATION_LEVEL : an ULONG type fits well to specify a FIPS Level like 1,2, 3 or 4. It doesnât fit that well to specify a Common Criteria Evaluation Assurance Level which may be 4+ for example. A type CK_UTF8CHAR might fit better for CC, and for other certification schemes as well?
Table 27: Typo CA_VALIDATION_VERSION -> CKA_VALIDATION_VERSION
Section 1.1.3: CKR_VALIDATION_INVALID may be misleading (in the sense âthe validation of the cryptographic module is not validâ). We suggest CKR_OPERATON_NOT_VALIDATED or CKR_OPERATION_NOT_APPROVED.
Error code CKR_VALIDATION_INVALID vs. validation indicators: Section 1.1.3 defines CKR_VALIDATION_INVALID as âthe requested operation violates one or more of the tokenâs validation policiesâ. Probably today, CKR_MECHANISM_INVALID is returned by the token. With the error code, the reason can be expressed more clearly. However, this supports only case 3) any non-FIPS compliant call will always fail as described by Bob in his introduction, but this error would not be returned in case 2) a special call or indicator the the current operation is FIPS compliant. Case 2) must use the FIPS indicator. Could or should case 3) return the error code and optionally use the validation indicator in addition, or can the validation indicator only be used if the operation returned CKR_OK? The description should be clear when to expect which return code or indicator.
New section âValidation indicatorsâ: We havenât understood yet why we need to distinguish between current operation flags and last operation flags? Couldnât a single âoperation flagâ indicate the status of the last function call in a sequence C_xxxInit â [ C_xxxUpdate â ] C_xxxFinal ?
- Assume a sequence of C_Derive calls: there is no current operation, thus the last operation flag must be queried. And it must be queried immediately after each C_Derive call, otherwise it will be overwritten by the last operation flag of the next C_Derive call.
- Assume a sequence of encryption operations, where each encryption applies to large documents and thus calls C_EncryptInit followed by 1..n C_EncryptUpdate followed by C_EncryptFinal. FIPS compliance may be determined during C_EncryptInit (e.g. when selecting a key with too short key size), or during some C_EncryptUpdate (e.g. when exceeding the number of blocks for a triple DES encryption operation after a while), or during C_EncryptFinal (because the provider always returns FIPS status with the final operation). For most operations, the FIPS state will not change with C_EncryptUpdate calls. And which/how many applications will query FIPS status after every single call to the crypto provider? Thus: Shouldnât we simplify the FIPS status handling by leaving out the current operations flag, and accept that the FIPS status can only be queried after the final operation? This assumes that an ongoing operation stays non-conforming until it is finished once it gets into non-conforming state; but it seems safe to assume this.
- On the other side we have message-based functions, where a single C_MessageâInit and C_MessageâFinal encloses multiple message operations; and where FIPS compliance would rather be queried at the end of a message encryption, but not after the C_Final call (C_Final will probably âneverâ be called for e.g. an OCSP responder up-and-running 24x7). Thus a last-operation flag linked to a C_Final call is not providing the necessary information, we need the current-operation flag.
- Ergo: expecting that an application queries the current-operation flag for some calls/operations but the last-operation flag for other calls/operations may be confusing and is error prone. Canât we just define a single flag which is set by each function call, i.e. the same indicator flag for C_...Init, C_...Update , C_...Final, C_Derive, message based functions, etc. Itâs then up to the application [developer] to check the FIPS flag either after every single call (to recognize a Non-FIPS operation already during Update) or at the end (i.e. after C_Final or after the last message block for a message-based operation) or after the only operation (C_Derive).
For optimization purposes an API might not call the token for every API call (examples are C_...Init, or C_...Update if the data size does not fill an algorithmâs block). Since the token must tell if an operation is compliant the API certainly cannot return CKR_VALIDATION_INVALID and the current operation flag also shows that itâs compliant (or there is an indicator âcanât tell yetâ). The specification must not make any assumption when the failing validation is returned, except for that the indication is correct when the operation has been completed.

Weâre looking forward to the next TC call.

Regards,

Daniel

pkcs11 message