As always, having a concrete proposal to read makes it a lot easier to have a discussion on the topic.
I don't get the whole concept here of having both a current and a last okay flag - there is no requirement for that in the IGs.
For those who haven't read the details go to 2.4.CÂ
Approved Security Service Indicator inÂ
It is explicit that successful completion of the service is a sufficient indicator.
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.
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.
Note that the flags returned in the flags field of a C_GetSessionInfo are the same flags passed into C_OpenSession - that is what applications expect. They aren't really "dynamic" as such in current usage - just a copy of what the caller provided when they called C_OpenSession. You've basically changed a fundamental concept here in this change.
Separately, the wording about "conforming to the approved security policy" is in itself highly problematic - as there are things in the security policy that are about what the operator does and not about what the module itself does. The module cannot make any such claim about the operator's action - only about its configuration and use of its services. That means narrowing such statements to the configuration the module is operating under being consistent with configurations that is allowed in the security policy (but even that wording too has challenges as security policies are pretty broad documents).Â
I think we should also generalise things - so this isn't a FIPS specific thing as such - but is about operating in a mode that matches a validation or some form or another.
There are a lot more validation schemes in use than FIPS140-2 and FIPS140-3. And if we did note this as specific to FIPS140-3Âthen we should have FIPS140-3 in the name itself - FIPS isn't specific enough.
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.
There are also a pile of different ways we could approach this - like using the CK_C_INITIALIZE_ARGS struction to pass in a flag or add an additional function for indication of approved function usage.
Or we could use the CK_NOTIFY capability in the C_OpenSession and add a flag to indicate an approved service was used.
We could indicate in the flags to initialise what level of notifications we want to have processed or something along those lines.
I think the notify approach is actually a much cleaner way to meet the requirements than your proposed new signaling approach in the session flags.
You could then also add notifications for non-approved function usage or other such potentially useful concepts.
I also think it is important to keep in mind that the problem here is that the module has to have some way to indicate this - there is no requirement on the application to use the module capability.Â
Tim.