On 30/09/2015 14:28, Steve Marquess wrote: > On 09/30/2015 03:50 AM, Jakob Bohm wrote: >> 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. > 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. For branches expected to be promoted to release "eventually" (like the non-fips master branch) this is good policy. However it is also good policy to have, outside such branches, a place to gather up snippets (own or contributed) that might come handy some day, such as a constant time memcmp (before it became needed in a recent security patch) or an implementation of an SHA-3 candidate (before NIST selected the final SHA-3) etc. For an open source project, such unpolished unintegrated code could live in the bugtracker or in a special "experiments" git branch. The code in such a place would have the common characteristic of fully clarified licensing (PD, BSD, classic OpenSSL/SSLeay, foundation contributed, etc.), such that if/when the need arises, there is no need to track down and negotiate with the original contributor (think of pre-Oracle Sun contributions or pre-RSA EAY contributions). Under the new "contribution agreement" scheme, publishing such items early would also make them available to users even if the UK's GCHQ suddenly imposes draconian restrictions on the UK-based foundation, as it would make them legally available to continuation projects based in different jurisdictions, just as the original EAY-style licenses made the code available for continuation projects outside Australia. > > 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. Interesting, I wonder if those plans include my previously posted ideas: - Having the FIPS module contain no direct system calls, only callbacks to its client. This would mean one FIPS blob per instruction set, not one per target platform. (Bureaucracy would still require enumeration of platform environments, but the change to add a new environment for the same instruction set would consist only of adding it to the list, no changes to policy or code). - Having the FIPS module be position independent, such that the integrity hash becomes immune to ASLR. - Having the FIPS blob be application independent, such that the correct integrity hash can be determined at FIPS module build time without using special application link steps. - Including the FIPS blob hash for known good compilers in the policy document, while still having the compilation-proven correspondence to source. > 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. > 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/20150930/4cadb4ea/attachment.html>
