<html>
<head>
<meta http-equiv="content-type" content="text/html; charset=windows-1252">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<div class="moz-cite-prefix">On 30/09/2015 14:28, Steve Marquess
wrote:<br>
</div>
<blockquote class=" cite" id="mid_560BD571_40701_openssl_com"
cite="mid:560BD571.40701@openssl.com" type="cite">
<pre wrap="">On 09/30/2015 03:50 AM, Jakob Bohm wrote:
</pre>
<blockquote class=" cite" id="Cite_150573" type="cite">
<pre wrap="">Dear Steve,
Have you considered that their contribution may be of value
to the next/future major version of the open source FIPS
module (which would presumably involve a fresh submission
under updated FIPS validation rules).
This would obviously be a different code branch from
maintenance/change letter updates to the current module.
</pre>
</blockquote>
<pre wrap="">We have indeed. As noted already that code will be of no value until we
can actually run it through a validation ourselves. Our days of
committing speculative code that "might come in handy someday" are
behind us.</pre>
</blockquote>
<tt>For branches expected to be promoted to release "eventually" <br>
(like the non-fips master branch) this is good policy. However <br>
it is also good policy to have, outside such branches, a place <br>
to gather up snippets (own or contributed) that might come <br>
handy some day, such as a constant time memcmp (before it <br>
became needed in a recent security patch) or an implementation <br>
of an SHA-3 candidate (before NIST selected the final SHA-3) etc.</tt><tt><br>
<br>
For an open source project, such unpolished unintegrated code
could <br>
live in the bugtracker or in a special "experiments" git branch. <br>
The code in such a place would have the common characteristic of <br>
fully clarified licensing (PD, BSD, classic OpenSSL/SSLeay,
foundation <br>
contributed, etc.), such that if/when the need arises, there is no
<br>
need to track down and negotiate with the original contributor
(think <br>
of pre-Oracle Sun contributions or pre-RSA EAY contributions).<br>
<br>
Under the new "contribution agreement" scheme, publishing such
items <br>
early would also make them available to users even if the UK's
GCHQ <br>
suddenly imposes draconian restrictions on the UK-based
foundation, <br>
as it would make them legally available to continuation projects
based <br>
in different jurisdictions, just as the original EAY-style
licenses <br>
made the code available for continuation projects outside
Australia.<br>
</tt>
<blockquote class=" cite" id="mid_560BD571_40701_openssl_com"
cite="mid:560BD571.40701@openssl.com" type="cite">
<pre wrap="">
We also have plans for a significant rewrite of the FIPS module from its
current form, and it's unlikely any third party submissions would fit
that vision.
</pre>
</blockquote>
<tt>Interesting, I wonder if those plans include my previously <br>
posted ideas:</tt><tt><br>
</tt><tt><br>
</tt><tt> - Having the FIPS module contain no direct system calls, <br>
only callbacks to its client.</tt><tt> This would mean one FIPS<br>
blob per instruction set, not one per target platform.<br>
(Bureaucracy would still require enumeration of platform <br>
environments, but the change to add a new environment for <br>
the same instruction set would consist only of adding it <br>
to the list, no changes to policy or code).<br>
</tt><tt> - Having the FIPS module be position independent, such <br>
that the integrity hash becomes immune to ASLR.</tt><tt><br>
</tt><tt> - Having the FIPS blob be application independent, such <br>
that the correct integrity hash can be determined at <br>
FIPS module build time without using special application <br>
link steps.</tt><tt><br>
</tt><tt> - Including the FIPS blob hash for known good compilers <br>
in the policy document, while still having the <br>
compilation-proven correspondence to source.</tt><tt><br>
</tt><br>
<blockquote class=" cite" id="mid_560BD571_40701_openssl_com"
cite="mid:560BD571.40701@openssl.com" type="cite">
<pre wrap="">
Of course any third party (Cisco for instance) is free to publish
patches or even a compete open source FIPS module themselves, and deal
with the inevitable onslaught of requests for support. I get those
almost daily, usually in the form of "we're trying to do our own
validation and need a little help...".
-Steve M.
</pre>
</blockquote>
<br>
<br>
<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>