Evidence Verifier Specification

Artifacts you can verify

Signed audit pack

A JSON bundle exported from Evidence Lineage. Contains sealed day roots, artifact fingerprints, lineage hops, a manifest hash, and a detached signature. Downloaded as RhindonCyber_SignedAuditPack_<date>.json.

Sealed day root

One SHA-256 value per organization per day, computed overnight over that day's ledger entries. A day root is fixed once sealed.

Continuity certificate

A signed statement that an organization has maintained an unbroken sealed evidence history through a 1, 3, or 5 year milestone. Exportable as PDF or DOCX, with the certificate hash printed on the document.

Hashing scheme

All digests are SHA-256, lowercase hexadecimal, 64 characters. Every ledger entry carries a digest computed over the canonical serialization of the event fields together with the digest of the entry immediately before it, which chains the entries into one continuous sequence per organization. A day root is the digest computed over that day's ordered entry digests, joined with a single vertical bar character | between consecutive digests, in ledger sequence order, and hashed as UTF-8 text with no trailing separator (separator stated in text v1.3). A manifest hash is the digest over the canonicalized pack manifest — the day roots, artifact fingerprints, and lineage hops it asserts. Canonicalization uses UTF-8 encoding with object keys sorted lexicographically and no insignificant whitespace, so any two implementations that follow this rule produce byte-identical input and therefore identical digests.

Merkle day roots (RAIC-MERKLE-1), specification text v1.3

Alongside the day root described above, each sealed day also carries a Merkle commitment over the same ordered entry digests. This is an additive extension: the day root itself is unchanged and remains the authoritative seal, and a verifier that ignores the Merkle value still verifies correctly. The Merkle value exists so a single ledger entry can be proven to belong to a sealed day without disclosing the rest of that day. Text version 1.1 clarified wording and added the leaf-count rule below; version 1.2 added the external timestamp section that follows; version 1.3 names the inclusion-proof sibling field. None of them changes any computed value, so every root sealed under the earlier text still verifies unchanged.

• Leaf digest: SHA-256 of the ASCII string RAIC-MERKLE-1:leaf: followed by the entry digest.
• Internal node: SHA-256 of RAIC-MERKLE-1:node: followed by the left digest, a colon, and the right digest.
• A level with an odd number of nodes promotes the trailing node unchanged to the next level; nothing is duplicated. Duplicating the trailing node instead would let two different day contents produce the same root, so a verifier must reject that construction.
• A day with no entries has no Merkle root.
• An inclusion proof carries the entry digest, its position, the number of leaves, and the sibling digest at each level with the side it sits on. Each step is an object whose sibling digest is in the field named sibling and whose side is in the field named side, with the value left or right describing where the sibling sits (field names stated in text v1.3; readers must also accept hash as a deprecated alias for sibling). Recompute upward from the leaf and compare the result with the sealed Merkle root.
• Leaf-count binding: when the sealed day records a leaf count, a proof whose leaf_count disagrees with it must be rejected before any digest is recomputed. A proof that verifies against a different tree shape is not a proof of inclusion in the sealed day.
• Root provenance: a sealed day reports whether its Merkle root was committed at seal time or recomputed during backfill. Both verify identically; the label exists so an auditor can tell which days were commitments made on the day and which were reconstructed from sealed entries afterwards.
• The public endpoint accepts either commitment in day_root, and returns merkle_root and merkle_spec when a sealed day matches.

External timestamps (RFC 3161), added in specification text v1.2

A RAIC seal establishes what a day contained. It does not, on its own, establish when that content existed, because the sealing time is recorded by RAIC. To close that gap, sealed day roots are submitted to an independent timestamp authority, which returns a signed token binding the root to a time the authority attests to. Anchoring is additive: a day with no anchor is still sealed and still verifies, and the verifier says plainly which of the two it is looking at rather than treating an unanchored day as anchored.

