Hubbry Logo
Associated Signature ContainersAssociated Signature ContainersMain
Open search
Associated Signature Containers
Community hub
Associated Signature Containers
logo
7 pages, 0 posts
0 subscribers
Be the first to start a discussion here.
Be the first to start a discussion here.
Associated Signature Containers
Associated Signature Containers
Associated Signature Containers
View on Wikipedia
from Wikipedia
Associated Signature Container Extended (ASiC-E)
Filename extension
.asice, .sce
Internet media type
application/vnd.
etsi.asic-e+zip
Magic number50 4B 03 04 (the container media type is present starting at offset 38)[1]
Developed byETSI
Initial release2011
Container forXAdES, CAdES, timestamp, signed objects
Extended fromZip (file format), OpenDocument, EPUB
Open format?Yes
Associated Signature Container Simple (ASiC-S)
Filename extension
.asics, .scs
Internet media type
application/vnd.
etsi.asic-s+zip
Magic number50 4B 03 04 (the container media type is present starting at offset 38)[1]
Developed byETSI
Initial release2011
Container forXAdES, CAdES, timestamp, signed object
Extended fromZip (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.[2]

Regulatory context

[edit]

Under the eIDAS-regulation,[3] 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:[4]

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),[1][6] but this updated standard is not required by the European Commission Implementing Decision.

Structure

[edit]

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,[7] whereas a single evidence record would conform to IETF RFC 4998[8] or IETF RFC6283.[9][2][1]

How ASiC is used

[edit]

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.[2]

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

[edit]

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:[2]

ASiC Simple (ASiC-S)

[edit]

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.[1][2]

ASiC Extended (ASiC-E)

[edit]

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.[1][2]

ASiC-S time assertion additional container

[edit]

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.[2][6]

ASiC-E CAdES additional container

[edit]

This container has the same baselines as an ASiC-E container, but with additional restrictions.[2][6]

ASiC-E time assertion additional container

[edit]

This container complies with ASiC-E baseline requirements along with additional requirements and restrictions.[2][6]

Reduced risk of loss of electronic signature

[edit]

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.[2]

References

[edit]
[edit]
Revisions and contributorsEdit on WikipediaRead on Wikipedia

Associated Signature Containers

View on Grokipedia
from Grokipedia
Associated Signature Containers (ASiC) are standardized digital container formats that package one or more data objects with their corresponding advanced electronic signatures, timestamp tokens, and related cryptographic elements into a single ZIP-based archive, facilitating secure bundling and long-term validation of signed content. Defined by the European Telecommunications Standards Institute (ETSI), ASiC enables the association of detached signatures—such as those in XAdES or CAdES formats—with documents, preserving integrity and authenticity without embedding signatures directly into files like PDFs. ASiC exists in two primary variants: ASiC-S for simple containers linking a single data object to one or more signatures, and ASiC-E for extended containers supporting multiple data objects across directories within the ZIP structure. These formats incorporate mandatory metadata files, including a mimetype entry specifying the container type (e.g., application/vnd.etsi.asic-e+zip) and an optional ASiCManifest.xml for describing signed elements and signature policies. Under the EU's eIDAS Regulation, ASiC qualifies as a recognized format for advanced and qualified electronic signatures, ensuring interoperability for cross-border digital transactions and archival purposes. The standard's design prioritizes flexibility for multi-signature scenarios, such as countersigning or timestamping chains, while supporting baseline profiles for without proprietary extensions. Adopted widely in European public sector applications for document authentication, ASiC addresses limitations of standalone signature formats by enabling portable, verifiable packages that resist tampering and facilitate audit trails.

History and Development

Origins in ETSI Specifications

The Associated Signature Container (ASiC) format originated from technical specifications developed by the European Telecommunications Standards Institute (ETSI) under its Electronic Signatures and Infrastructures (ESI) technical committee. The initial specification, ETSI TS 102 918 version 1.1.1, was published on April 15, 2011, and defined container structures for binding one or more data objects with detached CAdES (CMS Advanced Electronic Signatures) or XAdES (XML Advanced Electronic Signatures) signatures, as well as optional time-stamp tokens, into a single package. This approach addressed limitations in earlier detached signature models by enabling portable, self-contained units that maintain signature-data associations without modifying the original files, supporting compliance with EU electronic signature directives such as Directive 1999/93/EC. ETSI TS 102 918 introduced two primary container types: Simple ASiC (ASiC-S) for associating a single data object with one or more signatures, and provisions for extended variants incorporating time-stamps. Version 1.3.1, released on , 2013, expanded these definitions to include Extended ASiC (ASiC-E), which integrates time-mark or time-stamp mechanisms for long-term signature validity, ensuring evidence of data existence at signing time even after certificate expiration. These containers utilized ZIP archiving for packaging, with mandatory inclusion of a mimetype file and signature files in standardized directories (e.g., META-INF for signatures), promoting across signature validation tools while preserving the detached nature of signatures to avoid altering signed content. The specifications evolved from ETSI's foundational work on advanced electronic signatures, including TS 101 733 for CAdES (1999, with updates) and TS 101 903 for (2002, profiled in TS 103 171 from 2011), which emphasized verifiable, long-lived signatures but lacked standardized multi-file packaging. By 2016, TS 102 918 informed the normative EN 319 162-1 version 1.1.1 (April 28, 2016), which formalized ZIP-based ASiC baseline containers as building blocks for electronic document workflows, explicitly supporting eIDAS Regulation (EU) No 910/2014 requirements for qualified electronic signatures. This progression reflected ETSI's focus on causal integrity in signature validation, prioritizing empirical verifiability over embedded alterations that could introduce validation errors in formats like PDF or XML.

