You Cannot Sign a File by Changing It

Embedded content provenance contains an impossibility at the center, and the impossibility is not subtle.

A C2PA manifest lives inside the asset. The manifest contains a hash of the asset. So the hash would have to cover the manifest that contains the hash. No construction resolves that, and C2PA does not pretend otherwise. The specification carves out an exclusion range — a set of byte positions the hard binding does not cover — and the manifest goes there.

The recent formal-methods analysis of C2PA by Golaszewski, Krawetz, Sherman and colleagues states the situation plainly: “This omission is necessary to resolve a circular dependency: a claim manifest resides within the asset, and the asset’s hash value resides within the claim manifest.”

Necessary, given the decision to embed. The argument of this article is that the decision to embed is itself the thing worth revisiting, because the exclusion range is not an isolated wart. The exclusion range is one instance of a general tax paid by any provenance system that modifies the artifact it describes, and the tax is higher than it looks.

What the exclusion range actually permits

The scope of exclusions is not narrow. From the specification: “the claim generator shall ensure the exclusion range only contains content from C2PA Manifest Store, or asset metadata (e.g., EXIF, IPTC metadata).”

Read the sentence as a permission rather than a restriction. Everything in the manifest store and everything in the asset’s metadata may sit outside cryptographic coverage. An adversary can therefore modify EXIF fields, or reorder and remove manifests in the store, without invalidating the claim signature. The analysis notes that reordering manifests also produces errors and crashes in some validating software, so the excluded region is an availability surface as well as an integrity one.

C2PA is honest about the consequence in the way that matters — in its security goals. The paper derives two goals from the specifications themselves and proposes three more as essential. The relevant one is SG2, weak file integrity: validators can verify the integrity of the data explicitly covered by the signature, and the goal, in the authors’ words, “deliberately omits all data residing within the specified ‘exclusion byte ranges,’ rendering the overall file integrity verification incomplete and susceptible to undetected modification.”

The proposed goal C2PA does not meet is SG5, strong file integrity: verifying the integrity of the asset including non-C2PA metadata. The gap between SG2 and SG5 is precisely the space the manifest had to be inserted into.

The gap, measured

The abstract version convinces nobody, so take the concrete one from the paper.

The Google Pixel 10, software version HDR+ 1.0.821848803zd, excludes 6,741 bytes across 14 separate ranges. The ranges cover 131 bytes of EXIF GPS information and 6,610 bytes of C2PA manifest.

The authors alter the GPS coordinates inside the excluded region, relocating the photograph to somewhere near the Golden Gate Bridge. Adobe’s and CAI’s verifiers ignore EXIF GPS entirely and show nothing. Verifieddit and ProofMode extract the coordinates and display the attacker’s chosen location. No online validator detects the tampering.

Sit with the shape of that result. A cryptographically signed image, produced by a flagship device with a real hardware-backed pipeline, validating cleanly, displaying provenance metadata chosen by someone other than the signer. Nothing malfunctioned. Every component behaved to specification. The specification permits the outcome, because the bytes in question had to be left uncovered so that other bytes could be inserted.

Why the range is that wide

The obvious question is why exclusions extend past the manifest into asset metadata at all, and the answer is a legitimate requirement handled badly.

C2PA’s rationale is privacy. A photographer should be able to strip GPS coordinates from an image after signing, without access to the signing key and without re-signing. Editorial flexibility, in the paper’s framing, was prioritized over strict data integrity.

The requirement is real. Redaction after publication is exactly what journalism needs. But look at the mechanism chosen: privacy was implemented by widening the region the signature does not cover. The system achieved post-hoc redaction by making an area of the file permanently mutable by anyone, rather than by making redaction an authenticated operation. The paper’s recommendation is the correct one and is worth quoting as a design principle: “Post-capture changes to the media for anonymity or privacy must require resigning with a notation of the edit.”

Redaction should be a signed event, not an unsigned hole.

The general tax on modifying the artifact

Exclusion ranges are the cryptographic cost. Four more costs follow from the same decision, and none of them are specific to C2PA.

