On Tue, 2009-09-01 at 11:20 -0400, Steve Marquess wrote: > Mark Phalan wrote: > > ... > > > > > As you noted the incorporation of fipscanister.o in a FIPS capable > > > OpenSSL displaces the corresponding FIPS allowed algorithms of the > > > latter. While we retain functional equivalence (goal 1 above) any > > > platform optimizations or other improvements of the newer > > > implementations are lost. The nature of this interface is such > > > that we can't easily avoid this displacement within the constraints > > > of the existing fipscanister.o interface and 0.9.8 versioning > > > rules. > > > > Do you think delivering two versions of libcrypto in this case is a > > reasonable workaround? > > It's the simplest solution in your case, even though it's the outcome > our design hoped to avoid.
Ok. > > > > I should also note that developments in FIPS 140-2 testing > > > requirements for 2010 mean that even the existing v1.2 module will > > > no longer be compliant. The commercial vendors who have been > > > obtaining "private label" validations based on v1.2 will find that > > > those validations will no longer be rubber stamp formalities as is > > > the case today. > > > > Can you point me to more information about this? Does this mean that > > delivering a FIPS Capable OpenSSL (v1.2) as part of an OS will be > > essentially worthless to users of that OS in 2010? > > Well, I have a mixed track record in forecasting future CMVP actions so > take my speculations accordingly. > > The CMVP typically does not revoke or invalidate extant validations > simply because the criteria for new validations have changed (though I > should note past OpenSSL FIPS Object Module validations have been > effectively revoked). So presumably the current #1051 validation will > remain in effect through 2010 for those electing to use it directly. > Emphasis on presumably, as the OpenSSL open source based validations are > *not* typical. So assuming you base your deliverables on already > awarded validated products you *should* be OK. > > However, it has been common practice for vendors to take the same v1.2 > source code and documentation and obtain their own copy-cat or "private > label" validation. There are a number of practical and marketing > reasons why such duplicate validations are desirable (minimizing the > risk of exposure to the fate of validations #642 and #733 being first > and foremost). Those copy-cat validations will no longer be possible > with the as-is v1.2 source. > > At one point in time we thought that we would have, though sponsorships > brokered by the Open Source Software Institute, long term funding for an > ongoing series of periodic (annual or semi-annual) "rolling" > validations. That would have maintained availability of a reasonably > current product for direct use or as a model for private label use, and > would also have allowed us to work in the desired architectural changes > over several validations. Unfortunately that prospect fell through and > at this point we have no plans for any future validations. > > Private label validations will continue but will require increasing > amounts of modification to the v1.2 source code and documentation as the > validation requirements are extended. We could merge those changes back > into the shared baseline code and docs, but to date we have received > very few contributions of that sort. So what is currently a community > resource will gradually revert back to a roll-your-own situation, same > as it was before the first open source based validation. Ok. Thanks for all the information. -M ______________________________________________________________________ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
