The preceding six parts built the machinery of digital trust: certificate anatomy, the lifecycle, automation, crypto-agility, machine identity, and the discipline of operating it all. This final part points that machinery at a problem that has moved from niche to urgent inside a single product cycle: proving where a piece of media came from.
As generative models make convincing synthetic images, audio and video trivial to produce, the question "is this real?" has become unanswerable by inspection alone. Detection is an arms race that defenders tend to lose, so the industry's most serious answer is provenance: cryptographically signing content at the point of capture or creation so its origin and edit history travel with it. The standard carrying that effort is C2PA, and beneath the media-friendly language it is, almost entirely, a PKI signing problem of exactly the kind this series has described.
That is the reason to end here. C2PA is the whole series compressed into one applied case. It touches certificate profiles, path validation, lifecycle, revocation, timestamping, agility, attestation, and trust governance, all in service of a question ordinary people now ask daily.
What C2PA actually is
C2PA (the Coalition for Content Provenance and Authenticity) defines a format for attaching tamper-evident provenance to a media asset. The user-facing brand is Content Credentials. The core object is a manifest: a bundle of assertions about the asset (the capture device, the editing actions applied, whether a generative model was involved) together with a claim that binds those assertions to the actual bytes of the asset through cryptographic hashes. That link is the hard binding. The claim is then signed.
The consequence is the familiar tamper-evidence of any signature scheme: alter the pixels or the metadata and the hash no longer matches; alter the assertions and the signature breaks. One point deserves emphasis up front, because it is the most common misunderstanding of the entire effort:
C2PA proves that an asset came from a particular signer and has not changed since it was signed. It does not prove the asset is honest, accurate, or unmanipulated. Provenance is not truth; it is an auditable chain of custody.
The signing model
Where document signing uses CMS and the web uses TLS, C2PA signs with COSE (CBOR Object Signing and Encryption), specifically COSE_Sign1. The signer's X.509 certificate chain is carried inside the signature in the x5chain COSE header, so everything a verifier needs travels with the asset. Validation therefore needs no network call. That was a deliberate design choice, and it suits newsrooms, archives, and low-connectivity environments.
ASSET (image / video / audio / PDF)
|
v
+-------------------------------------------+
| C2PA Manifest |
| assertions: capture device, edits, |
| "AI-generated?", thumbnail |
| hard binding: SHA-256 hash of asset ----+--> ties manifest
| +-----------------------------------+ | to the bytes
| | Claim | |
| +----------------+------------------+ |
| | sign (COSE_Sign1) |
| v |
| +-----------------------------------+ |
| | Claim Signature | |
| | x5chain: [ leaf, intermediate ]|---+--> signer's X.509 chain
| | + RFC 3161 timestamp | | (no network call
| +-----------------------------------+ | needed to verify)
+-------------------------------------------+
|
v embedded in / sidecar to the asset — provenance travels with the fileThe certificate profile
This is where the fundamentals from Part 1 reappear unchanged. A C2PA claim-signing certificate is an ordinary X.509 v3 end-entity certificate constrained by a specific profile. The profile is intentionally narrow, which is what lets a validator decide quickly whether a certificate is even eligible to sign a claim.
C2PA Claim Signing Certificate (X.509 v3, end-entity)
Key Usage: digitalSignature (critical)
Extended Key Usage: 1.3.6.1.4.1.62558.2.1 (c2pa-kp-claimSigning)
# a document-signing EKU acts as the
# fallback default when a validator has
# no EKU list configured
Basic Constraints: cA = FALSE (never a CA)
Public Key: EC P-256 or X25519 (preferred)
RSA >= 2048 (alternative)
COSE signature alg: ES256 / ES384 / ES512
PS256 / PS384 / PS512
Ed25519
Chain delivery: carried in the x5chain COSE header
Validation: build a path to a Trust List anchor,
per RFC 5280 section 6The claimSigning extended key usage lives under C2PA's own private enterprise arc (1.3.6.1.4.1.62558), which makes a production claim-signing certificate unmistakable and prevents an arbitrary TLS or email certificate from being repurposed to sign provenance. Path building and path validation then proceed exactly as described in Part 1: the verifier assembles the chain from the x5chain header and validates it to a trusted anchor under RFC 5280. It is the same algorithm, pointed at a new surface.
The trust model: lists, conformance, and assurance
Two things distinguish C2PA's trust model from ordinary signing, and both are interesting architecturally.
First, trust is anchored not in the broad operating-system root store but in curated trust lists: a default C2PA Trust List, plus any additional lists a validator chooses to configure. As of recent versions of the specification, only X.509 certificates may be used for signing, and a verifier will trust a claim only if its chain terminates at an anchor on a list the verifier recognises. The meaning of a Content Credential is therefore exactly as strong as the governance of the list behind it, which is a point I will come back to.
Conformance-gated issuance
The second difference is newer. Obtaining a production claim-signing certificate is gated on conformance. The generator product doing the signing (camera firmware, an editing tool, a publishing platform) must pass a conformance and security evaluation before a certificate is issued to it. The resulting certificate records an Assurance Level derived from both static evidence (architectural review) and dynamic evidence (the implementation's security state), and higher assurance levels can require hardware-backed attestation at enrollment.
This is the attestation-gated issuance pattern from Part 5, applied to a different question. There, the question was "is this device genuine and in a known-good state?" Here it is "is this signing product trustworthy enough that its claims should be believed?" In both cases the certificate records the outcome of an evaluation as well as an identity, and its assurance level is part of the trust signal a verifier consumes.
Identity is a separate certificate
Two roles here are easy to conflate. The claim-signing certificate proves integrity, meaning that the manifest is intact and came from an approved signer. A distinct class of credential, the CAWG identity certificate, embeds a verified creator or organisation identity inside the manifest, proving who. Full attribution typically uses both: one certificate to vouch that the manifest is sound, another to attach a named, vetted author to it.
Timestamping and long-term validity
Provenance must outlive the certificate that produced it. A photograph signed today should still validate in a decade, long after the signing certificate has expired or been rotated. C2PA solves this the same way document and code signing do: with RFC 3161 timestamps, issued by timestamp authorities that are themselves governed by a trust list. A timestamp proves the certificate was valid and not revoked at the moment of signing, so a claim signature can be validated indefinitely even after the certificate's own validity window has closed. Live revocation status, where needed, uses OCSP.
This is also where crypto-agility (Part 4) quietly matters. Manifests are signed once and, by design, never re-signed, yet they must remain verifiable for years. The signature algorithms and trust lists that underpin them therefore have to be governed as living things, with room to add new algorithms and retire weak ones, or a generation of signed assets will gradually slide from "verified" to "signed with something nobody trusts any more."
Where it breaks
A clear-eyed architect adopts C2PA for what it is and is candid about what it is not. The honest limitations:
- Metadata stripping. Many platforms re-encode or strip metadata on upload, and an embedded manifest is easily lost in the process. The mitigation is durable or soft bindings: invisible watermarks or perceptual fingerprints that let a stripped asset be matched back to a stored manifest. These are statistical, though, and weaker than the cryptographic hard binding.
- Provenance is not authenticity. A signed lie is still a lie, now with a valid signature. C2PA tells you the chain of custody, not whether the first link was honest.
- Trust-list governance. The system is only as meaningful as the rules for who gets onto a trust list and how quickly revocation propagates. That is a governance problem rather than a cryptographic one (it was the subject of Part 6), and it is the part most likely to determine whether the ecosystem earns public confidence.
- Ecosystem maturity. Trust lists, the conformance program, and verifier coverage are all still evolving. Adoption is real and accelerating across camera makers, generative-AI providers, and newsrooms, but a missing or unrecognised Content Credential currently means "no information", not "fake".
The closing argument
C2PA is a fitting place to end this series precisely because it contains almost none of it that is new. There is no novel cryptography here. There is an X.509 certificate with a particular extended key usage, a signature format, a chain validated to a trusted anchor, a timestamp to outlast the certificate, a lifecycle to manage, a revocation story, and a trust list whose governance is the hardest part. Every one of those is a fundamental this series has already covered.
If there is one thing I would take from this series, it is this. The frontier problems of digital trust, such as synthetic media, machine identity at planetary scale and the post-quantum transition, are rarely solved by inventing new mathematics. They are solved by applying old, well-understood trust machinery, carefully and operationally, to a new and urgent surface. Build that machinery to be understood, automated, agile and well-governed, and it will keep answering questions its designers never anticipated, including ones like "is this image real?", that the world did not know it needed to ask.
NK