Re: PD-0091: Dependencies of Requirements on the IT Environment

["Dr.Ir. D.J. Out" <out@itsef.tno.nl>]

> [JLA] Just because Part 1 is supposedly normative doesn't mean it is
> correct. Perhaps Part 1 should be changed instead of ASE or APE. However,
> I'm sticking to my story that if it is not in ASE, it is not actually
> required.

What I was trying to convey is that you can have the opinion that 
something is true, but that an appeal to the CC text is not valid is the 
case. The CC is not consistent here: so we are reduced to opinions.

> Sometimes you should therefore apply FPT_SEP  and similar requirements) 
> both to the software TOE (it protects itself partially) and to the 
> hardware environment (which does the other part). And use a refinement 
> to show who does what exactly.
> 
> [JLA] I think the CC was intended to address such TOE architectures and
> hence I believe that refinement should not be necessary as I think the
> requirements should implicitly apply only within the TSC. 

I do not understand the use of TSC here:

TSC = defined as the set of interactions with or within the TOE subject 
to the TSP (Part 1, para 69).
TSP = loosely defined as being expressed the set of SFRs for the TOE 
(Part 3 para 302).

So this statement translates to: SFRs apply only to those interactions 
with or within the TOE that are subject to the SFRs for the TOE.

According to the definitions:
- if the environment corrupts the TOE that is an interaction with the TOE.
- if FPT_SEP is an SFR for the TOE in the ST, this interaction is in the TSC
- Therefore, if FPT_SEP is an SFR for the TOE in the ST, the environment 
  corrupting the TOE, is in the TSC.

This boils down to: you cannot generally use FPT_SEP in unmodified form 
in a software-only TOE as the CC is currently written.

Work is ongoing in- and outside the CCIMB to rectify this. But in v2.1 
(and v2.2) you will be stuck with this.

 > Regardless, the
 > TSS should be looked to to determine exactly how the TOE meets the
 > requirements within its intended environment.

But in order to find out whether that was done correctly, I need to know 
what the requirement means in the first place. With this scenario I 
might as well go the ITSEC route and completely dispense with SFRs.

And then you get straight into the ITSEC troubles: where I think that I 
clearly wrote down the functions in my ST, you may differ. One goal of 
having the SFRs in the CC in Part 2 language is to help define the exact 
meaning of the security functions, not the other way around.

> [JLA] I think the proposed new ASE removed IT environment requirements, but
> I also think it was rejected by the powers that be. In any case, my
> statement applies to the current ASE.

The exact status is that they have been removed and that this removal 
has been agreed to, but a open study item is to find out how STs can 
support composition. This may or may not reintroduce SFRs for the 
environment.

> This stems from two things you want to do with Part 2 that conflict here:
> 1) If you want to make sure people do exactly what is in your PP, the 
> contents of this PP need to be very strictly defined
> 2) If you want to write an ST not based on a PP, you want to be able to 
> be a little bit more flexible
> 
> [JLA] I disagree that there is a conflict in my statement. I think the
> requirements should have broad applicability as presented by the CC. If a PP
> author is concerned that the possible set of TOEs could, as a result, be too
> broad, they are free to use operations (e.g., refinement) to narrow the
> scope of conformance. I think such narrowing is less important for an ST as
> the TSS should provide some narrowing of scope to help users better
> understand the TOE.

Its not a conflict in your statement (I did not formulate well): it 
comes from two groups of people wanting to do two things.
Your opinion: I want to write STs with "broad" SFRs, and if a PP author 
has problems, he should modify the SFRs (use refinements)
The US Scheme appears to have the opinion: we want to write PPs and 
therefore we make the SFRs themselves more narrow in Part 2. If an ST 
writer has a problem with that, he should modify them (use refinements 
or extensions).

With regards,

Dirk-Jan Out
-- 
TNO ITSEF BV
P.O. Box 96864          tel +31 70 374 0304
2509 JG The Hague       fax +31 70 374 0651
The Netherlands         www.commoncriteria.nl