[Cryptography Team] Common Criteria Documentation...

[Ron Teitelbaum]

BINGO!

Ok so now we are on the same page!

I agree with your VM assessment although I will be working towards
validating our changes and working them into the main stream, since I can't
believe that anyone would not want a secure VM.  The biggest argument I
expect is about performance, but if we can moderate the impact of
cryptography on performance (there will of course be some penalty but newer
technologies for VM may help with overall performance), then hopefully the
changes we suggest will be acceptable to the community.   

Of course documentation, testing and performance evaluations will be very
important part of having the community accept our changes.

Ron

> -----Original Message-----
> From: Kyle Hamilton [mailto:aerowolf at gmail.com]
> Sent: Friday, October 20, 2006 1:57 PM
> To: Ron at usmedrec.com
> Cc: Cryptography Team Development List
> Subject: Re: [Cryptography Team] Common Criteria Documentation...
> 
> 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