C2PA Certificates and Trust Lists

A C2PA claim signature can show that a particular private key signed a particular claim. That is an essential integrity check, but it is not yet a complete trust decision. A validator must still determine what credential represents that key, whether the credential is technically suitable for C2PA, whether it chains to a trust source the validator accepts, whether it was valid at the relevant time, and whether it had been revoked.

Certificates and trust lists provide the identity and governance layer for those questions. They help a validator move from "the mathematics of this signature checks out" to the more useful statement "this valid manifest was signed under a trust framework I recognize." They do not prove that every assertion is factually true, that the content is an accurate depiction of reality, or that the signer deserves the same confidence in every context.^[1]

Why a valid signature is not enough

Digital signatures answer a narrow but powerful question: does this signature verify against the public key associated with the signed claim? If it does, the validator has evidence that the claim has not changed since the holder of the corresponding private key signed it.

That result says nothing by itself about who controls the key. Anyone can generate a key pair and sign data. A self-issued or unknown credential can produce a perfectly valid cryptographic signature. The signature becomes useful for public attribution only when the public key is connected to an identity through a certificate and the validator accepts the system that issued that certificate.

C2PA therefore separates cryptographic validity from trust. A validator can recognize that a manifest is intact and correctly signed while also reporting that the signing credential is untrusted under its current configuration. This is not a contradiction. It is a precise description of two different checks.

The roles in the C2PA trust model

Several related actors and objects participate in the trust decision. Keeping their responsibilities separate prevents common mistakes, especially the tendency to treat the software that created a claim, the organization whose credential signed it, and the certification authority as though they were the same entity.

The claim generator and signer may be closely related. A camera manufacturer, for example, may operate a signing identity used by camera software running on its devices. They are still conceptually different: the claim generator is the software or hardware that assembled the provenance record, while the signer is the credential holder whose private key authorized the claim.

How a certificate chain works

C2PA uses X.509 public-key infrastructure. The signing certificate normally sits at the end of a chain that leads through one or more intermediate certification authorities to a root or other configured trust anchor. Each certificate in the chain signs the certificate below it, creating a path a validator can test.

The claim signature carries an x5chain header containing the signing certificate and the intermediate certificates needed to propose a path. The trust anchor is generally supplied by the validator through a trust list or other configuration. It is not made trustworthy merely by being included in the manifest.^[2]

This last point is fundamental. Every certificate embedded with a signature must be treated as untrusted input until the validator builds and verifies a path to a trust anchor it already accepts. Otherwise, an attacker could place a self-signed root beside a fraudulent signature and ask the validator to trust the attacker's own authority.

Path building is more than matching issuer names. The validator checks signatures on the certificates, validity periods, basic constraints, key usage, extended key usage, policy restrictions, and other X.509 requirements. A chain that reaches a familiar root can still be rejected if a certificate is malformed, used for the wrong purpose, outside its effective period, or otherwise incompatible with the C2PA certificate profile.

The C2PA certificate profile

C2PA narrows the broad X.509 ecosystem to a certificate profile suitable for provenance signing, time-stamping, and credential-status responses. This improves interoperability and prevents a certificate intended for one purpose from being silently reused for another.

At a practical level, a C2PA signing credential is an end-entity X.509 v3 certificate. Its key usage must permit digital signatures, its basic constraints must not identify it as a certification authority, and its extended key usage must authorize an accepted claim-signing purpose. The C2PA-specific claim-signing EKU is c2pa-kp-claimSigning, identified by object identifier 1.3.6.1.4.1.62558.2.1.^[2]

Time-stamp certificates and OCSP response-signing certificates use different extended key usages. The profile requires an end-entity certificate to be authorized for no more than one of the three purposes: C2PA claim signing, time-stamp signing, or OCSP response signing. Separating these roles limits the impact of compromise and makes the validator's purpose checks explicit.

