C2PA Credential Revocation: How to Review Revoked Signing Certificates
Preserve the file and the complete validator output
Save the exact file under review before opening it in a C2PA-compatible validator. Record where it came from, when you obtained it, its filename, and the validator name and version. Keep the full output, including informational and failure codes. This evidence log is an operational review method proposed here, not a record format required by C2PA.
This review asks what revocation status the validator established for the signer's certificate and the CA certificates in its trust chain. Certificate status is one part of claim-signature validation. It does not establish when the media was captured, whether its caption is accurate, whether the depicted event occurred, or whether the file was generated by AI.
Separate CA checks from the signer certificate
C2PA 2.2 requires a validator to attempt to discover the revocation status of the signer's certificate and every CA certificate in the trust chain. For CA certificates, the specification points to the Authority Information Access extension and says the validator should use relevant OCSP responses included in the C2PA Manifest when AIA indicates that OCSP is available.
If a CA certificate was revoked at the time indicated by a trusted time-stamp, or at the current time when there is no trusted time-stamp, the claim signature is rejected with signingCredential.untrusted. Record which certificate the result concerns, the time basis used, and the exact status. Do not collapse a CA-chain failure and a signer-certificate result into one generic red badge.
The signer certificate follows a separate sequence. C2PA says that a credential is treated as not revoked when the certificate does not support revocation status or the issuer provides no query method. That rule is not the same as a fresh responder confirming good status, so retain the reason shown by the validator.
Trace the OCSP evidence and its time basis
A claim generator may staple OCSP responses in the rVals header of the COSE_Sign1 structure. Later claim generators may add certificate status assertions in other manifests in the same C2PA Manifest Store. When several responses are available, the specification tells the validator to try them until one passes validation and then ignore the others.
For a manifest-store OCSP response, accepted RFC 6960 response data, an authorized responder, certificate status, and timing all matter. C2PA treats removeFromCRL like a good response because it means an earlier certificate hold has been removed. A qualifying not-revoked result produces signingCredential.ocsp.notRevoked; a certificate revoked at signing produces signingCredential.ocsp.revoked and rejects the claim. Preserve the full code instead of shortening both outcomes to “OCSP checked.”
If the Manifest Store has no usable revocation information, an online validator may query the OCSP responder. The specification makes that query optional because it can reveal the identity of the asset being validated. A skipped query produces signingCredential.ocsp.skipped; an attempted query that receives no response produces signingCredential.ocsp.inaccessible. Neither informational code should be rewritten as a confirmed revocation.
Keep credential trust, detection, and event verification apart
A false positive can arise when a reviewer treats skipped, inaccessible, or missing detail as “revoked.” A false negative can arise when a reviewer records only that a manifest exists while discarding untrusted or ocsp.revoked. Keep unknown, informational, success, and failure results distinct, and preserve the time basis used for the decision.
If you separately submit the saved file to the DeepFakeCheck media risk checker, store that probabilistic result in another section of the case record. Automated detection can flag authentic media or miss synthetic or altered media. It does not issue C2PA OCSP codes, validate a certificate chain, or repair a failed signature.
Verify real-world claims through the original publication, the account or organization presenting the file, the stated date and place, and independent evidence about the event. End the review with the file identifier, validator and version, certificate role, OCSP source, time basis, exact status codes, unresolved fields, separate detector output if used, and the action taken.
Sources
- C2PA, “C2PA Technical Specification — Validate the Credential Revocation Information”: https://spec.c2pa.org/specifications/specifications/2.2/specs/C2PA_Specification.html#_validate_the_credential_revocation_information
Need to check a suspicious file?
Open the matching detector and interpret the result alongside the source and context.
Open Detector