Key Milestones and Updates

The initial specification for Associated Signature Containers was introduced in ETSI TS 102 918 V1.3.1, published in June 2013, which outlined ZIP-based containers for associating s with multiple data objects to enhance portability and long-term validity. This technical specification built on prior frameworks, enabling baseline packaging of signed documents, signatures, and optional timestamps. A key interoperability milestone occurred in March 2014 with the first ETSI remote Plugtests event on ASiC, testing implementations against TS 102 918 to identify conformance issues in creation, packaging, and validation processes across vendors. In alignment with the Regulation (EU) No 910/2014, ETSI transitioned to European Norm (EN) standards, publishing EN 319 162-1 V1.1.1 in April 2016, which defined building blocks and baseline ASiC containers (ASiC-S for single signatures and ASiC-E for multiple) to meet profile requirements under eIDAS Article 5. Concurrently, EN 319 162-2 V1.1.1 was released in April 2016, extending the baseline with additional profiles for enhanced functionality, such as support for and CAdES formats within containers. These updates formalized ASiC as a ZIP-structured format with mandatory MIME type (application/vnd.etsi.asic-e+zip or -s+zip) and signature policy references for . No substantive revisions to the core EN 319 162 specifications have occurred since 2016, with ongoing ETSI documents as recent as TS 119 511 V1.2.1 (October 2025) reaffirming their use in preservation and semantic contexts without altering the container architecture. This stability reflects ASiC's maturity, though related electronic signature baselines (e.g., EN 319 122-1 for CAdES) have seen updates to integrate with ASiC packaging.

Regulatory Framework

eIDAS and EU Directives

The Regulation (EU) No 910/2014, adopted on 23 July 2014 and applicable from 1 July 2016, establishes a harmonized EU-wide framework for and trust services, including electronic signatures, to facilitate secure cross-border electronic transactions. It defines advanced electronic signatures (AdES) as those based on qualified certificates with requirements for uniqueness, identification of the signer, and protection, while qualified electronic signatures (QES) incorporate a qualified certificate and device, granting them legal equivalence to handwritten signatures across EU member states. Associated Signature Containers (ASiC) conform to this framework by packaging one or more data objects with corresponding detached signatures in a ZIP-based structure, enabling the creation and long-term validation of AdES and QES that meet eIDAS criteria for , authenticity, and . ETSI standards, particularly EN 319 162-1 (published April 2016) for baseline ASiC containers and EN 319 162-2 for extended profiles, provide the technical specifications for ASiC to ensure compliance with , integrating signature formats such as , CAdES, and timestamps while supporting baseline levels from creation (ES-B-B) to archival validation (TAr-ES). These standards were developed to align with requirements for interoperability and recognition by public sector bodies, as referenced in implementing acts like Commission Implementing Decision (EU) 2015/1506, which specifies formats for advanced signatures under the transitional framework. ASiC's container approach addresses mandates for binding signatures to documents without embedding, preserving evidence of long-term validity through timestamps and certificate chains verifiable against trusted lists maintained under the regulation. Preceding eIDAS, Directive 1999/93/EC (adopted 13 December 1999) provided the initial EU framework for electronic signatures, distinguishing basic, advanced, and qualified types and requiring member states to recognize advanced signatures with equivalent legal effect where risks warranted. Early ASiC specifications, such as ETSI TS 102 918 (version 1.3.1, June 2013), emerged in this context to package detached advanced signatures with data objects, building on the directive's emphasis on signature-data linking without mandating specific formats. repealed and superseded the directive effective 1 July 2016, incorporating its core principles while mandating ETSI-compliant formats like ASiC for enhanced interoperability, though transitional recognition of pre- advanced signatures persists where they meet equivalent security levels. This evolution ensures ASiC's role in bridging the directive's foundational requirements with 's stricter conformity assessments for qualified trust service providers.

International and National Contexts

