Artifact families
-
identity - Ed25519 signatures and keys; trust-layer hashes use SHA-256.
-
attestation - Tagged COSE_Sign1 covering the payload’s SHA-256 hash and timestamp. Inspecting its fields does not verify its signature.
-
certificate - An Ed25519-signed X.509 certificate. An extension’s signed bytes need a separately defined interpretation; a signature alone is not an access decision.
-
checkpoint - A C2SP signed-note envelope over the log origin, tree size and root hash.
-
inclusion proof - A self-contained artifact for a raw leaf and a checkpoint, checked against a trusted signed-note verifier key.
-
consistency proof - Evidence that one tree extends an earlier tree, checked against the signed checkpoints.
-
sealed envelope - X25519, HKDF-SHA256 and AES-256-GCM, with the sender’s attestation verified before opening.
Signature and permission
A verified attestation without a certificate proves that the reported key signed that payload hash. Supplying a trusted issuer and certificate additionally checks the certificate and binds its subject key to the attestation signer.
Those checks do not, by themselves, decide a current product permission. Read certificate claims under their defined schema and use the relevant authority contract for access.
Log proofs
An inclusion proof concerns one raw leaf and a checkpoint. A consistency proof concerns extension between tree sizes. Trust in the checkpoint’s signing key must come from outside the disputed artifact; accepting a key merely because the same artifact supplies it is circular.
Frozen bytes
Signed and logged formats are versioned contracts. Wire formats records the raw leaf encoding and the distinction between artifact inspection and verification.