Ideally (in my view anyway), we'd have some sort of announcement as to where the FIPS code is being evaluated, then have a couple of weeks to a month to hammer at it before it's sent off to the (much more costly, and much more involved) CMVP validation.
We've seen through 2 iterations of the validation thus far that even the labs make mistakes. Since my primary interest in this is "making sure things that are supposed to be 'secure' are 'secure'" (to tolerances specified by the NIST and theoretically enforced by rigorous validation), my feeling is that it's most important to open up the process, to open up the eyes for white-box testing to increase the chances that it will pass stringent black-box testing. Thank you, very much, for the reference to the branch tag -- it's more than we've gotten from the OpenSSL developers themselves, and even if our input can't go into the current validation cycle it'll still be a lot easier to see what's going on. -Kyle H On Nov 29, 2007 5:59 PM, Steve Marquess <[EMAIL PROTECTED]> wrote: > > Kyle Hamilton wrote: > > > There is no available OpenSSL FIPS Object Module v1.2. > Well, yes and no. Check out the OpenSSL-fips-0_9_8-stable branch. The > code we're trying to validate now is from that branch. Currently we're > at tag FIPS_098_TEST_8. > > > > Until it passes > > validation, anyway, at which point the openssl-fips-1.2.0.tar.gz file will > > be made available. I don't think the source is actually even in the public > > CVS. (I would like to see a preview version that I can at least link things > > that use the API against, even if everything's stubbed out. :P) > > > The fact that the code is publicly available doesn't help anyone who > wants a validated module now. We also can't know until the very end if > the code will change -- the considerations behind some of the FIPS 140-2 > requirements are not aways obvious, even in hindsight. The requirements > and interpretations thereof evolve over time as well, even during the > course of a single validation. Even having something is better than nothing. I understand that you can't make any statements about ongoing validation status (for the reasons that you state). > > I do have to ask, though: is this one going to compile properly on > > Intel-based Macs? 1.1 and 1.1.1 didn't. > > > Try it and see. If you find problems it will probably be too late to do > anything for the current v1.2 validation, but we can address it for the > next. It was caught after the v1.1.1 validation submission. I haven't checked out that tag yet, but I'm hoping they did figure it out and put it in the 1.2 submission. (As an aside, Apple doesn't even have a FIPS-validated module for OSX yet, which is both disturbing and annoying.) > Note that we haven't attempted to solicit widespread testing because of > the peculiar timing of the FIPS validation process -- you have to > effectively freeze the code baseline *before* starting testing. The > ideal way to deal with that would be to have a continuing stream of > validations in process, spaced a few months apart -- then problems found > in validation N could be addressed in validation N+1. But validations > are very expensive and our financial sponsorship is erratic so we > proceed as resources allow. Even some widespread testing/examination has to be better than none, which how the situation has stood up to now. Can we ask for some notification as to when new "validation candidates" are tagged? And notification as to when those "validation candidates" are actually submitted? (It'd also be nice to know when the validation candidates are scrapped due to issues caught before the submission.) > -Steve M. Again, thank you very much for your time, and the information. -Kyle H ______________________________________________________________________ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
