Changes to Transforms - commoncriteria/pp-template GitHub Wiki

You can now have more than one <from> tag attached to a <threat> tag in a Module to indicate that a threat is inherited from more than one base PP. This results in the short names of the base PPs being displayed after the threat name in the Threats section and in the TOE Requirements Rationale table.

See Threats.

• Added a <suppress-niap-logo> preference to the <pp-preference> tag to suppress display of the NIAP logo on the title page. You might want to do this for a cPP, since cPPs are not strictly NIAP documents.

For details, see PP Preferences.

• Created a separate build target for cPPs in cPP.make and Helper.make so that 'release' and non-release builds are properly built.
• Release builds have separate SDs for the EAs and appendixes for optional, selection-based, etc. SFRs.
• Non-release builds have in-line EAs and appendixes for optional, selection-based, etc. SFRs (just like a PP).
• For this to work, cPPs must use the correct Makefile. Steal it from FDEAA or FDEEE.

• Modified cPP.make to support generation of separate Supporting Documents for cPPs.
• Fixed bug that Caused EAs for SARs to be displayed inline for cPPs and Modules.

• Allow the Introduction to include a Use Cases section
• Allow the invisible attribute on SFRs (for some reason this was not allowed in FPs) There were no changes to the handling of anything, so this should affect only the Validation of FPs and not the processing.

I didn't even know this was a thing, but it is now causing problems so from now on you will have to manually do this until somebody figures out a way to selectively turn off this feature.

This attribute is optional, but eventually it will become mandatory for extended components if they are to be included in the ECD Appendix. We hope this will eliminate a kludge related to iterated extended components. And maybe we'll be able to finally get rid of the invisible attribute. But for now, the attribute does nothing. The legal values are "yes" and "no," but only "yes" will likely be tested for.

By the way, there is no requirement in the CC that extended components have the "_EXT" extension.

Iteration names were being converted to upper case when displayed as part of a modified SFR in a Module. The case of the iteration name is now preserved from the <base-sfr-spec> tag.

The <from> tag is used within the <threat> tag to indicate that a threat in a PP-Module is inherited from a Base PP. This tag actually has existed for some time, but was not documented in this wiki.

The output of transforms has been modified to output the descriptions of the inherited threats (previously these were suppressed). And the SFR Requirements Rationale table has been modified to indicate that the threats are inherited.

See Threats.

The <CClaimsInfo> tag now includes an optional cc-errata attribute that allows a PP Author to specify the CC:2022 errata version that the document conforms to. Current legal values are "v1.0" and "v1.1".

If specified, the errata documents are automatically referenced in the Conformance Claims section and in the Bibliography.

See Conformance Claims.

Actually, any threat that includes a <from> tag will now include the source of the threat in the tables. There is no change to the schema.

If you add an id to a selection under a <base-sfr-spec> tag in the new, reformed <modified-sfrs> construct, you can now reference the selection in a <depends> tag.

If it works properly, the dependency will be displayed in the dependent SFR's header as a dependency on the Modified SFR. The downside is that it will refer to the component rather than the element. But that's the best we can do on short notice.

This way it can be left out if there are no Objectives of any kind in the document.

See Security Objectives Rationale.

This allows specification of text to appear in the Modified SFRs section of a PP Module that is not associated with any actual modification of the SFR.

See Modified SFR Reform

I seem to have forgotten to allow this--the most common status change.

This allows the mixing of normal selections and assignments with the tabularized selections in a tabularized f-element title. This was needed because of the Crypto Catalog's new SFR FCS_OTV_EXT.1.

Fixed a bug that caused invisible SFRs in Modules to not be invisible.

In the past, PPs and cPPs could impose audit events on SFRs within Functional Packages using the invisible attribute on an <f-component>. This is no longer supported. Audit events for FPs must be defined in the FPs. If a PP needs to enable or disable them, this can be done in FAU_GEN.1. If the PP needs to modify audit events from a Package, the Package SFR can be iterated and refined. But reaching into a Package and modifying an SFR should never have been allowed. And now you can't do it anymore.

Until now, objective requirements have been treated the same as optional requirements in the transforms. This minor change indicates that objective requirements may become mandatory in the future.

Fixed a minor bug that caused duplicate boilerplate text in some places in the Consistency Rationale Section of PP-Modules.

To define categories of EA other than TSS, Guidance, and Tests, use the <CustomEA> tag. The KMD tag will be deprecated in the future. See Evaluation Activities.

Added missing boilerplate introductory text for PP Conformance Claims.

