-
Notifications
You must be signed in to change notification settings - Fork 2
Changes to Transforms
- 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
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.