Skip to content

Normative · Part

Compatibility, migration and operations

SOP/1 does not alter SSP event merge rules.

Migration from SSP row replication to SOP object replication is explicit and per table. A table moves between the layers by a deliberate act, never by reinterpretation: SSP/1 state MUST NOT be silently re-read as SOP-PME-1 objects, and downgrade rules MUST be explicit and fail closed where security requires the object plane’s mode.

MLS reduces bespoke cryptographic protocol but introduces group-state operations, durable sensitive storage, Welcome/Commit delivery, and fork handling.

This is a desirable trade if the implementation is robust.

Too many cryptographic domains create:

  • excess group state;
  • excess KeyPackages;
  • more membership commits;
  • more key history;
  • more mobile persistence.

Domain count SHOULD therefore remain small and policy-driven.

Historical application KEK storage grows with security-relevant KEK generations, not with object count or routine MLS Commit count.

Because removals, compromise responses, and forward-only admissions should be rare, this should remain small.

There may be many object DEKs.

Only wrapped DEKs need persistent catalog storage; the unwrapped keys SHOULD be short-lived in memory.

Current DuckDB encrypted-Parquet support has non-trivial performance overhead relative to plaintext Parquet.

This MUST be benchmarked on representative hardware and data before final object-size targets are chosen.

The dominant background cost is expected to remain read/decrypt/rewrite/ reencrypt compaction rather than MLS operations.

A user adding/removing a node may need to wait for control-plane group state to converge before the new security state is effective across online peers.

That is acceptable for rare security-control operations.