Associated Signature Containers (ASiC) gain legal recognition primarily through national implementations of the EU's Regulation (EU) No 910/2014, which mandates equivalence for qualified electronic signatures across member states, with ASiC formats specified in ETSI EN 319 162 as compliant packaging for advanced and qualified signatures. National variations arise in mandatory usage, validation requirements, and integration with public services; for example, Estonia's Identity Documents Act and DigiDoc framework require ASiC-E (.asice) containers for qualified timestamped signatures (BDOC-TS), enabling widespread use in since 2012, with over 99% of government services digitally signed as of 2023. Lithuania's Electronic Signature Law similarly endorses ASiC for qualified signatures, integrating it into the state's MOBILE-ID and e-health systems for legally binding documents, while employs ASiC in its e-signature infrastructure for public procurement and tax filings under the Electronic Signature Law of 2003, amended to align with in 2016. In other EU states, adoption is less uniform but supported by national eIDAS transpositions; Germany's Signature Act () permits ASiC for advanced signatures in federal administration, though remains prevalent for PDFs, and Italy's Digital Administration Code mandates ASiC compatibility for interoperable documents via AgID guidelines updated in 2020. EEA non-EU members like , , and fully incorporate via the EEA Agreement, extending ASiC recognition for cross-border trust services, though practical compatibility challenges persist in Nordic-Baltic for ASiC-E validation. Internationally, ASiC lacks a unified regulatory framework equivalent to , with adoption limited to voluntary alignment with ETSI standards; the ' Telecommunications and Digital Government Regulatory Authority (TDRA) prescribes ASiC formats alongside , CAdES, and in its Digital Signature Standard Manual of January 2024, enabling their use for enforceable electronic transactions under Federal Decree-Law No. 46/2021 on Electronic Transactions, particularly in federal e-services and blockchain-integrated signatures. Other jurisdictions, such as the post-Brexit, recognize electronic signatures under the Electronic Communications Act 2000 but do not mandate ASiC, favoring flexible formats without -qualified equivalence, while countries like accept ETSI-compliant signatures via bilateral agreements but prioritize national standards like SwissSign for qualified validity. No global treaty enforces ASiC, though its ZIP-based structure facilitates technical in regions adopting ETSI norms, such as select Middle Eastern and Asian ETSI members.

Technical Foundations

Container Architecture

Associated Signature Containers (ASiC) are structured as ZIP archives conforming to the ZIP Application Note specification (PKWARE APPNOTE.TXT, September 2012). This format enables the packaging of one or more data objects alongside their electronic signatures or time assertions in a single, self-contained file, ensuring portability and ease of verification without altering the integrity of the contents. The container employs detached signatures, where the signature files reference the data objects via uniform resource identifiers (URIs) or manifest files, preserving the original data unchanged during extraction. The root of the ZIP archive contains the primary data files to be signed, placed directly without subfolders unless specified otherwise. A mandatory META-INF directory houses metadata, including signature documents and timestamps, typically formatted as (per ETSI EN 319 132-1 and EN 319 132-2) or CAdES (per ETSI EN 319 122-1 and EN 319 122-2). An optional but recommended mimetype file, stored as the first entry in the archive and uncompressed, declares the container type—such as application/vnd.etsi.asic-s+zip for simple variants or application/vnd.etsi.asic-e+zip for extended variants—to facilitate automatic recognition by verifiers. Baseline profiles impose further constraints, such as prohibiting digests, requiring explicit URI references to data objects, and mandating specific file extensions like .asics for simple containers or .asice for extended ones. Signature binding occurs through ds:Reference elements in the signature documents, which point to the data files by relative path or full URI, or via an ASiCManifest.xml in extended containers to catalog multiple objects. For simple ASiC-S containers, a single pairs with one file (e.g., signatures.xml or signature.p7s) in META-INF, ensuring one-to-one association. Extended ASiC-E variants support multiple s at the root and corresponding files (e.g., matching signatures.xml patterns), allowing complex multi-signature scenarios while maintaining verifiable linkages. Conformance to baseline levels (B-B, B-T, B-LT, B-LTA) aligns with underlying or CAdES profiles, ensuring long-term validity through timestamping and certificate chains.

Signature Binding Mechanisms

Associated Signature Containers (ASiC) employ a combination of structural packaging and cryptographic referencing to bind electronic signatures to their corresponding data objects, ensuring both physical association and verifiable integrity. The core mechanism relies on the ZIP archive format, which encapsulates signed data files, signature files (conforming to AdES formats such as CAdES or ), and optional metadata in a single container, identified by specific types like application/vnd.etsi.asic-s+zip for simple variants or application/vnd.etsi.asic-e+zip for extended ones. This packaging prevents detachment of signatures from documents during storage or transmission, as the container maintains all elements together unless deliberately extracted. In ASiC-S (simple containers), binding is achieved through direct association of a single data object with one or more signature or timestamp files housed in a META-INF directory within the ZIP structure. For XAdES signatures, the signatures.xml file includes <ds:Reference> elements that point to the data object via URI (e.g., referencing the file name) or imply the reference if no explicit URI is provided, leveraging XML Digital Signature standards for hash-based verification. CAdES signatures use files like signature.p7s, where binding occurs implicitly through the container's structure and the signature's internal content identifiers that match the data object's digest. Timestamp tokens (timestamp.tst) or evidence records follow similar placement rules, ensuring temporal assertions remain linked without requiring additional manifests. This approach suits scenarios with minimal complexity, as the single-file limitation enforces straightforward reference resolution during validation. ASiC-E (extended containers) support more intricate binding for multiple data objects and signatures, incorporating explicit manifests to orchestrate associations. An ASiCManifest.xml file, validated against an ETSI-defined , declares SigReference elements that link to signature files (e.g., *signatures*.xml for or *signature*.p7s for CAdES) and include DataObjectReference sub-elements containing digests of the signed data objects, enabling precise mapping even in nested or multi-signature setups. in ASiC-E may use <ds:Manifest> for indirect referencing of multiple objects, while CAdES relies on the manifest for cross-referencing, as CAdES lacks native multi-object support. These mechanisms allow parallel signatures, countersignatures, and incremental additions without invalidating prior bindings, provided new elements reference existing ones correctly. Validation of binding integrity involves recomputing digests of data objects from the ZIP-extracted files and comparing them against those embedded in the signatures or manifests, confirming no alterations or detachments have occurred. The ETSI specifications mandate conformance to ZIP APPNOTE 6.3.3 for archive robustness, further safeguarding against manipulation. This dual-layered approach—physical containment via ZIP and logical verification via AdES references and manifests—distinguishes ASiC from standalone signature formats, addressing risks of signature-document separation in long-term archiving or multi-party workflows.

