Notices

[3-31-2017] -- Using modulus sizes other than 2048 and 3072 bits in RSA signature generation:

The CT group at NIST has made the decision that the RSA moduli of any length not smaller than 2048 bits may be used when generating the RSA signatures. This policy is already reflected in SP 800-131A Rev1, Section 3, but not yet in the FIPS 186-4 standard, which will be updated later.

At least one of the RSA modulus lengths supported by the module for RSA signature generation shall be 2048, 3072, or 4096 bits. The RSA signature algorithm implementations shall be tested by a CST lab for all implemented RSA modulus lengths where CAVS testing is available.

Some of the RSA key generation methods described in Appendix B.3 of FIPS 186-4 rely on the use of the auxiliary primes p1, p2, q1 and q2 that must be generated before the module generates the RSA primes p and q. Table B.1 in FIPS 186-4 specifies, for RSA modulus lengths of 2048 and 3072 bits only, the minimum bit lengths and the maximum total length of the auxiliary primes. When implementing the RSA signature generation algorithm with other approved RSA modulus sizes, the vendor shall use the limitations from Table B.1 that apply to the longest RSA modulus shown in Table B.1 of FIPS 186-4 whose length does not exceed that of the implementation’s RSA modulus. In particular, when generating the primes for the 4096-bit RSA modulus the limitations stated for the 3072-bit modulus shall apply.

The use of the approved hash functions in digital signatures is documented in SP 800-131A Rev1, Table 9. Please note that the choice of a hash function may affect the security strength of the RSA signature algorithm.

Per IG 9.4, Note3, an RSA known-answer test for signature generation may be implemented for any approved RSA modulus size supported by the cryptographic module; that is, any implemented RSA modulus size of at least 2048 bits.

The use of the 1024-bit moduli in RSA signature verification is still approved, per SP 800-131A Rev1.

This guidance is effective immediately and will be formalized in an IG in the future.

[Updated 3-31-2017][Updated 3-22-2016] -- NIST CMVP Fees:

Cost recovery fees are collected for NIST CMVP report review of new module submissions, modified module submissions, and for report reviews that require additional time due to complexity or quality. These fees are referred to as Cost Recovery (CR) and Extended Cost Recovery (ECR). Modules are not validated unless all applicable fees have been collected by NIST Billing. Please see CMVP Management Manual PDF for further information.

Currently the CR fee is applicable for IG G.8 Scenarios 1A, 1B, 3 and 5; the CR fee is not applicable for IG G.8 Scenario's 1, 2, and 4. The ECR fee is applicable per the overall Security Level to all test reports received by NIST CMVP under FIPS 140-2 IG G.8 (all five scenarios).

The following fee structure is effective October 1, 2017:

• IG G.8 Scenario's 1, 2 and 4: CR fee N/A, ECR fee: $1000
• IG G.8 scenario's 1A and 1B: CR fee $1500, ECR fee: $1000
• IG G.8 Scenario 3: CR fee $3000, ECR fee: $1500
• IG G.8 Scenario 5:
  • Security Level 1: CR fee: $6000, ECR fee: $3000
  • Security Level 2: CR fee: $8000, ECR fee: $4000
  • Security Level 3: CR fee: $8000, ECR fee: $4000
  • Security Level 4: CR fee: $8000, ECR fee: $4000

The following fee structure is effective October 1, 2016:

• IG G.8 Scenario's 1, 2 and 4: CR fee N/A, ECR fee: $1000
• IG G.8 scenario's 1A and 1B: CR fee $1500, ECR fee: $1000
• IG G.8 Scenario 3: CR fee $3000, ECR fee: $1500
• IG G.8 Scenario 5:
  • Security Level 1: CR fee: $6000, ECR fee: $3000
  • Security Level 2: CR fee: $8000, ECR fee: $4000
  • Security Level 3: CR fee: $11000, ECR fee: $5000
  • Security Level 4: CR fee: $15000, ECR fee: $6000

[Updated 06-01-2016][11-12-2015] -- Validation Sunsetting Policy

The CMVP is adopting a five year validation sunsetting policy, effective February 1, 2017. The CMVP will move all validation entries with most recent validation dates** prior to February 1, 2012 and all FIPS 140-1 validation entries from the Active Validation Lists to the Historical Validation List. The Historical Validation List is not to be used for procurement by federal agencies. To maintain compliance with FISMA, agencies that use modules on the Historical List must make a risk management decision whether to continue to use these modules or replace them with compliant modules from the Active Validation Lists.

