Skip to content
AssinaJá

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

Section titled “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
Completion Report seal (AATL, DocMDP=1) At completion, on the report — not the document The evidence report permits no change at all

The certification seal, applied before any signature

Section titled “The certification seal, applied before any signature”

Documents published from the wizard are sealed at send time, before the first signer touches them — except those that arrive already signed: a PDF uploaded with signatures inside carries no seal, because the seal would have to be the file’s first signature, and it accepts co-signing by Chave Móvel Digital only. 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 PAdES-BES, or PAdES-LTV with the archive timestamp (ETSI TS 102 778). Not an EN 319 142-1 baseline profile — see below

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

Section titled “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.

Visual signatures go in as annotations

Section titled “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.

The qualified signature with Chave Móvel Digital

Section titled “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

Section titled “SCAP seals, where attributes are integrated”

With professional attributes (SCAP), the document carries one additional signature per certifying body, attesting the capacity in which the signer signed. What that proves, and what is written on the stamp, is in CMD and CMD with Professional Attributes.

The Completion Report carries its own seal

Section titled “The Completion Report carries its own seal”

The evidence report is sealed with the same AATL certificate, but at DocMDP=1 — it permits no change at all, while the document keeps the DocMDP=3 described above. What it contains is in What is in the completion report.

Long-term validation (LTV)

Section titled “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 material is what makes Adobe show the signature as LTV enabled.

An honest note on the profile’s name. The European Commission’s validator (EU DSS) classifies the seal as PAdES-BES — or PAdES-LTV where the archive timestamp is present — which are ETSI TS 102 778 profiles, and not as an EN 319 142-1 baseline profile (B-T, B-LT, B-LTA). The technical material is there; what differs is the classification. The signature policy says the same.

At completion, an archive timestamp covering the whole file — including that validation material — is appended. The validator then reports it as PAdES-LTV, and the “changes after the last signature” warning goes away.

The timestamps come from qualified European timestamping authorities, tried in a fixed priority order, falling through to the next one on failure — not a rotating list. For each signature’s timestamp the first is the Citizen Card TSA (IRN/AMA), then IZENPE, the Belgian BOSA, Sectigo Europe, BalTstamp and ACCV. For the archive timestamp the Citizen Card TSA is deliberately left out: its token does not carry the full chain, and with it Adobe shows “Signed by Unknown”. 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 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, because that check depends on the OCSP/CRL services of the time still answering.

Keep the pair. That is why you archive the signed PDF and the Completion Report, together — see Validate a signed document.

The limits, stated plainly

Section titled “The limits, stated plainly”

The legal limits — the platform seal is AES, not QES, and only Chave Móvel Digital produces a qualified signature — are in Legal validity. This page’s technical limit is a single one: the CMD signature stays at B-T, which is why the PDF + Completion Report pair has to be kept — see Long-term validation (LTV).

Section titled “Related”