PD-0037: Ambiguities Resulting From Choosing More Than One Selection In An Assignment

This decision represents a long-term technical decision based on an OD, and may not be the same as the final results of the source OD. With respect to published criteria documentation and scheme documents, it provides suggested guidance on evaluation direction, but is not authoritative. Authoritative decisions are provided through the published criteria documents and published scheme and international interpretations thereof. With respect to published PPs, PDs are authoritative corrections to the PP, based on input from the PP author (if available), that are in force until the publication of the next revision of that PP.

Issue

Choosing more than one selection in a functional requirement without considering the consequences of the assignment(s) on each selection may lead to ambiguous requirements that when interpreted do not express the intent of the PP/ST author.

Resolution

A PP/ST author should iterate the requirement if the assignments do not apply for all the selections made. If the assignments for the selections made are ambiguous the PP/ST author should use an application note to clarify their intent.

Support

The CC allows the PP/ST author to make multiple selections in an SFR, as well as assignments. In some cases, this may be done unambiguously within one instantiation of an SFR. However there are instances where one instantiation of an SFR leads to confusion.

For example, the SFR FAU_SAR.3.1 allows the PP author to make the selections [searches, sorting, ordering] and then allows the PP author to assign the criteria upon which these selections perform. If the PP author choses the selections "searches and sorting", and then assigns the criteria with logical relations to be "userid, presumed subject address, ranges of dates, ranges of time, and ranges of IP addresses" it is not clear what a TOE is required to do with respect to sorting. It is not clear what type of sorting operation is to be performed on the audit data. In this instance, the requirement may be interpreted to mean something other than the PP author intended. For example:

FAU_SAR.3 Selectable audit review (1)

FAU_SAR.3.1 The TSF shall provide the ability to perform searches of audit data based on:

1. [userid;
2. presumed subject address;
3. ranges of dates;
4. ranges of time;
5. ranges of IP addresses.]

FAU_SAR.3 Selectable audit review (2)

FAU_SAR.3.1 The TSF shall provide the ability to perform sorting of audit data based on:

1. [the chronological order of audit event occurance.]

If the PP author intended for the TOE to have the capability to sort audit events according to a userid, a TOE that was evaluated using the above interpreted requirement would have conformed to the PP without satisfying the intent of the PP author.

Modification History:

2004-08-12

Updated effective date to reflect the date the PD was issued. (August 2004 NIB 6.c.xiv)

References:

• ALFWPPv1.d

Related NIs:

• I-0388: What Is The Difference Between "Sort" And "Order"?

Related CCIMB-INTERPs:

• None

Source OD: 0147