Through January 31, 2017, vendors may reinstate affected modules in one of the following ways:

• Modules fully compliant with the latest standard and guidance: 1SUB scenarios, reaffirming the validation. Vendors must work with one of the NVLAP accredited Cryptographic and Security Testing Laboratories to prepare the submission for CMVP. The laboratory will review the module and confirm it complies with all applicable transitions (e.g. 2-key Triple-DES, RNG).
• Modules that require some maintenance changes: all available revalidation scenarios - see FIPS 140-2 Implementation Guidance - G.8.

**[Note: The most recent validation date for a module is the latest update of the validation certificate as the result of the original submission or any of the available revalidation scenarios (1SUB, 2SUB, 4SUB).]

• Effective July 1, 2016, for validation entries on the Historical List, the CMVP will only accept 1SUBs for administrative updates (e.g. updating contact information). The CMVP will not accept 1SUBs for any other types of updates (e.g. adding operating environments).
• Effective February 1, 2017, 1A and 1BSUB scenarios will inherit the sunset date of the original certificate.
• Effective February 1, 2017, 1SUB scenarios will not reset the sunset date.

[12-09-2015] -- Two-key TDEA transition, December 31, 2015

The Cryptographic Technology Group at NIST has confirmed the transition schedule for the Two-key TDEA provided in SP 800-131A. The CMVP will enforce the transition proactively. Accordingly, when the transition takes place the CMVP will proceed as follows:

Modules on the CMVP queue

• REVIEW PENDING or IN REVIEW: The laboratories/vendors will be asked to provide an updated submission that is fully compliant with the transition. Only compliant submission will be validated.
• COORDINATION: These module submissions will be handled like those in the REVIEW PENDING or IN REVIEW case.
• FINALIZATION: These module submissions will be handled like already validated modules.

1/2/4 SUBs for validated modules on the CMVP Active Validation Lists: When an updated Security Policy is submitted it will be required to comply with the transition.

[Updated 7-1-2016][Updated 11-24-2015][Updated 11-10-2015][03-16-2015] -- X9.31 RNG transition, December 31, 2015

The Cryptographic Technology Group at NIST has confirmed the transition schedule for RNGs (e.g., the X9.31 RNG) provided in SP 800-131A. Accordingly, when the transition takes place the CMVP will proceed as follows:

• Validated modules on the CMVP Active Validation Lists: The CMVP will classify the validations into four categories:
  • Category 1: Modules with DRBG's only.
  • Category 2: Modules without any DRBG's or RNG's.
  • Category 3: Modules with DRBG's and RNG's.
  • Category 4: Modules with RNG's only.

The CMVP will move all Category 3 and 4 modules to a Legacy Validation List, effective January 31, 2016. The Legacy Validation List is not to be used for procurement by federal agencies. However, impacted vendors who can substantiate a hardship case as the result of this deadline are encouraged to contact the CMVP as early as possible. The CMVP will work with them to minimize the negative impact.

The CMVP will provide vendors with a voluntary process for updating Category 3 and 4 modules on the Legacy Validation List and reinstating them back on the Active Validation Lists:

• 1SUB process: may be used to update the Security Policy and Certificate for modules without any module changes. After June 30, 2016, the CMVP will not accept 1SUBs to address the RNG transition.
• 1SUB-like process++: may be used to update modules with minimal changes. After June 30, 2016, the CMVP will not accept 1SUB-like submissions.

• 3SUB and 5SUB process: may be used for more substantial module changes.
• Modules on the CMVP queue
  • REVIEW PENDING or IN REVIEW: The laboratories/vendors will be asked to provide an updated submission that is fully compliant with the transition. Only compliant submission will be validated.
  • COORDINATION: These module submissions will be handled like those in the REVIEW PENDING or IN REVIEW case.
  • FINALIZATION: These module submissions will be handled like already validated modules.
• 1/2/4 SUBs for validated modules on the CMVP Active Validation Lists: When an updated Security Policy is submitted it will be required to comply with the transition.

