Short answer. The signature format is determined by three things: the file type, where the signature lives, and how long it has to remain verifiable. The practical rule is: for arbitrary files — CAdES (the classic .p7s); for PDFs that people will read — PAdES (the signature inside the PDF itself); for XML exchange between systems — XAdES; and to hand over the original and the signature as one file — an ASiC container. The cryptography inside is the same — a DSTU 4145 signature plus a hash; the only difference is the "wrapper" and the longevity level. In DSTUcrypt all four families — 16 formats — are available through a single format option.
Why different formats exist at all
When a key applies a signature, it signs not the file itself but its short fingerprint — the output of a hash function (in Ukrainian QES that is DSTU GOST 34.311-95 or the modern Kupyna under DSTU 7564:2014). Then this signature value has to be "put" somewhere — and that is where formats come in. The European ETSI family of standards defines several *AdES (Advanced Electronic Signature) families, and each answers three questions in its own way:
- What file type are we signing? An arbitrary binary file, a PDF, or XML — each has its own natural format.
- Where does the signature live? As a separate file alongside, inside the document itself, or in a shared container together with the original.
- How long must it "live"? A basic signature is verifiable while the certificate is valid; levels with timestamps and revocation data remain provable for years.
Answer these three questions for your task, and you get the right format almost automatically.
CAdES (.p7s): the universal CMS signature
CAdES is the oldest and most widespread family: the signature is packaged in a CMS (Cryptographic Message Syntax) structure, and the file usually has the .p7s extension. You can sign anything — a document, an archive, an image, binary data. CAdES is what people most often mean when they simply say "a digital signature file".
CAdES levels historically use the "old" nomenclature:
| format | Level | What it adds |
|---|---|---|
| CAdES-BES | basic | a signature without the network; verifiable while the certificate is valid |
| CAdES-T | + timestamp | a qualified TSP timestamp fixes the moment of signing |
| CAdES-C | + references | references to the certificates and OCSP/CRL needed for full verification |
| CAdES-XL | + full data | the certificates and OCSP/CRL themselves are embedded in the container — long-term offline verification |
There is also an archival level, CAdES-A (alias CAdES-LTA), with an archival timestamp. Mind the nomenclature: in CAdES the "with timestamp" level is written CAdES-T, not "CAdES-B-T" — only XAdES and PAdES use the baseline form of the name.
Attached or detached: where the data itself lives
A CMS signature comes in two kinds. Attached — the document is packed inside the .p7s together with the signature: a single file that is convenient to send, but reading its content requires a tool that can "unpack" it. Detached — the .p7s contains only the signature, while the original file lives alongside, unmodified: it can be opened as usual, but the validator needs both files to verify it.
In DSTUcrypt this is a single boolean option, detached: true (applies to CAdES). The practical rule: if the recipient is a system that expects a "file + signature" pair, go detached; if the document has to travel by email as a single attachment — attached, or an ASiC container.
PAdES: the signature lives inside the PDF
PAdES is a signature profile specifically for PDF: the signature value is embedded into the structure of the document itself. The main advantage is that the file remains an ordinary PDF: any viewer will open it, and tools like Adobe Acrobat will even show a signatures panel. No separate .p7s files that get lost in transit.
PAdES levels follow the ETSI baseline scheme: PAdES-B-B (basic), PAdES-B-T (+ timestamp), PAdES-B-LT (+ long-term validation data), PAdES-B-LTA (+ archival timestamp). For contracts and documents that people will read, PAdES is almost always the right choice: the recipient needs no explanation — they just open the PDF.
XAdES: the signature for the XML world
XAdES is a signature in XML markup (based on XML-DSig). It is the language of systems: electronic reporting, B2B exchange of structured documents, integrations where the signed XML is then parsed automatically. The levels mirror PAdES: XAdES-BES, XAdES-B-T, XAdES-B-LT, XAdES-B-LTA.
A nuance people often discover too late: support for Ukrainian DSTU 4145 keys in XAdES is a rarity among libraries. DSTUcrypt has it out of the box: XML signing works with DSTU 4145 keys paired with the DSTU GOST 34.311-95 hash (the default) or with Kupyna-256 (DSTU 7564:2014) — the algorithm pairs dstu4145-gost34311 and dstu4145-dstu7564-256.
ASiC-S and ASiC-E: the original and the signature in one container
ASiC (Associated Signature Container) is a ZIP archive with a standardized internal structure: the original files sit next to the signature. The result is an "envelope" that solves the biggest headache of detached signatures — the files can no longer get separated. Bonus: the container's contents can be inspected with an ordinary archiver.
| Container | File | Contents | Levels |
|---|---|---|---|
| ASiC-S (simple) | .asics | one file + a signature | ASiC-S-BES · ASiC-S-T |
| ASiC-E (extended) | .asice | several files under one signature | ASiC-E-BES · ASiC-E-T |
ASiC is convenient for document bundles: a contract plus its annexes travel as one file, and the signature covers them all. The name of the file inside the container is set with the fileName option.
Summary table: task → recommended format
| Task | Recommended format | Why |
|---|---|---|
| A report or document for a government body | CAdES-T (.p7s) | the classic "file + .p7s" pair; the default GOST 34.311 hash is accepted by government validators |
| A B2B contract meant to last years | CAdES-XL | certificates and OCSP/CRL are embedded — offline verification years later |
| A PDF that people will read | PAdES-B-T | the signature is inside the PDF; opens in any viewer |
| XML for reporting or systems | XAdES-B-T | the signature lives in the markup itself; convenient for automated processing |
| A document bundle as one file | ASiC-E-T | several files + a signature in one container |
| Archival storage for 10+ years | PAdES-B-LTA / XAdES-B-LTA / CAdES-XL | the maximum of verification data after the certificate expires |
| A quick internal signature without the network | CAdES-BES | the only level that needs no online TSP |
Remember the key constraint of the levels: everything above BES (T, C, XL, LT, LTA) requires online access to a TSP timestamp server at the moment of signing.
How to choose a format in DSTUcrypt: one parameter
In the DSTUcrypt signing widget, choosing a format is one line. The same widget signs PDF, XML, arbitrary files, and assembles ASiC containers:
Signature format — a single format option
import { embed } from 'https://dstucrypt.io/embed/dstucrypt-embed.mjs';
const signer = await embed('sign', { mount: 'modal' });
// a PDF for people: the signature is embedded in the document itself, with a timestamp
const { signature } = await signer.sign(pdfBytes, { format: 'PAdES-B-T' });
signature.download('contract.pdf');
// a long-term signature over any file: certificates and OCSP go in the container
const r = await signer.sign(fileBytes, { format: 'CAdES-XL' });
r.signature.download('document.p7s');
The full list of format values: CAdES — CAdES-BES, CAdES-T, CAdES-C, CAdES-XL; PAdES — PAdES-B-B, PAdES-B-T, PAdES-B-LT, PAdES-B-LTA; XAdES — XAdES-BES, XAdES-B-T, XAdES-B-LT, XAdES-B-LTA; ASiC-S — ASiC-S-BES, ASiC-S-T; ASiC-E — ASiC-E-BES, ASiC-E-T. The verification widget detects the family automatically from the file's content: CMS/CAdES, PDF, XML, or a ZIP container.
Why it is convenient here specifically. All 16 formats live in one SDK — no need to assemble a zoo of libraries for PDF, XML, and CMS. The cryptography runs in the user's browser on a proven native C/C++ library compiled to WebAssembly — the key and password never leave the browser. TSP timestamps and OCSP statuses are embedded directly in the signature container, so documents at the T/XL/LT/LTA levels can be verified offline.
Frequently asked questions
How does CAdES differ from PAdES and XAdES?
Cryptographically it is the same DSTU 4145 signature — the difference is in the "wrapper". CAdES is a universal CMS signature for any files (a separate .p7s file or a container with the data attached). PAdES embeds the signature inside the PDF itself — the file remains an ordinary PDF. XAdES is a signature in XML markup for data exchange systems. Choose based on the file type and on who will verify the signature.
What is a .p7s file?
It is a CMS/CAdES signature container. An attached .p7s holds both the document itself and the signature inside — one file is enough. A detached .p7s contains only the signature, while the original file is passed along next to it — to verify such a signature, the validator needs both files.
What is an ASiC container for?
ASiC is a ZIP archive with a standardized structure in which the original files sit next to the signature. The contents can be opened with an ordinary archiver, and the signature will not get "lost" in transit. ASiC-S (.asics) holds one file; ASiC-E (.asice) holds several files covered by one signature.
Which format level should I choose for long-term storage?
The one that embeds a timestamp and complete verification data in the container: CAdES-XL for .p7s, PAdES-B-LTA for PDF, XAdES-B-LTA for XML. TSP timestamps and OCSP statuses are embedded in the container itself, so the signature can be verified offline and remains provable even after the signer's certificate expires.
Read next
- QES in PDF: how to sign a PDF document with the PAdES standard
- XML signatures (XAdES) with DSTU 4145 keys: for reporting and B2B exchange
- Long-term electronic signatures: CAdES-XL and PAdES-LTA
All 16 signature formats on your website — in 10 minutes
Ready-made widgets for signing, verification, and encryption under DSTU. The key and password never leave the user's browser. Every new domain gets 7 days free.
Live demoHow to integrate