On 07/18/2013 12:53 PM, Nou Dadoun wrote: > Just as a short comment, our fips/non-fips usage could probably > satisfy this requirement; we wrap openssl in an external api that > routes through a function pointer table. Then at run-time we can > fill in the function pointers with the fips functions or the non-fips > functions depending on which mode is desired; it wouldn't take much > modification to delay loading the fips function pointers until the > POST is complete as long as the client code doesn't choke on a "not > ready yet" return code.
Not per the understanding that we have, and the test labs we're coordinating with. The "FIPS capable" OpenSSL already does the same thing, manipulating function pointers. The essence of the new requirement is that the application developers must not *be able* to code an application that calls the crypto module prior to the POST, not that they *refrain* from doing so. As noted in the fairly detailed discussion I put online, http://opensslfoundation.com/fips/ig95.html, the OpenSSL FIPS Object Module could be recoded to satisfy this new requirement, but the result will be an ugly mess. If some sponsor(s) want to fund that effort we'll consider it, though always with the concern that we'll be hit with yet more new requirements during the protracted process of obtaining a new open source based validation. -Steve M. -- Steve Marquess OpenSSL Software Foundation, Inc. 1829 Mount Ephraim Road Adamstown, MD 21710 USA +1 877 673 6775 s/b +1 301 874 2571 direct [email protected] [email protected] ______________________________________________________________________ OpenSSL Project http://www.openssl.org User Support Mailing List [email protected] Automated List Manager [email protected]
