RE: I-0451: When To Use IFF/IFC And ACF/ACC

["Arnold, James L. Jr." <JAMES.L.ARNOLD.JR@saic.com>]

> >> > I think that we should make a distinction between the 
> requirement 
> >> > level (with abstract operations) and the implementation 
> level (with 
> >> > real-life operations). So the TOE should meet the abstract
> >> operations
> >> > no matter how it chooses to implement those operations 
> in reality.
> >> 
> >> We do: it is called objectives vs. SFRs.
> 
> > It seems as though you are mapping the abstract requirements in the 
> > previous statement to objectives and implementation details 
> to SFRs. 
> > If so, then I believe this is incorrect. Rather, it is SFRs 
> vs. TSS. 
> > SFRs are supposed to be relatively abstract to promote 
> comparability 
> > among PPs and STs alike. It is the TSS that is supposed to bring 
> > implementation specificity to a security target.
> 
> I disagree, to an extent. Certainly, for PPs, you do need 
> implementation independence. You don't need it for STs, as if 
> one was intending to compare the requirements for an ST, 
> there should be a PP in common. However, I do agree that STs 
> need not go to the lowest level of implementation detail.
> 
> I view SFRs in a PPs as a statement of "I want". I view SFRs 
> in an ST as a statement of "Here's what I claim to give you". 
> The TSS is a statement of "Here's how I claim to have done 
> it". The ETR is the verification of the claim, and the VR is 
> the verification of the ETR's work.

I think we need to differentiate preference from requirement. In fact, I
have seen PPs developed to serve essentially as RFPs and as such were pretty
specific, sometimes delving into implementation details. PPs like STs can be
implementation specific - there is nothing in the CC to disallow this. The
only difference between requirements in PPs and STs is that STs MUST to
complete all incomplete operations, while PPs only MAY do so. In both cases,
I view SFRs as "though shalt" as opposed to "I want" or "I claim" (in other
words, requirements have the same intent and meaning regardless of whether
they are part of a PP, ST, or some other package). I agree that the SFRs in
an ST are intended to document what the TOE must do (just like those in a
PP) and the TSS is intended to explain how the TOE does it. But I disagree
that the claimed set of SFRs need to have any implementation dependence or
specificity at all. I also disagree that comparison is only intended to
happen through PP claims. Generally, less implementation specific means more
comparable and comparisons can happen based on the content of PPs and STs
alike.

You statement that the ETR is the verification of the claims is generally
correct. However, to go a bit further, the ETR substantiates that the
claimed environment is satisfied by the claimed objectives, the claimed
objectives are satisfied by the SFRs, the claimed SFRs are satisfied by the
TSS, the claimed SFRs and TSS are satisfied by the various design
abstractions, and the claimed design is substantiated by tests (among other
things). Hence, there are several claim abstractions that are verified and
validated, of which only the TSS is expected (i.e., required) to be
implementation specific.