PAdES Baseline Levels: B-B, B-T, B-LT, B-LTA

Consider an invoice signed on 2026-10-09 with a certificate valid for 825 days. Five years later an auditor opens it. Three things have changed, and each is a reason for one level.

Each level contains the previous one and adds exactly one kind of evidence. That makes the level a useful contract between the producer and the recipient: "B-LT" tells a validator what it can expect to find offline.

The figure below shows the same ladder as stacked layers, and below it the timeline of a B-LTA document: the signature at t0, its signature timestamp seconds later, the validation data collected while the revocation services still answer, and then document timestamps applied repeatedly, each renewing the protection of everything before it.

Several ETSI documents cooperate. Knowing which one defines what saves a lot of searching, because the names are close.

A practical rule: you implement PAdES through a library, so the standards are what you read to settle an argument, not to write code. The shape to remember is that PAdES = PDF container (ISO 32000) + CAdES signature (EN 319 122) + timestamps (RFC 3161 profiled by EN 319 422) + validation data stored in the PDF /DSS dictionary (EN 319 142-1) + document timestamps (TS 119 142-3).

B-B is the minimum that qualifies as a baseline PAdES signature. It is a CAdES-BES signature placed in a signature dictionary with SubFilter ETSI.CAdES.detached. Besides the signature value over the digest of the /ByteRange, the signed attributes include the content type, the message digest and a reference to the signing certificate that contains a hash of that certificate (the signing-certificate-v2 attribute, which is what makes SHA-256 certificate references possible and what replaced the SHA-1 reference). The signer’s certificate and, normally, the rest of the chain are embedded.

The claimed signing time is not the authoritative one. In PDF it is stored in the signature dictionary’s /M entry, and iText fills it with SignerProperties.setClaimedSignDate. A validator must not treat it as proof of when the signing happened, because the signer controls it.

What B-B guarantees: the content was not altered after signing, and the holder of the private key of the embedded certificate signed it. What it does not guarantee: that the certificate was valid at the time, or that anything about the signature can be checked once the certificate expires. A B-B signature validates today, with the CA online, and becomes harder to validate tomorrow. For a short-lived workflow, such as a customer approving a quotation that is acted on the same day, B-B can be enough.

B-T adds a signature timestamp: the digest of the signature value is sent to a TSA, which returns a signed time-stamp token stating that this digest existed at this time. The token is a CMS SignedData object defined by RFC 3161 and profiled by ETSI EN 319 422. It is stored as an unsigned attribute of the signature (signature-time-stamp), so it does not change the signed bytes and can be added after the signature. A validator then asks a different question: not "was the certificate valid now" but "was it valid at the time the TSA vouches for".

The protocol is a single HTTP exchange. The client sends a TimeStampReq as application/timestamp-query containing a message imprint (hash algorithm plus digest), an optional nonce to prevent replay and a flag requesting the TSA’s certificate to be included in the response. The TSA answers with a TimeStampResp as application/timestamp-reply: a status, and, when granted, the token with the generation time (genTime), a serial number, the policy OID and the imprint copy. The client must check the status, the nonce and the imprint before using the token.

B-T proves when. B-LT makes the file self-contained: everything a validator would normally fetch from the network, at the time of signing, is stored in the document, so validation works offline years later even if the responders are gone. In PDF the container is the Document Security Store, the /DSS dictionary in the document catalogue, added by an incremental update (see How a PDF File Works). It has arrays of streams:

The timing matters. Revocation data must be collected after the signature timestamp exists and while the CA still publishes it, so the producer signs, obtains the timestamp, and only then fetches the OCSP responses and CRLs and appends the DSS. That is why the signature of a B-LT file no longer covers the whole file: the DSS is an incremental update after the signed revision, and this is normal and permitted because the signature validity does not depend on the DSS bytes. An inspector that reports covers whole file=false for the original signature of a B-LT or B-LTA file is reporting the correct state, not a defect.