• What an anchor asserts: an outside authority saw this exact day root at or before the stated time. It says nothing about whether the underlying events are true or complete — those are separate claims the ledger and the day root carry.
• What an anchor does not assert: it does not prove the root existed no earlier, it does not re-verify the day's contents, and it does not extend to days absent from the anchor list.
• Where anchors appear: signed packs from manifest version 3 onward carry an external_anchors section listing one entry per anchored day — day, root hash, anchor time, authority serial, and the base64 timestamp token itself.
• Offline validation: the token is bundled with the certificate chain the authority returns, so an examiner can validate it with standard tooling and no network access. Check the token's message imprint equals the day root, then validate the token signature against the certificates embedded in the token. Chain completeness differs by authority and is stated plainly rather than assumed (text v1.4): one shipped authority embeds its own self-signed root, so its token validates entirely offline but its root must be trusted out of band; the other embeds a chain terminating at a widely distributed public root, so the final anchor comes from the examiner's own trust store. Both are complete in the sense that matters — no certificate must be fetched — and neither asks you to trust a root shipped inside the evidence.
• Reading a token: the authority's own signing digest is not fixed by this specification and differs between the shipped authorities (SHA-256 with RSA, SHA-512 with ECDSA). Read the digest and signature algorithms from the token's SignerInfo rather than assuming SHA-256. The serial to compare against the pack is the serialNumber field of TSTInfo, not any other integer in the token (stated in text v1.4).
• Unanchored and failed days: a day whose anchoring did not succeed is reported as unanchored or failed and never silently omitted, so coverage is visible rather than assumed.

Versioning and frozen text

The computation format is identified by the string RAIC-MERKLE-1 and does not change. The prose that describes it is versioned separately so clarifications can be published without disturbing verifiers. If a future change ever altered a computed value, it would be published under a new format identifier rather than as a revision here. From manifest version 4 onward, every signed pack states the specification text version it was produced under in a spec_version field, so a verifier reads the governing text from the pack rather than inferring it. Packs sealed before that field existed are covered by version 1.0 semantics by construction, because no version since has changed a computed value.

• Current specification (this page): /support/verifier-spec, specification text v1.3.
• Frozen Version 1.0 text, never edited: /support/verifier-spec/v1.
• Frozen text version 1.1, never edited: /support/verifier-spec/v1-1.
• Independent verifier for offline and CI use: /support/auditor-kit, and verify.html is bundled inside every signed pack.

Corrections published in specification text v1.4

Version 1.4 records two further points, found by extending the independently written verifier to validate the RFC 3161 tokens themselves rather than trusting the fields the pack records about them. Both are clarifications of prose: no computed value changes, and every pack sealed under earlier text verifies unchanged.

• Chain completeness is stated per authority. The earlier text said a token is bundled complete with its certificate chain; that is exact for an authority embedding its own self-signed root, and imprecise for one whose chain terminates at a public root supplied by the examiner's trust store.
• The authority's signing digest is stated to vary and must be read from the token's SignerInfo, and the comparable serial is stated to be TSTInfo's serialNumber.

Corrections published in specification text v1.3

Version 1.3 records five points where the earlier text was insufficient to write a correct verifier without reading RAIC source. Each was found by writing a second verifier, in another language, from this page alone, and each is a clarification of prose only: no computed value changes, and every pack sealed under 1.0, 1.1, or 1.2 verifies unchanged.

• The linear day root's separator is stated: entry digests are joined with a single | character. Previously the text said only that the root is computed over the ordered digests.
• The inclusion-proof step fields are named sibling and side. Previously the text named the values but not the field names, and readers must still accept hash as a deprecated alias.
• The signature encoding is stated as base64url, unpadded, with standard base64 accepted on read.
• The signed message is stated: the 64-character lowercase hexadecimal text of the manifest hash, UTF-8 encoded — not the 32 raw digest bytes.
• The ECDSA signature is stated as 64-byte IEEE P1363 r||s, with ASN.1 DER accepted on read.

