Re: [pkcs11] FiPS Indicator proposal.

[Robert Relyea <rrelyea@redhat.com>]

I'm about to update my proposal, so I've read through the guidance.

On 7/21/21 9:54 AM, Robert Relyea wrote:

For those who haven't read the details go to 2.4.CÂ Approved Security Service Indicator inÂ

https://csrc.nist.gov/CSRC/media/Projects/cryptographic-module-validation-program/documents/fips%20140-3/FIPS%20140-3%20IG.pdf

The only actual requirement present is that there needs to be an indication that some approved service was used.

So unlike FIPS140-2 where you can have a module mode which is on or off, you need to be able to indicate that a service was used that is approved.

There is no requirement to separate this across multiple services.

If you only have approved services then you have nothing you actually have to do.

"In this case, an explicit indication via the use of a static code or an implicit indication via the successful completion of a service is sufficient."

It is explicit that successful completion of the service is a sufficient indicator.

The full paragraph reads "A global indicator for the module that *only* supports services in an approved manner. Non-approved servcies are either not implemented, or the module itself explicitly prevents.... In this case...

This is one case where I mentioned in the original design.

So if you are a traditional module with the concept of a FIPS mode in which only approved services are accessible then the successful function return codes are the required indicator.

Nothing new is required.

It is only when you have a mixture of approved and non-approved that something different needs to be provided - but again it is a rather "simplistic" concept.

"For those modules implementing both approved and non-approved security services, a shared indicator common to multiple approved security services can be used."

There is nothing about needing to know what the current not-yet-completed service status is.

So there is actually nothing that indicates we need to have the FIPS_OK and FIPS_LAST_OK flags.

That really makes the proposal a bit of a mix in terms of what it is doing - and it isn't solving a concrete FIPS requirement but seems aimed at something different.

As part of this paragraph: "however, if the module provides support of running multiple security services simultaneously (that can alternate between approved & non-approved security services), Then the modules should clearly make the distinction between the running services that provide the indicator accordingly."

    This is clearly the case with NSS.

I also think that we should be looking at validations in a more general context and not looking at this as slipping a flag (or two) into the session info structure.

In the KMIP TC we took a much more general approach about being able to report information about validations.

SeeÂhttps://docs.oasis-open.org/kmip/kmip-spec/v2.1/os/kmip-spec-v2.1-os.html#_Toc57115737 for a direct link to the current specification (and this is unchanged in the almost finished 3.0 specification).

So I think the new proposal will have a new object: CKO_VALIDATION. It would have attributes mapping to all the fields in the kmip validation structure, plus the following:

CKA_VALIDATION_FLAG_VALUEÂ - CK_ULONG with a single bit set to indicate the bit in the following flags.

CKA_VALIDATION_MODULE_IDENTIFIER - utf8 string - They value that matches the module name and version number in the given validation's documentation for the module.

[CKA_VALIDATION_GLOBAL_INDICATOR] - bool - True if any valid operation has occured on this crypto module.

Object (maybe only key objects?) Will have the following attribute:

CKA_VALIDATION_FLAGS - CK_ULONG : The or of all the validation flags that this key/object was created with in a compliant way.

In addition there will be 3 new fields on the session, which we can reference with a new API call:

Current_validation_flags or of all the validations that are current on this session (better words in english needed here).

Last_validation_flags state of the last operation that completed on the session.

Global_validation_flags or of any operations that ever completed on this session.

I'm agnostic about whether the new API call can return all three at once, or take a parameter to determine which flags it wants.

    bob