CEN/TR 419040:2018

SLOVENSKI STANDARD
01-september-2018
Racionalizirana struktura za standardiziran elektronski podpis - Smernice za
državljane
Rationalized structure for electronic signature standardization - Guidelines for citizens
Cadre pour la normalisation de la signature électronique - Lignes directrices pour les
citoyens
Ta slovenski standard je istoveten z: CEN/TR 419040:2018
ICS:
35.040.01 Kodiranje informacij na Information coding in general
splošno
2003-01.Slovenski inštitut za standardizacijo. Razmnoževanje celote ali delov tega standarda ni dovoljeno.

CEN/TR 419040
TECHNICAL REPORT
RAPPORT TECHNIQUE
May 2018
TECHNISCHER BERICHT
ICS 35.030
English Version
Rationalized structure for electronic signature
standardization - Guidelines for citizens
Cadre pour la normalisation de la signature
électronique - Lignes directrices pour les citoyens

This Technical Report was approved by CEN on 9 March 2018. It has been drawn up by the Technical Committee CEN/TC 224.

CEN members are the national standards bodies of Austria, Belgium, Bulgaria, Croatia, Cyprus, Czech Republic, Denmark, Estonia,
Finland, Former Yugoslav Republic of Macedonia, France, Germany, Greece, Hungary, Iceland, Ireland, Italy, Latvia, Lithuania,
Luxembourg, Malta, Netherlands, Norway, Poland, Portugal, Romania, Serbia, Slovakia, Slovenia, Spain, Sweden, Switzerland,
Turkey and United Kingdom.
EUROPEAN COMMITTEE FOR STANDARDIZATION
COMITÉ EUROPÉEN DE NORMALISATION

EUROPÄISCHES KOMITEE FÜR NORMUNG

CEN-CENELEC Management Centre: Rue de la Science 23, B-1040 Brussels
© 2018 CEN All rights of exploitation in any form and by any means reserved Ref. No. CEN/TR 419040:2018 E
worldwide for CEN national Members.

