<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 15:34, Steve Marquess
      wrote:<br>
    </div>
    <blockquote class=" cite" id="mid_560BE4EF_5010207_openssl_com"
      cite="mid:560BE4EF.5010207@openssl.com" type="cite">
      <pre wrap="">On 09/30/2015 09:18 AM, Jakob Bohm wrote:
</pre>
      <blockquote class=" cite" id="Cite_9986076" type="cite">
        <pre wrap="">...

Under the new "contribution agreement" scheme, publishing such items
early would also make them available to users ...
</pre>
      </blockquote>
      <pre wrap="">Publishing by someone else is fine, go for it. It would be nice to have
someone else publish FIPS module code, or validation information of any
kind for that matter. I think the validation process would be a lot less
capricious with less of the secrecy that is the current norm.
</pre>
    </blockquote>
    <p><tt>Point is that the contribution agreement contains a bug,
        whereby <br>
      </tt><tt>anything not published by the OpenSSL Foundation in the
        UK is not <br>
        licensed to anyone.</tt></p>
    <p><tt>Having a publication procedure for things marked "This does
        NOT <br>
        work in its current form, but we are giving you a license" works
        <br>
        a</tt><tt>round that bug to the benefit of anyone recovering the
        project <br>
        s</tt><tt>imilar to how the original Australian project (SSLeay)
        was </tt><br>
      <tt>recovered by Dr. Henson in the UK as OpenSSL.</tt></p>
    <br>
    <blockquote class=" cite" id="mid_560BE4EF_5010207_openssl_com"
      cite="mid:560BE4EF.5010207@openssl.com" type="cite">
      <pre wrap="">Anything we (OpenSSL) publish carries with it an implied support
obligation, and that's the key problem with FIPS specific code: it can't
be "verified" in any meaningful sense other than with an official formal
FIPS 140-2 validation. The FIPS 140-2 requirements are more metaphysical
and ideological than technical, and what's worse those requirements are
applied very subjectively. By that I mean that on multiple occasions
I've had the experience of taking very similar or even precisely
identical code through parallel validations, with different end results.

The presence of FIPS specific code in an OpenSSL repo would imply some
sort of suitability for use with FIPS validations. No matter how many
disclaimers and caveats we attached to that, there would still be
vendors trying to use it to obtain validations and encountering
problems. Guess who they're gonna call?

That problem is avoided if we obtain an open source based validation --
one where the module is distributed in source code form -- that has been
successfully validated. That validation then speaks for itself.

</pre>
      <blockquote class=" cite" id="Cite_8134933" type="cite">
        <blockquote class=" cite" id="Cite_8180736" 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>
        <pre wrap="">Interesting, I wonder if those plans include my previously
posted ideas:
...
</pre>
      </blockquote>
      <pre wrap="">There are some issues with those ideas, but now is not the time to get
into details. We'll worry about it if and when we have an opportunity to
do a new open source based validation.
</pre>
    </blockquote>
    <tt>Agreed, just making sure they were posted somewhere you <br>
      could find them when the time comes.</tt><br>
    <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>