Usage and Implementation

Signing and Packaging Process

The signing process for Associated Signature Containers (ASiC) begins with the generation of advanced electronic signatures or timestamps over one or more data objects, adhering to ETSI standards for formats such as CAdES (per EN 319 122-1) or (per EN 319 132-1), which ensure long-term validity through inclusion of certificates, revocation information, and optional timestamps. These signatures are detached, meaning they reference the data objects via hashes rather than embedding them, to maintain flexibility in packaging. The signer must use cryptographic algorithms compliant with ETSI TS 119 312, such as RSA-PSS with SHA-256 or ECDSA with SHA-256, to meet security requirements for qualified electronic signatures under . Packaging follows signature creation by encapsulating the elements into a ZIP archive (per RFC 4883 or ZIP APPNOTE), with no encryption and optional compression to preserve integrity during verification. Filenames use encoding, and the container must include a type file at the root (e.g., mimetype with content application/vnd.etsi.asic-s+zip for simple variants) as the first uncompressed entry for unambiguous identification. For ASiC-S (simple containers), packaging involves placing a single data object (e.g., a PDF or XML file) at the root, followed by a single signature or timestamp file in the META-INF directory, such as signatures.xml for (containing one or more <ds:Signature> elements) or signature.p7s for CAdES. This structure binds exactly one data object to its associated signature(s), supporting sequential signing by multiple parties via appended elements, with file extensions like .asics or .scs. In ASiC-E (extended containers), the process accommodates multiple data objects and signatures by organizing data files outside META-INF and placing signature files (e.g., *signatures*.xml for with <asic:XAdESSignatures> or *signature*.p7s for CAdES) alongside manifests like ASiCManifest.xml that explicitly list referenced files and their digests for validation. (e.g., *timestamp*.tst per RFC 3161) or evidence records (e.g., evidencerecord.ers) can be included for , with extensions like .asice. Each signature may cover a of files, enabling parallel or counter-signing scenarios while ensuring the ZIP's central directory accurately reflects the binding.

Validation and Verification

Validation and verification of Associated Signature Containers (ASiC) proceed in two primary phases: syntactic validation of the container's structure and semantic validation of the embedded signatures and bindings. Syntactic validation requires confirming that the ASiC file is a valid ZIP archive per the ZIP specification, with the "mimetype" entry positioned first, stored uncompressed without extra fields or compression, and containing the MIME type "application/vnd.etsi.asic-s+zip" for ASiC-S or "application/vnd.etsi.asic-e+zip" for ASiC-E. Required entries include data objects in the root or subfolders, signatures or timestamps in the META-INF directory, and, for extended containers, an ASiCManifest.xml or equivalent to reference multiple objects; deviations, such as mismatched digests or unauthorized entries, result in structural failure. Semantic validation extracts the AdES-compliant signatures (e.g., or CAdES) and verifies binding to data objects via ds:Reference elements in or digest lists in ASiCManifest.xml for CAdES, ensuring hashes match the actual file contents. Core checks follow ETSI EN 319 102-1 procedures: format conformance, extraction and identification of the signing certificate, cryptographic verification of the signature value using the public key and approved algorithms, and certificate path validation including chain construction to a trusted anchor and revocation status via CRL or OCSP. Timestamps, if included, undergo separate validation of their token signatures and signing times relative to the electronic signature production. For long-term viability, verification assesses embedded or referenced validation data like revocation information or archive timestamps to confirm past validity under current constraints, yielding statuses of TOTAL-PASSED (all checks succeed), TOTAL-FAILED (critical defects), or INDETERMINATE (insufficient data). Open-source implementations, such as the EU Digital Signature Service (DSS), automate these steps for ASiC, integrating trusted lists for certificate trust. Conformance tools like ETSI's Signature Checker further test against baseline profiles for interoperability.

Container Variants

ASiC-S (Simple Containers)

