Hi Steve, I read the 'The FIPS 140-2 "Hostage" Issue' page. Its not clear to me what the problem is, or how OpenSSL is a hostage. I was looking under "The New Requirement" for a statement of the problem (assuming the new requirement is causing the problem), but its escaping me (forgive my ignorance). I think the "The New Requirement " section is bogged down with some background information, which is masking out the statement being made about the problem. If its "... the change that is being demanded is that we supply explicit version numbers for the hypervisor based platforms, so for instance an existing platform", then why is that a problem? How is virtualization a problem? (I know real problems exist in virtualized environments, so PRNGs can suffer. We had one appliance vendor tell us to do the "link /dev/random to /dev/urandom trick" (sigh...)). Can't that be worked around by having vendors provide real iron? (Most validated platforms appear to be real iron, so it seems nothing has changed to me). Is it a problem on mobile platforms? How is it holding OpenSSL hostage? Can you provide the executive summary here? Jeff On Wed, Feb 25, 2015 at 9:08 AM, Steve Marquess <marquess at openssl.com> wrote: > As always, if you don't know or care what FIPS 140-2 is count yourself > very, very lucky and move on. > > The open source based OpenSSL FIPS module validations now date back over > a decade, a period during which we've encountered many challenges. > We have recently hit an issue that is apparently inconsequential on its > face, but which threatens to bring an end to the era of the open source > validated module. This is a situation that reminds me of the old "for > want of a nail..." ditty (https://en.wikipedia.org/wiki/For_Want_of_a_Nail). > > Tedious details can be found here: > > http://openssl.com/fips/hostage.html > > The short take is that for now at least the OpenSSL FIPS Object Module > v2.0, certificate #1747, can no longer be updated to include new > platforms. This development also wrecks the already marginal economics > of tentative plans for a new open source based validation to succeed the > current #1747. So, the #1747 validation may be the last of the > collaborative open source FIPS modules. > > If you are a stakeholder currently using the OpenSSL FIPS module, or > with a desire to use it or successor modules (either directly or as the > basis for a "private label" validation), this is the time to speak up. > Feel free to contact me directly for specific suggestions or to > coordinate with other stakeholders. > > -Steve M.
