ARCH-01 — Issuer-proof adapters, replay resistance, and immutable store configuration generations #826

New Issue

2026-07-22T19:43:54-05:00

jcwalker3 commented

2026-07-22 19:43:54 -05:00

Candidate architecture requiring executable validation; not yet approved, production-ready, or certified.

Parents: #820, #821. Depends on: #825 (evidence attestations/subjects).

1. Summary / objective

Specify and implement the issuer-proof adapter contract (store_signed_receipt, store_authenticated_response) and immutable store configuration generations, so an attestation is backed by a verified, store-originated, non-secret proof bound to the exact evidence identity and subject.

2. Security/correctness problem

Without a real store-originated proof, record_evidence reduces to a supervisor asserting a store attested. An attacker (or a buggy service) could store a correctly-shaped attestation for content the store never issued. The proof must bind store, generation, kind, reference id, content digest, subject kind, subject digest, and a nonce.

3. Threat model / failure modes

Forged/altered receipt; wrong store; stale generation; replay; expired proof; unavailable store treated as success; signing-key rotation gap; store-instance replacement reusing an id.

4. In-scope behavior — for each proof kind define

Canonical request and response payloads.
Store identity authentication (mutually-authenticated channel to endpoint_identity).
Signature algorithm and key selection (signing_key_id).
Exact signed/authenticated fields covering: store_id, config_generation, reference_kind, store_reference_id, content_digest, subject_kind, subject_digest.
Nonce / request id; replay prevention (UNIQUE(store_id,store_reference_id) + nonce).
issued_at, verified_at, expiry policy.
Failure/unavailability behavior (STORE_UNAVAILABLE, no attestation written).
Durable non-secret receipt (retain issuer_proof_digest).
Key rotation + overlap; store-instance replacement = new store_id.
Verifying service identity + session recorded.
Structured verification results.
All remote verification is [RUNTIME-ADAPTER]; the durable bound record is [SCHEMA].

Store configuration generations: immutable canonical content covering endpoint_identity, trust_anchor_set, signing_key_id, allowed_proof_algorithms, transport_auth_policy, verifier evidence; config_digest = sha256 over canonical content with config_canon_version; activation/retirement; store replacement. [SCHEMA] for storage + digest hex-shape; [TRUSTED-SERVICE] for canonicalization.

5. Exclusions

