[Cryptography Team] Common Criteria Documentation...

[Kyle Hamilton]

Hi Ron!

Okay.  Now I think we're MUCH closer to understanding.

Krishna did ask me for detail, to be put onto the wiki -- not only
related to CC, but also to FIPS.  (A separate FIPS certification for
the cryptographic component is mandatory if a sysem is to be used in
the US government to handle any confidential data, per the Federal
Information Security Management Act of 2002.  This is where my
confusion comes in related to it, but it's something that can be put
on hold for a while.)

Your statement is that the immediate goal is the development of the
process through which we can meet all criteria necessary for
validation.  This is perfectly reasonable, especially as the process
requirements will be close to the same for whatever validations we go
through.

Krishna asked me to put as much detail in the wiki as I can related to
functional and process requirements.  It is my sense that he wants to
design a process to modify Squeak for validation with as little red
tape as possible for the people involved, while still adhering to the
requirements necessary.  (At least, I hope that's his goal.  I
wouldn't want too much red tape, myself.)

If there are few people outside of the cryptography list who are
interested in getting Squeak ready to be validated, then the target
may end up taking the form of a separate Monticello package with all
of the modifications to the VM classes necessary, and instructions on
how to build a CC-conforming VM and systems based on it.  (Yay
documentation :) )  I don't know, and right now I'm tossing ideas out
on the table simply because of that.  I'm not the one who's going to
determine the final destination, nor the path by which we get there.

So.  If the goal is the process, then I'll find everything I can
related to the process requirements and put it on the wiki so that you
and Krishna can figure out ways that they can be met without imposing
too huge an overhead on the volunteers involved.  Functional
requirements that I find will also go on the wiki (in a separate
page), so that they can be distilled into an overall architecture...
while presumably still leaving room for individual design and
development.

Which seems to be the way that most successful open-source projects do
it anyway. :)

-Kyle H

