[openssl-users] FIPS compile issue with Perl on Windows

[Steve Marquess]

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