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.
So currently, OpenSSL's realistic options are:
A. Wait for someone to convince the US Government to
drop thisretroactive requirement.
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.
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.
On 27/02/2015 03:24, Jeffrey Walton wrote:
> Hi Steve,
>
> I read the 'The FIPS 140-2 "Hostage" Issue' page. Its not clear to me
> what the problem is, or how OpenSSL is a hostage.
>
> I was looking under "The New Requirement" for a statement of the
> problem (assuming the new requirement is causing the problem), but its
> escaping me (forgive my ignorance). I think the "The New Requirement "
> section is bogged down with some background information, which is
> masking out the statement being made about the problem.
>
> If its "... the change that is being demanded is that we supply
> explicit version numbers for the hypervisor based platforms, so for
> instance an existing platform", then why is that a problem?
>
> How is virtualization a problem? (I know real problems exist in
> virtualized environments, so PRNGs can suffer. We had one appliance
> vendor tell us to do the "link /dev/random to /dev/urandom trick"
> (sigh...)).
>
> Can't that be worked around by having vendors provide real iron? (Most
> validated platforms appear to be real iron, so it seems nothing has
> changed to me).
>
> Is it a problem on mobile platforms?
>
> How is it holding OpenSSL hostage?
>
> Can you provide the executive summary here?
>
> Jeff
>
> On Wed, Feb 25, 2015 at 9:08 AM, Steve Marquess <marquess at openssl.com> wrote:
>> As always, if you don't know or care what FIPS 140-2 is count yourself
>> very, very lucky and move on.
>>
>> The open source based OpenSSL FIPS module validations now date back over
>> a decade, a period during which we've encountered many challenges.
>> We have recently hit an issue that is apparently inconsequential on its
>> face, but which threatens to bring an end to the era of the open source
>> validated module. This is a situation that reminds me of the old "for
>> want of a nail..." ditty (https://en.wikipedia.org/wiki/For_Want_of_a_Nail).
>>
>> Tedious details can be found here:
>>
>> http://openssl.com/fips/hostage.html
>>
>> The short take is that for now at least the OpenSSL FIPS Object Module
>> v2.0, certificate #1747, can no longer be updated to include new
>> platforms. This development also wrecks the already marginal economics
>> of tentative plans for a new open source based validation to succeed the
>> current #1747. So, the #1747 validation may be the last of the
>> collaborative open source FIPS modules.
>>
>> If you are a stakeholder currently using the OpenSSL FIPS module, or
>> with a desire to use it or successor modules (either directly or as the
>> basis for a "private label" validation), this is the time to speak up.
>> Feel free to contact me directly for specific suggestions or to
>> coordinate with other stakeholders.
>>
>> -Steve M.
Enjoy
Jakob
--
Jakob Bohm, CIO, Partner, WiseMo A/S. http://www.wisemo.com
Transformervej 29, 2860 S?borg, Denmark. Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20150227/aa7079ae/attachment.html>
