eSignature FAQ

An electronic signature is a data in electronic form which is attached to or logically associated with other data in electronic form and which is used by the signatory to sign, where the signatory is a natural person.

Like its handwritten counterpart in the offline world, an electronic signature can be used, for instance, to electronically indicate that the signatory has written the document, agreed with the content of the document, or that the signatory was present as a witness.

In case you want to seal a document as a legal person (e.g. as a business or organisation), you might be instead interested in an electronic seal ( What is an electronic seal?).

An electronic seal is a data in electronic form, which is attached to or logically associated with other data in electronic form to ensure the latter’s origin and integrity, where the creator of a seal is a legal person (unlike the electronic signature that is issued by a natural person).

In this purpose, electronic seals might serve as evidence that an electronic document was issued by a legal person, ensuring certainty of the document’s origin and integrity. Nevertheless, across the European Union, when a transaction requires a qualified electronic seal from a legal person, a qualified electronic signature from the authorised representative of the legal person is equally acceptable.

An ‘electronic signature’ is a legal concept that is defined in eIDAS by the following:

“‘electronic signature’ means data in electronic form which is attached to or logically associated with other data in electronic form and which is used by the signatory to sign;” (eIDAS Article 3.10)

A digital signature, on the other hand, refers to a mathematical and cryptographic concept that is widely used to provide concrete and practical instances of electronic signature. The definition given by ETSI TR 119 100 is that of data appended to, or a cryptographic transformation of a data unit that allows a recipient of the data unit to prove the source and integrity of the data unit and protect against forgery e.g. by the recipient.

These two concepts should be distinguished, as all electronic signatures are not necessarily digital signatures.

More information about the levels of electronic signatures can be found in the FAQ entry What are the levels (simple, advanced and qualified) of electronic signatures?

The eIDAS Regulation defines three levels of electronic signature: 'simple' electronic signature, advanced electronic signature and qualified electronic signature. The requirements of each level are built on the requirements of the level below it, such that a qualified electronic signature meets the most requirements and a 'simple' electronic signature the least.

'Simple' electronic signatures

An electronic signature is defined as "data in electronic form which is attached to or logically associated with other data in electronic form and which is used by the signatory to sign". Thus, something as simple as writing your name under an e-mail might constitute an electronic signature.

Advanced electronic signatures (AdES)

An advanced electronic signature is an electronic signature which is additionally:

• uniquely linked to and capable of identifying the signatory;
• created in a way that allows the signatory to retain control;
• linked to the document in a way that any subsequent change of the data is detectable.

The most commonly used technology able to provide these requirements relies on the use of a public-key infrastructure (PKI), which involves the use of certificates and cryptographic keys.

Qualified electronic signatures (QES)

A qualified electronic signature is an advanced electronic signature which is additionally:

• created by a qualified signature creation device (QSCD);
• and is based on a qualified certificate for electronic signatures.

Like the electronic signature, the eIDAS Regulation defines three levels of electronic seal: 'simple' electronic seal, advanced electronic seal and qualified electronic seal. The requirements of each level are built on the requirements of the level below it, such that a qualified electronic seal meets the most requirements and a 'simple' electronic seal the least.

Nevertheless, levels of electronic seals don’t have the same definitions, requirements, nor legal effects than levels of electronic signatures:

'Simple' electronic seals

An electronic seal is defined as "data in electronic form, which is attached to or logically associated with other data in electronic form to ensure the latter’s origin and integrity".

Advanced electronic seals (AdES)

An advanced electronic seal is an electronic seal which is additionally:

• uniquely linked to the creator of the seal;
• capable of identifying the creator of the seal;
• created using electronic seal creation data that the creator of the seal can, with a high level of confidence under its control, use for electronic seal creation; and
• linked to the data to which it relates in such a way that any subsequent change in the data is detectable.

The most commonly used technology able to provide these requirements relies on the use of a public-key infrastructure (PKI), which involves the use of certificates and cryptographic keys.

Qualified electronic seals (QES)

Similar to a qualified electronic signature, a qualified electronic seal is an advanced electronic seal which is additionally:

• created by a qualified seal creation device (QSCD);
• and is based on a qualified certificate for electronic seals.

When signing a document, a pair of keys might be needed (i.e. when the signature relies on the use of public-key infrastructure), namely a ‘public key’ and a ‘private key’. The public key can be publicly shared while the private key shall be securely stored. Especially, the private key is used by the signatory to sign a document while the public key is used by anyone verifying that it is actually the private key of the signatory that has been used to sign the document.

A certificate for electronic signatures, issued by a Certificate Authority (CA), is an electronic attestation which links electronic signature validation data to a natural person and confirms at least the name or the pseudonym of that person. This way, the certificate, usually linked to the signed document, can be used to verify the identity of the signatory and whether the document has been signed using the corresponding private key.

Qualified certificates for electronic signatures, by following stricter requirements laid down in eIDAS, provide, for instance, higher guarantees regarding the identity of the signatory and therefore higher legal certainty regarding the created electronic signatures. Especially, qualified certificates are provided by qualified trust service providers (QTSP) which have been audited as such and granted a qualified status by a national competent authority, as reflected in the national Trusted List. Those lists, and therefore QTSPs listed in it, can be browsed in a user-friendly way using the Trusted List Browser (the actual content of these Trusted Lists is managed and published by each Member State and ‘Trusted List Browser’ is “merely” browsing these Trusted Lists).

Usually, providers of qualified certificates for electronic signatures deliver the corresponding private key on a qualified signature creation device (QSCD).

When sealing a document, a pair of keys might be needed (i.e. when the seal relies on the use of public-key infrastructure), namely a ‘public key’ and a ‘private key’. The public key can be publicly shared while the private key shall be securely stored. Especially, the private key is used by the creator of the seal to seal a document while the public key is used by anyone verifying that it is actually the private key of the creator of the seal that has been used to seal the document.

A certificate for electronic seals, issued by a Certificate Authority (CA), is an electronic attestation that links electronic seal validation data to a legal person and confirms the name of that person. This way, the certificate, usually linked to the sealed document, can be used to verify the identity of the creator of the seal and whether the document has been sealed using the corresponding private key.

