Components - commoncriteria/pp-template GitHub Wiki

Updated 30 April 2025

Each SFR is defined within an <f-component> element. Each f-component should have the following structure:

• Component declaration and attributes
• Dependencies (if necessary)
• Consistency Rationale (Modified and Additional SFRs in PP Modules only)
• Extended Component Information (if extended)
• • Component Leveling
• • Management Functions and Audit Events
• • Dependencies
• Description (totally optional, seldom used)
• Elements (one or more)
• • Title (requirements text)
• • Extended Component Definition Title (optional)
• • Application Notes (optional)
• • Evaluation Activities
• • Rules (optional)
• Audit Events (if any)
• Management Functions (in the future)

Each of these constructs is discussed below.

  <f-component name="Cryptographic Operation: Symmetric Key Cryptography"   <!-- Name of the requirement as it should appear in the document -->
               id="sfr-fcs-cop-ext-1-skc"       <!-- Should look something like this, but it just needs to be unique in the document -->
               cc-id="fcs_cop_ext.1"            <!-- This is a lower-case version of the SFR name as it would appear in a document -->
               iteration="SKC"                  <!-- This attribute is required only if the SFR is an iteration --> 
               extended="yes"                   <!-- Optional attribute denoting an extended component. Will eventually become mandatory. -->
               status="sel-based">              <!-- See below -->

The status Attribute is poorly named. It's more a type than a status. In PPs, it identifies whether the SFR is mandatory, optional, objective, feature-based, or selection-based. The legal values are "optional," "objective," "feat-based," "sel-based," and "invisible."

If the status attribute is not included, then the SFR status defaults to "mandatory."

The "invisible" status indicates a sham f-component that should not appear in the PP or SD. There used to be two primary use cases for "invisible:"

• In the past, a PP could impose audit events on an external document such as a Functional Package. This should never have been allowed, and it no longer supported. To support this abomination there needed to be a sham <f-component> in the PP to attach the audit events to. The correct way is to define the audit events in the Functional Package, or to iterate the SFR from the FP in the PP.
• The use case that is still supported is when a PP includes iterations of Extended Components (e.g. FCS_COP_EXT.1/SKG, FCS_COP_EXT.1/Hash). In this case, the ECD section should not include copies of each iteration, but rather a single entry (e.g. for FCS_COP_EXT.1). One technique for doing this is to create an invisible version of the non-iterated component and include all the ECD information in there. And then exclude all ECD information from the iterated versions.

The addition of the extended attribute is intended to eliminate the need for the invisible status, but it is not yet implemented.

In Modules, most Components do not need the status attribute. Their status is determined by the section they are in: <man-sfrs>, <opt-sfrs>, <obj-sfrs>, <impl-dep-sfrs>, or <sel-sfrs>.

Sometimes in Modules you need to use the notnew attribute to suppress multiple occurrences of SFRs from appearing in the ECD Appendix. This attribute is necessary when there are multiple Extended SFRs with the same name in a Module. This can happen if the same SFR is listed in the <additional-sfrs> section of multiple Base PPs. To prevent this disaster, all occurrences of the same Extended SFR except for one should have the notnew="true" attribute. Also, all except for the SFR without the notnew attribute should not include a <ext-comp-def> for the Family. See also, SFR Classes and Families.

If the repeated SFRs are not Extended, then this should not be a problem, but I haven't actually tested this case.

But sometimes SFRs can be both optional and selection-based, for example. And SFRs that are added to a Base PP through a PP-Module could be optional or depend on a selection. Properly classifying SFRs can be thorny and complicated. Hopefully everything you need to know is in one of these articles:

• Classifying SFRs as Mandatory, Selection‐based, etc.
• Optional, Objective, and Implementation‐Dependent SFRs

The first XML element inside the <f-component> is zero or more <depends> elements. The <depends> element used to express the conditions on which selection-based SFRs are to be claimed in the Security Target.

The basic form is:

	<f-component id="sfr-fau-gen-1" cc-id="fau_gen.1" name="Audit Data Generation" status="sel-based">
		<depends on-sel="sel-rot2-audit"/>  

