References and appendices

29. References

• [SSP-1] — The Sovereign Synchronization Protocol, published on this site. Two further internal memos — a systems comparison and an implementation retrospective — informed this specification but are unpublished; their implementer-relevant content is folded into the published text and into SSP/1’s limitations.

• [RFC9420] — Barnes, R., et al. “The Messaging Layer Security (MLS) Protocol.” RFC 9420.

• [RFC9052] — Schaad, J. “CBOR Object Signing and Encryption (COSE): Structures and Process.” RFC 9052.

• [RFC9053] — Schaad, J. “CBOR Object Signing and Encryption (COSE): Initial Algorithms.” RFC 9053.

• [RFC8949] — Bormann, C. and P. Hoffman. “Concise Binary Object Representation (CBOR).” RFC 8949.

• [OPENMLS] — OpenMLS. Rust implementation of RFC 9420 and OpenMLS Book.

• [PARQUET-ENCRYPTION] — Apache Parquet. Parquet Modular Encryption specification.

• [PADME] — Nikitin, K., et al. “Reducing Metadata Leakage from Encrypted Files and Communication with PURBs.” Proceedings on Privacy Enhancing Technologies, 2019.

• [DUCKDB-PARQUET-ENCRYPTION] — DuckDB. Parquet Encryption documentation.

• [IROH] — iroh project documentation.

• [DELTA] — Delta Lake protocol specification.

Appendix A. Responsibility Matrix

Concern	Owner
Stable node identity	SSP
Human pairing policy	SSP
Vouching	SSP
Node roles	SSP
Table/domain scope	SSP
Admission decision	SSP
Removal decision	SSP
Group membership crypto	MLS / OpenMLS
Group epoch transition	MLS / OpenMLS
Control-message crypto	MLS PrivateMessage
Domain KEK distribution	MLS PrivateMessage + SOP application key
Historical key policy	SOVM SOP
COSE key/sign containers	RFC 9052/9053 + SOVM profile
Per-object DEK	SOVM SOP
Parquet encryption	PME
Encrypted object ID	iroh-blobs BLAKE3 hash (Section 11.7)
Object semantics	SOP
Mutable row convergence	SSP/1
Live transport	iroh
Large-object transport	iroh-blobs
Async mailbox	SSP mailbox
Local analytics	DuckDB / host engine
External lakehouse view	Delta Lake projection (Phase 5)

The important boundary is:

SSP decides membership and scope.
MLS makes membership cryptographically real and securely distributes
application KEKs.
COSE standardizes SOP key/signature records.
PME makes stored analytical data cryptographically private.
iroh-blobs defines the canonical object hash and verified byte transfer.

Appendix B. Privacy Invariants

A conforming production SOP implementation MUST preserve the following invariants.

1. Canonical SOP analytical objects are PME-encrypted.
2. PME encrypted-footer mode is used for SOP-PME-1.
3. All columns are encrypted in SOP-PME-1.
4. Every object receives a fresh random DEK.
5. Untrusted storage never receives an unkeyed plaintext content hash as the object identifier.
6. Semantic key names do not appear in PME key_metadata.
7. Every SOP-PME object uses a fresh random non-semantic AAD prefix.
8. Wrapped DEKs and semantic object metadata are protected from untrusted storage.
9. Cryptographic domain membership does not exceed SSP-authorized scope.
10. Out-of-scope nodes do not receive applicable domain-group secrets.
11. Historical access for a newly added node is explicit.
12. Obsolete MLS protocol secrets are not retained merely for historical lake access.
13. Historical SOP keys are protected separately under node-local encrypted storage.
14. Iroh sees already-encrypted bulk object bytes.
15. The SSP relay sees opaque MLS/SOP ciphertext, not user plaintext.
16. Query and compaction paths do not intentionally persist plaintext scratch files.
17. Production debugging does not expose user plaintext or key material.
18. Node removal blocks future epoch secrets and future accepted publication.
19. The product does not claim retroactive forgetting by an already compromised authorized node.
20. Plaintext export to an incompatible external lakehouse is explicit user release, not transparent replication.
21. Full-disk encryption is defense in depth, not the sole protocol privacy guarantee.
22. Loss of all MLS protocol state is never data loss provided at least one recoverable copy exists of the SOP ciphertext, its immutable ObjectManifest plus applicable AccessRecord state, and the necessary application KEK history (Section 12.7); recovery is rooted by RecoveryRoot and, when MLS state itself is lost, completed by the domain genesis reset (Section 22.10).

