Re: [pkcs11] FIPS Mode Indicator

[Robert Relyea <rrelyea@redhat.com>]

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 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?

    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

Â

Â