The formats of the digital signature

A file called contract.pdf.p7m lands in your inbox and your computer has no idea what to do with it. Or a PDF that opens normally yet claims to be signed. Or an XML nobody explained to you. They are all digital signatures, and the reason they come in different shapes is simpler than it looks: the container depends on what you are signing.

What a digital signature actually signs

Before the formats, the mechanism. Signing does not mean encrypting the document. It means:

1. computing the document's digest (typically SHA-256);
2. transforming that digest with the signer's private key, which lives inside a smart card and never leaves it;
3. attaching the result, together with the certificate binding that key to a name.

Anyone holding the certificate can run the computation backwards and check that the digest matches. The document stays in the clear. What is protected is not confidentiality: it is attribution and integrity.

Hence the first practical question: where do I put the signature? Inside the document, next to it, or around it? Those three answers generate the families of formats.

Attached and detached

An attached (or enveloping) signature swallows the document: the signed file contains both the original bytes and the signature. Out comes a single object, which must be «unwrapped» to read the document again. That is the classic .p7m.

A detached signature lives separately: the document stays as it was, and the signature is a file alongside it holding its digest. Convenient for enormous files you would rather not duplicate inside an envelope.

Then there is the middle way, the most elegant: the enveloped signature, embedded inside the document itself without altering its format. A signed PDF remains a PDF that opens in any reader. That is how PAdES works.

The formats, one by one

CAdES — the .p7m

It is the CMS envelope (Cryptographic Message Syntax, the successor to PKCS#7), encoded in DER, that is, a binary ASN.1 structure. The filename doubles its extension — contract.pdf.p7m — because the envelope contains a PDF, but it is not a PDF.

It is the format for signing anything at all: an image, a ZIP, an executable. It does not care what is inside. It is also the format in which Italian electronic invoices, transmitted as XML, are wrapped and signed.

PAdES — the signed PDF

The signature lives inside the PDF, in a dictionary with two decisive fields. /Contents holds the CMS envelope with the signature proper. /ByteRange declares which byte intervals of the file were signed — that is, the whole PDF except the space in which the signature itself is written, because data cannot contain its own digest.

The PDF still opens anywhere. And because the signature covers a precise byte interval, the document can be signed several times by different people, each appending a new section at the end: this is the incremental update, and it allows sequential signing without destroying earlier signatures.

XAdES — the signed XML

A ds:Signature node inside the XML tree. The technical difficulty here is not cryptography: it is that the same XML can be written in syntactically different but logically identical ways — whitespace, attribute order, namespace prefixes. Signing the digest of raw bytes would be desperately fragile.

Hence canonicalisation: a procedure that rewrites the XML into a normal form before its digest is computed. Probatio implements C14N 1.0 and Exclusive C14N, with the enveloped and XPath Filter 2.0 transforms. It is the format of the Italian tax-authority interchange receipts.

JAdES — the JSON signature

A JWS (JSON Web Signature): three dot-separated parts — header, payload and signature — each in base64url. It was born in the world of web tokens and adopted by the ETSI profiles for interoperability with APIs. Probatio verifies both the compact and the flattened-JSON serialisation.

The .tsr is not a signature

In the same folder you will often find a .tsr file. It signs no one: it is the reply of a time-stamping authority, an RFC 3161 token attesting when that digest existed. A different question and a different tool — and it deserves its own guide.

Summary

Extension	Format	Container	The document is…
.p7m	CAdES	CMS / PKCS#7 in DER	inside the envelope (attached)
.pdf	PAdES	PDF dictionary with /ByteRange	the PDF itself (enveloped)
.xml	XAdES	ds:Signature node	the XML itself (enveloped)
JWS token	JAdES	header.payload.signature	the payload
.tsr	—	RFC 3161 token	not a signature: it is a timestamp

How Probatio recognises the format

It does not trust the extension. It looks at the bytes.

Two things Probatio does not do

ASiC, the ZIP container that packages documents and signatures together (ASiC-S and ASiC-E), is not supported. If you receive an .asice, unpack it first.

Countersignatures — the CMS countersignature attribute, by which a second signer signs the first signer's signature — are not extracted. Among the unsigned attributes, Probatio reads timestamp tokens, not countersignatures.

What to take away

• A .p7m is an envelope: your document is inside, and must be extracted to be read.
• A signed PDF is still a PDF: it opens, it reads, and the signature covers the intervals declared in /ByteRange.
• A .tsr is a timestamp, not a signature.
• The extension is a hint, not a fact: the format lives in the bytes.
• That a file is signed does not mean the signature is valid. That is the next question.