++[Note:To take advantage of the 1SUB-like process vendors shall work with an accredited CST laboratory. The laboratory shall follow the procedure below:

1. The laboratory shall perform a Scenario 3 revalidation testing - see IG G.8.
2. The laboratory shall submit a 3SUB documentation, including a rationale for why this submission should be treated as a 1SUB-like. The rationale should be directly related to the RNG transition, i.e. modules in Categories 3 and 4 above. The RNG transition-related changes include changing all instances where an old RNG is used with a call to the new DRBG and the corresponding updates to the power-on self-tests and applicable health and conditional tests. The submisstion should not include any other security updates and the rationale shall state this explicitly. If it does, then cost recovery shall apply.
3. The CMVP will review the rationale and if accepted, NIST will waive the 3SUB cost recovery fee.
4. The report review will follow the 3SUB review process, except that the module does not have to adhere to the latest guidance and a new validation certificate will not be created. The CMVP will make a reasonable effort to expedite the processing of these submissions but the actual speedup will depend on the quality of the submissions. ]

[08-12-2015] -- NIST requests comments on using the ISO/IEC 19790:2012 standard as the U.S. Federal Standard for cryptographic modules

NIST is seeking public comments on using International Organization for Standardization/International Electrotechnical Commission (ISO/IEC) standards for cryptographic algorithm and cryptographic module testing, conformance, and validation activities, currently specified by Federal Information Processing Standard (FIPS) 140-2. The National Technology Transfer and Advancement Act (NTTAA), Public Law 104-113, directs federal agencies to adopt voluntary consensus standards wherever possible. The responses to this request for information will be used to plan possible changes to the FIPS or in a decision to use all or part of ISO/IEC 19790:2012 for testing, conformance and validation of cryptographic algorithms and modules. The Request for Information (RFI) posted in today’s Federal Register provides additional background, including seven questions that NIST is especially interested in having addressed, as well as NIST’s intentions.

Send public comments to: UseOfISO@nist.gov (also see the address for sending written comments)

Comment period closes: September 28, 2015.

**[Note: in the official RFI in the Federal Register Notice,
the link to the ISO site is incorrect; it should link to
http://www.iso.org/iso/catalogue_detail.htm?csnumber=52906 instead.]

[03-13-2015] -- The Third International Cryptographic Module Conference

The third annual International Cryptographic Module Conference will take place in November of this year. ICMC is a growing forum for global expertise in commercial cryptography. Industry leaders will convene November 4-6, 2015 in Hilton Washington, D.C., Rockville, MD to address the unique challenges faced by those who produce, use, and test cryptographic modules that conform with standards such as FIPS 140-2 and ISO/IEC 19790. Visit ICMC 2015 for complete information.

[Updated 12-09-2014][Updated 08-01-2014][Updated 06-05-2014][Updated 06-07-2007][Updated 01-24-2007][Updated 10-19-2006][Updated 04-19-2006][Updated 01-28-2003][07-18-2002] -- NIST CMVP Fees:

Cost recovery fees are collected for NIST CMVP report review of new module submissions, modified module submissions, and for report reviews that require additional time due to complexity or quality. These fees are referred to as Cost Recovery (CR) and Extended Cost Recovery (ECR). Modules are not validated unless all applicable fees have been collected by NIST Billing. Please see the CMVP FAQ PDF or CMVP Management Manual PDF for further information.

Currently the CR fee is applicable for IG G.8 Scenarios 1A, 1B and 5; the CR fee is not applicable for IG G.8 Scenario's 1, 2, 3 and 4. The ECR fee is applicable per the overall Security Level to all test reports received by NIST CMVP under FIPS 140-2 IG G.8 (all five scenarios).

The current fee structure is as follows:

• IG G.8 Scenario's 1, 2 and 4: CR fee N/A, ECR fee: $1000
• IG G.8 Scenario 3: CR fee $2000, ECR fee: $1000
• IG G.8 Scenario's 1A, 1B and 5:
  • Security Level 1: CR fee: $4250, ECR fee: $2000
  • Security Level 2: CR fee: $5750, ECR fee: $3000
  • Security Level 3: CR fee: $8000, ECR fee: $4000
  • Security Level 4: CR fee: $11000, ECR fee: $5000

The CMVP review of report documents will not begin for new report submissions received after September 30, 2014 until the applicable CR fee is collected by NIST Billing. NIST Billing will invoice the CR fee when the submission documents are received. Modules are not validated unless all applicable fees (CR and ECR) have been collected by NIST Billing.

For questions about methods of payments and associated handling fees, contact NIST Billing: Phone: 301-975-3880, FAX: 301-975-8943 and e-mail: billing@nist.gov.

[04-24-2014] -- Heartbleed Vulnerability

Reference: CVE-2014-0160 National Vulnerability Database.

The TLS and DTLS implementations in OpenSSL 1.0.1 before 1.0.1g do not properly handle Heartbeat Extension packets, which allows remote attackers to obtain sensitive information from process memory via crafted packets that trigger a buffer over-read, as demonstrated by reading private keys, related to d1_both.c and t1_lib.c, aka the Heartbleed bug.

This vulnerability, which may allow the reading of a cryptographic modules private keys, would violate FIPS 140-2 functional security objectives as described in Section 4.3. The CMVP has two objectives to meet: 1) To ensure that the CMVP does not validate any new cryptographic modules that contain this uncorrected vulnerability, and 2) To provide a process by which vendors can quickly patch and re-validate their existing cryptographic modules.

