What is an ASiC associated signature container?

An ASiC associated signature container is a ZIP-based file format defined by ETSI TS 102 918 (now ETSI EN 319 162). It packages one or more signed files with their digital signature — and optionally manifests, timestamps, and evidence records — into a single .asics or .asice file so the signature can be verified after transfer and long-term storage.

What is the difference between .asics and .asice files?

.asics (ASiC-S, simple) holds exactly one data object and a single XAdES or CAdES signature. .asice (ASiC-E, extended) can hold multiple data objects, additional signatures, manifests, and timestamps — the format to use for multi-file packages and long-term archiving.

How do ASiC files relate to XAdES, CAdES, and PAdES?

XAdES and CAdES are signature formats that live inside an ASiC container; ASiC is the ZIP envelope that wraps them around the signed files. PAdES is a signature embedded directly in a PDF, so it does not need a container, although an ASiC-E package can still include PDFs as data objects.

How do I open and verify an .asics or .asice file?

You can unpack an ASiC file with any ZIP utility because it is a ZIP archive. To verify the signature, use ASiC-aware tooling such as the European Commission's open-source DSS library, a national verification portal, or an e-invoicing validator, and follow a checklist covering the signature, certificate chain, revocation, manifest digests, and timestamps.

Is ASiC recognized under eIDAS?

eIDAS does not mandate ASiC, but the format is referenced by the ETSI framework that implements eIDAS and by EU Digital Identity Wallet technical specifications. Recognition depends on the signature level inside the container (standard, advanced, or qualified), not on the container format itself.

Which business scenarios actually need ASiC containers?

Teams that sign and transmit files together — e-invoicing exchanges, government filings, cross-border declarations, long-term archives, and evidence-heavy document flows — benefit most from ASiC, because the format keeps the signature attached to the exact bytes it protects.

ASiC Associated Signature Containers: A Complete Guide

ASiC (Associated Signature Containers), defined by ETSI TS 102 918, is a ZIP-based container format that packages a digital signature with the signed file and its supporting materials into a single .asics or .asice file. It exists because signatures and documents usually travel separately, so a bare signature file is easily lost, mismatched, or unverifiable after years of storage. With ASiC, the data, the signature, and — in the extended form — manifests, timestamps, and evidence records travel together and stay verifiable during transfer and long-term archiving. European public administrations, e-invoicing exchanges, and compliance-heavy teams use it most. Choose ASiC-S for a single data object; choose ASiC-E for multiple files or richer evidence.

What Is an ASiC Container and Why Does It Exist?

A detached digital signature protects the bytes of a document, but it does not travel with them. A contract and its .xml or .p7s signature file sit in separate attachments, get renamed in different folders, or drift apart when systems migrate. Years later, the verifier faces a pile of unsigned files on one side and orphan signatures on the other, with no reliable way to prove which signature belongs to which document. For background on the signing mechanics that ASiC wraps, see how digital signatures work in business workflows.

ASiC solves this packaging problem. Defined by ETSI TS 102 918 and continued in the ETSI EN 319 162 series, it binds the data object and the signature into one ZIP-based file so the association cannot be broken by file-system accidents. The container does not replace the signature; it carries it, along with manifests, timestamps, and validation evidence, so verification remains possible after transfer and long-term storage.

How an ASiC Container Is Structured

An ASiC file is an ordinary ZIP archive with strict conventions. You can unzip it with any archive tool, but its layout is standardized so verification software can parse it deterministically:

mimetype: the first entry in the archive, stored uncompressed, containing application/vnd.etsi.asic-s+zip or application/vnd.etsi.asic-e+zip. This announces the container type to any tool that opens the file.
Data objects: the signed files, stored at the root or in a docs folder, kept byte-identical to what was signed.
META-INF/: the metadata folder holding the signature blocks — signatures.xml for XAdES or signatures.p7s for CAdES — plus manifest.xml (which lists each data object with its digest) and timestamp.tst (an RFC 3161 time-stamp token) when present.

Because the digest of every data object appears either in the signature itself or in the manifest, changing a single byte after signing breaks verification — exactly the tamper evidence an archive needs.

ASiC-S vs ASiC-E: Which Container Should You Use?

The standard defines two profiles. ASiC-S (simple) wraps exactly one data object with one detached signature; ASiC-E (extended) holds multiple data objects, multiple signatures, and additional evidence. The choice is driven by how many files you need to protect together and how long the package must remain verifiable.

