FIPS 140-3 Algorithm Certificate Mapping Workflow

Do not begin with a generic list of algorithms. Begin with one candidate CAVP certificate and one module service that plans to rely on it. CMVP Implementation Guidance 2.3.A says the algorithm validation certificate identifies the validated implementation name, version, and tested operational environment; the module certificate identifies the validated module name, version, and tested operational environment.

Ask whether this algorithm implementation, in this module build and environment, can support the service claim. IG 2.3.A requires the integrated implementation to remain unmodified and the CAVP-tested operational environment to be identical to, or fully included in, the environment used by the Cryptographic and Security Testing (CST) laboratory for module testing. If either condition fails, the existing certificate does not satisfy that binding rule; record the row as requiring new CAVP testing or CST laboratory review.

A useful mapping row connects a module service to the algorithm evidence behind it. For each service, list the callable function or service name, the approved algorithm used, the CAVP certificate that supports that implementation, and the implemented service indicator. The Security Policy must explain the indicator, but its prose is not itself an indicator.

Keep protocol and component validation logic separate from raw algorithm certificates. CMVP guidance includes cases where Component Validation List (CVL) entries, key derivation functions (KDFs), key agreement pieces, entropy certificates, or protocol claims have their own documentation conditions. The mapping should show those limits instead of implying that a CAVP certificate validates an entire protocol or product.

For software modules, the mapping has to name the operating system, platform, and processor used for the module claim. If a hypervisor was part of the tested environment, include it. Do not generalize a certificate from one operating system to another, from a 32-bit processor to a 64-bit claim, or from one hardware implementation to another without cited validation support.

The workflow should make environment mismatches visible early. A row that says only "AES certificate available" is not enough; the reviewer needs to know whether the CAVP certificate environment matches the module environment and whether the implementation was retested where required.

Example: an algorithm implementation validated on a 32-bit platform cannot support a module claim on a 64-bit-only platform under IG 2.3.A merely because the source code or algorithm name is the same. Record that row as not mapped and send the 64-bit implementation through the CAVP and CST laboratory path; memory size and processor frequency do not cure the bit-size mismatch.

Use a compact row structure so reviewers can see whether the certificate supports the service claim without treating the mapping sheet as a CMVP decision.

Row fields: module service; algorithm or tested component; CAVP certificate number; implementation name and version; selected capability, mode, and parameter set; CAVP-tested operational environment; module operational environment; Security Policy location; service indicator; caveat or usage restriction; change trigger.

Example decision outcomes: mapped with no change; mapped with caveat; cannot map because the implementation changed; cannot map because the operational environment does not match; hold for CST laboratory or CMVP guidance.

Assign the cryptography owner to assemble the row, the module engineer to attest to the integrated binary and build configuration, and the CST laboratory contact to resolve any claimed environment inclusion or retest path. Retain the CAVP certificate data, build manifest, environment comparison, Security Policy cross-reference, reviewer, decision date, and approval condition with the module release.

Treat the mapping as release evidence, not a one-time spreadsheet. Recheck rows when a cryptographic library changes, an algorithm implementation is patched, compiler or build flags affect the implementation, the processor or operating system changes, a hypervisor is added, a hardware implementation moves to a new device, or a service starts using a different algorithm path.

For modules relying on bound or embedded modules, keep the dependency visible. The implementation-under-test (IUT) documentation and Security Policy need clear separation between the module under test and the embedded or bound validated module, including certificate number, version, service, algorithm, sensitive security parameter, self-test, and zeroisation distinctions where applicable.

Most failures in this workflow come from over-reading an algorithm certificate. A CAVP certificate is evidence for a tested algorithm implementation in a tested environment; it is not a blanket validation of the whole module, product, protocol, cloud deployment, or future release.

The cleanest public claim is specific: name the module certificate or validation status separately from the algorithm certificate evidence, and do not state that a service is approved unless the service table, indicator, Security Policy, and certificate mapping support the claim.