C2PA Through a CDN: Serving Content Credentials Without Breaking Them

01 /What a C2PA manifest is and where it lives

C2PA is the open specification for content credentials: a signed record, carried inside a media file, of who produced the asset and what was done to it. It is written by the coalition behind the C2PA standard, whose members include camera makers, software vendors, news organisations and standards bodies; the current technical specification is version 2.2. For a network operator one structural fact matters more than the assertions: the credential is a block of bytes inside the file, meaningful only while the rest of the file is exactly what it was when the block was signed.

That block is the manifest store, a JUMBF box (ISO 19566-5:2023) that holds one or more manifests. Each manifest contains an assertion store (the claims: actions taken, ingredients used, capture details, a thumbnail), a claim that lists and hashes those assertions, and a claim signature. The specification defines where the store goes in each container: APP11 marker segments in JPEG, a private caBX chunk in PNG, a C2PA chunk at the end of a RIFF file such as WebP, and a uuid box in BMFF-based formats such as HEIF, AVIF and MP4. A validator looks in the standard location for the container, and if the asset arrived over HTTP it may also look at a Link header, which is covered below.

02 /How signature validation works

Two things bind the manifest to the asset. The first is the hard binding: an assertion such as c2pa.hash.data that records a cryptographic hash over the asset's bytes with the manifest store itself excluded by byte range, or, for box-based formats, c2pa.hash.bmff which hashes the boxes. The second is the claim signature: a COSE_Sign1 structure over the serialised claim, made with a private key whose X.509 certificate chain is carried in the signature headers (per RFC 9360), ideally with an RFC 3161 time-stamp so that the signature remains checkable after the certificate expires.

A validator therefore does three checks in order: it parses the manifest store and the claim, recomputes the hash over the served bytes minus the exclusion ranges and compares it with the hard binding, then verifies the signature and walks the chain to a trust anchor it recognises. The hash check is the one an operator can break: the signature is still cryptographically fine, but it now signs a description of a file that no longer exists. Validators report this as an asset modified after signing, which to a reader looks worse than no credential at all.

03 /What breaks a manifest and what survives

The rule is byte identity. Anything that leaves the file's bytes unchanged leaves the credential valid, however much it does around the file. Anything that produces a new file, however similar it looks, produces a file whose hash does not match the hard binding, and most operations also discard the manifest store outright because the encoder never knew it was there.

Version 2.2 of the specification allows a claim generator to exclude classic metadata sections from the data hash, so a file signed that way tolerates a later EXIF or XMP edit. Do not rely on it: you rarely control how the file was signed, and the general guidance on which image metadata blocks survive a pipeline applies to the manifest store too, since it is just another block to the tools that strip.

04 /Configuring the pipeline to pass originals through

1. 01

   Inventory the credentialled assets

   Find out which paths carry manifests, by scanning the origin store for the JUMBF signature or checking the publishing workflow. Put those paths under a prefix or naming rule so the edge can recognise them without inspecting content.

2. 02

   Exempt those paths from every transform

   Image optimisation, format negotiation, responsive resizing and metadata stripping are usually on by default at the edge and in the origin's media library. Turn each off for the credentialled prefix with a rule that sets pass-through before any optimisation rule is evaluated.

3. 03

   Serve variants from separate URLs

   Generate thumbnails and WebP or AVIF variants as distinct objects at distinct paths. Keep the original at a stable URL with a long cache lifetime and reference it wherever a reader or validator might want the signed file.

4. 04

   Fix the response headers

   Send the correct media type, allow range requests and keep Content-Length accurate. For a remote manifest, add a Link header with rel=c2pa-manifest and serve the manifest as application/c2pa; make sure downstream header rewriting preserves it.

5. 05

   Decide what to do where transformation cannot be avoided

   A derivative is a new asset. Either re-sign it in your own workflow with the original as an ingredient, or accept that it carries no credential and link to the original.

6. 06

   Verify the served bytes, not the stored ones

   Fetch the file through the public URL, through the same edge and cache layers a reader uses, and run a validator on what comes back. Repeat after every edge configuration change, because a transform switched on for another reason breaks this path without any error.

$ curl -sS -o served.jpg -D headers.txt https://example.org/photos/2026/bridge.jpg
$ grep -i -E 'content-type|content-length|link|content-encoding' headers.txt
content-type: image/jpeg
content-length: 2417930
$ sha256sum served.jpg origin-copy/bridge.jpg
9f1c2a7e4b0d  served.jpg
9f1c2a7e4b0d  origin-copy/bridge.jpg
$ c2patool served.jpg
Validation: passed
  signature: valid (chain to trusted anchor)
  c2pa.hash.data: matches

05 /Remote and sidecar manifests

The specification allows the manifest store to live outside the file. A validator that finds no embedded store checks, in order, a Link header on the HTTP response (RFC 8288) with rel=c2pa-manifest, a dcterms:provenance key in any XMP the file carries, and finally a file at the same URL with a .c2pa extension, served as application/c2pa. A remote manifest is not a way around transformation: its hard binding still hashes the asset bytes. What it gives you is a manifest that survives a pipeline which strips unknown blocks, provided the Link header or sidecar reaches the client.

For assets that will be transformed, edited and re-shared beyond your control, the specification defines soft bindings, a watermark or a perceptual fingerprint that lets a manifest be found again in a repository after the metadata is gone. That is the content owner's concern rather than the operator's, but it is the answer to the question of what happens after a reader saves the file and uploads it elsewhere. On your own infrastructure, the operator's job is simpler: deliver the bytes unchanged and let the integrity checks on content in transit prove that you did.

06 /Testing a credentialled path end to end

Test from outside, with a cold cache and a warm one, and with the Accept header a browser sends, since format negotiation is keyed on it. Compare the hash of the served file with the origin copy before running the validator; a differing hash tells you which layer changed the bytes faster than the validator's report does. Request a byte range and confirm it is honoured, check the response on every edge location you can reach, and add the check to your synthetic monitoring so a transform switched on later is caught the same day.

07 /Pitfalls

• Content negotiation. Serving an AVIF derivative to a client that accepts it is a transform. Exempt the credentialled prefix or the browser never receives the signed file.
• Origin-side media libraries. Many publishing systems re-encode on upload and strip metadata by default. If the origin holds a broken copy, nothing at the edge can repair it.
• Cache keys that ignore the original. A cache that stores one derivative per device class may never hold the original. Give it its own key and a long lifetime; the cache design for crawler-heavy sites covers the trade-offs.
• Dropped Link headers. A proxy that allowlists response headers silently discards the pointer to a remote manifest.

A C2PA manifest asks one thing of the network: carry the file exactly as it was signed. Once the credentialled prefix is exempt from transformation and a validator passes on the served bytes, the next step is to put that validation into scheduled monitoring, so the guarantee holds for the life of the asset; the section on what the network can prove covers the other hops between client and origin.

Serving credentials intact is the media half of the provenance lane; which metadata blocks survive resizing and re-encoding is the companion page, and transport-level integrity checks tell you whether the bytes that left the origin are the bytes that arrived. Log the verification result as described in edge audit logs kept as evidence.