The profile also constrains certificate algorithms, key sizes, critical extensions, and chain behavior. Implementers generally should rely on a mature C2PA library or PKI component rather than writing custom X.509 validation logic. A signature can be cryptographically correct while its certificate still fails the profile.

What a trust list actually does

A trust list is not simply a collection of certificates labelled "good." It is a validator configuration that says which trust anchors are acceptable for particular certificate purposes. In C2PA 2.4, a signer trust configuration associates accepted extended key usages with one or more trust-anchor configurations. Those configurations can also define effective not-before and not-after times for the trust relationship itself.^[2]

This means trust can be both purpose-specific and time-bounded. A certification authority may be accepted for C2PA claim signing but not for time-stamping. A trust anchor can also be accepted only for signatures made during a defined period, even if the root certificate itself has a longer technical lifetime.

The official C2PA Trust List provides trust anchors for the C2PA claim-signing EKU, but the specification allows validators to support additional trust anchors and additional accepted EKUs. Private companies, publishers, government agencies, collaborative teams, or specialized industries can therefore operate domain-specific trust ecosystems while remaining compatible with the C2PA manifest format.

A validator may also offer a private credential store. This works more like an address book: a user explicitly trusts a particular signer certificate through an out-of-band relationship. A privately trusted certificate is accepted directly; it cannot act as a certification authority, and the private store is not used to trust Time Stamping Authorities.^[2]

The official C2PA trust ecosystem

The public C2PA ecosystem distinguishes three related but different resources: the C2PA Trust List, the C2PA TSA Trust List, and the C2PA Conforming Products List. They answer different questions and should not be collapsed into one generic badge.

The C2PA Conformance Program provides the governance process behind the official trust ecosystem. It evaluates generator products, validator products, and certification authorities against the specification, program requirements, security requirements, and the C2PA Certificate Policy. Public lists allow implementers and users to inspect the current state of participating products and trust anchors.^[5]

The official C2PA Trust List and Conformance Program launched in mid-2025. The earlier Interim Trust List was a temporary bridge for early implementations. It was frozen on January 1, 2026: no new entries or updates are added. Systems may still encounter credentials issued under the older model, but new implementations should support the official trust lists and make any legacy treatment explicit.^[5]

Conformance and trust remain separate from the truth of an individual asset. A conforming generator can correctly create a manifest containing a misleading assertion, just as a well-implemented document-signing system can sign an inaccurate document. Conformance increases confidence that the technical process was implemented correctly; the signer and the evidence still determine how the assertions should be interpreted.

Well-formed, valid, and trusted

C2PA defines a hierarchy of manifest states. These states are useful because they prevent a validator from turning many distinct checks into one ambiguous result.

Every trusted manifest is valid, and every valid manifest is well-formed. The reverse is not guaranteed. A structurally correct manifest can fail cryptographic validation. A valid manifest can remain untrusted because the validator lacks an applicable trust anchor, does not accept the certificate's EKU, or is operating in a different trust ecosystem.^[1]

An untrusted result should not automatically be presented as fraudulent. It may describe a legitimate private workflow, a newly issued chain not yet present in the validator's configuration, a legacy credential, or a signer intentionally using a certificate recognized only by a particular audience. The interface should explain the missing trust relationship rather than implying that the cryptography failed.

Why trusted time-stamps matter

Certificates have limited validity periods. If a validator considered only the current date, a manifest signed years ago would eventually stop validating when its signing certificate expired, even if the signature was created properly while the certificate was active.

A trusted time-stamp solves that historical problem. The Time Stamping Authority signs a time-stamp token tied to the C2PA signature value and attests that the signature existed at a particular time. The validator verifies the TSA's signature and builds a separate chain to a trust anchor in the C2PA TSA Trust List or another configured TSA trust store.^[3]

When the time-stamp is trusted and valid, the validator uses the attested time - rather than the current time - to determine whether the claim-signing certificate and its chain were within their validity periods. A valid time-stamp can remain useful after the TSA certificate itself expires, provided the attested time fell within the TSA certificate's valid period.^[3]

