Kyle Hamilton wrote: > ... >>> Yes, that is understandable. Any code going through validation at that >>> time cannot be touched. I think what Kyle asked for was prior to the >>> next validation starting, a 2-week window where people could provide >>> patches. Basically a 'last-call', or at least some projected timelines >>> for when it would be submitted so we know if the code is 'close-to-final' >>> before we try to provide patches (at least portability patches as is >>> my selfish concern). >>> > > ...basically, yes. I don't particularly want in-validation input > capability, since (as Steve M points out) it's pointless. However, I > am honestly annoyed that there have been two validation cycles past > without (still!) a working FIPS-validated module for the Intel Mac. I > know that at least HPUX64 had the same issue (I know I've got the tag > wrong, but you know to which I refer). This... well, honestly > violates my sensibilities. > I know that feeling well. My sensibilities are regularly violated when working FIPS 140 issues :-) > I just want to have the opportunity to know that what is submitted > will actually run on the platform I must use. > You best approach is to report problems (or provide patches) for the head of OpenSSL-fips-0_9_8-stable. That's where we'll start from when and it there's another validation. > ... > > Huh. You've just basically admitted that you have given up having any > kind of hope of having any kind of input into the process. I should > point out that you do have a fairly important role: you are the only > gateway through which users have any input at all. At what point does > the submission become 'fixed'? Is it 'at the moment you submit it'? > I don't really know for sure what the final distribution is until after the validation certificate is awarded, some 6-9 months after the first tarball is sent to the test lab. Even then I can't be entirely sure, as we may even be required to change it retroactively, as has actually happened. > ... > Quite honestly, if the CMVP needs to adapt to open-source methods, > open-source also needs to adapt to CMVP methods. Yes indeed, and adapt I did and a most difficult and awkward adaptation that was and is. FIPS 140 validation is an inherently closed process. All activity takes place under strict non-disclosure by default. Many of the insights and inputs I've received about this process were given to me on a not-for-attribution, close-hold, or non-disclosure basis. The ultimate authorities, the roughly six government bureaucrats who administer the CMVP, rarely communicate directly with vendors like OSSI. They have a specialized vocabulary, "FIPS-speak", where some terms have a very different meaning than in a typical software engineering context (that I still struggle with). There are both elaborate written policies using this vocabulary and a significant body of unwritten interpretations and understandings; a unique institutional culture if you will. In short, there is a substantial subjective element; the challenges from my perspective are thus primarily political and not technical. As such there are some things that it just isn't prudent for me to talk about in public. We spent five years tip-toeing through a minefield to obtain the first ever source code based validation, the first validation allowing static linking, the first validation to publish a full set of algorithm test drivers *and* the request and response test data and a test utility for the non-algorithm testing, the first to provide enough information to support "cookie cutter" validations. If you want to work a FIPS 140-2 validation and tell the world all about it then be my guest. I've chosen to work within the system as much as possible, to adapt to the way things are done there to achieve concrete results instead of trying to tear the cathedral down and turn it into a bazaar.
> ... So, if anyone else wants to > take any open-source cryptographic code through the validation process > they still have to go all the way from square 1. > Umm, actually you can do what many others (several dozen we think) have done and do a "private label" clone validation -- take the validated source distro, tweak as desired, change the names and dates in the Security Policy, write a check to the test lab, and you're all done except for the waiting. You don't have to write any code or documentation for the validation, other than for your customizations if any, because we've supplied a complete working model. Granted the rules are continually evolving and you may have to deal with requirements introduced since the reference validation, all validations do but there's not much we can do about that. > ... > > So HEAD is where the active development happens, and tags (not > branches) are created to mark the milestones? Alright. (It's good to > know how the development process works, so that we can understand how > best to fit in with the development.) > Yup, that's the place. The tags usually represent iterative submissions to a test lab. As noted above I can't really know what the final submission is until well after the fact. > > I am very sorry if my tone is inappropriate; I think your tone is typical of spirited discussions in open forums like this and no offense is taken on my part. I've had to deal with much worse in other less public forums. I can tell you that this kind of "frank exchange of views" does not play well everywhere, most bureaucracies (not just the CMVP) have very different ways of working and establishing consensus. So please please please direct all flames at me and not at them. -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]