Like qualified certificates for electronic signatures, qualified certificates for electronic seals, by following stricter requirements laid down in eIDAS, provide, for instance, higher guarantees regarding the identity of the creator of the seal and therefore higher legal certainty regarding the created electronic seals. Especially, qualified certificates are provided by qualified trust service providers (QTSP) which have been audited as such and granted a qualified status by a national competent authority, as reflected in the national Trusted List. Those lists, and therefore QTSPs listed in it, can be browsed in a user-friendly way using the Trusted List Browser (the actual content of these Trusted Lists is managed and published by each Member State and ‘Trusted List Browser’ is “merely” browsing these Trusted Lists).

Usually, providers of qualified certificates for electronic seals deliver the corresponding private key on a qualified seal creation device (QSCD).

Signature/seal creation devices come in many forms to protect the electronic signature/seal creation data (e.g. private key) of the signatory/creator of the seal, such as smartcards, SIM cards, USB sticks. A qualified signature/seal creation device (QSCD), by following stricter requirements laid down in eIDAS, offers higher guarantees regarding the protection (e.g. mitigating any kind of replication or forgery) of the electronic signature/seal creation data (such as the private key) and therefore higher legal certainty regarding the created qualified electronic signatures/seals.

For example, a smartcard (e.g. ID card), when following specific requirements, can be seen as a QSCD as, in order to “unlock” the electronic signature creation data, the signatory shall physically possess the smartcard and know the associated PIN code.

A QSCD is not necessarily in the physical possession of the signatory/creator of the seal but can also be remotely managed by a qualified trust service provider (QTSP). This kind of QSCD is known as “remote QSCD”. Those remote QSCD offer an improved user experience while maintaining the legal certainty offered by qualified electronic signatures/seals.

Across all EU Member States, the legal effects of electronic signatures are laid down in Article 25 of eIDAS.

An electronic signature (either simple, advanced or qualified) shall not be denied legal effect and admissibility as evidence in legal proceedings solely on the grounds that it is in an electronic form or that it does not meet the requirements for qualified electronic signatures.

Regarding qualified electronic signatures, they explicitly have the equivalent legal effect of handwritten signatures across all EU Member States.

Across all EU Member States, the legal effects of electronic seals are laid down in Article 35 of eIDAS.

Like an electronic signature, an electronic seal shall not be denied legal effect and admissibility as evidence in legal proceedings solely on the grounds that it is in an electronic form or that it does not meet the requirements for qualified electronic seals.

Regarding qualified electronic seals, they explicitly enjoy the presumption of integrity of the data and of correctness of the origin of that data to which the qualified electronic seal is linked across all EU Member States.

While different levels of electronic signatures may be appropriate in different contexts, only qualified electronic signatures are explicitly recognized to have the equivalent legal effect of hand-written signatures all over EU Member States.

Moreover, as a general rule, if a certain level of electronic signature (e.g. advanced signature) is required, a higher level will probably be accepted (e.g. advanced signature with a qualified certificate, qualified electronic signature).

While different levels of electronic seals may be appropriate in different contexts, only qualified electronic seals explicitly enjoy the presumption of integrity of the data and of correctness of the origin of that data to which the qualified electronic seal is linked, all over EU Member States.

Moreover, as a general rule, if a certain level of electronic seal (e.g. advanced seal) is required, a higher level will probably be accepted (e.g. advanced signature with a qualified seal, qualified electronic seal).

Nevertheless, when a transaction requires a qualified electronic seal from a legal person, a qualified electronic signature from the authorised representative of the legal person is equally acceptable.

In the first place, in order to sign documents as a natural person (in order to seal documents as a legal person, you might be instead interested in electronic seals), a certificate for electronic signatures is needed. And, using this certificate, electronic signatures can be created. As part of the eIDAS Regulation, these certificates can be purchased from specific providers, named Trust Service Providers (TSP).

• Obtain a digital certificate from a TSP

In the case of an ‘advanced electronic signature’, the certificate can be or not qualified. In the case of a ‘qualified electronic signature’, the certificate shall be qualified and the private key related to the certificate shall be stored on a ‘qualified electronic signature creation device’ (QSCD).

As a general rule, if a certain level of electronic signature (e.g. advanced signature) is required, a higher level will probably be accepted (e.g. advanced signature with a qualified certificate, qualified electronic signature).

As laid down in eIDAS, a qualified electronic signature explicitly has the equivalent legal effect of a handwritten signature.

Providers of qualified certificates for electronic signatures, as an eIDAS legal obligation, are mandatorily listed in the corresponding national Trusted List. But providers of non-qualified certificates for electronic signatures could be but are not mandatorily listed in these Trusted Lists.

Trusted Lists, and therefore the providers listed in it, can be browsed in a user-friendly way using the Trusted List Browser. The actual content of these Trusted Lists is managed and published by each Member State and Trusted List Browser is “merely” browsing these Trusted Lists.

• Choose your TSP using Trusted List Browser

Using Trusted List Browser, go to “Search by Type of service” (top left of the screen).

Select “Certificate for electronic signature” and/or “Qualified certificate for electronic signature” and click “Next”.

Then, select any country you may found appropriate and click “Search”.

Finally, click on any TSP you may found appropriate and, via the “Electronic address” multi-part field of the “Detailed information”, you will find a link to a website providing more information about this provider and the products it provides.

• Sign your document

Once you have a certificate for electronic signature, you will be able to sign documents. TSPs might offer their own step-by-step process for signing digitally.

The European Commission also proposes a demo of DSS, a tool enabling, among other features, the signature of documents. This demo is based on the open-source library Digital Signature Software (DSS). DSS supports the creation and verification of interoperable and secure electronic signatures in line with the eIDAS Regulation. More information is available in the documentation.

In the first place, in order to seal documents as a legal person, a certificate for electronic seals is actually needed. And, using this certificate, electronic seals can be created. As part of the eIDAS Regulation, these certificates can be purchased from specific providers, named Trust Service Providers (TSP).

1.  Obtain a digital certificate from a TSP

In the case of an ‘advanced electronic seal’, the certificate can be or not qualified. In the case of a ‘qualified electronic seal’, the certificate shall be qualified and the private key related to the certificate shall be stored on a ‘qualified electronic seal creation device’ (QSCD).

As a general rule, if a certain level of electronic seal (e.g. advanced seal) is required, a higher level will probably be accepted (e.g. advanced seal with a qualified certificate, qualified electronic seal).

