Joshua Hill wrote:

On Fri, Sep 05, 2003 at 04:05:07PM -0400, Rich Salz wrote:

It is the first *source code* certification.

The ability to do this runs counter to my understanding of FIPS 140-2.

. 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).

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).

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.
I realize this is stretching too thin. and can think of lots of reasons why it can't be. But...

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".

I have seen evidences that this restriction has become exceptionally loose, and that the "family" can be as broad as "UNIX-like" systems...

- Tolga

The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]

Reply via email to