On 7/9/2010 9:05 AM, Steve Marquess wrote: > Mark Parr wrote: >> Use of the FIPS OpenSSL is a mandated thing and not just something that we >> are looking to do for the fun of it. In fact, the base OpenSSL was working >> fine using the "FIPS AES 256 encryption" in a non "FIPS Certified" mode. >> >> ... > > Yes, that was my assumption and the point I was trying to make: if you > want to build your product from source in a clean and logical way then > just leave the FIPS module creation out of it. You will suffer less > hair-pulling and tooth gnashing. If you must use the FIPS validated > module then IMHO your best approach is to build the validated module > *once*, by hand with careful documentation, and henceforth just use that > resulting validated binary. > > Otherwise you're trying to perform what is effectively a ritual ceremony > in an inappropriate secular context: from the CMVP perspective the > source code itself isn't validated, only the resulting binary when the > specific peculiar build process has been followed, i.e. the "ritual". > Perform that ritual once and you have one validated module that you can > use many times -- perform it multiple times and you have multiple > different validated modules. > > Or, here's another way to look at it. I can take the same source code > and generate binaries two different ways, one by following the ritual > and one by deviating from the ritual in some technically trivial way > (by, say, adding a superfluous "--prefix" config option). The resulting > binaries are functionally identical by any technical test that could be > devised, yet one module is FIPS 140-2 validated and one isn't.
That isn't to say that it can't be rpm'ed, and the infrequently updated fips canister (currently v1.2) can't be 'the dependency' for building openssl-fips. ______________________________________________________________________ OpenSSL Project http://www.openssl.org User Support Mailing List openssl-users@openssl.org Automated List Manager majord...@openssl.org
