A Multi-Level Model for Common Criteria Certificate Maintenance

by Trang Huynh

I had the privilege of being on a discussion panel at the NIAP Validator Workshop this past June. The topic for the panel was “Continuous Software Update,” and the issue we were trying to tackle was Common Criteria (CC) evaluations for products with a high frequency of software updates, such as those for mobility products. From the discussion, I identified that the issue is two-fold:

1. updates occurring while the evaluation is in progress, and
2. updates after the evaluation is completed.

The case of updates after evaluation completion was the focal point of the panel discussion. Many ideas were brought up during the panel ranging from delta evaluations to requirements for regression testing, full evaluations, etc.

NIAP provides Publication #6 (Pub 6) describing the certificate maintenance / assurance continuity process offered by the scheme. This document contains definitions and examples of major changes and minor changes in addition to an outline of the necessary actions from the vendors and/or CCTLs pursuing certificate maintenance. Yet it is a great challenge for vendors/CCTLs and validation bodies alike to methodically determine whether an update constitutes a major or minor change. Changes in the extreme cases are easy to classify, but cases in the middle ground can be extremely fuzzy.

To solve this difficulty with classification, I raised an idea at the panel that the certificate maintenance process offer a predefined multi-level model similar to the one offered by FIPS 140-2. At a high-level FIPS 140-2 breaks down a change into several submission scenarios or SUB for short, (1SUB, 1ASUB, 1BSUB, 2SUB, 3SUB, 3ASUB, 4SUB, 5SUB, etc.) For example, 1SUB addresses administrative or non-security relevant changes that do not affect any FIPS 140-2 security-relevant items, such as updating vendor contact information or testing the module on additional platforms, that have little or no impact on the validated cryptographic module. The 3SUB scenario encompasses changes that would exceed 30% of the module's overall security functionality. Last but not least, 5SUB is for changes that do not meet 1SUB through 4SUB requirements. This model conceivably allows CST labs more "jurisdiction" to decide on the level of the change. Based on that decision the CST lab may proceed with the “game plan” described in section G.8 Re-validation Requirements of the Implementation Guidance which may involve the CST lab performing applicable testing on the changed cryptographic module and submitting the test results (along with other required materials) to the CMVP for re-validation.

I believe an introduction of gradation of changes in the certificate maintenance process would allow for a more systematic approach for performing impact analysis on product updates.