C2PA Trust Lists: How to Review Signer Trust

Record which trust store the validator used

Keep each validation run as a dated record. If a trust list or local setting changes later, retain the earlier configuration and output. The new run records what the later configuration accepts; it does not rewrite the first observation.

A C2PA validator evaluates signers against accepted Extended Key Usage values and corresponding X.509 certificate trust anchors. For the C2PA claim-signing EKU, the specification requires the trust-anchor list to include the signer trust anchors supplied by C2PA, while allowing other configured anchors and opt-in lists. Start a review by recording the validator, its version, the EKU shown, and the trust store or list selected. A bare label such as ‘trusted’ hides the configuration that produced the result.

Keep signer trust and time-stamp trust in separate rows. The specification requires a separate X.509 trust-anchor list for Time Stamping Authorities. A trusted signer result does not silently establish that the time-stamp used the same trust path, and a time-stamp result should not be copied into the signer field. Preserve the exact status text for each check.

Treat the certificate chain as input to validate

The x5chain header can carry a certificate or an ordered certificate chain. The quoted RFC requirements in the C2PA specification say certificates in this parameter are untrusted input. A self-signed certificate in the header must not update the validator’s trust anchors without out-of-band confirmation. Record the end-entity certificate and the path the validator built; do not treat presence in x5chain as acceptance.

If validation fails, save the file, the complete validator output, and the certificate details displayed by the tool. Report the narrow result, such as ‘this validator did not build an accepted signer path with the selected trust configuration.’ Do not convert that technical result into a claim that the media is fake or that the signer acted dishonestly.

Keep private credentials within their stated scope

A validator may let a user maintain a private credential store for credentials trusted through an out-of-band relationship. The specification limits that store to signed C2PA manifests, excludes time-stamp validation, and says entries cannot issue credentials or serve as trust anchors. It also says the store must not be pre-populated and that additions or removals happen only at the user’s request.

When a private credential produces the result, label it explicitly. Record who requested the local trust decision and what independent relationship supported it if that information is available. Do not present a local address-book decision as membership in the C2PA Trust List. This recording method is an operational recommendation from this article, not a required C2PA case-management format.

Read trust and claim contents as different evidence

Certificate trust answers a constrained question about a signing credential and an accepted validation path. It does not establish that every assertion in the signed claim is accurate, that the depicted event happened, or that the surrounding caption is correct. Read the manifest assertions separately, preserve their wording, and verify real-world claims with the publisher’s original context and independent evidence.

If a saved image, video, audio file, or text needs another form of review, DeepFakeCheck can provide a probabilistic risk signal. That analysis does not validate an X.509 path, identify a C2PA signer, or confirm a time-stamp. Automated analysis also has false positives and false negatives: authentic material can be flagged, and synthetic or altered material can be missed. Store the detector output apart from the credential result.

Leave a reproducible trust record

A useful review log names the inspected file, validator and version, accepted EKU, signer trust store, end-entity certificate, path result, TSA result, any private-credential decision, displayed assertions, and unresolved real-world claims. Preserve failures and unknowns without filling gaps by inference.

Another reviewer should be able to open the same file, select the documented trust configuration, repeat the certificate and time-stamp checks, and see which conclusions came from credential validation, content analysis, or external fact-checking.

Sources

• C2PA, “C2PA Technical Specification — Trust Lists”: https://spec.c2pa.org/specifications/specifications/2.2/specs/C2PA_Specification.html#_trust_lists