SIST-TP CEN/TR 419030:2018

SLOVENSKI STANDARD
01-september-2018
Racionalizirana struktura za standardiziran elektronski podpis - Dobre prakse za
MSP
Rationalized structure for electronic signature standardization - Best practices for SMEs
Cadre pour la normalisation de la signature électronique - Meilleures pratiques pour les
PME
Ta slovenski standard je istoveten z: CEN/TR 419030: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 419030
TECHNICAL REPORT
RAPPORT TECHNIQUE
May 2018
TECHNISCHER BERICHT
ICS 35.030
English Version
Rationalized structure for electronic signature
standardization - Best practices for SMEs
Cadre pour la normalisation de la signature
électronique - Meilleures pratiques pour les PME

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 419030:2018 E
worldwide for CEN national Members.

Contents Page
European foreword . 3
Introduction . 4
1 Scope . 5
2 Terms and definitions . 5
3 Abbreviations . 7
4 Electronic seals as per EU Regulation 910/2014. 9
5 SME’s perspective . 10
5.1 Reasons for signing or sealing . 10
5.1.1 General . 10
5.1.2 Electronic signing as a way to confirm a legal commitment or because of a legal
requirement . 11
5.1.3 Electronic signing as a matter of diligence / risk management . 12
5.1.4 Electronic seals as a way to comply with an explicit legal requirement to apply a seal,
stamp or comparable formal requirement . 13
5.1.5 Electronic seals as a way to ensure the integrity and authenticity of a document . 13
5.2 Who signs or seals? . 13
6 Solutions . 14
6.1 General . 14
6.2 Signature creation . 14
6.2.1 General . 14
6.2.2 Remotely managed signature creation application and signature creation device . 16
6.2.3 Remotely managed signature creation device . 17
6.2.4 Remotely managed signature creation . 17
6.2.5 Signature creation application and signature creation device in the hand of the
signatory . 18
6.2.6 Responsibilities of parties . 19
6.2.7 Level of security and assurance on the issued signatures . 20
6.3 Signature validation . 21
6.4 Signature preservation . 21
7 I’m a TSP? . 22
8 Use-cases . 23
8.1 Use-cases where the SME is signing . 23
8.1.1 eInvoicing . 23
8.1.2 eProcurement Directive . 23
8.1.3 Accessing markets across the EU and the impact of the Services Directive . 24
8.2 Use-cases where the SME and the SME’s customers / partners are co-signing or co-
sealing . 25
9 Annex Digital signatures standardization . 26
Bibliography . 30
European foreword
This document (CEN/TR 419030: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 Regulation (EU) N°
910/2014) which addresses various services that can be used to support different types of electronic
transactions and electronic signatures 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 electronic 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 document 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.
Further support is provided to the emerging cross-border use of eSignatures through other legal and
policy instruments that affect electronic processes being used in the market today (e.g. eInvoicing
Directive [3], Public Procurement Directive [4] and Services Directive [5]).
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.
The present document builds on CEN/TR 419040.
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.
1 Scope
This Technical Report aims to be the entry point in relation to electronic signatures for any SME that is
considering to dematerialize paper-based workflow(s) and seeks a sound legal and technical basis in
order to integrate electronic signatures or electronic seals in this process. It is not intended to be a guide
for SMEs active in the development of electronic signatures products and services - they should rather
rely on the series ETSI EN 319 for building their offer - but it is a guide for SMEs CONSUMING e-Signature
products and services.
This document builds on CEN/TR 419040, “Guidelines for citizens”, explaining the concept and use of
electronic signatures, to further help SMEs to understand the relevance of using e-Signatures within their
business processes. It guides SMEs in discovering the level of electronic Signatures which is appropriate
for their needs, extends the work to specific use-case scenarios, paying special attention to technologies
and solutions, and addresses other typical concrete questions that SMEs need to answer before any
making any decisions (such as the question of recognition of their e-Signature by third parties, within
their sector, country or even internationally).
Once the decision is taken to deploy electronic signatures or electronic seals in support of their business,
SMEs will then typically collaborate with their chosen providers of e electronic signatures or electronic
seals products or services, which can be done on the basis of ETSI TR 119 100 “Guidance on the use of
standards for signature creation and validation”, that helps enterprises fulfil their business requirements.
The present document presents the concepts and use of the standards relevant for SMEs developed under
the Rationalised Framework to SMEs.
2 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
2.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 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)]
2.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)]
2.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 [i.x]]
2.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)]
2.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)]
2.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)]
2.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)]
2.8
signature creation device
configured software or hardware used to create an electronic signature
[SOURCE: Regulation (EU) N° 910/2014 [1], Article 3 (22)]
2.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)]
2.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)]
2.11
signatory
natural person who creates an electronic signature
[SOURCE: Regulation (EU) N° 910/2014 [1] Article 3 (9)]
2.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]
2.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.]
2.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.]
2.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]
3 Abbreviations
For the purposes of this document, the following abbreviations apply.
AdESig/AdESeal QC An AdESig/AdESeal supported by a QC
AdESig/AdESeal advanced electronic signature / seal as defined in the Regulation
(EU) N° 910/2014 [1]
CA Certification Authority
CAdES CMS Advanced Electronic Signatures
CMS Cryptographic Message Syntax
CRL Certificate Revocation List
CSP Certification Service Provider
DA Driving Application
DTBS Data To Be Signed
EU European Union
HSM Hardware Security Module
ISO International Organization for Standardization
LoA Level of Assurance
LT Long Term
LTA Long Term Archive Validation Data
OCSP Online Certificate Status Protocol
OID Object IDentifier
PAdES PDF Advanced Electronic Signatures
PDF Portable Document Format
PIN Personal Identification Number
PK Public Key
PKI Public Key Infrastructure
QC Qualified Certificate
QES qualified electronic signature or seal
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
SME Small and medium size enterprise
SVA Signature Validation Application
TSA Time-Stamping Authority
TSP Trust Service(s) Provider
VAT Value Added Tax
XAdES XML Advanced Electronic Signatures
4 Electronic seals as per Regulation (EU) N° 910/2014
The concepts relating to electronic signature and its legal validity are presented in CEN/TR 419040,
“Guidelines for citizens”. In addition, in the framework of SMEs it is important to introduce a companion
concept, the electronic seal, which is defined by the Regulation 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”.
The electronic seal can be seen as the equivalent to a stamp on a paper document, i.e. attributed to a legal
entity (such as a company or public administration) but not necessarily to an identified natural person
(i.e. it is not necessarily possible to identify a specific person who applied the seal).
There are two major differences between an electronic seal and an electronic signature:
— the nature of the creator, which must be a legal person for an electronic seal and a natural person for
an electronic signature; and
— the intended legal effect, which is the presumption of integrity of the data and of correctness of the
origin of that data to which the seal is linked for the seal, and the equivalence to a handwritten
signature for the electronic signature.
It shall also be noted that no pseudonym is allowed for an electronic seal certificate, while pseudonyms
are allowed for electronic signature certificates.
However, the two concepts are similar conceptually and also technically:
— the definitions of advanced electronic seal and advanced electronic signature (AdESig/AdESealig and
AdESig/AdESealeal) are quasi identical. A small difference is the requirement on the control of the
electronic signature creation data that must be under the sole control of the signatory for the seal
and under control of the creator of the seal for the seal. This is to reflect the fact that a seal belongs
to a legal person and contrarily to a natural person, the legal person can frequently be represented /
controlled by more than one person.
— the definitions of validation and validation data are the same.
— the QSCD, qualified electronic seal creation device, is required to meet mutatis mutandis the Annex II
requirements for qualified electronic signature creation device.
Technically speaking, the same technology will support equally (advanced) electronic seals and
(advanced) electronic signatures. In particular, PKI such as presented in CEN/TR 419040, is well suited
for AdESig/AdESeal.
For SMEs, electronic seals can be particularly important. Signatures are used by natural persons with the
intent to sign, i.e. they are conceptually closely linked to the concept of hand written signatures. It is
nevertheless still possible to issue a signature that contains also the name of the organization the
signatory is associated with or the signatory’s quality or function in the organization. This would
be similar to the current practice of applying a hand written signature on a paper document and
mentioning the signatory’s name and title within a company: the signature in this case affirms the
involvement of the specific natural person, but also emphasizes their role within the company.
NOTE The Regulation Recital 58 states “When a transaction requires a qualified electronic seal from a legal
person, a qualified electronic signature from the authorised representative of the legal person should be equally
acceptable”. It means that, according to national legislation and / or for backward compliance or any other reasons,
it is still possible for a natural person who is entitled to represent a legal person (such as a CEO) to sign a data rather
than sealing it, provided there is an entitled natural person to do so.
Electronic seals on the other hand are defined in the Regulation 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’. In other words, they do not contain an intent to sign, but only an intent to ensure the origin
and integrity. Seals emanate from legal entities, not natural persons. This makes them very useful for
administrative processes where the responsible organization is relevant, but not necessarily the identity
of the person (e.g. employee) involved (if there is any human intervention to begin with). It is
nevertheless still possible to issue a seal that contains the name of the person that has affixed it
on behalf of the organization, for information. This would be similar to the current practice of
applying a stamp that identifies an organization and the person in charge of that organization (e.g. ‘John
Johnson - Secretary of company X’): the stamp in this case affirms the legal person from which the
document emanates, but also stresses the involvement of the specific natural person who is in control of
the issuance of such documents.
Finally, like for electronic signatures, the regulation distinguished between basic, advanced and
qualified electronic seals. Here too, the distinction is intended to reflect the trustworthiness, level of
assurance and legal reliability of the solution being used.
5 SME’s perspective
5.1 Reasons for signing or sealing
5.1.1 General
The first most important step for a SME that intends to use electronic seals or signatures is to assess the
business cases for signatures or seals, i.e. determining which documents will be sealed or signed (or even
both), and why. There are different reasons that an SME might have for signing or sealing, which will
impact their choice of technology. The paragraphs hereunder present a broad overview of potential
reasons and the implications.
5.1.2 Electronic signing as a way to confirm a legal commitment or because of a legal
requirement
Electronic signing can be used as a way to confirm a legal commitment, such as a contract, or because
there is an explicit legal requirement to sign a document. This includes forms/complaint forms sent to
the SME by a customer, or also documents which the law requires to be signed by an employee or a SME’s
formal representative (see also Clause 8 illustrating the eInvoicing, eProcurement and services Directives
related use-cases).
One of the most recognizable business cases of electronic signatures is to confirm the acceptance of a
legally binding commitment. As the examples below will demonstrate, confirming a legal commitment is
far from the only situation in which a document is signed, but it is a frequently encountered business case.
For most types of legal commitments, depending on national laws, a signature (electronic or otherwise)
may not be a legal requirement for the validity of the legal commitment, but usually it is a legal or practical
prerequisite to be able to prove the existence and nature of the commitment. From a practical
perspective, this implies that signatures are virtually mandatory to express legal commitments, as
informal commitments (e.g. verbally agreed between two parties or written down without any form of
signature) may be legally valid, but would face significant challenges in terms of enforceability and
accountability.
Examples include the signing of contracts, orders, and similar acts in which a natural person expresses a
legal commitment, either on behalf of themselves or on behalf of a third party (another natural person, a
legal entity or an organization) to be bound by the obligations in the signed document.
As a general principle, and subject to national laws which can impose specific requirements for specific
document types, basic electronic signatures, advanced electronic signatures and qualified electronic
signatures are all permissible. Seals however are not typically appropriate for this business case: it must
be possible to identify the natural person who created the electronic signature, which a seal doesn’t
necessarily do. If the person creating the signature cannot be identified, the result will not qualify as a
signature, and evidentiary challenges may arise since the competence of person to represent the SME
cannot be verified.
If the legal context (e.g. national law) requires an equivalence to handwritten signature, only the QES will
be certain to achieve this objective. In the absence of any other legal framework than the Regulation (EU)
N° 910/2014, the most comfortable situation is therefore to require signatures at the qualified level.
Nothing prevents the use of other AdESig/AdESeal that benefit from a non-deniable legal value, but the
qualified signature benefits from the automatic recognition and are considered as equivalent to hand-
written signature across the entire EU; this is an assurance that no other type of electronic signature can
provide, which may be important for an SME.
Basic signatures – like non-qualified AdESig/AdESeal can benefit from a non-discrimination rule. This
means that no judge in the EU can reject them automatically as being invalid simply because they are
electronic. However, their dependability is still lower than that of a QES because the signatory may be
required to prove the security of the technology being used if the validity of the signature is disputed
before a court. This requires significant costs and efforts that could be avoided with relative ease by
opting for the more established and standardized advanced and qualified signature solutions.
It may also be the case that the relying parties have no applications or tools to validate such signature,
when not based on standards; in such a scenario, the signature may be legally valid and technologically
robust, but yet unusable from a practical perspective. For these reasons, QES or AdESig/AdESeal based
on recognized EU standards are preferable unless the SME operates purely in a local context where the
acceptance and usability of the chosen signature solution is sufficiently certain.
Also, even if the relying parties have applications or tools to validate such signature such as explained in
CEN/TR 419040, it may be the case that the CA having issued the certificate is not recognised by the
application (where the Qualified Certification Authority is generally automatically endorsed by of-the-
shelf applications). This may lead to confusing security warnings.
Key complexities that can occur for this business case are the following:
• Representation of an organization, such as an SME. How can a relying party be sure that a person is
authorized to bind the organization? Note that this problem is not unique to electronic signatures; it
exists in paper signatures as well (and arguably more so, since electronic signatures can more easily
convey highly trustworthy identity information). However, electronic signatures do permit the
implementation of solutions to this problem by incorporating authorization management solutions.
• Long(er) term validity: this is not a necessity in all business cases; e.g. an order form only requires
short term validity, typically until the goods/services have been delivered and paid for. Contracts on
the other hand can have very long storage and retention requirements, of potentially an unlimited
duration. When needed, long-term preservation and validation shall be supported to address the
problem of aging of electronic signatures and seals (see CEN/TR 419040). Note that this can also
impact authorization powers: even after a signatory has left the organization, it should ideally still
be possible to determine that the person had the authority to sign at the time of signing. Again, this
problem is not unique to electronic signatures.
• Time of signing. Typically, the date of signing will be indicated in the signed document, at least if this
plays a role in its legal value or legal meaning. In paper documents, dates are simply printed on the
document to be signed. For electronic documents, time stamping is a possibility to avoid risks of
tampering. This is not a condition sine qua non, but implementing it will remove a risk, support
validation, and enhance legal certainty.
• Volume (or mass) signing. In paper processes, this complexity has no solution and many hand written
signatures must be applied. Electronic signatures can be more effective on this point through mass
signing of multiple documents. Whether this needs to be supported depends on the processes in
which the signature needs to be applied; an SME may or may not have a high number of documents
that need to be (electronically) signed.
Handling these complexities (that also affect the other business cases to a certain extend), will influence
the choice of the technical solution and of the options offered by such solution (e.g. does the solution
provide a preservation service?) (see below).
5.1.3 Electronic signing as a matter of diligence / risk management
Examples of this use-case include forms or documents which are not signed because the law requires a
signature, but because there is a need to ensure their integrity and authenticity. Such documents do not
necessarily contain a legal commitment. Rather, a signature is applied to support due diligence / risk
management: the signature enforces the signatory’s responsibility and authority with respect to the
issued document.
It allows the recipient to determine the integrity and authenticity of a document, and supports
accountability in case of incidents. The signature can be used in the framework of patent request, e.g.
indeed, with a timestamp it allows to proof the date of creation of a document and guarantees the link
with the author of the document.
Again, as a general principle, basic electronic signatures, advanced electronic signatures and qualified
electronic signatures are all theoretically permissible, and seals are not (although seals may be a separate
requirement).
The same considerations with regard to key complexities apply as for electronic signing as a way to
confirm a legal commitment.
5.1.4 Electronic seals as a way to comply with an explicit legal requirement to apply a seal,
stamp or comparable formal requirement
The logical counterpart of electronic signing as a way to confirm a legal commitment, the law sometimes
explicitly and unambiguously requires a seal, stamp or similar token from an organization, without a need
for any specific signature from a natural person. The functional goal of the law is often not stated,
although one might assume that it is a generic objective to ensure the integrity and authenticity of the
sealed/stamped document.
However, the current definitions of advanced and qualified signatures cannot be applied to seals, as they
require a human signatory and aim at equivalence with hand written signatures (meaningless in the
context of seals). Therefore, for these cases, electronic seals should be used rather than electronic
signatures.
As a general principle, basic electronic seals, advanced seals signatures and qualified electronic seals are
all permissible.
5.1.5 Electronic seals as a way to ensure the integrity and authenticity of a document
Finally, this last case includes issuance of an attestation, certificate, extract or similar document for which
a recipient must be able to determine the document’s origins and integrity (has it not been modified after
issuance), where the law does not contain a clear sealing/stamping obligation.
Here too, as a general principle, basic electronic seals, advanced seals signatures and qualified electronic
seals are all permissible.
5.2 Who signs or seals?
For some cases, the SME alone is signing or sealing (e.g. eInvocing, eProcurement) while in other cases
the SME’s partners or customers are signing or sealing (e.g. signing an order for the use or purchase of a
product or service) and in some cases both are signing or sealing (e.g. co-signing contracts).
— When the SME’s representative is signing it is important to determine how the signature will reflect
the link between the signatory and the organization. As indicated in Clause 4 above, the signatory’s
certificate can bear the name of the organization. It is also possible to add a sentence in the signed
document that says “I’m signing in quality of (e.g.) director”. This is a self-claim which is unverified
by the signature itself, but similar to what is done for paper signature.
— When the SME’s is creating a seal, it is important to determine if there is a need to identify the person
that has affixed it on behalf of the organization, for information.
— When the SME’s partner or customer is signing or sealing, it is important that the SME is satisfied by
the level of security and assurance provided by this signature or seal. E.g. a QES, or an
AdESig/AdESeal of a certain quality, or a basic signature (see above). If a certain level is expected,
the SME must be able to validate the fact that the received signature or seal actually reaches this level
(by itself or through the use of a validation application that can handle such validation constraints).
Finally, before choosing an appropriate signing/sealing solution, the SME needs to identify the elements
that characterize the transaction:
— It is possible that a document must be both sealed and signed, e.g. by both the SME and a specific
customer, or the SME and a specific employee.
— There is a distinction between unique documents that are signed one by one by a SME’s
representative or employee, and documents which are signed and issued in large numbers through
semi-automated processes. For high volume processes, greater automation of signature and signing
processes will be necessary (it is not viable, necessary nor appropriate to require the signatories to
type their PIN codes hundreds of times).
— What is the expected duration and validity period of the signed/sealed information? Is it sufficient
that the recipient of a document can validate it immediately, or is long term validation a requirement?
If the latter is the case, is it a matter of months, years, decades, or potentially without duration?
6 Solutions
6.1 General
NOTE If not specifically otherwise specified, the terms “sign” and “signature” in the following text address the
technique for creating both electronic signature and electronic seal.
Signature solutions can be implemented in many ways, ranging from situations where the signatory holds
and controls all hardware and software necessary for the creation of a signature, to situations where a
signing service is used and where the signatory does little more than select documents and enter an
appropriate code to apply the signature. Both of these situations and all intermediary cases may be
appropriate: CEN/TR 419040 explains that signatures can be entirely performed within the signatory’s
environment (the signatory holds his signature creation device and signs with an application residing on
his computer) or that it is possible to delegate a more or less important part of the signature creation
process to a centralised signature creation service, that can be provided by an external TSP.
The strict minimum is that the signatory shall be able to control the activation of the private key, as this
is the element that ultimately allows a signature to be attributed to a specific signatory. For this reason,
the signatory / creator of the seal shall have the sole control / control on the authentication to her/his
key. All the rest, even including the management of the private key (generation, storage), may be
delegated. For individual citizens the delegation will almost without exception be done to a TSP. For an
SME, depending on its technical proficiency and resources, the SME may take some parts of the process
in charge without necessarily be itself a TSP (see below).
6.2 Signature creation
6.2.1 General
As noted above, different architectures for signature creation are possible, ranging from a maximum of
signature components remotely managed, to cases where the signatory or the creator of the seal has “all
in hand”:
Figure 1 — Possible signature components architectures
In the architectures presented above, the “server” can be a centralised service managed by the SMEs for
offering signature solutions to its employees, or customers, or it can be a services offered by a third party
TSP.
6.2.2 Remotely managed signature creation application and signature creation device
In the first case, the signatory or the creator of the seal requests and authorizes a remote signature to be
created and applied to specific data on his behalf by a server.
The signing server hosts the signing keys and related certificates. The certificates are bought from a third
party CA or are generated by the party hosting the server. The certificates may include the function of
signatory or the name of the person that affix the seal; this is an implementation choice which is usually
made by the service provider, and the SME should verify that the solution which is offered meets its needs.
When a SME delegates this service to a TSP, the SME may play the role of Registration Authority (RA)
itself; in this case, it may at its own discretion enrol its employees and request the certification of roles
or other attributes within the certificate requests toward the CA.
Example of a process using this service
1. Once (s)he has been allocated with his/her certificate, the signatory or the creator of the seal
requests a signature to the signature creation service through e.g., a mobile app.
2. The signature service may request authentication.
3. The signature service proposes certain certificate(s) (if more than one are available to this person;
this can e.g. be the case if a single person has a signature certificate for private use (containing only
his/her own name) and another signature certificate for professional use (containing his/her
function within an identified company).
4. The signature service, according to the type of document, can impose a certain type of signature, or
limit its use to a specific type of person. If the restriction is not met, the service can refuse the creation
of the signature and abort the process.
5. The signatory or the creator of the seal may select the term of preservation (if proposed by the
service).
6. Optionally, a second authentication for signature activation is requested.
7. The signature is computed.
8. The signed / sealed data are locally stored (i.e. on the signatory’s environment) and/or stored on the
server and/or the service proposes to take further actions (e.g. sends the signed / sealed data to
another service, e.g. for counter signature).
Such a solution relies on remote implementation, but can still allow the signatory to control to a great
extent the way documents are signed and enables the organization and dematerialisation of complex
workflows, including mass signing, (i.e. signing more than one data at once is possible) are possible to
manage.
It allows a great level of mobility to the users. However, especially when provided by an external TSP,
remote signing services are only usable to the extent that the reliance on a third party’s services does not
lower the level of trustworthiness. Therefore, great care shall be taken with respect to the security at the
server side:
— Precautions must be taken that the signing platform never requests (or permits any security holes
that would enable to request) the signature creation key to sign a fake document (this is called the
“what you see is what you sign” principle).
— There is a need to protect the signing keys properly; all accesses to the signing server and to the
signing keys stored o
...