As laid down in eIDAS, a qualified electronic seal explicitly enjoys the presumption of integrity of the data and of correctness of the origin of that data to which the qualified electronic seal is linked.

Providers of qualified certificates for electronic seals, as an eIDAS legal obligation, are mandatorily listed in the corresponding national Trusted List. But providers of non-qualified certificates for electronic seals could be but are not mandatorily listed in these Trusted Lists.

Trusted Lists, and therefore the providers listed in it, can be browsed in a user-friendly way using the Trusted List Browser. The actual content of these Trusted Lists is managed and published by each Member State and ‘Trusted List Browser’ is “merely” browsing these Trusted Lists.

2.  Choose your TSP using Trusted List Browser

Using Trusted List Browser, go to “Search by Type of service” (top left of the screen).

Select “Certificate for electronic seal” and/or “Qualified certificate for electronic seal” and click “Next”.

Then, select any country you may found appropriate and click “Search”.

Finally, click on any TSP you may found appropriate and, via the “Electronic address” multi-part field of the “Detailed information”, you will find a link to a website providing more information about this provider and the products it provides.

3.   Seal your document

Once you have a certificate for electronic seal, you will be able to seal documents. TSPs might offer their own step-by-step process for sealing digitally.

The European Commission also proposes a demo of DSS, a tool enabling, among other features, the signature and seal of documents. This demo is based on the open-source library Digital Signature Software (DSS). DSS supports the creation and verification of interoperable and secure electronic signatures/seals in line with the eIDAS Regulation. More information is available in the documentation.

Three formats of advanced signature and one format of signature container are specified in the European Telecommunications Standards Institute (ETSI) standards, namely:

• XML advanced electronic signature (XAdES), based on XML signatures;
• PDF advanced electronic signature (PAdES), based on PDF signatures;
• CMS advanced electronic signature (CAdES), based on Cryptographic Message Syntax (CMS);
• Associated Signature Container (ASiC) based on ZIP format and supporting XAdES and CAdES signature formats.

Especially, following CID 2015/1506, these formats shall be recognised by European public sector bodies.

Advanced electronic signatures and advanced electronic seals being similar from the technical point of view, the standards for formats of advanced electronic signatures apply mutatis mutandis to formats for advanced electronic seals.

When signing/sealing a single document, the format of signature to choose typically depends on the format of the document to sign:

• XML documents are suggested to be signed/sealed using XAdES signature format (either with enveloped or enveloping packaging);
• PDF documents are suggested to be signed/sealed using PAdES signature format;
• Binary files are suggested to be signed/sealed with XAdES or CAdES signature formats (with enveloping packaging).

When signing/sealing multiple documents, it is suggested to use ASiC containers.

Above suggestions are intended for basic usage of the signature/seal of documents. Other formats of signatures might be more appropriate in other specific contexts.

An electronic time stamp is a data in electronic form which binds other data in electronic form to a particular time establishing evidence that the latter data existed at that time.

For example, a signatory can use an electronic time stamp to bind a signed document to a particular date and time and prove in the future that the signed document existed at this particular date and time.

As part of eIDAS, a time stamp can be qualified. Following stricter requirements laid down in eIDAS, a qualified electronic time stamp enjoys the presumption of the accuracy of the date and the time it indicates and the integrity of the data (e.g. signed document) to which the date and time are bound.

Across all EU Member States, the legal effects of electronic time stamps are laid down in Article 41 of eIDAS.

An electronic time stamp (qualified or not) shall not be denied legal effect and admissibility as evidence in legal proceedings solely on the grounds that it is in an electronic form or that it does not meet the requirements of the qualified electronic time stamp.

Regarding qualified electronic time stamps, they enjoy the presumption of the accuracy of the date and the time it indicates and the integrity of the data to which the date and time are bound, across all EU Member States.

Qualified time stamps are provided as part of a service, provided by qualified trust service providers (QTSP). QTSP, as an eIDAS legal obligation, are mandatorily listed in the corresponding national Trusted List.

Trusted Lists, and therefore the providers listed in it, can be browsed in a user-friendly way using the Trusted List Browser. The actual content of these Trusted Lists is managed and published by each Member State and ‘Trusted List Browser’ is “merely” browsing these Trusted Lists.

Using Trusted List Browser, go to “Search by Type of service” (top left of the screen):

1. Select “Qualified time stamp” and click “Next”.
2. Then, select any country you may found appropriate and click “Search”.
3. Finally, click on any QTSP you may found appropriate and, via the “Electronic address” multi-part field of the “Detailed information”, you will find a link to a website providing more information about this provider and the products it provides.

When a party needs to rely on signed electronic data (e.g. a signed document), it is very often important that it can verify:

-  The integrity of the signed data;

-  The authenticity of the signed data.

 The requirements for the validation of qualified electronic signatures are, in particular, described in Article 32 of the eIDAS Regulation. In this context,

-  Integrity means that no modification has been made to the signed data after it has been signed;

-  Authenticity means that the signature is supported by a qualified certificate identifying the signatory, and that only the signatory can produce the signature.

A summary and non-exhaustive overview of the steps involved in the validation process for qualified electronic signature would be:

• The verification of the integrity of the data;
• The verification of the validity of the certificate;
• The verification of the qualified status of the certificate and;
• The verification of the signature was created by a qualified electronic signature creation device.

Finally, as numerous steps are involved in this validation process, the answer to a validation request can take the form of a validation report that contains the set of answers to the various verifications and steps involved during the validation process.

Using DSS Demonstration WebApp

In order to easily validate on any format of document whether a signature/seal is qualified, you might be interested in the “Validate a signature” feature of DSS Demonstration WebApp. This demo is based on the open-source library Digital Signature Software (DSS). DSS supports the creation and verification of interoperable and secure electronic signatures/seals in line with the eIDAS Regulation. More information is available in the documentation.

Using Adobe Acrobat Reader (for signatures only)

When the signed document is a PDF, you can also use the “Adobe Acrobat Reader” software. If, via the Signature Panel, the software indicates “This is a Qualified Electronic Signature according to EU Regulation 910/2014”, you can assume the signature is qualified.

Via a qualified trust service

