Wiki · Concept · Last reviewed July 10, 2026

C2PA Trust List

The C2PA Trust List is the certificate-trust layer underneath Content Credentials validation. It helps validators decide whether a signer belongs to a recognized provenance ecosystem, but it does not prove that a media claim is true, complete, lawful, or fair.

Category: media provenance / trust infrastructure Published: June 25, 2026 Modified: July 10, 2026 Last reviewed: July 10, 2026 Tags: C2PA, Content Credentials, trust list, certificate authorities, provenance, synthetic media

Snapshot

Definition

The C2PA Trust List is a C2PA-managed list of X.509 certificate trust anchors that issue certificates to hardware and software signers used to sign C2PA claims. In practice, it is one of the roots that lets a validator treat a Content Credential as signed through a recognized C2PA certificate path rather than by an unknown certificate chain.

More precisely, the Trust List is a list of Certification Authorities, not a list of true images, honest publishers, approved political claims, or universally trusted people. C2PA's FAQ says signing certificates are issued by CAs on the Trust List, and that a conforming generator product must undergo conformance and security evaluation before obtaining one.

The trust list is not the whole Content Credentials system. A C2PA Manifest records provenance assertions and is bound to an asset by hashes and signatures. The trust list helps validate the signer side of that record. A separate C2PA TSA Trust List covers Time Stamping Authorities. C2PA 2.0 introduced the default C2PA Trust List for hardware and software certificates, while validators can also use configured trust lists, user-selected lists, or private credential stores.

This distinction matters for synthetic-media governance. "Valid credential," "trusted signer," "known publisher," "AI-generated label," and "true depiction" are different claims. The trust list can support the first two. It cannot settle the last one.

Mechanism

In C2PA validation, the claim signature includes an identity credential in the COSE signature headers. A validator checks that credential, builds a certificate chain from the signing certificate through intermediates to a trust anchor, and evaluates whether the certificate is acceptable for C2PA claim signing. The 2.4 specification defines the c2pa-kp-claimSigning extended key usage and says trust-anchor configurations for that EKU include, at minimum, the signer trust anchors provided by C2PA.

The time-stamp path is separate. The specification says validators maintain a separate list of X.509 certificate trust anchors for Time Stamping Authorities, including the C2PA TSA Trust List. That separation keeps "this claim was signed by an accepted content signer" distinct from "this time-stamp was issued by an accepted TSA."

Validation records can also carry evidence of which trust basis was used. The C2PA validation-results map may include a specification version and a trustListURI when a non-default trust list was used. That is small but important: a provenance display without validator version, trust source, and certificate-chain evidence can look cleaner than the trust decision actually was.

Boundary Tests

Current Context

As of July 10, 2026, C2PA describes the official Trust List as part of its Conformance Program. The conformance page says the program covers generator products, validator products, and certification authorities, that conforming products are placed on a publicly accessible list, and that the program is intended to hold those actors accountable to the Content Credentials specification, certificate policy, and security requirements.

The same page says the official C2PA Trust List launched in mid-2025, the earlier Interim Trust List was a temporary early-adoption measure, and the Interim Trust List was frozen on January 1, 2026. Existing ITL-era certificates can still matter for legacy validation, but interfaces are expected to distinguish ITL-based credentials from credentials under the official C2PA Trust List and 2.x trust model.

The Conformance Explorer exposes live versions of the conforming-products list, the C2PA Trust List, and the C2PA TSA Trust List. That turns a provenance badge into an ecosystem claim: not only "this file has a manifest," but "this validator recognized a signer chain or time-stamp chain under a particular trust configuration."

C2PA's FAQ clarifies the product path: only products evaluated and approved by the Conformance Program are eligible to receive certificates from trusted CAs. That makes trust-list governance a procurement and assurance issue. A buyer of a camera, generator, editor, archive tool, or validator should ask whether the product is conforming, which assurance level and certificate chain are used, how keys are protected, and how validation results are displayed.

Governance Use

For newsrooms, courts, archives, platforms, campaigns, and public agencies, the trust list should be part of the evidence file. A serious review should preserve the validator product and version, C2PA specification version, signer certificate, issuer chain, trust-list source, TSA evidence, revocation status, validation errors, active manifest, ingredient manifests, and viewer-facing language.

Trust lists also define institutional power. A certificate authority or product that enters the list becomes part of the media-authenticity infrastructure. A product excluded from the list may still create useful provenance for a local community, but public validators may present it differently. That makes trust-list governance a media-policy question, not only a PKI detail.

User interfaces should separate cryptographic status from human interpretation. "Signed by a conforming product," "trusted signer chain," "legacy trust model," "unknown signer," "broken binding," "redacted assertion," and "unverified claim" should not collapse into a single green check or warning triangle. The viewer needs enough detail to understand what kind of trust was established.

Procurement should also require operational records: certificate enrollment process, private-key protection, revocation and renewal process, offline signing behavior, validator update policy, privacy behavior for revocation or remote-manifest checks, and incident handling when a signing key or conforming product is compromised.

Limits

C2PA's explainer is explicit that Content Credentials provide no value judgment about whether provenance data is good or bad. They can show that provenance is well formed, untampered, valid, trusted, and associated with the asset. They do not prove truth, consent, legality, editorial judgment, or moral authority.

There are also security and usability risks. C2PA security guidance discusses name-collision and identity-confusion attacks where a trusted-looking certificate or a sequence of signed edits can mislead human viewers. Implementation guidance describes revocation as best effort: revocation information may not be present, and consumers may choose not to query a certificate authority for privacy reasons. Private credential stores can support trusted out-of-band relationships, but they require careful handling and do not make a self-signed credential globally trusted.

Trust-list validation also depends on local validator state. An outdated validator, missing trust-list update, blocked network request, offline environment, or policy choice about legacy ITL certificates can change how the same asset is presented. A legal, journalistic, or archival record should therefore preserve the validation environment rather than only the final badge.

Failure Modes

Review Record

Source Discipline

Claims about the C2PA Trust List should cite the C2PA technical specification, FAQ, conformance page, conformance explorer, implementation guidance, and security considerations. For list membership or certificate-policy claims, cite the official C2PA conformance repository or the live explorer rather than vendor marketing alone.

Do not collapse the C2PA Trust List into all Content Credentials, CAWG identity assertions, watermarking, blockchain provenance, publisher reputation, or fact-checking. Name the layer: manifest store, signer certificate, trust list, TSA trust list, validation result, identity assertion, visible label, or editorial verification.

Spiralist Reading

Spiralism reads the C2PA Trust List as a root store for public memory. The image carries a credential, the credential carries a signature, the signature points to a certificate, and the certificate asks the viewer to accept an institution upstream.

That chain is useful. It is also a transfer of trust from the visible media object to a hidden governance list. The right discipline is to keep the chain visible: who signed, who issued, which list accepted it, which validator said so, and which claims still remain outside the certificate path.

Sources

Return to Wiki