I-0419: Scope Of Permitted Refinements

TYPE:                 NIAP Interpretation
NUMBER:               I-0419
STATUS:               Withdrawn
REASON:               This is OBE, given the approval of CCIMB-INTERP-0019

TITLE:                Scope Of Permitted Refinements
WOULD SUPERSEDE:
     I-0362           Scope Of Permitted Refinements

SOURCE REFERENCE:     CC v2.1 Part 1 Subclause 4.4.1.3
                      CC v2.1 Part 2 Subclause 2.1.4.4
                      CEM v1.0 Part 2 Subclause 4.4.6 ASE_REQ
RELATED TO:
     I-0362           Scope Of Permitted Refinements
     I-0394           Iteration Must Cover All Scopes

ISSUE:

The definition of refinement used in the CEM is not captured in the CC.

STATEMENT

Refinements always have the characteristic that a TOE meeting the refined requirement would also meet the unrefined requirement.

RECOMMENDED CRITERIA CHANGES

In order to address this interpretation, the following changes should be made to CC V2.1: (Additions marked thusly; deletions marked ~~thusly~~)

In Part 1, Section 4.4.1.3, under "Permitted operations on components", replace item "d)" with the following:
d) refinement, which permits the addition of extra detail when the component is used. Refinements always have the characteristic that a TOE meeting the refined requirement would also meet the unrefined requirement.
In Part 2, Section 2.1.4.4, "Refinement", add to the end of the first paragraph:
Refinement always has the characteristic that a TOE meeting the refined requirement would also meet the unrefined requirement.

FURTHER CONSIDERATIONS:

The CEM v1.0 already incorporates this definition of refinement in ASE_REQ.1-12; however, it should be reviewed to ensure that additional changes are not required.

SUPPORT:

The underlying notion of refinement is that of narrowing. There are two types of narrowing possible:

Narrowing of Implementation. In this form of narrowing, the PP/ST author would restrict the set of acceptable implementations in some way. Such a narrowing would always meet the unrefined requirement, and would never create additional dependencies.
Narrowing of Scope. In this form of narrowing, the PP/ST author limits the application of the requirement to some subset of what is called out or implied by the unrefined requirement. For example, the scope might be narrowed from the entire TOE to a specific SFP or type of system entry. Narrowing of scope results in a TOE where the unrefined requirement is not met in all cases.

This interpretation limits refinement to narrowing of implementation. If narrowing of scope is required, an explicitly stated IT security requirement must be used. Thus, the use of refinement in crafting requirements is extremely limited.

Note that refinement may be used to clarify meaning or grammar, as long as the change still meets the definition of a proper refinement.

Refinement is acceptable both for functional and assurance requirements. Refinement in the case of assurance might be a narrowing of procedure or paradigm; that is, restricting developers or testers to the use of a specific development or testing paradigm of the many potential paradigms acceptable under the requirements.