Kyle Hamilton wrote: > > I'm trying to point out something that I perceive as an issue in the > organizational intelligence. > > ...<big snip>... > > 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. > I'm fine with this suggestion in principle, and for the next new validation(s) will try to encourage this community participation.
Please understand that no one has deliberately been excluded; to date all of our resources have been utterly exhausted on the goal of obtaining a validation on *some* platform. We had to make a lot of compromises on the first validation, the currently ongoing validation will be the first to be more or less feature (not platform) complete. Trying to cover all the platforms supported by the baseline OpenSSL has been far to ambitious for me to dream about. I'm open to collaboration with volunteers who would like to undertake the tedious effort of coordinating the platform testing with the fickle realities of the validation 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.) > Well the timeline for the ongoing validation is "hurry up and wait". At present we have no schedule for another validation; that's entirely dependent on sponsor funding. The various contracts and paperwork can take up to a month once funding is secured, so I can give that much heads-up. Unfortunately the beginning of the validation testing requires a final version of the code, so a real scramble ensues (with or without community input). How much time we can spare will be determined primarily by the sponsor deadline. That's why I encourage anyone concerned with the platform to check the head of the branch before the scramble begins. > 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.) > The short answer is that the two key documents are the FIPS 140-2 standard (http://csrc.nist.gov/publications/fips/fips140-2/fips1402.pdf) and the Implement Guidance (http://csrc.nist.gov/groups/STM/cmvp/documents/fips140-2/FIPS1402IG.pdf). There are additional standards documents for each of the algorithms and so forth that aren't hard to find at the NIST CMVP web site (http://csrc.nist.gov/groups/STM/cmvp/index.html). Each validation has a formal document called the Security Policy (http://csrc.nist.gov/groups/STM/cmvp/documents/140-1/140val-all.htm#733 in our case). I also wrote a more detailed unofficial companion document, the User Guide (http://www.openssl.org/docs//fips/UserGuide-1.1.1.pdf). I tried, though surely unsuccessfully, to make that document as comprehensive as possible. You won't make any sense of these quickly, though, if ever (I sure haven't). As for any specialized field of human endeavor there is a unique vocabulary and unwritten history that is largely impenetrable to the outsider. In my many years of working on various kinds of validations, certifications, approvals, approvals, audits, etc., I've come to the realization that all specialized formal non-technical or quasi-technical standards like FIPS 140-2 are essentially scripture: cryptic, contradictory in places, requiring interpretation by a "priesthood", often with passionate adherents and detractors. Scripture (FIPS 140-2) means exactly what the priesthood (the CMVP) says it does, no more and no less. There is no point in a layman like myself arguing scripture with the priesthood or adherents. I've been amused by the advice I've received in private messages from a number of well-meaning correspondents, all eager to share their knowledge of the one true "correct" interpretation of FIPS 140-2, and all contradicting each other and sometimes themselves. > 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.) > Heh, so would I :-) I've now done six FIPS 140-2 validations (some for proprietary code) and with each and every one there have been new hoops to jump through. The standards and the interpretations thereof are constantly evolving. I've learned that the requirements vary significantly with the test lab (so far I've only worked directly with two out of over a dozen) and with the individual at CMVP who does the paperwork review. I'm afraid a sample size of six isn't large enough to hazard many useful predictions of the process overall. I see the validation process now as far less predictable than I did five plus years ago when I knew nothing about it. That said I'll be glad to answer any questions that I can, it's just that it's a lot more impressionistic art than science. > 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. > I'll drink to that... -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]