Without a trusted time-stamp, the current time is used for the signing-certificate validity check. Once the certificate chain is outside its validity period, the manifest can no longer satisfy that part of C2PA validation. For long-lived public content, time-stamping is therefore an operational requirement even where the base specification does not force every signing workflow to obtain one.

A trusted time-stamp should not be confused with a date written into metadata or the claim's optional claimed signing time. The TSA provides an independently signed attestation about when the signature value existed. It does not certify that the camera clock, publication date, location, or other asserted event time is accurate.

Expiration, revocation, and credential status

Expiration and revocation address different risks. Expiration is planned: the certificate reaches the end of its defined validity period. Revocation is an early termination triggered by events such as private-key compromise, mis-issuance, loss of authorization, or a serious security incident.

C2PA uses the Online Certificate Status Protocol, or OCSP, to evaluate revocation status. A signer can obtain and attach credential-status evidence around signing time, and later manifests can carry certificate-status assertions. The specification does not use certificate revocation lists for this workflow. When suitable status evidence and a trusted time-stamp are available, a validator can assess the credential at the relevant signing time.^[3]

If sufficient stapled status information is not available, an online validator may query the certificate authority's OCSP responder. The specification makes that online query optional because it can create privacy and availability concerns. A status request can reveal information about what is being validated, and an unreachable responder should not be confused with a positive revocation result.

Revocation is not magical erasure. A certificate revoked after a well-evidenced signing event does not necessarily invalidate everything signed before the revocation became effective. Trusted time and acceptable status evidence allow a validator to reason about the credential at the time the signature was created, subject to the validator's policy and the available evidence.

What a certificate identifies - and what it does not

The signing certificate identifies the signer: the credential holder associated with the private key. That signer may be an organization, service, device family, product operator, account system, or another entity defined by the issuing ecosystem. It is not automatically the individual person who clicked a button, captured a photograph, wrote a prompt, or edited the content.

The claim separately contains claim-generator information describing the non-human hardware or software component that generated the manifest. A user interface should avoid presenting the certificate subject and claim-generator name as interchangeable. One tells the consumer whose credential authorized the claim; the other tells the consumer which system generated it.

Human and organizational identity assertions can add richer identity evidence, including identity-provider attestations and role-specific claims. Those assertions are separate trust signals with their own validation profiles. Their presence does not change the basic role of the claim-signing certificate, and the certificate alone should not be stretched into a claim it was not issued to make.^[6]

Most importantly, the certificate does not vouch for the factual truth of the content or every assertion. It provides a basis for attribution. The consumer can then decide whether that signer is competent and trustworthy for the particular statement being evaluated.

A practical validation walkthrough

Consider an image signed by a C2PA-aware publishing service. The service acts as the claim generator, and an organization holds the private key and signing certificate. The signature includes the organization's signing certificate, the required intermediate certificates, a trusted time-stamp, and credential-status evidence.

A validator can process the trust layer in the following sequence:

1. Verify the claim signature against the public key in the signing certificate.

2. Check that the certificate follows the C2PA certificate profile and is authorized for an accepted claim-signing EKU.

3. Build and validate the certificate path using the supplied intermediates and an independently configured trust anchor.

4. Confirm that the trust anchor and EKU were accepted for the signature's relevant time.

5. Validate the time-stamp token against the separate TSA trust configuration.

6. Use the trusted time and available OCSP evidence to determine whether the signing certificate was valid and acceptable at signing time.

7. Return the cryptographic and trust results separately from the content assertions and the consumer's final judgment.

If all manifest-validity checks succeed and the signer chain reaches an accepted trust anchor, the manifest can be reported as trusted. The interface can say who signed it, which trust configuration was used, and what time and status evidence was available. It still should not replace that information with the unsupported statement "this image is true."

