Updated 12 December 2023

1. In NIAP PPs, cPPs, Functional Packages, and PP-Modules, all “optional” requirements should appear in Appendix A “Optional SFRs.” But some of these SFRs are more optional than others, so it is important to classify your SFRs correctly. This is the case whether or not you are developing in XML.

2. The way we specify product features and implementation-dependent SFRs in XML has changed. If you have implementation-dependent SFRs, you need to make changes to conform with the schema changes (see below). These changes do not apply to SFRs in the Additional SFRs section for a base PP in PP-Modules.

3. Additional changes to the PP-Module schema have been made. These changes allow SFRs in the Additional SFRs section for a base PP to be optional, objective, or implementation-dependent. Previously the XML schema supported only mandatory requirements in the Additional SFRs section.

Appendix A.1 “Strictly Optional Requirements” should contain only SFRs that are truly optional. This means that the claiming of the requirement by the ST Author is completely optional whether or not the TOE implements the capability addressed by the requirement. The conformance of the TOE to the PP or Module is not affected if the requirement is not claimed.

In XML, a component is marked as optional by including the attribute status=”optional” in the f-component element. This is not necessary if the SFR is within the <opt-sfrs> section of a PP-Module.

<f-component cc-id="fia_wht_ext.4" id="fc-fia-wht-ext-4" name="Whatever" status="optional">

If an SFR is both selection-based and optional, its status should be set to sel-based and it should include the dependency <depends><optional/></depends> in addition to the dependencies for the selection.

If an SFR is both implementation-dependent and optional, its status should be set to feat-based and it should include the <optional/> dependency in addition to the dependencies for the feature.

If an SFR is somehow selection-based, implementation-dependent, and optional, then the status should be set to sel-based, and both the <optional/> dependency and a dependency on the feature should be included along with the dependencies on the selection.

It doesn't hurt to add the <optional/> dependency if it is not needed.

Appendix A.2 contains Objective SFRs. Objective SFRs are truly optional SFRs, but there is an intent that they will become mandatory SFRs in the future. In XML, they are indicated in a similar manner as are Optional requirements, or can be within the <obj-sfrs> section of a PP-Module:

   <f-component cc-id="fia_wht_ext.4" id="fc-fia-wht-ext-4" name="Whatever" status="objective">

A requirement cannot be both selection-based and objective.

If an SFR is both objective and implementation-dependent, its status should be set to feat-based and it should include the <objective/> dependency in addition to the dependencies for the feature.

It doesn't hurt to add the <objective/> dependency if it is not needed.

CC:2022 permits a type of “optional” SFR that must be claimed if the TOE implements a specified product feature. NIAP calls these “implementation-dependent SFRs,” or “feature-based SFRs.” Although these requirements are specified in Appendix A with the other optional requirements, they are not actually optional. The ST Author must claim them if the TOE implements the associated technology or feature. These requirements appear in Appendix A.3.

Features must be defined using an <implements> tag in section within the introduction--preferably near the Use Cases section, if there is one.

For example:

<section title="Product Features Mapped to Implementation-dependent Requirements" id="sec-features">
	The feature(s) enumerated below, if implemented by the TOE, require that additional SFRs be claimed in the ST.<htm:br/>
	<implements>
		<feature id="bluetooth" title="Bluetooth">
			<description>Bluetooth is a short-range wireless technology standard that is commonly used for exchanging data between devices over short distances. Most, if not all, mobile devices include Bluetooth hardware.<htm:br/></description>
		</feature>
	</implements>			
</section>

The <implements> element can contain one or more <feature> elements. Requirements that are dependent on a feature are indicated by including the status=”feat-based” attribute in the f-component and a dependency on the feature. Implementation-dependent SFRs may also appear in the <impl-dep-sfrs> section of a PP-Module.

For example:

<f-component cc-id="fdp_upc_ext.1" iteration="BLUETOOTH" name="Inter-TSF User Data Transfer Protection (Bluetooth)" status="feat-based"> 
     <depends on="bluetooth"/>  

In the generated html document the feature section should look like this:

And the requirement should appear in Appendix A.3 looking something like this:

If an SFR is both selection-based and implementation-dependent, its status should be set to sel-based and it should include a dependency on the feature, along with the dependency on the selection.

If an SFR is both implementation-dependent and optional, its status should be set to feat-based and it also should include the <optional/> dependency along with the dependency on the feature.

If an SFR is both implementation-dependent and objective, its status should be set to feat-based and it should include the <objective/> dependency in addition to the dependencies for the feature.

If an SFR is somehow selection-based, implementation-dependent, and optional, then the status should be set to sel-based, and both the <optional/> dependency and a dependency on the feature should be included along with the dependency on the selection.