Associated Signature Containers

Last updated
Associated Signature Container Extended (ASiC-E)
Filename extension
.asice, .sce
Internet media type
application/vnd.
etsi.asic-e+zip
Magic number 50 4B 03 04 (the container media type is present starting at offset 38) [1]
Developed by ETSI
Initial release2011
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.
etsi.asic-s+zip
Magic number 50 4B 03 04 (the container media type is present starting at offset 38) [1]
Developed by ETSI
Initial release2011
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. [2]

Contents

Regulatory context

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

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

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

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)

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)

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

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

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

ASiC-E time assertion additional container

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

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

Related Research Articles

In the realm of electronic technology, ASIC stands for application-specific integrated circuit, an integrated circuit customized for a specific task.

<span class="mw-page-title-main">PDF</span> Portable Document Format, a digital file format

Portable Document Format (PDF), standardized as ISO 32000, is a file format developed by Adobe in 1992 to present documents, including text formatting and images, in a manner independent of application software, hardware, and operating systems. Based on the PostScript language, each PDF file encapsulates a complete description of a fixed-layout flat document, including the text, fonts, vector graphics, raster images and other information needed to display it. PDF has its roots in "The Camelot Project" initiated by Adobe co-founder John Warnock in 1991. PDF was standardized as ISO 32000 in 2008. The last edition as ISO 32000-2:2020 was published in December 2020.

ZIP is an archive file format that supports lossless data compression. A ZIP file may contain one or more files or directories that may have been compressed. The ZIP file format permits a number of compression algorithms, though DEFLATE is the most common. This format was originally created in 1989 and was first implemented in PKWARE, Inc.'s PKZIP utility, as a replacement for the previous ARC compression format by Thom Henderson. The ZIP format was then quickly supported by many software utilities other than PKZIP. Microsoft has included built-in ZIP support in versions of Microsoft Windows since 1998 via the "Plus! 98" addon for Windows 98. Native support was added as of the year 2000 in Windows ME. Apple has included built-in ZIP support in Mac OS X 10.3 and later. Most free operating systems have built in support for ZIP in similar manners to Windows and macOS.

S/MIME is a standard for public-key encryption and signing of MIME data. S/MIME is on an IETF standards track and defined in a number of documents, most importantly RFC 8551. It was originally developed by RSA Data Security, and the original specification used the IETF MIME specification with the de facto industry standard PKCS #7 secure message format. Change control to S/MIME has since been vested in the IETF, and the specification is now layered on Cryptographic Message Syntax (CMS), an IETF specification that is identical in most respects with PKCS #7. S/MIME functionality is built into the majority of modern email software and interoperates between them. Since it is built on CMS, MIME can also hold an advanced digital signature.

An electronic signature, or e-signature, is data that is logically associated with other data and which is used by the signatory to sign the associated data. This type of signature has the same legal standing as a handwritten signature as long as it adheres to the requirements of the specific regulation under which it was created.

The Time-Stamp Protocol, or TSP is a cryptographic protocol for certifying timestamps using X.509 certificates and public key infrastructure. The timestamp is the signer's assertion that a piece of electronic data existed at or before a particular time. The protocol is defined in RFC 3161. One application of the protocol is to show that a digital signature was issued before a point in time, for example before the corresponding certificate was revoked.

XAdES is a set of extensions to XML-DSig recommendation making it suitable for advanced electronic signatures. W3C and ETSI maintain and update XAdES together.

Digital Signature Services (DSS) is an OASIS standard.

Trusted timestamping is the process of securely keeping track of the creation and modification time of a document. Security here means that no one—not even the owner of the document—should be able to change it once it has been recorded provided that the timestamper's integrity is never compromised.

CAdES is a set of extensions to Cryptographic Message Syntax (CMS) signed data making it suitable for advanced electronic signatures.

The ISO base media file format (ISOBMFF) is a container file format that defines a general structure for files that contain time-based multimedia data such as video and audio. It is standardized in ISO/IEC 14496-12, a.k.a. MPEG-4 Part 12, and was formerly also published as ISO/IEC 15444-12, a.k.a. JPEG 2000 Part 12.

PAdES is a set of restrictions and extensions to PDF and ISO 32000-1 making it suitable for advanced electronic signatures (AdES). This is published by ETSI as EN 319 142.

<span class="mw-page-title-main">DigiDoc</span> File format family

