Elements - commoncriteria/pp-template GitHub Wiki

Updated 11 January 2024

Common Criteria Components contain one or more Elements. Each Component is a requirement and each Element is a part of that requirement. Component names look like FCS_COP.1, Element names look like FCS_COP.1.1.

The basic structure of an <f-element> is something like this:

        <f-element id="fau-stg-ext-1e1">
            <title>The TSF shall be able to transfer generated audit data to an external IT entity using 
		<selectables linebreak="yes">
			<selectable id="sel-fau-itc">a trusted channel as specified in FTP_ITC_EXT.1</selectable>
			<selectable>removable media requiring physical access to the platform</selectable>
		</selectables>.
           </title>
	   <ext-comp-def-title>
		    <title>The TSF shall be able to transfer generated audit data to an external IT entity using 
			    <assignable>mechanism for moving audit data</assignable>. 
		    </title>
           </ext-comp-def-title>				    
  	   <note role="application">
		Instructions for the ST Author on how to fill in the selections and assignments.
	   </note>
           <aactivity level="element">
                 <TSS>What the evaluator has to do with the TSS.</TSS>
                 <Guidance>What the evaluator has to do with the TOE Guidance document.</Guidance>
		 <KMD>What the evaluator has to do with the Key Management Document, or whatever.</KMD>
                 <Tests>The tests that the evaluator has to run to verify that the requirement is met.</Tests>
           </aactivity>
       </f-element>

Each of these sections is discussed in greater detail below.

Every <f-element> must have an id attribute that is unique to the document. I like to use a form of the Element name because that way it's easier to find the problem when somebody finds an error in the HTML document.

The <title> tag contains the actual text of the requirement. The schema allows almost anything to be in the title, but generally it consists of English words and Selections and Assignments.

A Management Functions Table is a special case of Title contents. See, Management Functions.

For details on Assignments and Selections, see Assignments and Selections.

This tag is used only for Elements that are part of an Extended Component and that have a Title that contains a Selection or Assignment with an id attribute. In this case, the <ext-comp-def-title> tag should be populated with a version of the Title with all Selections replaced by Assignments, and with all id attributes removed from Selections and Assignments. This version of the Title is used when the Title is copied into the ECD Appendix. This prevents the Title from being mis-rendered in the ECD Appendix.

If the Component is not Extended, or does not contain a a Selection or an Assignment with an id, then the <ext-comp-def-title> tag can be omitted.

Application notes are indicated with the <note role="application"> tag. App Notes contain guidance for ST Authorson filling out the Selections and Assignments. Additionally,

• If the SFR is Selection-based, the App Note should document the selections that cause the Component to be claimed,
• If the SFR is Implementation-based, the App Note should document the product feature that the Component depends on,
• If any selections in the Element cause other SFRs to be claimed in the ST, then these should be documented.

Evaluation Activities, formerly known as Assurance Activities, are defined in the XML at the Element level rather than the Component level.

In most SFRs, the EAs are specified in the last Element and they apply to the entire Component. For this case, you can use the <aactivity> tag without any attributes.

If an EA has to be applied to a particular Element, then use the level attribute <aactivity level="element">. This is fairly rare, but it does come up (e.g. the massive IPSec SFR).

If a Component has both element- and component-level EAs, the Component level EA should be specified with <aactivity level="component">. This is especially necessary if the last Element has specific element-level EAs and the Component also has component-level EAs.

For more on Evaluation Activities, see Evaluation Activities.

Rules are a new non-official construct used by the automation framework to help automate the validation of the CC Document by, for example, ensuring the consistency of selections across the document. They are completely optional.

In the published document, rules generally appear as part of the App Notes and in an Appendix.

For the details on Rules, see Validation Rules.