Associated Signature Containers

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. 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: • XAdES Baseline Profile - ETSI TS 103171 v.2.1.1. • CAdES Baseline Profile - ETSI TS 103173 v.2.2.1. • PAdES Baseline Profile - ETSI TS 103172 v.2.2.2. • Associated Signature Container Baseline Profile - ETSI TS 103174 v.2.2.1 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), but this updated standard is not required by the European Commission Implementing Decision. ==Structure==

The internal structure of an ASiC includes two folders: • A root folder that stores all the container's content, which might include folders that reflect the structure of that content. • A “META-INF” folder that resides in the root folder and contains files that hold metadata about the content, including its associated signature and/or time assertion files. 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. ==How ASiC is used==

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. ==Types of ASiC containers==

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: ASiC Simple (ASiC-S) 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. ASiC Extended (ASiC-E) 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. ASiC-S time assertion additional container 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. ASiC-E CAdES additional container This container has the same baselines as an ASiC-E container, but with additional restrictions. ASiC-E time assertion additional container This container complies with ASiC-E baseline requirements along with additional requirements and restrictions. ==Reduced risk of loss of electronic signature==

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. ==References==