Common Criteria Documentation...

> From: Kyle Hamilton
> Sent: Tuesday, October 17, 2006 11:26 PM
>
> Ron,
>
> 'large number of tasks' is an understatement. :)  The question is
> this: which validation are you looking for, first?  Two (well, three,
> really, but only two classes of) validations have been mentioned, and
> my question relates to which of them resources will be allocated to --
> which, in turn, defines what should go on the task list and with what
> priority.
>
> FIPS 140-2 is the Trusted Cryptographic Module, which in and of itself
> is a huge undertaking -- a high-level overview of the things required
> for it are "make sure that the binary representation of the code
> cannot be altered", "make sure that calls into the binary
> representation of the code cannot be diverted", "make sure that, once
> in FIPS mode, only FIPS-approved algorithms can be used", "ensure that
> the random number generator has a good enough source of entropy AND is
> then stirred by a FIPS-approved pseudo-random function", and various
> and sundry other things.  This is the validation that OpenSSL
> received, this is the validation that Windows CryptoAPI received, this
> is the validation that those two specific binary versions of Crypto++
> received, this is the mandatory validation for cryptographic software
> that is to be used by the US government.  (VM changes will be required
> for a validatable pure-Squeak FIPS implementation.)

>
> Common Criteria assurance validation is mandatory for entire systems
> that are to be used by the US government, and for information
> processing systems used by financial institutions.  It also provides
> (to my understanding) assurance that is good enough for HIPAA's
> requirements.  One of its requirements is that it use FIPS-validated
> cryptographic software, but it doesn't stop there -- this validation
> applies to entire systems and not merely the cryptographic component.
> In any case, the project eventually will need a FIPS-validated
> cryptographic component in its architecture

