I-0397: Iteration On Assurance Components/Elements


[The following is the ASCII version of the proposal as posted on Gibraltar. A
pretty-printed PDF version is attached.]

  This transaction consists of a proposal for a National Interpretation of
  a Common Criteria document. It is being posted in accordance with the
  procedures of the IWG.

  Comments on this proposal are welcomed and should be posted to this
  transaction chain.  If any party wishes to post a comment anonymously,
  the comment should be mailed to IWG@gibraltar.ncsc.mil in a form
  suitable for posting.  All comments should be posted no later than
  Monday, February 5, 2001.


                 CCITSE/CEM  NIAP INTERPRETATION (PROPOSED)


     _________________________________________________________________

              I-0397: Iteration On Assurance Components/Elements
     _________________________________________________________________

NUMBER:               I-0397
STATUS:               Ready for External Review
TYPE:                 NIAP Interpretation

TITLE:                Iteration On Assurance Components/Elements

SOURCE REFERENCE:     CC v2.1 Part 1 Subclause 4.4.1
                      CC v2.1 Part 3 Subclause 2.1.3.5
                      CC v2.1 Part 3 Subclause 2.1.4
RELATED TO:           <None>

ISSUE:

   The CC, in Part 1, appears to permit iteration at the level of
   assurance components. However, Part 3 only discusses refinement at the
   element level; no mention is made of iteration.

STATEMENT OF INTERPRETATION:

   Iteration is permitted on sets of assurance elements (as defined in
   Part 3, Section 2.1.3.5) and on assurance elements.

SPECIFIC INTERPRETATION:

   To address this interpretation, the following changes are made to CC
   v2.1, Part 3: (additions marked _thusly_; deletions marked _[DEL:_
   thusly _:DEL]_ )


     * In Section 2.1.3.5, after paragraph 53, add the following
       paragraph:

     Iteration is permitted at the level of developer action elements,
     content and presentation of evidence elements, and explicit
     evaluator action elements.

     * In Section 2.1.4, replace paragraph 56 with the following:

     In contrast to CC Part 2, neither assignment nor selection
     operations are relevant for elements in CC Part 3; however,
     refinements _and iterations_ may be made to Part 3 elements as
     required.

FURTHER CONSIDERATIONS:

   The criteria changes may be subject to further changes depending on
   the resolution of I-0379 (Documentation Sections) [an RFI sent to the
   CCIMB]; in particular, assigment may move from the not-relevant
   category to being relevent when explicitly specified.

   Additionally, the above paragraph may be subject to futher changes
   depending on the resolution of I-0394 (Iteration Must Cover All
   Scopes); in particular, there may be additional words noting that if
   iteration is used to apply a requirement to a subpart of the TOE,
   there must be sufficient iterations that the entire TOE is covered.

   Lastly, corresponding methodology changes may be needed to address the
   effects of these changes.

PROJECTED IMPACT:

   Negligible impact anticipated.

SUPPORT:

   This interpretation corrects the identified discrepancy.

   There are three potential levels of iteration for assurance
   components:

    1. At the level of the entire component.
    2. At the level of a set of assurance elements (C/D/E).
    3. At the element level.

   It is difficult to come up with an example of iteration of an entire
   assurance component that does not result in unnecessary redundancy. It
   is more appropriate to iterate assurance at either the level of the
   D/C/E groupings, or at the level of individual elements. For example:

    1. Iteration at the level of D/C/E might be useful for independent
       testing, if the ST author wanted to have multiple groups
       performing independent testing. In such a case, the "E" components
       might be iterated to explicitly specify the groups performing
       testing.
    2. Iteration at the element level might be useful for indicating that
       some elements of a design description might have an additional
       formal specification in addition to the level called out by the
       EAL.


0397.pdf



Date Index | Thread Index | Problems or questions? Contact list-master@nist.gov