A secure final document

The file that comes out at the end is not the PDF that went in with images pasted on top. It is a cryptographically sealed document, with every revision verifiable, carrying the material needed to validate it years from now — without the platform, without an internet connection, and without our help.

This page describes, layer by layer, what is in there.

The layers, at a glance

Layer	Applied when	What it guarantees
Platform certification seal (AATL, DocMDP=3)	At send time, before anyone signs	Integrity: page content is locked
Visual signatures (annotations)	As each signer signs	Visible authorship, without breaking the seal
Qualified CMD signature	If the signer uses Chave Móvel Digital	QES — equivalent to a handwritten signature
SCAP seals	Where professional attributes are integrated	The professional capacity, attested by the certifying body
LTV material + archive timestamp	At sealing and at completion	Long-term, offline verifiability

The certification seal, applied before any signature

Every document published from the wizard is sealed at send time, before the first signer touches it. The seal is an invisible certification signature, applied server-side.

Certificate	Sectigo AATL Document Signing (rmb-aatl-signing)
Issued to	RMB - SISTEMAS DE INFORMACAO LDA — the entity operating AssinaJá
Private key	Azure Key Vault Premium HSM, non-exportable — it never leaves the module
eIDAS level	AES (Art. 26)
PAdES profile	B-LT, raised to B-LTA by the archive timestamp

AATL is the Adobe Approved Trust List. Adobe Reader trusts it by default, which is why the document opens with a green check without the reader having to install or configure anything.

What DocMDP=3 permits and forbids

The seal writes /Perms/DocMDP with /P 3. From then on the PDF accepts only three things: form-field filling, additional signatures, and annotations. Any change to page content invalidates the seal, and the PDF reader shows the document as altered. Adobe Reader states exactly that: form filling, signing and commenting are allowed, and no other change is permitted.

Why this matters even for a document with simple signatures

A document signed only with visual signatures still leaves as a cryptographically sealed PDF, with a qualified timestamp and tamper detection. The signer’s signature is still SES — what changes is that the document can no longer be altered unnoticed.

Visual signatures go in as annotations

Each visual signature — signature or initials image, name, date — is written as an annotation with its own appearance stream, not drawn onto the page.

The reason is the rule above: under DocMDP=3, annotations are a permitted change and page content is not. Writing the signature onto the page would invalidate the platform seal; writing it as an annotation leaves it intact.

Each signature is added in an incremental revision: nothing already written is rewritten. That is why several qualified signers in a row work — the third signer’s signature never touches the byte range covered by the first.

If Adobe reports “annotations modified”

That is an informational note, not an invalidation. Each new signature appends a reference to the page’s annotation list, and Adobe flags the list changing — not the content of the annotations, which stays byte-for-byte identical. /P 3 permits precisely this.

The qualified signature with Chave Móvel Digital

When a signer uses Chave Móvel Digital, what lands in the PDF is a QES produced with a qualified certificate issued by AMA, a qualified trust service provider on the Portuguese EU Trust List. The private key lives in AMA’s HSM — never on the signer’s phone, never in AssinaJá.

Technically it is a CAdES-BES container (ETSI.CAdES.detached, with the content-type, message-digest and signing-certificate-v2 signed attributes, SHA-256) sealed with a qualified timestamp. The European Commission’s DSS validator classifies the result as QESig / TOTAL_PASSED, at the PAdES-BASELINE-T profile.

See Qualified signatures with CMD.

SCAP seals, where attributes are integrated

With professional attributes (SCAP), the document carries additional signatures — one per certifying body — attesting the capacity in which the signer signed.

The difference is one of kind, not degree: CMD proves who signed; SCAP proves in what capacity, and it is the professional body itself making that statement, not the signer and not AssinaJá.

Being activated

Professional attributes are finished and go into production in the coming days. Until then, documents carry the remaining layers on this page.

Long-term validation (LTV)

A signature can only be validated if, at verification time, it is still possible to establish that the certificate was valid when it was used. Years later, the services answering that question may no longer exist. That is what LTV solves: keeping the answers inside the file.

At sealing time, AssinaJá collects the OCSP/CRL responses and the chain certificates and writes them into the PDF, in a Document Security Store (/DSS) with a per-signature entry (/VRI). That is what takes the platform seal to the PAdES B-LT profile, and what makes Adobe show the signature as LTV enabled.

At completion, an archive timestamp covering the whole file — including that validation material — is appended. The document becomes PAdES B-LTA, and the “changes after the last signature” warning goes away.

The timestamps come from a rotating list of qualified European timestamping authorities, tried in order and falling through to the next one on failure — the Citizen Card TSA (IRN/AMA), IZENPE, the Belgian BOSA, Sectigo Europe, BalTstamp and ACCV. No document goes without a timestamp because one service is down.

The practical effect of all this is a single one: whoever receives the PDF validates it with what is inside it. No internet access required, and no AssinaJá.

The limits, stated plainly

This page describes real protections; it would be less useful if it did not say where they end.

The platform seal is AES, not QES. The Sectigo AATL certificate guarantees integrity and identifies the service provider, but Sectigo is not on the EU Trust List as a qualified provider. The seal does not turn a simple signature into a qualified one.

Only Chave Móvel Digital produces a qualified signature. That character comes from AMA, not from AssinaJá — which prepares the document, hands over the cryptographic digest and assembles the result.

The CMD signature stays at B-T, not B-LT. LTV enrichment runs for CMD too, but the Citizen Card certificate publishes no revocation access point that lets it be embedded reliably. The signature is fully valid; what gets harder is verifying it many years after the certificate has expired.

Keep the pair. Because of the point above, archive the signed PDF and the Completion Report, together — see Validate a signed document.

Related

• Validate a signed document — how to confirm all of this without AssinaJá
• Signature levels
• Qualified signatures with CMD
• Audit trail
• Legal validity