Anchoring Evidence Digests
Status: informative. This guide describes how an operator can register, timestamp, or checkpoint a PEAC evidence digest using an external transparency service, an RFC 3161 timestamp authority, a signed repository checkpoint, or another explicitly documented mechanism. It adds no normative requirement and no PEAC field. PEAC does not operate a log, a chain, or a timestamp authority; anchoring is an operator composition.
There is no universal anchor_ref field, no external-anchor record schema, and no canonical digest-only payload defined here.
What you can anchor
Three digest forms already produced by PEAC are suitable for external registration or timestamping. Each is a lowercase sha256:<hex64> string:
receipt_ref: the SHA-256 over a record's compact JWS bytes (@peac/schemacomputeReceiptRef).- dispute-bundle
content_hash: the SHA-256 over the JCS-canonical dispute-bundle manifest (@peac/auditcreateDisputeBundle/verifyBundle). receipt_merkle_root: a commitment over a sorted set ofreceipt_refs (@peac/auditbuildReceiptMerkleCommitment).
What each mechanism does and does not establish
External registration can establish inclusion, ordering, or time evidence depending on the chosen mechanism and its trust model. It does not establish the validity, completeness, authorization, or truth of the underlying PEAC record; verify the PEAC record independently.
| Mechanism | What the retained proof can establish | What it does not establish |
|---|---|---|
| SCITT Transparency Service (RFC 9943, receipts RFC 9942) | Verified registration or inclusion of the Signed Statement under the service's registration policy, receipt profile, and applicable log algorithm | Consistency between multiple log states, or the validity or truth of the PEAC record. A signed but invalid or unsupported proof is not successful verification |
| RFC 3161 timestamp authority | Evidence that the submitted message imprint existed no later than the authority's genTime, interpreted with the token's accuracy, policy, and trust model | Meaning, validity, authorization, settlement, or completeness of the PEAC record; and the exact time of the underlying interaction |
| Signed git tag | A signer authenticated a repository checkpoint or tag content | Independent trusted time, append-only history, or public transparency |
| Generic append-only log | Only the inclusion, ordering, consistency, or time properties its specific receipt or proof format defines | Any generic trusted-time or validity property not present in that proof |
Retain the external proof artifact itself (a SCITT receipt, an RFC 3161 token, a tag signature, or a log receipt), not only a URL or a transaction identifier. For long-lived timestamp evidence, also retain the certificate chain, policy identifier, token, and verification material; a token being present does not make its trust perpetual.
Digest handling: do not anchor the wrong bytes
A digest is not encryption. It does not expose the underlying bytes directly, but low-entropy or guessable inputs may be testable, and the digest remains a stable correlator across places it is registered.
- Validate the lowercase
sha256:<hex64>reference. - Preserve the digest kind (
receipt_ref, dispute-bundlecontent_hash, orreceipt_merkle_root); do not mix kinds. For a Merkle commitment, retain the complete commitment metadata (tree_alg,hash_alg,tree_size) and every inclusion proof the relying party needs. The bare root does not identify the tree algorithm, set size, or membership path. A valid inclusion proof establishes membership under the stated commitment algorithm; it does not establish chronology, completeness, privacy, payment finality, authorization, or legal validity. - For RFC 3161, decode the hex to the raw 32-byte SHA-256 digest and use the SHA-256 algorithm identifier in the
MessageImprint. Use a client API that accepts a precomputed message imprint. - Do not submit the UTF-8 bytes of the string
"sha256:<hex>"as though they were the raw digest, and do not let a client API hash the digest a second time unless that second hash is explicitly intended and documented. - If an external service wraps or re-hashes the value, retain the exact encoding and transformation description needed to reproduce it.
SCITT and RFC 3161 patterns
Two patterns compose PEAC with a SCITT Transparency Service (RFC 9943 / RFC 9942):
- Full-record registration. Place the compact PEAC JWS in the Statement payload of the RFC 9943 Signed Statement.
- Digest-only registration. Use an operator-defined Statement payload that binds the digest and its kind, then authenticate it as an RFC 9943 Signed Statement.
An inclusion proof shows registration in the relevant log state; it does not by itself show consistency or non-equivocation, which require the corresponding proof type or service mechanism. Before registration, assess the service's privacy and security posture; a digest hides bytes but remains a correlator, so submit only the minimum digest and type context the mechanism requires.
When verifying an RFC 3161 timestamp token, check that the token's message-imprint algorithm and digest bytes exactly match the submitted imprint, that the CMS signature verifies, that the signer is bound to its certificate (SigningCertificateV2 / ESSCertIDv2, preferred for algorithm agility), that the certificate path and policy are acceptable under the verifier's policy, and that the signing certificate carries id-kp-timeStamping as its sole, critical Extended Key Usage.
Boundary
PEAC does not anchor, host a log, operate a chain, or run a timestamp authority in its core. Anchoring is an operator composition: an operator submits a PEAC digest to a service it or a third party operates. The anchor's assurances are those of the chosen mechanism; they do not replace independent verification of each PEAC record.