## Problem `audit_trail_tsa` exists to give a chain an external, independently verifiable anchor in time. The only cryptographic check it performs is: ``` openssl ts -verify -in <tsr> -queryfile <tsq> -CAfile <ca> ``` Both blobs come from the **same stored row's** payload. `anchored_hash` is never compared to the imprint inside the TSQ, and never compared to the chain row's own hash. ## What happens So the verification establishes only that the TSA signed *something*, and that the response matches the query stored beside it. It says nothing whatsoever about the chain. Substitute any valid, internally consistent timestamp pair, whether from an unrelated document, a different chain or a different site, and the module still reports a trusted external anchor for the chain. An attacker who can write the TSA row does not need to forge a timestamp at all; they need only supply a real one. RFC-3161 timestamping is the feature an operator installs this submodule for, and the one part of the design that is supposed to hold even against someone who controls the whole site. ## Findings in this issue - **H24** `modules/audit_trail_tsa/src/Tsa/ChainTimestamper.php:340-353`: the only crypto check is `openssl ts -verify -in <tsr> -queryfile <tsq> -CAfile <ca>` with both blobs from the same row; `anchored_hash` is never compared to the TSQ imprint or to the row hash. Verified by reading the whole verification path. ## Fix Two comparisons, both cheap: 1. **`openssl ts -verify -digest <anchored_hash>`** makes openssl compare the response's `messageImprint` against the anchor the row claims it covers. openssl does the ASN.1, so the module gains no DER parser and no second way of reading a TimeStampResp. 2. **The anchor is compared to the chain's own hash** at the row it says it anchored. That row id comes from the `resource` column, which is part of the canonical payload the chain HMAC covers and belongs to no retention tier. The `@head_id` placeholder in the transient bucket is the obvious source and the wrong one: a transient purge takes it away. Neither alone closes the substitution, because they are two links of one chain of custody and an attacker who can write the row picks whichever link is missing: - With only the imprint comparison, the anchor is written to match the lifted timestamp. The response covers the anchor it claims, and the anchor belongs to nothing. - With only the chain comparison, the anchor is left as the real chain head and the response is swapped. The anchor is this chain's head, and the response attests something else. Together they tie response to anchor and anchor to a specific row of a specific chain, which is the property this submodule exists to provide. Two departures from how this issue first proposed it, both deliberate: - The imprint is not parsed out of the TSQ. `-digest` makes openssl do that comparison itself, which is one shell-out either way and no parser to maintain. - The chain hash is read from the `hash` column rather than recomputed from the canonical payload. A rewritten column is precisely what the chain verifier walks the chain to catch, and recomputing here would duplicate that walk on every verified row to answer a question that already has an owner. The second comparison is a database read, so it runs even for a provider with no CA chain pinned, which is a supported setup: it is the only one of the checks that can see a timestamp moved onto this chain from another, and refusing the row over the missing CA threw it away. A test had to be seen to fail first: timestamp chain A, move the TSR/TSQ pair onto chain B's row, and assert verification fails. Filed on its own because the fix is two comparisons rather than a design change, and because it is the most serious single finding of the audit. --- Found by a full-tree audit of `1.x` pinned at `7bae553` (tag `1.0.0-alpha9`), reading all 271 tracked files. Every claim above was checked against the source, and where a claim could only be settled by running something, the issue says so. AI-Generated: Yes (Claude Code was used to help draft this issue summary and the merge request on it, !42. I reviewed both before posting.)