>
> A problem exists with loosening the documentation requirements for too
> long -- which is that if it is left for too long, the criteria simply
> cannot be met.  Krishna suggested a Protection Profile as a target
> ("Single-Level Operating Systems in Medium Robustness Environments
> PP") which requires that the system must meet EAL 4 with some
> augmentations.  In order to do that, there are some requirements,
> including partially-automated configuration management (I'm thinking
> that Monticello may be good enough for this, though I have not looked
> at it or the CC in sufficient detail to be able to state
> definitively), that require that only authorized changes can be made
> to any configuration item.
>
> I quote paragraph 217 from the Common Criteria v2.3 Part 3 document:
>
> 217  EAL4 also provides assurance through the use of development
> environment controls  and additional TOE configuration management
> including automation, and evidence of secure delivery procedures.
>
> All of the relevant information is contained in the CC v2.3
> documentation (the administrative requirements are contained in part
> 3).  Suffice it to say, though, that one of the requirements is that
> no developer should be able to insert unauthorized or malicious code
> or information undetected -- and since the profile includes that
> Administrator and User documentation will be created and delivered,
> those documents must be kept under Configuration Management as well.

>
> So, to sum it all up: One of the tasks that needs to be completed is
> to set up an authenticated configuration management system before the
> user and administrator documentation is written.  As I said, the
> current wiki system will not be sufficient for the long term, but
> there's a huge mountain of other tasks as well.  Since no
> administrator or user documentation is being created at this point,
> the wiki does not need to move to a positive identification system
> yet.  Not in the short term, and probably not in the medium term.
> This doesn't mean that the eventual need shouldn't be planned for.

> > Common Criteria assurance validation is mandatory for entire systems
> > that are to be used by the US government, and for information
> > processing systems used by financial institutions.  It also provides
> > (to my understanding) assurance that is good enough for HIPAA's
> > requirements.  One of its requirements is that it use FIPS-validated
> > cryptographic software, but it doesn't stop there -- this validation
> > applies to entire systems and not merely the cryptographic component.
> > In any case, the project eventually will need a FIPS-validated
> > cryptographic component in its architecture
>
> Ahhh this may be the point that I am missing, are you saying validation of
> the individual components need to meet FIPS criteria?

> I thank you very much for your participation.  I know that you will be an
> extremely valuable part of the team.  My only concern is that we need to
> take this one step at a time in order to make sure that everyone is on the
> same page.  Nothing should be assumed, and no steps should be skipped.  I
> think that it is very important to flush out the big picture, but I want to
> as quickly as possible focus on manageable detail tasks.  As we move forward
> we need feedback as to the big picture but I don't want the big picture to
> get in the way of actual progress.  That is why I felt that the Validation
> Officer position was needed and why it is so important.  Someone needs to
> manage the big picture.

> I agree with these points and agree that they are very important once we
> freeze development and identify a platform that will be used for validation.
> Since we are no where near ready for this freezing, controlling the
> environment is not needed.  This was how OpenSSL validation worked.  Once
> they started they picked a version and set it up for the lab.  Once that was
> done any changes needed to be very closely tracked.  I've done FDA
> documentation and I know the mantra, "A CHANGE IS A CHANGE IS A CHANGE".
> Even code COMMENTS needed to be documented in the journals for the
> inspectors.  So once we decide that we can pass CC we will have to set this
> up and strictly follow all of the guidelines under the supervision of the
> lab.

> -----Original Message-----
> From: [hidden email]
> [mailto:[hidden email]] On
> Behalf Of Kyle Hamilton
> Sent: Wednesday, October 18, 2006 1:49 PM
> To: [hidden email]; Cryptography Team Development List
> Subject: Re: [Cryptography Team] Common Criteria Documentation...
>
> Hey, Ron!
>
> On 10/18/06, Ron Teitelbaum <[hidden email]> wrote:
> > Yes this is what I had in mind.  My understanding though was that
> > following common criteria was a good first step since receiving
> > official FIPS 140-2 validation was a very large task.  If CC is not
> > possible without meeting the specifications of FIPS 140-2 (even
> > without having an official validation) then we should start there.
>
> I'm reading this to mean that all effort should be put into
> the cryptographic components for inclusion into the VM, with
> an eye toward making sure that those components won't later
> interfere with a CC validation... with the main
> responsibility for the "design won't interfere later" on
> Krishna.  Do I understand correctly?
>
> >  The things that you just mention have been the pieces that
> I've been
> > considering.  If they are the only pieces that are still
> outstanding
> > then we should take them as tasks, assume that we will find a way
> > around them and move onto the other validation tasks.  
> Since they will
> > be a long process and there is no guarantee that what we
> come up with
> > will be adequate without having an official lab help to set the
> > development agenda for qualifying our software.
>
> Aye.  I'd suggest contacting the lab that the OpenSSL team
> used, since they're much more likely to be amenable to
> concepts other than just "binary-only".
>
> > As for the specific tasks you mention:
> > Code isolation and exclusive use of validated code, I agree
> with you
> > that the right way to accomplish this is by embedding the code into
> > the VM, and signing that VM, or having some sort of crc
> code checking and a signed VM.
>
> *cough*HMAC*cough* :)
>
> > What has me confused is that
> > I see that Java and Eclipse have gained CC validation without FIPS
> > 140-2 validation so it appears to me that CC is less strict, and it
> > must be possible to gain CC validation since Java and
> Eclipse are both
> > VM type environments.  It might be a good idea for me to
> find someone
> > from one of those teams also.  I will reach out to the Eclipse
> > community to see if I can get some help understanding the
> differences.
>
> Common Criteria validation does not necessarily include FIPS
> validation.  A CC validation cannot be used to show proof of
> FIPS validation.
>
> CC relates to the overall security of the system.  FIPS
> relates solely to the cryptographic module.
>
> 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+.)
>
> What is the CC EAL level to which Java and Eclipse have been verified?
>  What protection profiles have they been verified to meet?
>
> EAL4+ is a prerequisite to the "Single-level OS/moderate assurance
> environments" protection profile, but that means that EAL4+
> can be acheived without meeting the requirements for the
> protection profile.
> FIPS cryptography is mandatory for the protection profile,
> though I have not read whether it's mandatory for EAL4.  
> ("EAL4+" means "assured to Common Criteria level 4, with some
> additional security-related augmentations.")
>
> Basically, I would suggest that you read through part 1 of
> the Common Criteria v2.3 documentation (available in the
> Google svn repository) in order to understand what it is.  
> There is also a shorter, more executive introduction to
> precisely what it is and is not in one of the NOSPEC documents.
>
> > PRNG I plan to work on Bruce's FORTUNA implementation for squeak.
>
> Alright.  Please read the FIPS requirement for PRNG for test
> vectors and such.
>
> (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.)
>
> > > Common Criteria assurance validation is mandatory for
> entire systems
> > > that are to be used by the US government, and for information
> > > processing systems used by financial institutions.  It
> also provides
> > > (to my understanding) assurance that is good enough for HIPAA's
> > > requirements.  One of its requirements is that it use
> FIPS-validated
> > > cryptographic software, but it doesn't stop there -- this
> validation
> > > applies to entire systems and not merely the
> cryptographic component.
> > > In any case, the project eventually will need a FIPS-validated
> > > cryptographic component in its architecture
> >
> > Ahhh this may be the point that I am missing, are you saying
> > validation of the individual components need to meet FIPS criteria?
>
> The only component that can be FIPS-validated is the
> cryptographic component.  (The cryptographic component, as a
> whole, must be validated to FIPS 140-1 or FIPS 140-2, and all
> cryptographic operations must be performed by that component.
>  This means that Squeak could acquire a FIPS 140-1 validated
> cryptographic module and use that for the FIPS validation
> requirement.  This doesn't change the fact that the only FIPS
> validation that any crypto component newly written in Squeak
> could acquire is 140-2.)  The rest of the CC protection
> profile specifies how the cryptographic module is used.
>
> (The reason for the FIPS requirement in the protection
> profile is political, not necessarily technical.  The PP was
> authored by the NSA, which is mandated to use FIPS 140-x
> cryptography for non-classified purposes.  Since the NSA
> creates things for its own use first, and only THEN for other
> people to use, it had to specify FIPS 140-x for the
> cryptographic components.)
>
> > My biggest concern right now is building something that we think is
> > acceptable just to find that it misses the mark.  I do like
> the idea
> > of brainstorming solutions, so that we have things we can present.
> > But I would not want to build any of them without some gut check
> > validation with people that know.
>
> Agreed.  All we can do is read the requirements, interpret
> them to the best of our (fairly limited) ability, build code
> that conforms to the functional testing requirements, and
> (with guidance) figure out how to package that into a
> coherent, validatable whole.
>
> At least, I'm presuming that those two (development of
> functional code & determinance of packaging requirements) can
> be parallelized.
>
> > I thank you very much for your participation.  I know that
> you will be
> > an extremely valuable part of the team.  My only concern is that we
> > need to take this one step at a time in order to make sure that
> > everyone is on the same page.  Nothing should be assumed,
> and no steps
> > should be skipped.  I think that it is very important to
> flush out the
> > big picture, but I want to as quickly as possible focus on
> manageable
> > detail tasks.  As we move forward we need feedback as to the big
> > picture but I don't want the big picture to get in the way
> of actual
> > progress.  That is why I felt that the Validation Officer
> position was
> > needed and why it is so important.  Someone needs to manage
> the big picture.
>
> In order to get to manageable task details, I think it's
> important that everyone know the eventual target so that it
> guides them during the design and implementation.  That's why
> I've been rushing through making sure that the eventual
> requirements are out on the table, so that people can look at
> them and understand why the tasks are happening, and what the
> deliverables from those tasks need to be able to support.  
> (Bluh.  I'm sounding like a middle manager. :P)
>
> > I agree with these points and agree that they are very
> important once
> > we freeze development and identify a platform that will be
> used for validation.
> > Since we are no where near ready for this freezing, controlling the
> > environment is not needed.  This was how OpenSSL validation
> worked.  
> > Once they started they picked a version and set it up for the lab.  
> > Once that was done any changes needed to be very closely tracked.  
> > I've done FDA documentation and I know the mantra, "A
> CHANGE IS A CHANGE IS A CHANGE".
> > Even code COMMENTS needed to be documented in the journals for the
> > inspectors.  So once we decide that we can pass CC we will
> have to set
> > this up and strictly follow all of the guidelines under the
> > supervision of the lab.
>
> I suppose I'm still thinking in terms of TCSEC -- everything
> had to be documented from the outset.  Ah well -- welcome to
> the new world. ;)
>
> > No need to apologize, I very much appreciate your contribution and
> > encourage you to participate as much as possible.  Having
> you on the
> > team will help a great deal towards our goal of validation!
>  Thank you!
>
> It's something I'm good at, and I enjoy.  Thank you for having me!
>
> > > You and/or Krishna are going to make decisions as to the exact
> > > procedures that the team and project are going to use -- however,
> > > I'm an agoraphobic bachelor, and I thus have more time to
> research
> > > the requirements much more in-depth than you two can.  
> This suggests
> > > that I should do so, and make recommendations based on
> what I have
> > > found.
> >
> > Your contributions and research are very much appreciated.  Sorry
> > about your phobias.  Are you working towards facing those fears?
>
> I am, yes, but I don't particularly want to make that a
> discussion point.  I brought it up as an explanation for what
> I'm doing (researching), why I'm doing it (to help you make
> informed decisions), and the situation that makes it possible
> (so that you understand that I actually am reading these
> things, putting my intellect toward understanding them, and
> not just making stuff up).
>
> > > I liken this to the role of a research librarian -- sift through
> > > mountains of data, to provide a concise report.  As I
> said, I defer
> > > to you and Krishna -- but if you want to know the
> rationale behind
> > > something I suggest, I will quote you book, chapter and
> paragraph of
> > > everything relevant that I have found so that you can
> make up your
> > > own minds without having to sift through the mountains yourselves.
> >
> > That will be very helpful for us to understand!
>
> Also, you can ask me to find out about some aspect, and I'll
> come up with a report of my understanding of the issue after
> research, as well as the precise sources I found related to
> it.  (The CC documents make it easy by numbering their
> paragraphs. :) )
>
> I should point out: I'm very interested in cryptography, but
> am not at all good at coding Smalltalk yet.  I'm still
> wrapping my head around "everything AND I DO MEAN EVERYTHING
> is an object".
>
> Wish I'd grown up with Smalltalk instead of Applesoft BASIC. ;)
>
> Cheers!
>
> -Kyle H
> _______________________________________________
> Cryptography mailing list
> [hidden email]
> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/cry
> ptography
>