---

Appendix C. Example Lifecycle

Consider four nodes:

Symbol	Node
L	laptop
P	phone
H	home server
K	kitchen hub

SSP policy:

flowchart LR
  accTitle: Domain membership in the worked example
  accDescr: The control group holds all four nodes, the health domain holds the laptop and phone, and the finance domain holds the laptop and home server.
  CONTROL --- L
  CONTROL --- P
  CONTROL --- H
  CONTROL --- K
  HEALTH --- L
  HEALTH --- P
  FINANCE --- L
  FINANCE --- H

C.1. Create a health object

Phone P is a current HEALTH MLS member and holds HEALTH KEK generation 4.

It records 100,000 heart-rate rows.

flowchart TD
  accTitle: Creating an object on an authorized producer
  accDescr: Rows become Parquet, are encrypted under a fresh random data key, and the resulting object yields a content hash, a producer-signed manifest, an access record wrapping the data key under the current domain key generation, and an encrypted catalog entry.
  rows[rows] --> parquet[Parquet]
  parquet --> dek["random DEK D1"]
  dek --> enc[PME encrypt]
  enc --> obj["object O1"]
  obj --> sid["storage_id = iroh-blobs hash(O1)"]
  obj --> man["COSE_Sign1_producer(ObjectManifest)"]
  obj --> acc["COSE AccessRecord(D1, K_gen4)"]
  obj --> pub[encrypted catalog-entry publication]

O1 may be copied to L, H, or blind archive storage.

H may store O1 without receiving HEALTH decryption membership if policy allows blind storage.

C.2. Phone goes offline

P remains on an older HEALTH MLS state.

L and H continue operating.

If no membership-security transition occurs, P can reconnect, process ordinary MLS updates, confirm that HEALTH KEK generation 4 remains current, create publication wrappers for unpublished DEKs, and publish. Routine MLS epoch advancement does not create a new HEALTH KEK generation.

C.3. Phone is removed

While P is offline, the user removes P.

SSP authorizes removal.

L submits an MLS Remove/Commit for HEALTH through the blind Commit sequencer. Once the removal becomes canonical, L — as the accepted committer and therefore the unique generator (Section 7.3) — creates a fresh random HEALTH KEK generation 5 and distributes it over MLS.

flowchart LR
  accTitle: Key generation advance on node removal
  accDescr: Removing a node advances the domain key generation, so the removed node holds only the superseded generation.
  g4["KEK generation 4"] -->|"REMOVE P"| g5["KEK generation 5"]

Newly published health objects use generation-5 COSE AccessRecords.

P never receives K_health_gen5.

When P reconnects, its newly introduced manifests/access records are rejected because the site has been removed, regardless of which MLS epoch or KEK generation they reference.

C.4. New phone joins

New node N passes SSP pairing, vouching, and human confirmation.

N is added to CONTROL and HEALTH.

If policy is FORWARD_ONLY, N receives current HEALTH access only.

If policy is FULL_HISTORY, an authorized existing member sends N a COSE-signed historical key package inside an authorized confidential channel containing the retained application KEKs needed to decrypt historical HEALTH objects.

MLS itself is not forced to retain old epoch protocol state for this purpose.

C.5. Compaction

L compactly rewrites 50 historical encrypted objects and their logical delete objects.

It decrypts authorized source modules, applies deletes, creates a new Parquet file, generates random DEK D2, PME-encrypts it, and publishes O2.

O2 receives a new ciphertext storage ID.

O2’s immutable producer manifest records the superseded source set; its access record independently grants current-domain decryption.

Only after retention, synchronization, purge, and the supersession verification-or-dispute-window precondition of Section 18.5 permit may the old ciphertext objects be garbage-collected. If H is a fully entitled second replica, its signed verification attestation of O2 satisfies the precondition early; otherwise the configured dispute window applies.