Some qualified trust service providers (QTSP) also offer “qualified validation service for qualified electronic signature/seal” services. When using this kind of service, users ensure the validation service follows requirements laid down in eIDAS and benefit therefore of higher legal certainty.

QTSP, as an eIDAS legal obligation, are mandatorily listed in the corresponding national Trusted List. Trusted Lists, and therefore the providers listed in it, can be browsed in a user-friendly way using the Trusted List Browser. The actual content of these Trusted Lists is managed and published by each Member State and ‘Trusted List Browser’ is “merely” browsing these Trusted Lists.

Using Trusted List Browser, go to “Search by Type of service” (top left of the screen):

1. Select “Qualified validation service for qualified electronic signature” or “Qualified validation service for qualified electronic seal” and click “Next”.
2. Then, select any country you may found appropriate and click “Search”.

Finally, click on any QTSP you may found appropriate and, via the “Electronic address” multi-part field of the “Detailed information”, you will find a link to a website 

As defined by RFC 5280, a Trust Anchor is the end point of a certificate validation process.

As part of the EU Trusted List, when validating a qualified certificate (i.e. QC for electronic signatures, QC for electronic seals, QC for website authentication), the Trust Anchor is the Service digital identity (Sdi) of a trust service entry (cf. ETSI TS 119 612 v2.1.1). It means that, when validating a certificate, there is no need to chain up to the Root CA of a qualified certificate but only to the related CA/QC issuer entry within the Trusted List.

In order to extract the certificate chain from a qualified certificate to its issuer, you may find interesting the “certificate validation” feature of DSS Demonstration WebApp. This demo is based on the open-source library Digital Signature Software (DSS). DSS supports the creation and verification of interoperable and secure electronic signatures in line with the eIDAS Regulation. More information is available in the documentation.

You will also find more document information about this certificate validation in the “Introduction to the Qualified electronic signature (QES) validation algorithm” webpage.

AdES is the acronym for either an advanced electronic signature or an advanced electronic seal. It is the second level of electronic signatures/seals defined in eIDAS.

More information → What are the levels (simple, advanced and qualified) of electronic signatures? + What are the levels (simple, advanced and qualified) of electronic seals?

QES is the acronym for either qualified electronic signature or qualified electronic seal. It is the third and most secure level of electronic signature/seal defined in eIDAS.

More information → What are the levels of electronic signatures? + Do I need a qualified electronic signature? + What are the levels (simple, advanced and qualified) of electronic seals? + Do I need a qualified electronic seal?

A trust service provider (TSP) is a natural or a legal person who provides one or more trust services (TS) either as a qualified or as a non-qualified trust service provider.

A qualified trust service provider (QTSP) is a TSP who provides one or more qualified trust services (QTS) and is granted the qualified status by the national supervisory body. The decision of the supervisory body to grant the qualified status is reflected in the corresponding national Trusted List. In this respect, QTSPs are mandatorily listed in the corresponding national Trusted List while TSP could be but are not mandatorily listed in these Trusted Lists.

Trusted Lists, and therefore the providers listed in it, can be browsed in a user-friendly way using the Trusted List Browser. The actual content of these Trusted Lists is managed and published by each Member State and ‘Trusted List Browser’ is “merely” browsing these Trusted Lists.

QC stands for a qualified certificate. As part of eIDAS, a qualified certificate can either be a:

• Qualified certificate for electronic signature
• Qualified certificate for electronic seal
• Qualified certificate for website authentication

More information → What is a certificate for electronic signatures? + What is a certificate for electronic seals?

QSCD stands for a qualified electronic signature/seal creation device.

More information → What is a qualified signature/seal creation device?

AdES/QC is an advanced electronic signature/seal (AdES) based on a qualified certificate.

More information → What are the levels of electronic signatures? + What is a certificate for electronic signatures? + What are the levels of electronic seals? + What is a certificate for electronic seals?

Trusted List Browser is a publicly available tool provided by the European Commission. It allows the user to browse through the information present in the Member States national Trusted Lists (TLs), as well as in the European Commission central list (named List of Trusted Lists (LOTL)). It provides an intuitive interface that is user-friendly and human-readable.

Trusted List Browser should be taken as a tool to search for Trust Service Providers and the services associated with them that are listed in a Member State national Trusted List. It is not intended to provide sufficient information to be used in a validation process.

The eIDAS Regulation introduces the concept of Trusted List (TL) in the following statement:

“Each Member State shall establish, maintain and publish trusted lists, including information related to the qualified trust service providers for which it is responsible, together with information related to the qualified trust services provided by them.” (eIDAS article 22.1).

It may therefore be understood that all qualified trust services (QTSP’s) and the qualified trust services (QTS) they provide are mandatorily listed in its national TL, and that this is the main goal the TL’s serve. Nevertheless, while not mandatory in eIDAS, Member States can also include in their TL’s information related to non-QTSP and non-QTS.

The information related to the trust services includes information about the status (e.g. granted, withdrawn) and the status history of the trust services in compliance with the applicable requirements and the relevant provisions of the eIDAS Regulation.

In addition to the legal definition provided by eIDAS, the Commission Implementing Decision (EU) 2015/1505 specifies the technical specifications and formats for Trusted List.

The eIDAS Regulation states that:

“The Commission shall make available to the public, through a secure channel, the information referred to in paragraph 3 [i.e. about Member States Trusted Lists] in electronically signed or sealed form suitable for automated processing.” (eIDAS article 22.4)

In practice, the European Commission publishes an XML document called the List of Trusted Lists (LOTL), which consists of a compiled list of links (pointers) towards all trusted lists from the Member States, together with the certificates used to sign these trusted lists.

The primary goals of the publication of the LOTL are to allow access to the trusted lists of all Member States in an easy way and to provide a way to trust and authenticate those lists.

More information on the LOTL can be found here.

Using the Trusted List Browser allows you to find any Trust Service Provider (TSP) listed in a Member State national Trusted List. This means that you should be able to find any Qualified Trust Service Providers (QTSP’s) and the qualified trust services it provides, as it is mandatory for them to be listed in an EU MS national TL. Any other TSP (i.e. non-qualified TSP) may or may not be found using Trusted List Browser, as they are not required to be listed in a national TL.

Please keep mind that finding a TSP using Trusted List Browser does not mean that it is a Qualified TSP. In order to verify that a TSP corresponds to your needs, you can refer to the tags associated to it.

