open-standards/sandbox/conformance/README.md
Transaction Science ba1212361f Add aac, map, sandbox standards; catalog the standards family
Commit the previously-untracked standard directories and catalog them in the
root README alongside proof:

- aac/    — communication cargo class: portable boards + a ten-level
            offline-first cascade (Apache-2.0 code / CC-BY-4.0 spec).
- map/    — geospatial cargo class: range-requestable signed tilesets +
            an F0–F4 fidelity cascade (Apache-2.0 code / CC-BY-4.0 spec).
- sandbox/— isolated, metered, attested execution across the heterogeneous
            compute fabric (Apache-2.0 code / CC-BY-4.0 spec).
- jouleclaw-otel-authz, jouleclaw-trust — new jouleclaw reference crates.

Root README now lists aac, map, sandbox, and proof in the catalog, the tree,
and the contribution guide.

Co-Authored-By: Claude Opus 4.8 <[email protected]>
2026-06-07 17:04:36 -04:00

3.8 KiB
Raw Permalink Blame History

Sandbox conformance vectors

Signed, content-addressed wire vectors for the Sandbox standard (SPEC §10, ../spec/conformance.md). An implementation is conformant for the tiers it advertises if it round-trips these vectors with no skips.

The vectors are the authority. They are not illustrative: each is a real, cryptographically computed value, and the reference harness recomputes every content address, sealed JCR-1 envelope, and Ed25519/JCS signature and checks it against the committed file. A change to wire behaviour MUST regenerate the vectors and note it in VERSIONS.md.

Layout

conformance/
├── README.md        — this file
├── VERSIONS.md      — vector-set changelog
└── v1/              — the v1 vector set
    ├── content_addressing.json   — C1: bytes → BLAKE3 content id
    ├── capability.json           — C2: grant set → allow/deny decisions (incl. negatives)
    ├── receipt.json              — C3: per-device receipt → core, content id, sealed JCR-1 envelope
    ├── attestation.json          — C4: attestation → JCS bytes, content id, Ed25519 signature
    ├── tier.json                 — C5: grant set + flags → required tier
    ├── negative.json             — C-neg: malformed receipts + attestations a host MUST reject
    └── confidential.json         — C-tee: SEV-SNP report verification + audit-chain vectors

Vector classes

  • C1 — canonicality. Content addressing (b3: + base64url over BLAKE3-256) is byte-stable.

  • C2 — capability enforcement. The deny-by-default Enforcer returns the fixed decision for each query, including the negatives (ungranted device class, read-only path written, wrong port).

  • C3 — receipt integrity. The per-device records sum to the total; the (provenance, measured_uj) coupling holds; the sealed JCR-1 envelope verifies under the committed steward key and matches the canonical core.

  • C4 — attestation. The core canonicalizes to the fixed JCS bytes and verifies under the committed supervisor key; the device classes match the receipt's.

  • C5 — tier minimization. Each grant set + flag combination resolves to the lowest satisfying tier (S0–S7).

  • C-neg — adversarial negatives. negative.json holds malformed artifacts a conformant host MUST reject: a HwShunt reading with no measured figure, an Estimator carrying one, a total that does not equal the device sum, a measured-coverage mismatch, an attestation that omits an accelerator the receipt metered (SPEC §7.2), an S6 attestation without TEE evidence (SPEC §7.6), a replay journal that diverges and one that is truncated (SPEC §8), and a mid-run grant-set mutation whose content address changes (SPEC §1.2). The harness asserts each is rejected or detectable.

  • C-tee — confidential + sovereign. confidential.json carries SEV-SNP report vectors — a valid report that verifies against policy + VCEK, plus negatives (wrong launch measurement, tampered body that fails the ECDSA-P384 signature) — and a hash-chained audit-log vector that must verify (SPEC §7.6, §7.7).

Negatives are what a standard certifies; growing this set (tier-minimization violations, anti-evasion probing) is the highest-value contribution here — see ../CONTRIBUTING.md.

Regenerating and verifying

cd ../sandbox-rs
cargo run -p sandbox-conformance --bin gen_vectors   # rewrite conformance/v1/*.json
cargo test -p sandbox-conformance                    # verify in-code + file-backed
cargo run -p sandbox-cli -- conformance              # human-readable pass/fail

Ed25519 signing is deterministic (RFC 8032), so the signatures are reproducible known answers: regenerating on an unchanged reference produces byte-identical files.