ASiC-S, or simple Associated Signature Containers, constitute a baseline format for binding a single data object to an or , ensuring persistent association during storage, transmission, and verification. Defined in ETSI EN 319 162-1, ASiC-S utilizes a ZIP archive structure compliant with ZIP specification version 4.4 or higher, employing encoding and prohibiting split archives or encryption to maintain accessibility and integrity. This format supports by packaging the at the alongside a single or file within a META-INF subdirectory, with an optional mimetype entry at the root declaring the type application/vnd.etsi.asic-s+zip. The container mandates exactly one data object, which may itself be a nested ZIP or other supported format, and one corresponding or assertion file, preventing fragmentation common in detached workflows. Supported formats include CAdES baseline signatures per ETSI EN 319 122-1 and XAdES baseline signatures per ETSI EN 319 132-1, alongside RFC 3161 timestamps or RFC 4998/6283 evidence records. File naming conventions require the file to use extensions such as .p7s for CAdES, .xml for XAdES, or .tst for timestamps, stored exclusively in META-INF to enforce a standardized verification path. Conformance to baseline profiles—B-B (basic), B-T (timestamped), B-LT (long-term), and B-LTA (archival)—ensures escalating levels of validity, with signatures verifiable against the contained data references. Unlike extended variants, ASiC-S restricts contents to a singular association, eschewing support for multiple independent objects or layered signatures, which simplifies for straightforward signing scenarios while mitigating risks of desynchronization. Recommended file extensions include .asics or .scs, though .zip is permissible with the MIME declaration to signal conformance. Validation involves extracting the ZIP, confirming the mimetype, and processing the META-INF entry against the root data file, yielding high reliability in eIDAS-compliant environments for qualified electronic signatures. Empirical adoption demonstrates reduced signature loss in archival systems, as the self-contained structure preserves without reliance on external manifests.

ASiC-E (Extended Containers)

The ASiC-E (Associated Signature Container Extended) format, defined in ETSI EN 319 162-1, provides a ZIP-based packaging mechanism to bind one or more data objects with multiple advanced electronic signatures or time assertions, enabling flexible management of signed content in electronic transactions. This structure supports the inclusion of diverse file types, such as documents or nested containers, referenced through an ASiCManifest.xml file in the META-INF directory, which enumerates data objects and their digests using SHA-256 or stronger algorithms ( prohibited). Signatures conform to (ETSI EN 319 132-1 and -2) or CAdES (ETSI EN 319 122-1 and -2) profiles, with time assertions via RFC 3161 timestamps or RFC 4998/6283 evidence records, and the container uses the MIME type application/vnd.etsi.asic-e+zip. Unlike ASiC-S, which limits association to a single primary data object and its signatures or timestamps, ASiC-E accommodates multiple data objects and permits sequential addition of signatures or validation material without disrupting prior bindings, making it suitable for workflows involving countersignatures or iterative validation updates. For XAdES-based ASiC-E, signature files (e.g., signatures*.xml) reference data via ds:Reference or ds:Manifest elements; CAdES variants use detached .p7s files with corresponding manifest entries. Containers adhere to ZIP constraints, including encoding and no split archives, with file extensions typically .asice or .sce for . ASiC-E incorporates baseline profiles (B-B, B-T, B-LT, B-LTA) to ensure progressive long-term validity, where B-B provides basic , B-T adds trusted timestamps, B-LT includes certificates and data, and B-LTA incorporates archival timestamps for extended preservation against key compromise or data degradation. This enables use cases such as multi-party contract signing, where successive signers append or CAdES structures referencing the container's manifest, or regulatory archiving requiring embedded validation evidence. Validation processes verify the ZIP , manifest consistency, and signature conformance per ETSI TS 119 172-1, confirming bindings without relying on external references unless specified.

Specialized Additional Containers

ETSI EN 319 162-2 specifies additional ASiC container profiles to address use cases outside the scope of baseline containers, focusing on enhanced for scenarios involving independent time assertions or alternative signature formats. These specialized variants maintain the ZIP-based structure of ASiC while incorporating elements like timestamp tokens from trusted service providers, enabling long-term validity without full electronic signatures in certain evidentiary contexts. One key type is the ASiC-S time assertion additional container, which associates one or more data objects with timestamp tokens rather than signatures, suitable for proving existence or integrity at a specific point without signer authentication. This variant uses a META-INF/ASiC-metadata.xml file to reference timestamp files, ensuring the container validates the timestamps' applicability to the enclosed data. Timestamp tokens comply with ETSI EN 319 421, providing cryptographic proof of data processing before a defined time, which supports non-repudiation in archiving or auditing processes. Extended additional containers include ASiC-E with CAdES, extending the baseline ASiC-E (limited to ) to support CMS-based signatures for multiple data objects and signatures, each potentially covering distinct subsets of files. This allows flexible binding in complex workflows, such as multi-party contracts, where CAdES signatures (per ETSI EN 319 122-1) enable embedding certificates and revocation data directly. Validation requires checking the ASiCManifest.xml for signature-data associations and verifying CAdES profiles up to long-term validation levels (CAdES-LT), ensuring sustained evidentiary value over decades. These additional containers also support hybrid use cases, such as combining timestamps with s in extended formats, to mitigate risks of signature invalidation due to expired certificates by incorporating archival timestamps. Conformance testing, as outlined in ETSI TS 119 162-2, emphasizes structural integrity, metadata accuracy, and format-specific validation to prevent interoperability failures in eIDAS-compliant systems. Adoption remains niche compared to baseline types, primarily in preservation services where timestamp-only proof suffices, as evidenced by their integration in tools like the European Commission's Digital Signature Service for optional timestamping.

