RE: I-0434: 3rd Party Hardware/Software And Assurance
- Subject: RE: I-0434: 3rd Party Hardware/Software And Assurance
- From: "Simpson, Randy" <RSimpson@ida.org>
- Date: Wed, 25 Jun 2003 10:13:56 -0400
- content-class: urn:content-classes:message
- Content-Transfer-Encoding: 8bit
- Content-Type: text/plain; charset="iso-8859-1"
- Thread-Index: AcM7IlvJlAmeoTjLQE+8Z9ZF1EOVrQAAKbgg
- Thread-Topic: I-0434: 3rd Party Hardware/Software And Assurance
I believe monolithic representation is the problem. The PP may state all requirements to be satisfied, but does that mean the TOE does it all? The PP might state it is either in the TSF or provided for by evaluated products in the environment. Most producers don't mind being evaluated for their own claims, but have trouble being evaluated for other people products claims, and often can't produce the evidence for these. Thus an ID system that communicates via crypto might use a 3rd party crypto system (for example, RSA?) and place those functionalities in the environment. It is important that he states that he relies upon this functionality in the environment. However, the PP isn't worded to allow this and he drops the PP conformance claim. I don't think this is what we had in mind. This, of course, begs the question of composability and that is where we should put some effort.
From: Daniel P. Faigin [mailto:email@example.com]
Sent: Wednesday, June 25, 2003 9:58 AM
To: Multiple recipients of list
Subject: RE: I-0434: 3rd Party Hardware/Software And Assurance
Jim Arnold said:
> I think the unfortunate problem here is that government PP
> authors are tending to over-specify requirements and even explicitly
> demand monolithic solutions, contrary to the design and construction of
> the vast majority of existing products. This problem is, of course, made
> worse by the U.S. government policies to use products evaluated using
> their PPs.
This statement bothers me quite a bit. Jim seems to be saying it is
wrong for a particular consumer group to design a specification for the
products they want to use, and then insist that the products they buy
conform to that specification. I though such a use was exactly the
intent of PPs and the CC. Whether or not the specification fits a
producers ideas of right or wrong, it reflects what the consumer has
asked for (and presumably, they have vetted their need). Once they have
determined their need, how is the problem made worse by the consumer
insisting that the products they buy meet their published need.
So, whether or not I agree with the government PPs, they reflect what
the government believes that it wants, and those desiring to sell to
the government should give them what it wants.
> While I think the CC requirements currently work for STs, I have to
> wonder whether PPs should be based on different or expanded rules -
> offering more selectivity of WHICH and flexibility in HOW requirements
> must be satisfied.
As for the WHICH, the proposal from the NIB published elsewhere
suggesting that conditional requirements be permitted would address
equivalency of requirements. And of course, a PP author is always free
to use explicitly specified requirements, as long as they can argue the
requirement they want is not already in the CC. They just have to mark
it as explicitly specified, which many people are loathe to do.
As for the how: The CC doesn't specify implementation. Developers are
free to choose whatever implementation they want that meets the stated
> Alternately, the notion of partial conformance could be accepted where
> some PP requirements are fulfilled by the TOE and the balance are
> assigned to the IT environment. As long as it is clear that this is the
> case (i.e., truth in advertising), I'm not sure what the problem would
> be (except what this means in the context of various gov't policies).
Remember that requirements assigned to the IT environment can be met by
the TOE, but not vice-versa. Thus, if a PP author wanted to allow
compliance as stated above, they need only write the PPs properly.
Date Index |
Thread Index |
Problems or questions? Contact firstname.lastname@example.org