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 <marqu...@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
_______________________________________________
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
