Sharing infrastructure in a Mission Partner Environment

A shared mechanism

CABE can provide a common mechanism for protecting application data and controlling key access within agreed mission-partner information-sharing arrangements. The objective is to make approved sharing rules executable and repeatable across participating applications, including arrangements that must continue operating through disrupted connectivity.

The common mechanism is an Envelope format and key access protocol. It does not require one centrally operated Key Service, one identity provider or identical permissions. The architectural objectives are less bespoke protection logic, reusable brokers, transport and storage, and less infrastructure duplicated solely to separate audiences. These are intended benefits, not measured savings or evidence of a deployed government solution.

DoDD 5101.22E’s MPE definition describes an operating framework at a single security level. A CABE Domain instead comprises one logical Key Service, provided by one or more Key Servers, and its Clients. It is not a synonym for an MPE, classification domain or approved security boundary. [1] [5]

Three distinct relationships

DoDI 8520.02 likewise distinguishes accepting an authenticated identity from subsequent rules-based authorisation or access decisions. Here, each application authenticates to its own Domain’s Key Service through locally accepted identity arrangements; federation does not require every client to authenticate to every partner’s identity system. [2] [7]

Disclosure authority is also distinct from authorisation to use a particular transport or storage architecture. ‘The relay cannot decrypt this’ is a security property. It is not, by itself, an authorisation to place the information on that relay. Reusing shared or unclassified transport remains an objective within an appropriately authorised architecture; object encryption neither authorises arbitrary placement of classified information nor supplies the assurance of an entire classified network.

Prepare the partner product

Consider a proposed integration using synthetic data, inside an already approved security and releasability arrangement. It demonstrates no transition between classification levels. An organisational rule permits specified partner analysis applications to receive a defined class of observation products.

The original synthetic report contains an observation, an internal source identifier and collection notes not intended for partners. An authorised production process prepares a distinct partner product, retaining the approved observation and removing the excluded details. This illustrates writing for release: preparing content for the intended audience, including sanitisation or redaction where required. The Army’s April 2025 guide connects this practice with disclosure coordination and data-sharing agreements; it describes REL TO as reflecting an affirmative disclosure determination. [3]

Operators assign the resulting product appropriate Attributes and translate the sharing rule into recognised caller Claims and Key Service policy. For example: permit observation access to the designated partner analysis application; refuse the partner maintenance application. These are illustrative application choices, not CABE-defined fields. Translating and testing that rule is integration work. Approval may cover a class of exchanges, subject to whatever review the arrangement requires.

The release process decides what the product contains. CABE protects that product afterwards; it does not redact, declassify, inherit policy automatically or relabel unchanged ciphertext into a releasable product.

Protect and deliver

The operators establish the necessary Origin–Target federation arrangement. This construction uses CFAR’s Non-Captive Lease Keys, Early Interbinding and Inline Propagation. During Prograde Resolution, the Origin Key Service includes the prepared Target Domain and creates a Simple Federated Lease Package (FLP) using a suitable Federation Public Key of the Target. The Target retains the corresponding Federation Secret Key. [8]

The producer obtains the authorised Lease and FLP, encrypts the partner Message locally, and attaches the FLP to the Envelope. A shared relay carries the Envelope and encrypted package without application decryption keys. The protected Payload travels to the applications, not through a Key Service. [6]

Each recipient authenticates locally and requests Retrograde Resolution, quoting the Origin Domain ID, Attribute Set, Lease Reference and FLP. The Target Key Service decrypts and verifies the package and checks that its protected identifiers exactly match the request. Local policy then determines whether that caller receives the applicable material. Both clients can authenticate while only the analysis application obtains access. [7] [8]

When the Origin link fails

After delivery, interrupt the Origin-to-shared-delivery connection shown in the diagram; assume the Target has no other live Origin connection. Already delivered Envelopes and FLPs remain accessible. With its federation private material, local Key Service, identity information and policy available, the Target can service fresh local requests without contacting the Origin. This does not promise continued arrival of new products.

An unprepared Domain is not guaranteed access. The Target cannot learn remote policy or credential changes it has not received. Lease expiry does not erase obtained keys or plaintext. Because the Target Key Service recovers usable Lease material, it is a trusted material holder, unlike the ciphertext relay. The Origin cannot continuously enforce every downstream decision after sharing that material.

A proposed evaluation

These are expected observations for a proposed test, not reported results:

1. Deliver the synthetic Envelope and inline FLP. Authenticate both applications successfully; expect the analysis application’s fresh local request to obtain material and the maintenance application’s request to be refused.
2. Interrupt the identified Origin connection. Repeat a fresh request to the Target Key Service; expect permitted access using the available FLP, federation material and local services.

For each trial, start the permitted client without a cached Lease Key, Content Encryption Key or plaintext. Record the new request and local decision so client caching cannot explain success.

The interoperability contribution

Common protection and key access can support exchange; applications still need compatible Payload formats, agreed Attribute meanings and operational procedures. CJCSI 6290.01A frames mission-based interoperability analysis around operational processes and supporting technical capabilities. Its CIAV support-request process is not a CABE certification framework. [4]

The government publications supply context; the CABE drafts specify the mechanism. This proposed integration and its intended benefits are project analysis, with no claim of government adoption, endorsement or evaluation success.