DigiDoc is a family of digital signature- and cryptographic computing file formats utilizing a public key infrastructure. It currently has three generations of sub formats, DDOC-, a later binary based BDOC and currently used ASiC-E format that is supposed to replace the previous generation formats. DigiDoc was created and is developed and maintained by RIA.

JSON Web Token is a proposed Internet standard for creating data with optional signature and/or optional encryption whose payload holds JSON that asserts some number of claims. The tokens are signed either using a private secret or a public/private key.

eIDAS EU electronic identification regulation

eIDAS is an EU regulation with the stated purpose of governing "electronic identification and trust services for electronic transactions". It passed in 2014 and its provisions came into effect between 2016 and 2018.

An advanced electronic signature is an electronic signature that has met the requirements set forth under EU Regulation No 910/2014 (eIDAS-regulation) on electronic identification and trust services for electronic transactions in the European Single Market.

ZertES is a Swiss Federal law that regulates the conditions under which trust service providers may use certification services with electronic signatures. Additionally, this law provides a framework that outlines the provider’s obligations and rights as they apply to providing their certification services.

A qualified electronic signature is an electronic signature that is compliant with EU Regulation No 910/2014 for electronic transactions within the internal European market. It enables to verify the authorship of a declaration in electronic data exchange over long periods of time. Qualified electronic signatures can be considered as a digital equivalent to handwritten signatures.

A trust service provider (TSP) is a person or legal entity providing and preserving digital certificates to create and validate electronic signatures and to authenticate their signatories as well as websites in general. Trust service providers are qualified certificate authorities required in the European Union and in Switzerland in the context of regulated electronic signing procedures.

References

  1. 1 2 3 4 5 6 "Electronic Signatures and Infrastructures (ESI); Associated Signature Containers (ASiC); Part 1: Building blocks and ASiC baseline containers (ETSI EN 319 162-1 V1.1.1 (2016-04)" (PDF). European Telecommunications Standards Institute.
  2. 1 2 3 4 5 6 7 8 9 10 Turner, Dawn M. "ASiC - Associated Signature Containers for eIDAS". Cryptomathic. Retrieved 13 June 2017.
  3. ↑ "Regulation (EU) No 910/2014 of the European Parliament and of the Council of 23 July 2014 on electronic identification and trust services for electronic transactions in the internal market and repealing Directive 1999/93/EC". EUR-Lex. The European Parliament and the Council of the European Union. Retrieved 18 March 2016.
  4. ↑ "COMMISSION IMPLEMENTING DECISION (EU) 2015/1506 of 8 September 2015 laying down specifications relating to formats of advanced electronic signatures and advanced seals to be recognised by public sector bodies pursuant to Articles 27(5) and 37(5) of Regulation (EU) No 910/2014 of the European Parliament and of the Council on electronic identification and trust services for electronic transactions in the internal market" . Retrieved 18 March 2018.
  5. ↑ "Commission Implementing Decision (EU) 2015/1506 of 8 September 2015 laying down specifications relating to formats of advanced electronic signatures and advanced seals to be recognised by public sector bodies pursuant to Articles 27(5) and 37(5) of Regulation (EU) No 910/2014 of the European Parliament and of the Council on electronic identification and trust services for electronic transactions in the internal market (Text with EEA relevance)". EUR-Lex. 9 September 2015. Material has been copied from this source. Reuse is authorised, provided the source is acknowledged.
  6. 1 2 3 4 "Electronic Signatures and Infrastructures (ESI); Associated Signature Containers (ASiC); Part 2: Additional ASiC containers (ETSI EN 319 162-2 V1.1.1 (2016-04)" (PDF). European Telecommunications Standards Institute.
  7. ↑ Adams, C.; Cain, P.; Pinkas, D.; Zuccherato, R. "Internet X.509 Public Key Infrastructure - Time-Stamp Protocol (TSP)". Network Working Group. Retrieved 13 June 2017.
  8. ↑ Gondrom, T.; Brander, R.; Pordesch, U. "Evidence Record Syntax (ERS)". Network Working Group. Retrieved 13 June 2017.
  9. ↑ Jerman Blazic, A.; Saljic, S.; Gondrom, T. "Extensible Markup Language Evidence Record Syntax (XMLERS)". Internet Engineering Task Force (IETF). Retrieved 13 June 2017.
This page is based on this Wikipedia article
Text is available under the CC BY-SA 4.0 license; additional terms may apply.
Images, videos and audio are available under their respective licenses.