Problem
VerifyExtended iterates only the ASiCManifest's DataObjectReference elements. A data file that sits in the ZIP but is not referenced by the manifest is therefore:
- never hashed,
- never reported as a step, and
- does not prevent
IsValid from being true.
Compounding it, ExtractAll walks ZIP entries (FindDataEntries) rather than the manifest, so it does return those unlisted files. A consumer that verifies a container, sees IsValid == true, and then calls ExtractAll will surface bytes that the proof of existence never covered — presented as though they were timestamped.
The listed files' proofs remain intact; this is not a break of the timestamp itself. The issue is that "valid container" currently says nothing about whether every file in it is covered.
Reproduction sketch
- Create an ASiC-E container with
file1.txt.
- Add
injected.txt to the ZIP without touching META-INF/ASiCManifest.xml.
Verify → IsValid == true, no step mentions injected.txt.
ExtractAll → returns both files.
Why this needs a decision, not just a patch
IsValid is the conjunction of every VerificationStep. Adding a completeness step means containers that verify today become invalid — including any third-party ASiC-E container that legitimately carries extra unreferenced entries. So the options differ in blast radius:
- New failing step — strictest, but a breaking change for existing containers.
- Passing-but-informational step — surfaces the fact without flipping
IsValid; no break, weaker guarantee.
- Report-only property on
AsicVerifyResult (e.g. unlisted entry names) plus a documented caveat — no step, caller decides.
- Fix
ExtractAll only — have it return manifest-referenced files for ASiC-E, closing the dangerous half without touching the verdict.
Options 3 and 4 compose well and avoid the breaking change; option 1 is the strongest guarantee if a major-version bump is acceptable.
Tracking
STRIDE.md T-9 (Tampering, score 6, status Open)
- Documented in
docs/verification.md (gotchas) and docs/container.md (gotchas)
🤖 Generated with Claude Code
Problem
VerifyExtendediterates only the ASiCManifest'sDataObjectReferenceelements. A data file that sits in the ZIP but is not referenced by the manifest is therefore:IsValidfrom beingtrue.Compounding it,
ExtractAllwalks ZIP entries (FindDataEntries) rather than the manifest, so it does return those unlisted files. A consumer that verifies a container, seesIsValid == true, and then callsExtractAllwill surface bytes that the proof of existence never covered — presented as though they were timestamped.The listed files' proofs remain intact; this is not a break of the timestamp itself. The issue is that "valid container" currently says nothing about whether every file in it is covered.
Reproduction sketch
file1.txt.injected.txtto the ZIP without touchingMETA-INF/ASiCManifest.xml.Verify→IsValid == true, no step mentionsinjected.txt.ExtractAll→ returns both files.Why this needs a decision, not just a patch
IsValidis the conjunction of everyVerificationStep. Adding a completeness step means containers that verify today become invalid — including any third-party ASiC-E container that legitimately carries extra unreferenced entries. So the options differ in blast radius:IsValid; no break, weaker guarantee.AsicVerifyResult(e.g. unlisted entry names) plus a documented caveat — no step, caller decides.ExtractAllonly — have it return manifest-referenced files for ASiC-E, closing the dangerous half without touching the verdict.Options 3 and 4 compose well and avoid the breaking change; option 1 is the strongest guarantee if a major-version bump is acceptable.
Tracking
STRIDE.mdT-9 (Tampering, score 6, status Open)docs/verification.md(gotchas) anddocs/container.md(gotchas)🤖 Generated with Claude Code