The eIDAS Regulation aims to deliver a comprehensive cross-border and cross-sector framework for secure, trustworthy and easy-to-use electronic transactions. Qualified trust services are a mean to this end, as their legal significance is recognised at European level. They are subject to strict requirements that consist of:

a)     Issuing qualified certificates for:

1. 1. Electronic signature
   2. Electronic seal
   3. Website authentication

b)    Providing qualified validation of:

1. 1. Qualified electronic signature
   2. Qualified electronic seal

c)     Providing qualified preservation of;

1. 1. Qualified electronic signature
   2. Qualified electronic seal

d)    Issuing qualified time stamp

e)    Providing qualified electronic registered delivery.

The eIDAS Regulation defines a qualified trust service provider (QTSP) as “[…] a natural or a legal person who provides one or more qualified trust services […]”.

As opposed to non-qualified trust service providers, QTSP’s are thus granted the right to deliver one or more qualified trust services after undergoing a strict assessment process.

While it is mandatory for QTSP to be listed in an EU Member State Trusted List (TL), member states may decide to include non-qualified trust service providers in their TL.

Trusted List Browser allows the user to search for QTSP by the type of qualified trust services they provide, as well as easily identifying which trust services, qualified or not, are provided by a particular TSP listed on a national TL, using explicit tags.

A qualified trust service provider (QTSP) must provide at least one qualified trust service, but may also provide non-qualified trust services. That is the reason why some QTSP may be tagged with qualified and non-qualified trust services in the Trusted List Browser.

These two tags only concern qualified trust services. The right for a Qualified Trust Service Provider (QTSP) to provide a qualified trust service (QTS) is decided by the national Supervisory Body (SB). The decision of the SB to allow the QTSP to provide the QTS is reflected in the associated national Trusted List (TL). This is a field that Trusted List Browser visually represents as a tag under the QTS.

If the tag under the qualified trust service states “Granted”, this means that the QTSP has been granted by the SB the right to currently provide the QTS.

If the tag under the qualified trust service is “Withdrawn”, this means that the QTSP was, at one time, given the right to provide this qualified trust service, but this right has been currently withdrawn.

The history of this status can be found in Trusted List Browser under the banner “History”, accessible by clicking on a qualified trust service.

These two tags only concern non-qualified trust services and have to do with a refinement of their type:

-   The tag “Undefined” is associated with trust services whose type has been defined in the eIDAS Regulation, but for which there is a lack of additional information in the TL to further specify its use.

-   The tag “Non-Regulatory” on the other hand is associated with trust services whose type has not been defined in the eIDAS Regulation and are country-specific.

These two tags only concern non-qualified trust services and have to do with a refinement of their type:

-  The tag “Recognised at national level” means that the trust service to which it refers as well as the relevant TSP have been granted an “approved” status, as recognized at national level.

-  The tag “Deprecated at national level” means that the trust service to which it refers as well as the relevant TSP had their “approved” status withdrawn.

According to the eIDAS Regulation, only the Qualified Trust Service Providers (QTSP’s) have to be listed in a Trusted List:

“Each Member State shall establish, maintain and publish trusted lists, including information related to the qualified trust service providers for which it is responsible, together with information related to the qualified trust services provided by them.” (eIDAS article 22.1)

As such, each national Trusted List may or may not include non-qualified TSPs. It is up to the Member State’s Supervisory Body to decide which non-qualified TSP will be listed.

The absence of a particular TSP from the Trusted List Browser should not be interpreted as a TSP not being compliant with the eIDAS definition. It only means that it does not provide qualified trust services.

The Trusted List Browser API can be found here.

Before using the API, please be aware of the following facts:

• The main purpose of the Trusted List Browser and its API is to browse the content of Trusted Lists, not validating certificates nor signatures. The actual content of Trusted Lists is managed and published by each Member States;
• This API is available on a "best effort" basis. The API should usually be available, but it shall be noted that some downtime might occur;
• The signature on a Trusted List (TL) is validated when the TL is first loaded (i.e. when the TL is published) and every day at midnight (e.g. when a TL signing certificate expires, the validity status of the signature will only be updated at midnight).

A trusted list (TL) shown in a transparent hue means that Trusted List Browser was, for some reason, unable to download and validate the content of this TL. This could therefore mean that this TL is currently unavailable.

If you are looking for a qualified certificate for electronic signature, you might be interested in: How can I create an advanced or qualified electronic signature?

If you are looking for a qualified certificate for electronic seal, you might be interested in: How can I create an advanced or qualified electronic seal?

If you are looking for a qualified certificate for website authentication, a similar process to the two below entries applies. 

Trusted List Browser should be taken as a tool to search for trust service providers and the services associated with that are listed in a Member State national Trusted List. It is not intended to provide sufficient information to be used in a validation process.

Instead, you might be interested in the answer provided in: How do I validate an electronic signature/seal is qualified?

There are currently three non-EU countries appearing in Trusted List Browser, belonging to the European Economic Area (EEA).

The reason they appear here is because the EEA Joint Committee adopted the decision to insert eIDAS (i.e. Regulation No 910/2014) in the EEA Agreement Annex XI (EEA JCD No 22/2018). Consequently, the Commission is to be notified of the information referred in eIDAS Article 22.3, applied to the EEA Contracting Parties mutatis mutandis with respect to the EEA Agreement protocol:

“Member States shall notify to the Commission, without undue delay, information on the body responsible for establishing, maintaining and publishing national trusted lists, and details of where such lists are published, the certificates used to sign or seal the trusted lists and any changes thereto.” (eIDAS article 22.3)

Furthermore, eIDAS Article 22.4 applies as well, and the Commission uses the LOTL to make this information available. As Trusted List Browser is a tool made to browse through the Trusted Lists referenced in the LOTL, the presence of the non-EU EEA countries Trusted Lists location in the LOTL is shown in this tool.

Displayed under the banner “Currently active trust service providers” are all the Trust Services Providers (TSP) for which there is at least one listed trust service they provide that has as its status either “Granted” or “Recognised at national level”.

More information about these statuses can be found on the corresponding FAQ entry:

-  What are the tags “granted” and “withdrawn”?

-  What are the tags “Recognised at national level” and “Deprecated at national level”?