Designing trustworthy implementations

Certificates and trust lists are operational systems, not static configuration files. Their value depends on secure issuance, key protection, timely updates, revocation services, transparent governance, and clear user interfaces. The strongest implementation treats the full lifecycle as part of the product.^[4]

For claim generators and signing services

• Use a signing credential appropriate for the audience that will validate the content. Public distribution generally benefits from a chain rooted in a broadly recognized trust list; private workflows may use domain-specific trust.
• Validate the credential, chain, and EKU before signing rather than discovering incompatibility only after assets have been distributed.
• Protect private keys in a hardware-backed key store, HSM, or managed KMS where appropriate. A stolen signing key can create technically valid manifests under the compromised identity.
• Obtain trusted time-stamps and credential-status evidence at signing time whenever the content may outlive the signing certificate or must validate offline.
• Plan certificate issuance, rotation, renewal, suspension, and revocation before production launch. Do not encode a single long-lived certificate as a permanent application assumption.
• Independently verify the completed signed asset and record the exact certificate, chain, time-stamp, and status evidence used.

For validators and provenance platforms

• Keep signer trust lists and TSA trust lists separate and update them through an authenticated, auditable process.
• Preserve the exact trust-list version or snapshot used for each historical validation. A later list change should create a new evaluation, not silently rewrite the old result.
• Treat all certificates supplied by the asset as untrusted input until path validation reaches a configured trust anchor.
• Display well-formed, valid, and trusted as distinct states, and explain missing trust anchors, unavailable OCSP services, expired credentials, and failed signatures separately.
• Support private trust configurations without allowing a directly trusted leaf certificate to become an unintended certification authority.
• Do not equate conformance, certificate trust, verified identity, factual accuracy, and content integrity. They are related signals with different meanings.

For audit-grade systems, trust must be reproducible. The record should identify the validator version, trust-list snapshot, accepted EKUs, certificate path, time source, OCSP evidence, policy configuration, and result codes. That makes it possible to explain why a manifest was trusted at a particular time rather than relying on a mutable green badge.

Common misunderstandings

The simplest mental model

• The private key creates the claim signature.
• The signing certificate associates the public key with the signer.
• Intermediate CAs connect the signing certificate toward a trust anchor.
• The validator chooses which trust anchors and certificate purposes it accepts.
• The C2PA Trust List covers public claim-signing trust anchors; the C2PA TSA Trust List covers time-stamp trust anchors.
• A trusted time-stamp establishes the relevant historical time for credential validity.
• OCSP evidence helps determine the signing credential's status at that time.
• A trusted manifest is valid and signed under an accepted trust configuration.
• None of these checks, by themselves, prove that the content or assertions are factually true.

Certificates and trust lists give Content Credentials an identity framework that can operate across many tools and organizations. Their real value comes from preserving the distinctions: signature integrity, certificate validity, signer trust, product conformance, identity evidence, and factual credibility are related, but they are not the same thing.

Sources and notes

Technical source notes are limited to exact structural, normative, version-specific, or current operational claims. All linked material is published by C2PA or its official conformance program.

[1] C2PA Technical Specification 2.4, section 14, "Trust Model": signer identity and the Well-Formed, Valid, and Trusted states.

[2] C2PA Technical Specification 2.4, sections 14.4-14.5: trust-anchor configuration, private credentials, certificate profiles, EKUs, and path validation.

[3] C2PA Technical Specification 2.4, sections 15.7-15.9: signature, time-stamp, certificate-validity, and OCSP validation.

[4] C2PA Implementation Guidance 2.4, section 6, "Trust": key protection, time-stamps, status evidence, credential suitability, and private trust ecosystems.

[5] C2PA Conformance Program: official trust lists, the Conformance Explorer, and the January 1, 2026 freeze of the Interim Trust List.

[6] C2PA Human and Organizational Identity Recommendation: identity assertions that supplement machine signer identity.