Contents Page
European foreword . 4
Introduction . 5
1 Scope . 6
2 Normative references . 6
3 Terms and definitions . 6
4 Abbreviations . 8
5 What are (legally valid) electronic signatures? . 9
5.1 Electronic signatures defined by the EU Regulation N° 910/2014 . 9
5.2 The underlying technology – Public key cryptography and digital signatures . 10
5.2.1 Introduction . 10
5.2.2 How it works . 10
5.2.3 Ensuring trust . 12
5.2.4 Functionalities offered by PKI based technologies: data integrity and authentication
of origin . 13
5.3 Where technical tools meet legal requirements . 13
5.3.1 Introduction . 13
5.3.2 Mapping the legal and the technical concepts . 14
5.3.3 How digital signatures cover the legal requirements for AdESig . 16
5.3.4 How digital signatures cover the legal requirements for QES . 18
5.4 Other use-cases for digital signatures . 19
6 Digital signatures– how does it work in real life applications? . 19
6.1 The signature process . 19
6.2 Creation . 19
6.3 Validation . 21
6.4 Augmentation . 23
7 Digital signatures ancillary services and tools for use in practice . 23
7.1 Introduction . 23
7.2 Identifying the required level of signature . 24
7.2.1 General . 24
7.2.2 Use-cases for QES. 24
7.2.3 Use-cases for non QES . 24
7.3 Identifying required tools and services . 25
7.3.1 Creation . 25
7.3.2 Augmentation – when the signature needs to be preserved . 26
7.3.3 Validation . 26
7.3.4 Preservation. 26
8 In case of dispute: evidence and proofs . 27
8.1 General . 27
8.2 Evidence present in the signed data . 27
8.3 Evidence generally present in the certificate . 28
8.4 Evidence present in the CA’s documentation . 29
8.5 Evidence regarding Certificate Status . 29
8.6 Evidence present in the Signature Policy . 29
8.7 Evidence at the Registration Authority . 30
8.8 Evidence not available through the signed message . 31
9 What about the (international) recognition of electronic signatures? . 31
9.1 Within Europe . 31
9.2 Outside Europe . 31
Bibliography . 33
European foreword
This document (CEN/TR 419040:2018) has been prepared by Technical Committee CEN/TC 224
“Personal identification and related personal devices with secure element, systems, operations and
privacy in a multi sectorial environment”, the secretariat of which is held by AFNOR.
Attention is drawn to the possibility that some of the elements of this document may be the subject of
patent rights. CEN shall not be held responsible for identifying any or all such patent rights.
Introduction
Today, it is possible to electronically sign data to achieve the same effects as when using a hand-written
signature. Such electronic signatures benefit from full legal recognition due to the EU Regulation
N° 910/2014 of the European Parliament and of the Council on electronic identification and trust services
for electronic transactions in the internal market [1] (hereafter referred to as EU Regulation N°
910/2014) which addresses various services that can be used to support different types of electronic
transactions and electronic signature in particular.
The use of secure electronic signatures should help the development of online businesses and services in
Europe. The European Commission standards initiative aims at answering immediate market needs by:
— securing online transactions and services in Europe in many sectors: e-business, e-administration, e-
banking, online games, e-services, online contract, etc.;
— contributing to a single digital market;
— creating the conditions for achieving the interoperability of e-signatures at a European level.
Besides the legal framework, the technical framework at the present time is very mature. Citizens
routinely sign data electronically by using cryptographic mechanisms such as, e.g. when they use a credit
card or debit card to make a payment. Electronic signatures implemented by such cryptographic
mechanisms are called “digital signatures”. Appropriate technical methods for digital signature creation,
validation and preservation, as well as ancillary tools and services provided by trust service providers
(TSPs), are specified in a series of documents developed along with the present document.
The present document is part of a rationalized framework of standards (see ETSI TR 119 000 [6])
realized under the Standardization Mandate 460 issued by the European Commission to CEN, CENELEC
and ETSI for updating the existing standardization deliverables.
In this framework, CEN is in charge of issuing Guidelines for electronic signatures implementation. These
guidelines are provided through two documents:
— CEN/TR 419030, “Rationalized structure for electronic signature standardization - Best practices for
SMEs”, aligned with standards developed under the Rationalised Framework as described by
ETSI SR 001 604, and
— CEN/TR 419040, “Rationalized structure for electronic signature standardization - Guidelines for
citizens”, explaining the concept and use of electronic signatures.
These two documents differ slightly from the other documents in the Technical Framework since they go
beyond the technical concept of “digital signature” and deal also with the legal concepts of electronic
signatures and electronic seals. The concept of electronic seal specified in the Regulation, which is
technically close to the electronic signature, is developed in CEN/TR 419030 and not in the present
document as it relates to legal person and not to natural persons as are the citizens The present document
concerning the citizens is focusing on electronic signature that are created by natural persons.
1 Scope
This Technical Report aims to help citizens to understand the relevance of using electronic signature
within their day-to-day lives. It also explains the legal and the technical backgrounds of electronic
signatures.
This document gives guidance on the use of electronic signatures and addresses typical practical
questions the citizen may have on how to proceed to electronically sign, where to find the suitable
applications and material.
2 Normative references
There are no normative references in this document.
3 Terms and definitions
For the purposes of this document, the following terms and definitions apply.
ISO and IEC maintain terminological databases for use in standardization at the following addresses:
— IEC Electropedia: available at http://www.electropedia.org/
— ISO Online browsing platform: available at http://www.iso.org/obp
3.1
advanced electronic signature
electronic signature which meets the requirements set out in Article 26 of Regulation (EU)
N° 910/2014 [1]
Note 1 to entry: Article 26: An advanced electronic signature shall meet the following requirements:
(a) it is uniquely linked to the signatory;
(b) it is capable of identifying the signatory;
(c) it is created using electronic signature creation data that the signatory can, with a high level of confidence, use
under his/her sole control; and
(d) it is linked to the data signed therewith in such a way that any subsequent change in the data are detectable.
[SOURCE: Regulation (EU) N° 910/2014 [1], Article 3 (11)]
3.2
electronic signature (from the regulation)
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
[SOURCE: Regulation (EU) N° 910/2014 [1], Article 3 (10)]
3.3
digital signature
data appended to, or a cryptographic transformation (see cryptography) 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
[SOURCE: ISO/IEC 7498 / ITU-T/Recommendation X.800]
3.4
trust service provider
natural or legal person who provides one or more trust services either as a qualified or as a non-qualified
trust service provider
[SOURCE: Regulation (EU) N° 910/2014 [1], Article 3 (19)]
3.5
trust service
electronic service normally provided for remuneration which consists of:
(a) the creation, verification, and validation of electronic signatures, electronic seals or electronic time
stamps, electronic registered delivery services and certificates related to those services, or
(b) the creation, verification and validation of certificates for website authentication, or
(c) the preservation of electronic signatures, seals or certificates related to those services
[SOURCE: Regulation (EU) N° 910/2014 [1], Article 3 (16)]
Note 1 to entry: The concept of electronic seal specified in the Regulation is not developed in the present
document as it relates to legal person and not to natural person as are the citizens. More details can be found in the
companion document CEN/TR 419030.
3.6
qualified trust service
trust service that meets the applicable requirements laid down in this Regulation
[SOURCE: Regulation (EU) N° 910/2014 [1], Article 3 (17)]
3.7
qualified trust service provider
trust service provider who provides one or more qualified trust services and is granted the qualified
status by the supervisory body
[SOURCE: Regulation (EU) N° 910/2014 [1], Article 3 (20)]
3.8
signature creation device
configured software or hardware used to create an electronic signature
[SOURCE: Regulation (EU) N° 910/2014 [1], Article 3 (22)]
3.9
qualified electronic signature
advanced electronic signature that is created by a qualified electronic signature creation device, and
which is based on a qualified certificate for electronic signatures
[SOURCE: Regulation (EU) N° 910/2014 [1], Article 3 (12)]
3.10
certificate for electronic signature
electronic attestation which links electronic signature validation data to a natural person and confirms
at least the name or the pseudonym of that person
[SOURCE: Regulation (EU) N° 910/2014 [1], Article 3 (14)]
3.11
signatory
natural person who creates an electronic signature
[SOURCE: Regulation (EU) N° 910/2014 [1] Article 3 (9)]
3.12
certificate
public key of a user, together with some other information, rendered un-forgeable by encipherment with
the private key of the certification authority which issued it
Note 1 to entry: The term certificate is used for public key certificate within the present document.
[SOURCE: ISO/IEC 9594-8 / ITU-T Recommendation X.509]
3.13
entity authentication
means the corroboration of the claimed identity of an entity and a set of its observed attributes
[SOURCE: Modinis Study on Identity Management in eGovernment – Common terminological framework
for interoperable electronic identity management, v2.01, November 23, 2005.]
3.14
data authentication
means the corroboration that the origin and the integrity of data are as claimed
[SOURCE: Modinis Study on Identity Management in eGovernment – Common terminological framework
for interoperable electronic identity management, v2.01, November 23, 2005.]
3.15
data authentication data
means data in electronic form which are attached to or logically associated with other electronic data and
which corroborates the identity of the entity at the origin of the associated data and the integrity of the
associated data.
[SOURCE: Feasibility study on an electronic identification, authentication and signature policy
(IAS) carried out for the European Commission by DLA Piper, SEALED, time.lex, Price Waterhouse
Coopers and Studio Genghini & Associati, 2013]
4 Abbreviations
For the purposes of this document, the following abbreviations apply.
AdESig_QC An advanced electronic signature / seal as defined in the Regulation
supported by a QC
AdESig advanced electronic signature as defined in the Regulation [1]
CA Certification Authority
CRL Certificate Revocation List
CSP Certification Service Provider
DA Driving Application
EC European Commission
EU European Union
ISO International Organization for Standardization
LoA Level of Assurance
OCSP Online Certificate Status Protocol
PDF Portable Document Format
PIN Personal Identification Number
PK Public Key
PKI Public Key Infrastructure
QC Qualified Certificate
QES qualified electronic signature
QSCD Qualified Signature Creation Device
QTSP Qualified Trust Service(s) Provider
RA Registration Authority
SCA Signature Creation Application
SCD Signature Creation data
SCDev Signature Creation Device
SVA Signature Validation Application
TSA Time-Stamping Authority
TSP Trust Service(s) Provider
5 What are (legally valid) electronic signatures?
5.1 Electronic signatures defined by the EU Regulation N° 910/2014
The Regulation (EU) N° 910/2014 defines electronic signature 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”. Electronic signatures are created by an electronic ‘signature creation device’, which is “a
configured software or hardware used to create an electronic signature and by means of an ‘electronic
signature creation data’ (i.e. “a unique data which is used by the signatory to create an electronic
signature”)”.
Electronic signatures shall not be denied legal effect and admissibility as evidence in legal proceedings.
Within the electronic signature family, the Regulation (EU) N° 910/2014 defines subsets of electronic
signature that provide a greater legal predictability up to a level that benefit from the legal equivalence
to handwritten signatures:
— the advanced electronic signature (AdESig) – which requires some security features such as
defined in Clause 3;
— the qualified electronic signature (QES) – which is an advanced electronic signature which
provides additional level of assurance on the identity of the signatory and an enhanced protection
and level of assurance on the signature creation. A special device is required for the creation of QES
(a Qualified Signature Creation Device, QSCD). A QES shall have the equivalent legal effect of a
handwritten signature and shall be recognized as a qualified electronic signature in all
European Member States. Besides the fact that a QES is equivalent to a handwritten signature, it
also benefits from legal protection with regard to acceptation; anyone who receives such a signature
has to accept it. Also, in the case of litigation with the service providers supporting the QES ancillary
services, it is not up to the person claiming the damage to support the burden of proof, but well up to
the Qualified Service Provider to prove that it has not acted negligently.
NOTE The Regulation also defines an intermediary level, the AdESig_QC, that has the same legal value as the
AdESig but brings more assurance on the identity of the signatory. This will be discussed later on in the present
document.
5.2 The underlying technology – Public key cryptography and digital signatures
5.2.1 Introduction
Asymmetric cryptography is a technology that enables the creation of digital signatures (the technical
concept defined by ISO, see Clause 3).
As demonstrated in the next subclause, digital signature is a technique that allows the legal requirements
for the 3 levels of electronic signature defined in the Regulation (EU) N° 910/2014 (i.e. simple, advanced
and qualified signatures) to be met. In the current state of the art, QES are only possible with such
technologies.
NOTE 1 In the present document, the terms “electronic signature” refer to the legal concept while the terms
“digital signature” refer to the PKI based underlying technology.
NOTE 2 The terms signer or signatory can be used to refer to the person that creates a digital signature. The
European Regulation uses the term signatory. It is limited to natural person creating electronic signatures (see
below). The present document uses the term signatory to refer to electronic signatures such as addressed by the
European regulation, and the more generic term signer for any context.
5.2.2 How it works
Each signer owns a key pair made of a private and a public key (the asymmetric cryptography technology
is also often referred to as “Public Key cryptography”):
— The private key is a secret code used by a mathematical function in order to render data unintelligible
(i.e. encrypt data).
— The public key is a public code used by the reverse mathematical function in order to retrieve the
initial data from the encrypted data.
If we schematize the private key by ‘1100101’ and the encryption function by , and the
public key by ‘0100001’ and the decryption function by we can illustrate the digital
signature process as follows (the actual protocol is slightly more complicated, the schematization
provided below is for the sake of illustrating the principles and introducing the components that support
the creation of digital signatures):
1. The signature of a text ‘text’ is performed by the signer by means of his/her private key. The result is
the text in the unintelligible in the red box.