Collecting the data needs the information in the certificates: the Authority Information Access extension with an OCSP responder URL and the CRL Distribution Points extension. A production certificate has them. The throwaway test CA built for this section does not publish either, and this has a consequence that is easy to hit. iText’s PdfPadesSigner fails for the test signer with PdfException: Neither ocsp nor crl data are available for the signing certificate or certificate is revoked. To produce a B-LT file with the test PKI you supply the revocation data yourself, for example a CRL generated by the test CA at run time with BouncyCastle and returned from a custom ICrlClient, as the section on producing all four levels shows below. In production you use the default clients and a real certificate.

A timestamp has its own certificate, key and hash algorithm, all of which age. B-LTA protects a B-LT document against that by adding a document timestamp over the whole file, including the DSS: an ETSI.RFC3161 signature with no signer, only a token from a TSA (the profile is ETSI TS 119 142-3). Because the timestamp covers the DSS and the previous revisions, an attacker who later breaks the old algorithms cannot forge new content without also forging the timestamp.

The document is then renewed. Before the TSA certificate used by the last document timestamp expires, and before its algorithms become doubtful, you add validation data for that timestamp (its chain, its OCSP responses and CRLs) to the DSS and apply a new document timestamp over the result. The chain of timestamps reaches forward in time, each one vouching for the previous evidence. iText implements the renewal as PdfPadesSigner.prolongSignatures, which adds new validation data and a new document timestamp. In the lab run of this page (test CRL for the test certificates, live FreeTSA, so the OCSP responses concern the TSA’s chain), prolonging the test document grew the DSS from 5 certificates, 2 OCSP responses and 1 CRL to 8 certificates, 4 OCSP responses and 2 CRLs, and a third signature entry with the new timestamp covered the whole file, while the previous one no longer did.

Renewal is an operational commitment, not a one-off action. For the invoices in the Bookshelf Billing scenario the decision is therefore economic: B-LT is enough when the document has to stay verifiable for a few years and the signing certificate and TSA are expected to remain checkable, and B-LTA, with a scheduled job that prolongs signatures before the TSA certificate and the algorithms age, is the answer when the retention period is long. The scheduling of such a renewal job is an ordinary batch problem, covered in Scheduling for the site’s Spring services.

iText 9.8.0 packages the four profiles in one class, com.itextpdf.signatures.PdfPadesSigner, with one method per level: signWithBaselineBProfile, signWithBaselineTProfile, signWithBaselineLTProfile and signWithBaselineLTAProfile. The OCSP and CRL clients are set on the signer (setOcspClient, setCrlClient), not passed to the profile methods; the compiled signatures of version 9.8.0 take the signer properties, the certificate chain, a PrivateKey (or an IExternalSignature) and, from level T upwards, an ITSAClient. TSAClientBouncyCastle is the TSA client, and prolongSignatures works on any signed file: it adds validation data for every signature it finds and, with a TSA client, a new document timestamp, which is how a B-LTA file is renewed. The complete walk-through, including visible signatures, certification levels and multiple signatures, is in Signing PDFs with iText. Here the example only shows the ladder.

Maven coordinates (iText Core is released under the AGPLv3 or a commercial licence; the AGPL requires that you offer the source of the whole network-facing application to its users unless you buy a commercial licence):

The signer’s keystore comes from the shared test PKI: a self-signed test root CA in billing-test-ca.p12 (alias billing-test-ca) and a signer certificate issued by it in billing-signer.p12 (alias billing-signer), with the keystore password read from the environment variable BILLING_KEYSTORE_PASSWORD. The keytool script that creates both is in Digital Signature Fundamentals; the two files were created with it for the run below and are never committed.

This example was compiled and run against iText 9.8.0 on Java 21 (the run used the JDK on the machine, and the build was set to release 21). B-B and B-T succeeded, with the timestamp coming from the live FreeTSA. As described above, the B-LT call throws for the test PKI because the signer certificate has no OCSP or CRL information, and B-LTA performs the same step first. What makes them succeed with a test CA is a custom CRL client that returns a CRL signed by the test CA at run time (caCert and caKey are read from billing-test-ca.p12 like the signer keystore above); it was also compiled and run:

Passing TestCrl.emptyCrlClient(caCert, caKey) to setCrlClient in the sign helper, in place of CrlClientOnline, produced the B-LT and B-LTA files inspected below. The test CRL is an empty list signed by the test CA, so every certificate that CA issued counts as not revoked; the client returns it only for those certificates and asks CrlClientOnline for any other issuer, because a CRL from the wrong issuer is not revocation evidence for them. It exists only to make the DSS non-empty in a lab; production code keeps CrlClientOnline and OcspClientBouncyCastle, which read the URLs from the certificate. Documentation: the iText Knowledge Base pages PAdES signing high-level API and How to enable LTV for a timestamp signature, and the Java API for PdfPadesSigner and TSAClientBouncyCastle.

A level is not a flag in the file; it is a conclusion drawn from what the file contains. A small inspector makes the definitions concrete: it lists the signatures with their SubFilter and timestamp, and reports whether a /DSS dictionary exists and how many certificates, OCSP responses and CRLs it holds. It uses SignatureUtil and PdfPKCS7 from iText’s signature module and reads the DSS directly from the catalogue.

Run on the files produced above, the inspector printed:

The numbers are those of the lab run with the test CRL and live FreeTSA and will vary with the TSA’s chain and with the OCSP responses obtained. That run used an earlier version of TestCrl that returned the test CRL for every certificate; with the issuer check shown above, the TSA’s chain gets its CRLs online, so the CRL count can differ. The inspector is a teaching aid and not a validator: it does not check any signature, chain or revocation status. A real validation, with trust anchors and policies, is the subject of Signature Validation and Long-Term Validity, and with EU DSS in Signing with PDFBox and EU DSS.

Level and algorithms are independent decisions: a B-LTA file signed with a weak hash is still weak. ETSI TS 119 312 V2.1.1 (2026-06) is the document to consult, because it is the reference of the European standards for which suites are acceptable and for how long. Its main points, as the specification states them, are:

What this means for code. The default of most libraries, SHA256withRSA, is PKCS#1 v1.5 and therefore "legacy" in TS 119 312 terms. It is still universally accepted by validators, and it is what the test PKI in this section uses, because it is what Acrobat and every PAdES validator can read today. A new service that controls both ends can choose RSASSA-PSS or SHA256withECDSA (P-256) instead. Interoperability, not security, is the reason to be careful: a signature algorithm that a recipient’s validator does not know produces an "unknown algorithm" result, not a rejection of the document, but the signature cannot then be validated. Test with the validators your recipients use.

The post-quantum algorithms are the new element in V2.1.1. They are in the standard because a document that has to be valid for decades will outlive the algorithms in use today, and a long-term archive must be re-timestamped with a quantum-resistant signature at some point. Their support in PDF producers and viewers is not universal as of 2026-10-09, and the support in iText 9.8.0 or EU DSS 6.5 was not exercised for this page, so verify it against the release notes of the library you use before promising it. The sensible interim measures are the ones B-LTA already provides: keep the signed bytes and the evidence, and renew with stronger algorithms when they become available. The signature algorithms of the timestamp token are chosen by the TSA, not by you; EN 319 422 constrains them.

PAdES describes a technical format; the law decides what the format is worth. In the European Union the regulation is eIDAS, Regulation (EU) 910/2014, as amended by Regulation (EU) 2024/1183, which entered into force in 2024 and is sometimes called "eIDAS 2". It distinguishes three kinds of electronic signature, and they are not the same thing as the four baseline levels.

A QES is thus a PAdES signature (or CAdES, XAdES) of some baseline level plus a qualified certificate on a qualified device. The reverse is not true: a B-LTA signature made with a self-issued certificate is technically excellent evidence and is not a qualified signature. In the same way, a qualified timestamp carries a presumption of accuracy of the date and time and of the integrity of the data to which they are bound (Article 42 of the regulation), which a free TSA cannot provide. The 2024 amendment adds the European Digital Identity Wallet and new qualified services such as electronic attestation of attributes, electronic ledgers, electronic archiving and the remote management of qualified signature creation devices. For the format of signatures, the main change is that the wallet will be a way of creating qualified signatures; the baseline levels remain the interoperable formats. The regulation text is at Regulation 910/2014 and Regulation 2024/1183. This page is a technical guide and not legal advice; which signature a contract or a tax rule requires is a question for the lawyer of the project, and the Bookshelf Billing invoices, being signed by the shop with a service certificate, are advanced or seal-like evidence at best unless the shop buys a qualified certificate.

