FIPS Mode Indicator

Hi,

I’m catching up on all the proposals I missed. So I’m sorry if these types of questions were already discussed and resolved.

1) In 4.13.2, CKA_VALIDATION_FLAGS is defined as “Flags Identifiying this validation in sessions and objects.” I’m not sure what this is supposed to mean. This probably means it needs a better description here, or elsewhere in the spec?

2) In section 1.1.2, the table shows CKA_VALIDATION_FLAGS has footnote 12. 12 is “Attribute cannot be changed once set to CK_FALSE. It becomes a read only attribute”. “CK_FALSE” isn’t applicable to this attribute, unless we are equating CK_FALS==0 == no flags set? If that is the case, we probably should do something better/more explicit. Shouldn’t there be a new footnote for this type of attribute; attribute that is set by the module and can never be modified? Is my understanding about the rules around this attributes?

For the avoidance of doubt, shouldn’t footnote 1 “must not be specified with C_CreateObject” also be listed? Unless a new footnote is created.

This raises a different question. We don’t have a footnote regarding what must/can/cannot be specified during C_DeriveKey. Wouldn’t that apply here, and in many other case?

3) The proposal has this note

“Notes to application. Many of these operations chain, so in SSL, if the final key objects have the

appropriate flags set in CKA_VALIDATION_FLAGS, then it generally means that all the operations

(unwrap, key_derive, etc.) occurred in a manner that matches the modules’s validation, so the

application would generally only need to query the validation flags of the final keys.”

The term “generally” is used twice here, which just means usually, or in most cases. That isn’t very clear, about whether it is ok to only check the flags on the final key.

I would expect that if the final key has validation flags, then it means that all operations performed and all keys that were used to eventually establish the final key (unwrap, derive, etc) occurred in a manner that matches the modules validation. The application would only need to query the validation flags of the final key. Something more explicit about what it means.

4) Specific to FIPS indicators, should the module have flags to identify which type of indicator it supports? Three type of indicators are defined. But how will an application know which to use without referring to product specific documentation and implementing product specific logic on which indicators to check?

5) As a provider, I can imagine how I “might” use some of the attributes associated with the CKO_VALIDATION objects. But are there any examples on how the specification expects these attributes to be set? examples would go a long way for addressing any questions.

6) C_GetSessionValidationFlags

The “type” parameter is defined as CK_SESSION_VALIDATION_FLAGS_TYPE. Which is defined as “selects the validation flags to return”. What is “CKS_LAST_VALIDATION_OK” supposed to mean?

7) In general, there are a lot of places where “flags” are used. But no flags are defined, nor are their meaning. So it isn’t clear to me on how a lot of these pieces all come together.

Thanks

Darren

pkcs11 message