Building Your Own RFC 3161 Timestamp Authority on AWS KMS and Lambda

A C2PA signature proves who signed. Without a trusted timestamp, it does not prove when, and backdating is trivial. Most integrations solve this by calling a third-party TSA (Time Stamping Authority) and inheriting its latency, cost, and trust assumptions. We run our own RFC 3161 authority as a serverless service: KMS holds the signing key, DynamoDB guarantees unique serial numbers, and one ASN.1 trap taught us more about DER encoding than any spec document.

Why run your own TSA

Evidence timestamps must be verifiable against infrastructure you can explain to an auditor. An external TSA adds a third-party dependency to every protect call, with latency on the critical path of capture. A serverless TSA scales with the API itself, and the trust story stays inside one threat model. This does not automatically replace every third-party compliance requirement, and RFC 3161 is not mandatory for every C2PA manifest, but for our evidence pipeline, owning trusted time is the right default.

Where trusted time enters C2PA

The COSE layer requests a timestamp over the message imprint of the signature. The token goes into the signature's unsigned attributes, and validation later checks the token and its relationship to signer validity. Our library keeps this behind a one-method interface, TimestampProvider.getSignedTimestamp(request) (part of our core c2pa-ts library), so the same code can talk to our API, a local provider in tests, or a native bridge on mobile.

The serial number problem

RFC 3161 requires a unique serial number per token, and uniqueness across a distributed fleet of Lambdas is the kind of requirement that looks trivial until it is not. Our scheme: a DynamoDB atomic counter provides the uniqueness, then we hash the counter value with a salt stored in SSM. SHA-1's 160-bit output fits the serial field, and the salt prevents serial prediction and enumeration. Coordination-free, stateless beyond the counter, and boring in exactly the way security infrastructure should be.

The DER constructed-string trap

A TimeStampResp wraps its content in an EncapsulatedContentInfo. Pass the content to the constructor and the library helpfully chunks it into 64 kB pieces, turning a primitive OCTET STRING into a constructed one. DER forbids constructed strings, and several timestamp parsers reject the result. The signature is valid, the structure is plausible, and interop fails anyway.

The fix is three lines and a comment: construct the object first, then set the content property directly so the bytes stay untouched. This is the part that tripped us up, and it is invisible until your tokens fail in someone else's verifier.

KMS as key custodian

The TSA private key never leaves KMS. The Lambda builds the TSTInfo, assembles the signed attributes, and asks KMS to sign the DER-encoded payload via SignCommand. Certificates and chain load from SSM at cold start. The private-key operation is an API call with audit logging; there is no key material in the function to leak.

Frequently asked questions

Is an in-house TSA eIDAS-qualified? No. Ours is infrastructure for evidence timestamps inside our trust layer, not a qualified trust service. Deployments that need qualified timestamps can plug an external qualified TSA into the same TimestampProvider interface.

What does a timestamp prove about the content? That the signed digest existed at the stated time, according to the TSA's clock and key. It proves nothing about capture time on its own, which is why it complements, and does not replace, sensor-sealed metadata.

Why not a blockchain timestamp? Anchoring gives ordering against a public ledger but adds confirmation latency and cost per event. RFC 3161 gives an immediate, standards-based token that C2PA validators already understand.

Trusted time looks like a small supporting service until you build one. Then it is ASN.1, serial numbers, and key custody, and every one of those details is load-bearing.