Displayed under the banner “Trusted service providers without currently active trust services” are all the Trust Service Providers for which the status of every trust services listed under them in the Trusted List is either “Withdrawn” or “Deprecated at national level”.

More information about these statuses can be found on the corresponding FAQ entry:

-   What are the tags “granted” and “withdrawn”?

-    What are the tags “Recognised at national level” and “Deprecated at national level”?

The banner “Trust service providers currently taken over” indicates that a service was formerly under the legal responsibility of a Trust Service Provider (TSP) and is now taken over by another TSP. This doesn’t mean that those trust services have ceased nor that they lost their qualified status : As long as their status is ‘granted’, they are still recognised as qualified.

Trusted List Browser allows users to:

a)     Search for a trust service:

• • By the type of service
  • By the name of the service
  • By a signed file

b)    Display the content of a Member State national Trusted List (TL)

c)     Display the content of the European Commission List of the Trusted Lists (LOTL)

It should be noted that Trusted List Browser is not intended to provide a way to acquire a product nor to subscribe to a trust service. It merely gives information to the user on whether or not a Trust Service and the associated Trust Service Provider (TSP) is listed in a national Trusted List. Subscribing to a Trust Service or acquiring a product should be done by directly contacting the TSPs.

Search for a trust service

-   Searching by the type of service allows the user to look for all the TSP’s listed in a Member State Trusted List that provide the trust service(s) he is interested in.

-   Searching by the name of a service allows the user to check if a particular trust service is listed in a Member State TL, in which case the service along with some information would be displayed.

-   Searching by a signed file (either a PDF, XML or a certificate) allows the user to check if the trust service that issued the certificate for the signature used, is listed in a Member State Trusted List, in which case the service along with some information would be displayed.

Also please keep in mind that this would by no means constitute a validation of an electronic signature.

Display the content of a national Trusted List

When displaying the content of a national TL, what you will observe that a TL is a list of TSP grouped in a maximum of three categories (“Currently active TSP”, “TSP currently taken over”, “TSP without currently active trust services”) and displayed this way:

Where “Trust Service Provider Name” is the name of the TSP, the tag(s) in yellow represent the qualified trust service(s) it provides, and the tag(s) in grey represent the non-qualified trust service(s) appearing in the TL that it provides. Hovering over a tag will produce a short text clarifying its name, whereas clicking on the name of the TSP will bring you to a new page further describing those services by listing them in one of the two following manners, depending on whether they are qualified or not:

• Qualified trust service:

Where “Qualified trust service A” is the type of the QTS, “QTS type” is the service type identifier of the QTS, and “QTS name under the QTSP” is the name of the QTS.

More information on the tags “granted” and “withdrawn” can be found in What are the tags “granted” and “withdrawn”?

• Non-qualified trust service:

Where “Non-Qualified trust service A” is the qualifier used in the TL to further describe the type of the TS, “TS type” is the type of the TS, and “TS name under the QTSP” is the name under which the TSP provides the service.

More information on the tags “Recognised at a national level” and “Deprecated at a national level” can be found in What are the tags “Recognised at a national level” and “Deprecated at a national level”?

Display the content of the LOTL:

By default, the Trusted List Browser home interface actually displays the countries that have the location to their national Trusted List referenced in the LOTL. Clicking on the icon “European Union” will then only provide you with the detailed information about the LOTL (e.g. scheme information, signature).

If a Qualified Trust Service Provider (QTSP) for qualified certificates provisions loses its qualified status, the qualified certificates already issued do not lose automatically their qualified status as well.

Nevertheless, the TSP that no longer exists as a QTSP cannot provide new qualified certificates. The qualified certificates already issued by such a QTSP might be used to create a qualified electronic signature/seal, unless they have unambiguously been revoked, either as direct implementation of the QTSP's termination plan or at the request of the supervisory body.

Trusted Lists provide such information on whether the TSP and an identified trust service it provides were qualified both at the time of issuing the certificate, as well as at the time at which it is believed a signature/seal was created, in the history of the given trust service.

It is important to differentiate between the validity of a certificate and its qualified status.

 When a certificate is delivered by a Trust Service Provider (TSP), it comes with a specified timeframe during which it can be considered valid. The TSP may furthermore decide to revoke the certificate during this timeframe for various reasons. Checking the validity of a certificate may thus be taken as equivalent to checking whether the certificate has expired or been revoked.

 The qualified status of a certificate, on the other hand, means that it has been issued by a qualified trust service provider with the statement ‘qualified’. As one of the aims of the eIDAS regulation is to achieve cross-border interoperability and recognition of qualified certificates, a qualified certificate delivered in any Member State will be recognised as such in every Member State.

Finally, please note that the certificate would also be recognised in all EEA Member States, as further detailed in Why are there non-EU countries listed by Trusted List Browser?

One of the goals of the ‘qualified’ status is to achieve cross-border interoperability and recognition of electronic products and trust services across all Member States. As such, a qualified product delivered by a qualified trust service under a Qualified Trust Service Provider (QTSP) based in any Member State will be considered as qualified in every Member States.

From a legal point of view, both qualified and non-qualified trust services benefit from a non-discrimination clause as evidence in courts. In other words, trust services cannot be discarded by the judge only on the grounds that they are in an electronic form.

However, because of the more stringent requirements applicable to Qualified Trust Service Providers, qualified trust services provide a stronger specific legal effect than non-qualified ones as well as a higher technical security. Qualified trust services, therefore, provide higher legal certainty and higher security of electronic transactions.

DSS (Digital Signature Services) is an open-source software library for digital signature creation, validation, and extension, designed to help digital solutions achieve compliance with the eIDAS Regulation.

 Among the features it offers are:

• A large panel of formats being supported for the signed documents (XML, PDF, ODT, TXT, ZIP, …);
• The three main formats for digital signature XAdES, CAdES, and PAdES, as well as their four levels of baseline signatures profile being supported in compliance with the ETSI standards;
  • Along with the packaging structures enveloping, enveloped, detached and internally-detached;
  • And the ASIC-S or ASIC-E containers;
• The management of authenticating and trusting the Trusted Lists;
• Building certificate chains up to a trust anchor;
• Handling revocation data from OCSP and CRL sources;
• ETSI compliant signature validation processes;
• Certificate validation, including the determination of the qualified status.

