The PAdES baseline levels

PAdES is the PDF profile of the ETSI advanced electronic signature family. Clause 6.1 of ETSI EN 319 142-1 V1.2.1 (2024-01) defines four baseline levels, and clause 6.3 table 1 states field by field which CMS attributes and which signature dictionary entries each level requires.

Clause 6.1 gives each level a sentence of intent. B-B "provides requirements for the incorporation of signed and some unsigned attributes when the signature is generated". B-T covers "a trusted token proving that the signature itself actually existed at a certain date and time". B-LT covers "the incorporation of all the material required for validating the signature in the signature document". B-LTA covers "the incorporation of electronic time-stamps that allow validation of the signature long time after its generation".

The levels are cumulative: a B-LTA file contains everything a B-B file contains. The Document Security Store and the document timestamps arrive as further incremental PDF revisions. A signature-time-stamp attribute need not, because requirement q) contemplates reserving space inside the already-allocated Contents entry: "If it is anticipated to propagate PAdES-B-B signatures to a higher conformance level, they can reserve space for the signature-time-stamp attribute that will be added to the DER-encoded SignedData object as specified in ETSI EN 319 122-1 [2]."

B-B is the signature and nothing beyond it. Table 1 marks SignedData.certificates, content-type and message-digest "shall be present" in all four level columns, and requirement a) states that "the generator shall include the signing certificate in the SignedData.certificates field". Requirement e) binds the certificate into the signed attributes: "Generators shall use either the signing certificate or the signing-certificate v2 attribute, depending on the hash function, in accordance with ETSI EN 319 122-1 [2]." Requirement l) fixes the container: "The Signature Dictionary shall contain a value of ETSI.CAdES.detached for the key SubFilter."

What B-B carries about time is a claim rather than evidence. Table 1 requires the entry with key M, which requirement g) describes as "the claimed UTC time of the signature", and marks the CMS signing-time attribute "shall not be present" in every column.

B-T introduces an outside witness. Table 1 marks the service "provide trusted time for existence of the signature" as "shall be provided" from B-T upward, and requirement n) states that "the trusted time shall be provided either by a signature-time-stamp attribute or a document-time-stamp". RFC 3161, published August 2001, describes what the token does: "The TSA's role is to time-stamp a datum to establish evidence indicating that a datum existed before a particular time."

ETSI EN 319 102-1 V1.4.1 (2024-06) clause 4.3.3.4 step 1) requires that "the time-stamp token shall cover the signature value". The timing constraint is recorded separately, in clause 4.3.3.1 NOTE 2: "Time-stamp token provides the initial steps towards providing long term validity. The time-stamp tokens need to be created before a certificate has been revoked or expired. If this cannot be achieved, validation of the created signature can fail."

B-LT stops the file from depending on services nobody in the transaction controls. Clause 5.4.1 of EN 319 142-1 introduces the Document Security Store as an extension to ISO 32000-1 "to carry such validation data as necessary to validate a signature", and clause 5.4.2.2 defines it as a DSS key in the document catalog dictionary providing "a single place where all of the validation-related information for some or all signatures in the document should be placed". Table 1 marks SPO: DSS "shall be present" at B-LT and B-LTA with cardinality at least 1.

What goes in is specified. Requirement r) states: "The full set of certificates, including the trust anchor when it is available in the form of a certificate, that have been used to validate the signature and which are not already present shall be included." Requirement t) states: "The full set of revocation data (CRL or OCSP responses) that have been used in the validation of the signer and CA certificates used in signature shall be included." Both extend to "any time-stamp token's signing certificate (i.e. a TSA certificate) already incorporated to the signature", which is what makes the B-T token survive too.

B-LTA timestamps the validation material. Requirement x) states: "Before generating and incorporating a document-time-stamp attribute, applications shall include all the validation material, which are not already in the signature, required for validating the signature." Requirement y) fixes the form: "The value of SubFilter shall be ETSI.RFC3161." Clause 5.4.3 defines the Document Time-stamp dictionary as a signature dictionary with Type DocTimeStamp. Table 1 marks SPO: document-time-stamp "shall be present" at B-LTA with cardinality at least 1, and requirement w) permits more than one: "PAdES-B-LTA signatures may have more than one document-time-stamp applied after the DSS and DSS/VRI."

