About the Version 2.0 Public-Review Draft

The draft gives shared vocabulary for a TOE composed of multiple application payloads. It distinguishes named TOE Components, deployed TOE Component Instances, and Runtime Replicas. It also identifies Communication Relationship Types and protected-channel instances so that an ST can describe which components communicate, how they are deployed, and which security claims apply.

This makes scale-out reviewable without treating every horizontally scaled replica as a new logical component. A deployment difference that changes an artifact, security-relevant configuration, role, claimed behavior, or relevant platform interface is not silently treated as equivalent.

The draft uses an NDcPP-aligned allocation vocabulary: All Components, At Least One Component, and Feature Dependent. It records the condition that brings a requirement into the ST separately from the allocation that identifies the component or components that implement it.

Where components implement different elements of a multi-element requirement, the ST maps the elements to the responsible components. The TOE-level claim is satisfied only when the mapped elements collectively satisfy the requirement. This is intended to make responsibility precise without creating an optionality mechanism or allowing an implementing component to be omitted.

The draft distinguishes vendor-provided application content from the platform services on which it runs. A payload, sidecar, library, or other vendor-provided component that implements or supports a claimed requirement remains TOE content even when delivered in a container pattern. Conversely, the orchestration platform, runtime, host kernel, service mesh, ingress, cluster network, and platform-provided secret or configuration services are operational-environment components unless the ST explicitly includes them in the TOE boundary.

The ST and guidance must describe each operational-environment dependency, including the required configuration, expected service and failure behavior, and relevant trust assumptions.

For Server—​Agent deployments, the draft distinguishes the enablement, registration, permitted communication, and disablement of a pairing from the protection of data transmitted between components. It also distinguishes in-scope network-mediated communication from local, non-network IPC so that each is addressed by the appropriate requirement or objective.

This separation is intended to make the channel, component, and operational-environment boundaries visible to both ST authors and evaluators.

The draft permits a permitted replica topology to be described without duplicating a claim merely because an application scales horizontally. It still preserves required coverage for separately versioned artifacts, update paths, security-relevant configurations, interfaces, communication relationships, and end-to-end behavior.

Evidence or testing may be reused only when the relevant security implementation, configuration, and execution context are demonstrated equivalent for the particular activity. It does not remove component-, artifact-, interface-, channel-, or end-to-end checks that remain applicable.

The Server and Agent material has been re-layered against the Version 2.0 base so that common functionality is handled once at the appropriate layer. For example, the base handles the applicable X.509 and transmitted-data treatment, while the modules and configurations identify the role-specific responsibilities and mappings. This is an alignment of the existing modular approach with the new base, not a new cryptographic policy.