The Cryptographic Algorithm Validation Program (CAVP) recently issued updated guidance regarding the use of advertising or promotional language in all of the fields posted as part of algorithm certificates, including the implementation name and description; this guidance has been posted on the CMUF as well.

CAVP provides validation testing of approved cryptographic algorithms and their individual components. Cryptographic algorithm validation is a prerequisite of cryptographic module validation. An algorithm implementation successfully tested by a lab and validated by NIST is added to an appropriate validation list, which identifies the vendor, implementation, operational environment, validation date, and algorithm details.
This information is collected in data fields that are eventually published on NIST’s Computer Security Resource Center (CSRC) website as part of the official algorithm and entropy validation certificates, and thus serve a very specific purpose: to list the tested and validated capabilities of a product. However, as many of these collected data fields are entered using a free-form text field, it is sometime used by a vendor as a marketing tool to provide product details that may not be directly related to the implementation being tested.
This has led to the CAVP clarifying that any information provided for certificate posting should only include objective, factual information about the implementation—limited to details that have been verified through CAVP (or Entropy Source Validation, ESV) testing.
Going forward, if the CAVP identifies promotional or otherwise inappropriate content in any data field, that submission will be rejected. Furthermore, if an issue is discovered during a lab’s request that impacts an ongoing validation, the entire validation process may be placed on hold until the lab submits a corrected submission.
The CAVP acknowledges that this approach is not without its complexities, particularly given the subjective nature of evaluating descriptions and implementation names. In cases of uncertainty, the CAVP Program Manager will have final authority in determining whether a module description is appropriate.
These changes, as the CAVP states, aim to ensure consistency and maintain the integrity of data published on CSRC, starting with all data generated by the CAVP from this point forward.
Here are some examples of descriptions the CAVP thinks is inappropriate:
- Module XYZ frees up developer resources by providing efficient APIs for ABC algorithms.
- This description should be updated to say “Module XYZ provides APIs for ABC algorithms.”
- Fast, secure, portable Module XYZ Java package library.
- This is close, but the description should remove “fast” and “secure.” In this case “portable” is a property of the technology and the CAVP can accept that.
atsec will work with the customers to make sure the description submitted will meet the requirements of this new guidance to avoid any issues.