Geoff Thorpe wrote:
...
Caveat: I haven't been involved in FIPS at all BTW, so I find myself
in the "couldn't care less" category regarding the details. But if
there's something that needs to be locked down (ie. fixed in the C
code), we can surely lock it down as a part *of* the engine code
rather than locking out engine code altogether. If this isn't the
case then long-term, FIPS work will diverge significantly from (a)
ongoing development, and (b) common sense.
FIPS 140-2 level 1 does NOT require that all possible invalid modes of
operation of the validated module be absolutely "locked down". Many
validated modules contain within the module boundary implementations of
disallowed algorithms. However FIPS 140-2 does require through the
Security Policy that the end user not utilize any such disallowed
functionality while in the validated mode of operation. In other words,
the fact that the module *could* be misused is OK as long as it *isn't*
misused.
That said, in the OpenSSL FIPS Object Modules we've taken care to
automatically disable disallowed functionality wherever feasible, to aid
the end user with the responsibility of not using such functionality.
Side-note: I've heard people who *are* involved in the FIPS work
speak of it in fairly colourful ways - I suspect they'd agree that
the "standard" (and its process) is little more than bureaucratic,
superstitious B-S. IANAL, FWIW, etc. :-)
Well, as with most such initiatives the FIPS validation program was
initiated with the best of intentions and IMHO in the beginning served a
useful purpose. Other that that, no comment :-)
-Steve M.
--
Steve Marquess
Open Source Software Institute
[EMAIL PROTECTED]
______________________________________________________________________
OpenSSL Project http://www.openssl.org
Development Mailing List openssl-dev@openssl.org
Automated List Manager [EMAIL PROTECTED]