Benefits and Empirical Advantages

Enhanced Interoperability

Associated Signature Containers (ASiC) promote enhanced interoperability through a standardized ZIP-based packaging mechanism that bundles one or more electronic documents with their corresponding advanced electronic signatures—formatted according to CAdES, XAdES, or PAdES baselines—alongside optional timestamps, certificates, and revocation data within a single, self-contained archive. This approach, outlined in ETSI EN 319 162-1, eliminates dependencies on external file associations or proprietary wrappers, enabling seamless processing by conforming software across vendors and platforms without loss of signature integrity during transit or storage. The standard defines baseline container profiles at four levels (e.g., ASiC-S Baseline and ASiC-E Baseline), which restrict options to those maximizing cross-system compatibility for common and business applications, such as multi-signature workflows and long-term validation needs. These profiles facilitate interchange by enforcing a consistent internal structure, including mandatory entries (e.g., application/vnd.etsi.asic-e+zip for extended containers), which support automatic recognition and handling in diverse environments like systems and tools. Empirical validation of this occurs via ETSI-organized Plugtests events, which conduct test suites assessing conformance and mutual recognition among implementations; for instance, events since 2014 have covered ASiC signature packaging, revealing high compatibility rates for baseline profiles while identifying edge-case refinements. In practice, this reduces verification failures in multinational settings, as the container's manifest and references ensure atomic handling, contrasting with detached signature models prone to desynchronization in non-standardized exchanges.

Mitigation of Signature Loss Risks

Associated Signature Containers (ASiC) address signature loss risks primarily through their ZIP-based structure, which binds data objects, detached electronic signatures, and associated validation elements—such as certificates, timestamps, and revocation information—into a single, tamper-evident package. This prevents accidental or inadvertent separation of signatures from signed content during file handling, archiving, transmission, or workflow processing, where detached signatures in traditional formats might be overlooked, deleted, or mismatched. The ETSI EN 319 162-1 standard specifies this binding mechanism to maintain the integrity and association of components, reducing vulnerabilities to data fragmentation that could render signatures unverifiable. In scenarios involving multiple signers or iterative signing, ASiC-S (simple containers) supports attaching additional signatures to existing ones without invalidating prior validations, mitigating risks of cumulative invalidation from sequential modifications. For extended use cases, ASiC-E variants incorporate advanced formats like XAdES or CAdES, embedding long-term validation data (e.g., archival timestamps per ETSI EN 319 122 profiles) to preserve verifiability against certificate expiration, key compromise, or algorithm obsolescence over decades. This inclusion of self-contained evidence counters time-dependent degradation, where absent revocation or chain-of-trust data might otherwise lead to signature invalidation during future audits. Empirical advantages stem from standardized profiles (e.g., ASiC Baseline under ), which enforce types and entry naming conventions in the ZIP archive to facilitate automated verification tools in detecting and processing complete containers, thereby minimizing human-error-induced losses in enterprise systems. While not immune to deliberate tampering, the container's design supports optional sealing mechanisms and hash-based integrity checks, enhancing resilience in archival repositories compliant with standards like ETSI EN 319 162-1. Adoption in EU qualified trust services has demonstrated reduced invalidation rates in long-term preservation, as the bundled structure obviates reliance on external repositories for validation artifacts that may become unavailable.

Limitations and Potential Drawbacks

Technical Constraints

Associated Signature Containers (ASiC) are constrained by their reliance on the ZIP format, which prohibits the use of multiple volume splits and limits compression methods to either no compression or as defined in IETF RFC 1951. File names and comments must be encoded in ISO/IEC 10646 , ensuring compatibility but restricting legacy systems without support. In ASiC-S variants, a fundamental limitation is the allowance of only one data file at the root level alongside a single signature or time assertion file in the META-INF directory, restricting applicability to simple, single-document scenarios. Supported formats are confined to CAdES, XAdES, or specific time assertions per IETF RFC 3161, RFC 4998, or RFC 6283, with file extensions limited to .asics (or .scs/.zip variants for compatibility). This structure precludes multiple signatures or assertions on separate files without nesting, potentially complicating workflows involving diverse or iterative signing. ASiC-E variants permit multiple data files and signatures but mandate an ASiCManifest.xml for precise referencing of each signed object, introducing overhead in manifest creation and validation to ensure no external file dependencies. Baseline profiles further restrict signatures to CAdES or as per ETSI EN 319 122-1 or EN 319 132-1, explicitly prohibiting the digest algorithm due to its vulnerabilities. While no explicit upper bounds on file count or size are imposed beyond ZIP's practical limits (typically up to 4 GB per entry in compliant implementations), validation requires computing and verifying digests for all referenced objects, escalating computational demands for large or numerous files. Long-term validation in baseline levels (B-B, B-T, B-LT, B-LTA) depends on embedded certificates, data, and timestamps, but CAdES Archive Time-stamps do not inherently ensure indefinite validity without supplementary preservation measures. Processing ASiC requires robust ZIP handling libraries capable of decompression and XML parsing for manifests/signatures, with interoperability risks arising from varying ZIP implementation behaviors across platforms. Nesting of containers is supported but amplifies these demands, as validators must recursively process inner structures.