Aspect	ASiC-S (simple)	ASiC-E (extended)
Data objects	Exactly one	One or many
Signatures	One XAdES or CAdES signature	Multiple signatures, incl. counter-signatures
Manifest / timestamps	Not required	`manifest.xml` and time-stamp tokens supported
Typical extension	`.asics`	`.asice` (`.sce` also seen)
Best for	One document signed once (e.g. a single invoice XML)	Multi-file packages, parallel signatures, long-term archiving

Rule of thumb: if you would ever need to add a second file, a second signer, or a time-stamp to the same package, start with ASiC-E. Converting later means re-packaging and re-signing.

How ASiC Relates to XAdES, CAdES, and PAdES

ASiC is not a signature format — it is a container that carries signature formats. XAdES (XML Advanced Electronic Signatures) and CAdES (CMS/PKCS#7-based signatures) can both be detached, which is exactly the situation ASiC fixes: the signature block lives in the container's META-INF folder and references the data objects by digest. If you are comparing the certificate side of these signatures, our explainer on what a DSC is covers the credential that XAdES and CAdES signers use.

PAdES is different: the signature is embedded directly inside the PDF's structure, so a signed PDF is already self-contained and needs no ASiC wrapper. You can still drop PDFs into an ASiC-E container as data objects — for example when a PDF must travel with signed XML attachments — but the PAdES signature itself remains inside the PDF.

Where ASiC Containers Are Used in Practice

ASiC shows up wherever signatures and files must survive transfer, audits, and years of storage:

E-invoicing: several European e-invoicing exchanges transmit the invoice XML together with its signature as one .asice package, so the receiving platform validates a single artifact.
Government and cross-border filings: EU member-state portals and customs or tax declarations often accept ASiC submissions because one container reduces the "which file did you sign?" dispute to zero.
Long-term archiving: with ASiC-E manifests and time-stamp tokens, an archive can re-verify packages years later even as algorithms age.
Court evidence: bundling the exhibit, the signature, and the validation evidence in one file simplifies chain-of-custody arguments.

The common thread: any flow where the signature must stay attached to the exact bytes it protects. Teams producing the underlying certificates can review how to make a digital signature certificate for the issuance prerequisites.

How to Open and Verify an .asics or .asice File

Opening is trivial — rename the file to .zip if your archive tool does not recognize it, and inspect the contents. Verification is the real work. ASiC-aware options include the European Commission's open-source DSS (Digital Signature Service) library and its demo webapp, national e-signature verification portals, and e-invoicing validators. A practical verification checklist:

Confirm the mimetype entry matches the container profile (asic-s vs asic-e).
Validate the signature cryptographically and check it references the present data objects.
Walk the certificate chain to a trusted root — a recognized certificate authority list helps confirm the issuer's standing.
Check revocation status (CRL/OCSP) at the claimed signing time.
Recompute manifest digests against each data object; every one must match.
Verify time-stamp tokens and their own signature chains.
Record the validation report as evidence for audits.

Browser-based checks cover the certificate piece too; verifying a digital signature in Chrome shows the chain-inspection steps that apply equally to the certificates inside an ASiC container.

How ASiC Fits Into the eIDAS Framework

eIDAS does not mandate ASiC. What eIDAS regulates is the signature level inside the container — standard (SES), advanced (AES), or qualified (QES) — while ASiC sits in the ETSI standards family (EN 319 162) that implements eIDAS-compatible packaging. An .asice file holding a qualified XAdES signature carries the same legal weight as that qualified signature in any other wrapping; the container simply keeps it intact. The format is also referenced in EU Digital Identity Wallet technical work, which keeps it on the European roadmap. If your workflows need the signature level to be right, not just the packaging, the requirements are covered in our guide to eIDAS-compliant electronic signatures. Outside the EU, ASiC remains a technical choice rather than a legal requirement — useful for interoperability with European partners, neutral elsewhere.

Nota Sign: Put ASiC-Ready Signing Inside a Compliant Workflow

An ASiC container keeps signature and document together, but it cannot fix a weak signature inside it. The identity checks, signature level, and evidence records that go into the container are decided by the signing workflow that produces it. Nota Sign, FaDaDa's global e-signature platform, builds that workflow correctly from the start: signature levels from SES through AES to QES, identity verification matched to each tier, and audit records that survive long-term archiving. Regional data centers respect data-residency expectations, and pricing carries no per-seat fees, keeping costs predictable as volumes grow. If your documents need signatures that remain verifiable for years inside any container, contact Nota Sign about building the evidence chain in from the first signature.