| Associated Signature Container Extended (ASiC-E) | |
|---|---|
| Filename extension | .asice, .sce |
| Internet media type | application/vnd. |
| Magic number | 50 4B 03 04 (the container media type is present starting at offset 38) |
| Developed by | ETSI |
| Initial release | 2011 |
| Container for | XAdES, CAdES, timestamp, signed objects |
| Extended from | Zip (file format), OpenDocument, EPUB |
| Open format? | Yes |
| Associated Signature Container Simple (ASiC-S) | |
|---|---|
| Filename extension | .asics, .scs |
| Internet media type | application/vnd. |
| Magic number | 50 4B 03 04 (the container media type is present starting at offset 38) |
| Developed by | ETSI |
| Initial release | 2011 |
| Container for | XAdES, CAdES, timestamp, signed object |
| Extended from | Zip (file format), OpenDocument, EPUB |
| Open format? | Yes |
Associated Signature Containers (ASiC) specifies the use of container structures to bind together one or more signed objects with either advanced electronic signatures or timestamp tokens into one single digital container.
Under the eIDAS-regulation, an associated signature container (ASiC) for eIDAS is a data container that is used to hold a group of file objects and digital signatures and/or time assertions that are associated to those objects. This data is stored in the ASiC in a ZIP format.
European Commission Implementing Decision 2015/1506 of 8 September 2015 laid down specifications relating to formats of advanced electronic signatures and advanced seals to be recognised by public sector bodies pursuant to Articles 27 and 37 of the eIDAS-regulation. It was repealed by Commission Implementing Regulation (EU) 2026/248, which updates the recognised formats for advanced electronic signatures and advanced electronic seals. Article 1(1) and Article 3(1) of Regulation (EU) 2026/248, which refer to the updated Annex I specifications, apply from 23 February 2027. The transition rules in Article 1(2) and Article 3(2) require recognition of electronic signatures and electronic seals created before 23 February 2028 where they comply with the Annex II specifications, which correspond to the earlier specifications from Implementing Decision (EU) 2015/1506.
The technical specifications listed in Annex II of Regulation (EU) 2026/248 are:
The technical specifications listed in Annex I of Regulation (EU) 2026/248, applying from 23 February 2027, are:
Technical specifications of ASiC have been updated and standardized since April 2016 by the European Telecommunications Standards Institute in the standard Associated Signature Containers (ASiC), including ETSI EN 319 162-1 V1.1.1 and ETSI EN 319 162-2 V1.1.1.
The internal structure of an ASiC includes two folders:
Such an electronic signature file would contain a single CAdES object or one or more XAdES signatures. A time assertion file would either contain a one timestamp token that will conform to IETF RFC 3161, whereas a single evidence record would conform to IETF RFC 4998 or IETF RFC6283.
One of the purposes of an electronic signature is to secure the data that it is attached to it from being modified. This can be done by creating a dataset that combines the signature with its signed data or to store the detached signature to a separate resource and then utilize an external process to re-associate the signature with its data. It can be advantageous to use detached signatures because it prevents unauthorized modifications to the original data objects. However, by doing this, there is the risk that the detached signature will become separated from its associated data. If this were to happen, the association would be lost and therefore, the data would become inaccessible.
One of the most widespread deployments of the ASiC standard is the Estonian digital signature system with the use of multiplatform (Windows, Linux, MacOS (OSX)) software called DigiDoc.
Using the correct tool for each job is always important. Using the correct type of ASiC container for the job at hand is also important:
With this container, a single file object is associated with a signature or time assertion file. A “mimetype” file that specifies the media type might also be included in this container. When a mimetype file is included, it is required to be the first file in the ASiC container. This container type will allow additional signatures to be added in the future to be used to sign stored file objects. When long-term time-stamp tokens are used, ASiC Archive Manifest files are used to protect long-term time-stamp tokens from tampering.
This type of container can hold one or more signature or time assertion files. ASiC-E with XAdES deals with signature files, while ASiC-E with CAdES deals with time assertions. The files within these ASiC containers apply to their own file object sets. Each file object might have additional metadata or information that is associated with it that can also be protected by the signature. An ASiC-E container could be designed to prevent this modification or allow its inclusion without causing damage to previous signatures.
Both of these ASiC containers are capable of maintaining long-term availability and integrity when storing XAdES or CAdES signatures through the use of time-stamp tokens or evidence record manifest files that are contained within the containers. ASiC containers must comply with the ZIP specification and limitations that are applied to ZIP.
This container operates under the baseline requirements of the ASiC Simple (ASiC-S) container but it also provides additional time assertion requirements. Additional elements may be within its META-INF folder and requires the use of “SignedData” variable to include certificate and revocation information.
This container has the same baselines as an ASiC-E container, but with additional restrictions.
This container complies with ASiC-E baseline requirements along with additional requirements and restrictions.
The use of ASiC reduces the risk of an electronic signature becoming separated from its data by combining the signature and its signed data in a container. With both elements secured within an ASiC, it is easier to distribute a signature and guarantee that the correct signature and its metadata is being used during validation. This process can also be used when associating time assertions, including evidence records or time-stamp tokens to their associated data.