Identity mutation. A digital artifact often has a canonical identity elsewhere, expressed as a digest. A package in a lockfile. An object in a Git tree. A layer in a container image. An entry in an SBOM. A leaf in a Merkle tree. An RFC 3161 timestamp over a hash. A reproducible build output that must match bit for bit. Embedding provenance changes the artifact’s bytes, which changes its digest, which invalidates every external reference that pointed at the original. Signing the artifact broke every system that was already tracking the artifact. For media assets the problem is often tolerable. For anything under supply-chain control, the problem is disqualifying.

Non-idempotence. Sign the same asset twice and the bytes differ, because the second manifest is inserted into a file that already contains the first. Two parties signing the same source independently produce divergent artifacts that no longer compare equal, which turns an ordinary equality check into a format-aware comparison.

Composition by re-serialization. Multi-party provenance under an embedded model means each actor rewrites the container. Append-only is the property you want when four people touch a story and none of them should be able to disturb what a predecessor signed. Embedding gives you read-modify-write instead, with a re-serialization step at every stage, and every re-serialization is an opportunity to alter something outside the covered range.

Channel fragility. Embedding is a bet that every hop preserves your bytes. Social platforms re-encode. CDNs transform. Email gateways rewrite. Image pipelines strip metadata as a matter of policy. The manifest travels with the asset right up until an intermediary decides otherwise, and the failure is silent.

The line that actually matters: reserved space versus semantic space

None of the above means every embedded manifest is a mistake. The distinction that survives scrutiny is not whether bytes were added but where the format says those bytes may go.

A JPEG APP11 marker segment, an ISO BMFF free or uuid box, a PNG ancillary chunk — each is space the format specification reserves for extension data, which conforming parsers are required to ignore. Writing a manifest into reserved space is using the format as designed. The bytes added carry no meaning to any consumer of the format.

Writing into space the format gives meaning to is a different act entirely, and the difference is categorical rather than one of degree.

Consider provenance for text implemented as invisible Unicode characters interleaved with the content. For prose, the mark degrades the artifact in ways the producer cannot see: byte length changes, wc -c disagrees with the visible text, copy-paste behavior varies by application, and any NFKC normalization step deletes the provenance silently. For source code and configuration — and vendors are now offering exactly this for JavaScript, Python, JSON, YAML, TOML, CSS and XML — the same technique is the mechanism behind the Trojan Source class of attacks catalogued as CVE-2021-42574, where invisible and bidirectional characters cause a compiler and a human reviewer to read different programs. The industry response was to make compilers warn, linters flag, and code review tools strip precisely those characters. A provenance scheme that inserts invisible characters into a .py file is inserting a construct the surrounding toolchain is actively built to remove or reject, and doing so in the one file class where an unnoticed character is a security defect rather than a cosmetic one.

SVG deserves its own mention, because SVG appears in image format lists as though it were a raster format. SVG is XML, XML is parsed for meaning, and SVG can execute script. Anything inserted into an SVG is inserted into a document with an execution context.

So the rule is not “never add bytes.” The rule is provenance may occupy space the format reserves for it, and may never occupy space the format gives meaning to. The rule is checkable: point at the clause in the format specification that reserves the space. If no such clause exists, the mechanism is injection wearing a different name.

Embedding is irreversible, which matters most for the people who need provenance most

One more property of modification deserves attention, because the property is permanent and asymmetric.

What you embed, you cannot un-embed. Every copy that has left your control carries whatever you bound into it, for as long as the copy exists. Post-hoc redaction of an embedded manifest reaches only the copies you still hold, which for published media is approximately none of them.

C2PA’s base specifications keep identity out of the core, and identity arrives through a separate layer — the Creator Assertions Working Group extension. The separation is a deliberate architectural decision, and it is a good one, because it lets a producer document the how of an asset (tools, edits, transformations) without binding who into the artifact by default. As provenance becomes regulated infrastructure, pressure to collapse the two will grow, and the separation is worth defending.

