What is an Associated Signature Container and How Does it Work?

When an electronic signature is created, it must be associated to the data that it is being used to secure. This is accomplished by creating a data set that will combine the signature with the signed data or by storing the detached signature in a separate resource and then using an external means to associate it back to the data.

There are some advantages to using detached signatures; mainly that it prevents modification of the original data objects. However, there is a risk in doing this. There is always the possibility that the signature will become separated from its applicable data, and when this happens, the association is lost.

In an effort to reduce this risk, techniques have been developed for application systems to combine a detached signature, along with its signed data in a container. This container allows for easier distribution and helps to guarantee that the correct signature, in addition to its metadata is used during the validation process. This also applies to associating time assertions, such as time-stamp tokens or evidence records to their associated data. The implementation of ASiC provides a standard for container types for packaging digital signatures and/or time assertions with their associated data objects.

What is ASiC?

Simply put, an ASiC is a data container that holds a group of file objects and their associated digital signatures/and or time assertions using the ZIP format.

This data container’s internal structure includes:

• A root folder that holds all the container content, which may include folders that reflect the structure of the content
• A “META-INF” folder within the root folder that holds files that contain metadata about the content, which includes the associated signature/and or time assertion files

The files that are contained in the “META-INF” folder are applied in such a manner that the integrity of the data is not compromised when they are extracted from the ZIP container. When placed in local storage, these files can be verified against their associated file objects.

The signature file will hold either a single CAdES object or one or more XAdES signatures. The time assertion file will hold either a one time-stamp token that conforms to IEFT RFC 3161 [3] or a single evidence record that conforms to IETF RFC 4998 [8] or IETF RFC 6283 [9].

What ASiC Supports

Associated Signature Containers (ASiC) binds detached digital signatures and/or time assertions to their applicable file objects in a single container that is based on ZIP, which provides a basic container structure. The file objects may include documents, spreadsheets, XML structured data or multimedia content. ASiC supports:

• CAdES objects incorporating CAdES signatures (ETSI EN 319 122-1 “Electronic Signatures and Infrastructures (ESI); CAdES digital signatures’ Part 1: Building blocks and CAdES baseline signatures”)
• XAdES signatures (ETSI EN 319-412-1 “Electronic Signatures and Infrastructures (ESI)); XAdES digital signatures; Part 1: Building blocks and XAdES baseline signatures)

Part 1: Building blocks and ASiC baseline containers

ASiC Simple (ASiC-S). This container associates one file object with either a signature file or a time assertion file. A file named “mimetype,” which specifies the media type may also be included in this container. This container type allows additional signatures to be added at a later date to sign the stored file object and add ASiC ArchiveManifest files that will protect long term time-stamp tokens.

ASiC Extended (ASiC-E). This container is capable of holding one or more signature or time assertion files that apply to their own sets of file objects. Each file object can have additional information or metadata associated to it that can be protected by the signature. This type of container can be designed to restrict this modification or to allow their inclusion without damaging the previous signatures.

Long term availability and integrity of both types of ASiC containers containing XAdES or CAdES signatures is achieved using time-stamp tokens or evidence record manifest files within the containers.

Part 2: Additional ASiC containers

As of April 2016, with the release of “Electronic Signatures and Infrastructures (ESI); Associated Signature Containers (ASiC); Part 2: Additional ASiC Containers (ETSI EN 319 162-2 V1.1.1)", three new additional containers exist for eIDAS. These additional containers were designed to maximize the interoperability for ASiC uses that are not covered by the original two baseline containers.

ASiC-S Time Assertion Additional Container. This container operates under the requirements of an ASiC Simple (ASiC-S) container; however, it includes additional requirements for time assertion. It may contain additional elements within its META-INF folder, to only using “SignedData” variable to include certificate and revocation information in the event that one or more ASiCArchiveManifest files are present.

ASiC-E CAdES Additional Container. This container adheres to requirements as specified in ASiC part 1 [2] clause 4.4 for ASiC-E, but it features additional restrictions. It can support the same levels as defined for baseline containers as specified in ASiC part 1 [2], clause 5.

ASiC-E Time Assertion Additional Container. This container complies with the baseline requirements as specified in ASiC part 1 [2]. It also features additional restrictions by adhering to and supporting additional ASiC clauses regarding time assertion.