-
Notifications
You must be signed in to change notification settings - Fork 2
Conformance Claims Section
7 December 2023
The Conformance Claims section is used to express the linkages between the Protection Profile and the Common Criteria. Eventually this section should be automatically generated from XML data structures (for example, the <included-packages> and <modules> elements). But for the time being, the simplest thing is to write this as free text within the Conformance Claims section, or as a series of <cclaim> elements containing <description> elements with free HTML text.
The Conformance Claims section should defined using the <section> element:
<section title="Conformance Claims" id="sec-unique-id" boilerplate="no">The Conformance Claims section should include five sub-sections: CC Conformance Claims, PP Claims, Package Claims, Conformance Claim Rationale, and Conformance Statement.
According to CC:2022 (Part 1, Section 11), the Conformance Claims section:
a) shall state the edition of the relevant parts of the CC to which the PP claims conformance;
b) shall describe the conformance to CC Part 2 as either:
— “CC Part 2 conformant”;
A PP is CC Part 2 conformant if all SFRs in that PP are based only upon functional
components in CC Part 2; or
— “CC Part 2 extended”.
A PP is CC Part 2 extended if at least one SFR in that PP is not based upon functional
components in CC Part 2;
c) shall describe the conformance to CC Part 3 as either;
— “CC Part 3 conformant”;
A PP is CC Part 3 conformant if all SARs in that PP are based only upon assurance
components in CC Part 3; or
— “CC Part 3 extended”.
A PP is CC Part 3 extended if at least one SAR in that PP is not based upon assurance
components in CC Part 3;
Since NIAP PPs almost always include extended SFRs and SARs, this could be represented in XML as follows:
<cclaim name="CC Conformance Claims">
<description>This PP is conformant to CC Part 2 extended and CC Part 3 extended of Common
Criteria Version CC:2022 Release 1.</description>
</cclaim>To comply more exactly with CC:2022, this statement should refer to the ISO standards rather than the CC Documents. So maybe something like this:
<cclaim name="CC Conformance Claims">
<description>This PP is conformant to CC Part 2 (ISO/IEC 15408-2) extended and CC Part 3 (ISO/IEC 15408-3) extended of Common
Criteria Version CC:2022 Release 1 (ISO/IEC 15408:2022 and ISO/IEC 18045:2022).</description>
</cclaim> d) may also include a conformance claim with respect to other PPs:
— “PP Conformant”;
A PP is “PP Conformant" when it meets other specific PP(s).
A PP may be specified in a PP-Configuration with other PPs to which it is "PP Conformant." This is not something happens very often in NIAP PPs. But someday the MDF PP and DSC cPP will need to be conformant with each other. For now, this will do:
<cclaim name="PP Claims">
<description>This PP does not claim conformance to any Protection Profile.</description>
</cclaim> e) may include a package conformance claim;
More than one package may be claimed in a PP.
If a package claim is made, it shall consist of one of the following statements for each package
claim:
— “Package Conformant”;
A PP is conformant to a package if:
— for functional packages, all constituent parts (SPD, security objectives, and SFRs) of
the functional package are present in the corresponding parts of the PP without
modification;
— for assurance packages, the SARs of that PP are identical to the SARs in the
assurance package;
— a PP that restricts some selections of SFRs in a package may still claim it is package
conformant.
— “Package Augmented”;
A PP claims an augmentation of a package if:
— for functional packages, all constituent parts (SPD, security objectives, and SFRs) of
that PP contain all constituent parts given in the functional package but shall have
at least one additional SFR or one SFR that is hierarchically higher than an SFR in
the functional package;
— for assurance packages, the SARs of that PP contain all SARs in the assurance
package, but have at least one additional SAR or one SAR that is hierarchically
higher than an SAR in the assurance package.
— “Package Tailored”.
A PP claims tailoring of a package if:
— for functional packages, all constituent parts (SPD, Security Objectives, and SFRs) of
that PP contain all constituent parts given in the functional package, but shall have
additional selection items for an SFR with existing selections in the package, and
optionally, at least one additional SFR and/or one SFR that is hierarchically higher
than an SFR in the functional package;
— assurance packages and STs shall not claim (or perform) tailoring.
More than one package may be claimed in a PP.
Where PPs claim strict or demonstrable conformance to PP(s) they shall not also claim
conformance to the packages claimed in the PPs they claim conformance to, unless the PP
augments the package. The PP claims <package>-augmented only in the case where the PP
augments the packages beyond that claimed by the PP to which it claims conformance to.
Typically, the package claims are presented in NIAP PPs something like this:
<cclaim name="Package Claims">
<description>
<htm:ul>
<htm:li>This PP is Package Conformant with the Functional Package for TLS, Version 1.1.</htm:li>
<htm:li>This PP is Package Conformant with the Functional Package for SSH, Version 1.0.</htm:li>
</htm:ul>
</description>
</cclaim>Someone who really understands the CC language will have to determine whether "Augmented" or "Tailored" should be used in a particular case.
f) PPs shall contain a conformance claim rationale;
The conformance claim rationale describes the reasons and the logical basis for the authors
choice of conformance claims and statement.
This is new in CC:2022, so there is no example for this claim. This should be boilerplate text.
<cclaim name="Conformance Claim Rationale">
<description>
Blah blah blah.
</description>
</cclaim> g) PPs shall provide a conformance statement.
The conformance statement shall describe the manner in which other PPs or STs shall
conform to this PP: The conformance statement shall be one of:
— “Exact conformance”;
If the PP states that exact conformance is required, a ST shall conform to the PP in an
exact manner, i.e. a conformant ST shall contain SPD and objectives identical to the PP’s,
and the same set of PP’s SFRs with all the assignments and selections resolved;
— “Strict conformance”;
If the PP states that strict conformance is required, a PP/ST shall conform to the PP in a
strict manner, i.e. a conformant PP/ST shall contain a superset of PP’s SPD, objectives
and SFRs, where the new assumptions (if any) do not weaken the PP’s SPD, and all the
PP’s SFRs have their assignments and selections unchanged or where appropriate,
resolved;
Strict conformance allows the conformant PP/ST not to add any element to the PP’s SPD,
set of objectives and SFRs, i.e. the superset defined in the PP/ST may be identical to the
PP’s, with all the SFRs resolved;
— “Demonstrable conformance”.
If the PP states that demonstrable conformance is required, the PP/ST shall conform to
the PP in a strict or demonstrable manner, i.e. a conformant PP/ST shall contain a SPD,
set of objectives and set of SFRs that are equivalent to a superset of PP’s SPD, objectives
and SFRs, where the new assumptions (if any) do not weaken the PP’s SPD, and where
the set of the conformant PP/ST SFRs imply the PP’s SFRs.
Demonstrable conformance allows the conformant PP/ST to use different but equivalent
statements, and it allows as well to simply define a superset as in the strict conformance
case, without changing the statements given in the PP.
Section 10.8.2 of CC:2022 Part 1 Release 1 requires that the conformance statement for exact conformance PPs (all of NIAP's PPs are exact conformance) include a list of PPs and Modules that are allowed in a PP-Configuration with the PP. Typically this is lumped in with the Conformance Claim, as follows:
<cclaim name="Conformance Statement">
<description> An ST must claim exact conformance to this PP.<htm:p/>
The following PP-Modules are allowed to be specified in a PP-Configuration with this PP.
<htm:ul>
<htm:li>PP-Module for VPN Client, Version 2.2</htm:li>
<htm:li>PP-Module for Bluetooth, Version 1.0</htm:li>
<htm:li>PP-Module for MDM Agent, Version 1.0</htm:li>
</htm:ul>
</description>
</cclaim> The conformance statement may also include a reference to any evaluation methods/
activities that have been derived from the CEM. If evaluation methods/ evaluation activities
that have been derived from the CEM are to be used to evaluate the PP then these shall be
identified with the relevant security requirement section by including a statement in the
following form:
“This PP requires the use of evaluation methods/ evaluation activities defined in <reference(s)>.”
In this statement, <reference> is replaced by the identification of the location of the relevant
evaluation methods and evaluation activities. This reference may be to the document
containing the PP or to one or more separate documents.
Evaluation methods is a new construct in CC:2022 that allows EAs to be collected and published as separate documents that can be included by reference into PPs. It is not clear whether any of these even exist. In the unlikely event that any of these are used by a NIAP PP, a reference to any Evaluation Methods would have to be included in the Conformance Statement.