We are very close (a few days at most) from the point where the 26 special source files in the ./fips/ tree can no longer be modified (or else the FIPS validation won't apply). These files are identified by the SHA-1 HMAC signatures in the fingerprint.sha1 files; these signatures will be immortalized in the validation from NIST.
So if there are any last minutes fixes needed please do them now!
Steve Marquess DMLSS Technical Manager JMLFDC, 623 Porter Street, Ft. Detrick, MD 21702 DSN 343-3933, COM 301-619-3933, FAX 301-619-7831 [EMAIL PROTECTED]
Steve:
I asked the following of Ben but never received an answer regarding how library and application verification can be ensured on Windows (and perhaps other platforms):
"There are a couple of things that have been bothering me. (1) I'm not sure the use of .SHA1 files is going to work long term on Windows. First, they are unmanageable when it comes to patches. Second, Windows itself modifies the .EXE/.DLL files to include updating binding information. It seems to me that we need to compute the hash not on the entire .EXE/.DLL file but instead exclude the Run Time Binding data and the Resource data. Then we can store the hash as a resource string bound to the file.
(2) Why is it that the SHA1 hash of the executable linked to LIBEAY32.DLL is being checked and not the hash of LIBEAY32.DLL itself? Are we truly worried about the application being altered and not the crypto library?"
Can you provide some insight?
Thanks.
Jeffrey Altman
smime.p7s
Description: S/MIME Cryptographic Signature
