- Previously, NIST had left open the possibility of another public comment period. The schedule now indicates that another public comment period will occur in 1Q 2012.
- Since it has been some time since the last public review, I am expecting a 60 day public review period (perhaps it will be only 30 days? -- share your thoughts in the comment section).
- After the comments have been addressed, the Secretary of Commerce receives the FIPS 140-3 publication for signature. Previous estimates allow for 6 months for the Secretary of Commerce to sign.
- My unofficial estimate for FIPS 140-3 reports to be accepted by the CMVP is now 2Q 2013 (at the earliest).
- My unofficial estimate for the last date FIPS 140-2 reports will be accepted by the CMVP is the end of 2013 (which allows for a 6 month transition period from 140-2 to 140-3).
September 21, 2011
Update: Unofficial FIPS 140-3 schedule
Here are my thoughts on the current FIPS 140-3 schedule:
September 20, 2011
Update: CMVP review times for FIPS 140-2 validations
Recent FIPS 140-2 submissions have shown an increase in review time by the CMVP. Since my last update, reports submitted by InfoGard have experienced CMVP review times between 9 and 12 weeks -- although one report submission took only 4 weeks.
(In my May 16 blog entry, I provided a CMVP review estimate between 5 and 10 weeks)
I am raising my Unofficial CMVP Review Time Estimate to "9 to 12 weeks."
[NOTE: My definition of "CMVP Review Time" is the time between report submission to the CMVP (Review Pending block on the Modules in Process List) to the day the Laboratory first receives comments from the CMVP (Coordination block on the Module in Process List).]
My revised estimate is still significantly better than the review times from last year. Please share your experience in the comment section.
(In my May 16 blog entry, I provided a CMVP review estimate between 5 and 10 weeks)
I am raising my Unofficial CMVP Review Time Estimate to "9 to 12 weeks."
[NOTE: My definition of "CMVP Review Time" is the time between report submission to the CMVP (Review Pending block on the Modules in Process List) to the day the Laboratory first receives comments from the CMVP (Coordination block on the Module in Process List).]
My revised estimate is still significantly better than the review times from last year. Please share your experience in the comment section.
September 1, 2011
FIPS 140-2 revalidation terms to know: 1SUB, 3SUB, 5SUB
I received a question recently about maintaining a FIPS 140-2 certificate after changes are made to the module. Here is some background for those not familiar with the process.
There are 5 different scenarios when making changes to a cryptographic module. I'll cover the 3 most common. Additional details are found in the FIPS 140-2 Implementation Guidance document, G.8.
1SUB - Modifications are made to hardware, software or firmware components that do not affect any FIPS 140-1 or FIPS 140-2 security relevant items. The vendor is responsible for providing the applicable documentation to the CST laboratory, which identifies the modification(s).
[Mark Minnoch] A "1SUB" (say "one-sub") is a "maintenance" or "bug-fix" activity for the Lab. As an example let's consider the case of a vendor making source code only changes. The Lab reviews the source code changes to determine if any of the changes were security relevant. If the Lab agrees with the vendor that the changes are not security relevant, then a letter request is submitted to the CMVP to include the updated firmware (or software) version on the existing FIPS certificate.
3SUB - Modifications are made to hardware, software or firmware components that affect some of the FIPS 140-2 security relevant items. An updated cryptographic module can be considered in this scenario if it is similar to the original module with only minor changes in the security policy and FSM, and less than 30% of the modules security relevant features.
[Mark Minnoch] A "3SUB" change is commonly referred to as a "revalidation". The Laboratory updates the previous report submission to include changes and also to confirm that the required regression testing was completed. This is more involved than a 1SUB but typically less effort than a new validation. The Lab considers service changes, algorithm changes, hardware changes, etc. when determining if the 30% threshold for security relevant changes is exceeded.
5SUB - If modifications are made to hardware, software, or firmware components that do not meet the above criteria, then the cryptographic module will be considered a new module and must undergo a full validation testing by a CST laboratory.
[Mark Minnoch] A "5SUB" is commonly referred to as a "validation". The Laboratory submits a full validation test report package and the appropriate NIST fee applies.
Subscribe to:
Posts (Atom)