Are iterations allowed in assurance components (see CC Part 3, section 2.1.4 (paragraph 56))? CC Part 1, section 4.4.1.3 (paragraph 148) specifically permits it.

Iteration is permitted for assurance components, particularly in instances where assurance elements within these components have undergone refinement. The same operations that are applicable to Part 2 functional components are also applicable to Part 3 assurance components. In addition, at the present time none of the Part 3 assurance components contain explicit assignment or selection operations. However, this does not preclude Part 3 assurance components from containing assignment or selection operations in the future.

Specific Changes

The following changes are made to the CC:

·         CC Part 2 section 2.1.4 is deleted.

·        CC Part 3 paragraph 56 is deleted.

·         In CC Part 1, paragraph 148 is replaced with the following text:

CC functional and assurance components may be used exactly as defined in the CC, or they may be tailored through the use of permitted operations in order to meet a security objective. When an element within a component undergoes a refinement, the PP/ST author shall clearly identify that such a refinement has been performed. The PP/ST author must also be careful that the dependency needs of other requirements that depend on this requirement are satisfied. The permitted operations are selected from the following set:

Iteration: allows a component to be used more than once with varying operations;

Assignment: allows the specification of parameters;

Selection: allows the specification of one or more items from a list; and

Refinement: allows the addition of details.

Iteration

Where necessary to cover different aspects of the same requirement (e.g. identification of more than one type of user), repetitive use of the same component to cover each aspect is permitted.

While iteration is referred to at the level of a requirement component, it is not always necessary to repeat the full text of each of the iterations of the component, if doing so would result in some elements within the component being repeated multiple times with no changes. It is permissible in the PP or ST to repeat only those requirement elements that are being changed each time, whether by refinement, or by the completion of assignment or selection operations. (See Refinement for further guidance on iterating refined requirements).

Assignment

Some components have elements that contain parameters that enable the PP/ST author to specify a set of values for incorporation into the PP or ST to meet a security objective. These elements clearly identify each parameter and constraint on values that may be assigned to that parameter.

Any aspect of an element whose acceptable values can be unambiguously described or enumerated can be represented by a parameter. The parameter may be an attribute or rule that narrows the requirement to a specific value or range of values. For instance, based on a security objective, an element within a component may state that a given operation should be performed a number of times. In this case, the assignment would provide the number, or range of numbers, to be used in the parameter.

Selection

This is the operation of picking one or more items from a list in order to narrow the scope of an element within a component.

Refinement

For all components, the PP/ST author is permitted to limit the set of acceptable implementations by specifying additional detail in order to meet a security objective. Refinement of an element within a component consists of adding these technical details.

In order for a change to a component to be considered a valid refinement, the change must satisfy all the following conditions:

o        A TOE meeting the refined requirement would also meet the original requirement, as interpreted in the context of the PP/ST;

o        In cases where a refined requirement is iterated, it is permissible that each iteration address only a subset of the scope of the requirement; however, the sum of the iterations must together meet the entire scope of the original requirement;

o        The refined requirement does not extend the scope of the original requirement; and

o        The refined requirement does not alter the list of dependences of the original requirement.

Some examples of valid refinements are:

1) Any change that is only editorial, such as changes to enhance the readability of a completed assignment or to address grammatical correctness.

2) A change that does not alter the scope of the requirement due to the context in which it is used in the PP/ST. For example, changing a requirement that stated "TOE users" to "TOE telnet users" would be a valid refinement where the only users of the TOE are telnet users.

3) A change that provides information on allowable approaches to implementation without extending the scope of the requirement. An example of a valid refinement is changing a requirement from "provide the capability to verify" to "provide the capability to verify by implementing cryptographic checksums". The change places restrictions on the nature of the mechanism to be used in implementing an existing requirement, and does not extend the scope of the original.

In CC Part 1, paragraph 199 a) and a) 1) are replaced with the following text:

This part of the PP defines the detailed IT security requirements that shall be satisfied by the TOE or its environment. The IT security requirements shall be stated as follows:

