Search every question across sub-FAQs

For SP 800-208 HSS, IG C.O lists concrete conditions rather than a self-attestation shortcut. If HSS key generation or signature generation is implemented, the underlying LMS key generation and LMS signature generation operations need CAVP certificates. If HSS signature verification is implemented, the underlying LMS signature verification operation needs a CAVP certificate.

The same IG requires every LMS parameter set used inside the HSS tree to have the applicable CAVP certificates. It also requires CSTL source-code review of each supported HSS operation against RFC 8554 key generation, signature generation, and signature verification sections, with the results documented in TE02.20.04 of the Test Report.

Keep a compact evidence packet for each vendor-affirmed claim. It should identify the IG section, the module and version, the exact algorithm or key-generation method, the Security Policy table or disclosure, the CAVP certificates that remain required, and the CSTL or test-report evidence that the IG says must exist.

For SP 800-133 key generation, IG D.H says vendor affirmation is required for methods covered by Sections 4 and 6.3 when a symmetric key or seed for asymmetric key generation starts with a random bit string. It also says the Security Policy must provide details for each method, and that the validation certificate has a CKG entry only when the module generates keys for symmetric-key algorithms.

Start with the validated cryptographic module, not the product or platform around it. FIPS 140-3 specifies requirements for cryptographic modules, and CMVP guidance treats approved-mode analysis at the level of module services, security functions, indicators, and Security Policy descriptions.

For a customer, procurement, or audit answer, identify the specific module certificate and version, the service being called, the approved algorithm or process used by that service, and the operator-visible indicator that shows the service is approved. A broad statement that a product is "in FIPS mode" is not enough when the module can expose approved and non-approved services or use context-sensitive algorithms.

The strongest evidence is the set of records that let a reader trace the answer from a module certificate and Security Policy to the exact service behavior. The CMVP guidance says the Security Policy must list approved and non-approved services with details and applicable indicators; the Security Policy can explain the indicators, but its text alone does not satisfy the indicator requirement.

Evidence should also show the treatment of non-approved algorithms. CMVP guidance allows some non-approved algorithms in approved mode only when no security is claimed and the use is documented in the Security Policy; non-approved security functions must not be used in approved mode.

Most approved-mode mistakes come from treating the mode as a switch that validates every cryptographic operation. FIPS 140-3 and the CMVP guidance require a more precise answer: which module, which service, which approved security function, which indicator, and which Security Policy rule.