PD-0054: What is an appropriate TOE Reference?

This decision represents a long-term technical decision based on an OD, and may not be the same as the final results of the source OD. With respect to published criteria documentation and scheme documents, it provides suggested guidance on evaluation direction, but is not authoritative. Authoritative decisions are provided through the published criteria documents and published scheme and international interpretations thereof. With respect to published PPs, PDs are authoritative corrections to the PP, based on input from the PP author (if available), that are in force until the publication of the next revision of that PP.

Issue

(U) The CC (Part 1, Section C.2.2, page 45) states that the ST must identify the TOE to which it refers. ACM_CAP.4.1D and ACM_CAP.4.1C require the developer to provide a unique reference for the TOE. Is there a specific NIAP-recommended/mandated form for this reference? Must it be short enough to appear on a NIAP web page (i.e., product name, version/release number, date)? What happens if a vendor does not refer to their product in that manner? Could it be a list of part numbers, hardware versions, software versions, and firmware versions?

Resolution

The CC and the CEM do not mention (or support) a requirement to control how a developer chooses to uniquely identify the TOE. Therefore, there is no mandate for a “short version” number of the TOE to be assigned and published.

However, there does remain the requirement in ACM_CAP.4.1D and it associated CEM work unit ACM_CAP.4-3 that must be addressed.

ACM_CAP.4.1D states:

“The Developer shall provide a reference for the TOE.”

CEM work unit ACM_CAP.4-4 states:

“ The evaluator shall check that the TOE references are consistent.”

If the TOE is labeled more than once then the labels have to be consistent. For example, it should be possible to relate any labeled guidance documentation supplied as part of the TOE to the evaluated operational TOE. …”

This requirement applies not only to labeled guidance documentation supplied as part of the TOE, but also to all documentation where the TOE is referenced to include the CCEVS Certificate, the Security Target and the CCEVS Validation Report. The evaluators are not only responsible for ensuring that TOE references within the developer documentation is consistent, they (and the validators) are responsible for ensuring that documents produced by the scheme or on behalf of the scheme meet this requirement.

Given this, there are some practical concerns that the developer should consider when uniquely identifying the TOE such as the physical space limitations of a CCEVS Certificate, how the TOE will be marketed and the overhead of listing all components of TOE when the TOE is referenced in different documents.

Support

Although there are a number of practical arguments for mandating a short identification for TOE unique references, the CC does not dictate this and probably with good reason. What would such requirements look like? What parameters would be allowed? Coming up with such a standard approach not only impedes what has traditionally been a developers right to create their own product and reference but also implements yet more bureaucracy for the scheme and the vendors using it for a small return.

However, this does not mean that that reference can be ambiguous and inconsistently used. This is what the CCEVS should strive for: consistent, unambiguous references to the TOE, not necessarily simplicity, which in some cases cause more problems than it solves.

Modification History:

2004-08-12

Updated effective date to reflect the date the PD was issued. (August 2004 NIB 6.c.xiv)

References:

• CC v2.1 Part 1 Subclause C.2.2
• CC v2.1 Part 2 Subclause 8.2 ACM_CAP.4.1

Related NIs:

• None

Related CCIMB-INTERPs:

• None

Source OD: 0196