[openssl-users] End of the line for the OpenSSL FIPS Object Module?

[Steve Marquess]

On 02/27/2015 01:56 AM, Jakob Bohm wrote:
> I think it was clear enough:
> 
> NIST/NSA/CMVP is demanding that OpenSSL change the
> definition of*already* "validated" platforms before they
> will allow OpenSSL to addnew platforms.
> 
> But changing those definitions would invalidate existing
> governmentcontracts for delivery of products that used
> the OpenSSL FIPS moduleon those platforms, so the users
> that actually need the FIPS validationwill be hurt
> either way.
> 
> For example, if company X has an existing contract where
> they promisethat the foo system they delivered to some
> US Government agencyuses only crypto code which was
> validated for "Red Hat EnterpriseLinux 7.0 (x86_64)
> running on VmWare ESX", then if OpenSSL obeysthe
> demand to change the definition to read "Red Hat
> EnterpriseLinux 7.0 (x86_64) running on VmWare ESX
> 5.1", then company Xwould suddenly be unable to
> fulfill their contract, which may evenbe a criminal
> offense.  But if OpenSSL refuses to change the
> definition, OpenSSL cannot deliver to company X a
> new validationfor "Apple OS/X 10.8 (x86_64) running
> on raw Apple hardware",so company X cannot get a new
> government contract to deliver forthat platform, and
> neither can anybody else.

Jakob, you nailed it. Do you mind if I add that explanation as a
footnote (with attribution)?

I've spent so long in the government arena I forget that not everyone
realizes how arduous the procurement process can be, or how rigid and
inflexible.

> 
> So currently, OpenSSL's realistic options are:
> 
> A. Wait for someone to convince the US Government to
>   drop thisretroactive requirement.

Which we are doing, and I do expect this latest retroactive requirement
to be rescinded eventually (as happened before in early 2014). However,
once again the delay has a severe short term cost for the sponsors of
pending new platforms.

> B. Start over with a new validation for a new FIPS
>   module version 3, whichwould have to be modified
>   to meet other new demands, whichdidn't exist when
>   FIPS module version 2 was originally submitted.

We do want to begin a new validation to address all the new requirements
that have accumulated since the #1747 validation was awarded in 2012.
But, while platform sponsors are easy to find, sponsors for the big pain
and big bucks of new validations are not.

We *may* have such sponsorship, at long last, but both we and those
sponsor(s) realize that our plans for that new validation have assumed
that we would be able to extend it indefinitely with change letter
updates (as has traditionally been the case). With that assumption now
in doubt the validation effort becomes economically infeasible for OSF,
as we'll take a loss on the validation itself that could only be
recouped via subsequent change letters. Likewise, the sponsor(s) had
planned on leveraging their substantial investment over time by adding
new platforms as needed.

>    This would involve 2 variants of the FIPS interface
>   code in OpenSSL1.0.3, lots of new code and a very
>   very expensive bill to get thecode validated all
>   over again.

Very expensive indeed -- well into six figures -- but the platform
validation costs are typically spread over a large number of platform
sponsors. Each prospective platform sponsor is reminded that if they are
willing to wait long enough some other sponsor may do that platform for
them; but I've found that the platform sponsors are usually delighted to
have the option of paying themselves for a platform validation now
rather than waiting indefinitely. Those sponsors usually have pending
sales that easily justify the platform validation costs.

The hard part has always been funding the initial new validation.

-Steve M.

-- 
Steve Marquess
OpenSSL Software Foundation, Inc.
1829 Mount Ephraim Road
Adamstown, MD  21710
USA
+1 877 673 6775 s/b
+1 301 874 2571 direct
marquess at opensslfoundation.com
marquess at openssl.com
gpg/pgp key: http://openssl.com/docs/0x6D1892F5.asc