Timestamp Authority

How the TSA works

How the proof is constructed

You compute a hash of your data locally and submit only the hash. CNX timestamps the hash, signs the token, and returns it. The original data stays in your environment — the proof is constructed entirely from its cryptographic fingerprint.

Your data:  Transaction record, log entry, document...
                ↓
You compute:  SHA-256(data) = "a3f7b9c2..."  (32 bytes)
                ↓
You send to CNX TSA:  just the hash
                ↓
CNX returns:  Signed token containing { hash + genTime + serial }
                ↓
You store:  original data + token together

This has two consequences. First, there is no privacy exposure — CNX cannot read your records. Second, the link between the token and your data is cryptographic: if even one byte of the data changes, the hash changes, and the token no longer matches.

What the token contains

The timestamp token (TimeStampToken, RFC 3161) is a DER-encoded ASN.1 structure containing:

  • messageImprint — the hash algorithm and hash value you submitted
  • genTime — the UTC time CNX received and signed the request
  • serialNumber — a unique identifier for this token
  • policy — the CNX TSA policy OID
  • signature — CNX’s digital signature over all of the above, using the TSA signing key held in a hardware security module

The signature is made with a certificate issued from the CNX private CA, with Extended Key Usage restricted exclusively to id-kp-timeStamping (OID 1.3.6.1.5.5.7.3.8). This certificate cannot be used for any other purpose.

Verification

Anyone with the CNX TSA CA certificate can verify a token:

  1. Check the token signature against CNX’s TSA certificate
  2. Check that CNX’s certificate chains to the CNX TSA CA
  3. Check that the hash in the token matches SHA-256 of the original data
  4. Read genTime — this is the attested timestamp

If all three checks pass: this data existed in this exact form at this time, as witnessed by CNX. If any check fails: the token is invalid or the data has been modified since timestamping.

The signing infrastructure

The signing infrastructure is hardware-bound at every layer.

CNX’s root CA key is held in a hardware security module — non-exportable by hardware design and never in plaintext outside the device. Each TSA node generates its own signing key inside the VM’s hardware-backed vTPM, submits a Certificate Signing Request, and receives a TSU certificate signed by the root CA. The node’s private key was generated in its vTPM and never leaves it — the HSM signs the certificate, not the key.

Every timestamp token is signed by the node’s vTPM-bound key under a certificate that chains to the HSM-held root CA. All private keys are hardware-bound. If a node is decommissioned or its certificate revoked, the root CA and all other nodes are unaffected.

All signing operations use ECDSAP256SHA256: NIST P-256 curve with SHA-256, specified in NIST FIPS 186-4. Key operations are logged for audit. The same root CA infrastructure underpins CNX DNS Shield’s DNSSEC key management — the CA, algorithms, and HSM protection are detailed in the DNS Compliance section.

Non-repudiation — bound to the moment of receipt

Each token is bound to the exact moment CNX received the request. The genTime is derived from CNX’s atomic oscillators at the instant of receipt — it cannot be specified by the requester, configured by an operator, or obtained after the moment has passed. A token for a given moment can only be issued at that moment.

This property — that past moments cannot be re-timestamped — is what gives the attestation its evidentiary weight. The record and the token were created together, at the same instant, witnessed by an independent party. That is the definition of non-repudiation.

The embedding problem — and how it is solved

A common question: if the token proves the hash, and you put the token inside the document, the document changes, the hash changes, and the token no longer verifies. You cannot embed the proof inside the thing it proves.

There are three established patterns for handling this.

Pattern A — PDF/PAdES embedded timestamp

The PDF specification (ISO 32000, PAdES standard) defines a mechanism where the signer reserves a placeholder byte range inside the PDF structure, hashes everything except those placeholder bytes, gets the token for that hash, then inserts the token into the placeholder. Verification skips the same byte ranges that were excluded when hashing.

The result: the token is inside the PDF file and does not invalidate the hash — the verifier knows to skip it. The timestamped PDF is the complete record. No separate file to manage.

In Adobe Acrobat Pro — one-time setup:

  1. Edit → Preferences → Signatures → Document Timestamping → More…
  2. Click New… · Name: CNX TSA · URL: https://tsa.cnx.net.kh/ · OK
  3. Set as default

To timestamp any PDF after setup: Tools → Certificates → Timestamp → save. Adobe Reader will display the timestamp in the signature panel: “Document timestamp: [date] — CNX TSA.” Any modification to the PDF after this point is immediately visible as a broken certification. That is the complete workflow.

In LibreOffice — free, Mac, Windows, and Linux:

When exporting any document to PDF: File → Export as PDF → Digital Signatures tab. Enter https://tsa.cnx.net.kh/ in the Timestamp Authority URL field. The exported PDF will contain an embedded PAdES-T timestamp. No separate file, no additional setup. LibreOffice handles this natively for any document type it can open — Writer, Calc, Impress.

Pattern B — Sidecar file

For non-PDF documents, data records, and log files, the token is stored as a separate file alongside the original. The original is never modified.

contract-v3.pdf      ← document, unchanged
contract-v3.pdf.tsr  ← timestamp token

The token contains the document’s hash; the document’s hash verifies against the token. Neither file references the other by name or path, so both can be moved or renamed without breaking verification as long as they are presented together.

Pattern C — Manifest envelope

Create a manifest file listing all documents with their individual hashes. Stamp the manifest. One token covers all documents at once without modifying any of them.

{
  "manifest_version": "1",
  "files": [
    {"name": "loan-agreement.pdf",  "sha256": "a3f7b9..."},
    {"name": "schedule-a.xlsx",     "sha256": "c8d2e1..."},
    {"name": "id-verification.pdf", "sha256": "f4b8a3..."}
  ]
}

The token proves all listed documents existed in those exact states at the moment of stamping. Standard pattern for multi-document agreements, release packages, and audit bundles.

For practical code examples — backup attestation, audit log rolling stamps, code signing, PDF signing — see the Integration guide.