where the SFR FAU_GEN.1 is claimed in the ST only if a selection elsewhere in the document with the id of "sel-rot2-audit" is made by the ST Author. The dependency need not be on a selection--it could be a use case, a platform, or anything else with an id attribute.

For all the details, see Dependencies.

Consistency rationales are required only for SFRs within the Modified SFRs and Additional SFRs sections of a PP-Module.

       <f-component cc-id="fia_x509_ext.3" id="os-fia-x509-ext-3" name="X.509 Certificate Use and Management">
            <consistency-rationale>This SFR defines additional uses for X.509 certificate functionality that
                 do not conflict with those defined in the GPOS PP.</consistency-rationale>

This information is used to auto-fill the "Consistency of Requirements" section in the "Consistency Rationale" section for each base PP.

The consistency rationale shall demonstrate that the unions of SPDs, objectives, and SFRs defined in the PP-Module and in its PP-Module Base do not lead to a contradiction. (CC:2022 Part1, Rev 1, Sec C.2.2.3, p. 139).

See, Consistency Rationale.

If an SFR is an extended component, that is, its name ends in "EXT," its Extended Component Definition (ECD) must appear in the PP. ECDs are generated from information provided throughout the document and auto-generated into Appendix C.

The Extended Component Definition is the way the new requirement that you just made up is fit into the seamless network of requirements that is the Common Criteria. It's the price you pay for straying from the globally recognized path. It's a pretty good reason to use existing requirements if you possibly can.

The following information must be provided for each Extended Component:

Component leveling is a diagram that is auto-generated from the component hierarchy. The <comp-lev> element contains the text that appears beneath the diagram. It must be written as a sentence fragment describing the requirement.

	<comp-lev>specifies how audit data may be transmitted or removed from the TOE, which is not 
		covered by any FCS_STG component.</comp-lev>

ECDs must include management functions and auditable events that a PP Author might consider requiring for an SFR. Since this PP is defining a Component that is not in the CC Catalog, this is guidance for future PP Authors who might want to pick the Component out of this PP and use it somewhere else. That's the theory anyway.

	<management>The following actions could be considered for the management functions in FMT:
		<h:ol type="a">
			<h:li>Ability to configure and manage the audit system and audit data,
				including the ability to configure name/address of audit/logging server
				to which to send audit/logging records.</h:li>
		</h:ol>
	</management>
	<audit>The following actions should be auditable if FAU_GEN Security audit data generation 
		is included in the PP/ST:
		<h:ol type="a">
			<h:li>On failure of logging function, capture record of failure and record upon restart of logging function.</h:li>
		</h:ol>
	</audit>

Also for the theoretical global catalog of requirements, this entry lists the other Components on which our Extended Component depends.

	<dependencies><h:br/>
		FAU_GEN.1 Audit Data Generation
        </dependencies>

This is a totally optional element that you can use to display some text after the declaration of an SFR and before the first element. It is very seldom used.

    <description>
       This is something that I want to say up front about this requirement, but I don't have to. Most people use App Notes for this.
    </description>

Every SFR consists of at least one element. This means that every <f-component> XML element contains at least one <f-element> element. Yes, the overloaded use of the term "element" is confusing. Elements are both XML constructs and CC constructs. The CC element construct is represented in NIAP XML by the <f-element> element.

Elements have the following structure in NIAP XML:

• Title (requirements text)
• Extended Component Definition Title (optional)
• Application Notes (optional)
• Evaluation Activities
• Rules (optional)

For the details on Elements, see Elements.

Evaluation activities for SFRs are defined at the Element level. See Evaluation Activities.

Audit events are defined after the last element. They look something like this:

	<audit-event>
		<audit-event-descr>Failure to establish a HTTPS Session.</audit-event-descr>
                <audit-event-info>Reason for failure.</audit-event-info>
                <audit-event-info>Non-TOE endpoint of connection (IP address) for failures.</audit-event-info>
	</audit-event>

For all the details on audit events, see Audit Events

Someday Management Functions will be attached to SFRs the same way that Audit Events are. But that day is not today.

For the current handling of Management Functions, see Management Functions.