ASiC-E and BDOC Files Explained: How to Open, Sign and Verify .asice Containers

ASiC-E stands for Associated Signature Container Extended. It is an EU-wide container format standardised by ETSI, the European standards body — not an Estonian invention. Technically, an .asice file is a ZIP archive with a fixed internal layout: the original documents in their native formats, a mimetype declaration, and a META-INF folder holding one or more XAdES XML signatures together with the certificates, timestamps and revocation data needed to check them. Because it is a ZIP, you can rename a copy to .zip and look inside — though that only shows the contents; it does not verify anything.

Estonia adopted ASiC-E as its default through the national DigiDoc software, which is why the extension is everywhere in Estonian business. When someone signs with an ID-card, Mobile-ID or Smart-ID through the state tools, the result is normally a qualified electronic signature (QES) packed into an .asice container — the highest eIDAS level, legally equivalent to a handwritten signature across the EU. One container can hold several documents and collect several signatures, which suits contracts with multiple signers.

BDOC is the older Estonian profile of the same idea — a national specification (BDOC 2.1) built on the ASiC-E structure before today's defaults settled. Files with the .bdoc extension are still perfectly readable and existing signatures remain valid, but modern DigiDoc versions create .asice with timestamps by default. In practice you can treat .bdoc as "yesterday's .asice": verify it with the same tools, keep the original file untouched, and create new signatures as .asice.

On a computer, the standard tool is DigiDoc4 — the free, official client maintained by Estonia's Information System Authority (RIA), available for Windows, macOS and Linux. Install it, double-click the container, and you see the documents inside plus each signature's status: who signed, when, and whether the signature is valid. DigiDoc4 also lets you add your own signature with an Estonian ID-card, Mobile-ID or Smart-ID and save the updated container.

On a phone, use the official RIA DigiDoc mobile app for iOS and Android. Opening an .asice attachment from your email in the app shows the contents and validates the signatures, and you can sign with Smart-ID or Mobile-ID directly on the device. The app also warns you when a signature fails validation, so you know before you forward the file. This is the practical answer for signers who receive contracts on the go and are nowhere near a card reader.

If you cannot install anything, there are still options. RIA operates a signature validation service (SiVa) that powers web-based validators, EU-level open-source validation tools built on the DSS library exist as well, and several commercial e-signing platforms open ASiC-E containers in the browser. And remember the ZIP trick: renaming a copy of the file to .zip lets you extract and read the documents — useful in a pinch, but it tells you nothing about whether the signatures are genuine and intact. Verification always needs a validator.

Three Estonian extensions, one timeline. .ddoc is the legacy DigiDoc XML format: new .ddoc files can no longer be created, but old ones can still be opened and their signatures checked. .bdoc replaced it and remains fine to read and verify. .asice is the current default and the right choice for new signatures, because it matches the EU-wide ETSI standard and travels best across borders. If a counterparty's tooling rejects a .bdoc, re-signing the same document as .asice usually solves the problem.

The Baltic neighbours have parallel formats: Latvia's eDoc (.edoc) and Lithuania's ADOC (.adoc) are national signed-container profiles used within their state ecosystems. They serve the same purpose, but not every Estonian tool opens them — and vice versa. For cross-Baltic contracts, the pragmatic moves are to agree the container format up front, use a platform that handles validation for both sides, or fall back to the format with the broadest support.

A signed PDF (PAdES) embeds the signature inside the PDF itself: one file, opens in any PDF reader, and the signature panel shows the status. Containers win when you need to sign multiple files or non-PDF formats — spreadsheets, drawings, images — as one sealed package; PAdES wins on frictionless viewing for recipients outside the DigiDoc world. Both are eIDAS-recognised formats, so the choice is about your counterparties' tools, not about legal strength.

A contract signed today may need to be proven in five or ten years, when the signer's certificate has long expired. That is what the container's extra baggage is for. A modern .asice signature at the LT (long-term) level embeds a qualified timestamp and the certificate-validity (OCSP) response captured at signing time, so a validator can later confirm that the certificate was valid at the moment of signing — even after it expires or is revoked. That is the difference between "the file looks signed" and "this signature is provable years later".

Two practical rules follow. First, never modify a signed container: do not re-zip it, do not open-and-resave it in an archive tool, do not "fix" a file name inside it. Any byte-level change breaks the cryptographic link and the signatures stop validating. Second, keep the container together with the surrounding audit trail — who was invited to sign, which version was signed, when each party confirmed. The container proves the signature; the evidence trail around it proves the process, and that combination is what holds up when a contract is challenged.

For very long retention periods, the standards also define an archival (LTA) level, which adds further timestamps over time so the evidence chain stays strong even as cryptographic algorithms age. Most businesses will not manage that by hand — the practical takeaway is to store signed containers unchanged in a system that tracks them, rather than in a shared folder where a well-meaning colleague can accidentally re-save the file. When you need to prove a contract years later, you want the original container, its validation status and the surrounding process records available in one place.

Under eIDAS, a qualified electronic signature has the same legal effect as a handwritten one in every EU member state, whatever file format it arrives in. For the public sector, Commission Implementing Decision 2015/1506 goes further: it lists the signature formats — including XAdES/ASiC and PAdES — that public bodies must accept from other member states. Private companies are free to agree formats between themselves. In the Baltics, receiving an .asice is completely normal; elsewhere in the EU, a PAdES signed PDF is often the smoother choice for the other side. If you regularly exchange contracts with Estonian, Latvian or Lithuanian counterparties, it is worth having at least one tool in the team that opens all the local containers — it removes a whole category of "cannot open your attachment" emails.

For day-to-day contract work, the format question sits inside a bigger workflow question: how the document gets drafted, negotiated, signed at the right level (SES, AES or QES) and archived with its evidence. DokDesk approaches it from that end: reusable templates, negotiation on one live version, and eIDAS e-signing with Smart-ID and Mobile-ID over a secure link that needs no account — with a court-ready evidence base and data staying in the EU under GDPR. DokDesk performs SES and AES signing with national eIDs and is architecture-ready for QES; it does not issue qualified signatures itself. When your process specifically requires a QES in an .asice container, the state DigiDoc tools remain the reference path.