Figure 1 — Creating a signature
2. For the verification of the signature, the verifier receives both the signed text (in the green box) and
the signature (in the red box). The verifier will use the signer public key to decrypt the signature. The
result is the text in the blue box. If this text is the same as the text received (in the green box), it means
that the encryption was performed by the person that owns the private key matching the public key used
for the verification.
Figure 2 — Verifying a signature
If only the person that owns the private key matching the public key is able to create the signature, the
signer cannot deny to be at the origin of such signature. This non-repudiation feature is the foundation
of any signature (electronic or paper based).
Of course, there are some technical tricks to ensure that only the person that owns the private key
matching the public key is able to create the signature (and not a third person that would be able to
imitate the signers signature):
— It is easy to create the key pair, but it is likely impossible to discover the private key from the
knowledge of the public key. Any stakeholder in possession of a public key is able to verify that signed
data has been made by the corresponding private key, without being able to play the role of the signer
since (s)he cannot guess the private key. The size of the key is an important parameter for the
security of the algorithm.
— A different unique key pair is allocated to each signer.
— The signer shall protect the private key (in the same way as (s)he would not explain to a third party
how to imitate his/her signature).
So, when using asymmetric cryptography, two major properties are not provided a priori by the digital
signature mechanism:
— knowing who is the owner of the public key with a good level of assurance;
— be assured that the private key was under the (sole) control of the signer at the time of the signature.
A “trust” dimension needs to be provided on top of the technical dimension.
5.2.3 Ensuring trust
The technical foundations presented above, alone, are not sufficient to ensure full confidence in the
system. Indeed, trust in signatures relies in the guarantee that a certain Public Key (e.g. ‘0100001’)
belongs to a particular signer. For this purpose, an entity, trusted by the community, called a
Certification Authority (also called a Certification Service Provider, CSP), certifies the link {public key –
signer} in a Public Key Certificate.
The certificate is a signed statement by the CA; the CA’s signature is itself trusted because this is a trusted
third party (trusted by the user’s community) and the CA’s key is published in a media trusted by the
community (e.g. the official journal). The procedures, techniques and mechanisms put in place to realize
such certification services is commonly called Public Key Infrastructure (or PKI).
The CA is also responsible to provide certificate validity status services. In the event that a signer loose
the control on his/her private key (e.g. because (s)he lost his/her signature creation device), it is
fundamental that the community does not trust the related certificate anymore. It is also crucial that a
trusted time can be associated to the event in order to prevent repudiation by the signer (a fraudulent
signer may sign a data, benefit from the signed transaction, and repudiate it when a payment is requested,
e.g., by claiming (s)he was not controlling his/her private key at the moment of the transaction). Different
techniques exist to advertise the community on the validity status of the certificate. The most spread
method is the revocation of the certificate. As soon as the CA knows with a certain degree of certitude
that a certificate cannot be trusted anymore, it inserts the certificate serial number in a list (called a
Certificate Revocation List), together with the revocation time and it publishes the list. The CA may also
answer directly to relying parties that enquire about a certificate by means of an on-line certificate status
service (OCSP).
The trust in certificate relies in the quality of the CA and its certification / validity status information
services; the CA must follow suitable policies: a sound cryptography, secure CA premises and devices,
providing signature creation device (to protect the private key) to signatories of a good quality, trusted
personnel, possibility to revoke and publish revocation status to verifying parties (i.e. validation
services), insurances, etc.
Finally, the trust in CA policies relies in the level of assurance that the CA indeed correctly implements
these policies. For this purpose, the CA can be audited. In the next section, one will see that each of the
concepts highlighted here can be mapped to elements of the Regulation (EU) N° 910/2014 in such a way
that the resulting signature is an electronic signature such as defined in this Regulation.
As highlighted later on in the present document, even if the citizen can assess the quality of a CA on its
own, this is quite often done on his/her behalf by the signature creation and validation providers. Many
of-the-shelf applications have a list of trusted CAs and the citizens are not obliged to look at the (sometime
complex) documentation of a CA to decide whether it is trusted or not.
Some CA (the qualified CAs, see below) are officially listed under the European Regulation and it is the
European Member States that check their quality so that the citizen can trust them.
5.2.4 Functionalities offered by PKI based technologies: data integrity and authentication of
origin
One of the characteristics of digital signatures is that if the text claimed to be signed has been modified,
the verification of the signature will fail (the text discovered in the blue box above will not be the same
as the claimed signed text in the green box). As a consequence, a successful signature verification also
ensures data integrity.
Because the verification of a signature with a certain public key means that the signature was computed
with the corresponding private key, only the signer in possession of the private key (and the related
certificate) can be at the origin of the signature as far as the certificate is not revoked. As a consequence,
verifying a signature also means authenticating the person that was at its origin. Moreover, it is difficult
for the signer to deny having performed such a signature (impersonating the signer would mean that the
cryptographic system has been hacked); this characteristic is called the non-repudiation.
5.3 Where technical tools meet legal requirements
5.3.1 Introduction
The present clause will show how digital signatures can answer the requirements of the Regulation (EU)
N° 910/2014 for the different levels of signatures it defines.
The picture below shows that both the electronic signatures and the digital signatures are a subset of the
electronic data in general. Such as described above, AdESig is a subset of the electronic signature family
and QES is a subset of AdESig. As explained below, PKI based signatures is a technique that can answer
the requirements of the Regulation (EU) N° 910/2014 for the different levels of signatures it defines.
However, electronic signatures built on techniques other than PKI based signatures are also possible; this
is out of scope of the present document which focuses on PKI based digital signatures which benefit from
a sound standardization framework, in particular from CEN and ETSI.
The picture also shows that PKI based signatures is a technique that goes beyond the construction of
electronic signatures such as defined by the Regulation. Indeed, as explained later on, PKI based
signatures can also support authentication processes (see Clause 3).
Figure 3 — Framework of the electronic signatures within the electronic data
5.3.2 Mapping the legal and the technical concepts
With the digital signature technique, the signature creation data as defined in the EU Regulation
N° 910/2014, is the cryptographic private key (and the signatory’s public key is the electronic signature
validation data as defined in the EU Regulation N° 910/2014).
The electronic signature creation device (SCDev) implements the asymmetric cryptography technique.
In other words, it is a component (e.g. a smart-card similar to a bank card, or a device like a smart phone),
that holds and protects the signature creation data (or private key) and that is able to activate it on
demand of the signatory in order to compute a signature on data to be signed.
Electronic signatures like any electronic data may take different (signature) formats. The electronic
signature format is generally bound to the signed data format (e.g. XML signature for XML content to be
signed, or PDF signature for PDF content to be signed). Within a certain format, an electronic signature
may take different forms, depending on the elements and information that are present within, or
presented with, the signature.
The CA is a Trust service(s) providers (TSP) such as defined by the EU Regulation N° 910/2014. More
generally, beyond their role in certifying the link between a key pair and a signatory, such trusted third
parties may also be implied in either the creation, verification, or the validation of electronic signatures.
The TSP may provide proofs of existence of signature by means of time stamping, e.g. or may perform the
validation of a certain signature on behalf of a relying party.
For all the trust services, and thus in particular for the creation, verification, and validation of electronic
signatures, the Regulation (EU) N° 910/2014 supports two levels of legal value, exactly in the same vein
as the distinction between AdESig and QES:
1. A level with non-deniable legal effect but whose quality is to be proven by any stakeholder in a
transaction that is asked to do so.
2. A qualified level that benefit from an automatic legal recognition, defined service per service.
More generally, as stated in the Regulation (EU) N° 910/2014 “the notions of qualified trust services and
qualified trust service provider should be introduced with a view to indicating requirements and obligations
that ensure high-level security of whatever qualified trust services and products are used or provided.” As a
pledge for this high level security, qualified trust service(s) providers are supervised by the Member State
within which they operate.
Without necessarily knowing the mechanisms underlying the supervision processes, citizen may easily
check the qualified status of any provider in official and publicly available lists; the member states’
trusted list of qualified trust provider and qualified services their offer (member states’ lists are
themselves officially referred by the European Commission List of the Lists). It is worth to mention that
such qualified trust providers are allowed to use a label to advertise users on the fact that the service(s)
they offer is qualified: it is called the EU trust mark.

