On 2/15/23 3:48 AM, JOHNSON Darren wrote: 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. So we've approved the FIPS Indicator proposal and the Async proposals, but if there are issues we can probably revisit them if they are critical enough. It think you've identified some issues that need to be fixed. 1) In 4.13.2, CKA_VALIDATION_FLAGS is defined as Flags Identifiying this validation i n 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? This is the Validation flags on the key objects that are returned by single shot operations. This allows us to chain validation information. I thought I has an explanation of that in the text somewhere. 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? Good point, it should say that new bits cannot be turned on. Yes it would need a new footnote. 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? yes, I think it can only be specified in the C_CreateObject case in all other cases it's implict from the generating operation. 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. yes, I should probably strike both generally's. 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. Agreed. 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? There is. It's called a validation object and it's part of the spec. 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. They are validation specific, which is why we don't specify them. For example, the FIPS would be be specified in your FIPS security policy. Guidance for each the various validations make it impossible to specify this in PKCS #11. 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? The last operation on the session conformed to the validation. 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. Hmmm, They are the same flags as in CKA_VALIDATION_FLAGS. I'm sure I specified that they matched the flags in the Validation Objects (So each token has their own definition on what the flag bits mean which are specified in the validation objects). Are you sure that's not there? bob Thanks Darren