Modified SFR Reform - commoncriteria/pp-template GitHub Wiki
Edited 29 Jan 2025
Starting in about mid-2025, this will become the only way to specify modified SFRs in a PP Module. Until then, both the old-style and new-style schemas will be supported.
To support automation. Currently modified SFRs are expressed as text. Unless the entire modified SFR is specified, there is no way to automate the modifications in an ST-Generation tool.
The solution is to separate the display of the description of the modification in the PP-Module from the specification of the modification. Modifications are specified using XPath expressions.
The <modified-sfrs> tag contains zero or more <section> tags. Each section tag is the header for the CC class of the modified SFRs that follow inside <base-sfr-spec> tags.
There is a <base-sfr-spec> tag for each base PP SFR within the class that is modified by the PP Module.
The <base-sfr-spec> tag itself must uniquely identify the SFR within the base PP. It has the following attributes:
- cc-id: The cc-id of the target SFR within the base PP
- iteration (optional): The iteration of the target SFR, if any.
- title: Title of the target SFR. This is what appears in the modified SFRs section of the PP Module.
-
id: An id for this
<base-sfr-spec>tag.
Each <base-sfr-spec> tag includes an optional package specification, a consistency rationale, a description of the way the PP Module changes the SFR, and a set of instructions that precisely codifies the changes.
The package specification allows the PP Module to modify Functional Packages that are used by the base PP. The Package is specified using the <from-pkg>. For example:
<base-sfr-spec cc-id="fcs_ckm.2" title="Cryptographic Key Establishment" id="modsfr-os-tlspkg-fcs-ckm-2">
<from-pkg name="Functional Package for TLS"
short="TLS"
version="2.0">
<git>
<url>https://github.com/commoncriteria/tls</url>
<branch>release-2.0</branch>
</git>
</from-pkg>
specifies that the version of FCS_CKM.2 that is being modified is the one imported into the base PP from the TLS Package. The name, short, and version attributes are all required, as is the <git> tag that refers to the github repo for the Package. Modifications to SFRs in Packages that are not in NIAP github cannot be automated.
A consistency rationale is required for all modified SFRs. Even if the change is only to status of the SFR.
The <description> element can contain anything, but it must be HTML or text, not XML. The contents of the <description> is what will appear in the text of the PP Module under the header for the modified SFR.
The second part of the <base-sfr-spec> represents instructions specifying how the PP Module modifies the base PP SFR. The contents of this part does not appear in the text of the PP Module and is used only by downstream tools, such as Security Target generators.
There are six operations that may be specified as tags. There may be as many of these as are necessary. Three of the operations identify all or part of the base SFR using XPath expressions and supply new XML code that represents the modification.
-
<replace>: Replace the specified XML with new XML. -
<insert-before>: Insert new XML before the specified XML. -
<insert-after>: Insert new XML after the specified XML.
One operation does not require new XML.
-
<delete>: Delete the XML at the specified location.
Two operations do not require an XPath expression. This one changes the status attribute of the target SFR.
<set-status status="new value"/>
Of course, if you modify the status of an SFR and the old status included a dependency that no longer applies, you need to remove the dependency using the <delete> tag. Likewise, if the change in status requires a dependency, the dependency should be added using the <insert-before>. <insert-after>, or <replace> construct.
The final tag does nothing. Any text in the <description> tag is displayed, but no modification to the base PP is specified.
<no-change/>
Each of the above operations except set-status contains a single child tag that specifies the XPath and the replacement XML.
<replace>
<xpath-specified xpath="path to the target XML">
The XML content that replaces the XML element referenced by the xpath.
</xpath-specified>
</replace>
An Xpath expression should look something like this:
<xpath-specified xpath="*//cc:f-element[@id='fel-asym-gen']//cc:title">
The above Xpath expression refers to the <title> tag of the <f-element> with the id attribute "fel-asym-gen". It is implicit that this path refers to an element in the base PP.
The XML that follows should include the <title> tag if that is the tag whose contents are to be replaced.
<modified-sfrs>
<zeroOrMore classes that have modified SFRs>
<section header for the class including title and id>
<oneOrMore SFRs in the above class that are modified>
<base-sfr-spec cc-id="cc-id for the target SFR" [iteration="if any"] title="Title of the target SFR" id="id for this modification">
<optional> <!-- If SFR is in a package imported by the base PP -->
<from-pkg name="Package long name" short="Package short name" version="Package version">
<git><url>URL of git repo for package</url>
<branch>branch of package</branch>
</git>
</from-pkg>
</optional>
<consistency-rationale>Words....</consistency-rationale>
<description>
Text and html description of the modification.
</description>
<oneOrMore of the following <replace>, <delete>, <insert-before>, <insert-after>, <set-status>, or <no-change> elements>
<replace>
<xpath-specified xpath="path to the target XML">
The XML content that replaces the XML element referenced by the xpath.
</xpath-specified>
</replace>
<delete>
<xpath-specified xpath="path to the target XML"/>
Note: This could also be accomplished using <replace>.
</delete>
<insert-before>
<xpath-specified xpath="path to the target XML">
The XML content that is inserted before the element referenced by the xpath.
</xpath-specified>
</insert-before>
<insert-after>
<xpath-specified xpath="path to the target XML">
The XML content that is inserted after the element referenced by the xpath.
</xpath-specified>
</insert-after>
<set-status status="new status"/>
<no-change/>
</oneOrMore>
</base-sfr-spec>
</oneOrMore>
</section>
</zeroOrMore>
</modified-sfrs>
<modified-sfrs>
<section title="Cryptographic Support (FCS)" id="modsfr-sec-gpos-fcs">
<base-sfr-spec cc-id="fcs_ckm.1" title="Cryptographic Key Generation" id="modsfr-os-fcs-ckm-1">
<consistency-rationale>
The ST author is instructed to make specific selections at minimum to address VPN client requirements; the
SFR behavior itself is unmodified.
</consistency-rationale>
<description>
This SFR is functionally identical to what is defined in the GPOS PP except that
ECC key generation with support for P-256 and P-384 has been made mandatory
in support of IPsec due to the mandated support for Diffie-Hellman (DH) groups 19 and 20 in
FCS_IPSEC_EXT.1.8.<h:p/>
In other words:<h:br/><h:br/>
The <h:b>OS</h:b> shall generate <h:b>asymmetric</h:b> cryptographic keys in accordance with a
specified cryptographic key generation algorithm
<h:b>[selection:</h:b><h:br/><h:i><h:ul>
<h:li>RSA schemes using cryptographic key sizes of 3072-bit or greater that
meet the following: FIPS PUB 186-4, "Digital Signature Standard (DSS)", Appendix B.3
</h:li>
<h:li>ECC schemes using "NIST curves" P-384 and
<h:b>[selection:</h:b>P-521, no other curves<h:b>]</h:b>
that meet the following: FIPS PUB 186-4, "Digital Signature Standard (DSS)",
Appendix B.4
</h:li>
<h:li>FFC schemes using <h:br/>
<h:b>[selection:</h:b><h:ul>
<h:li>cryptographic key sizes of 3072-bit
or greater that meet the following: FIPS PUB 186-4, "Digital Signature
Standard (DSS)", Appendix B.1
</h:li>
<h:li>safe primes that meet the following:
NIST Special Publication 800-56A Revision 3, “Recommendation for Pair-Wise Key Establishment Schemes"
</h:li>
</h:ul><h:b>]</h:b>
</h:li>
</h:ul></h:i><h:b>]</h:b>.<h:p/>
Is replaced by:<h:br/><h:br/>
The <h:b>OS</h:b> shall generate <h:b>asymmetric</h:b> cryptographic keys in accordance with a
specified cryptographic key generation algorithm
<h:b><h:ul><h:i>
<h:li>ECC schemes using “NIST curves” P-256, P-384, and
<h:b>selection:</h:b>P-521, no other curves<h:b>]</h:b>
that meet the following: FIPS PUB 186-4, “Digital Signature
Standard (DSS),” Appendix B.4, and,
</h:li></h:i>
</h:ul></h:b>
<h:b>[selection: </h:b><h:i><h:ul>
<h:li>RSA schemes using cryptographic key sizes of 3072-bit or greater that
meet the following: FIPS PUB 186-4, "Digital Signature Standard (DSS)", Appendix B.3
</h:li>
<h:li>FFC schemes using <h:br/>
<h:b>[selection:</h:b><h:ul>
<h:li>cryptographic key sizes of 3072-bit
or greater that meet the following: FIPS PUB 186-4, "Digital Signature
Standard (DSS)", Appendix B.1</h:li>
<h:li>safe primes that meet the following:
NIST Special Publication 800-56A Revision 3, “Recommendation for Pair-Wise Key Establishment Schemes"
</h:li>
</h:ul><h:b>]</h:b>
</h:li>
<h:li><h:b>No other key generation methods</h:b></h:li>
</h:ul></h:i><h:b>]</h:b>.
This SFR is also changed from mandatory to optional.
</description>
<replace>
<xpath-specified xpath="*//cc:f-element[@id='fel-asym-gen']//cc:title">
<title> The <h:b>OS</h:b> shall generate <h:b>asymmetric</h:b> cryptographic keys in accordance with a
specified cryptographic key generation algorithm
<h:b><h:ul><h:i>
<h:li>ECC schemes using “NIST curves” P-256, P-384, and
<selectables>
<selectable>P-521</selectable>
<selectable exclusive="yes">no other curves</selectable>
</selectables>
that meet the following: FIPS PUB 186-4, “Digital Signature
Standard (DSS),” Appendix B.4, and,
</h:li></h:i>
</h:ul></h:b>
<selectables linebreak="yes">
<selectable>RSA schemes using cryptographic key sizes of 3072-bit or greater that meet
the following: FIPS PUB 186-4, “Digital Signature Standard (DSS),”
Appendix B.3</selectable>
<selectable>FFC schemes using <selectables>
<selectable>cryptographic key sizes of 3072-bit or
greater that meet the following: FIPS PUB 186-4, "Digital Signature
Standard (DSS), Appendix B.1"</selectable>
<selectable>safe primes that meet the following: NIST
Special Publication 800-56A Revision 3, “Recommendation for Pair-Wise
Key Establishment Schemes</selectable></selectables></selectable>
<selectable exclusive="yes"><h:b>No other key generation methods</h:b></selectable>
</selectables>.
</title>
</xpath-specified>
</replace>
<set-status status="optional"/>
</base-sfr-spec>
</section>
etc. etc. etc.
</modified-sfrs>