A cryptographically correct signature says nothing until the validator trusts the issuing CA. Two lists decide that for the common PDF viewers.

EU Trusted Lists and the LOTL. Each Member State publishes a trusted list: a signed XML document with its qualified trust service providers and the services they provide, such as issuing qualified certificates or qualified timestamps. The European Commission publishes the List of Trusted Lists (LOTL), a signed XML file that points to all the national lists, and the validator discovers the others from it. A validator such as EU DSS downloads the LOTL, verifies its signature, downloads the national lists, and uses the result to decide whether a certificate or a timestamp unit is qualified at the date of signing. The LOTL is published at the Commission’s tools server, and the Commission’s browser for the lists is the EU Trust Services Dashboard (trusted list browser). The LOTL is a live document that changes when a provider is added or withdrawn, so a validator must refresh it and must not freeze a copy in the source tree. How DSS loads it with a refresh policy is in Signing with PDFBox and EU DSS.

Adobe AATL. The Adobe Approved Trust List is a list of roots that Adobe Acrobat and Acrobat Reader trust by default for document signing. A signature chaining to an AATL root appears with the green check "signature is valid" and without configuration in the reader. Adobe Acrobat also trusts the European Union Trusted Lists, so qualified certificates of European providers are recognised that way. Membership of the AATL is granted to CAs that meet Adobe’s technical and audit requirements, and the certificates of such CAs are the ones sold as "document signing" certificates. The details and the current programme are at Adobe’s AATL pages, which return an error to command-line tools: open them in a browser.

The test CA of this section is on neither list. A signature made with it is valid cryptographically, and Acrobat shows it as having an unknown signer until a user imports the test CA certificate (billing-test-ca.pem) as a trusted root. That is the correct behaviour, and the reason to treat the output of a test PKI as a format example, not as a delivered invoice.

For development, FreeTSA (https://freetsa.org/tsr) is convenient: no registration, SHA-256 and SHA-512 imprints, and a documented CA that you can download and use with openssl ts -verify as above. Its limits are the reason it is a test service. It is a free service of a single private operator without a service-level agreement, its policy OID in the replies observed here was the placeholder 1.2.3.4.1, it is not on any trust list, and Acrobat will not recognise its timestamp as trusted without importing its CA. Do not rely on it for documents that have legal or audit value.

A commercial TSA gives the properties that matter in production: availability with a stated service level, a documented time source and policy, audited operations, and certificates chaining to roots that readers trust. Established certificate authorities such as DigiCert and Sectigo operate public RFC 3161 time-stamping endpoints, which are typically non-qualified; qualified timestamps under eIDAS come from qualified trust service providers that appear on the trusted lists with a qualified time-stamping service, and are the only ones that carry the Article 42 presumption. Whatever the provider, read its terms before relying on it: rate limits and whether the service is free or contractually supported differ. In the code, the TSA is a single URL passed to TSAClientBouncyCastle, optionally with credentials, which a real deployment loads from a secret manager rather than source or the configuration repository; see AWS Secrets Manager and KMS or Azure Key Vault and Secrets for the pattern.

A signature-level consequence: the TSA’s own certificate is part of the evidence. A B-LT file must carry the TSA’s chain and its revocation data in the DSS, and a B-LTA file must renew the timestamp before that certificate expires. This is why the lab DSS held more than the signer’s certificates.

Finding O11 of this section’s source analysis covers the signing code in the books consulted (the 2006 text iText in Action, consulted and not reproduced). It used PdfStamper.createSignature with a PdfSignatureAppearance, the SELF_SIGNED filter and the Adobe.PPKLite handler, the SubFilter adbe.pkcs7.sha1 and SHA-1 digests. All of that is obsolete for this topic.