In the past, only text was allowed inside the <assignable> tag. Now HTML is allowed as well. This was a change only to the schema, not to the transforms.

If you use the above construct to apply to a selection-based SFR, it is now displayed in the SFR header that the SFR is optional.

An overnight update (18-19 Dec) broke something in the back-end causing QuickBuild to fail for all builds.

The problem was caused by an update somewhere in python or lxml that caused a failure to handle comments in the XML source files. An update to post_process.py seems to have done the trick.

Updating to the latest transforms should solve the problem.

SFRs that are modified by a PP Module may now be either from a Base PP or from a Functional Package that is imported by a Base PP.

This is documented in Modified SFRs Reform.

This tag was used only in the AppPP to defining platform-specific tests. It was long ago replaced by a set of selections.

Conformance claims must now be expressed in terms of the <CClaimsInfo> tag. All text is boilerplate unless the display attribute is set to "no". The boilerplate attribute of the Conformance Claim section should have no effect.

There are now two ways to specify Modified SFRs in PP-Modules:

• The Old Way is the way it's been done up till now.
• The New Way better supports automation. Eventually the New Way will be the only way.

The new way is documented in Modified SFRs Reform.

Added a new attribute notes-in-table to the <management-function-set> tag. Setting this attribute to "yes" indicates that the contents of all the <app-note> tags for each <management-function> should appear in a column in the table versus at the end of the management functions. By default, management function app-notes appear after all the management functions.

E.g.

         <management-function id="mf-sample">
             <depends on-sfr="sfr-sample"/>

Management functions that are implemented at the discretion of the ST Author must use this construct. The Function is assumed to be Mandatory if there is no dependency.

         <management-function id="mf-sample">
             <depends><optional/></depends>

E.g.

         <O ref="A">
             <depends on-sel="sel-admin-priv-exists"/>
         </O>

If there is no dependency, the role-to-function mapping is assumed to be optional at the discretion of the ST Author.

All dependencies should be documented in the app-notes.

For more on these changes, see Management Functions and Management Function Reform.

• Updated the schema to allow HTML elements to appear in <comment> tags. This eliminates annoying validation errors in these debugging elements.

• Deprecated and removed the <using-cc2022> preference from the schema and transforms. Instead, requirements documents must specify CC:2022 from within the <CClaimsInfo>. See Conformance Claims.

• Changed Module SD generation to use <base-pp> attributes. This should also fix problems with the names and section numbers for Module's SDs (not tested).

• Removed links from <componentid> tags of <componentsneeded> elements in FPs. These are references to SFRs in other documents, so they should not be links.
• Added ECD elements to Package schema for <f-components>. You could add ECD information to these SFRs, but they would fail validation. Now they will validate.
• Removed output of Part 3 Conformance statement for FPs in the <CClassInfo> tag (not tested).

• Updated boilerplate.xml to fix typo (mbdowne).

• Allow choose-one-of attribute on <selectables> to mean the same thing as onlyone, that is, [selection, choose one of...].

• Allow <implements> tag almost anywhere that stray text is allowed. In the past, the <implements> tag could appear only between Appendixes at the end of the document. Now, you can't use it there, but you can use it almost anywhere else.

The <implements> tag is used to define features that are used as dependencies for implementation-dependent SFRs. The preferred way to define these features is in a section in the Introduction. The old way was to define them in an Appendix.

Direct Rationale PPs and PP-Modules are now supported. See Direct Rationale Documents for details on the changes, and on how to declare a document to use the Direct Rationale approach.

The display attribute has been added to the <CClaimsInfo> element. If the attribute is set to 'no', then the contents of the <CClaimsInfo> are used for purposes of Direct Rationale, etc., but are not be displayed in the Conformance Claims section.

There is a new way for defining the Conformance Claims section. The new construct is mandatory for Direct Rationale documents (although Direct Rationale is not yet supported), and encouraged for CC:2022 documents.

See a description of the new <CClaimsInfo> XML element here.

In PP-Modules, Optional SARs must be defined in the <opt-sfrs> section--not the <mod-sars> section. In the published document, they appear in Appendix A.1 with the other Optional Requirements. Mandatory SARs are defined in the <mod-sars> section.

The reason for this odd arrangement is that to do otherwise would require a major overhaul of transforms, which would certainly not be worth it for a corner case like this.

• Fixed a problem with the section numbering in the SAR Section of PP-Modules.