> From: Kyle Hamilton
> Sent: Wednesday, October 18, 2006 4:49 PM
>
> Hey, Ron!
>
> On 10/18/06, Ron Teitelbaum <[hidden email]> wrote:
> > Yes this is what I had in mind.  My understanding though was that
> following
> > common criteria was a good first step since receiving official FIPS 140-
> 2
> > validation was a very large task.  If CC is not possible without meeting
> the
> > specifications of FIPS 140-2 (even without having an official
> validation)
> > then we should start there.
>
> I'm reading this to mean that all effort should be put into the
> cryptographic components for inclusion into the VM, with an eye toward
> making sure that those components won't later interfere with a CC
> validation... with the main responsibility for the "design won't
> interfere later" on Krishna.  Do I understand correctly?

>
> >  The things that you just mention have been the
> > pieces that I've been considering.  If they are the only pieces that are
> > still outstanding then we should take them as tasks, assume that we will
> > find a way around them and move onto the other validation tasks.  Since
> they
> > will be a long process and there is no guarantee that what we come up
> with
> > will be adequate without having an official lab help to set the
> development
> > agenda for qualifying our software.
>
> Aye.  I'd suggest contacting the lab that the OpenSSL team used, since
> they're much more likely to be amenable to concepts other than just
> "binary-only".
>
> > As for the specific tasks you mention:
> > Code isolation and exclusive use of validated code, I agree with you
> that
> > the right way to accomplish this is by embedding the code into the VM,
> and
> > signing that VM, or having some sort of crc code checking and a signed
> VM.
>
> *cough*HMAC*cough* :)
>
> > What has me confused is that
> > I see that Java and Eclipse have gained CC validation without FIPS 140-2
> > validation so it appears to me that CC is less strict, and it must be
> > possible to gain CC validation since Java and Eclipse are both VM type
> > environments.  It might be a good idea for me to find someone from one
> of
> > those teams also.  I will reach out to the Eclipse community to see if I
> can
> > get some help understanding the differences.
>
> Common Criteria validation does not necessarily include FIPS
> validation.  A CC validation cannot be used to show proof of FIPS
> validation.
>
> CC relates to the overall security of the system.  FIPS relates solely
> to the cryptographic module.
>
> 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+.)

