In FIPS 140-2 Validations, Why So Much Redundant Data Redundancy in FIPS 140-2 Validations? (C23c)
When working on FIPS 140-2 validations, labs and the CMVP have to handle a lot of information, in many different places. It is not always trivial to ensure that this information is consistent across documents, because entering this information is primarily a manual process – this is one of the reasons why the CMVP provides the labs with comments.
For example: CAVS certificates are manually copied from emails received from CAVP to at least the report, the Security Policy and the draft FIPS 140-2 certificate; the lists of Approved, non-approved but allowed, and non-Approved algorithms are in the report, the Security Policy and the draft certificate (until recently); the list of Critical Security parameters (CSPs) are listed in the report and in the Security Policy; the list of services is in the report and the Security Policy; the algorithms options, block chaining modes and key sizes are listed in the report, the Security Policy and on the CAVS certificate.
This presentation will try to determine the following:
• Which information is redundant?
• Why is it redundant (lab processes, CMVP software, guidances, etc.)?
• What the best location for the redundant information?
• How can we reduce duplication of information across documents if it is not necessary?
• Would starting a working group be appropriate to tackle these questions?
This would help the laboratories to be more efficient and less error prone in their process of testing and validating FIPS 140-2 modules. It would also help the CMVP in reviewing and verifying the information during the coordination phase, making the overall process clearer and easier to manage.