Repetition is the design. EN 319 102-1 clause 4.3.5.1 states that "Before algorithms, keys, and other cryptographic data used at the time a signature was built become weak and the cryptographic functions become vulnerable, or the certificates supporting previous time-assertions expire or are revoked, the signer's document, the signature as well as any attributes contained in a signature with Long-Term Validation Material should be protected by applying one or more time-assertions", and that "the creation of time-assertions should be repeated in time before the protection provided by a previous time-assertion becomes weak and should make use of stronger algorithms or longer key lengths than have been used in the original signatures or previous time-assertions". Clause 5.4.1 of EN 319 142-1 puts the same idea in PDF terms: "The life-time of the protection can be further extended beyond the life-time of the last document time-stamp applied by adding further DSS information to validate the previous last document time-stamp along with a new document time-stamp." Each renewal is an incremental revision, so signed bytes are never rewritten.

The gap between B-T and B-LT runs in one direction only. Revocation material can be collected only while it is being published. EN 319 102-1 clause 4.3.4.1 NOTE 1 sets out the condition: "In case it is unsure that the validation data required to validate the signature will still be on-line available to the verifiers or that some verifiers cannot access that data, then it is necessary to capture that data inside the signature." A file that reached B-LT captured that material once, at signing. A file that did not is still relying on the responder to answer.

B-LTA closes the second half of the same problem, since a revocation answer means something only in relation to a time. NOTE 3 to clause 6.1 states the effect: "The B-LTA level can help to validate the signature beyond many events that limit its validity (for instance, the weakness of used cryptographic algorithms, or expiration of validation data)." NOTE 4 records the alternative: B-LT "combined with appropriate additional preservation techniques" reaches the same place, at the cost of the file no longer being self-contained.

None of the four levels says anything about who signed. A PAdES signature binds a byte range to a certificate, and from B-T upward binds that pairing to a time attested by a timestamp authority. Binding the same bytes to a named human being is a separate evidentiary problem, addressed outside the signature by authentication events, consent records and the audit record that carries them.

The instrument that used to enumerate signature levels no longer applies. EUR-Lex records Commission Implementing Decision (EU) 2015/1506 as "No longer in force, Date of end of validity: 22/02/2026; Repealed by 32026R0248". Article 5 of the replacing act is one line: "Implementing Decision (EU) 2015/1506 is repealed."

The act now in the field is Commission Implementing Regulation (EU) 2026/248 of 2 February 2026. Its Article 1(1) provides that Member States requiring an advanced electronic signature under Article 27(1) and (2) of Regulation (EU) No 910/2014 "shall recognise advanced electronic signatures, using formats or associated signature containers, that comply with the technical specifications listed in Annex I to this Regulation". Annex I carries a "PAdES Baseline Profile" row naming ETSI EN 319 142-1 V1.2.1 (2024-01) — the edition described on this page — with a footnote linking the ETSI PDF and no conformance-level qualifier attached. Article 6 provides that "Article 1(1) and Article 3(1) shall apply from 23 February 2027."

The B, T and LT letters survive only in Annex II, which Article 1(2) confines to signatures "created before 23 February 2028". The PAdES row there names ETSI TS 103 172 v.2.2.2 "with the exception of clause 9 and at conformance level B-Level, T-Level or LT-Level" — the older TS-series profile, not the EN this page describes.

OctoDoc's post-v1.0 signing design targets B-LTA at issue. It would write the chain, the OCSP responses and the CRLs into the DSS at the moment of sealing, then apply a /DocTimeStamp over the resulting revision. The planned proof file would record the level reached, the timestamp authority behind each token, and the certificate serial that signed the bytes. The intended conformance rule is independent validation: the validator would never be the library that produced the signature. The current v1.0 product does not claim B-LTA, AATL trust, a proof file, or public verification.

Nobody wants to read the contract. OctoDoc is being built so you do not have to: write a document from a prompt, ask plain-language questions about the one you were sent, and keep every one of them in a single place instead of four accounts and an inbox.

Anyone can check a sealed file with no account.

Unlimited human sends on the paid tier.