Security and Compatibility Challenges

Associated Signature Containers (ASiC), being ZIP-based formats that encapsulate signed data objects alongside detached signatures in CAdES or formats, introduce security risks primarily through dependencies on these underlying signature standards and the container structure itself. Multiple nested signatures or containers can complicate validation processes, potentially allowing incomplete or erroneous verification if identifiers like DSId (per ISO 14533-4) are not properly utilized, as validators may fail to isolate and confirm only the intended signed content. When employing signatures within ASiC, vulnerabilities such as XML element wrapping attacks pose risks to integrity, where manipulated XML structures could evade detection; ETSI recommends preferring CAdES for XML-associated files to mitigate such issues. The ZIP foundation of ASiC inherits general archive handling risks, including potential path traversal or resource exhaustion if validation software does not enforce strict and sanitization of file paths and contents, though no ASiC-specific CVEs have been widely documented as of 2025. ETSI TS 119 164-4 specifies testing profiles to detect syntax-related security flaws in ASiC files, underscoring the need for rigorous conformance checks to prevent malformed containers from undermining signature authenticity. Compatibility challenges arise from inconsistent implementation across validation tools, as evidenced by ETSI Plugtests events identifying issues such as the handling of META-INF/manifest.xml in ASiC-E containers using signatures, where failure to define types for unsigned files can lead to misinterpretation of content. Containers with duplicate file names or paths violate unique identifiability requirements via ds: URIs, necessitating validation to ensure data object integrity, yet not all software enforces this uniformly. ASiC-S variants face inherent limitations, including inability to apply multiple timestamps, restricting long-term validation scenarios compared to ASiC-E. These interoperability gaps, highlighted in DSS updates addressing in-file processing inefficiencies, demand standardized to align tools like those from ETSI's signature checker.

Adoption and Real-World Impact

European Union Deployment

The deployment of Associated Signature Containers (ASiC) in the aligns with the Regulation (EU) No 910/2014, which took effect on July 1, 2016, establishing mutual recognition of electronic signatures and trust services across member states. ASiC formats, particularly ASiC-S and ASiC-E variants, enable the packaging of one or more documents with advanced electronic signatures (AdES) or qualified electronic signatures (QES) in a ZIP-based structure, supporting and CAdES profiles for interoperability and long-term validity. This facilitates compliance for qualified trust service providers (QTSPs) in scenarios requiring multiple signatories or attachment bundling, such as and administrative approvals, without mandating ASiC exclusively but recommending it for enhanced preservation. ETSI standards, notably EN 319 162-1 published in February 2016, define ASiC baseline containers to meet requirements for signature integrity and validation, including timestamping and evidence for extended forms. The European Commission's Service (DSS), an open-source library updated as of August 2025, integrates ASiC validation to verify signatures in applications, ensuring cross-border usability under Article 32. QTSPs, accredited in at least 11 member states by 2019, utilize ASiC for QES creation, with interoperability tested via ETSI Plugtests events starting in 2015 to address format conformance. In practice, ASiC deployment varies by member state, with higher integration in digitally advanced nations like —where DigiDoc containers prefigure ASiC principles—and the for cross-border e-signing in SMEs and public services. Northern European countries exhibit stronger eID adoption rates exceeding 90% as of 2025, indirectly boosting ASiC usage in trust services, though exact container-specific metrics remain limited due to decentralized implementation. Public administrations leverage ASiC to mitigate risks in multi-document signing, as endorsed by the Commission for e-invoicing under Directive 2014/55/, promoting standardized formats over disparate national systems. Challenges include varying QTSP accreditation, with 30 conformity assessment bodies operational by 2019, underscoring the need for ongoing harmonization.

Broader Global Usage

Associated Signature Containers (ASiC) have limited adoption outside the , largely restricted to (EEA) countries such as , , and , which incorporate eIDAS-equivalent regulations and thus support ETSI ASiC standards for advanced electronic signatures. These nations maintain trusted lists compatible with EU formats, enabling ASiC usage in and cross-border services aligned with European norms. In the , post-Brexit divergence from has reduced mandatory reliance on ASiC, though voluntary implementation persists in scenarios involving interoperability, such as trade documentation or multinational contracts where ETSI-compliant tools are employed. Switzerland, while not part of the EEA, recognizes advanced electronic signatures under its Federal Act on Electronic Signatures and participates in mutual recognition frameworks that accommodate ETSI formats like ASiC for bilateral exchanges. However, no comprehensive data indicates widespread institutional adoption in these contexts as of 2025. Beyond Europe, verifiable instances of ASiC deployment are scarce, with global electronic signature practices favoring national standards or UNCITRAL Model Law implementations that do not mandate container formats like ASiC. For example, in the , , and , jurisdictions such as the (under ESIGN Act and UETA), , , and various Asian nations prioritize simple or standard electronic signatures without specifying ASiC, leading to reliance on formats like or proprietary systems. ASiC's ZIP-based structure and integration with /CAdES provide potential for international validation rather than native usage, as evidenced by tools like Estonia's DigiDoc4, which supports ASiC-E long-term (LT) signatures claimed to offer superior cross-border compatibility for verification purposes. This facilitates ad-hoc global handling in hybrid EU-non-EU workflows, but systemic adoption remains constrained by regional regulatory silos and the absence of ASiC references in non-European standards bodies. ETSI specifications emphasize European compliance, with no documented extensions to international bodies like ISO for broader mandates.

