Every C2PA signature validates against an X.509 certificate. The cryptography is identical to any other public-key system: the certificate binds a public key to an identity, the signature is produced with the corresponding private key, and a verifier with the public key checks the math. What is specific to C2PA is the trust layer above the cryptography — the question of which certificates a consumer is willing to call "trusted" by default. The C2PA Trust List answers that question.
This page covers the certificate model, the structure and governance of the Trust List, the migration from the frozen legacy Initial Trust List to the current process, and what an "untrusted signer" actually means in a validator's report. The mechanics are inherited from standard PKI; the governance is the part that is C2PA-specific and the part that practical implementers most often misunderstand.
The certificate chain
A C2PA signing certificate is a standard X.509 (RFC 5280) certificate. The signer's certificate is issued by an intermediate CA, which is itself issued by a root CA. The chain is the ordered list from signer to root. A validator walks the chain by verifying each certificate's signature against the next certificate's public key, terminating at a root that the validator trusts intrinsically.
What is trusted intrinsically depends on the validator's configuration. The C2PA Trust List is the canonical set of trusted roots for C2PA-aware validation. A signer whose chain terminates at a Trust List root is trusted by default; a signer whose chain does not — including a self-signed certificate — is not trusted by default. The cryptographic validation still works in both cases; only the trust label differs.
This separation matters. C2PA does not gate the ability to produce manifests behind certificate issuance. Anyone can generate a key pair, self-sign a certificate, and emit valid C2PA manifests. They simply do not benefit from the default-trusted label in consumer-facing UIs. Whether that distinction is meaningful depends entirely on how consuming applications surface it to users, which varies.
The Trust List and its governance
The C2PA Trust List is a published list of CA root certificates whose chains the C2PA coalition considers acceptable for default-trusted signing. Inclusion criteria, as published in the C2PA governance documents, cover identity-verification practices, key protection requirements, audit obligations, and incident-response commitments. CAs that meet the criteria can apply for inclusion through a documented process under the JDF governance structure.
The list is not large. As of mid-2026 it includes Adobe-managed CAs for editorial software signing, Microsoft for Office and Edge signing, several camera-maker CAs (Leica, Canon, Sony, Nikon — though the Nikon entries were temporarily restricted during the 2025 Z6 III incident), the major AI generators' CAs (OpenAI, Google, Adobe Firefly), Truepic, and a small number of issuing CAs operated by national press associations and broadcast consortia. The full list is published at the C2PA website.
The Initial Trust List, or ITL, was a bootstrap list maintained during the 1.x and early-2.x specification line. It was frozen on 1 January 2026, meaning no new entries are accepted; chains terminating at ITL roots continue to validate but are migrating toward the new governance process. Producers issued certificates from ITL CAs received refreshed certificates from successor CAs during 2025; legacy ITL chains will continue to be honored by validators for several more years to avoid invalidating archived signed content.
What "untrusted" means in practice
A validator encountering a signer whose chain does not terminate at a Trust List root will report the signer as untrusted. The exact phrasing varies — "untrusted signer," "unknown certificate authority," "self-signed" — but the underlying meaning is the same: the cryptography is valid; the signer's identity is not endorsed by the C2PA trust infrastructure.
Consuming applications must decide what to do with this. The choices are:
- Treat untrusted as invalid. The image is presented as if no manifest existed. This is the harshest choice and the one most likely to discourage independent signing.
- Treat untrusted as a separate category. The manifest is presented with an explicit "this signer is not on the trust list" indicator, and the user can inspect the chain. This is what Adobe's Content Credentials Verify does.
- Treat untrusted as trusted. The manifest is shown as validated. This is what some early implementations did and is no longer considered acceptable practice.
The middle choice — separate category — is the consensus 2026 approach. It preserves the signing capability for independent publishers, citizen journalists, and tooling outside the trust-list ecosystem, while not creating a misleading endorsement signal. The UX work to make the distinction legible to ordinary users is ongoing.
Revocation
Revocation is the process of marking a previously issued certificate as no longer valid. C2PA inherits standard PKI revocation mechanisms — Certificate Revocation Lists (CRLs) and Online Certificate Status Protocol (OCSP) — with adjustments for offline validation. A validator should check revocation status before accepting a chain; the C2PA spec describes how to handle the case where revocation status cannot be reached (typically by allowing validation with a flag indicating staleness).
Beyond per-certificate revocation, C2PA supports trust-list-level removal. A CA whose practices are found to be deficient — through audit failure, breach disclosure, or systemic compromise — can be removed from the Trust List entirely. Existing signatures from that CA's chain remain cryptographically valid but become untrusted. The 2025 Nikon Z6 III incident, in which a signing flaw allowed C2PA manifests to be forged without camera possession, prompted exactly this kind of action: affected certificate chains were marked untrusted while the underlying flaw was remediated, then re-trusted with corrected firmware in late 2025.
The governance question
The Trust List is the place where C2PA's technical neutrality gives way to political choice. Someone decides which CAs are listed; someone decides what happens when a listed CA misbehaves; someone decides whether a national-government-issued CA can join. These decisions are made by the C2PA coalition under JDF governance, with documented procedures, but they are decisions and they have not been tested by hard cases.
The hard cases that have been raised in coalition discussions through 2025 include: a national government insisting on issuing a Trust List CA whose certificates would be issued only to journalists licensed by that government; a coalition member acquired by a foreign entity whose new ownership raises sanctions concerns; a CA that suffers a major breach and disputes the coalition's revocation timeline. None of these have produced a public crisis yet, but each is foreseeable.
The honest position is that the Trust List makes C2PA's effectiveness in any given political context contingent on the governance behavior of the coalition. A coalition that excludes a CA because of political pressure undermines the standard's neutrality claim; a coalition that includes one despite practice failures undermines the security claim. The tension is structural and probably unresolvable; the practical answer is procedural transparency and a willingness to fork the Trust List if necessary.
Operating outside the Trust List
An independent publisher, a citizen journalist, or a free-software project can operate outside the Trust List entirely. Self-signed C2PA manifests are valid, parseable, and inspectable; what they lack is the default-trusted label. Several efforts through 2024 and 2025 have explored alternative trust models — a community-maintained "secondary trust list," a Web of Trust pattern based on social-graph signing, a Sigstore-like ephemeral signing model — but none has achieved meaningful adoption, and most consuming applications still treat trust-list membership as the default trust gate.
For a working publisher considering this path, the practical question is what consumers will see. If the consuming application is Adobe Content Credentials Verify, an untrusted manifest is surfaced with explicit indication; the user can inspect and decide. If the consuming application is a browser badge that collapses everything into trusted-or-not, the untrusted manifest may simply not appear. The answer depends on which validators the publisher's audience uses, which is rarely under the publisher's control.
Where the field is moving
The Trust List's structure and governance are likely to be tested in public over the next two years. The migration off the ITL was completed without major incident; the harder tests are ahead, particularly as government CAs from various jurisdictions seek inclusion and as the EU AI Act's marking requirement creates demand for signing infrastructure that may or may not interoperate cleanly with the C2PA process. The coalition's published roadmap commits to procedural improvements (faster revocation cycles, better audit reporting) but does not commit to specific governance outcomes for contested CA applications.
The other live front is the alternative-trust ecosystem. A federation pattern in which multiple trust lists coexist, each with its own scope and acceptance criteria, would give publishers more flexibility and consumers more nuanced trust signals. The technical work is mostly done; the social coordination is the bottleneck. Whether this emerges depends as much on the EU and the major platforms as on the C2PA coalition itself.