That is not an outside opinion. WITNESS — a human rights organization that is itself a C2PA member and co-chairs the coalition’s Threats and Harms Task Force, the body responsible for C2PA’s own harm assessment — makes the same point in C2PA Content Credentials and the Surveillance Risk, calling the separation of identity from the base specifications “a deliberate governance choice, and one worth safeguarding as pressure to converge the two increases.” The report maps seven pathways by which provenance infrastructure can be turned toward identity disclosure, behavioral profiling, and expression control, and observes that none of them require the technology to malfunction — only that it be deployed in adverse political and regulatory contexts, which specifications alone cannot prevent. The gap the report identifies is in governance: no mechanism exists to assess whether a given deployment constitutes misuse, and no authority exists to respond when one does.

The reason is not abstract. For a journalist, a human rights documentarian, or a photographer working somewhere hostile, a signed asset that binds identity into the bytes is a durable, cryptographically precise link between a person and a specific piece of content, distributed to everyone who receives the file, and accumulating across every file they sign. An unsigned photograph is deniable. A signed photograph carrying an embedded identity assertion is evidence, and evidence that cannot be recalled. WITNESS names journalists, human rights defenders, and documentary filmmakers as the most exposed populations, and adds a category rarely considered: viewers, for whom the act of verifying content can itself generate a behavioral record without their knowledge or consent.

Detached provenance changes the shape of that risk in a way no amount of policy can. A record that references an asset by digest can be withheld, scoped, selectively disclosed, or never published, while the asset itself circulates carrying nothing. Withholding is possible because the binding runs from the record to the asset, and not the other way around.

What the detached model looks like

Concretely, rather than as a slogan.

The signed object is a canonical structured record. The record names the work, its components, its ingredients, the actions taken, the actors and roles, and it references each byte-level artifact by cryptographic digest. The record is serialized through a fixed, syntactic, offline canonicalization, hashed, and signed. The artifact is never opened, never rewritten, and never re-encoded.

The properties follow directly. No exclusion range exists, because nothing was inserted, so SG5-style strong integrity over the artifact is available rather than structurally impossible. Signing is idempotent, since signing twice produces two records and one unchanged artifact. Multi-party composition is append-only, because a second actor emits a second record referencing the first rather than rewriting a container. External digests stay valid, so lockfiles, SBOMs, Merkle proofs and reproducible builds continue to resolve. Redaction becomes an authenticated operation — a new signed record omitting a component and noting the omission — which is exactly what the paper’s recommendation asks for.

The cost, stated honestly

Detached provenance has a real problem, and glossing over the problem is how architecture arguments become marketing.

Discovery. An embedded manifest is always found, because the manifest is inside the thing you already have. A detached record has to be located, and every mechanism for locating one — a well-known URL, a DNS record, a registry, a resolver, a link in an HTTP header — introduces a lookup. A lookup implies a party being asked. Embedded provenance won on this axis, and the win is legitimate.

The answer is not to pretend the lookup away. The answer is to constrain where the lookup lands. A record resolved from the publisher’s own domain, under an identifier the publisher controls, with keys published in a document anyone can dereference, is a lookup against the party making the claim. A record resolved from a vendor’s API is a lookup against a company with a commercial interest in the answer and an incentive to log the question. The two are not equivalent, and the difference is the entire reason decentralized identifiers belong in this stack rather than a proprietary manifest registry.

There is a second cost worth naming: an embedded manifest survives being handed to someone on a USB stick, and a detached record does not, absent a sidecar convention. Air-gapped and archival workflows are the honest home ground for embedding, and a serious architecture should support both rather than declaring one universally correct.

Three rules

Provenance may occupy space the format reserves for it, and may never occupy space the format gives meaning to. Reserved means a clause in a specification, not a region that happens to be ignored today.

Where an artifact has a canonical identity that other systems reference by digest, provenance must be detached. Source, packages, datasets, archival records, anything under supply-chain control. Mutating those artifacts breaks consumers that were doing nothing wrong.

Detached provenance must resolve against the publisher, not a vendor. A lookup is acceptable. A lookup that terminates at the company selling the provenance service is a trust anchor pretending to be an implementation detail.

The exclusion range is not a bug in C2PA. The exclusion range is what an otherwise careful specification had to do once it decided the manifest goes inside the file. The decision was reasonable for cameras and editing software in 2019. The decision is worth reopening for everything else.