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