On 10/18/06, Ron Teitelbaum Ron@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.
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. 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).
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.
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.
Even then, it uses separately-FIPS-validated Java class libraries.
(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