On 04/18/2016 08:25 PM, Jakob Bohm wrote: > On 19/04/2016 01:51, Steve Marquess wrote: >> On 04/18/2016 04:05 PM, Leaky wrote: >>>>> plus you're constrained by the >>>>> requirements of the Security Policy to build the module with precisely >>>>> the commands: >>>>> >>>>> gunzip -c openssl-fips-2.0.12.tar.gz | tar xvf - >>>>> cd openssl-fips-2.0.12 >>>>> ./config >>>>> make >>> Silly question... I know that you should only run the above commands, >>> but >>> can you deviate from the unzip tool, i.e. use 7zip? >>> >>> ... >> >> There is no point in attempting to do the usual configuration management >> and software version control on the contents of the >> openssl-fips-2.0.12.tar.gz tarball. You CANNOT change the content; there >> can be no changes to manage!!! > Almost true. If it wasn't banned by the FIPS security policy, checking in > the uncompressed tarball could be used to efficiently manage and track new > upstream releases of the tarball and to document which exact upstream FIPS > cannister source code (and hence corresponding validation date) was > incorporated into which product version (an aspect of FIPS compliance which > someone might want to audit Well, the righteous way to track the "exact upstream FIPS cannister source code" is by the SHA1 digest of the tarball that is documented in the Security Policy. > > But alas, as you clarify below, this is not permitted by the OpenSSL FIPS > security policy directly incorporated into the validation. > > The slightly less efficient idea of putting the compressed tarball into > the configuration control repository (which in this case *is* tracking the > build configuration, not the code versions) is probably (I am not sure) > againstthe policy that the tarball must be taken "securely" from the > physical CD mailed out by the OpenSSL foundation. Per the CMVP internal storage and transmission of the official tarball within the end user organization is not subject to any special requirements, once that organization has received the official snail-mailed CD disk. So for instance the east coast office of vendor XYZ could copy the openssl-fips-2.0.12.tar.gz tarball off of the official CD onto the corporate internal network, where it could be retrieved and used by the west coast office. So by that logic you could stash the complete tarball in an internal repository. That doesn't make a lot of sense, but hey it's FIPS 140-2. The CMVP was most insistent on the snail-mailed CD requirement during the #1747 validation -- resolution of that "secure distribution" issue held up the validation by a couple of months -- but I can't help but notice that several "Alternative Scenario 1A/1B" validations granted since then (which are supposedly carbon copy clones) have been allowed to omit the snail-mail CD requirement. So even the CMVP itself is confused by this requirement. > So the thing that can probably be put into a repository is the binary > FIPSCannister.o file along with copies of any documents certifying how, > where, from what and by whom said FIPS cannister was built. Exactly, and this is my recommendation (per section 5.5 of the FIPS module User Guide). -Steve M. -- Steve Marquess OpenSSL Validation Services, Inc. 1829 Mount Ephraim Road Adamstown, MD 21710 USA +1 877 673 6775 s/b +1 301 874 2571 direct marquess at openssl.com gpg/pgp key: http://openssl.com/docs/0x6D1892F5.asc
