Trust List

A Trust List is not a passive collection; it is a curated, policy-driven manifest of approved identity providers. It answers the question: 'Who is allowed to make claims about content?'

• Allowlisting: The list operates on an allowlist principle. Any issuer not on the list is treated as untrusted, regardless of the mathematical validity of their signature.
• Granular Permissions: Advanced lists can constrain what specific claims an issuer is trusted to make. For example, a news organization's CA might be trusted for copyright assertions but not for identity assertions.
• Governance: The curation process is a governance function, often managed by an industry consortium or a chief trust officer, not an automated algorithm.

The Trust List is a runtime configuration file consumed by the Validator Engine. It is the operational database that drives the verification decision logic.

• Lookup Mechanism: During validation, the engine extracts the issuer's certificate chain from the manifest and performs a lookup against the Trust List to find a matching trusted root.
• Offline Capability: A complete Trust List can be bundled with a verifier application, enabling provenance validation in air-gapped or offline environments without relying on a live network request.
• Update Cadence: The list must be updated regularly to add new trusted issuers and, critically, to distribute revocation information for compromised CAs.

Trust is temporal. A Trust List must provide mechanisms for revoking trust when a signing key is compromised or an issuer's authority is rescinded.

• CRL Distribution Points: The list can specify where to fetch Certificate Revocation Lists (CRLs) to check if a previously valid certificate has been revoked.
• OCSP Stapling Support: It can mandate or prefer Online Certificate Status Protocol (OCSP) stapling for real-time revocation status checks without revealing the specific certificate being validated.
• 'Not After' Enforcement: The Trust List itself has a validity period. A verifier must reject any list that has expired, ensuring operators are forced to update to the latest trust posture.

A provenance Trust List is fundamentally different from the trust store in your web browser. It serves a narrower, higher-assurance purpose.

• Scope: A browser trust store must be universal to connect to any website. A provenance Trust List is domain-specific, tailored for media and content authenticity.
• Risk Profile: The consequence of a failure is different. A rogue TLS certificate enables eavesdropping; a rogue content credential enables large-scale disinformation. The Trust List's curation reflects this higher-stakes risk.
• Identity Verification: Issuers on a provenance Trust List typically undergo a rigorous, out-of-band identity verification process, unlike the automated domain validation common in Web PKI.

The software component that consumes a Trust List to perform cryptographic verification of a content credential. It checks signature validity, certificate chains, and revocation status.

• Queries the Trust List to determine if a signer is authorized
• Performs OCSP and CRL revocation checks
• Validates the entire certificate chain up to the Trust Anchor
• Returns a binary pass/fail or a confidence score

A standard digital certificate format that binds a public key to an identity verified by a Certificate Authority (CA). It forms the foundational identity primitive that Trust Lists authorize.

• Contains the subject's public key and identity attributes
• Signed by an issuer CA to establish a Chain of Trust
• Has a defined validity period and can be revoked
• Used to sign Claim Signatures within C2PA manifests

A foundational, inherently trusted source of cryptographic truth—typically a root Certificate Authority—from which a chain of trust is derived. The Trust List explicitly defines which root CAs are trusted.

• The ultimate root of the Chain of Trust
• Its public key is pre-installed in the Validator Engine
• Compromise of a Trust Anchor invalidates all downstream trust
• Managed with extreme security in hardware security modules (HSMs)

The process of querying a certificate authority's database to ensure a digital certificate used to sign a content credential has not been revoked before its expiration date. A Trust List is useless without active revocation checking.

• Uses OCSP (Online Certificate Status Protocol) for real-time checks
• Falls back to CRLs (Certificate Revocation Lists) for batch validation
• A revoked certificate in the chain invalidates the entire Provenance Verification
• Critical for responding to key compromise events

A cryptographic digital signature generated over a set of assertions within a C2PA manifest. The Trust List determines if the certificate used to create this signature is authorized.

• Binds assertions to a specific identity with non-repudiation
• Uses the private key corresponding to the public key in an X.509 Certificate
• Any tampering with the assertions invalidates the signature
• Verified by the Validator Engine during provenance checks

The complete end-to-end process of cryptographically validating all signatures, hashes, and certificate chains within a content credential. The Trust List is the gatekeeper that authorizes which signers are legitimate.

• Step 1: Validate Asset Hashing integrity
• Step 2: Verify all Claim Signatures cryptographically
• Step 3: Walk the certificate chain to a Trust Anchor
• Step 4: Confirm the signer is on the active Trust List
• Step 5: Perform Revocation Checks on all certificates