ASiC (Associated Signature Containers) is a packaging format for advanced electronic signatures defined by ETSI in the EN 319 162 standard. It bundles one or more documents together with their cryptographic signatures inside a single ZIP-based container — making signature verification portable, self-contained, and legally binding under EU eIDAS regulation.
📌 What Is ASiC?
ASiC stands for Associated Signature Container. It is a standardised container format — based on a simple ZIP archive — that associates one or more data objects (e.g. documents, files, binaries) with one or more signatures or timestamps. The signatures inside can be in XAdES (XML Advanced Electronic Signatures) or CAdES (CMS Advanced Electronic Signatures) format.
The format was designed to solve a fundamental problem in document signing: how do you keep a document and its proof of authenticity together as a single transportable unit, without any ambiguity about what was signed? ASiC answers that by wrapping everything in one standardised container.
🗂️ At its core, an ASiC container is a ZIP file containing:
- The original signed data files (documents, XML, PDFs, binaries, etc.)
- One or more signature files (XAdES .xml or CAdES .p7s)
- A mandatory mimetype file (first entry, uncompressed — identifies container type)
- An optional META-INF/ directory containing manifest files and timestamps
🔀 The Two ASiC Variants: ASiC-S vs ASiC-E
ETSI defines two distinct container profiles, each serving a different use case:
ASiC-S
Simple Container
- Exactly one signed data object
- One or more associated signatures/timestamps
- Signature covers the single file directly
- mimetype:
application/vnd.etsi.asic-s+zip - Ideal: single document + proof
- Example: a PDF invoice with one XAdES signature
ASiC-E
Extended Container
- Multiple data objects in one container
- Signatures reference specific files via manifest
- META-INF/manifest.xml or ASiCManifest.xml
- mimetype:
application/vnd.etsi.asic-e+zip - Ideal: multi-document signing workflows
- Example: a contract + annexes signed together
🏗️ Container Structure (ASiC-E with XAdES Example)
my-container.asice (ZIP archive)
├── mimetype ← first entry, uncompressed, no extra fields
│ └── "application/vnd.etsi.asic-e+zip"
├── document1.xml ← signed data file 1
├── document2.pdf ← signed data file 2
├── invoice.json ← signed data file 3
└── META-INF/
├── ASiCManifest.xml ← lists which files are signed by which sig
├── signatures001.xml ← XAdES-LTA signature file (XML)
└── timestamp.tst ← optional archive timestamp
🌍 Who Uses ASiC and Why
ASiC is primarily driven by European regulatory requirements under the eIDAS Regulation (EU No 910/2014), which requires electronic signatures used in cross-border transactions to be in standardised, interoperable formats. Here are the main adopters:
Government & Public Sector
EU member states mandate ASiC-based signatures for e-government services, tax filings, procurement portals, and official correspondence. Estonia's X-Road and many national eID systems output ASiC containers.
Banking & Finance
Loan agreements, KYC documents, fund transfer authorisations, and audit trails use ASiC-E containers to bundle all related documents under one qualified signature — legally equivalent to a handwritten signature.
Legal & Notarial
Court submissions, notarised contracts, and legal evidence packages are signed in ASiC format across EU jurisdictions to ensure the signature remains verifiable in any ETSI-compliant system.
Healthcare
Patient records, prescriptions, and clinical trial data require long-term verifiable signatures (LTA-level). ASiC containers allow these documents to remain provably authentic for decades.
e-Commerce & e-Invoicing
EU Directive 2014/55/EU requires structured e-invoices. ASiC-E wraps UBL/CII invoice XML files with XAdES signatures, providing tamper-evident, legally compliant invoices across all EU member states.
Research & Academia
Research datasets, scholarly publications, and grant documentation signed in ASiC format ensure provenance, integrity, and authorship can be independently verified years or decades later.
⚡ Advantages of ASiC
Self-Contained Portability
Documents and signatures travel together as one file. No risk of a signature becoming separated from its data — the ZIP bundle is the authoritative unit.
EU-Wide Interoperability
Because ASiC is an ETSI standard mandated by eIDAS, any compliant system across all 27 EU member states can create, verify, and process an ASiC container without custom integration.
Long-Term Validity (LTA)
ASiC supports XAdES-LTA and CAdES-LTA signature levels, embedding archive timestamps that preserve the signature's validity even after the original cryptographic algorithms are deprecated.
Multiple Signatures Support
Multiple signers can independently sign the same container (parallel signatures) or sign a progressively extended container. Both the original data and all signature histories are preserved.
Format Agnostic
The container can hold any file type — XML, PDF, JSON, DOCX, images, binary blobs. The signature covers the bit-exact content, not a display interpretation, ensuring true integrity.
Legal Equivalence
A Qualified Electronic Signature (QES) inside an ASiC container has the same legal effect as a handwritten signature under eIDAS Article 25(2) — enforceable in all EU courts.
Container Merging
The EU DSS framework (esig/dss) supports ASiC container merging — combining two valid containers into one, which is essential for workflows where documents accumulate signatures over time.
Tamper Evidence
Any modification to any byte of any signed file inside the container will invalidate the signature — providing cryptographic proof of integrity that is independently verifiable without trusting any third party.
📊 Signature Levels Supported in ASiC
ASiC containers can carry XAdES or CAdES signatures at multiple conformance levels, from a basic digital signature up to a fully archive-proof long-term signature:
| Level | Full Name | What It Adds | Use Case |
|---|---|---|---|
| B-B | Baseline-B (Basic) | Signer certificate + signed attributes (time is claimed, not proven) | Simple short-term signing |
| B-T | Baseline-T (Trusted Time) | Adds a trusted timestamp from a TSA proving signature existed at that moment | Contracts, invoices |
| B-LT | Baseline-LT (Long-Term) | Embeds full certificate chain + revocation data (OCSP/CRL) so verification needs no online lookups | Archiving, compliance |
| B-LTA | Baseline-LTA (Long-Term Archive) | Archive timestamp covering all prior material — ensures validity even after algorithm deprecation | Legal archives, 20+ year retention |
🧩 DSS Framework Components for ASiC
The EU's open-source Digital Signature Service (DSS) library — maintained by the European Commission's DIGIT unit — is the reference implementation for ASiC creation, extension, and validation. It is built with Java and published to Maven Central under the eu.europa.ec.joinup.sd-dss group ID. Here are the key ASiC-related modules:
Core shared abstractions for ASiC containers: ASiCContent model, ZIP reading/writing utilities, mimetype handling, and the base classes for both ASiC-S and ASiC-E processing.
ASiC containers using XAdES (XML) signatures. Handles creation and extension of ASiC-S/E with XAdES-B-B through XAdES-LTA levels. Produces .asics and .asice files.
ASiC containers using CAdES (CMS/PKCS#7) signatures. Handles creation and extension of ASiC-S/E with CAdES-BASELINE levels. Often used for non-XML data like PDFs or binary documents.
Core XAdES engine — creates, parses, and validates XAdES-conformant XML signatures. Used internally by dss-asic-xades to produce the actual cryptographic signature XML embedded in the container.
Core CAdES engine — builds and parses CMS-based signatures. Supports detached, enveloping, and enveloped modes. Used by dss-asic-cades for the embedded .p7s signature file.
Full signature validation engine — validates ASiC containers against ETSI EN 319 102 and produces Simple, Detailed, and ETSI Validation Reports. Drives the certificate chain building, revocation, and trust anchor resolution.
Timestamp (TSP) client for obtaining timestamps from RFC 3161 compliant Timestamp Authorities (TSAs). Essential for creating T, LT, and LTA level signatures inside ASiC containers.
Standalone certificate validation — checks certificate status via OCSP and CRL, builds certificate chains, and loads Trusted Lists (EU LOTL). Used by the validation pipeline to establish trust.
Abstraction layer for signature tokens: PKCS#12 files, PKCS#11 smart cards/HSMs, Windows CAPI, and Apple Keychain. Decouples key management from the signing workflow.
REST and SOAP web service wrappers around the core DSS features. Allows language-agnostic clients (Python, .NET, PHP, etc.) to create and validate ASiC containers by calling HTTP endpoints.
📦 Maven Integration
<!-- Import DSS BOM for version management --> <dependencyManagement> <dependencies> <dependency> <groupId>eu.europa.ec.joinup.sd-dss</groupId> <artifactId>dss-bom</artifactId> <version>6.4</version> <type>pom</type> <scope>import</scope> </dependency> </dependencies> </dependencyManagement> <!-- Add ASiC modules you need --> <dependencies> <dependency> <groupId>eu.europa.ec.joinup.sd-dss</groupId> <artifactId>dss-asic-xades</artifactId> <!-- ASiC + XAdES --> </dependency> <dependency> <groupId>eu.europa.ec.joinup.sd-dss</groupId> <artifactId>dss-asic-cades</artifactId> <!-- ASiC + CAdES --> </dependency> <dependency> <groupId>eu.europa.ec.joinup.sd-dss</groupId> <artifactId>dss-validation</artifactId> <!-- Validation engine --> </dependency> </dependencies>
⚙️ How ASiC Signing Works — Step by Step
Prepare Documents
The signing application assembles the data objects to be signed. In DSS, these are DSSDocument instances — file-system documents, in-memory buffers, or streams.
Configure Signature Parameters
The signer specifies: container type (ASiC-S or ASiC-E), signature format (XAdES or CAdES), signature level (B-B, B-T, B-LT, or B-LTA), and the signing algorithm (RSA, ECDSA, etc.).
Compute Data to Be Signed (DTBS)
DSS computes the digest of the document content (and mandatory signed attributes) and returns a byte array for the DTBS. This is what will be cryptographically signed — the key never needs to touch the raw document.
Sign with Private Key (Token)
The DTBS is signed using the signer's private key — from a PKCS#12 file, smart card (PKCS#11), HSM, or cloud signing service. The signature value (raw bytes) is returned to DSS.
Build the Signature File
DSS assembles the XAdES (XML) or CAdES (CMS) signature structure, embedding the signature value, signer certificate, signed attributes, and — for higher levels — the timestamp response from the TSA.
Package the ASiC Container
DSS writes the ZIP archive: mimetype (uncompressed, first entry), all signed data files, the META-INF/signatures file, and optionally the ASiCManifest.xml. The output is a valid .asice or .asics file.
Validate the Container
Any conformant system receives the container, unzips it, resolves the certificate chain against the EU Trusted List (LOTL), checks OCSP/CRL revocation, verifies the timestamp chain, and produces a standardised Validation Report.
🌍 Real-World Deployments
| Country / System | Container Type | Signature | Use |
|---|---|---|---|
| Estonia — DigiDoc4 | ASiC-E | XAdES-LT | National eID document signing, tax, healthcare |
| EU — e-CODEX | ASiC-E | XAdES-LTA | Cross-border legal document exchange between courts |
| Italy — FatturaPA | ASiC-S | CAdES-BES | Mandatory electronic B2B invoicing to SDI platform |
| Lithuania — VIISP | ASiC-E | XAdES-LT | Government e-services portal, civil documents |
| EU DSS Demo | ASiC-S / ASiC-E | XAdES / CAdES (all levels) | EU reference implementation & interoperability testing |
📚 Key Standards and References
Core ASiC standard — defines the container format, ASiC-S and ASiC-E profiles, ZIP structure requirements, mimetype rules, and mandatory META-INF content.
Defines XAdES Baseline signatures (B-B, B-T, B-LT, B-LTA) — the XML format used inside ASiC containers when the XAdES variant is chosen.
Defines CAdES Baseline signatures — the CMS-based format used inside ASiC containers when the CAdES variant is chosen (common for binary documents).
The legal framework that gives qualified electronic signatures (including those in ASiC containers) the same legal effect as handwritten signatures across all EU member states.
Defines the algorithm for validating advanced electronic signatures — the standard that drives how the DSS validation engine evaluates signatures inside an ASiC container.
The Internet timestamp protocol used to obtain trusted timestamps from TSAs — critical for creating B-T, B-LT, and B-LTA level signatures inside ASiC containers.
📋 Quick Summary
A ZIP-based container format that bundles documents with their XAdES or CAdES electronic signatures into a single portable, self-contained file.
eIDAS-compliant legal signatures, EU cross-border interoperability, long-term archival validity, and tamper-evident document bundling.
ETSI EN 319 162 standard, implemented by the EU DSS Java library (esig/dss), supporting ASiC-S and ASiC-E with all XAdES/CAdES baseline levels.
Written by Alex R. | Coding with Alex Blog | Tags: Digital Signatures, ASiC, eIDAS, ETSI, XAdES, CAdES, EU DSS