Re: PD-0101: Level of Detail Necessary for Assurance Requirements on Third Party Products
On Tue, 9 Mar 2004 12:13:36 -0500 (EST), "Dr.Ir. D.J. Out" <email@example.com> said:
> The TSF is "everything that you need to rely upon to enforce the TSP".
> If the RAM chips have severe flaws they will break the TSP.
> A RAM chip with the feature that whenever you load an address at address
> FFFF+1, will load the contents of that address into FFFF+1 at the next
> clock cyle would have some nice side effects.
But what you are depending on is functional correctness: they work like RAM
chips, just like we depend on the CPU's add function to add two numbers
right. It is not specific security functionality.
Usually, such functionality is not an explicit SFR, and is way below even the
HHD or LLD.
> So perhaps I should modify the question into "What should CC 3.0 say on
> this point?"
CC 3.0 should provide a way to do subsetting within assurance, so that
appropriate arguments can be made.
CC 3.0 should take into account the differences between hardware and software.
> If you are going to be like that: in CC you certify TOEs rather than
> products. What if the TOE is only part of a product or consists of two
In general, you need to be able to order whatever the TOE is. In that sense,
it is a product.
Date Index |
Thread Index |
Problems or questions? Contact firstname.lastname@example.org