On Fri, Sep 05, 2003 at 04:05:07PM -0400, Rich Salz wrote:. and to experiences with the previous FIPS 140-1 certifications I was involved in, including a fairly recent communication from NIST that defines a "crypto module": it is not a statically linked library, and that it ought to be an executable or a shared library (so,dll).
It is the first *source code* certification.
The ability to do this runs counter to my understanding of FIPS 140-2.
Can you say that the C/asm source code is the "code" that constitutes a "module", and define compiler/linker/OS/CPU as your execution environment for FIPS 140 purposes? Think Java, for instance.Second, it is unclear to me what would be tested during operational testing. The source code can't itself be a module, because the source code doesn't do anything until it is compiled and run. FIPS 140-2 currently only allows for fully functional units to be modules; you'll note, for instance, that FIPS certs for "software" modules are listed as a "multi-chip standalone" embodiment, for instance. NIST was talking about producing documents that would support a true "software only" embodiment, but that initiative seems to have stalled with the change of directors of the CMVP (the NIST group that issues FIPS 140-2 certs).
I realize this is stretching too thin. and can think of lots of reasons why it can't be. But...
I have seen evidences that this restriction has become exceptionally loose, and that the "family" can be as broad as "UNIX-like" systems...Third, nominally, the FIPS certificate only applies to the particular operating system (and OS version) that the operational testing was done on. For level 1 modules, NIST has historically allowed OSes in the same "family" to also be covered, and they have been very liberal in their definition of "family".
- Tolga
--------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