Users of validated cryptographic modules should contact the modules vendor to determine if the Heartbleed vulnerability is applicable and determine if a patch or replacement module is available.

Vendors of validated cryptographic modules for which the Heartbleed vulnerability is applicable should contact a NVLAP Cryptographic and Security Testing Laboratory to validate a corrective patch or replacement module.

[04-24-2014] -- The Second International Cryptographic Module Conference

Bringing experts together from around the world to confer on the topic of cryptographic modules. Discussion on technical topics underlying the implementation of a cryptographic module including physical security, key management, side-channel analysis, key management, cryptographic algorithm implementation testing, standardization (FIPS 140-2, ISO/IEC 19790), validation programs and more. November 19-21, 2014 in Rockville, MD. Register now. Details at: ICMC 2014

[04-05-2013] -- The First International Cryptographic Module Conference

Bringing experts together from around the world to confer on the topic of cryptographic modules. Discussion on technical topics underlying the implementation of a cryptographic module including physical security, key management, side-channel analysis, key management, cryptographic algorithm implementation testing, standardization (FIPS 140-2, ISO/IEC 19790), validation programs and more. September 24-26, 2013 in Gaithersburg, MD. Registration February through August 2013. Details at: ICMC 2013

[04-23-2012] -- Validation of Transitioning Cryptographic Algorithms and Key Lengths

The Implementation Guidance for FIPS PUB 140-2 and the Cryptographic Module Validation Program [ PDF ] has been updated to include IG G.14 which addresses how the validation of cryptographic algorithms by the CAVP and the validation of cryptographic modules by the CMVP will be affected during the transition as specified in SP 800-131A. This transition guidance was originally drafted as SP800-131B but has been moved to the CMVP Implementation Guidance IG G.14.

[04-23-2012] -- Validating the Transition from FIPS 186-2 to FIPS 186-3

The Implementation Guidance for FIPS PUB 140-2 and the Cryptographic Module Validation Program [ PDF ] has been updated to include IG G.15 which addresses the transition plan specific to the validation of FIPS 186-2 and FIPS 186-3. This transition plan addresses both the cryptographic algorithm validations and the cryptographic module validations that are conducted by the CAVP and CMVP, respectively. This transition guidance was originally drafted as SP800-131C but has been moved to the CMVP Implementation Guidance IG G.15

[11-24-2010] -- References to NIST Draft Special Publications of interest: NIST Draft Special Publications

Nov. 19, 2010 Special Publication 800-78-3 DRAFT Cryptographic Algorithms and Key Sizes for PIV

Sep. 23, 2010 Special Publication 800-56C DRAFT Recommendation for Key Derivation through Extraction-then-Expansion

Aug. 30, 2010 Special Publication 800-135 DRAFT Recommendation for Existing Application-Specific Key Derivation Functions

Jun. 24, 2010 Special Publication 800-132 DRAFT Recommendation for Password-Based Key Derivation - Part 1: Storage Applications

Jun. 16, 2010 Special Publication 800-131 DRAFT Recommendation for the Transitioning of Cryptographic Algorithms and Key Sizes

[08-17-2009] -- Comments received on White Paper: The Transitioning of Cryptographic Algorithms and Key Sizes

Updated comments as of August 14, 2009.

[07-02-2009] -- White Paper: The Transitioning of Cryptographic Algorithms and Key Sizes

Comments are requested on the white paper "The Transitioning of Cryptographic Algorithms and Key Sizes" by August 3, 2009. Please provide comments to CryptoTransitions@nist.gov.

Comments received as of July 24, 2009.

[11-30-2007] -- Non-Compliance update to Certificate #733

