On Wed, 10 Jun 2009, Garrett D'Amore wrote: > Mehdi Bonyadi wrote: >> FIPS 140-3 is still in draft and under review, but since certifications can >> take many months it is a good idea to monitor the situation and be >> prepared. Has anyone heard of any target dates for 14-3 release or do they >> know how it would impact our case? > > If the precedent set by 140-2 holds, then certifications of 140-2 will still > be valid after 140-3 is approved. And IIRC, there will probably be a > transition period where products can still be evaluated as 140-2.
That is correct, that is what 140-3 stipulates (I think the timer is set by when you officially enter evaluation). To answer your question, though, Mehdi. We have been following 140-3, and the lab we've engaged is watching that very closely. Valerie > > - Garrett >> >> Mehdi >> >> >> On 06/09/09 22:53, Anthony Scarpino wrote: >>> Hi, >>> >>> The team is enhancing the Cryptographic Framework to support a Security >>> Level 2. That level requires a Common Criteria certified OS. Having it >>> on by default would have to be a special case for that particular >>> release.. >>> >>> Now taking off the project team hat... >>> >>> In a world with an appetite for performance. FIPS (regardless of Security >>> Level) requires Power-On Self Tests and other tests that will degrade >>> performance. There are also boundaries which have to the verified before >>> crypto operations can be performed. I feel that you would see many more >>> unhappy users than happy.. >>> >>> Also a FIPS validation requires a Security Policy that is a configuration >>> the user must keep the system in, so no addition crypto cards or >>> providers. And for Level 1 and 2, it's not that the whole system is >>> FIPS'ed, but just a set of supported APIs. >>> >>> In general as FIPS 140-2 is, I don't believe it's practical by default.. >>> >>> Tony >>> >>> >>> Glenn Brunette wrote: >>>> >>>> Given the strong push by U.S. and other governments, financial >>>> services organizations, etc. (inside and outside of the U.S.) to >>>> use FIPS approved algorithms, has there been any consideration >>>> to make FIPS-140 mode enabled by default? I realize that in a >>>> global marketplace, this is likely a touchy issue, but I at least >>>> wanted to put the question on the table and hear from the project >>>> team and the community. >>>> >>>> g >>>> >>>> On 6/9/09 6:17 PM, Krishna Yenduri wrote: >>>>> I am sponsoring this fast track for Hai-May Chao. The timer >>>>> is set for 06/17/2009. Micro/patch binding is requested. >>>>> >>>>> >>>>> Template Version: @(#)sac_nextcase 1.68 02/23/09 SMI >>>>> This information is Copyright 2009 Sun Microsystems >>>>> 1. Introduction >>>>> 1.1. Project/Component Working Name: >>>>> cryptoadm(1M) enhancement for FIPS-140 mode >>>>> 1.2. Name of Document Author/Supplier: >>>>> Author: Hai-May Chao >>>>> Valerie Fenwick >>>>> Tony Scarpino >>>>> 1.3 Date of This Document: >>>>> 09 June, 2009 >>>>> >>>>> 4. Technical Description >>>>> >>>>> 4.1 Proposal: >>>>> >>>>> Enhance cryptoadm interface to provide for enabling and disabling >>>>> of the FIPS-140 mode of operations in the Cryptographic Framework. >>>>> >>>>> 4.2 Description: >>>>> >>>>> The Cryptographic Framework team is planning on obtaining FIPS 140-2 >>>>> certification. The cryptoadm command is the administrative front-end >>>>> interface to the framework. This case is intended to add new features >>>>> to cryptoadm(1M) that allow administrators to enable and disable the >>>>> FIPS-140 mode in the Cryptographic Framework. Hence, this case >>>>> represents the first set of changes to get prepared toward the FIPS >>>>> 140-2 evaluation process. >>>>> >>>>> There will be two FIPS-140 modes of operations in the framework: enabled >>>>> and disabled. The default FIPS-140 mode is disabled. >>>>> >>>>> When FIPS-140 mode is enabled, the Cryptographic Framework is put into >>>>> FIPS-140 mode of operations. The non-approved FIPS algorithms provided >>>>> by >>>>> the user-level pkcs11_softtoken provider and the kernel software >>>>> providers >>>>> will not be disabled. It is up to the consumers of the framework to be >>>>> responsible for using only FIPS approved algorithms and that will be >>>>> documented in the Security Policy. This meets FIPS 140 level 2 >>>>> requirements. >>>>> >>>>> As we start working with the certification lab, we anticipate there may >>>>> be additional changes needed and those changes should be internal to the >>>>> framework. The cryptoadm interface changes should stand by itself. >>>>> >>>>> The cryptoadm command will also be modified to display the active >>>>> FIPS-140 mode setting. >>>>> >>>>> 4.3 Interfaces: >>>>> >>>>> The following new options are added to cryptoadm(1M) sub-commands >>>>> cryptoadm list fips-140 >>>>> cryptoadm enable fips-140 >>>>> cryptoadm disable fips-140 >>>>> >>>>> Stability level is "committed". >>>>> Release binding is Micro/Patch. >>>>> >>>>> >>>>> 4.4 Doc Impact: >>>>> >>>>> The diff-marked cryptoadm(1M) man page is in the case directory. >>>>> >>>>> 5. Reference >>>>> >>>>> FIPS 140-2 Spec can be located at: >>>>> http://csrc.nist.gov/publications/PubsFIPS.html >>>>> >>>>> 6. Resources and Schedule >>>>> 6.4. Steering Committee requested information >>>>> 6.4.1. Consolidation C-team Name: >>>>> ON >>>>> 6.5. ARC review type: FastTrack >>>>> 6.6. ARC Exposure: open >>>>> >>> >>> _______________________________________________ >>> crypto-discuss mailing list >>> crypto-discuss at opensolaris.org >>> http://mail.opensolaris.org/mailman/listinfo/crypto-discuss > >
