<html>
<head>
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<div class="moz-cite-prefix"><tt>I think it was clear enough:</tt><tt><br>
</tt><tt><br>
</tt><tt>NIST/NSA/CMVP is demanding that OpenSSL change the<br>
definition of</tt><tt> </tt><tt>*already* "validated" platforms
before they<br>
will allow OpenSSL to add</tt><tt> </tt><tt>new platforms.</tt><tt><br>
</tt><tt><br>
</tt><tt>But changing those definitions would invalidate existing<br>
government</tt><tt> </tt><tt>contracts for delivery of products
that used<br>
the OpenSSL FIPS module</tt><tt> </tt><tt>on those platforms,
so the users<br>
that actually need the FIPS validation</tt><tt> </tt><tt>will
be hurt<br>
either way.</tt><tt><br>
</tt><tt><br>
</tt><tt>For example, if company X has an existing contract where<br>
they promise</tt><tt> </tt><tt>that the foo system they
delivered to some<br>
US Government agency</tt><tt> </tt><tt>uses only crypto code
which was<br>
validated for "Red Hat Enterprise</tt><tt> </tt><tt>Linux 7.0
(x86_64)<br>
running on VmWare ESX", then if OpenSSL obeys</tt><tt> </tt><tt>the<br>
demand to change the definition to read "Red Hat<br>
Enterprise</tt><tt> </tt><tt>Linux 7.0 (x86_64) running on
VmWare ESX<br>
5.1", then company X</tt><tt> </tt><tt>would suddenly be unable
to<br>
fulfill their contract, which may even</tt><tt> </tt><tt>be a
criminal<br>
offense. But if OpenSSL refuses to change the</tt><tt><br>
defini</tt><tt>tion, OpenSSL cannot deliver to company X a<br>
new validation</tt><tt> </tt><tt>for "Apple OS/X 10.8 (x86_64)
running<br>
on raw Apple hardware",</tt><tt> </tt><tt>so company X cannot
get a new<br>
government contract to deliver for</tt><tt> </tt><tt>that
platform, and<br>
neither can anybody else.</tt><tt><br>
</tt><tt><br>
</tt><tt>So currently, OpenSSL's realistic options </tt><tt>are:</tt><tt><br>
</tt><tt><br>
</tt><tt>A. Wait for someone to convince the US Government to<br>
drop this</tt><tt> </tt><tt>retroactive requirement.</tt><tt><br>
</tt><tt>B. Start over with a new validation for a new FIPS<br>
module version 3, which</tt><tt> </tt><tt>would have to be
modified<br>
to meet other new demands, which</tt><tt> didn't exist when<br>
FIPS module version 2 was originally submitted.</tt><tt><br>
</tt><tt> This would involve 2 variants of the FIPS interface<br>
code in OpenSSL</tt><tt> 1.0.3, lots of new code and a very<br>
very expensive bill to get the</tt><tt> </tt><tt>code
validated all<br>
over again.</tt><tt><br>
<br>
</tt>On 27/02/2015 03:24, Jeffrey Walton wrote:<br>
</div>
<blockquote
cite="mid:CAH8yC8=VpYFk-oy0m7Xt+5jRUqxLJeAd6AK3+6u07ZUa6Ugi-Q@mail.gmail.com"
type="cite">
<pre wrap="">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 <a class="moz-txt-link-rfc2396E" href="mailto:marquess@openssl.com"><marquess@openssl.com></a> wrote:
</pre>
<blockquote type="cite">
<pre wrap="">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 (<a class="moz-txt-link-freetext" href="https://en.wikipedia.org/wiki/For_Want_of_a_Nail">https://en.wikipedia.org/wiki/For_Want_of_a_Nail</a>).
Tedious details can be found here:
<a class="moz-txt-link-freetext" href="http://openssl.com/fips/hostage.html">http://openssl.com/fips/hostage.html</a>
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.
</pre>
</blockquote>
</blockquote>
<pre class="moz-signature" cols="72">Enjoy
Jakob
--
Jakob Bohm, CIO, Partner, WiseMo A/S. <a class="moz-txt-link-freetext" href="http://www.wisemo.com">http://www.wisemo.com</a>
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 </pre>
</body>
</html>