Transforms has been updated to properly handle optional SARs. Optional SARs are defined in the Security Assurance Requirements section with all the other SARs by defining the <a-component> tags with status="optional." In the generated requirements document, optional SARs appear in Appendix A.1 along with the other Strictly Optional Requirements. The "optional" status is the only recognized status for SARs. If you try to make a SAR "objective" or "invisible" it will not go well for you.

• Optional Security Problem Description and Security Objectives sections now supported in Functional Packages.

• Simplified the boilerplate text for empty EA sections.

• Schema updated to allow xrefs to now-predefined Bibliography entry for the CEM.
• XSL updated to implement the above.

• Schema updated to allow status="optional" for <a-component> elements. This in anticipation of having optional SARs to support CC:2022.

• Fixed the annoying extra space that appeared before the closing bracket in all selections. It was really easy to fix, so I suspect I broke something else.

• Updated the schema for Base PP specifications in Modules to require id, name, short, product, and version attributes. The plural attribute remains optional. Also, the schema now accepts the <git> element here as well. The <url> element is still required.
• Deprecated element "pp-pref-pat" element removed from the schema.
• Unused sel-by-sfr attribute removed from <audit-table>.

• Now supports empty EAs with boilerplate text for Management Functions.

• Removed sanity checks for empty <TSS>, <Guidance>, <KMD>, and <Tests> tags.
• Now those tags, if empty, produce boilerplate text.
• Extra <br/> or <p/> tags are no longer needed at the ends of text for the above tags for the text to look pretty.
• The above changes apply only to Element-level and Component-level EAs, not to management function EAs.
• An empty <no-tests> tag now outputs "TODO" text into the document. You have to explain why there are no tests.
• The schema now allows the empty <bibliography/> tag.
• Added the boilerplate attribute to the OSP section to allow suppression of the default text.

• Fixed (I hope) a bug that caused duplicate SFRs in <additional-sfrs> sections of PP-Modules for non-release builds.

• Added table number and caption to Bibliography

• Changed Security Requirements Direction heading in Modules to use the expanded PP Name
• Added captions and numbers to the tables in the Consistency Rationale section of Modules
• Added caption and number for Acronyms table
• Fixed a problem with Section numbering in an <additional-sfrs> section.
• Fixed a problem with empty <management> and <audit> tags not displaying default text in ECD Appendix.

• Fixed typo in Modules Consistency of Objectives
• Fixed typo in Bibliography boilerplate
• Fixed Base PP Short Names in Security Objectives Rationale in Modules

• Updated Package schema to allow the <using-2022/> preference.

If you add the <using-cc2022/> element to the <pp-preferences> then the following boilerplate is updated to CC:2022:

• The bibliography. Also the CEM reference is now auto-generated.
• Updated boilerplate text for Implicitly Satisfied Requirements.
• Updated boilerplate text for referring to the CC version

Also

• Refinement to the boilerplate text describing Refinements.

• Modified the schema to allow a <using-cc2022/> preference to be included in the <pp-preferences> element. It's not hooked up to anything yet, but PPs that intend to be CC:2022 compliant should include it. Eventually this preference will go away and all PPs will be CC:2022 compliant.
• Modified the Module schema to allow the <pp-preferences> element. This element is already allowed in Packages.

• Edited boilerplate to output "Functional Package" rather than "PP-Package" into the front matter of Functional Packages.

• Edited schema to allow optional name and short attributes to the <base-pp> element whether or not the referenced documents are "known." This seems to fix a weird problem in vpnclient where some of the headers for the base PP sections have the wrong names.

These SFRs can now be assigned status values of "optional," "objective," "sel-based," or "feature-based."

The resulting HTML document will indicate the statuses of the SFRs.

These were for some reason hidden before. Or they weren't allowed. In any case, you can define audit events for these SFRs and they will be displayed at the top of the Additional SFRs section.

You still can't do this for Modified SFRs.

This element should now appear in a section in the introduction for PPs or Modules that have implementation-dependent SFRs.

See Optional, Objective, and Implementation‐Dependent SFRs for details.

Those keywords were not being used for anything.

• All occurrences of "implementation-based" changed to "implementation-dependent"
• Other minor changes to boilerplate text.
• Modified the PP-Module schema to allow audit tables in the Additional SFRs section of a PP-Module.

The "Security Problem Description" section has been changed to "Security Problem Definition" as is required by the Common Criteria. This breaks all protection profiles.

The solution is to change:

  <sec:Security_Problem_Description> to <sec:Security_Problem_Definition>

or

  <section title="Security Problem Description"> to <section title="Security Problem Definition">

depending on which form you use in your document.