This list is not exhaustive and more information about DSS and the features it offers is available by following the links given in “ Which are the DSS useful links? "

The DSS useful links are:

• DSS maven repository:

<repository>
<id>cefdigital</id>
<name>cefdigital</name>
<url>https://ec.europa.eu/digital-building-blocks/artifact/content/repositories/esignaturedss/</url>
</repository>

• “Start using DSS” webpage: https://ec.europa.eu/digital-building-blocks/sites/x/84TXGw
• DSS JIRA: https://ec.europa.eu/digital-building-blocks/tracker/projects/DSS/issues/
• DSS GitHub: https://github.com/esig/
• DSS documentation: https://ec.europa.eu/digital-building-blocks/DSS/webapp-demo/doc/dss-documentation.html

 You might be also interested in the DSS demonstration WebApp, providing a concrete example of DSS usage: https://ec.europa.eu/digital-building-blocks/DSS/webapp-demo/.

 A bundle of the DSS demonstration WebApp bundle can be downloaded in the DSS webpage. 
More information about this WebApp is given in What is the DSS demonstration WebApp?

The DSS demonstration Web Application is an integration of the DSS framework providing a concrete example of DSS usage. It can be used to:

• Sign documents (a qualified signature can be created provided that the signing private key resides in a QSCD such as a smartcard and is supported by a qualified certificate for eSignature);
• Extend a signature;
• Validate a signature (this service can in no case be considered as qualified);
• Validate a certificate;
• Get information about the Trusted Lists (for a user-friendly view of the Trusted Lists, the Trusted List Browser is a more adequate tool).

This Web Application only provides an insight of what can be achieved by using DSS and cannot be taken as a faithful representation of all the possibilities the DSS framework offers.

In particular, this Web Application has been designed to fit in the context of the eIDAS Regulation, but DSS can equivalently be used to validate signatures and certificates in other trust schemes.

In order to sign a document with the WebApp demonstration, the first step is to access the adequate webpage named “Sign a document”.

The DSS WebApp demo uses NexU to access the signing keys needed to sign the document, and you will therefore need to install it. If NexU is not installed or not launched, you will see this notification:

For additional information about NexU and its installation, please refer to the entry “ What is NexU and how to install it? ”.

After launching NexU, you might need to refresh the page for the WebApp demo to detect it. If the WebApp has properly detected NexU, you should see the following notification:

Once NexU is launched, the following steps will allow you to sign a document:

• Select the document to be signed;
• Configure the right parameters:
  • Suggestions regarding the ‘Container’, ‘Signature format’, and ‘Packaging’ are given in the FAQ entry “When signing/sealing a document, which format of signature should I use?” . More information about the ‘Packaging’ is also available via “What is the packaging enveloped, detached, enveloping, and internally detached of a signature?”.
  • The ‘Level’, together with suggestions, is explained in the FAQ entry “What are the B, T, LT, and LTA level of an electronic signature?”
  • The ‘Digest algorithm’ is the cryptographic algorithm used when generating the value of the signature. The algorithms proposed by the demo are sorted from the weakest (SHA1 that is not recommended) to the strongest (SHA512).
  • The option ‘Allow expired certificate’ will allow you to create a signature whose supporting certificate has expired
  • The option ‘Add a content timestamp’ will add a non-qualified time stamp (when using the bundle, a fake time stamp is generated) on the content of the document before it is signed.
• Click on the ‘Submit’ button.

More detailed and technical information about choosing the appropriate options when creating a signature can be found in the technical report ETSI TR 119 100 section 8.

Alternatively, if the document to be signed is a PDF file, you can use the “Sign a PDF” webpage and simply drag and drop the document. No customization is needed in this case, and the result will be a signature with no container, PAdES signature format, enveloped packaging, -B level and SHA256 as digest algorithm.

In the DSS WebApp demonstration, extending a signature is used when a user wishes to augment the level of a signature. The goal of the augmentation is to extend the time-period during which the signature can successfully be validated. For instance, when the certificate supporting a XAdES-B-B signature is soon to expire (or the certificate is about to be revoked), one can augment the signature to a XAdES-B-T signature allowing the validation to survive the expiration of the certificate.

More information about the levels of an electronic signature can be found in the FAQ entry What are the B, T, LT, and LTA levels of an electronic signature?

In order to validate a signature/seal with the WebApp demonstration, the first step is to access the adequate webpage named “Validate a signature”.

Once on the webpage, the next steps are to:

• Select the signed file;
• If the signature is detached, select the detached signature with “Signed file” then select the documents to which this signature refers with “Original file(s)”.
• Optionally specify the validation level. Changing the default setting will only reduce the set of signatures the WebApp can validate considering that:
  • The validation process for Basic Signatures only consider B-level attributes and does a basic validation of timestamps;
  • The validation process for Signature with Long-Term Validation Data is a validation process for Basic Signature that also validate the revocation data;
  • The validation process for Signature with Archival Data (recommended) is built from the previous level by also allowing the validation of the signature in the past with all collected data.

For instance, selecting the validation process for basic signature when trying to validate a qualified XAdES-B-LTA signature for which the signing certificate has expired will result in the WebApp demo being unable to validate the signature, even though the signature should still be considered qualified and valid;

• Optionally chose to use a custom validation constrains file. The default validation constrains file is available in the GitHub and can be used to build custom files;
• Click on the ‘Submit’ button.

The simple validation report will then give you a quick overview of the validation results by providing:

• The qualification level of the signature taking the values
  • • ‘QESig’ for a qualified signature;
    • ‘QESeal’ for a qualified seal;
    • ‘AdESig-QC’ for an advanced signature based on a qualified certificate for electronic signatures. The signature is therefore not qualified;
    • ‘AdESeal-QC’ for an advanced seal based on a qualified certificate for electronic seals. The seal is therefore not qualified;
    • ‘N/A’ for a signature with no qualification.

An enumeration of all possible values can be found in the GitHub;

