On Dec 2, 2007 4:31 PM, Steve Marquess <[EMAIL PROTECTED]> wrote: > Kyle Hamilton wrote:
> > 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. That's the best location to focus energy 'at the current time'. That will /not/ necessarily be the best location at various points during a validation-ramp. > > 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. I'm trying to point out something that I perceive as an issue in the organizational intelligence. Experience shows that retroactive changes may be required. If that's the case, you can still accept the requirement, make the changes necessary to the codebase, and put the results of that change (the 'proposed changes') back out to the community for a week for another round of "make sure it's portable" testing, with the only reports/patches being accepted for that being for the purposes of portability. The Open Source community as a whole can be viewed a stakeholder in the OpenSSL FIPS process. Everyone who's ever worked on the code is a direct stakeholder. Everyone who's ever compiled the code or reported a bug or a security issue is an indirect stakeholder. That's labor, that's sweat equity -- though it be not bound by contract, it must ethically be recognized. As stakeholders, we only seek to gain (and maintain) the ability-to-use. If a FIPS-validated module doesn't compile or run/test somewhere the non-FIPS-validated code does, then that ability is lost, and you alienate everyone who doesn't have a platform that it can be run on. > > 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. First validation allowing static linking, first validation on source -- yes. What you and your organization have achieved is remarkable, and some would rightly call it 'miraculous'. But... you have chosen to "work within the system as much as possible", without realizing that you have created a new system. You have created, and pioneered, an extremely important bridge, but unless it's buttressed and properly strengthened it won't be useful for anyone else. In fact, it could even be a liability for anyone else who tries, if the organizations expect to be worked with in a given manner and information on that manner isn't shared. And if you don't share your knowledge, when you're gone there won't be anyone who has your knowledge to be able to continue the work that you're doing with OpenSSL. There won't be anyone to continue turning this bridge you've built from a rickety wooden 1-lane bridge into a bridge capable of supporting substantial traffic. > > ... 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. ...assuming they want to use the OpenSSL code base, which some people cannot do for various reasons. I was rather unclear in my original statement: I'm not talking "only OpenSSL", here, I'm talking "any project which makes source available to the public and/or receives contributions from the public". > 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. Much of the problem comes from the fact that this is also the first source-compilable FIPS-validated module. The module itself is subject to white-box analysis, not black-box, and that is what allows things like the RNG flaw to be found and dealt with. This is the type of analysis that the CMVP /doesn't/ do. This is the type of analysis that the CMVP's policies and procedures weren't designed around the idea of making public. (Yes, Mozilla's NSS has had validations performed, but their FIPS-validated modules are also not source-compilable.) The flaw is in the CMVP policies and procedures, in their basic design and presumptions -- but we can't change those. (The primary flaw is this assumption: "all organizations have a vested interest in preventing their implementation details from being made public." The entire process has been built around that assumption. Since OpenSSL's validations, they've been likely revisiting this and causing new requirements to be made available, but they're still bound by regulation and statute that prescribe a specific means of handling the modules they work with. They really don't have the flexibility required to adapt to this other, more public model any more quickly than they have been.) > > 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. As noted above, there's other things the openssl organization can do to ensure the submission has gone through at least some semblance of the QA that the opensource community can bring to bear. Yes, it makes things a bit more hectic, yes it adds another line-item to the schedule before each validation submission (or resubmission) -- but honestly? The FIPS validation sponsors don't exactly get much of a favor by ignoring this step, either. > 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. ...funny, I have only the sketchiest of information on who those bureaucracies would be, and no information on contacts within them to flame. How would I direct the flames? To whom would I direct the flames? And if the flames were viewed as generated by the openssl validation, what would exist to prevent the ire raised by the heat from being directed back at openssl's future validations? It'd be daft to direct my opinions anywhere /but/ here. I also don't direct flames personally, if I can avoid it. Organizations are abstract, but people are people and it does not help to insult, defame, or otherwise cause problems. Especially when trying to effect changes in organizations that people are part of. To make plain the changes that I'd like to see, in order of my perception of possibility/likelihood: a) I would like to see the the addition of ability for the community (which is otherwise unrepresented in the validation process) to be able to contribute to the code submitted for validation, for the purposes of ensuring that the platforms which are supposed to be supported actually are. I have suggested the smallest way I can see this being useful in the process. b) I would like to see more information made public about specific timeframes and timelines contemplated by OSSI as relate to openssl's ongoing validation lifecycles. (You have already gone through two validations, and you have seen what can happen and what must happen -- even though the validation sponsorship money can't be relied upon to be there, you at least have some inkling as to the things that must be done and in what timeframes, which means that the process can be documented.) c) I would like to know where to find the formal specification documents for what must be met in a module boundary, and (to a lesser extent) the formal documentation/proof of how OpenSSL's fipscanister meets that specification. (One thing I've learned: almost all validation is a matter of paperwork -- even the query/response validation system that the CMVP specifies is a matter of ensuring that the paperwork that is generated by the module is correct. Because of that paperwork requirement, the process is auditable. I'm pretty sure that what I would like to see here has already been done, but I've not yet found it.) d) I would like to see more, generic information about the process as far as how it has already been done, and what hoops needed to be jumped through. (Rationale: you have the information necessary to do a risk analysis of the process. Mozilla's NSS validation sponsor does, too. But, nobody else in the open-source community does. Ron Teitelbaum for example, head of Croquet's cryptography development group, doesn't.) I'll end this by saying "it took me three and one half hours to write this." I understand the effort of writing, and I understand its time-consuming nature, and that's part of why I don't have any desire to flame at all. I appreciate your input, Steve M, and I appreciate the time that you have taken thus far to express what you've thus far been willing and able to. I basically seek to find a means by which we (the users) can contribute to something which is arguably the most important advance of open source into US governmental computation, so that we can then contribute things which utilize it. -Kyle H ______________________________________________________________________ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
