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
