If I'm understanding Mark Miller's thesis properly, it seems to be possible to look at Islands as performing the same set of operations that X.509 "Proxy Certificates" perform -- basically, as a user, you delegate permission to run on your behalf to the objects that you interact with, and they in turn grant permission to the objects they call to perform a limited set of functions for them, and so on. From the computer's point of view, you're the trust anchor (after your identity and authorization are validated from a trust anchor like a CA) for everything that it does on your behalf.
After your identity and authorization are validated, the system then evaluates the ability for code running on your behalf to perform certain operations based on what you are authorized to do.
FIPS 140-2 Level 2 requires EAL 2, not EAL 3. I think that EAL 3 is a better target to shoot for than EAL 2, though. (EAL 2 is a single-user environment.)
-Kyle H
On 12/1/06, Ron Teitelbaum Ron@usmedrec.com wrote:
Thanks Tim,
Based on that, if we design and distribute security components for Squeak and we want to be CC evaluated we should at a minimum shoot for level 3. We should revisit this when we have standard security components to offer.
All,
Would anything within Islands meet the criteria for a security component and be eligible for, or be contained in any existing security target, or protection profile? (Again my apologies for not being able to review it)
Ron
-----Original Message----- From: Cerebus [mailto:cerebus2@gmail.com] Sent: Friday, December 01, 2006 10:31 AM To: Ron@usmedrec.com; Cryptography Team Development List Subject: Re: [Cryptography Team] Todays Meeting update
On 12/1/06, Ron Teitelbaum Ron@usmedrec.com wrote:
Tim could you explain this in more detail?
You get EAL2 just for showing up at the meetings is what I hear. :)
http://en.wikipedia.org/wiki/Evaluation_Assurance_Level
""" EAL2: Structurally Tested
EAL2 requires the cooperation of the developer in terms of the delivery of design information and test results, but should not demand more effort on the part of the developer than is consistent with good commercial practice. As such it should not require a substantially increased investment of cost or time. EAL2 is therefore applicable in those circumstances where developers or users require a low to moderate level of independently assured security in the absence of ready availability of the complete development record. Such a situation may arise when securing legacy systems """
Basically, EAL2 says "It works and there's at least some evidence provided that it was designed," i.e., the developer showed up at the meetings. EAL1 says "It works but nobody showed it works on purpose," i.e., the developer didn't show any design documentation, or didn't have any design documents to show.
EAL3 and 4 are where the stringency takes hold.
-- Tim
Cryptography mailing list Cryptography@lists.squeakfoundation.org http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/cryptography