Implicitly Satisfied Requirements

16 January 2024

Implicitly Satisfied Requirements are presented in an Appendix. The Appendix must be be declared in XML as follows:

       <appendix title="Implicitly Satisfied Requirements" id="apndx-satisfiedreqs">

The name must be "Implicitly Satisfied Requirements." The id must be unique to the document.

This declaration causes boilerplate text to be generated that explains how these these requirements are considered met as long as the product is successfully evaluated against the PP or PP-Module. The text varies slightly between the versions of the CC because the specific reference to the CC differs.

In CC:2022, Implicitly Satisfied Requirements are permitted by Part 1, section 8.3: Dependencies between components.

CC:2022 Part 1:

8.3 Dependencies between components

Dependencies may exist between components. Dependencies arise when a component is not self- sufficient and relies upon the presence of another component to provide security functionality or assurance.

The functional components in CC Part 2 typically have dependencies on other functional components. Some of the assurance components in CC Part 3 also have dependencies, which in turn, may have dependencies on other CC Part 3 components.

CC Part 2 dependencies on CC Part 3 components may also be defined. Extended functional/assurance components may define dependencies similarly. Component dependency descriptions are determined by consulting the component definitions given in CC Part 2, CC Part 3, or the extended components definition. In order to ensure completeness of the TOE security requirements, dependencies should be satisfied when requirements based on components with dependencies are incorporated into PPs, PP-Modules, packages or STs. Dependencies should also be considered when constructing packages, i.e. if component A has a dependency on component B, this means that whenever a PP, PP-Module, package or ST contains a security requirement based on component A, the PP, PP-Module, package or ST shall also contain one of:

a) a security requirement based on component B; or

b) a security requirement based on a component that is hierarchically higher than B; or

c) a justification why the PP, PP-Module, package or ST does not contain a security requirement based on component B.

In cases a) and b), when a security requirement is included because of a dependency, it can be necessary to complete operations (assignment, iteration, refinement, selection) on that security requirement in a particular manner to make sure that it actually satisfies the dependency.

In case c), the justification that a security requirement is not included should address either:

— why the dependency is not necessary or useful; or

— that the dependency has been addressed by the operational environment of the TOE, in which case the justification should describe how the security objectives for the operational environment address this dependency; or

— that the dependency has been addressed by the other SFRs in some other manner (e.g. extended SFRs, combinations of SFRs).

What does this mean?

Generally, when an SFR has a dependency on another SFR, the other SFR must be included in the evaluation. If it is not included, its exclusion must be rationalized as in (c) above. This appendix contains a table of the rationalizations for claiming that dependent requirements are implicitly satisfied, and therefore do not need to be included in the PP.

The most common situation is when an SFR from the CC Catalog has a dependency that has been replaced by an extended component in the PP. For example, in CCv3.1r5, FCS_CKM.1 (Cryptographic key generation) depends on FCS_CKM.4 (Cryptographic key destruction). But most NIAP PPs replaced FCS_CKM.4 with the extended component FCS_CKM_EXT.4. Therefore, PPs that use FCS_CKM.1 must explain why the dependency on FCS_CKM.4 is satisfied by the inclusion of FCS_CKM_EXT.4 in the evaluation.

Implicitly Satisfied Requirements are generally expressed in a table:

There is no shortcut for declaring this table. You have to do it by hand:

   <h:b><ctr ctr-type="Table" pre="Table " id="imp-sat-reqs-table">: Implicitly Satisfied Requirements</ctr></h:b>
   <h:table>	
      <h:tr class="header"><h:td>Requirement</h:td><h:td>Rationale for Satisfaction</h:td></h:tr>
      <h:tr>
         <h:td>FCS_CKM.4 – Cryptographic Key Destruction</h:td>
	 <h:td>
	    FCS_CKM.1 has a dependency on FCS_CKM.4. The extended SFR FCS_CKM_EXT.4 addresses this dependency 
	    by defining an alternate requirement for key destruction.
	 </h:td>
       </h:tr>
       <h:tr>
	  <h:td>FCS_CKM.4 – Cryptographic Key Destruction</h:td>
	  <h:td>
	     FCS_CKM.2 has a dependency on FCS_CKM.4. The extended SFR FCS_CKM_EXT.4 addresses this dependency by 
	     defining an alternate requirement for key destruction.
	  </h:td>
       </h:tr> 
               . 
               .
               .
   </h:table>