a)     Where necessary to cover different aspects of the same requirement (e.g. identification of more than one type of user), repetitive use (i.e. applying the operation of iteration) of the same Part 2 components to cover each aspect is possible. The statement of TOE security requirements shall define the functional and assurance security requirements that the TOE and the supporting evidence for its evaluation need to satisfy in order to meet the security objectives for the TOE. The TOE security requirements shall be stated as follows:

1)     The statement of TOE security functional requirements should define the functional requirements for the TOE as functional components drawn from Part 2 where applicable.

Where AVA_SOF.1 is included in the TOE security assurance requirements (e.g. EAL2 and higher), the statement of TOE security functional requirements shall include a minimum strength level for the TOE security functions realised by a probabilistic or permutational mechanism (e.g. a password or hash function). All such functions shall meet this minimum level. The level shall be one of the following: SOF-basic, SOF-medium, SOF-high. The selection of the level shall be consistent with the identified security objectives for the TOE. Optionally, specific strength of function metrics may be defined for selected functional requirements, in order to meet certain security objectives for the TOE.

As part of the strength of TOE security functions evaluation (AVA_SOF.1), it will be assessed whether the strength claims made for individual TOE security functions and the overall minimum strength level are met by the TOE.

In CC Part 1, paragraph 215 a) and a) 1) are replaced with the following text:

This part of the ST defines the detailed IT security requirements that shall be satisfied by the TOE or its environment. The IT security requirements shall be stated as follows:

a) Where necessary to cover different aspects of the same requirement (e.g. identification of more than one type of user), repetitive use (i.e. applying the operation of iteration) of the same Part 2 components to cover each aspect is possible. The statement of TOE security requirements shall define the functional and assurance security requirements that the TOE and the supporting evidence for its evaluation need to satisfy in order to meet the security objectives for the TOE. The TOE security requirements shall be stated as follows:

1)     The statement of TOE security functional requirements should define the functional requirements for the TOE as functional components drawn from Part 2 where applicable.

Where AVA_SOF.1 is included in the TOE security assurance requirements (e.g. EAL2 and higher), the statement of TOE security functional requirements shall include a minimum strength level for the TOE security functions realised by a probabilistic or permutational mechanism (e.g. a password or hash function). All such functions shall meet this minimum level. The level shall be one of the following: SOF-basic, SOF-medium, SOF-high. The selection of the level shall be consistent with the identified security objectives for the TOE. Optionally, specific strength of function metrics may be defined for selected functional requirements, in order to meet certain security objectives for the TOE.

As part of the strength of TOE security functions evaluation (AVA_SOF.1), it will be assessed whether the strength claims made for individual TOE security functions and the overall minimum strength level are met by the TOE.

The following changes are made to the CEM:

·       The second sentence of paragraph 220 is reworded as follows:

"That is, the PP can contain IT security requirement statements that include uncompleted operations for assignment or selection."

·        Paragraphs 221 and 222 are replaced by the following:

"The permitted operations for CC Part 2 and Part 3 components are assignment, iteration, selection and refinement. The assignment and selection operations are permitted only where specifically indicated in a component. Iteration and refinement are permitted for all components."

·         Paragraphs 410 and 411 are replaced by the following:

The permitted operations for CC Part 2 and Part 3 components are assignment, iteration, selection and refinement. The assignment and selection operations are permitted only where specifically indicated in a component. Iteration and refinement are permitted for all components.

Since there is no difference between the types of operations permitted for functional and assurance components, CC Part 1 is the most appropriate place to address these permitted operations, while avoiding redundancy by covering the same topic in both CC Part 2 and CC Part 3. The CEM is updated to make this clear in the methodology as well.

Paragraph 56 of CC Part 3, as worded, specifically excludes any mention of iteration, assignment and selection as valid operations. However, iteration of assurance components is permitted, and it is possible that future versions of the CC could contain one or more assurance components that contain assignment and/or selection operations.