SFR Classes and Families

Updated 18 December 2023

Security Functional Requirements section of a PP contains a sub-section for each SFR Class. For example:

   <section title="Class: Cryptologic Support (FCS)" id="sec-fcs">

The general format for an SFR Class section is:

• Introductory text (optional)
• Class description and Class ECD info (if the class is not in the CC)
• ECD data for each extended component family in the Class
• All the SFRs in the Class, in alphabetical order by CC name

Extended Classes

SFR Classes, SFR Families, and SFRs that are not defined in CC Part 2 must be Defined as Extended Components. In NIAP PPs, Extended Component Definitions (ECDs) are auto-generated into Appendix C. The information that is used to generate the ECDs is provided in the SFR Class sections and in the individual SFRs.

New classes are rare, but they do happen. If a class is new the SFR Class section must include a description of the class and and some ECD information. This is done using the <class-description> and <ext-comp-class> XML elements. The contents of the <class-description> element appear in the ECD Appendix. The purpose of the <description> element within the <ext-comp-class> element is not clear.

      <section title="Class: Firewall (FFW)" id="sec-ffw">
        It's probably a good idea to include some text here to describe the new Class. This text should appear at the start of the Class section.
        <class-description>Firewall functionality involves selective processing of network traffic such that the traffic 
          is routed or discarded based on some notion of whether the traffic is valid. 
          Requirements in this class define capabilities for these processing functions.
        </class-description>        
        <ext-comp-class class="Firewall (FFW)">
          <description/>
        </ext-comp-class>

Families in XML

There is no need to create XML sections for Families. This is done automatically. Each Class section is populated with Components. Extended Components, however, require some additional XML.

Extended Components and Families

In NIAP PPs, Extended Components are indicated by the suffix "_EXT" on the Family Name. Defining Extended Components in an existing Family requires that the Family description be modified to explain how the Family changes. In our XML the Family is redefined within the Class section. Sometimes they are defined just above the new Components in the Family, but it is simpler if they are all defined at the top of the Class section. Extended Families are defined using the <ext-comp-def> XML element. For example:

	<section id="fcs" title="Class: Cryptographic Support (FCS)">
		
	        <ext-comp-def title="Cryptographic Key Management" fam-id="FCS_CKM_EXT">
			<fam-behavior>This family defines requirements for management of cryptographic keys.
				FCS_CKM_EXT.4 is necessary because FCS_CKM.4 does not include a requirement for the timing of 
				key destruction.
				FCS_CKM_EXT.5 is necessary to express requirements for key derivation, which are missing from Part 2. 
				</fam-behavior>
		</ext-comp-def>

		<ext-comp-def title="Entropy for Virtual Machines" fam-id="FCS_ENT_EXT">
			<fam-behavior>This family defines requirements for availability of entropy data
				generated or collected by the TSF.</fam-behavior>
		</ext-comp-def>

	 	<ext-comp-def title="HTTPS Protocol" fam-id="FCS_HTTPS_EXT">
			<fam-behavior>This family defines requirements for protecting HTTP communications between the TOE and
				an external IT entity.
			</fam-behavior>
		</ext-comp-def>

		<ext-comp-def title="IPsec Protocol" fam-id="FCS_IPSEC_EXT">
			<fam-behavior>This family defines requirements for protecting communications using IPsec.</fam-behavior>
		</ext-comp-def>

	   	<ext-comp-def title="Cryptographic Operation (Random Bit Generation)" fam-id="FCS_RBG_EXT">
			<fam-behavior>This family defines requirements for random bit/number generation.</fam-behavior>
		</ext-comp-def>

	   	<ext-comp-def title="Cryptographic Salt Generation" fam-id="FCS_SLT_EXT">
			<fam-behavior>This family defines requirements for cryptographic salt generation.</fam-behavior>
		</ext-comp-def>

	   	<ext-comp-def title="Cryptographic Key Storage" fam-id="FCS_STG_EXT">
			<fam-behavior>This family defines requirements for ensuring the protection of keys and secrets.</fam-behavior>
		</ext-comp-def>

Naturally, if there are no extended SFRs within a Class, then there is no need to include any <ext-comp-def> elements.

The <ext-comp-def> elements (if any) are followed by one or more SFRs, organized alphabetically by Family, and by number or iteration within a Family.

There is a special case in Modules where an <ext-comp-def> tag should not be used. This is when there are multiple versions of the same SFR in a Module listed under the Additional SFRs section under multiple Base PPs. Only one of them should have an <ext-comp-def> element, and all the other <f-component> elements should have their notnew attribute set to true. See also, Components.

New Families

New Families are represented in the XML in the same way as Extended Families, except that the new Family necessarily causes a change to the Class definition, so an <ext-comp-class> element should be included in the Class along with the <ext-comp-def> and <family-behavior> elements.

Just to be clear:

• FCS is a Class
• FCS_CKM is a Family
• FCS_CKM.1 is a Component
• FCS_CKM_EXT.1 is an Extended Component in the family FCS_CKM

For more on SFRs, see Security Functional Requirements.