<a href="../../source/openssl-fips-1.2.tar.gz">source</a> at a minimum.
And did we mention the <a href="UserGuide.pdf">User Guide</a>?
<p>
-<font color="#cc3333">Inportant Note:</font> Due to upcoming changes in the FIPS 140-2 validation requirements the current v1.2 Module will
+<font color="#cc3333">Important Note:</font> Due to upcoming changes in the FIPS 140-2 validation requirements the current v1.2 Module will
no longer be a suitable model for private label validations in its current form past the year 2010. See the NIST <a href="http://csrc.nist.gov/groups/STM/cmvp/notices.html">Notices</a>,
<a href="http://csrc.nist.gov/groups/ST/key_mgmt/documents/Transitioning_CryptoAlgos_070209.pdf">discussion paper</a> and
<a href="http://csrc.nist.gov/publications/drafts/800-131/draft-800-131_transition-paper.pdf">Draft 800-131</a>.
No open source based validations are currently in progress. This situation is due not to a lack of interest on our part;
we labored for years to obtain the first ever groundbreaking open source based validation and we'd dearly love
to keep it current and available forever. The obstacle is lack of funding.
-The CMVP test lab and filing fees are more than pocket change (~USD$25,000 and up) and beyond the limited
+The CMVP test lab and filing fees are more than pocket change (~US$30,000 and up) and beyond the limited
financial resources of the OSF. Past validations have been funded by
commercial sector and government sponsors, some identified in published acknowledgments and some not (by request).
<p>
the rent and thus indirectly supports all of OpenSSL. However, unless you are one of the companies directly obtaining a custom
private label validation those improvements don't give you validated cryptography that can be sold in the markets requiring such validation.
<p>
-If and when sufficient sponsor funding materializes we will move quickly and enthusiastically to obtain a new and updated validation
-to satisfy the validation requirements then in effect. Any such plans will be posted here. If you have an interest in sponsoring
+If and when sufficient sponsor funding materializes we will move quickly and enthusiastically to
+obtain a new and updated validation to satisfy the validation requirements then in effect.
+Any such plans will be posted here.
+<p>
+More discussion of technical options for a new validation
+can be found on our separate <a href="fipsvalidation.html">FIPS 140-2 Validation</a> page.
+<p>
+<font color="#cc3333">Status Update:</font> We have several potential co-sponsors who have indicated a
+willingness to partially fund a new validation. These co-sponsorships collectively do not yet total
+enough to cover a full validation effort, but we may be only a co-sponsor or two shy of meeting that
+goal.
+<p>If you have an interest in sponsoring
that effort, in whole or in part, please contact the <a href="http://openssl.org/support/funding/support-contact.html">OSF</a>.
--- /dev/null
+
+#use wml::openssl area=documents page=FIPS140
+
+<title>OpenSSL and FIPS 140-2</title>
+
+<h1>OpenSSL and FIPS 140-2 Validation Plans</h1>
+
+The most recent open source based validation of a cryptographic module (Module) compatible with the
+OpenSSL libraries is v1.2, FIPS 140-2 certificate
+ <a href="http://csrc.nist.gov/groups/STM/cmvp/documents/140-1/140val-all.htm#1051">#1051</a>.
+This Module is documented in the <a href="UserGuide.pdf">User Guide</a>.
+<p>
+<font color="#cc3333">Important Note:</font> Due to upcoming changes in the FIPS 140-2 validation
+requirements the current v1.2 Module will no longer be a suitable model for private label validations
+in its current form past the year 2010. See the NIST
+ <a href="http://csrc.nist.gov/groups/STM/cmvp/notices.html">Notices</a>,
+<a href="http://csrc.nist.gov/groups/ST/key_mgmt/documents/Transitioning_CryptoAlgos_070209.pdf">discussion paper</a> and
+<a href="http://csrc.nist.gov/publications/drafts/800-131/draft-800-131_transition-paper.pdf">Draft 800-131</a>.
+<p>
+We hope to address these new changes in the next open source based validation once
+adequate funding is available. Depending on the level of funding we have two different
+possible technical approaches to pursue:
+<p>
+
+<ul>
+<li><h2>Expeditious Port</h2>
+The most basic approach would be to tweak the current 0.9.8 compatible Module for compatibility
+with 1.0. Such a port would be untidy due to the fact that many internal interfaces have changed
+in the transition from 0.9.8 to 1.0. The resulting validated module would need to be similarly
+updated and re-validated again for the OpenSSL 1.1 baseline.
+
+<li><h2>Rehab</h2>
+A cleaner and more robust approach is "do it right"; redesigning the
+Module API and interfaces so that the Module would no longer be version specific with respect to
+subsequent OpenSSL revisions.
+<p>
+During the long iterative process of obtaining the first OpenSSL FIPS Object Module validation
+we adapted and the design of the Module in response to evolving CMVP guidance, while constrained
+by both funding and schedule. In other words, we were forced implement a less technically elegant
+design that we would have preferred. Now that the requirements for open source based validations
+are more clearly established and understood we would like a "clean slate" building on that new
+understanding.
+</ul>
+
+These is also an additional possible but technically inelegant workaround that could avoid the
+need for a new validation entirely, at the cost of the complications that come from
+shoving a round peg into a square hole:
+
+<ul>
+<li><h2>Emulation Voo-doo</h2>
+This option is to develop an emulation layer, probably in the form of a new shared library,
+to make the existing Module API look like something the 1.0.x releases can use.
+This emulation layer could also be designed for compatibility with the "do it right" Module.
+The big (and only) advantage to this approach is that no new validation would be required in
+the short term.
+<p>
+Note however that this workaround constitutes a less permanent solution than either re-validation
+approach, as we would be unable to take advantage of the new performance optimisations now
+available for the algorithm and Power-Up Self Test (POST) implementations. Those optimisations
+can be very significant for some applications such as low power embedded devices.
+</ul>
+
+<p>If you have an interest in sponsoring any if these initiatives,
+in whole or in part, please contact the <a href="http://openssl.org/support/funding/support-contact.html">OSF</a>.
+<p>
+Some commercial software vendors ask us "what do we gain from sponsoring a validation
+that our competition can also use?". Our answer is "nothing, if you think in terms of
+obstructing your competition". If, on the other hand, you compete primarily on the
+merits of you products what others may do with the validation is less of a threat as
+they derive no more advantage from it than you do. Your advantage is that your sponsorship
+will probably cost less that the commercial software license you would otherwise have to buy,
+and you will retain backwards compatibility with the regular OpenSSL API while avoiding
+vendor lock-in.
+
+
projects / openssl-web.git / commitdiff