// Dispatches / May 4, 2026

Introducing CABE: Open Specifications for Attribute-Bound, Data-Centric Encryption

Open specifications for attribute-bound, data-centric encryption. The first public drafts, a Go library, an interactive demo, and the reference Khaled key server are all released today.

Messier 42

CABE (Concise Attribute-Bound Encapsulation) is a new family of open specifications for encrypting data according to attribute-based policy. It is compact enough for very small messages, structured enough for interoperable systems, and designed for environments where trust boundaries are fragmented.

Most security architecture still assumes shared infrastructure: shared networks, shared gateways, shared trust. Real interoperability rarely works that way. Data moves across vendors, organizations, domains, and classification boundaries, often through systems you do not fully control. In those environments, protection has to travel with the data.

Today we are publishing the first public CABE drafts and opening the project to adopters, implementers, and collaborators. CABE is an open family of specifications for object-level encryption bound to attribute metadata and enforced through Attribute-Based Access Control. It is built for environments where information has to keep moving even when infrastructure trust is incomplete.

The premise is simple: encrypt the object, bind its attributes into the envelope, and let key access be governed by policy. Instead of depending on every intermediary to understand and enforce access rules correctly, CABE keeps the security context attached to the data itself. Systems can route, store, or relay protected objects without needing to see the plaintext.

CABE is also deliberately compact. The baseline envelope is built on COSE and CBOR rather than heavyweight archive containers, which makes the format practical across a wide range of payload sizes, from large objects down to very small units of data. That matters for machine-to-machine systems, message buses, edge workloads, and any environment where overhead is a real cost rather than a footnote.

What is in this release

The first public CABE release includes the three core drafts that define the foundation of the ecosystem.

  • CABE-ARCH defines the architecture: the attribute model, the relationship between clients and key servers, and the way the specifications fit together.
  • CBES, the CABE Baseline Envelope Structure, defines the protected envelope format used to encapsulate messages.
  • CKAP, the CABE Key Access Protocol, defines how CABE clients interact with a key server to resolve keys and access protected data according to policy.

These three drafts are the starting point. Two further specifications are already planned: a NATO ACP240 attribute mapping, and a messaging format for transporting large volumes of small protected messages efficiently.

What developers can use right now

Alongside the public drafts, we are releasing a CABE Go library. The goal is to give implementers a practical starting point: safe attribute-set handling, CKAP client operations, managed encapsulation and decapsulation, and utilities for inspecting CBES envelopes. It is meant to turn the specification into working systems faster than reading the drafts alone would allow.

We have also built an interactive CABE demo. It simulates coalition message routing through an unclassified datacenter, shows how attribute-labeled messages are evaluated against policy, and lets people change policy live and watch decisions flip in real time. Policy evaluation runs in-browser using Cedar via WebAssembly. It is a demo, not a production cryptosystem, but it has been the most direct way to make the model legible to engineers and non-specialists.

Rounding out the release, we are also publishing Khaled, the reference CABE Key Server implementation. Khaled stands for Key Handling Attribute/Lease Encryption Daemon. It is licensed under Apache 2.0, ships with a Helm chart for Kubernetes deployments, and implements the architecture and key access protocol defined in the CABE drafts. The specifications are not just drafts; they are running code.

Process matters as much as code. CABE is being developed in the open. The specification drafts are public. Discussion is public. The point is not to produce another closed format that others have to reverse-engineer from behavior, but to build an interoperable ecosystem that can be reviewed, implemented, challenged, and improved.

CABE is not a replacement for transport security, and it is not a policy engine in its own right. It is a compact, data-centric framework for protecting objects so that access control survives transit, storage, and federation across imperfect trust boundaries. If you are building systems where data has to cross domains, organizations, or classification contexts without losing its security posture, this is the problem CABE is designed to address.

Now is a good time to get involved. Read the drafts at cabespec.org. Try the demo. Pull the Go library. Run Khaled. Bring requirements from the field. The strongest standards are the ones shaped in public, with operational feedback in the loop early.