Anatomy of a cryptographically anchored PDF.
A PAdES B-LTA signature isn't just a hash of your document. It's a stack: signed bytes, trusted timestamp, embedded validation data, and an archive timestamp that re-anchors the entire chain to a moment future-you can prove. Here's what each layer does and why it matters.
Each tier closes a gap the last one leaves open.
Basic
The foundation tier. Inkbak takes the bytes of your PDF, computes a SHA-256 hash, and signs that hash with your signing certificate’s private key. The signature is encoded as PKCS#7 detached and embedded in the PDF’s signature dictionary.
Verifying the signature is a single openssl call. Any verifier — Acrobat, a court archive, a third-party validation service — can confirm the document hasn’t been altered since the moment you signed.
What B-B does not give you: proof of when the signature happened. The signing timestamp in the signature is self-declared, and your certificate will eventually expire. That’s what B-T solves.
Timestamped
After signing the bytes, inkbak hashes the resulting PKCS#7 signature value and sends it to a Time-Stamp Authority — by default DigiCert’s public RFC 3161 TSA, whose root is on the Adobe Approved Trust List (AATL). The TSA signs the hash with its own timestamping certificate and returns a signed token attesting “this signature existed at this exact moment.”
The timestamp token is embedded inside the signature as an unsigned attribute (id-aa-timeStampToken). A verifier can prove when the signature happened independent of what your signing certificate claims.
Why this matters in practice: even if your certificate is revoked tomorrow, the timestamp anchors the signature to a moment when the certificate was still valid. That moment is provable by anyone who trusts the TSA’s root.
Long-term
A B-T signature is verifiable today — but in five years, the signer’s certificate chain and the TSA’s chain will be expired, and the OCSP responders that vouched for them may be offline. A verifier in 2031 looking at a B-T PDF can’t independently confirm the chain was valid when the signature was made.
B-LT solves this by writing a Document Security Store (DSS) into the PDF as an incremental update. The DSS embeds every certificate in both the signer’s and TSA’s chains, plus the OCSP responses that proved those certificates were valid at signing time. Adobe Reader’s signature panel lights up “LTV enabled” once the DSS is in place.
The signed PDF becomes self-contained. A verifier needs nothing but the file itself — and the public root keys for whichever chains are involved — to confirm the signature was valid when it was made.
Archive
The DSS solves “I can verify it today.” It does not solve “I can verify it after the TSA’s own certificate has expired.” The OCSP responses in the DSS were signed by responders whose certificates also have lifetimes. Once those expire, the DSS becomes a frozen photograph of trust — verifiable in principle but no longer cryptographically alive.
B-LTA fixes this by stacking a second timestamp on top of the entire B-LT PDF. A new RFC 3161 token (a “Document Timestamp” with /SubFilter /ETSI.RFC3161) is requested over the whole document including the DSS, then embedded as a second signature.
The effect: the original signature is now re-anchored to the moment the archive timestamp was made. Before the archive timestamp’s own certificate expires (typically 10–15 years out), you can stack another archive timestamp on top of it. In theory the chain can be extended forever — your signature outlives any individual cryptographic identity that was used to make it.
Four objects, one chain, no proprietary anything.
A B-LTA signature isn't an inkbak format. It's ISO 32000 + ETSI EN 319 142 — open standards any verifier can read. Drop this file into Acrobat, into a CLI like openssl, into a third-party validation service, and they all see the same structure.
{
"ByteRange": [0, 100000, 132768, 5000], // signed regions, with a gap for /Contents
"Contents": { // the PKCS#7 envelope
"version": 1,
"signerInfo": {
"digestAlgorithm": "SHA-256",
"signatureAlgorithm": "RSA",
"signature": "<256 bytes>",
"unsignedAttributes": {
"id-aa-timeStampToken": { // B-T layer
"tsa": "DigiCert SHA256 RSA4096 TSA 2025",
"timestamp": "2026-06-01T18:14:22Z",
"signature": "<256 bytes>"
}
}
}
},
"DSS": { // B-LT layer (incremental update)
"Certs": [<signer-cert>, <tsa-cert>, <tsa-root>, <signer-ca>],
"OCSPs": [<signer-ocsp>, <tsa-ocsp>],
"CRLs": [<signer-crl>],
"VRI": { /* per-signature mapping */ }
},
"DocTimeStamp": { // B-LTA layer (second incremental update)
"type": "/DocTimeStamp",
"subFilter": "ETSI.RFC3161",
"timestamp": "2026-06-01T18:14:25Z", // re-anchors the whole DSS
"signature": "<256 bytes>"
}
} Every byte of this structure is defined by an open standard. The signer cert is RSA-2048. The hash is SHA-256. The timestamps come from a Time-Stamp Authority whose root is on the Adobe Approved Trust List. There is no inkbak-specific format anywhere in the file.
The when is signed by someone you trust — not us.
Every B-T (and above) signature inkbak makes is timestamped by an independent Time-Stamp Authority. The default is DigiCert's public RFC 3161 TSA, whose root is on the Adobe Approved Trust List (AATL) — Acrobat shows the timestamp as valid out of the box, with no manual trust import.
Here's the relevant moment in the signing pipeline:
async function requestTimestamp(signature: Buffer): Promise<Buffer> {
const hash = sha256(signature);
// Build a TimeStampReq per RFC 3161 §2.4.1.
const req = encodeTimeStampReq({
version: 1,
messageImprint: {
hashAlgorithm: { algorithm: '2.16.840.1.101.3.4.2.1' }, // SHA-256
hashedMessage: hash,
},
nonce: randomBytes(8),
certReq: true,
});
const res = await fetch('http://timestamp.digicert.com', {
method: 'POST',
headers: { 'Content-Type': 'application/timestamp-query' },
body: req,
});
return Buffer.from(await res.arrayBuffer()); // the TimeStampToken
} The returned token contains a TSTInfo structure: the policy OID, the hashed message we sent, the TSA's serial number, the moment of stamping (RFC 3339), and an optional accuracy field. The whole TSTInfo is signed by the TSA with its timestamping certificate.
Inkbak embeds the token as an unsigned attribute on the signer's SignerInfo (id-aa-timeStampToken). The signature itself doesn't change. The timestamp rides alongside.
Every cert, every OCSP, embedded into the file.
A B-T signature is verifiable today. In ten years, the certificate authorities and OCSP responders that vouched for the signer and TSA will be gone, and a future verifier can't independently prove the chain was valid when the signature was made.
The Document Security Store (DSS) is inkbak's answer. After signing, inkbak walks the certificate chains of both the signer and the TSA, fetches OCSP responses for each non-root certificate, and writes everything into the PDF as an incremental update. The DSS lives in the PDF catalog under /DSS and contains three arrays: /Certs, /OCSPs, and /CRLs, plus a /VRI dict mapping each signature's SHA-1 to its specific validation set.
Once the DSS is in place, Adobe Reader's signature panel reads "LTV enabled." A verifier needs nothing but the file itself.
Your signature outlives the certificate that made it.
Even the DSS has a shelf life. The OCSP responses inside it were signed by responder certificates that themselves expire. Once those expire, the DSS becomes a frozen photograph of trust — verifiable in principle, but no longer cryptographically alive.
B-LTA solves this by stacking a Document Timestamp on top of the entire B-LT structure. Inkbak requests a fresh RFC 3161 token over the whole post-DSS document, then embeds it as a second signature with /SubFilter /ETSI.RFC3161. The original signature is now re-anchored to the moment the archive timestamp was made.
Before the archive timestamp's own certificate expires (typically 10–15 years out), you can stack another archive timestamp on top of it. The chain extends forward. Your signature outlives any individual cryptographic identity that was used to make it.
There is no inkbak document warehouse.
Unsigned PDFs never leave your browser. The signing happens client-side or in an ephemeral signing context that has access to your signing certificate but does not persist your document. Once the signature is written, the signed bytes either land in your Drive (if you've connected Google) or download directly to your machine.
We don't keep a copy. There is no archive on our side, no log of what you signed, no list of who you sent it to. The cryptographic provenance lives entirely inside the PDF — anywhere the PDF goes, the proof goes with it.
A third party can verify in one command.
The recipient of an inkbak-signed PDF doesn't need inkbak to verify it. The signature follows the open PAdES standard; any compliant verifier — Acrobat, openssl, pdfsig, third-party validation services like the EU's DSS Demonstration — confirms the chain identically.
$ openssl pkcs7 -in signed.pdf.p7 -print -text -verify # returns the signed bytes, validates the PKCS#7 structure, walks # the certificate chain to a trusted root, and confirms the digest. Verification successful
For a graphical verification, drop the file into Adobe Reader. The signature panel shows: signer identity, timestamp source, certificate chain validity, document integrity, and an LTV badge once the DSS has been processed.