No evidence-record/subject schema (→ #825); no consumers.

6. Schema/operation contracts

trusted_evidence_stores, store_config_generations, evidence_reference_kinds; adapter interface verify_issuance(kind, request) -> {result, proof_digest, nonce, issued_at}. Operations: register_evidence_store, add_store_config_generation, revoke_evidence_store, attest_evidence_issuance.

7. SQLite behavior

Config-generation FK from attestation; bump stales prior records to issuance_stale; revoke → store_revoked (terminal, dominates stale).

8. PostgreSQL behavior

Same; adapter runs in the service; EXECUTE on adapter-invoking functions restricted to cp_service.

9. Concurrency / transaction requirements

Attestation write and adapter verification ordered so a failed/expired/replayed proof never yields a stored attestation; nonce uniqueness prevents concurrent replay.

10. Structured results

ATTESTED, ADAPTER_VERIFY_FAILED, STORE_UNAVAILABLE, PROOF_REPLAY, PROOF_EXPIRED, WRONG_STORE, WRONG_GENERATION, WRONG_KEY, SUBJECT_MISMATCH.

11. Enforcement classification

Remote verification [RUNTIME-ADAPTER]; bound durable record + digest shapes + immutability [SCHEMA]; canonicalization [TRUSTED-SERVICE].

12. Acceptance criteria

Proof binds all seven identity/subject fields + nonce.
Altered field → ADAPTER_VERIFY_FAILED.
Wrong store/generation/key → rejected.
Replay → rejected (nonce + unique).
Expired proof → PROOF_EXPIRED.
Unavailable store → STORE_UNAVAILABLE, no attestation.
Config generation identifies endpoint/keys/anchors; rotation stales prior records.
Config rows immutable; store replacement = new store id.

13. Named tests (adapter + schema)

t_proof_altered_field, t_proof_wrong_store, t_proof_wrong_generation, t_proof_replay, t_proof_expired, t_store_unavailable, t_proof_wrong_key, t_key_rotation_overlap, t_config_immutable(raw-bypass).

14. Audit events / evidence

issuance_attested, evidence_store_revoked, store_config_added. Retained non-secret receipt digests are durable evidence.

15. Dependencies / parent

Parents #820, #821; depends #825.

16. Definition of done

Adapter contract implemented and exercised by tests (altered/replay/expired/unavailable/rotation); store-config lifecycle executable; bounded PR; no self-review/merge.

17. Known limitations / deferred

Remote signature verification cannot be schema-enforced (category limit); readiness checks gate unattended evidence recording (G-SUPERVISOR, program-level).

**Candidate architecture requiring executable validation; not yet approved, production-ready, or certified.** Parents: #820, #821. Depends on: #825 (evidence attestations/subjects). ## 1. Summary / objective Specify and implement the issuer-proof adapter contract (`store_signed_receipt`, `store_authenticated_response`) and immutable store configuration generations, so an attestation is backed by a verified, store-originated, non-secret proof bound to the exact evidence identity and subject. ## 2. Security/correctness problem Without a real store-originated proof, `record_evidence` reduces to a supervisor asserting a store attested. An attacker (or a buggy service) could store a correctly-shaped attestation for content the store never issued. The proof must bind store, generation, kind, reference id, content digest, subject kind, subject digest, and a nonce. ## 3. Threat model / failure modes Forged/altered receipt; wrong store; stale generation; replay; expired proof; unavailable store treated as success; signing-key rotation gap; store-instance replacement reusing an id. ## 4. In-scope behavior — for each proof kind define - Canonical request and response payloads. - Store identity authentication (mutually-authenticated channel to `endpoint_identity`). - Signature algorithm and key selection (`signing_key_id`). - Exact signed/authenticated fields covering: `store_id`, `config_generation`, `reference_kind`, `store_reference_id`, `content_digest`, `subject_kind`, `subject_digest`. - Nonce / request id; replay prevention (`UNIQUE(store_id,store_reference_id)` + nonce). - `issued_at`, `verified_at`, expiry policy. - Failure/unavailability behavior (`STORE_UNAVAILABLE`, no attestation written). - Durable **non-secret** receipt (retain `issuer_proof_digest`). - Key rotation + overlap; store-instance replacement = new `store_id`. - Verifying service identity + session recorded. - Structured verification results. All remote verification is `[RUNTIME-ADAPTER]`; the durable bound record is `[SCHEMA]`. Store configuration generations: immutable canonical content covering `endpoint_identity`, `trust_anchor_set`, `signing_key_id`, `allowed_proof_algorithms`, `transport_auth_policy`, verifier evidence; `config_digest` = sha256 over canonical content with `config_canon_version`; activation/retirement; store replacement. `[SCHEMA]` for storage + digest hex-shape; `[TRUSTED-SERVICE]` for canonicalization. ## 5. Exclusions No evidence-record/subject schema (→ #825); no consumers. ## 6. Schema/operation contracts `trusted_evidence_stores`, `store_config_generations`, `evidence_reference_kinds`; adapter interface `verify_issuance(kind, request) -> {result, proof_digest, nonce, issued_at}`. Operations: `register_evidence_store`, `add_store_config_generation`, `revoke_evidence_store`, `attest_evidence_issuance`. ## 7. SQLite behavior Config-generation FK from attestation; bump stales prior records to `issuance_stale`; revoke → `store_revoked` (terminal, dominates stale). ## 8. PostgreSQL behavior Same; adapter runs in the service; `EXECUTE` on adapter-invoking functions restricted to `cp_service`. ## 9. Concurrency / transaction requirements Attestation write and adapter verification ordered so a failed/expired/replayed proof never yields a stored attestation; nonce uniqueness prevents concurrent replay. ## 10. Structured results `ATTESTED`, `ADAPTER_VERIFY_FAILED`, `STORE_UNAVAILABLE`, `PROOF_REPLAY`, `PROOF_EXPIRED`, `WRONG_STORE`, `WRONG_GENERATION`, `WRONG_KEY`, `SUBJECT_MISMATCH`. ## 11. Enforcement classification Remote verification `[RUNTIME-ADAPTER]`; bound durable record + digest shapes + immutability `[SCHEMA]`; canonicalization `[TRUSTED-SERVICE]`. ## 12. Acceptance criteria 1. Proof binds all seven identity/subject fields + nonce. 2. Altered field → `ADAPTER_VERIFY_FAILED`. 3. Wrong store/generation/key → rejected. 4. Replay → rejected (nonce + unique). 5. Expired proof → `PROOF_EXPIRED`. 6. Unavailable store → `STORE_UNAVAILABLE`, no attestation. 7. Config generation identifies endpoint/keys/anchors; rotation stales prior records. 8. Config rows immutable; store replacement = new store id. ## 13. Named tests (adapter + schema) `t_proof_altered_field`, `t_proof_wrong_store`, `t_proof_wrong_generation`, `t_proof_replay`, `t_proof_expired`, `t_store_unavailable`, `t_proof_wrong_key`, `t_key_rotation_overlap`, `t_config_immutable`(raw-bypass). ## 14. Audit events / evidence `issuance_attested`, `evidence_store_revoked`, `store_config_added`. Retained non-secret receipt digests are durable evidence. ## 15. Dependencies / parent Parents #820, #821; depends #825. ## 16. Definition of done Adapter contract implemented and exercised by tests (altered/replay/expired/unavailable/rotation); store-config lifecycle executable; bounded PR; no self-review/merge. ## 17. Known limitations / deferred Remote signature verification cannot be schema-enforced (category limit); readiness checks gate unattended evidence recording (G-SUPERVISOR, program-level).

jcwalker3 referenced this issue

2026-07-22 19:44:38 -05:00

ARCH-01 — PostgreSQL actor context, roles, privileges, and connection-pool safety #827

jcwalker3 referenced this issue

2026-07-22 19:45:52 -05:00

ARCH-02 — Transport identity authorities, external bindings, and reconciliation lifecycle #829

jcwalker3 referenced this issue

2026-07-22 19:48:33 -05:00

ARCH-04 — Global nodes, volume incarnations, exclusion domains, and isolation proofs #833

jcwalker3 referenced this issue

2026-07-22 19:51:24 -05:00

Architecture acceptance matrix — invariant, test, evidence, and backend traceability #837