commoncriteria / application

Protection Profile for Application Software
The Unlicense
9 stars 3 forks source link

ment/able #69

Closed WeeknightMVP closed 10 years ago

WeeknightMVP commented 10 years ago

When did we get rid of <assignable>s (templates declared in this PP to be populated by STs)? <assignment>s were supposed to be for the symmetric concept (this PP populating templates declared in the CC)?

Our PP specifies plenty of assignables and makes one assignment, in (this PP's) FMT_SMF.1.1, which derives from CC Part 2 FMT_SMF.1.1.

CC Part 2 FMT_SMF.1.1: "The TSF shall be capable of performing the following management functions: [assignment: list of management functions to be provided by the TSF]."

Applications PP FMT_SMF.1.1: "The TSF shall be capable of performing the following management functions:

So what we are doing is making an assignment, replacing CC's "list of management functions to be provided by the TSF" to everything within our outer square brackets, which in turn has assignables to be specified by STs.

Let's look at the underlying XML:

Original:

<f-element id="fmt_smf.1.1">The TSF shall be capable of performing the following management functions:
  <fe-assignment>
    <fe-assignmentitem>list of management functions to be provided by the TSF</fe-assignmentitem>
    <fe-assignmentnotes>
      <para type="normal">
        the PP/ST author should specify the management functions to be provided by the TSF, either security attribute management, TSF data management, or security function management.
      </para>
    </fe-assignmentnotes>
  </fe-assignment>.
</f-element>

Note that this markup calls it an "assignment", but it's really indicating something PPs can assign -- an "assignable", if you will. (The markup also fails to identify the <fe-assignment>, so external documents can't directly refer to it. This further demonstrates that the author didn't fully consider the premise that other documents might link to the CC XML, but I digress.)

But suppose the CC XML were rephrased a little more reusably/descriptively:

<element id="FMT_SMF.1.1">The TSF shall be capable of performing the following management functions:
  <assignable id="FMT_SMF.1.1.a1">
    <template>list of management functions to be provided by the TSF</template>
    <note>The PP/ST author should specify the management functions to be provided by the TSF, either security attribute management, TSF data management, or security function management.
    </note>
  </assignable>.
</element>

Then PP XML could refer directly to this <assignable> with an <assignment>:

<element id="FMT_SMF.1.1">
  <derives ref="cc.xml#FMT_SMF.1.1" />
  <assignment ref="cc.xml#FMT_SMF.1.1">
    <ul>
      <li>enable/disable the transmission of any information describing the system's hardware, software, or configuration if this functionality exists</li>
      <li>enable/disable the transmission of any PII if this functionality exists</li>
      <li>enable/disable transmission of any application state (e.g. crashdump) information if this functionality exists</li>
      <li>
        enable/disable network backup functionality to 
        <assignable id="FMT_SMF.1.1.a1">
          <template>list of enterprise or commercial cloud backup systems</template>
          <note>[describes valid assignments STs can make for this assignable]</note>
        </assignable> 
        if this functionality exists
      </li>
      <li>
        <assignable id="FMT_SMF.1.1.a2">
          <template>list of other management functions to be provided by the TSF</template>
          <note>[describes valid assignments STs can make for this assignable]</note>
        </assignable>
      </li>
    </ul>
  </assignment>
</element>

But @jeffblank argued that awkwardly referring to, or improving, flawed CC XML markup would not be worth the effort, preferring a hybrid of copying/pasting the template text and marking up the CC operations, more like:

<f-element id="FMT_SMF.1.1"> <!-- Why aren't these currently uppercase like the actual labels? -->
  <template> <!-- Right now it's "title"??!! -->
    The <abbr linkend="TSF"/> shall be capable of performing the following management functions:
    <assignment ref="cc.xml#fmt_smf.1.1.a1"> <!-- Supposing reusable CC XML with labeled assignable. -->
      <ul>
        <li>enable/disable the transmission of any information describing the system's hardware, software, or configuration if this functionality exists</li>
        <li>enable/disable the transmission of any PII if this functionality exists</li>
        <li>enable/disable transmission of any application state (e.g. crashdump) information if this functionality exists</li>
        <li>
          enable/disable network backup functionality to 
          <assignable id="FMT_SMF.1.1.a1"> <!-- Identify assignables; STs might actually want to refer to our stuff. -->
            <template>list of enterprise or commercial cloud backup systems</template>
            <note>[describes valid assignments STs can make for this assignable]</note>
          </assignable> 
          if this functionality exists
        </li>
        <li>
          <assignable id="FMT_SMF.1.1.a2">
            <template>list of other management functions to be provided by the TSF</template>
            <note>[describes valid assignments STs can make for this assignable]</note>
          </assignable>
        </li>
      </ul>
    </assignment>
  </template> <!-- I mean, really; "title"??!! -->
  <aactivity>...</aactivity>
</f-element>

And then at some point when I was off the reservation, this approach became something I lost touch of.

So the point is that the markup should distinguish things we tell STs to assign ("assignables") from things we're assigning from the CC ("assignments"), and ditto for selectables/selections.

I will try to polish the markup/transform to this effect sometime when the rest of the group is not actively changing content.

WeeknightMVP commented 10 years ago

Did name change (<assignment> --> <assignable>) and corrected transforms so that markup within <selectable>s/<assignable>s is processed; closing.