PDFPipe

Signatures, encryption and attachments / PAdES signature levels

PAdES signature levels B-B, B-T, B-LT and B-LTA

The four European profiles for PDF signatures, each adding what the one below it needs to still be verifiable years later.

Where this API stands

This is not something a renderer emits. It is applied to a finished file by a step that comes after rendering, so the honest answer is about where the boundary falls. None of this is produced by this API, which does not sign, does not timestamp and does not maintain a Document Security Store. The relevant thing to plan around is that B-LT and B-LTA both work by appending validation material and timestamps as incremental updates, so they assume the file is otherwise untouched after signing. Any step you were planning to run after the signature, including this API's password protection, has to move before it.

What the standard requires

The requirements as a checker enforces them, rather than as a procurement document paraphrases them. A file satisfies all of these or it satisfies none of them.

  • B-B is the baseline: a CAdES signature embedded with /SubFilter /ETSI.CAdES.detached, carrying the signing certificate and the basic signed attributes.
  • B-T adds a trusted timestamp over the signature, which proves the signing happened before a point in time rather than relying on the signer's clock.
  • B-LT adds the validation material, meaning the certificate chain, CRLs and OCSP responses, in a Document Security Store so verification does not depend on those services still being online.
  • B-LTA adds a document timestamp over the whole thing, and further document timestamps can be applied later to extend validity past the expiry of the algorithms used.
  • Each level is a superset of the one below, so a B-LTA signature is also a valid B-B signature to a verifier that only checks that far.

Who asks for this

Anyone signing under eIDAS in the EU, and anyone whose documents have to be verifiable for longer than a certificate lifetime. The practical trigger is a retention requirement: a contract kept for ten years signed at B-B becomes unverifiable when the certificate expires and the revocation information is no longer published, which is not a theoretical problem.

What to do about it

Pick the level from the retention requirement, not from the tooling. B-B for something that will be verified this week, B-T where the time of signing matters, B-LT where the document outlives the certificate, B-LTA where it outlives the algorithms. The DSS library from the European Commission implements all four and is the reference most vendors are tested against. Whichever level you choose, you also need a timestamp authority, and that is a service with a cost rather than a library.

How to check a file rather than assume

The DSS demonstration validator reports the level it detected and the qualification of the signature against the EU Trusted Lists, which is the authoritative answer for an eIDAS question. Acrobat verifies the signature but does not name the PAdES level, so it will tell you a signature is valid without telling you it is only valid today.

The mistake people make here

Signing at B-B and archiving. The signature is valid at the moment it is made and stays valid for as long as the certificate is current and the revocation service is answering. Some years later the certificate has expired, the CRL is gone, and a verifier cannot tell the difference between a signature that was valid when made and one that never was. The validation material has to be captured at signing time, which is what B-LT exists for.

Frequently asked

Does this API produce PAdES signature levels?

A step after rendering. None of this is produced by this API, which does not sign, does not timestamp and does not maintain a Document Security Store. The relevant thing to plan around is that B-LT and B-LTA both work by appending validation material and timestamps as incremental updates, so they assume the file is otherwise untouched after signing. Any step you were planning to run after the signature, including this API's password protection, has to move before it.

Can I turn on the pdf_a option and be done?

No. The option writes an XMP packet declaring PDF/A-1b into the document catalogue, and the render response comes back carrying a warning that says in as many words that this is best-effort and that full conformance requires tagged structure and an embedded ICC profile. It is a claim written into the file, not a certificate earned by it, and a validator checks the claim against the bytes. Read the warning array in the response rather than taking the absence of an error as a pass.

Should I convert before rendering or after?

After, always. A conformance converter rewrites colour, embeds profiles, sets boxes and stamps metadata on a finished PDF. Trying to satisfy a conformance target from the source side means guessing at what the converter would have done, and the guesses that go wrong are expensive: flattening transparency you did not need to flatten changes what the page looks like.

Standards this one is confused with

The neighbours that matter are the ones people mistake for this, not the ones that sort next to it.

Conformance is decided after a file exists. Render the document, then check it, then convert only what the checker actually flags.