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
Utimaco IS GmbH
Germanusstr. 4, D.52080 Aachen, Germany, Tel: +49-241-1696-0, www.utimaco.com
Seat: Aachen â Registergericht Aachen HRB 18922
VAT ID No.: DE 815 496 496
Managementboard: Stefan Auerbach (Chairman) CEO, Malte Pollmann CSO, Martin Stamm CFO
This communication is confidential. If you are not the intended recipient, any use, interference with, disclosure or copying of this material is unauthorised and prohibited. Please inform us immediately and destroy the email.
|