| Associated Signature Container Extended (ASiC-E) | |
| Extension: | , |
| Mime: | application/vnd.<br/>etsi.asic-e+zip |
| Magic: | 50 4B 03 04 (the container media type is present starting at offset 38) |
| Owner: | ETSI |
| Released: | 2011 |
| Container For: | XAdES, CAdES, timestamp, signed objects |
| Extended From: | Zip (file format), OpenDocument, EPUB |
| Open: | Yes |
| Associated Signature Container Simple (ASiC-S) | |
| Extension: | , |
| Mime: | application/vnd.<br/>etsi.asic-s+zip |
| Magic: | 50 4B 03 04 (the container media type is present starting at offset 38) |
| Owner: | ETSI |
| Released: | 2011 |
| Container For: | XAdES, CAdES, timestamp, signed object |
| Extended From: | Zip (file format), OpenDocument, EPUB |
| Open: | 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.[1]
Under the eIDAS-regulation,[2] 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. EU Member States requiring an advanced electronic signature or an advanced electronic signature based on a qualified certificate, shall recognise XML, CMS or PDF advanced electronic signature at conformance level B, T or LT level or using an associated signature container, where those signatures comply with the following technical specifications:[3]
Technical specification of ASiCs have been updated and standardized since April 2016 by the European Telecommunications Standards Institute in the standard Associated Signature Containers (ASiC)(ETSI EN 319 162-1 V1.1.1 (2016-04),[5] [6] but this updated standard is not required by the European Commission Implementing Decision.
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,[7] whereas a single evidence record would conform to IETF RFC 4998[8] or IETF RFC6283.[9]
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.