|
|
||||
PD-0087: STs Adding Requirements to Protection Profiles |
||||
|
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.
IssueCan an ST be compliant with a PP if it includes details not called for in a PP? ResolutionAn ST is compliant with a PP if it satisfies all of the security functional requirements and assurance requirements specified in the PP. In general, adding requirements to those contained in the PP has no effect on compliance. The ST writer may include more detail and additional capabilities. However, in order to remain compliant with the PP, the additional requirements must not have the effect of altering the objectives of the PP. SupportThe PP is considered to be a specification that identifies minimum requirements. Thus, valid responses to the PP must, at a minimum, provide the capabilities and behavior specified in the PP (and, of course, comply with the assurance requirements). In short, the set of SFRs that are called out in the PP must be satisfied by the ST (and the resulting TOE), and including capability and features that exceed the PP requirements does not, per se, invalidate the satisfaction of the PP SFRs. Unless there is an explicit statement to the contrary, the selection of "[none]" in the components of both instantiations of FDP_IFF is to be read to mean "none required" rather than as, "no others may be provided." An ST may stipulate capabilities and features that exceed the PP requirements; doing so does not render the ST non-compliant with the PP. However, for the ST author (and, eventually, TOE developer) there will be the burden of demonstrating that features and capabilities that are provided in addition to what is required in the PP neither introduce security vulnerabilities nor circumvent or interfere with required security functions. Note: This issue is also being addressed as part of the ASE revision. Modification History:
References:
Related NIs:
Related CCIMB-INTERPs:
Source OD: 0121 |