RNG (Cert. #216) changed to non-compliant. This RNG shall not be used for any services requiring the use of random bits.

[10-12-2007] -- Federal Register Notice
DEPARTMENT OF COMMERCE
National Institute of Standards and Technology
Docket No. 070321067–7068–01[ PDF ]

Public Draft of Federal Information Processing Standard (FIPS) 140-3, a revision of FIPS 140-2, Security Requirements for Cryptographic Modules

AGENCY: National Institute of Standards and Technology (NIST), Department of Commerce.
ACTION: Public comment period has closed.

[07-13-2007] -- Federal Register Notice
DEPARTMENT OF COMMERCE
National Institute of Standards and Technology
Docket No. 070321067–7068–01[ PDF ]

Announcing Public Draft of Federal Information Processing Standard (FIPS) 140-3, a revision of FIPS 140-2, Security Requirements for Cryptographic Modules

AGENCY: National Institute of Standards and Technology (NIST), Department of Commerce.
ACTION: Notice; request for comments.

[05-21-2007] DES Transition Plan and SP 800-57 Transition Plan has ended on May 19, 2007.

The Cryptographic Module Validation Program (CMVP) DES Transition Plan addresses the use of single key DES by Federal agencies, which are incorporated in cryptographic modules, validated to FIPS 140-1 or FIPS 140-2. Single key DES has been an Approved security function since the inception of the CMVP and the signing of FIPS 140-1 on January 11, 1994. The DES transition plan was developed to allow Federal agencies and vendors to smoothly transition to the stronger Approved security functions, specifically AES and Triple-DES.

The Cryptographic Module Validation Program (CMVP) NIST Special Publication (SP) 800-57 Transition Plan addresses the use of a minimum of 80 bits of security strength used by Federal agencies, as incorporated in cryptographic modules validated to FIPS 140-1 or FIPS 140-2. The SP 800-57 transition plan was developed to allow Federal agencies and vendors to smoothly transition to the use of a minimum of 80 bits of security strength.

CMVP Actions:

• References to DES as an Approved Security Function has been removed from FIPS 140-2 Annex A.
• All cryptographic module validation entries for DES as an Approved Security Function have been changed and DES has been moved as a non-Approved Security Function.
• All cryptographic module validation entries for security methods less than 80-bits of security strength have been modified to indicate these methods are not Approved for use in a FIPS Approved mode of operations.
• Referenced Security Policies or Certificate images have not been modified or updated. Vendors are encourage to provide updated Security Policies. Per FIPS 140-2 FAQ, certificate images are only provided representing initial validation and are not updated when validation changes occur.
• As a result of the above changes, if a cryptographic module validation is no longer valid, this module entry will be marked as "Revoked" with a link to the transition plan document.

CAVP Actions:

• The DES Algorithm Validation List has been archived and is still accessible for historical purposes only.
• The Triple-DES Algorithm Validation List has been modified to only recognize those implementations that support keying option 1 (K1, K2, and K3 are independent) and keying option 2 (K1=K2, and K3 is independent). If an implementation previously tested supported only keying option 3 (which is equivalent to DES), it has been marked as no longer NIST-Approved.
• The DSA Algorithm Validation List has been modified to only recognize those implementations that support 80-bits or more of security strength. This includes implementations that use a modulus size of 1024 bits. If an implementation previously tested did not support mod size of 1024 bits, it has been marked as no longer NIST-Approved.

Please contact the NIST Security Technology Group for additional information regarding the transition. William Burr 301-975-2914.

[03-06-2006] SP 800-57 Transition Plan

The Cryptographic Module Validation Program (CMVP) NIST Special Publication (SP) 800-57 Transition Plan addresses the use of a minimum of 80 bits of security strength used by Federal agencies, as incorporated in cryptographic modules validated to FIPS 140-1 or FIPS 140-2. The SP 800-57 transition plan was developed to allow Federal agencies and vendors to smoothly transition to the use of a minimum of 80 bits of security strength.

[09-20-2005] Key Establishment methods and Key Strength

NIST Special Publication 800-57, Recommendation for Key Management - Part 1: General, was published August, 2005. The CMVP is determining transition applicability to FIPS 140-2. Until this is determined, all new module validation certificates with key establishment schemes will include a caveat with the following text, IF the strength of the key establishment method does not equal the strength of the keys established per SP 800-57. For certificates issued prior to this notice, SP 800-57 Table 2 provides information regarding comparable key strengths.

Example caveat: RSA (key wrapping, key establishment methodology provides 80 bits of encryption strength);

[05-19-2005] Federal Register Notice

DEPARTMENT OF COMMERCE
National Institute of Standards and Technology
[Docket No. 040602169-5002-02]

Announcing Approval of the Withdrawal of Federal Information Processing Standard (FIPS) 46-3, Data Encryption Standard (DES); FIPS 74, Guidelines for Implementing and Using the NBS Data Encryption Standard; and FIPS 81, DES Modes of Operation

AGENCY: National Institute of Standards and Technology (NIST), Commerce.

[05-19-2005] DES Transition Plan

The Cryptographic Module Validation Program (CMVP) DES Transition Plan addresses the use of single key DES by Federal agencies, which are incorporated in cryptographic modules, validated to FIPS 140-1 or FIPS 140-2. Single key DES has been an Approved security function since the inception of the CMVP and the signing of FIPS 140-1 on January 11, 1994. The DES transition plan was developed to allow Federal agencies and vendors to smoothly transition to the stronger Approved security functions, specifically AES and Triple-DES.

[02-09-2005] DES Testing and Algorithm Validation

The CMT laboratories shall no longer accept DES algorithm implementations for validation by the CAVP. As of today, February 9, 2005, the CAVP will no longer issue algorithm certificates for DES algorithm implementations not under contract for testing by the CMT laboratories at the time of receipt of this notice.

[01-12-2005] Federal Register Notice

DEPARTMENT OF COMMERCE
National Institute of Standards and Technology
[Docket No. 041217352-4352-01]

Announcing Development of Federal Information Processing Standard (FIPS) 140-3, a revision of FIPS 140-2, Security Requirements for Cryptographic Modules

AGENCY: National Institute of Standards and Technology (NIST), Commerce.

ACTION: Notice; request for comments.

[12-16-2003] AES MAC for OTAR for use in radios.

Effective December 12, 2003, the CMVP will recognize the use of AES MAC (CBC-MAC based on AES defined in Project 25 TIA-102.AACA-1) for the Digital Radio Over-the-Air Rekeying (OTAR) Protocol when operated in a FIPS Approved mode. Further details in CMVP FAQ.

[08-07-2003] With the passage of the Federal Information Security Management Act of 2002, there is no longer a statutory provision to allow for agencies to waive mandatory Federal Information Processing Standards. For further information, please go to the CMVP FAQs Section 3.2.

[06-12-2003] -- CNSS Policy No. 15, Fact Sheet No. 1: [ PDF ]

National Policy on the Use of the Advanced Encryption Standard (AES) to Protect National Security Systems and National Security Information, June 2003.

[02-10-2003] -- Development of Cryptographic Module Validation Program Management Processes:

The U.S. National Institute of Standards and Technology (NIST) and the Communications Security Establishment Canada (CSEC) jointly manage the Cryptographic Module Validation Program (CMVP). The CMVP validates commercial cryptographic modules to Federal Information Processing Standard (FIPS) 140-2 and other cryptography based standards such as algorithms. Products validated as conforming to FIPS 140-1 or FIPS 140-2 are accepted by the Federal agencies of both countries for the protection of sensitive but unclassified information (Government of the United States) or designated information (Government of Canada).

In the CMVP, vendors of commercial cryptographic modules use independent, accredited Cryptographic Module Testing (CMT) laboratories to have their modules tested. Laboratories accredited by National Voluntary Laboratory Accreditation Program (NVLAP) perform cryptographic module compliance/conformance testing.

The CMVP Team has begun the process of reviewing and updating its CMVP management processes. The intent is to better define the policies and processes that govern the CMVP Team, the laboratories and the vendors.

The deliverable is the CMVP Management Manual that will refine the already existing policies and collate them in one document. The CMVP Team will also add new policies, processes and requirements that will affect present and new CMT laboratories, and the vendors of validated cryptographic modules. Amongst other things, new requirements will be added in the areas of:

• CMT laboratory personnel
• Communication between the CMVP, CMT laboratories, vendors and consulting firms

The first draft of the CMVP Management Manual is expected to be available for public review during the fall of 2003 and will be finalized during the winter of 2004.

[02-04-2002] -- FIPS PUB 140-2 Page v, Implementation Schedule:

"Agencies may retain and use FIPS 140-1 validated products that have been purchased before the end of the transition period." Clarification: Agencies may continue to purchase, retain and use FIPS 140-1 validated products after May 25, 2002.