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]

Reply via email to