OASIS PKCS 11 TC

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.

On 22/10/2021 13:02, Daniel Minder wrote:   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? If this is intended as purely information for human consumption then a CK_UTF8CHAR makes sense. However if an application is intended to make decisions based on this value the data should be structured otherwise we are delegating parsing of that field to the application and wrong decisions will be made. See the issues with apps not understanding that Python 3.10 came after 3.9 and thinking it was 3.1 instead. -- Darren J Moffat

On 10/22/21 5:02 AM, Daniel Minder wrote: 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? CK_UTF8CHAR is probably most general. This is likely an informational (pass through to your UI) type interface. CK_ULONG is easier for matching, but CK_UTF8CHAR means we won't have to define any special defines for non-integer levels (but it also means it's likely one vendor puts '4+' and another puts '4plus') as well.. Table 27: Typo CA_VALIDATION_VERSION -> CKA_VALIDATION_VERSION ack. 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. I like both of these better than my proposed CKR_ value. 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. In the case you are failing, CKR_MECHANISM_INVALID would still comply. I don't know if other vendors would want to continue using the later, or use the validation status error code to give more detail. This error code is mostly an afterthought on my part since I'm likely to just use the indicator in my token. If it's used, then when NSS updates, it will return an error related to the mechanism being unvalidated rather then unknown or invalid. 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 ? It's not needed for Cxxx - CxxxFinal. It is needed for C_WrapKey() which no active 'operation' you can access (unless you break pkcs11 rules and try to read the session on another thread), nor any object 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. That is absolutely positively correct (for that session). I have three comments about this: 1) the application controls is sessions and access to the token, so the application knows which C_Derive operation it called on that session. 2) C_Derive also returns a key object which receives the CKA_VALIDATION_FLAG attribute that doesn't change on the second Derive, 3) C_WrapKey has the same issue, except it doesn't return a key object, so it *must* be queried right after the operation. It is the C_WrapKey operation I am trying to solve with last. Given you need it for C_WrapKey, I see no reason not to allow it for other session queries as well. Again the application is the manager of his sessions, not one else can use his sessions without violating the PKCS #11 spec (because you need to guarrentee thread sequencing on the application level to the session...e.i. you can't call the same session twice from multiple threads at the same time). 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? Hmm that's interesting. You aren't arguing for removing last state, you are arguing for removing current state. I think there's a slight complication with overlapping operations (C_EncryptDigest). but that complication exists in the current state as well.. I think my only objection is my current prototype implementation in NSS is able to tell you that your current ssl connection has all FIPS indicators because I'm able to query the current ssl state (before the connection finishes), so there is a real world application use for the current state. 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. I'm pretty sure it's required. 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. yup, that's the current issue I also have with my SSL FIPS indicators. 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). Unfortunately I think we've just argued that we need both and have to deal with the potential ambiguity. 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. So in practice the CKR_VALIDATION_INVALID* call and the FIPS indicator will likely be mutually exclusive. That is an application that return CKR_VALIDATION_INVALID won't update the FIPS indicator because the function never executed. I envision tokens like NSS would never return CKR_VALIDATION_INVALID, but would just update the FIPS indicator. Some tokens will always return CKR_VALIDATION_INVALID for invalid mechanism, and always return FIPS indicator on (this is using 'implicit indicator method' of NIST). There may be tokens that do a mix. In that case the effect of the mechanism the was CKR_VALIDATION_INVALID would be null on the FIPS indicators. BTW, I don't expect the application would call the API every call. It *could* in principle, but in general applications really only care if this macro operation was completed using properly FIPS validated modules. So, my SSL chaining example. NSS doesn't call the FIPS indicator every call, only when the application asks 'hey is the current thing I'm doing fips'. In the case of SSL we can query just the state of the two encryption session (and two mac session in the case on non-AEAD) and merge those into a single indicator. The FIPS Validation state flows from the key agreement to the key derive to the actual encryption (through the key's validation status flag)), making it unnecessary to query each step along the way. Bob *I'm still using the old name, but I like your new names better. 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.