RFC: Bounded-offline key access for disconnected / DIL tactical deployments

[cursor]

OpenTDF RFC Issue Draft — Bounded-Offline Key Access

Draft for upstream submission. File as a GitHub issue on
opentdf/spec or opentdf/platform
when ready (target: M3–M4).

---

Title

RFC: Bounded-offline key access for disconnected / DIL tactical deployments

Summary

Propose a standard extension to OpenTDF that allows authorized clients to
decrypt TDF-protected data during bounded periods when the Key Access Server
(KAS) is unreachable, with cryptographically enforced expiry and a clean
revocation path on reconnection.

This addresses a gap explicitly noted in the public spec: offline / disconnected
operating modes are out of scope today, yet tactical and edge deployments
routinely face partitions, high RTT, and intermittent backhaul.

Motivation

• OpenTDF's decrypt path requires live KAS reachability for DEK rewrap.
• DoD Zero Trust (Data Pillar) and programs like Project Olympus push
  data-centric protection to the tactical edge.
• Authorized users are currently denied access to data they are entitled to
  whenever the KAS is unreachable — a availability failure, not an authorization
  failure.

We are not proposing silent fork or replacement of existing modes (ZTDF,
IC-TDF, nanoTDF). We seek an optional, bounded extension compatible with
custom PEP architecture already documented by OpenTDF.

Proposed approach (sketch)

Threshold (t-of-n) key release across mesh peers:

1. Pre-release (connected): KAS splits the per-object DEK into n Shamir
   shares; issues one KAS-signed grant per peer, each binding share + attributes
   • expires_at.
2. Offline decrypt (partitioned): Client gathers t verified grants from
   reachable peers, reconstructs DEK locally after re-checking entitlement.
3. Reconnect: KAS pushes signed revocation deltas; clients purge stale
   offline material.

Security properties: no single edge node holds the full key; expiry and
revocation are KAS-signed; < t shares reveal nothing.

Reference implementation

Work-in-progress reference implementation (research, not production):

• Repository: edge-tdf (link TBD public)
• Modules: threshold split (GF(2^8) Shamir), KAS-signed grants (RSA-PSS),
  mesh share exchange, reconnect revocation sync, native ZTDF reader
• Testbed: Docker baseline pinned to service/v0.15.0; CORE+EMANE evaluation planned

Questions for the working group

1. Should bounded-offline be a KAS PEP extension, a client SDK profile, or
   both?
2. What is the preferred grant format — extend existing KAS rewrap responses
   or a new ShareGrant payload?
3. How should revocation deltas integrate with existing policy update /
   notification mechanisms?
4. Is there interest in standardizing (t, n) policy alongside classification
   attributes?
5. Relationship to non-public variants (ZTDF, IC-TDF) — complementary or
   convergent?

Non-goals

• Replacing online KAS decrypt (online-first remains default)
• Unbounded offline access
• New cryptographic primitives
• Cross Domain Solution / accreditation claims

References

• OpenTDF architecture (custom PEP extension point)
• Edge-TDF threat model and evaluation plan (attached when filing)
• NSA Zero Trust Implementation Guide Phase 2 (Jan 2026) — TDF endorsement

---

Filing checklist

• Review against latest opentdf/spec main
• Attach link to reproducible Docker baseline (make smoke)
• Attach threat model summary (1 page)
• Confirm licensing / export posture for public reference impl
• Post to spec repo; cross-link platform repo if implementation-track issue needed