Hypermedia Security: Case Catalog Integrity Specification
v1.0.0Hypermedia Au
Case Catalog Integrity (complete enumeration + hashes recomputed at seal)
The catalog-integrity attestation: one per seal, the signed statement that the catalog version produced by that seal is complete (every artifact in the corpus is enumerated) and hash-true (every content hash recomputed from the Vault bytes and matched at the moment of sealing). Where custody-chain/v1 testifies to the case's history, case-catalog/v1 testifies to the snapshot — together they are the two attestations the Case Provenance BOM carries. Named case-catalog to remain distinct from the deployment-pipeline catalog-integrity standard in this authority.
Machine attestation: /attestations/case-catalog/v1
Relationships
References
- target-standard →Hypermedia Security: Case Provenance BOM Specification
- target-standard →Hypermedia Security: Timestamp Token Specification
- references →Hypermedia Security: Case Provenance BOM Specification
Referenced by
About this standard
- artifact-kind
- attestation (declarations document; one per seal)
- claim-predicate
- catalog-integrity-verified
Sources
- www.iso.org
- ISO/IEC 27037:2012 — §5.4.4: original and copy verified with a proven verification function producing the same output (the hash-recomputation duty behind #hash-at-seal); §6.1 custody record identity/integrity — verified against the standard text 2026-07-11 (SPEC-5 note)
- www.iso.org
- ISO/IEC 27043:2015 — §11.3: each process performed should be documented to assure repeatability/reproducibility and preserve chain of custody — the concurrent-documentation duty a per-seal integrity attestation discharges; verified against the standard text 2026-07-11 (SPEC-6 note)
- cyclonedx.org
- CycloneDX 1.7 — the JSF signature definition verified for the seal-signature row (SPEC-6)
- www.rfc-editor.org
- RFC 2119 (as clarified by RFC 8174) — requirement key words; only capitalised forms are normative
- sec.hypermedia.au
- website
CCAT-001 Target MUST
The attestation MUST carry exactly one claim whose target is the sealed Case Provenance BOM version by BOM-Link and paired hash, and whose predicate is catalog-integrity-verified. One attestation MUST be issued at every seal — one per catalog version.
The claim binds the verification to one specific sealed version: 'the catalog is intact' is meaningless without saying which catalog, at which seal. The predicate is a stable machine identifier from the locked v1.0.0 vocabulary.
- predicate
- catalog-integrity-verified
- cardinality
- one-per-seal
CCAT-002 Complete Enumeration MUST
At the seal, every artifact in the case corpus MUST appear as a component of the sealed catalog. The attestation MUST record the enumeration check as evidence; any artifact present in the Vault but absent from the catalog MUST abort the seal.
Completeness is what turns the catalog from a list into an index of record: a verifier who trusts this attestation knows the sealed components array is the whole corpus, not a selection. ISO/IEC 27043 §11.3's concurrent-documentation duty — each process documented to preserve custody — is discharged per seal by exactly this check.
- iso-basis
- ISO/IEC 27043 §11.3
CCAT-003 Hashes Recomputed At Seal MUST
At the seal, every content hash enumerated in the catalog MUST be recomputed from the Vault bytes and matched against the catalog's value. A single mismatch MUST abort the seal. The attestation MUST record the hash-check outcome as evidence.
This is ISO/IEC 27037 §5.4.4's verification-function duty applied at every checkpoint: the original and the record produce the same verification output. It is also what makes hash-only artifact entries safe — the seal is the moment their hashes are proven against the actual bytes, batch-wide.
- iso-basis
- ISO/IEC 27037 §5.4.4
CCAT-004 Seal Signature Verified MUST
The sealed catalog's JSF signature MUST verify against the Fulcio root and certificate chain at the time of attestation.
The integrity claim covers a signed object: attesting a catalog whose own seal does not verify would be attesting the wrong bytes. The signature mechanics are governed by case-provenance/v1 (#seal-signature); this row is the independent re-check of them.
CCAT-005 Operator Identity MUST
The catalog's metadata.authors[] MUST match the identity in the sealing certificate, and the attestation's assessor MUST be that same identity. All identity comparisons MUST be made between Fulcio-verified identities, never name strings.
The sealing operator attests their own seal — this is the snapshot check, not maker-checker (which applies to findings and publications, where a second identity signs). What this row proves is that the name on the record and the key that sealed it are the same actor, per ISO/IEC 27037's handler-attribution duty.
- iso-basis
- handler attribution — ISO/IEC 27037 §6.1 (synthesis, per SPEC-5 note)
CCAT-006 External Seal Anchor SHOULD
The seal's RFC 3161 token SHOULD exist in the sidecar index and verify per timestamp-token/v1 at the time of attestation. Where the token is not yet available (intermittent connectivity), the attestation MUST record that the anchor is pending.
SHOULD, not MUST, because the token is obtained from an external service moments after sealing — the attestation may be produced before the round-trip completes. The token remains mandatory at the timestamp-token/v1 level; this row is about whether the catalog-integrity assessor could already verify it.
- level
- SHOULD
- target-standard
- https://sec.hypermedia.au/standards/timestamp-token/v1