It goes without saying that any changes you have to make to the FIPS module would be quite welcome if you passed them along upstream, along with any information about the Priesthood of the CMVP that you're dealing with which required the change, and why.
Then again, I don't know if there's an NDA from the sponsor re the CMVP's actions, regardless of whether there's one from the CMVP to the sponsor re the sponsor's or CMVP's actions. -Kyle H On Tue, Sep 1, 2009 at 8:39 AM, Mark Phalan<mark.pha...@sun.com> wrote: > > 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 > ______________________________________________________________________ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