>
> EAL4+ is a prerequisite to the "Single-level OS/moderate assurance
> environments" protection profile, but that means that EAL4+ can be
> acheived without meeting the requirements for the protection profile.
> FIPS cryptography is mandatory for the protection profile, though I
> have not read whether it's mandatory for EAL4.  ("EAL4+" means
> "assured to Common Criteria level 4, with some additional
> security-related augmentations.")
>
> Basically, I would suggest that you read through part 1 of the Common
> Criteria v2.3 documentation (available in the Google svn repository)
> in order to understand what it is.  There is also a shorter, more
> executive introduction to precisely what it is and is not in one of
> the NOSPEC documents.
>
> > PRNG I plan to work on Bruce's FORTUNA implementation for squeak.
>
> Alright.  Please read the FIPS requirement for PRNG for test vectors and
> such.
>
> (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.)

>
> > > Common Criteria assurance validation is mandatory for entire systems
> > > that are to be used by the US government, and for information
> > > processing systems used by financial institutions.  It also provides
> > > (to my understanding) assurance that is good enough for HIPAA's
> > > requirements.  One of its requirements is that it use FIPS-validated
> > > cryptographic software, but it doesn't stop there -- this validation
> > > applies to entire systems and not merely the cryptographic component.
> > > In any case, the project eventually will need a FIPS-validated
> > > cryptographic component in its architecture
> >
> > Ahhh this may be the point that I am missing, are you saying validation
> of
> > the individual components need to meet FIPS criteria?
>
> The only component that can be FIPS-validated is the cryptographic
> component.  (The cryptographic component, as a whole, must be
> validated to FIPS 140-1 or FIPS 140-2, and all cryptographic
> operations must be performed by that component.  This means that
> Squeak could acquire a FIPS 140-1 validated cryptographic module and
> use that for the FIPS validation requirement.  This doesn't change the
> fact that the only FIPS validation that any crypto component newly
> written in Squeak could acquire is 140-2.)  The rest of the CC
> protection profile specifies how the cryptographic module is used.

