C2PA Timestamping & OCSP Stapling

One of the main technical challenges of content provenance is long-term validation: how can provenance be trusted after months, years, or even decades?

The trust model that C2PA runs on is similar to the trust model that the Internet runs on: X.509 certificates with a list of root anchors. This is a tried and true system — for the Internet, it is what allows us to simply trust HTTPS traffic instead of depending on anti-virus software. How this works is that each Generator Product has a secret key, which it uses to sign content, and the X.509 certificate establishes that the secret key indeed belongs to the Generator Product. This is why C2PA Certificate Authorities require all Generator Products to complete both Organization Validation (OV) and Product Validation (PV).

However, there is one key difference between digital content and network traffic. On the Internet, the network traffic is validated seconds after it is signed and sent. However, with C2PA, digital content can be validated at any time in the future. This is a problem for X.509 because it is not designed for long-term validation: the certificates expire after some period of time (max 366 days for Level 1, 90 days for Level 2).

One way to solve this is to put everything on the blockchain, but that would mean that every time content is read, a blockchain must be queried. A more lightweight, chain-agnostic method is needed. This is where timestamping and OCSP stapling come in.

Certain Timestamping Authorities (TSAs) are authorized by the C2PA to issue trusted timestamps, following RFC 3161. These are run on secure servers, synced to a trusted time source (e.g. atomic reference clocks) via specific protocols (e.g. NTP, PTP), signed with keys that live in a secure enclave (e.g. FIPS 140-3 Level 3+ HSM). As a user, you send a simple request to the TSA, and the TSA returns a secure signed timestamp.

Not all timestamps are trusted by the C2PA. In order for a timestamp to be trusted, the certificate it is signed with must be a C2PA Timestamping Leaf Certificate.

If you are using a managed C2PA signing product, it is important to check whether it includes and properly implements trusted C2PA timestamping.

If you are building your own C2PA Generator Product, you will want to find a C2PA TSA to procure timestamps from.

Actually making the network request is already handled by c2pa-rs and c2patool. Note that most C2PA TSAs will require authentication of some sort, so an X-API-Key header (or similar) will be required in the request. Currently, c2pa-rs supports this but c2patool does not. If you are using c2patool directly, the recommendation is to set up a reverse proxy that you pass into c2patool to format the requests as needed.

Test the Trufo TSA with OpenSSL:

echo "Hello, C2PA world" > test_data.txt
openssl ts -query -data test_data.txt -sha256 -cert -out request.tsq
curl -s -H "Content-Type: application/timestamp-query" \
     -H "X-API-Key: <YOUR_TSA_API_KEY>" \
     --data-binary @request.tsq https://tsa.trufo.ai/ -o response.tsr
openssl ts -reply -in response.tsr -text

Follow the timestamping quickstart for c2pa-rs, c2patool, and OpenSSL.

It is important to check what the price of the timestamps will be, because unlike the certificate which is per Generator Product instance, timestamps are per signed content. Standard industry rates for non-C2PA trusted timestamps typically vary from $0.1 per timestamp at 1K volume to $0.01 per timestamp at 1M volume, but this is just a rough estimate. Here is what we could find about existing C2PA timestamping prices:

For high-volume or high-value deployments, dedicated TSA endpoints can provide enterprise SLAs and regional deployments and are often available as a negotiated contract. For example, Trufo currently administers multi-region 99.95% SLA endpoints for enterprise clients.

While the timestamp establishes when the content was signed, the OCSP response establishes that the certificate was valid when the content was signed. Both pieces are necessary. The OCSP response must be provided by the CA that issued the C2PA Claim Signing certificate following RFC 6960.

The recommended way to use OCSP is to insert the OCSP response directly into the C2PA manifest. Many validators will not mark signed content as trusted unless this is done properly. How this works is that, when signing the content, the OCSP request is made to the CA and the response recorded in the manifest; then, validators do not need to make an OCSP request themselves in order to complete validation. This is supported by c2pa-rs but not by c2patool.

Importantly, the OCSP response can be stapled. Typically, the OCSP responses that CAs issue are valid for a short period of time (e.g. 7 days). The signing server simply needs to make OCSP requests once in a while, and reuse the most recent OCSP response when signing content.