RE: I-0434: 3rd Party Hardware/Software And Assurance

["Daniel P. Faigin" <faigin@aero.org>]

> The problem is not with the notion of consumers specifying requirements
> and insisting they be met. The problem is a broader problem of
> specifying requirements that are in effect not practical to meet.

The underlying assumption is that the author of a PP has vetted the PP 
to ensure that the requirements are practical. Of course, it is 
important to note that the APE requirements do not require an evaluator 
to check that the requirements are practical, or even make sense -- 
only that they are consistent and coherent :-)

More importantly, the US Government profiles (supposedly) represent the 
needs of the DoD. Those of us that work with the DoD understand (but 
the general public does not) that the DoD needs and requirements are 
not necessarily *practical*, but are what are felt necessary to ensure 
that safety and security of the mission of defending this nation. Thus, 
although some particular product may be suitable for a consumer use, or 
even in a non-critical government use (Commerce, HUD, etc.), something 
stronger might be needed for defense purposes.

> Insisting that a product be evaluated against a PP is worse in the case
> where the only applicable PPs do not match the intended application, but
> must be met because a policy says you have to be evaluated against a PP
> should one happen to exist (regardless of its content).

I'm not trying to say that the US Government PPs are perfect. However, 
to say something is *worse* for complying with a PP is just wrong. We 
should be endeavoring to make the PPs correct for their intended use 
(and suitably strong), not necessarily weakening them to meet the 
products commercially available.

I've seen this working on the Web Browser PP. There are functions that 
one might want even in a basic secure browser that are not in browsers 
today (for example, appropriate sandboxing of all mobile code, not just 
Java). Should we weaken the profile simply because the products today 
cannot meet it, or should we set the bar based on the threat, and let 
those that want to sell to the government meet the bar?

> > As for the how: The CC doesn't specify implementation. Developers are
> > free to choose whatever implementation they want that meets the stated
> > requirements.
> 
> I am including the ability to allow a requirement to be met by the IT
> environment rather than the TOE as part of the HOW. Other examples,
> might include requiring a hardware rather than software solution.

I disagree. If a PP author, for reason of the perceived threat, wants a 
particular mechanism to undergo evaluation at the level of effort of a 
TOE component, as opposed to an IT environment component, they should 
be able to specify it and know that said specification will be 
followed. If they want to permit it to be met by the IT environment, 
then they can specify IT environment (which can be met by the TOE, if a 
developer wants). We shouldn't be second guessing the PP author.

As for requiring a hardware viz. software solution: If a specific 
implementation approach is desired by a PP author, they can specify it 
via refinement. If there is no refinement, the ST author can choose the 
implementation approach (with the exception that if something is 
specified as IT environment, it can't be met by a non-IT mechanism, 
such as procedures).

> I agree that a PP author could put requirements in the IT environment to
> offer flexibility, but I'm claiming that it is not inaccurate for an ST
> author to claim that they partially fulfill a PP (if it is true).

I have no problem with truthfully claiming that a particular ST meets 
some number of requirements of a particular PP, but not all, as long as 
it is clear that full compliance is not being claimed, and it is clear 
the areas in which the ST is non-compliant. Truth in advertising, and 
all that rot.

Daniel