>
> (The reason for the FIPS requirement in the protection profile is
> political, not necessarily technical.  The PP was authored by the NSA,
> which is mandated to use FIPS 140-x cryptography for non-classified
> purposes.  Since the NSA creates things for its own use first, and
> only THEN for other people to use, it had to specify FIPS 140-x for
> the cryptographic components.)
>
> > My biggest concern right now is building something
> > that we think is acceptable just to find that it misses the mark.  I do
> like
> > the idea of brainstorming solutions, so that we have things we can
> present.
> > But I would not want to build any of them without some gut check
> validation
> > with people that know.
>
> Agreed.  All we can do is read the requirements, interpret them to the
> best of our (fairly limited) ability, build code that conforms to the
> functional testing requirements, and (with guidance) figure out how to
> package that into a coherent, validatable whole.
>
> At least, I'm presuming that those two (development of functional code
> & determinance of packaging requirements) can be parallelized.

>
> > I thank you very much for your participation.  I know that you will be
> an
> > extremely valuable part of the team.  My only concern is that we need to
> > take this one step at a time in order to make sure that everyone is on
> the
> > same page.  Nothing should be assumed, and no steps should be skipped.
> I
> > think that it is very important to flush out the big picture, but I want
> to
> > as quickly as possible focus on manageable detail tasks.  As we move
> forward
> > we need feedback as to the big picture but I don't want the big picture
> to
> > get in the way of actual progress.  That is why I felt that the
> Validation
> > Officer position was needed and why it is so important.  Someone needs
> to
> > manage the big picture.
>
> In order to get to manageable task details, I think it's important
> that everyone know the eventual target so that it guides them during
> the design and implementation.  That's why I've been rushing through
> making sure that the eventual requirements are out on the table, so
> that people can look at them and understand why the tasks are
> happening, and what the deliverables from those tasks need to be able
> to support.  (Bluh.  I'm sounding like a middle manager. :P)
>
> > I agree with these points and agree that they are very important once we
> > freeze development and identify a platform that will be used for
> validation.
> > Since we are no where near ready for this freezing, controlling the
> > environment is not needed.  This was how OpenSSL validation worked.
> Once
> > they started they picked a version and set it up for the lab.  Once that
> was
> > done any changes needed to be very closely tracked.  I've done FDA
> > documentation and I know the mantra, "A CHANGE IS A CHANGE IS A CHANGE".
> > Even code COMMENTS needed to be documented in the journals for the
> > inspectors.  So once we decide that we can pass CC we will have to set
> this
> > up and strictly follow all of the guidelines under the supervision of
> the
> > lab.
>
> I suppose I'm still thinking in terms of TCSEC -- everything had to be
> documented from the outset.  Ah well -- welcome to the new world. ;)
>
> > No need to apologize, I very much appreciate your contribution and
> encourage
> > you to participate as much as possible.  Having you on the team will
> help a
> > great deal towards our goal of validation!  Thank you!
>
> It's something I'm good at, and I enjoy.  Thank you for having me!
>
> > > You and/or Krishna are going to make decisions as
> > > to the exact procedures that the team and project are going to use --
> > > however, I'm an agoraphobic bachelor, and I thus have more time to
> > > research the requirements much more in-depth than you two can.  This
> > > suggests that I should do so, and make recommendations based on what I
> > > have found.
> >
> > Your contributions and research are very much appreciated.  Sorry about
> your
> > phobias.  Are you working towards facing those fears?
>
> I am, yes, but I don't particularly want to make that a discussion
> point.  I brought it up as an explanation for what I'm doing
> (researching), why I'm doing it (to help you make informed decisions),
> and the situation that makes it possible (so that you understand that
> I actually am reading these things, putting my intellect toward
> understanding them, and not just making stuff up).
>
> > > I liken this to the role of a research librarian -- sift through
> > > mountains of data, to provide a concise report.  As I said, I defer to
> > > you and Krishna -- but if you want to know the rationale behind
> > > something I suggest, I will quote you book, chapter and paragraph of
> > > everything relevant that I have found so that you can make up your own
> > > minds without having to sift through the mountains yourselves.
> >
> > That will be very helpful for us to understand!
>
> Also, you can ask me to find out about some aspect, and I'll come up
> with a report of my understanding of the issue after research, as well
> as the precise sources I found related to it.  (The CC documents make
> it easy by numbering their paragraphs. :) )

>
> I should point out: I'm very interested in cryptography, but am not at
> all good at coding Smalltalk yet.  I'm still wrapping my head around
> "everything AND I DO MEAN EVERYTHING is an object".
>
> Wish I'd grown up with Smalltalk instead of Applesoft BASIC. ;)
>
> Cheers!
>
> -Kyle H

> From: Kyle Hamilton
> Sent: Friday, October 20, 2006 1:02 AM
>
> On 10/18/06, Ron Teitelbaum <[hidden email]> 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.

>
> 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).

>
> 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.

>
> > 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.

>
> > > 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.

>
> 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.

>
> > > 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.

>
> > > (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.

>
> > 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.
>

> > > 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

> 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 <[hidden email]> 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
>
>

> -----Original Message-----
> From: Kyle Hamilton [mailto:[hidden email]]
> Sent: Friday, October 20, 2006 1:57 PM
> To: [hidden email]
> 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 <[hidden email]> 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 <[hidden email]> 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