References

  1. https://www.etsi.org/deliver/etsi_en/319100_319199/31916201/01.01.01_60/en_31916201v010101p.pdf
  2. https://www.etsi.org/deliver/etsi_ts/102900_102999/102918/01.03.01_60/ts_102918v010301p.pdf
  3. https://ec.europa.eu/digital-building-blocks/sites/spaces/DIGITAL/pages/467109093/Standards%2Band%2Bspecifications
  4. https://www.etsi.org/deliver/etsi_ts/102900_102999/102918/01.01.01_60/ts_102918v010101p.pdf
  5. https://www.etsi.org/deliver/etsi_ts/103100_103199/103171/01.01.01_60/ts_103171v010101p.pdf
  6. https://portal.etsi.org/Portals/0/TBpages/CTI/Docs/ASIC2014_Plugtests_Technical_Report_1.0.0.pdf
  7. https://www.etsi.org/deliver/etsi_en/319100_319199/31916202/01.01.01_60/en_31916202v010101p.pdf
  8. https://www.etsi.org/deliver/etsi_ts/119500_119599/119511/01.02.01_60/ts_119511v010201p.pdf
  9. https://www.etsi.org/deliver/etsi_en/319100_319199/31912201/01.02.01_60/en_31912201v010201p.pdf
  10. https://ec.europa.eu/digital-building-blocks/wikis/display/DIGITAL/eSignature%2BFAQ
  11. https://www.cryptomathic.com/blog/asic-associated-signature-containers-for-eidas
  12. https://eur-lex.europa.eu/legal-content/EN/TXT/HTML/?uri=CELEX:32015D1506
  13. https://ec.europa.eu/digital-building-blocks/sites/spaces/DIGITAL/pages/467109107/Digital%2BSignature%2BService%2B-%2BDSS
  14. https://www.id.ee/en/article/bdoc-cdoc-and-asice-digidoc-file-formats-4/
  15. https://www.agrello.io/digital-signing/what-is-asic-container-and-xades-signature
  16. https://www.digdir.no/media/995/download
  17. https://tdra.gov.ae/-/media/About/Trust-Services/Guidelines/Guidelines-for-Digital-Signature-Standard-Manual.ashx
  18. https://www.etsi.org/deliver/etsi_en/319100_319199/31910201/01.03.01_60/en_31910201v010301p.pdf
  19. https://signatures-conformance-checker.etsi.org/
  20. https://www.etsi.org/deliver/etsi_ts/119100_119199/11916405/01.01.01_60/ts_11916405v010101p.pdf
  21. https://ec.europa.eu/digital-building-blocks/DSS/webapp-demo/doc/dss-documentation.html
  22. https://www.etsi.org/deliver/etsi_en/319100_319199/31916201/01.01.00_30/en_31916201v010100v.pdf
  23. https://www.etsi.org/deliver/etsi_ts/102900_102999/102918/01.02.01_60/ts_102918v010201p.pdf
  24. https://www.etsi.org/deliver/etsi_sr/003100_003199/003186/02.01.01_60/sr_003186v020101p.pdf
  25. https://www.etsi.org/deliver/etsi_ts/119100_119199/11916402/02.01.01_60/ts_11916402v020101p.pdf
  26. https://www.etsi.org/deliver/etsi_en/319100_319199/31916201/01.00.00_20/en_31916201v010000a.pdf
  27. https://www.agrello.io/posts/what-is-asic-container-and-xades-signature
  28. https://www.nbu.gov.sk/data/att/353.pdf
  29. https://www.etsi.org/deliver/etsi_ts/119100_119199/11916404/01.01.01_60/ts_11916404v010101p.pdf
  30. https://portal.etsi.org/Portals/0/TBpages/CTI/Docs/eSignature_Validation_2016_Plugtests_report_1.0.pdf
  31. http://signatures-conformance-checker.etsi.org/
  32. https://www.etsi.org/newsroom/press-releases/1010-2015-10-press-etsi-enables-chain-of-trust-for-digital-signatures
  33. https://www.id.ee/en/article/electronic-signatures-and-addressing-them-in-europe/
  34. https://www.agrello.io/post/cross-border-digital-identity-and-e-signing-in-the-baltic-states-a-practical-guide-for-smes
  35. https://docbox.etsi.org/Workshop/2025/10_SECURITY_CONFERENCE/9OCTOBER/CRAPROGRESSandPERSPECTIVES/SECTIGO_BARREIRA.pdf
  36. https://sign.dropbox.com/en-GB/blog/electronic-signature-laws-around-the-world-a-look-at-esignature-laws-by-country
  37. https://www.ssl.com/article/digital-document-signing-laws/
Add your contribution
Related Hubs
User Avatar
No comments yet.