Signature format

Manifests and continuity certificates are signed with ECDSA over the NIST P-256 curve using SHA-256 as the digest. The signature is detached: it is computed over the manifest hash (or certificate hash) rather than the whole document, so a verifier recomputes the hash from the payload, then checks the signature against that hash. The signed message is the hexadecimal text of that hash, UTF-8 encoded, not its raw bytes. The signature itself is 64 bytes of IEEE P1363 r||s, encoded base64url without padding; a reader should also accept standard base64 and ASN.1 DER (encodings stated in text v1.3). The active signing key is identified by the fingerprint 9a9980482b19bbc86b354122020c95c2, which the verification endpoint returns on every response so you can confirm which key was used.

Public verification endpoint

The endpoint is open, requires no account or API key, sends permissive CORS headers, and returns non-identifying facts only — never organization names, actors, artifacts, or personal data.

• GET https://app.rhindoncyber.com/api/public/verify-evidence?manifest_hash=<64-hex>
• GET https://app.rhindoncyber.com/api/public/verify-evidence?day_root=<64-hex>
• POST the same path with a JSON body of { manifest_hash, day_root, signature } — supply at least one hash.
• Include signature alongside manifest_hash to have RAIC check the detached signature for you; the response then carries signature_valid as true or false rather than null.
• Hashes must be 64-character lowercase SHA-256 hex. Anything else returns HTTP 400 with an explanatory error.

Reading the response

found

True when RAIC recorded the hash you supplied. False means the artifact was not produced by RAIC, or its contents were altered after export so the recomputed hash no longer matches.

kind

Which artifact matched: manifest, day_root, or certificate.

signature_valid

True or false when you supplied a signature; null when you did not. This is an independent cryptographic check, not a database lookup.

signing_key_fingerprint

The fingerprint of the key RAIC currently signs with — compare it to the published key you hold.

Verifying offline

Nothing in the scheme requires network access. An auditor working from an archived pack can reproduce every check locally.

• Canonicalize the manifest as described above and compute its SHA-256 digest; it must equal the manifest hash printed in the pack.
• Verify the detached base64 signature over that digest with the published P-256 public key, using ECDSA with SHA-256.
• For each artifact listed in the pack, hash the corresponding evidence file and compare it to the fingerprint recorded in the manifest.
• For each sealed day cited, recompute the day root from the ordered entry digests supplied in the pack and compare it to the recorded root.
• A break at any step localizes the problem: a manifest mismatch means the pack was edited, an artifact mismatch means a file was replaced, and a day root mismatch means underlying history changed after the seal.

Verifying a continuity certificate

A continuity certificate asserts an unbroken run of sealed days through a milestone. Verification is the same two-step check: recompute the certificate hash over the canonicalized certificate payload, then verify the signature over that hash. Submit the certificate hash to the public endpoint to confirm RAIC issued it. Certificates deliberately exclude tenant-internal detail — no ledger volumes, no gap dates, no record counts — so they can be shared with a prospect, a regulator, or an insurer without disclosing operational data.

What verification does not claim

Verification proves integrity and origin, not correctness of judgment. A passing pack tells you that the record you are reading is the record RAIC sealed at the time it claims, that it was signed by the RAIC evidence key, and that no entry, artifact, or day has been altered since. It does not assert that the governance decisions inside were sound, that a control is effective, or that the organization is compliant with any framework. Those remain the assessor's conclusions.

Telemetry and privacy

Each lookup records an anonymous adoption event: the artifact kind, whether it matched, and a coarse client descriptor. No organization identity, no requester identity, and no hash contents leave that record in a form that identifies a tenant. Telemetry never blocks or changes the outcome of a verification — if recording fails, verification still returns normally.

Getting the public key

The signing public key is published on request to auditors and examiners; contact [email protected] with the key fingerprint shown in your pack. Verify the fingerprint you receive against signing_key_fingerprint from the endpoint before relying on it for offline verification.