Does the Core session chain (§8.6) protect anything without an independent collector?

[vadim-kyvvu]

(Disclosure: I work on Kyvvu. We hash-chain our own audit records, so this is about where the requirement sits, not whether chains are useful.)

A hash chain is tamper-evident only if its heads reach a witness the Guardian cannot influence: an independent, append-only collector that receives the signed heads as they are issued. ACS-Core defines no such collector:

• The only party that receives chain_hash is the Observed Agent. Nothing requires it to keep the heads, or to store them anywhere the Guardian can't reach.
• Under the HMAC baseline both sides hold the same key, so the Guardian can re-sign a rewritten head. §8.6 says so: it "does not bind the Guardian itself".

So a Guardian that drops a DENY and recomputes the chain still produces a history nobody can contradict. That is the exact attack the published head was added for in PR #2. Against a network tamperer, the envelope signature already protects every response.

Meanwhile the chain costs every Guardian per-session ordering and durable state (#233), and its cross-implementation comparability is undefined until v0.2 (#18, §3).

Question: is there a reason the chain needs to be in Core rather than ACS-Audit? ACS-Audit could require it together with an asymmetric signature (ACS-Crypto) and an external append-only witness, which is where it actually becomes evidence.

If not, I'd propose:

• Move the chain to ACS-Audit.
• Make §8.6 apply to "a Guardian that maintains the chain".
• Let a Core-only Guardian publish chain_hash as a MAY.

Nothing breaks: a Guardian that publishes heads today stays conformant. Happy to write the PR.

[slaxxarn]

I think you’re right that it only becomes evidence in ACS-Audit, together with ACS-Crypto. I’ve just opened “ACS-Audit: external anchoring of the chain head”, which is close to the “external append-only witness” part of your proposal, so the two fit together.

One thing that might make the witness cheaper to require: it doesn’t need to receive every head as it’s issued. Periodic anchoring to a party the Guardian doesn’t control (an RFC 3161 TSA, a transparency log like Rekor, another operator), plus a mandatory anchor at sessionEnd, is enough. A rewrite before the next anchor still goes through, so the interval is the risk window, and a conformance claim should state it. That’s a parameter a deployer can reason about, instead of hoping someone recorded the traffic.

The chain only covers order and completeness, though. It doesn’t show that an ASK was actually approved by the approver. I’ve raised that separately in “ASK: approver-signed grant bound to the exact request”.

(Same disclosure as you: I build INTYGA, which anchors its evidence logs this way.)