Figure 4 — EU trust mark
When the EU trust mark appears on a TSP website e.g., it means that the service offered by the TSP is
qualified. This is a very useful tool for the citizen.
Also, the burden of proving intention or negligence of a non-qualified trust service provider lies with the
natural or legal person claiming a potential damage due to a failure to comply with the EU Regulation N°
910/2014, whilst in the case of a qualified trust service provider, it is up to the provider to prove that
such damage occurred without intention or negligence, making it more “secure” for a citizen to work with
qualified trust providers for their sensitive transactions.
5.3.3 How digital signatures cover the legal requirements for AdESig
An AdESig, according to the regulation specification, is an electronic signature which meets the following
a) to d) requirements:
a) it is uniquely linked to the signatory;
With digital signatures, the link with the signatory is established by means of the certificate. It is one
of the duties of the CA to make sure each signatory has its own key material, which is unique.
b) it is capable of identifying the signatory;
The certificate may establish more or less completely the identity of the signatory (this is ensured by
requirements on the signatory’s certificate profile).
c) it is created using electronic signature creation data that the signatory can, with a high level of
confidence, use under his/her sole control;
Two digital signatures related tools ensure this property:
1) The signature creation device protection design; the access control to the SCDev containing
the private key must be secure. The access control has to be implemented in such a way that the
signatory is able, using a certain procedure, to be sure that his/her private key and/or SCDev can
be utilized only by himself/herself in order to sign data. This means that the signatory may have
to be somehow “active” in protecting his/her private key, and the SCDev must protect the access
and use to the private key (e.g. by means of a PIN code); and
2) Revocation of the signature tools; e.g. it must be possible for the signatory who has a doubt on
the sole control (e.g. if the device has been stolen) to revoke the certificate (in other word to
“blacklist” his/her certificate). It is also necessary to advertise relying parties of such revocation;
the notification of revocation of the signatory certificate by the CA is generally published online.
As mentioned above, the online publication can take the form of lists called Certificates
Revocation Lists (CRL), or of a server answering to questions on the status of a certain certificate
(e.g. the OCSP, Online Certificate Status Protocol standardized by the RFC 6960).
d) it is linked to the data signed therewith in such a way that any subsequent change in the data are
detectable;
One of the characteristics of digital signatures is that they ensure the integrity of the signed data. For
this purpose:
1) The signing algorithm has to be adequate to the security required (an algorithm with sufficient
strength, e.g. a mathematical function that ensures as far as possible that one cannot discover
the private key from the public key).
2) The key data has to be adequate to the security required. Especially the key pair must be secure
against attacks (e.g. brute force attacks that consist of trying every private key until one finds a
match). For this purpose, key length must be sufficiently high.
In addition, the detection of “any subsequent change in the data”, must be possible at any time after the
signature creation, even after several years if needed. This is only possible by the use of (trusted)
(long-term) preservation features; indeed depending on the form of the AdESig, more or less rapidly,
the technically validation of the AdESig is not possible anymore. Some basic forms of AdESig even face
this risk immediately after their creation (indeed if a certificate is revoked just after the creation of a
signature and if there is no clue about the time of the signature, for a relying party that tries to validate
the signature after the revocation time, it is impossible to assess whether the signature was actually
created before or after the revocation)!
The trust in PKI based digital signature heavily relies on the possibility for the signatory to revoke his/her
signature tools (see above) but also on the validity period of a certificate (period within which the CA
maintains the revocation services and/or guarantees the cryptographic strength of the signatory’s
material).
It is crucial when validating a signature that the relying party can assess whether the signature has
been created when the certificate was valid. For this reason, the relying party needs to trust an
indication about the time of creation of the signature.
Finally, beyond the validity period of a certificate, digital signatures face a problem of aging. This is
due to the obsolescence of the cryptographic material. Indeed a certain cryptographic algorithm, or a
certain key length, perfectly valid today (e.g. resistant to a hacker that would try to retrieve the private
key from the public key) will not be valid anymore in the future because the computational power will
have increased (e.g. trying all possible public-private keys combinations to find a match, instead of taking
years today for a certain key length, will only take a few hours). When validating a signature years after
its creation, it is important to know if it was created at a time when the signature algorithm was
still valid.
For the reasons explained above, one sees that it is crucial for the relying party that validates a signature
to have a good assurance on the time of creation of the signature. The time of creation of the signature
needs to be positioned BEFORE any event affecting the validity of a signature. I.e.:
— the possible revocation of any signature tool (typically the signer’s certificate or the signer’s CA’s
certificate);
— the end of validity period of the signer’s certificate;
— the obsolescence of the underling cryptographic algorithm.
According to the term of preservation, different proofs need to be gathered in due time (e.g. after expiry
of the certificate, one needs to use other guarantees and tools (not only because the CA’s guarantees on
the crypto suites are likely expired, but also because other guarantees and services linked to the
certificate have also expired or may not be available anymore)). This is referred to as the signature
augmentation (see Clause 6).
The security and level of assurance (LoA) on these tools and proofs are provided by the CA and/or other
TSPs offering them (see Clause 6). To this regard, the TSP that offers (qualified) preservation service for
(qualified) electronic signatures is important.
Whatever the quality of an AdESig in the past, if it is not possible at a certain point of time to affirm that
it is linked to the data signed therewith in such a way that any subsequent change in the data is detectable,
it is not an AdESig anymore, since the “detectability” feature of point d) above is lost.
5.3.4 How digital signatures cover the legal requirements for QES
A QES requires a “qualified certificate for electronic signatures” and a “qualified signature creation device”.
The same components are used for QES and AdESig, but the quality of these components will reach a
certain level defined by the EU Regulation N°
...