[Cryptography Team] Common Criteria Documentation...

[Ron Teitelbaum]

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