Validation Rules - commoncriteria/pp-template GitHub Wiki

11 January 2024

Validation Rules are a new construct designed to help automate the validation of a Security Target. Rules allows a PP Author to specify that selections dependent on each other. For example, if a protocol is selected that requires AES-CBC-256, then a Rule can be written to ensure that AES-CBC-256 is selected in FCS_COP.1.

There are two ways that Rules can be used. They can be written into a PP and enforced as a ST is developed in an ST Authoring Tool. They can also be maintained as a separate file and applied by a validator after the ST is complete. Here we are concerned only with Rules that are written into PPs.

In a PP, Rules are attached to Elements. But since they are not a part of the Common Criteria, in published PPs Rules appear in Application Notes. They may also appear in an automatically generated appendix.

Rules appear in the Application Notes of all SFRs that are referenced by the Rule. Generally, the PP Author attaches the Rule to an Element that includes a Selection that is refenced in the Rule. If the Rule also references a selection in another SFR, then in the published document, the Rule appears in the App Note for both SFRs.

In Application Notes, Rules appear as a list under each SFR that is referenced by the Rule. Under a heading of "Validation Guidelines." The below example shows a set of Rules in the Keyed Hash SFR that ensures that the corresponding selections are made in the Hash SFR.

If the PP includes a Validation Guidelines Appendix, the Rules are automatically presented there as well in slightly more detail:

To include a Validation Rules Appendix, a PP Author simply needs to include the following XML between the other Appendixes.

   <appendix id="appdx-rules" title="Validation Guidelines"/>

Rules should appear at the end of an <f-element> element, just after the <aactivity> element, though they can probably appear just about anywhere in a PP.

A simple rule:

	<rule id="keyedhash-alg-match-sha-256">
	  <description>If "<h:i><xref to="sel-hmac-sha-256"/></h:i>" is selected in FCS_COP.1/KeyedHash then "<h:i><xref to="sel-hash-sha-256"/></h:i>" 
				must be selected in FCS_COP.1/Hash.</description>
	  <if><ref-id>sel-hmac-sha-256</ref-id></if><then><ref-id>sel-hash-sha-256</ref-id></then>
        </rule>

The contents of the<description> element are displayed in both the App Note and the Appendix.

Rules are of the form <if> this is true </if><then> this must also be true</then>. So for the above Rule, if the ST Author makes the selection with id="sel-hmac-sha-256" then the ST Author must also make the selection with id="sel-hash-sha-256." In other words, if the TOE supports HMAC-SHA-256, then it must also support SHA-256.

The following Rule is more complicated. If the TOE supports IPSec, then it must also support AES-CBC and AES-GCM with key sizes of both 128 and 256 bits. Notice that the <and>...</and> construct is used to specify that all of the other selections must be made.

	<rule id="rule-ipsec-included-ude">
	   <description>If the TOE implements IPSec then "<h:i><xref to="sel-ude-aes-cbc"/></h:i>," "<h:i><xref to="sel-ude-aes-gcm"/></h:i>,"
		"<h:i><xref to="sel-ude-keysize-128"/></h:i>," and "<h:i><xref to="sel-ude-keysize-256"/></h:i>" must be selected in FCS_COP.1/UDE.
	   </description>
	   <if><ref-id>sel-itc-ipsec</ref-id></if>
		<then><and><ref-id>sel-ude-aes-cbc</ref-id>
                           <ref-id>sel-ude-aes-gcm</ref-id>
	  		   <ref-id>sel-ude-keysize-128</ref-id>
			   <ref-id>sel-ude-keysize-256</ref-id></and>
		</then>							
	</rule>

There is also an <or>...</or> construct to allow OR conditions in either the <if> or <then> condition. <and> and <or> elements can be nested to specify more complicated rules. Likewise, there is a <not> element to specify that a selection must not be made. It can get pretty complicated.

	<rule id="rule-mf-dir-based">
  	   <description>If <h:i>"directory-based"</h:i> is selected anywhere in FIA_UAU.5.1 then 
		"<h:i>Ability to configure name/address of directory server to bind with</h:i>" must be selected in the Client or Server module 
		management function table.</description>
	   <if><or><ref-id>sel-uau-x509-dirbased</ref-id><ref-id>sel-uau-ssh-dirbased</ref-id><ref-id>sel-uau-pwd-dirbased</ref-id></or></if>
	   <then><ref-id>sel-mf-dir-server</ref-id></then>
        </rule>

The above example specifies that if the "dirbased" selection is made in any of three places, then this one other selection must be claimed.

The final example shows an example of references to selections in other documents. In this case, if the condition is true, the Rule specifies that one of the two selections in the <then> element must be made. One is in the Client Virtualization PP-Module and the other is in the Server Virtualization PP-Module.

	<rule id="rule-admin-action-cert-validity">
	   <description>If "<h:i><xref to="sel-x509-adminset"/></h:i>" is selected then 
		"<h:i>Ability to configure action taken if unable to determine the validity of a certificate</h:i>" in the Client or Server module 
		management function table must also be selected.</description>
	   <if><ref-id>sel-x509-adminset</ref-id></if>
	   <then><or>
		<doc ref="client-virt"><ref-id>sel-mf-cert-no-validity-action</ref-id></doc>
		<doc ref="server-virt"><ref-id>sel-mf-cert-no-validity-action</ref-id></doc></or></then>
        </rule>

The sharp-eyed will have noticed that these PP-Modules should not have been referenced from the Base PP. This is true. A Base PP should never reference PP-Modules outside of the Conformance Claims section. This Rule should have been defined in both of the PP-Modules to reference a selection in the Base PP and not the other way around. If they were Packages, the referencing them from the PP would have been fine.