According to Section 2.1.2.3 in Part 2, "A component is hierarchical to another if it offers more security." The problem is that FPT_SEP.2, depending on the instantiation, does not necessarily provide less security than FPT_SEP.3. It could be instantiated to provide the same security as FPT_SEP.3. Hence, FPT_SEP.3 cannot be hierarchical to FPT_SEP.2.

The following interprets the entire FPT_SEP family: FPT_SEP.2 and FPT_SEP.3 permit some or all access control and information flow SFPs to be in a distinct domain and are not hierarchical.

To address this interpretation, the following changes should be made to FPT_SEP FPT_SEP.2.3 should be changed to: " ... in a security domains for ..." FPT_SEP.3.3 should be changed to: "... in security domains for their own..." A new component, FPT_SEP.4, should be created that is the same as FPT_SEP.3, except that element FPT_SEP.4.3 should be changed to: " ... each in a security domain for its ..." The hierarchy should be modified so that both FPT_SEP.2 and FPT_SEP.3 are hierarchical to FPT_SEP.1, and the new component FPT_SEP.4 is hierarchical to both FPT_SEP.2 and FPT_SEP.3.

To correct the problem, adjustment is made to the hierarchy to make FPT_SEP.3 hierarchical to FPT_SEP.1, not FPT_SEP.2. To make clear that placing each access control and information flow SFP into a separate domain provides more security than having two or more SFPs in a single domain, an additional component is added that is hierarchical to both FPT_SEP.2 and FPT_SEP.3 that has each SFP in its own domain. This change further corrects the inconsistency between CC Part 2 and the CC Part 2 Annex in making clear that FPT_SEP.2 and FPT_SEP.3 may have more than a single domain for the SFPs. Note that both components (FPT_SEP.2 and FPT_SEP.3) allow for distinct domains per SFP, and that both components are silent with respect to non-data protection SFPs. 00/08 Message: Group that submitted RI rethinks their questions.It is now suspended and status changed to “awaiting input”.