On 10/20/06, Ron Teitelbaum <Ron at usmedrec.com> wrote:
> Hi Kyle,
>
> It looks like we are getting closer, but still slightly off.  Let's see if
> we can move more towards each other in our differences.
>
> > From: Kyle Hamilton
> > Sent: Friday, October 20, 2006 1:02 AM
> >
> > On 10/18/06, Ron Teitelbaum <Ron at usmedrec.com> wrote:
> > > I'm not sure I would put it that way.  Let me reword my intention in my
> > own
> > > words and see if they match what you are saying.  My goal is to first
> > set up
> > > an organized plan of attack.  I specifically asked Krishna to keep an
> > eye on
> > > the larger goal but to provide us with a road map that consists of a
> > short
> > > list of items that need to be accomplished.  We will work on a high
> > level
> > > feedback mechanism so that we can all see the big picture and where we
> > are
> > > in that larger process, but I want to make sure that the current tasks
> > are
> > > highlighted, considered carefully, and that the list of To-do's is short
> > and
> > > manageable.
> >
> > Every list of To-do's is made up of a thousand details.  If I read
> > this right, you want basically the top and some of the second-level
> > items in the outline, so that it can be distributed to each group...
> > and each group determines what's necessary.
>
> Not quite since there is really only one group.  We can work towards
> reaching out to other groups but only as we identify areas where we need
> help.  I don't believe that we have the resources to do things in parallel.
>
> >
> > I can understand your desire and need to keep it manageable -- you
> > are, essentially, the resource manager (as well as a resource!), and
> > Krishna is the project manager.
>
> Yes.
>
> > You need to have a high-level
> > overview of what kinds of resources (people, time, money) are going to
> > be needed, at what points in the process, so that you can make sure
> > that they're allocated properly (and not be surprised later on).
>
> Yes.
> >
> > Krishna's job, on the other hand, is the more detailed one.  This is
> > not a simple process.  Each and every single detail needs to be
> > checked and doublechecked -- yes, over time, the details can be
> > fleshed out for each group, but at this point the resource
> > requirements (and the support needed) aren't really known by anyone.
> > He needs as much information as he can get so that over the next
> > month, he can figure out the tasks, figure out what the bullet points
> > must be -- and figure out what resources will be needed for each task.
>
> Now here is where we get off track again.  Kristna's job is organization
> research and feedback.  Nobody in our group in an expert, and we will all
> contribute towards the process, tasks and big picture.  I don't expect that
> Kristna will be able to know everything, although he has considerable
> experience interpreting government requirements, so I expect that his
> contribution to defining the process will be considerable.
>
> Let me spell this out as distinctly as possible: The tasks ahead of us are
> huge; my goal right now is process.  The goal is not even CC or FIPS
> Validation, it is process.  Krishna's job right now is process.  He is a
> facilitator and an organizer.  We will all work together to make sure that
> we answer the questions that Krishna has.  Keep in mind what I mean by a
> small list of TO-Do's.  Considering the number of resources we have, a major
> goal is to simplify the process into manageable chunks.  This simplification
> may result in the process being extended indefinitely but as we work through
> and improve the process it will be possible for us to attract more
> resources.  Think of this first part as moving up a big hill and starting in
> low gear!
>
> >
> > After he figures that out and publishes it for you and all other
> > volunteers (including himself, you, me, every member of the VM team,
> > every member of the cryptography team, every member of the UI team,
> > every member of the documentation team, and everyone else who isn't
> > even on a team yet), that's when you can really do your job.  Krishna
> > will identify the questions that need to be answered, the roadblocks
> > in the way, the direction that the project needs to go, and basically
> > the tasks that need resources assigned to them.
> >
> > My job right now, as requested by Krishna, is to feed him as much
> > information as possible, and help him identify questions that need to
> > be answered before he can figure out what the top-level tasks will end
> > up being.  I expect that he'll consult with you regarding the
> > questions he has; I can provide information from the published
> > documents, but I can't interface with any external organizations
> > (that's a POC function, and I think someone appointed by the Squeak
> > Foundation itself should do that -- which is you).
>
> My task for you would be to help define the big picture but only in very
> broad strokes.  I think that putting together and understanding the process
> and where we might need to be steered back onto the road and out of a ditch
> is what you will be very good at.  As for actual work instead of steering I
> would like you to help focus on the actual first task as defined by Krishna.
> You are right we are waiting for a process and a first task from Krishna.
> The first task may be something like what are the steps to accomplish the
> first task.  Or what is the process for determining the first task.  I know
> it sounds simple but there is a huge benefit toward organization, and that
> right now is our goal.
>
> >
> > There appears to be some confusion remaining as to what is being
> > required, by whom.  The sense that you got from the evaluation
> > organization you spoke with seemed to be that a systemic evaluation
> > included component evaluation, where I'm seeing that there is a
> > political distinction being made by the CSRC at NIST, by the NSA, and
> > by US Code.  (I will be happily surprised if this distinction that I'm
> > seeing really isn't there, and that the FIPS validation can occur as
> > part of the CC validation... but I would be remiss if I didn't point
> > out the possibility that the sense you got from the conversation
> > wasn't necessarily the sense that the person who the conversation was
> > with was trying to convey, or that the person who conveyed had a
> > misunderstanding himself.)
> >
> > Remember: an application may use FIPS-specified cryptographic
> > algorithms, PRNG algorithms, key seeding mechanisms, etc -- but it's
> > not FIPS unless the cryptographic component is validated by an
> > independent testing organization.
>
> Ok understood, but my understanding is FIPS validation of cryptographic
> components can be done as a separate process, we could have both a system
> validation and a cryptographic component validations, my understanding is
> that there is little value to having the individual components validated if
> the systems as a whole is validated.  I could be wrong, but it sounded to me
> like more money spent for little value.
>
> >
> > > The design of code and handling of each task will be the responsibility
> > of
> > > the group with an eye on following the standards as closely as possible
> > so
> > > that we can achieve CC validation.
> >
> > Again, which CC protection profile validation are we attempting to
> > achieve?  Krishna has identified one that exists, that may or may not
> > be what we are attempting to work toward.  One of the roadblocks that
> > exists right now is that not all of us are on the same page as regards
> > eventual destination.
>
> Right this is something we need to decide.
>
> >
> > > > Squeak could meet the CC EAL4+ requirement for FIPS validated
> > > > cryptography by embedding OpenSSL, or by interfacing directly to the
> > > > CryptoAPI, and not implementing any cryptography internally.  (This
> > > > would also allow Squeak to be used by the US government now, in
> > > > low-assurance environments that require only EAL1+.)
> > >
> > > Yes and I would agree that this is a subject that we will need to
> > discuss as
> > > a group.
> >
> > Yes, not only on the cryptography list, but also on the main
> > Squeak-dev list.  It is also probably something that the Squeak
> > Foundation board will have to discuss and agree on.
>
> I disagree here, we can reach out for help when we need to but few people
> are interested in what we are doing (regrettably).  We will decide what we
> are going to work on, it may not be a consensus decision, and it may not be
> valuable to everyone but it will get us somewhere that we are not today.
>
> >
> > The way I would frame the question is thus:
> > How quickly do we want government agencies to be able to consider
> > Squeak as part of their acquisition strategy?
> > Is it worth doing in multiple phases -- i.e., make it possible now,
> > and then work on progressively more detailed assurance levels until it
> > finally meets the eventual protection profile goal?
> > As an alternative, should we do it in two phases by adding FIPS now,
> > and then meet the eventual Common Criteria validation destination
> > several years down the road, with no intermediate validations?
> > Or, should we just not worry about the government, and only present it
> > to them with the final destination's validation?
> >
> > I suspect there are other considerations that I'm not thinking about.
>
> These are things we will need to decide.
>
> >
> > > > What is the CC EAL level to which Java and Eclipse have been verified?
> > > >  What protection profiles have they been verified to meet?
> > >
> > > EAL4:
> > >
> > http://publib.boulder.ibm.com/infocenter/wasinfo/v6r0/index.jsp?topic=/com
> > .i
> > > bm.websphere.express.doc/info/exp/ae/rovr_commoncriteria.html
> >
> > From what I read there, Websphere has been verified to meet EAL4 in a
> > specific configuration.  That does not necessarily mean that Java
> > itself has been, nor does it necessarily mean that Eclipse has been.
> >
> > The standard Websphere configuration is not EAL4 verified -- it takes
> > downloading and faithfully following a 1 meg PDF to deploy it in a CC
> > verified configuration.
>
> Right but this is our goal too!  Understand that the value of our work is
> this document.  Our goal is to provide a map to others building applications
> and deploying them deliver CC validated software.  Our goal is not to
> validate Squeak or to have a validated running implementation it is to allow
> others to have that.  We have to set up a running implementation so that a
> lab can poke at it, but after that it goes away and what we did to get the
> system validated becomes that large implementation guide.  The goal is the
> implantation guide and deployed validated commercial Squeak software.  We
> won't be doing the deployment but we might consult with people that want too
> (to help fund the group!)
>
> >
> > Even then, it uses separately-FIPS-validated Java class libraries.
>
> Again I don't think that individual validation is necessary, but I could be
> wrong.  When we are ready to talk to a lab we will bring this up again, if
> we need individual component validation we will raise money for it at that
> time.
>
> >
> > > > (I realize that this isn't really a Squeak question, but I am curious
> > > > why on startup Croquet says, on Windows 2000, that there is no good
> > > > source of entropy for the random number generator.  This is something
> > > > that should be looked at, if only to make sure that it's not poisoning
> > > > this effort.)
> > >
> > > Andreas mentioned this to me; he is using a primitive call to an OS
> > level
> > > PRNG as entropy.  For Fortuna we need many more sources of entropy then
> > > that.  I will read through the requirements before starting this
> > project.
> >
> > On Windows, the HKLM\Software\Microsoft\Cryptography\Rng\Seed registry
> > key is available, as is the CryptoAPI's RC4-based entropy generator.
>
> Terrific I will look at this more closely to see if it will work.  We need
> 32 separate entropy sources for Fortuna!  It will be a fun project!  Maybe
> we could start a list on wiki?
>
> >
> > > I was asked by the lab I spoke with if we planned on doing individual
> > > component validation or system validation.  There feeling was that
> > > individual component validation is included in system validation so that
> > > having each component validated separately was not necessary.
> >
> > Again, I'm not sure if their interpretation is correct.  I'll look at
> > the various interpretations documents and see what I can find out --
> > but someone at the CSRC may be a better source of information.
> >
>
> OK!
>
> > > > At least, I'm presuming that those two (development of functional code
> > > > & determinance of packaging requirements) can be parallelized.
> > >
> > > My feeling is that we will need to do most of this by ourselves.  I will
> > try
> > > to find more consultants for high level review.  I do not expect to
> > bring in
> > > a lab until we are satisfied that we are very close, except for maybe an
> > > initial consultation, or as needed to answer questions if we feel we are
> > off
> > > track.
> >
> > Aye.
> >
> > Thanks again,
> >
> > -Kyle H
>
> Thanks,
>
> Ron
>
>


-- 

-Kyle H