• The format and the level of the signature as specified in ETSI standards;
• An indication of whether and which problems were encountered during the validation process, according to the standards ETSI EN 319 102-1 and ETSI TS 119 172-4. Such problems could be:
  • • The integrity of the signed data has been compromised;
    • The assurance level of the cryptographic means used for the signature format is not deemed acceptable;
    • The certificate supporting the signature has expired or been revoked;
    • The certificate supporting the signature is not qualified for electronic signature (the signature may be valid but not qualified);
    • The signature has not been created by a Qualified Signature Creation Device (QSCD) (the signature may be valid but not qualified).
    • The signature format is not recognised by the WebApp demo (This does not automatically mean that the signature is not valid nor that is not qualified as the eIDAS Regulation does not impose any restriction on the format).
• The chain of trust of the signing certificate
• The time at which the signature claims to have been created
• The best time at which there exists proof of the existence of the signature: If there is no time stamp on the signature, the best time is the time at which the current validation is performed.

More information about the validation of an electronic signature is given in What is the validation of an electronic signature?  , and you might also be interested in How to understand the detailed validation report?

In order to validate a signature/seal with the WebApp demonstration, the first step is to select the adequate webpage named “Validate a certificate”.

Then, you need to select the certificate you wish to validate. The format of this certificate needs to be DER or Base64 encoded.

As some certificates do not contain information processable in an automated manner for retrieving the certificate of the issuing authority, you may manually specify the certificate chain leading to a trust anchor.

The simple validation report will give you a quick overview of the validation results by providing:

• The qualification level of the certificate at both the time it has been issued and the time of the validation, taking the values:
  • ‘QC for eSig with QSCD’ and ‘QC for eSeal with QSCD’ for a qualified certificate for electronic signature/seal supporting a private signing key residing in a QSCD;
  • ‘QC for eSig’, ‘QC for eSeal’, and ‘QC for WSA’ for a qualified certificate for electronic signature/seal/website authentication. A signature based on such a certificate would not be qualified;
  • ‘cert for eSig’, ‘cert for eSeal’, and ‘cert for WSA’ for a non-qualified certificate for electronic signature/seal/website authentication delivered by a trust service provider listed in an EU Member State Trusted List;
  • ‘N/A’ for a certificate with no qualification.

An enumeration of all possible values can be found in the GitHub.

• The name of the entity to which it has been issued;
• The name of the organization of the entity to which it has been issued;
• The locality, state and country of the entity to which it has been issued;
• The information about the usages for which the key has been certified;
• The validity period of the certificate
• The information about whether it has been revoked;
• The resources needed for its validation that are provided in the certificate (e.g. KeyUsage, AuthorityInfoAccess).

More information about the validation process can be found in the DSS documentation: https://ec.europa.eu/digital-building-blocks/DSS/webapp-demo/doc/dss-documentation.html#_certificate_validation.

NexU is an open-source signature tool that enables web applications to interact with local smartcard readers. It also allows the use of signing keys locally stored on a computer.

The latest release of the compiled bundle for Windows OS can be downloaded on the associated GitHub.

Once downloaded, you need to extract it:

You can then use NexU by running the NexU-Startup file:

Four levels of baseline signatures have been defined by ETSI standards for the CAdES, XAdES, and PAdES formats. They are the:

-  B-B level, which is the level of a Basic Signature meaning that it is a signature that can be validated as long as the signing certificate is valid (not revoked or expired).

-  B-T level, which is the level of a Signature with Time , meaning that it is a signature that proves that the signature existed at a given point in time. It is built from the previous level by adding a time stamp token on the signature as unsigned properties.

-  B-LT level, which is the level of a Signature with Long-Term Validation Material , meaning that it is a signature that provides the long-term availability of the validation material by incorporating all the material or references to material required for validating the signature. It is built from the previous level by adding this material, that is: the complete certificate and revocation data on the signature and the time stamp(s) as unsigned properties.

-  B-LTA level, which is the level of a Signature providing Long Term Availability and Integrity of Validation Material . It is built from the previous level by adding a time stamp token on the validation material as unsigned properties, thereby establishing evidence that the validation data existed at the indicated time. This level targets the long-term availability and integrity of validation material, and if appropriate measures are put in place (e.g. periodical timestamping), a signature at this level could still be validated long after the cryptographic algorithms used for its creation are no longer considered secure enough, or more simply after the expiration of the validation data.

The appropriate level to use when creating an electronic signature depends on the intended usage of the signature:

-  If the signature only needs to be validated in the short term (e.g. when signing invoices), a basic signature at the B-B level would usually be enough;

-  On the other hand, if there is a need for a signature (and its eventual qualification level) to be able to be validated in the long term, a preservation process of periodical B-LTA level augmentation should be considered.  Such a preservation process is however usually much heavier to put in place than the simple generation of an electronic signature and its application should be duly justified.

More information about these levels can be found in the standards ETSI EN 319 102-1 (section 4.3), 122-1, 132-1, and 142-1 (section 6).

A signature can be enveloped or detached, whether it is included as an element of the file containing the signed data or a separate signature file is created, that refers to the data upon which it bears:

 It can also be enveloping when the signed data are included as a sub-element of the signature, and in special cases where the signature is detached but both the signed data and the signature data are included in another file, it is called internally detached. (Internally detached signatures are very rarely used).

Not all signature formats support these different locations and positionings of a signature and a simplified overview can be given by the following:

• Enveloped signatures can be created using XAdES or PAdES formats
• Detached signatures can be created using XAdES or CAdES formats
• Enveloping signatures can be created using XAdES or CAdES formats
• Internally detached signatures can only be created using XAdES format.

Understanding this report requires a good knowledge of the validation processes and the standards involved.

The detailed report has a structure that is composed of three types of blocks:  The signature block, the basic building blocks, and the Trusted Lists blocks.

Under the eIDAS Regulation, a new dimension has been added to the classical validation of an electronic signature: the determination of its qualification level.

That is why the signature block is composed of two types of sub-blocks:

• The first sub-blocks that summarize the result of “classic eSignature validation processes” (cf. ETSI EN 319 102-1). The detailed information about those processes is found in the building blocks.
• The last sub-block with detailed information about the qualification level of the signature (cf. ETSI TS 119 172-4).

Each building block addresses a specific validation process, and contains extensive information about it, such as cryptographic and format conformance checks, while the Trusted Lists blocks provide the information used for accepting or rejecting a Trusted List.

More information about the validation processes can be found in the DSS documentation: https://ec.europa.eu/digital-building-blocks/DSS/webapp-demo/doc/dss-documentation.html#_the_signature_validation.