Professional Documents
Culture Documents
Report
November 2007
Preliminary Study on Mutual Recognition of
eSignatures for eGovernment applications
November 2007
This report / paper was prepared for the IDABC programme by:
Disclaimer
The views expressed in this document are purely those of the writer and may not, in any
circumstances, be interpreted as stating an official position of the European Commission.
The European Commission does not guarantee the accuracy of the information included in
this study, nor does it accept any responsibility for any use thereof.
Reference herein to any specific products, specifications, process, or service by trade name,
trademark, manufacturer, or otherwise, does not necessarily constitute or imply its
endorsement, recommendation, or favouring by the European Commission.
All care has been taken by the author to ensure that s/he has obtained, where necessary,
permission to use any parts of manuscripts including illustrations, maps, and graphs, on which
intellectual property rights already exist from the titular holder(s) of such rights or from her/his
or their legal representative.
2
Preliminary Study on Mutual Recognition of
eSignatures for eGovernment applications
November 2007
Executive summary
The objective of the project is to analyse the requirements in terms of interoperability of electronic
signatures for different eGovernment applications and services taking into account the relevant
provisions of Directive 1999/93/EC on a Community framework for electronic signatures and their
national implementation as well as the report on the Directive and the standardisation activities on the
interoperability of electronic signatures.
The goal of this document is three-fold:
- identify and analyse the similarities and differences in the use of electronic signatures in
eGovernment applications in each Member State both in the legal context, and on the technical
implementation aspects;
- assess the impact of the identified similarities and differences on the interoperability of eSignatures
and hence of the eGovernment applications;
- prepare conclusions and recommendations on addressing interoperability issues related to the
mutual recognition of electronic signatures for eGovernment applications/services.
3
Preliminary Study on Mutual Recognition of
eSignatures for eGovernment applications
November 2007
Table of Contents
EXECUTIVE SUMMARY 3
1 DOCUMENTS 7
1.1 APPLICABLE DOCUMENTS 7
1.2 REFERENCE DOCUMENTS 7
2 GLOSSARY 8
2.1 DEFINITIONS 8
2.2 ACRONYMS 10
3 INTRODUCTION 11
4 ANALYSIS 14
4.1 EGOVERNMENT AND ESIGNATURE REGULATIONS 14
4.1.1 THE EUROPEAN LEGAL FRAMEWORK 14
4.1.1.1 Basic principles 14
4.1.1.2 Public sector clause: article 3.7 14
4.1.1.3 eSignatures and authentication 16
4.1.2 NATIONAL REGULATORY APPROACH MODELS 18
4.1.2.1 General strategy 18
4.1.2.2 National competence and organisation 24
4.1.3 NATIONAL ESIGNATURE REQUIREMENTS 27
4.1.3.1 Dominant Signature types 28
4.1.3.2 Choice of Unique identifiers 37
4.1.3.3 Technological choices 41
4.1.3.4 Cross border acceptance 41
4.1.4 NATIONAL TRENDS AND EXPECTATIONS 42
4.1.4.1 State of eSignatures 42
4.1.4.2 Interoperability requirements 43
4.1.4.3 Long term validity and storage 44
4.2 EGOVERNMENT APPLICATIONS USING ELECTRONIC SIGNATURES 47
4.2.1 APPLICATION APPROACH MODELS 47
4.2.1.1 Group 1: shared service approach 48
4.2.1.2 Group 2: ad-hoc approach 54
4.2.2 CLASSIFICATION BY MODEL 62
4.2.2.1 Introduction 62
4.2.2.2 Model 1: One-stop shop model 64
4.2.2.3 Model 2: common eSignature framework model 64
4.2.2.4 Model 3: Generic CSPs model 68
4
Preliminary Study on Mutual Recognition of
eSignatures for eGovernment applications
November 2007
5
Preliminary Study on Mutual Recognition of
eSignatures for eGovernment applications
November 2007
7 CONCLUSIONS 153
6
Preliminary Study on Mutual Recognition of
eSignatures for eGovernment applications
November 2007
1 Documents
[RD1] eGovernment in the Member States of the European Union – 5th Edition – May
2006
http://ec.europa.eu/idabc/servlets/Doc?id=24769
[RD2] European Electronic Signatures Study
http://www.law.kuleuven.ac.be/icri/itl/es_archive.php?where=itl
[RD3] DIRECTIVE 1999/93/EC OF THE EUROPEAN PARLIAMENT AND OF THE
COUNCIL of 13 December 1999 on a Community framework for electronic
signatures
http://europa.eu.int/information_society/eeurope/i2010/docs/esignatures/esignatur
es_en.pdf
[RD4] Decision 2003/511/EC of 14 July 2003 on the publication of reference numbers of
generally recognised standards for electronic signature products in accordance
with Directive 1999/93/EC of the European Parliament and of the Council, OJ L
175, 15.7.2003, p.45
http://europa.eu.int/eur-
lex/pri/en/oj/dat/2003/l_175/l_17520030715en00450046.pdf
[RD5] DIRECTIVE 2004/18/EC OF THE EUROPEAN PARLIAMENT AND OF THE
COUNCIL of 31 March 2004 on the coordination of procedures for the award of
public works contracts, public supply contracts and public service contracts
http://eur-
lex.europa.eu/LexUriServ/site/en/oj/2004/l_134/l_13420040430en01140240.pdf
[RD6] IDABC Work Programme Third Revision
http://ec.europa.eu/idabc/servlets/Doc?id=25302
[RD7] DIRECTIVE 2004/17/EC OF THE EUROPEAN PARLIAMENT AND OF THE
COUNCIL of 31 March 2004 coordinating the procurement procedures of entities
operating in the water, energy, transport and postal services sectors
http://europa.eu.int/eur-
lex/pri/en/oj/dat/2004/l_134/l_13420040430en00010113.pdf
[RD8]
[RD9]
7
Preliminary Study on Mutual Recognition of
eSignatures for eGovernment applications
November 2007
2 Glossary
2.1 Definitions
In the course of this report, a number of key notions are frequently referred to. To avoid any
ambiguity, the following definitions apply to these notions and should also be used by the
correspondents.
o eGovernment application: any interactive public service using electronic means which is
offered entirely or partially by or on the authority of a public administration, for the mutual
benefit of the end user (which may include citizens, legal persons and/or other
administrations) and the public administration. Any form of electronic service (including
stand-alone software, web applications, and proprietary interfaces offered locally (e.g. at a
local office counter using an electronic device)) can be considered an eGovernment
application, provided that a certain degree of interactivity is included. Interactivity requires
that a transaction between the parties must be involved; one-way communication by a public
administration (such as the publication of standardised forms on a website) does not suffice.
It should be noted that for the purposes of this questionnaire, only services which rely on
eSignatures are relevant, and that the focus is on eGovernment applications offered to
citizens and businesses (A2C and A2B, rather than A2A).
o eSignature: data in electronic form which are attached to or logically associated with other
electronic data and which serve as a method of authentication with regard to this data. Note
that this also includes non-PKI solutions. However, PKI solutions are the principal focus of
this questionnaire, and non-PKI solutions should only be included if no PKI solutions are in
common use. It should also be noted that the questionnaire only examines eGovernment
applications in which the eSignature is used to sign a specific transaction, and not where the
signature is merely used as a method of authentication of the eSignature holder as defined
below.
o Qualified electronic signature: advanced electronic signatures which are based on a qualified
certificate and which are created by a secure-signature-creation device, as defined in the
eSignatures Directive1.
1
See http://eur-lex.europa.eu/LexUriServ/LexUriServ.do?uri=CELEX:31999L0093:EN:HTML
8
Preliminary Study on Mutual Recognition of
eSignatures for eGovernment applications
November 2007
o Authentication: the corroboration of the claimed identity of an entity and a set of its observed
attributes (i.e. the notion is used as a synonym of “entity authentication”). It should be noted
that the questionnaire is focused on the use of eSignatures as a method of signing a
transaction, and not on their use as a method for authenticating the eSignature holder.
o Relying party: any individual or organisation that acts in reliance on a certificate (in a PKI
solution) or an eSignature.
o Validation: the corroboration of whether an eSignature was valid at the time of signing.
9
Preliminary Study on Mutual Recognition of
eSignatures for eGovernment applications
November 2007
2.2 Acronyms
OTP..............................................One-Time Password
10
Preliminary Study on Mutual Recognition of
eSignatures for eGovernment applications
November 2007
3 Introduction
The background of this report is the European Community Programme for the interoperable delivery
of pan-European e-government services to public administrations, businesses and citizens
(hereinafter IDABC).2 The objective of IDABC is to identify, support and promote the development
and establishment of pan-European e-government services and the underlying interoperable
communications networks supporting the Member States and the European Community in the
implementation, within their respective areas of competence, of Community policies and activities,
achieving substantial benefits for public administrations, businesses and citizens.
The report is part of a larger study, of which the objective is to analyse the requirements in terms of
interoperability of electronic signatures for different e-government applications and services taking
into account the relevant provisions of Directive 1999/93/EC of 13 December 1999 on a Community
framework for electronic signatures and their national implementation. .
The first phase of this study provided an extensive overview of currently existing or envisaged
relevant e-government applications in all Member States, which make use of electronic signatures
(e.g. for public procurement, tax and social security declarations, request and delivery of documents,
etc.).
Per Member State, relevant information has been collected and a profile has been drafted describing
for each application the type of electronic signature legally required, the technical implementation of
the interface between the application and the electronic signature, the applicable technical restrictions
notably regarding interoperability with non-national electronic signatures and the authorities or
institutions that have been contacted to obtain information. The information has been collected
through a network of national experts.
The aim of this study is to analyse the national country profiles, to detect similarities and differences
and, on the basis of this comparative study, to provide an assessment from the perspective of
interoperability for cross-border e-government services in Europe.
The study focuses on signature applications with regard to the interaction between governmental
authorities and the public (A2B and A2C services, i.e. services to citizens, professionals, companies).
Purely internal interactions (A2A services, i.e. the e-government back-office) as such are not within
the scope of the study. Applications merely serving entity authentication purposes (i.e. not involving
electronic signatures) are not the aim of this study. They will be the object of a further study in the
framework of IDABC, focusing on electronic identity management schemes for e-government
purposes.
The main objective of the programme of which this study is a part, is to make progress in the field of
interoperability of electronic signature applications between Member States. The results of the study
must allow the elaboration of a strategy on the required inputs and components to produce an
interoperability solution for secure electronic signatures. Recommendations for such a strategy will be
the object of the third phase of the study.
2
More information on the IDABC programme can be found on http://ec.europa.eu/idabc.
11
Preliminary Study on Mutual Recognition of
eSignatures for eGovernment applications
November 2007
- it needs to offer legal certainty with regard to the requirements to be met by the used e-
signature technique;
- it needs to offer legal certainty with regard to the result of using the application (i.e. the legal
effect of the signature and the signed document);
- it needs to offer sufficient guidelines to service providers in all stages of the process
(application owners and designers, CSPs, token manufacturers, etc);
- it needs to ensure the long term validity of the signature and the signed document for any
application to which this factor is relevant;
- a variety of additional legal requirements need to be met, including with regard to privacy
protection, liability, and security.
In this report, we will describe what legal standards have been presented to the Member States and
Candidate Countries (hereafter: the ‘surveyed countries’), and how they have taken these to heart in
creating their own legal framework with regard to e-signatures in eGovernment applications. Specific
attention will be devoted to the requirements for the most dominant signature techniques for the
surveyed countries, and the impact that this may have on cross-border interoperability.
The main purpose is to provide a short descriptive overview of European regulatory initiatives and the
issues they present, and a more thorough examination of national approaches, specifically with
regard to their e-government regulations. To the extent possible, categories of approaches will be
proposed for each examined legal aspect. An evaluation of this information will be included in the
chapter on the impact of e-signature interoperability.
We will first take a brief look at the European legal framework with regard to e-signatures as it applies
to e-government applications, since this is essentially the baseline that has been provided to the
surveyed countries as a general target.
Secondly, the national regulatory approaches in the surveyed countries will be described, focusing on
the structural choices that have been made in establishing such a framework, particularly keeping into
account at which level regulations have been created (national vs. local; general vs. application
specific, etc.).
The third part of the analysis will indicate what e-signature solutions are
endorsed/recommended/required in the surveyed countries, and which requirements have been
imposed (including qualification according to the tiers of the e-signature directive, and accessibility of
the application to non-nationals). Finally the report will also examine the extent to which the
regulatory framework in the surveyed countries has stabilised at this point, and which future trends
can be expected.
From a technical perspective we will look in detail at every e-government application of all surveyed
countries to find if their approach is in some way illustrative of a given trend. The main purpose is to
describe the technical and organisational solution models, which need to be taken into account for
further analysis and recommendations. The applications will be classified in a limited number of
models, in order to obtain some degree of transparency and to enable an assessment with regard to
interoperability for cross-border e-government transactions.
12
Preliminary Study on Mutual Recognition of
eSignatures for eGovernment applications
November 2007
Four application models have been detected based on similarities shared by the described
eGovernment applications. The objective is to characterise and classify the various electronic
signature applications in the surveyed countries against these four models.
Secondly, we will define the concept of “interoperability”. Our analysis of the profiles of the surveyed
countries has shown that interoperability may have several interpretations. This section presents the
definition we used to classify the various e-government applications.
Thirdly, we present an analysis based on the models. For each model, a list of applications belonging
to that model will be presented, and the major deviations of each application type will be observed,
and assessed.
Finally, a last sub-section will contain a list of all eGovernment applications that have been assessed,
sorted by country and by model.
The legal and technical analysis of the e-signature applications in the surveyed countries will lead us
to a list of interoperability issues. The issues will be presented and can be used as a basis for a
discussion on possible European strategies in this area.
13
Preliminary Study on Mutual Recognition of
eSignatures for eGovernment applications
November 2007
4 Analysis
Before taking a closer look at the national regulatory e-signature frameworks, it is worth providing a
short overview of the main European provisions in this regard, as they essentially constitute the
baseline provided to the Member States as an aide or limit to their own regulatory initiatives.
In this section, we will take a succinct look at the e-signatures directive3 (hereafter referred to as ‘the
Directive’) as it pertains specifically to the public sector.
The stated goal of the Directive, as expressed in article 1, was to create a harmonised legal
framework for the use of electronic signatures and certain related certification services, in order to
improve their legal reliability and encourage ongoing dematerialisation efforts:
“Article 1. The purpose of this Directive is to facilitate the use of electronic signatures and to
contribute to their legal recognition. It establishes a legal framework for electronic signatures
and certain certification-services in order to ensure the proper functioning of the internal
market. […]”
The Directive’s provisions were in principle horizontal in scope, i.e. without any inherent limitation to a
specific sector. Thus, its tiered categorisation of signatures (basic, advanced and qualified), and more
importantly the related principles of non-discrimination and legal equivalence (article 5) would have
been applicable to solutions employed in the e-government sector as well.
However, article 3.7 contains an important derogation of this principle:
“7. Member States may make the use of electronic signatures in the public sector subject to
possible additional requirements. Such requirements shall be objective, transparent,
proportionate and non-discriminatory and shall relate only to the specific characteristics of the
application concerned. Such requirements may not constitute an obstacle to cross-border
services for citizens.”
It is clear that the Directive thus allows Member States to impose additional requirements to
electronic signatures as used in public sector applications. The main purpose of the legal section of
the report will be to assess how the Member States have interpreted this clause, and what type of
signatures they commonly require for such applications.
3
Directive 1999/93/EC of the European Parliament and of the Council of 13 December 1999 on a
Community framework for electronic signatures, OJ L 13, 19.01.2000, p.12.
14
Preliminary Study on Mutual Recognition of
eSignatures for eGovernment applications
November 2007
It is noteworthy that the Directive prohibits the creation of obstacles “to cross-border services for
citizens” (emphasis added) but we don’t think that this term has to be interpreted in a strict sense in
this context.
However, even if this would be so, the requirements must remain “objective, transparent,
proportionate and non-discriminatory and shall relate only to the specific characteristics of the
application concerned”. Thus, it is clear that the intended goal was for such requirements to be the
exception (as they should be application-specific), and clearly justified by the needs of the service
being provided and the common interest.
Furthermore, and specifically with regard to the cross-border exchangeability of e-signature, the
Directive also explicitly notes that:
The ELSIGN Study4 already noted that these principles of voluntary accreditation and public sector
restriction occasionally combined to a situation which was hardly in compliance with the Directive’s
intentions:
4
Study on the legal and market aspects of electronic signatures, see
http://europa.eu.int/information_society/eeurope/2005/all_about/security/electronic_sig_report.pdf
15
Preliminary Study on Mutual Recognition of
eSignatures for eGovernment applications
November 2007
“[…] it is necessary to perform a more detailed study on the internal Market consequences of
the e-government programmes of the Member States. There is a clear danger that these
programmes will result in national barriers, fragmentation and [lacking] interoperability.” (p. 12)
One of the main purposes of this report is precisely to assess whether or not this risk has materialised
in practice.
A major and frequently recurring point of debate is the relationship between electronic signatures and
authentication. In practice, it frequently occurs that a person is requested to authenticate himself in an
e-government application, after which he may exchange certain documents freely and without any
further technical steps. This method of proceeding (which is common in many countries, but which is
particularly prevalent in e.g. the United Kingdom, Lithuania, the Netherlands and Malta) is often
signalled as an electronic signature, both by the national experts and by the public sector application
owners. However, there is some debate as to whether or not such a process can be considered an
electronic signature.
A significant number of experts are of the opinion that this is the case. The reasoning behind this is
typically twofold. First of all, it is clear that the underlying process from a technical perspective can be
quite similar, in the sense that a PKI system is often5 used to authenticate the user, and that to the
layman this process is barely distinguishable from an actual act of signing6. Secondly, the Directive
explicitly defines the electronic signature as ‘data in electronic form which are attached to or logically
associated with other electronic data and which serve as a method of authentication’ (article 2.1,
emphasis added). Thus, there is a legal basis for the link between authentication and e-signatures7.
None the less, in our opinion the distinction between two core functionalities must be made. Firstly, it
is indeed clear that any signature will serve to some extent as a mechanism for authentication,
understood as the corroboration of a claimed set of attributes or facts with a specified, or understood,
level of confidence8. However, for the purposes of electronic signatures, the ‘authentication’ referred
to in the Directive can in our view only refer to data authentication, understood as the corroboration
that the origin and integrity of data is as claimed9; and not to entity authentication10.
5
But not always; username/password systems are also in common use for lower security type
applications.
6
Especially in cases such as the Belgian eID card, where the same PIN code is used for signature
purposes and authentication purposes, so that only the more attentive and knowledgeable users will
be able to ascertain which of the two certificates is actually being used by the application.
7
This perspective is also taken in the paper ‘Regulating a European eID – A preliminary study on a
regulatory framework for entity authentication and a pan European electronic ID for the Porvoo e-ID
Group’ by Thomas Myhr. See
http://www.fineid.fi/vrk/fineid/files.nsf/files/7431D844D1C359F9C225711F004553CB/$file/Thomas_M
yhr_report.pdf
8
See inter alia the Modinis eIDM Glossary, https://www.cosic.esat.kuleuven.be/modinis-
idm/twiki/bin/view.cgi/Main/GlossaryDoc#4_5_Authentication
9
See inter alia the Modinis eIDM Glossary, https://www.cosic.esat.kuleuven.be/modinis-
idm/twiki/bin/view.cgi/Main/GlossaryDoc#4_5_1_Data_authentication
16
Preliminary Study on Mutual Recognition of
eSignatures for eGovernment applications
November 2007
We argue against the extension of the notion of a signature to include entity authentication processes,
both for practical and for philosophical reasons. In legal practice, a signature has traditionally been
only one of many ways in which a person can confirm his identity, express his consent, effect non-
repudiation, and a myriad of other functions which are traditionally ascribed to signatures. The
signature has been given a specific legal status in most jurisdictions, although other ways of obtaining
the same legal result are usually (but not always) allowed. It is therefore not surprising that e-
government applications would show the same degree of flexibility, and permit other solutions than
electronic signatures to serve the same function. This does not mean in our opinion that such other
solutions can be readily considered to be signatures.
Indeed, if entity authentication could be said to be a form of signature on the grounds that it can
obtain similar results, the traditional value attached to signatures in many legal frameworks would be
in serious peril. After all, if one can be said to have electronically ‘signed’ a document after suitably
secure electronic entity authentication, then it seems one must also accept that a paper document
should be considered ‘signed’ if a person has merely handed it in after authenticating himself in
another suitable fashion (e.g. after ID card verification, or simply after visual identification by
someone familiar with the provider of the paper document). Paper documents should by this logic be
considered ‘signed’, even if there is ostensibly no signature attached to the document. This is not the
case: both in the paper and in the electronic context (as witnessed by the definition of the electronic
signature in the Directive), a signature is always ‘attached to or logically associated with’ the signed
document.
This distinction is thus not a purely theoretical or academic exercise. To accept that entity
authentication can be equalled to an electronic signature for the reason that the same functions are
served is an exaggeration of the theory of functional equivalence, to the point where the notion of a
signature becomes redundant, and where it merely becomes synonymous with the expression of
consent, validation, non-repudiation, and any other functionality which can be ascribed to a signature.
The purpose of the Directive was not to abolish the notion of a signature, but to allow technical
equivalents to it.
It is therefore our opinion that any process ensuring only entity authentication cannot be given the
status of an electronic signature, no more than a ‘real life’ entity authentication process can turn an
unsigned document into a signature bearing one.
These considerations should of course not be interpreted to mean that we consider entity
authentication as an invalid operating method in e-government applications, or indeed that we would
consider it to be somehow inadequate or less suitable than an electronic signature. As in any other
legal field, a signature has its purposes and its uses in e-government, but it should never be
considered to be a requirement when a different solution offers the necessary guarantees. We merely
wish to emphasise that in such cases, we find that no signature is actually used, and that applications
using purely entity authentication are therefore strictly speaking out of scope for this study.
It is interesting to note that many countries relying on entity authentication methods are in a transitory
phase, where the authentication method is planned as a user friendly but lower security level solution,
but where actual signature solutions are being planned for higher security applications.
10
See also the ELSIGN Study (The Legal and Market Aspects of Electronic Signatures report) in this
regard. See
http://europa.eu.int/information_society/eeurope/2005/all_about/security/electronic_sig_report.pdf
17
Preliminary Study on Mutual Recognition of
eSignatures for eGovernment applications
November 2007
“This mechanism is being rolled out in three phases. The first phase consists in the provision of a
username and password to each citizen for him/her to be able to authenticate himself/herself when
requesting eGovernment services. The second level is the distribution of digital certificates, while the
third level consists of a qualified digital certificate based on a smart card which would replace the
current Government-issued Identity Card. Malta is currently at the first phase of the project and has
implemented eID Level 1.
However, some eGovernment services already run on normalized digital certificates. For these
restricted number of eGovernment services, meant for Government’s business Clients, the Maltese
government procures digital certificates from a commercial CA. This allows Government, as a relying
party and the Business as the client, to benefit from a range of advanced eGovernment services
and to gain experience with certificate-based eServices. Digital certificates act as identity tokens for
electronic authentication but none of the eGovernment services require the user to sign
electronically.”
Thus, the main driver behind entity authentication as a proxy for electronic signatures seems to be
user friendliness and flexibility, rather than any philosophical or political preference. It has been noted
by several experts that entity authentication is retained as a proxy for electronic signatures for the
simple reason that it is considered ‘good enough’ in terms of safety and reliability, and that additional
requirements would encumber the underlying processes excessively in a manner that would offer little
added value.
For these reasons, entity authentication shall only be dealt with below insofar as it is presented by a
Member State as its current main proxy for electronic signatures. It should be noted that, for reasons
of brevity, ‘entity authentication’ will simply be referred to as ‘authentication’ in the remainder of the
report.
A first question that needs to be assessed is how the surveyed countries generally regulate their e-
signature applications. There are several components to this question.
First of all, the general regulatory strategy of the surveyed states needs to be described: is there
centralised regulation, do the rules vary from sector to sector or even from application to application,
etc. In short, a first question is to what extent a global vision is enacted in the country’s regulation.
Secondly, there is the legal-technical issue of competence: at what level is regulation enacted? While
national harmonisation is expected, it is none the less conceivable that certain regions or even
communes in any given country have taken a frontrunner role, possibly by relying on different
technological solutions.
While all surveyed countries have put in place specific regulation with regard to e-signatures in
general (typically as a result of the transposition of the Directive, or at least updated to reflect its
provisions), there is still a significant difference in the general strategies followed by the surveyed
18
Preliminary Study on Mutual Recognition of
eSignatures for eGovernment applications
November 2007
countries. While all aim to encourage the use of e-signatures in public sector applications, the
regulatory approach can differ significantly. Broadly, the following archetypes can be distinguished
(with the usual caveat that virtually no country falls cleanly and uniformly in one category, but that
most choose to incorporate aspects of several approaches).
4.1.2.1.1 Centralised
A first conceivable strategy (followed by a large majority of European countries) is the creation of a
single centralised legal framework, consisting of a single e-signatures law, on which all e-signature
uses are to be based. While this central legislation may have limited specific references to the use of
e-signatures in an e-government context (usually in the form of a transposition of the aforementioned
article 1.7 of the Directive), the focus is on establishing a global e-signatures framework, without
emphasis on the manner in which it is used.
Such central laws are then typically completed by a series of governmental/ministerial decrees
determining the specific modalities of the use of e-signatures in an e-government context. Thus, this
approach can be summarised as creating an e-signature regulatory core, and drafting the necessary
additions and clarifications around this core as required.
“The legal basis for the introduction of electronic signatures in eGovernment applications can be
found in various legislative provisions, which allow changing the way in which data are collected for
e.g. social security and tax purposes, or which put electronic notifications on par with paper
notification in a social security context.
By way of example, the social security contributions’ collecting institution can lay down the form and
11
rules for the electronic obligatory notification of the start and end of employee relationships . Also,
the social security management committee can lay down conditions for access to and use of the
information systems of social security institutions and the information system of the federal
government, including standards for message exchange.”
The result can be diverse and occasionally lacks consistency, since only the core is common, and
actual application details can vary quite widely.
This approach is followed in a number of countries, including:
11
Royal decree of 5 November 2002 introducing the immediate notification of an employment
relationship.
19
Preliminary Study on Mutual Recognition of
eSignatures for eGovernment applications
November 2007
4.1.2.1.2 Comprehensive
This second approach attempts to solve this problem by first establishing a holistic e-government
policy or vision (or even a broader e-society policy comprising such issues as e-government, e-
inclusion, e-health, etc.), which is then implemented in a homogeneous manner throughout all
affected sectors.
This typically results in a single broader legal act encompassing electronic signatures (or e-society
activities in general); or in a series of regulatory initiatives aiming to gradually implement a
centralised vision.
20
Preliminary Study on Mutual Recognition of
eSignatures for eGovernment applications
November 2007
The E-Government Act is an overall legal basis for the instruments used to provide eGovernment
and for closer cooperation between all authorities providing eGovernment services. Guiding
principles are freedom of choice for users of which means of communication to use when submitting
public administration requests, security and improved legal protection provided by appropriate
technical means such as the citizen card, and unhindered access for people with special needs to
public administration information and services by the end of 2007.
The E-Government Act defines the principal eGovernment elements. This includes the citizen card
concept together with the identity management system based on sector-specific personal identifiers,
provisions on the authority to act as a representative, or electronic delivery. Related to electronic
signatures, two provisions have been made: […]”
th
“On 13 September 2006 the federal Government passed a new programme with the name “E-
Government 2.0”. The content and basic thinking is in line with the E-Government action plan as part
of the i2010 initiative. Programme implementation resides with all federal departments with
coordination being handled by the Federal Interior Ministry. To this end a dedicated eGovernment
competence centre will be set up within the BMI in 2007.”
The main benefit of this approach is that such initiatives tend to benefit from an increased internal
consistency, since the relevant provisions are drafted as a whole. Such approaches also favour
distinct solution models, often emphasising one single token or one specific technology over others.
The downside of this approach is that the system can become inflexible or immune to changes, since
any modification can upset the coordination between the provisions, negating the central vision.
This approach is followed in a number of countries, including:
21
Preliminary Study on Mutual Recognition of
eSignatures for eGovernment applications
November 2007
A decentralised version of the earlier approaches, this model entails the creation of a suitable legal
framework on a sector by sector basis, i.e. specific regulations for the social security sector, the tax
sector, public procurement, civil administration, etc. Rather than depending on a global e-signatures
model, this approach favours the creation of a model taking into account the specific problems and
sensitivities of each concerned sector.
The genesis of such approaches is typically not the result of a specific vision or of a desire to ensure
that the regulatory framework is optimally adapted to the needs of the sector involved. Rather, such
approaches tend to evolve organically in situations where no central framework for e-signatures
existed, but where the need for technological advancements was still felt and acted upon in a specific
sector. Thus, it is conceivable that sector specific solutions are created before a national solution
model.
This is e.g. the case in Malta, where the current trend is to rely on authentication mechanisms
(userID/password based), rather than on e-signatures, except for two distinct sectors where specific e-
signature solutions have been introduced.
“The usage of electronic signatures is as yet not very diffused, since most of the services launched
have been based on eID Level 1 authentication mechanism (using a username and password). This
is not the case for only the following eGovernment services:
The advantage of sector specific regulation is of course that the solution has been built to the exact
needs of that sector, which should (in theory) result in a relatively well suited framework.
The obvious downside is that solution models can differ greatly from sector to sector, thus harming
consistency on a national scale, and creating interoperability problems even within a nation’s borders.
Such approaches are typically implemented by simply modernising existing legal texts to
accommodate a specific new technology, without introducing more all-encompassing changes.
Alternatively, as in the Maltese example above, it can be a result of an as of yet incomplete transition
to a generic signature framework.
This approach is followed in a number of countries, including:
22
Preliminary Study on Mutual Recognition of
eSignatures for eGovernment applications
November 2007
This final model is the logical extreme of the sector based approach described above. In this specific
case, regulation is created not with regard to an entire legal system or to a specific sector, but
specifically for a single application. While more limited in scope than the sector based approach, the
underlying logic is similar: a desire or need to advance one specific application, while a more global
vision has not yet been universally accepted.
This is a model that has been followed to a certain extent in Bulgaria, where efforts are now underway
to harmonising national e-signature practices.
“At the present moment the Bulgarian eGovernment is at a stage of development whereby the
available electronic services are mostly separate elements than parts of an organized structure. The
eGovernment projects are usually implemented separately within the structure of one administrative
body and under the control and the coordination of this body. Steps for overcoming the lack of
coordination between the administrative authorities in relation to the eGovernment development
have been undertaken through drafting a particular legislative framework of the Bulgarian
eGovernment, including the eGovernment Strategy, Action Plan for the implementation of the
Strategy, eGovernance Act etc.”
“Currently the applications in public administration that rely on e-signature use different modules for
creating digital signatures. Most of them use web components while others integrate desktop signing
modules. Such a situation is quite unsuitable because digital signatures created in all these
applications are not interoperable and some of them are not developed according to guidelines and
recommendations. Recently a decision to unify solutions for digital signatures in all public
administration applications has been taken. A tender for development of an independent module for
creating digital signatures will soon start and the selected solution will be available to all public
administration institutions.”
23
Preliminary Study on Mutual Recognition of
eSignatures for eGovernment applications
November 2007
However, the availability of specific ad hoc solutions is not restricted to legacy applications that have
not yet been sufficiently harmonised. In several instances, applications were reported that relied on
distinct signature mechanisms because it was felt that the generic framework did not provide
adequate safeguards to meet the requirements of the field at hand:
However, there are two notable applications that do not use the [eGovernment] portal (and they are
both described in more detail below).
The first is the e-Conveyancing application being developed for the Land Registry, which is a
government executive agency and trading fund responsible to the Lord Chancellor that keeps and
maintains the Land Register of England and Wales. Its main purpose is to register title to land and to
record dealings once the land is registered. Established in 1862, it is required by statute to be self-
financing and makes no call on public funds.
It was felt that the extreme sensitivity and liability implications relating to transactions for the buying
and selling of people’s homes meant that a bespoke solution needed to be developed that could be
introduced carefully in phases with tight controls on all aspects of the process, and should thus not
be added into the more generic solution provided by the Government Gateway.
The second such application is the DTI’s Oil & Gas Trust Scheme. Here it was felt that the
requirements of the industrial sector being served were more specific than those provided for by the
Government Gateway’s generic approach and that the financial model dictated by the value of the
transactions meant that a standalone solution was the most efficient way of achieving a workable
solution. Like the Government Gateway, tScheme is used as the basis for determining the suitability
of the CAs but unlike it, there are extra requirements placed on the CA over and above the basic
tScheme approval criteria.
It should be noted that the existence of ad hoc legal frameworks can in a sense be encouraged by
harmonisation initiatives. For example, following the e-procurement directives (Directive 2004/17/EC
and Directive 2004/18/EC), a given Member State may decide to prioritise the implementation of an
e-procurement platform incorporating e-signature functionality, before a global strategy for e-
government applications in general has been put into place.
Again, the main risk is the creation of a disjointed or maladjusted legal framework, when a more
global vision is drafted into law that does not mesh entirely with the legacy application created for a
specific problem field.
This approach is followed in a number of countries, including:
Aside from the general regulatory approach, issues of national competence can also play a
noteworthy role in assessing interoperability risks. Particularly (but by no means exclusively) within
24
Preliminary Study on Mutual Recognition of
eSignatures for eGovernment applications
November 2007
federal countries, the division of competences between the federal and regional levels can be
complicated, since there may be a common e-signature infrastructure which is offered on a federal
level which is open to use by regional or local authorities; or such regional or local authorities may
create their own independent infrastructures. Depending on the national situations, these diverging
local solutions may not (yet) have been subjected to harmonisation initiatives.
While the focus of the study was on national e-signature policy, which inevitably slants results toward
national solutions rather than regional/local initiatives, the main conclusion is that even federal
countries are attempting (or have already attempted) to harmonise their e-signature infrastructures on
a federal level. Two examples of this are Belgium and Germany.
Federal eGovernment
Federal eGovernment initiatives are lead and coordinated by FedICT, the Federal Public Service for
Information and Communication Technology (www.fedict.be).
Regional eGovernment
Regional eGovernment initiatives are lead and coordinated by the respective regional services.
• CORVE, the coordination service for Flemish eGovernment (http://www.corve.be);
• EASI, the coordination service for Walloon eGovernment (http://easi.wallonie.be);
• BRIC, the Brussels Regional Informatics Centre, for the Brussels Capital Region
(http://www.bric.irisnet.be/site/en).
Local eGovernment
Local eGovernment initiatives are lead and coordinated by local authorities, mostly municipalities.
Several municipalities set up an online interactive desk for the provision of eGovernment services
(www.iloket.be), developed by the IT service provider for communes (www.cipal.be). Typically, these
systems rely on the authentication mechanisms offered on a federal level, usually the e-ID card,
certificate or token offered by FEDICT (see below for a description of each option). In practice, the
user visits the communal website to access a local portal, which verifies the user’s credentials
through an LDAP framework offered by FEDICT. Upon successful authentication by FEDICT on a
federal level, the end user can access the local service.
[…]
As most electronic signatures in eGovernment applications have been designed at a federal level,
internal Belgian interoperability difficulties are few.”
25
Preliminary Study on Mutual Recognition of
eSignatures for eGovernment applications
November 2007
“In recent years Germany has experienced enormous changes in the public administration arena
both at federal and state level and at community level. As long ago as 1999, the federal Government
placed extensive emphasis on its reform programme "modern state - modern administration" for
modernising the Federal Republic of Germany’s public administration. 440 of the federal
Government’s administrative services were made available online as part of the “BundOnline 2005“12
initiative, which came to an end in December 2005. The lead role was taken by the Federal Interior
Ministry (Bundesministerium des Inneren - BMI)13. It is fair to say however that only a very small
proportion was designed for the use of electronic signatures.
However, because of Germany's federal structure - Germany is organised into 16 federal states14,
which exercise responsibility on their own account and some of which are able to look back on a
long tradition - the federal Government is unable to take any far-reaching decisions on behalf of the
federal states and municipalities. As most administrative services in Germany are provided not by
the federal Government but by the states and municipalities, their eGovernment activities assume
particular significance in the German context. It would clearly be beyond the scope of this study to
examine all of the eGovernment initiatives of the 16 federal states.”
However, despite both being federal states, the practical situation is noticeably different, with Belgium
having a significantly more centralised system, with less fragmentation and diversity between its
constituent regions and communities15.
12
http://www.bundonline2005.de/
13
http://www.bmi.bund.de/
14
http://www.magazine-deutschland.de/bl_overview.php
15
It can be argued that this is a consequence of the historical genesis of the federal states involved:
Belgium is a centrifugal federal state (i.e. a former unitary state that has at some point decentralised
part of its competences), which could naturally lead to a more unified approach than would be the
case for a centripetal federal state such as Germany (i.e. a federal country composed of states that
traditionally had a larger degree of autonomy which have centralized part of their competences).
Since this discussion is out of scope for this Study, it will not be examined further.
26
Preliminary Study on Mutual Recognition of
eSignatures for eGovernment applications
November 2007
Again, it should be noted that issues of fragmentation between regions also occur in unitary nations:
“As the result of the hierarchical administrative structure most of systems and services built for
eGovernment purposes are also very hierarchised. Moreover, in the case of eGovernment systems in
Poland there is a tendency to centralise information during collection, storage and processing. The
information is transferred from the communities and district level to the regional administration authorities
(the ‘voivodeship’ level); then the direct transfer from the voivodeship level to the central administration
authorities (ministries, departments) occurs. […] Practically there are no intersector public administration
systems, nor regional/local government ones. It means there is a lack of a vertical and horizontal
integration. Therefore the citizen (or an organisation) has no possibility to gather information from one
access point. He is forced to use many portals and access points.
[…]
In Poland the minister designated for IT implementation is responsible for the development of intersector
A2C and A2B IT solutions (horizontal integration), whereas the responsibility for sector-specific IT
solutions (vertical integration) is delegated to the minister of an appropriate government administration
department.
So there is no institution at the national level which would be responsible for the development of all IT
systems which use digital signatures.”
In this section, we will take a closer look at the signature requirements most commonly imposed by
laws or regulations to the dominant e-signature applications in the surveyed countries. It should be
noted that the emphasis here is not on the legal requirements imposed by the core legislations (which
is typically a faithful transposition of the Directive and therefore broadly includes provisions for all
signature types), but rather on the national administrative practices.
First of all, this requires an examination of the legal qualification of the signature type most commonly
required in e-government e-signature applications (in terms of the Directive: a
basic/advanced/qualified signature or an ad hoc solution that does not map cleanly into these
groups).
Secondly, we will examine what kind of unique identifiers are included in the certificates of PKI-based
signature systems, and the legal issues (mostly with regard to privacy regulations) revolving around
these.
A brief overview will also be given to the (lack of) technological neutrality of the legal frameworks in
the surveyed countries, and the extent to which any specific technology is allowed / encouraged /
mandated.
It should be reiterated that this report is descriptive; the consequences of these qualifications for
interoperability purposes will be dealt with in section 5 of this report. Nonetheless, a summary
overview will be provided at the end of this section describing the measures which are commonly
taken to allow cross-border functionality.
27
Preliminary Study on Mutual Recognition of
eSignatures for eGovernment applications
November 2007
It is interesting to note that, while most countries have faithfully copied the provisions of the Directive,
several countries have interpreted these in a slightly different manner, or have tailored their specific
e-government e-signature policies to their legal traditions. In this section of the Report, we will provide
a short overview of the national e-signature policies, and discuss a few specific interesting examples
in more detail.
In this section, we will provide a short overview of the requirements imposed on the principal e-
signature solutions in the surveyed countries. For specific details (including alternative signature
types less commonly encountered in these countries), we refer to the full country reports.
For the purposes of this report, the qualifications are used in the following sense:
• Qualified signature: use of a qualified certificate in combination with an SSCD, as the notion
is defined in the glossary above. Note that in most cases, the SSCD is not formally accredited
as such, but its status is generally accepted.
• Qualified certificate: use of a qualified certificate in the sense of the e-Signatures Directive16
is required, but no requirement of an SSCD is presented.
• Advanced signature: use of a non-qualified certificate meeting the requirements of the
Directive as presented in the glossary above.
• Simple signature: use of a lower level signature solution, meeting the definition of an
electronic signature in the Directive, but not that of an advanced or qualified signature. In this
case, the specific solution type is commented further below.
• Authentication: use of an authentication mechanism, typically based on a username/password
system, which cannot formally be considered a signature as discussed above in section 6.2.3.
In this case, the specific solution type is commented further below.
It should be noted that the table below contains the qualifications reported by the national
correspondents, as reviewed by the Expert Group.
16
As communicated by the correspondent. It should be noted that some countries may impose
additional requirements on qualified certificates, such as the French requirement for CSPs to issue
certificates in compliance with the norm AFNOR AC Z74-400 (TS 101 456); which would imply that
qualified certificates in other countries might not be considered qualified under French law if they
have not received such certification.
28
Preliminary Study on Mutual Recognition of
eSignatures for eGovernment applications
November 2007
29
Preliminary Study on Mutual Recognition of
eSignatures for eGovernment applications
November 2007
30
Preliminary Study on Mutual Recognition of
eSignatures for eGovernment applications
November 2007
In this section, we will look at a few Member States in detail if their approach is in some way
remarkable or illustrative of a given trend (e.g. The Netherlands’ use of authentication; the Estonian
generic eID based approach; the influence of historical legal traditions in Germany and Denmark;
etc.). The main purpose of this section is to describe a few typical legal solution models, which need
to be taken into account for further analysis and recommendations.
4.1.3.1.2.1 The Danish and German examples – the influence of legal traditions
Both the Danish and the German profiles are interesting examples of the influence of legal traditions
and socio-cultural sensitivities on the choices made when implementing a regulatory e-signatures
framework.
31
Preliminary Study on Mutual Recognition of
eSignatures for eGovernment applications
November 2007
“The definitions of advanced and “qualified” electronic signature under Danish law are very close to
the definitions of the European Directive. Advanced and “qualified” electronic signatures cannot be
issued to legal persons under Danish law.
[…]
The practical effect of the Danish eSignature Act has been disappointing as no “qualified” electronic
signatures are being offered by certification providers in Denmark. One of the main obstacles has
been the requirement for signature holders to meet up and identify themselves in person. Realising
that few people would do this the Government initiated the establishing of above mentioned OCES
signature.
The OCES signature is a “light version” of the qualified electronic signature with the important
difference that the holder of an OCES signature does not have to perform fact to face identification.
The OCES signature is widely supported by public authorities in their eGovernment solutions and is
explained in details below.
The OCES signature is not covered by the Danish eSignature Act as the OCES signature is not
based on a qualified certificate. Neither is the OCES signature covered by any other general
eSignature legislation (the eSignature Act focusing on “qualified” electronic signatures is the only
general eSignature legislation under Danish law).”
The Danish legal situation is to a large extent a result of its traditionally more flexible approach to
electronic documents in civil and commercial relations. The presence of a signature was for most
document types not a requirement for the admissibility of the document in legal proceedings under
Danish law. It is telling from that perspective that the Danish eSignature Act does not contain a
transposition of art. 5.2 of the Directive with regard to the non-discrimination of e-Signatures. Rather,
the Danish eSignature Act focused more on the validity requirement of qualified signatures of art. 5.2
of the Directive.
The fact that the Danish government was able to make the pragmatic choice for an advanced
signature that did not require in-person identification is to a large extent a consequence of this
tradition of legal flexibility. As a result, the main e-signature solution in Denmark is an advanced
software certificate, a significantly lower barrier than in other countries.
The German example is radically different, again partially due to its legal tradition, which is
substantially more formal in Germany than in Denmark. The German Civil Code makes a distinction
between several categories of formal documents, including the mandatory written form (sec. 126
BGB), the agreed written form (sec. 127 BGB), the notarisation (sec. 128 BGB) and finally the
certification by a notary public (sec. 129 BGB), none of which traditionally could be signed in an
electronic form. Following the eCommerce directive and the eSignature directive (directive
1999/93/EC), the German legislator introduced two new document categories, the so called Textform
(sec. 126b BGB) and the electronic form (126b BGB), the latter of which was capable of replacing a
substantial number of traditional paper document types, but also required a qualified signature. Thus,
the qualified signature was the de facto standard for valid e-signatures under German law.
It is thus not surprising that this also became the standard for e-signatures in e-government
applications:
32
Preliminary Study on Mutual Recognition of
eSignatures for eGovernment applications
November 2007
“As regards the topic of electronic signatures in eGovernment applications, it is worth noting that
when electronic signature procedures are used or offered, only qualified signatures are used. This
applies for the federal Government, states and municipalities and can be traced to the German legal
system (so-called written form requirement).”
While choosing drastically different approaches, both the Danish and the German situations are thus
good examples of the influence of legal traditions on the present e-government framework.
4.1.3.1.2.2 The Estonian example – generic e-signature functionality through a mandatory eID
card solution
The Estonian system is equally interesting, because it was designed based on the requirement that
the solution offered should allow Estonian citizens to use electronic signatures in an easily accessible
and harmonious way, without having to consider differences between systems. To do so, it relies on a
tandem consisting of the mandatory eID card (which includes two qualified certificates: one for
signature functionality, and one for authentication purposes) and of a common digital signature
system, revolving around the common set of libraries, tools and applications known as DigiDoc.
“In order to bring digital signatures into everyday life, common understanding and signature handling
practices are required. In addition, software and technology must be available for anyone interested, in
order to create compatible applications. After all, the key to unleashing potential digital signature benefits
lies in communication between organizations, not within one organization. Therefore, it is vital that all
organizations in a given community interpret and understand digital signatures the same way. In case of
Estonia, the community is the whole country.
A number of digital signature implementations and applications are available on the market, all claiming to
be suitable for specific purposes. However, no known application or implementation of the latest
standards was found which would suit the needs of the Estonian project, and reliance on foreign software
providers guaranteeing the functioning of a country's everyday life relying on digital signatures can also be
seen as a strategic risk. Therefore, a whole new approach – and a whole new software architecture –
was needed.
In 2002, SK together with its partners created an all-around digital signature architecture called DigiDoc.
As the name suggests, DigiDoc aims to meet all the needs users might have about digital signature
creation, handling and verification.
[…]
The DigiDoc library provides easy-to-use interfaces to all of the above and there is no need for application
developers to know OCSP protocol specifics or DigiDoc (XAdES, XML-DSIG) format internals. It can be
embedded in any application and on top of it, a COM interface has been implemented, making it easy to
add DigiDoc support to any Windows application supporting COM technology. A Java implementation and
webservice is also provided. DigiDoc architecture is presented in the figure below.
33
Preliminary Study on Mutual Recognition of
eSignatures for eGovernment applications
November 2007
However, providing the libraries, web service and formats was not enough because these do not add
value to end users without real applications. Although DigiDoc support is present in most Estonian
document management systems, some web sites dealing with documents etc, a couple of “standard”
end-user applications are also provided. DigiDoc Client is a Windows application that lets users simply
sign, verify and encrypt documents, and DigiDoc portal is an application that lets users do the same online
without the need to install any stand-alone software. Naturally, both are based on the same DigiDoc
library and thus fully compatible – signatures given in Client can be verified in portal and vice versa.”
This approach is particularly interesting because of the consistent distinction being made between the
e-signature components itself (the eID card, DigiDoc and the surrounding infrastructure) and the
applications making use of the signed documents. As a result, interoperability requirements become
easier to map than with solutions where specific applications have a larger impact on how signatures
are generated and/or processed.
As discussed extensively above, there are a number of Member States which presently rely mostly on
authentication mechanisms as a sufficient proxy for e-signature functionality in public sector
applications. The Netherlands, which currently relies largely on the DigiD system, is one example of
this approach.
34
Preliminary Study on Mutual Recognition of
eSignatures for eGovernment applications
November 2007
“DigiD stands for Digital Identity and is a system shared between cooperating governmental agencies,
allowing to digitally authenticate the identity of a person who applies for a transaction service via internet.
With increasing numbers of public authority offices implementing the DigiD system, it is easy to begin
using their range of electronic services after first choosing your own login code (user’s name and
password) at www.DigiD.nl. In short: DigiD provides users with a personalised login code for the full
spectrum of contact with various governmental bodies. Anyone with a Social Fiscal number (SOFI-
number) can apply for a DigiD.”
However, while the DigiD system is an authentication system relying only on a username/password,
this solution will be complemented in the future by an eID card know as eNIK. Similar to comparable
solutions such as the Belgian, Estonian, Finnish, Italian and Spanish ones, eNIK would contain
distinct certificates for authentication and e-signature functionality. While it is presently not yet known
which applications would require eNIK in the future and which would continue to support DigiD, it is
likely that at least some applications will require the use of actual signatures in the future.
The Finnish situation is interesting because it offers two very distinct solutions: either a FINEID
signature (based on a qualified certificate on a smart card), or the bank controlled Tupas
authentication system.
“Three different types of electronic signatures are predominantly used in eGovernment applications:
1. Signature applications based on the FINEID electronic identity card, which contains a qualified
certificate;
2. Signature applications based on the FINEID certificate card for organisation use (”organisation CA
certificates”) which contains a qualified certificate; and
3. TUPAS bank identification system.
The FINEID certificates are qualified signature certificates as specified in the relevant European Directive
and in the Finnish Act that implements the directive. For eGovernment applications the proportion of
qualified vs. Advanced certificates that are used for signing is not measurable since only FINEID and
Tupas based signature methods are offered in the services.
The Tupas system does not provide for qualified nor advanced signatures since it is a two-factor
password authentication method. Advanced certificates are not used in eGovernment services, even
though some are available (e.g. commercial SoneraCA certificates). The reasons for this are multiple and
they are described in more detail in section 6 of the report.”
35
Preliminary Study on Mutual Recognition of
eSignatures for eGovernment applications
November 2007
It is interesting to note that, despite to the division in functionality (with FINEID offering both signature
and authentication functionality, and TUPAS only offering authentication), both solutions are
commonly supported, without any clear system of preference.
While the Bulgarian EDESA (Electronic Documents and Electronic Signatures Act) globally follows
the provisions of the Directive, it is interesting to note that the baseline signatures concept is in fact
the advanced electronic signature of the Directive:
“According to Art. 13, Para. 1 of EDESA electronic signature is a data attached to the electronic
17
message (data message) in a way agreed between the author (the signatory) and the addressee
and enough secure for the needs of the turnover which:
• reveals the identity of the author (the signatory);
• reveals the consent of the author (the signatory) with the signed electronic message; and
• protects the content of the electronic message against any further changes.
The meaning of electronic signature under the Bulgarian EDESA is similar to the meaning of
advanced electronic signature under the Directive.”
Similarly, the Bulgarian advanced signature is in fact what the Directive labelled as a qualified
signature:
“The advanced electronic signature under EDESA could be equalled to the “qualified” electronic
signature under the meaning of art.5, para.1 of the eSignatures Directive.”
Finally, the signature type endorsed most frequently by the Bulgarian government (the so called
universal electronic signature) is an advanced signature relying on a qualified certificate. Thus, the
bar in Bulgaria is set relatively high, falling just short of a qualified signature (due to the lack of a
SSCD requirement).
In fact, the Austrian legislator took a similar approach, by retaining the qualified signature as the
fundamental notion (under the name of “secure electronic signature”):
17
The author is the natural person who makes the electronic statement – on his own behalf or on
behalf of a legal entity or another person as a proxy.
36
Preliminary Study on Mutual Recognition of
eSignatures for eGovernment applications
November 2007
Austrian legislation did not explicitly introduce the concept of advanced electronic signatures.
“Qualified” electronic signatures are however literally taken from the Directive by taking and
combining the definitions of advanced electronic signatures and the provisions of article 5 of the
Directive into a single definition. Qualified electronic signatures are referred to as “secure electronic
signatures” under Austrian legislation.
Certificate based systems incorporate a unique identifier in the signature certificate, which is often
derived from national registers, such as the national registry numbers for Belgium or Bulgaria (Unique
Citizen Number), the personal identification number based on the central personal number in
Denmark, or the tax number for Slovenia.
This presents a dual difficulty. First of all, this implies that such certificates cannot be issued to non-
nationals if such non-nationals cannot be entered into the national registers without a permanent
establishment, essentially barring them from using this specific e-signature solution (which is e.g. the
case in Belgium, Bulgaria, Denmark, Finland and Slovakia).
“At the moment only persons with a Danish [Central Personal Register]-number can have an OCES-
personal digital signature. The reason being that the registration and identification process is based
on a CPR-register. For the same reason only companies registered in the Danish central business
register can have an OCES employee- and/or company certificate.”
Furthermore, such unique identifiers may be under specific legal protection rules barring them from
being used or access without prior authorization (which is e.g. the case under Belgian and Danish
law). Thus, from a legal-technical perspective the use (including validation) of such signatures
requires the relying party (even if this is a public authority) to obtain prior clearance from a mandated
instance (e.g. a sector committee within the national Privacy Commission in the Belgian example).
37
Preliminary Study on Mutual Recognition of
eSignatures for eGovernment applications
November 2007
“The national registry number was originally intended to be used for public sector applications only.
As a result, only a limited number of institutions are allowed to use the national registry number in
their internal processes.
With regard to the use of electronic signatures in eGovernment applications, the national register
number is particularly relevant because it is used as the unique identifier in the certificate of the e -ID
card (but not in commercial ca certificates). Furthermore, the national register number is also
envisaged to become the identifier to be used in the future for all back-office information exchanges
in eGovernment applications regarding all persons who hold such a number.
Providers of e-ID applications are only allowed to use the national register number in certain cases
upon authorisation from a sector committee, which is a subdivision of the national privacy
commission. Only certain categories of authorities and instances qualify for this permission.”
A similar situation exists for the Danish OCES, where the signature certificate contains a non-
protected personal identification number (PID), which however can only be issued to a person having
a central personal register number (CPR). While CA services exist that can be used to map a PID to
the corresponding CPR, such services may only be used after mandate by law or after obtaining the
holder’s permission. Permission for private parties to process the personal identification number must
generally be granted by law.
“Note that the serial number field for personal certificates contains a person specific identification
number (PID), which uniquely refers to a person’s central personal identification number. Conversion
can be achieved through a CA service, which maps the PID and CPR numbers and which is
accessible only to authorities who by law are entitled to use the CPR or by explicit consent given by
the certificate holder.
[…]
For company certificates the serial number field contains the company’s business registration
number, which can be concatenated with different qualifiers, denominating different departments in
the company. These numbers can be used by applications to uniquely identify a given company or
department of a company.
[…]
The [Act on the Civil Registration System] states that all Danish citizens are provided with a personal
identification number. The personal identification number may be handed over to public authorities in
compliance with the Danish Act on processing of personal data. Private parties are in general not
entitled to request personal identification numbers from the CPR-register. Public authorities who are
in possession of personal identification numbers are not entitled to make the personal identification
numbers public available.”
38
Preliminary Study on Mutual Recognition of
eSignatures for eGovernment applications
November 2007
The combination of these two factors constitutes an additional legal barrier to cross-border use of e-
signature solutions, since foreign national bodies would not be allowed to access such unique
identifiers either without prior authorisation. It is of course prohibitively difficult for each foreign relying
party to obtain such clearances.
For this reason, alternative solutions exist in many countries. Referring back to the Belgian model, the
unique identifier is only included in the national eID card signature certificate, but not in the software
certificates provided by private sector CSPs (who do not have automatic clearance to include such
identifiers in their certificates). Thus, no clearance is required for the use of these certificates, and
they can be issued to non-nationals.
“It should be noted that the three recognised certification authorities can also offer their certificates
to foreign entities, and that no generic standards have been put in place to accept certificates issued
by other entities. From an interoperability perspective, this means that any user of an application
requiring commercial ca certificates is limited to these providers; no other certification service
providers qualify.”
Additionally, certain countries choose to issue separate eID cards (without protected unique
identifiers) to non-nationals, or are looking at encrypting/hashing the protected identifier into a
separate number, equally unique but unlinkable to the original. Both solutions thus present a technical
solution (or at least a workaround) to the legal problem of protected identifiers. To some extent this
approach is followed in Slovenia, where the tax number need not be directly included in the
certificate, but can merely be referred to through a separate CSP-specific unique identifier:
“Certification Authorities in Slovenia use different approaches in mapping single certificate with its
holder’s identification data (i.e. tax number) but all of them manage some connection between the
user and his certificate. Some Certification Authorities simply add the tax ID number in certificates,
while others add a unique certificate identification (serial number) to a certificate and keep all the
data in a stand-alone database. Personal data in this database can only be used under conditions
regulated in the Personal Data Protection Act.”
Similarly, the Finnish FINEID uses a so-called FINUID, which is available to non-nationals. However,
the FINUID is derived from the social security number, so that only non-nationals with a permanent
establishment in Finland would qualify:
“FINEID eSignature applications are available for all Finnish nationals and foreign permanent residents.
39
Preliminary Study on Mutual Recognition of
eSignatures for eGovernment applications
November 2007
All permanent residents, regardless of citizenship are able to receive a FINEID card with citizen certificate
and to use all available eGovernment services making use of it. The only limitation of the permanent
resident FINEID is in the physical card, which in this case does not constitute an ICAO travel document.
All permanent residents are covered by National Social Security, which provides for the SSN, which in
turn is automatically transformed into a FINUID that will be activated when a FINEID is issued. Asylum
seekers, tourists or other non permanent foreign residents are not allowed to receive a FINEID card or
citizen certificate.
[…]
The FINUID is a serial number (unique identification number) and a check sign identifying Finnish citizens
and foreign citizens residing permanently in Finland in accordance with the Municipality of Residence Act
who have been entered in the Population Information System.
The FINUID is included in the FINEID citizen certificate in two areas: as part of the certificate holder’s
Distinguished Name (DN) and as Serial Number (SN). The legal framework for the use of the Finnish
unique identification number is laid down in The Personal Data File Act (523/1999).
The origin of the FINUID is tied to the privacy concerns related to the use of the Social Security Number
(SSN). The legislation sought the use of the SSN in publicly accessible directory services – a serious
privacy concern that should be avoided. The public FINUID contained in the FINEID is of no use outside
the FINEID framework, thus making void any privacy concerns.
The FINUID provides the citizen with a code that serves as reference to the population registry system
containing information on the user. The PRC owns, creates and controls the FINUID, but other
organisations may use it for user identification purposes.”
It should be noted though that such solutions have of course not (yet) been implemented globally,
including e.g. in Bulgaria.
A more advanced approach was taken in Austria, where each entity is identified through an identity
link, which refers to data in official registers, including a separate register for non-nationals:
“The SourcePIN Register Regulation defines the activities of the SourcePIN Register Authority that
are necessary to implement the citizen card concept and the cooperation with its service providers.
This includes the creation of an identity link which is a separate data structure on the citizen card to
establish a link between an electronic signature and the unique identity of the citizen derived from
central registers (for natural persons the Central Register of Residents and a Supplementary
Register for Natural Persons). An identity management system allowing for integrating alien eIDs
has been defined using so-called recurring identities.
[…]
For natural persons not registered in Austria (e.g., expatriates, cross-border commuters, foreigners),
a Supplementary Register for Natural Persons is defined in the Supplementary Register Regulation.
Unique identification is maintained when a person’s data is moved between the Central Register of
Residents and the Supplementary Register for Natural Persons (e.g., being enrolled in the
Supplementary Register and then taking residence in Austria).
[…]
Identification of legal persons is carried out via the Register of Company Names, the Central
Register of Associations, or the Supplementary Register of Other Concerned Parties. The identifier
of these registers is used as sourcePIN – the encryption step carried by the SourcePIN Register
40
Preliminary Study on Mutual Recognition of
eSignatures for eGovernment applications
November 2007
Thus, a model was created that permits a resolution of the problem of unique identifiers while
permitting cross border functionality (provided of course that an entity is willing and able to enter its
information in an Austrian official register).
Yet, even in cases where an unprotected unique identifier originating from a private sector CSP are
used as an identification method, issues can arise:
“Qualified and unqualified certification authorities issue electronic identifiers to individual persons (they are
not the same as eIDs mentioned in 4.2.1, and issued by appropriate public administration organs). Usually
these identifiers are Integrated Circuit Cards with cryptocontroller and private cryptographic keys and
public key certificates installed inside (obligatory solution used by qualified CAs) or software based tokens
(cryptographic keys and certificates stored outside ICC’s cryptographic modules).
[…]
Let us notice that commercial electronic IDs do not allow unambiguous assignment of a unique identifier to
the person – every CA has its own policy for electronic ID configuration. It is the main reason why they
cannot be used as national electronic IDs.”
It is interesting to note that regulations focus exclusively on the qualities to be exhibited by the
signature technology, but not on the medium itself. For example, the Belgian solution primarily
focuses on the national eID cards and on private sector certificates, but makes no statement for the
latter on the medium to be used. Thus, it is possible to obtain software certificates (to be installed in a
browser or kept separately, e.g. on a memory stick) or to receive a smart card containing this
certificate.
For instance, the Danish OCES is available in software certificate form, or on a smart card; and the
aforementioned Austrian solution is characterised as a “concept”, since there is no restriction to the
medium being used as a token (if indeed any material token is used at all).
While this issue will be more extensively dealt with in the section 5 of this report, a few summary
observations can already be made at this stage.
It is worth reiterating that the use of unique identifiers which are specific to one country (e.g. national
register numbers) and which may be subject to specific prior authorisations before use can have a
detrimental effect on cross-border interoperability of e-signatures, as explained above.
41
Preliminary Study on Mutual Recognition of
eSignatures for eGovernment applications
November 2007
One of the main conclusions of the initial analysis is that there is insufficient openness of
administrations towards non-national solutions which in combination make cross-border
interoperability extremely difficult.
Notably, there is a distinct tendency towards relying only on national solutions, either:
As a first observation, it is clear that national regulatory frameworks tend to maintain their
technological neutrality with regard to e-signature means. While the use of smart cards is clearly
gaining in prevalence (possibly due to the greater security potential and the resulting ease with which
a qualified signature could be generated), this evolution is not made explicit in national e-signature
regulations. In fact, as is most emphatically witnessed in the Austrian example, there is a clear and
increasing awareness of the importance of technological neutrality.
“The citizen card is a technology neutral concept that allows for a variety of implementations. A
number of token exists allowing the citizen the choice which token (or tokens) to activate as citizen
card. The major ones are the health insurance cards, each bank card, or each mobile phone.
18
Although the line can be difficult to draw when a CSP is a local branch of a foreign undertaking.
E.g., in the Netherlands, one of the accredited CSPs is ESG De Electronische Signatuur B.V.,
affiliated to the German ESG Elektronische Signatur GmbH.
42
Preliminary Study on Mutual Recognition of
eSignatures for eGovernment applications
November 2007
Integration of the various technologies is done via an open interface referred to as “Security Layer”.
Implementations as software for the citizen’s PC are available from two vendors for free. In case of
mobile phones as citizen card the interface provided on the Internet with no installation needed at
the PC, respectively.”
Rather, it would appear that the increasing attention to smart cards is primarily attributable to policy
changes with regard to national security. As the introduction of eID cards is contemplated, the
integration of e-signature capabilities is a logical extension of this strategy, which offers an added
value that can ease the acceptability of eID cards in countries where they are traditionally considered
controversial.
None the less, from a legal perspective, e-government regulations tend to specify high level
requirements without referring to the material carrier of the e-signature, which has the dual
consequence of increasing both technical flexibility (as specific technologies are not commonly
mandated) and interoperability complexities (as actual implementations may vary even within a given
country).
It is equally interesting to note that authentication mechanisms are used in many countries as a viable
alternative to actual e-signatures, since the required functionality can often be emulated in a sufficient
manner by such mechanisms. In certain countries, including the Netherlands, the UK and Malta,
authentication mechanisms are currently the dominant solution for signature issues, and in most other
countries authentication takes at least the role of a second tier solution.
While exceptions exist, it is noteworthy that most of the reports indicate that their national solution
frameworks have not been designed with cross-border interoperability in mind, and that no real
changes in this attitude are planned in the short term. In fact, national reports indicate that the notion
of interoperability has received some attention in the surveyed countries, but mostly in the context of
national harmonisation. In many countries, multiple e-signature solutions have been developed in
parallel and without internal coordination. In order to simplify this situation, internal harmonisation
initiatives are still underway in most countries in some form or other, such as the Belgian migration
towards the eID card as a general solution, the German trend towards a national eID framework, and
various central portal solutions, including in the UK and in Bulgaria.
“The available eGovernment applications (the information systems employed in the government
bodies) are not interoperable and are usually developed without an idea for being able to exchange
information with other applications.”
Furthermore, the common perception is that the business case for cross-border interoperability has
not been established, which is likely the main reason why it was not one of the design criteria from the
onset. None the less, there is an increasing awareness of the importance of cross-border functionality.
43
Preliminary Study on Mutual Recognition of
eSignatures for eGovernment applications
November 2007
“The OCES signature does not provide cross border functionality in its current form. In general this
applies to the eGovernment applications as such. The reason for this is probably a limited request
for such functionality for the time being combined with the fact that many of the applications are
providing services only relevant to Danish citizens (tax, health care and the like). More and more
demands coming from the implementation of different cross border solutions will increase the need
to address this challenge in the future.”
Given the scepticism with regard to the business case, it seems likely that external initiatives (e.g. in
the form of European intervention) may be required if any progress is to be made in the shorter term.
One recurring pattern in many national reports was the fact that long term validity of e-signatures and
the storage of signed documents / certificates has not received a great deal of governmental
attention, either from a regulatory or from a technical / organisational perspective. Regulatory
intervention is typically limited to the repetition of the provisions of the Directive insofar as they relate
to long term storage19, with a reference to the applicability of the CSPs Certification Practice
Statements for further details. Thus, direct legislative intervention is this regard is very limited,
although generic (not e-government specific) exceptions exist:
“Slovenia recently adopted new law on the electronic records with full legal effects, registration and
accreditation of equipment and service providers:
• Protection of Documents and Archives and Archival Institutions Act (Official Gazette of the
RS, No. 30/2006),
• Regulation on documentary and archival material custody (Official Gazette of the RS, No.
86/2006).
This regulation governs the activities and internal rules of persons keeping documents and/or
archives, storage of such materials in physical and digital form, general conditions, registration and
accreditation of digital storage equipment and services, selection and transfer of archives to public
archival institutions, processing and keeping registers of archives, protection of film and private
archives, use of archives in archival institutions and work of the Archival Commission.
With regards to the electronic signature it is obligatory to capture or generate all necessary meta-
data about the certificates related to the electronic signature or time stamp, additional data
confirming the same authenticity of captured materials in comparison with the original materials, date
of creation, data on capture procedure, data on hardware and software, in which a document unit
was created, etc. The regulation sates that in case authenticity and integrity of captured materials
19
E.g. in Annex II to the Directive, stating that all relevant information concerning a qualified
certificate must be stored “for an appropriate period of time, in particular for the purpose of providing
evidence of certification for the purposes of legal proceedings. Such recording may be done
electronically.”
44
Preliminary Study on Mutual Recognition of
eSignatures for eGovernment applications
November 2007
proved with contents, which are losing or have completely lost their value or have been annulated
with time (e.g. electronic signature, time stamp and similar), authenticity of captured materials in a
long-term digital preservation form shall be provided with strictly controlled addition of contents (e.g.
reliably added meta-data, re-signing of contents or a new time stamp), confirming authenticity of
captured materials. Such contents can be added on the level of individual units, group of units or
entire captured material.”
A few countries (e.g. Estonia) had more explicit provisions, although this was the exception rather
than the rule:
“SK runs secure logging system which logs all changes in certificate status (activation, suspension,
termination of suspension and revocation) and all validity confirmations given by OCSP responder. In
case logging procedure fails, then given transaction will not be completed. This princip le ensures
existence of log record in the system.
Log records are cryptographically linked to prevent insider attacks and forging log records (for
example backdating the log record). Once a month, cryptographic hash is printed in newspaper. Log
record database is backed up in timely basis with three copies stored in different locations.
Secure log is completely invisible to end-users with one exception – every ID-card holder can check
their personal records (certificate history and issued validity confirmations).”
While the surveyed countries do not appear to consider long term validity and storage of signed
electronic documents to be a key priority at this time, it is none the less important to highlight a
number of important issues.
First of all, apart from the legal issues, it is clear that the readability of electronic documents (both by
implementing sufficient security and back-up policies and by opting for file formats that guarantee
45
Preliminary Study on Mutual Recognition of
eSignatures for eGovernment applications
November 2007
long term accessibility) in general should be a policy priority in all eGovernment decisions. Situations
such as vendor lock-in or obsolescence of ageing equipment or file formats are irreconcilable with the
requirements incumbent on governments as a part of their good administrative governance
obligations. However, as such, this issue is not related to electronic signatures, and therefore falls
outside the scope of this study.
Specifically with regard to electronic signatures, it is important to note that the eSignatures Directive
does not contain any specific requirements with regard to the obligation of CSPs to retain signature
related data for any specific amount of time. Indeed, the issue is only tangentially referred to in Annex
II of the Directive:
“ANNEX II – Requirements for certification-service-providers issuing qualified certificates
Certification-service-providers must:
[..]
(i) record all relevant information concerning a qualified certificate for an appropriate period of
time, in particular for the purpose of providing evidence of certification for the purposes
of legal proceedings. Such recording may be done electronically;
[..]”
Thus, the Directive only prescribes a general obligation on the issuers of qualified certificates to
record all relevant information ‘for an appropriate amount of time’. This presents a number of clear
difficulties.
• First of all, the Directive does not specify which information exactly is ‘relevant’ to ensure the
long term validity of electronic signatures, and leaves it up to the CSPs (or Member States, if
they desire) to regulate this issue further.
• Secondly, the Directive only requires this information to be stored ‘for an appropriate amount
of time’; a notion which is to be interpreted keeping into account the possible need to rely on
electronically signed documents in legal proceedings. This offers little tangible help to CSPs,
as the validity of a document and the period during which it may be relevant in legal
proceedings can span almost all possibilities, from several days to several decades (e.g. for
contracts of an unlimited duration).
From an eGovernment perspective this can be particularly problematic, as administrative
regulations can often be extremely complex in this regard, and ostensibly similar types of
documents may be subject to vastly different rules with regard to the duration of their validity
and the period in time during which they may be disputed or relied upon in administrative or
civil proceedings. In short, even for CSPs issuing qualified certificates it is virtually impossible
to foresee precisely how much time is reasonable to ensure long term validity of a signature.
• This problem is exacerbated in a cross border context. For instance, in a specific Member
State a limited validity of e.g. five years may be sufficient for a specific document type (e.g.
an attestation of compliance with direct tax obligations), However, it is possible that an entity
is called upon after this period (e.g. after 7 years) to present such a document before a
different administration which has instated a longer validity period (e.g. 10 years), and as a
result, it will no longer be possible to validate the signature on the original document. This
need not be a problem in the case of easily replaceable document (e.g. one might imagine in
the present example that a tax administration might still be able to attest to an entity’s
compliance with tax regulations 7 years ago through a new attestation). However, this will not
always be the case. Sometimes, the requested information may no longer be available, and
no new electronic document can be created anymore.
From a practical perspective, this scenario is unlikely, as is demonstrated by the lack of
concern seen in the country profiles. None the less, the increasing uptake of electronic
signatures ensures that this problem will manifest itself in the future. It is therefore important
46
Preliminary Study on Mutual Recognition of
eSignatures for eGovernment applications
November 2007
that both signatories and recipients should be able to verify easily for how long any given
signature will remain verifiable. A simple referral to whatever CPS has been adopted by the
chosen CSP may not prove to be a sufficient answer, particularly in a cross border context,
where the required information may simply be linguistically inaccessible.
• Furthermore, the guidelines provided in the eSignatures Directive are only applicable to
CSPs issuing qualified certificates. For non-qualified signature certificates or non-PKI
signature solutions, no guidelines with regard to long term validity exist, so that signatories
and relying parties are entirely dependent on the local applicable legal framework. The same
goes for solutions which rely entirely on an authentication mechanism rather than on a
signature solution covered by the directive: in this case, the legal framework with regard to
legal signatures does not apply, and it is unlikely that a specific legal framework has been
created that is specifically targeted towards the long term validity of electronic documents
submitted through a secured electronic communications channel after a suitable
authentication procedure. In such cases, the parties will likely be entirely dependent on
applicable doctrine and jurisprudence, which will offer little to no legal certainty.
However, it is also important not to overstate these issues. As noted above, the matter of long term
storage and validity receives relatively little attention in practice, which is indicative of the fact that for
most applications this is not a major issue. For instance, in eProcurement procedures the validity of
an offer is only relevant until the expiration of the period in which a granted contract can be disputed;
after this period, only the final contract itself is legally relevant. While such periods obviously vary
from country to country, it is doubtful that they extend over a period of several years, given the need
for public service continuity and legal certainty when performing public sector contracts. Similarly,
income tax declarations are only relevant until a final tax has been established based on the contents
of the declaration and the period of contestation has expired, which is again unlikely to span several
years. Finally, for official certificates (e.g. birth certificates) and attestations (e.g. attestation of
domicile) it is often possible (and even required) to present current documents only, so that long term
validity is much less of an issue.
In summary, the country reports show that, at least with regard to electronic documents being used in
eGovernment applications, the surveyed countries take a very pragmatic approach, looking at the
needs of the application rather than at any abstract principles. None the less, it is important to be
aware that long term storage and validity will become an issue before long, and that no readily
available solution for the issues mentioned above seems to exist.
The analysis of various eGovernment applications (approximately 130) described in the Country
Profiles has allowed for establishing a grouping of those applications based on similarities shared by
them.
Two main groups of applications have been identified:
• on one side, applications that have a shared-service approach, meaning that they are making
use of a common framework or of a common infrastructure;
• on the other side, applications that have an ad-hoc approach, meaning that they are built up
from scratch implementing e.g. their own signature functions or even their own certification
authority.
Obviously, there are applications that are more difficult to class because they refer to several models.
The next sections will describe the models with full details.
47
Preliminary Study on Mutual Recognition of
eSignatures for eGovernment applications
November 2007
The first group concerns countries that have set-up a shared approach in the design of their
applications either by providing a one-stop shop infrastructure (Model 1) or by providing a common
framework for the use of eSignatures (Model 2).
There are several commonalities observed that are applicable to both models of this group.
Technical aspects:
eSignature type: None of the two models impose a specific eSignature type. The
eSignatures used can be either of type Simple, Advanced or Qualified.
Credential or token type: Applications of this first group (shared approach) do not impose
any type of token or credential because they are by design opened to support the largest
possible range of token/credential. These can be smart-card (eID card …) – USB Token –
virtual smart-card (the signature creation data is held within a central location (e.g. central
hardware security modules)), software certificates, user/password, one-time passwords
(OTP). …
eSignature validation: one of the main advantages of this shared approach resides in the
validation of eSignatures being realised either by a central module of the portal (in case of
model 1) or by using common libraries provided by the framework (model 2). In both cases,
the goal is to hide the validation complexity to the application. Applications do not need to
know how much Certification Service Providers are involved, neither what type of validation
protocols (CRLs, OCSP …) is provided by the CSP
Organisational aspects:
CSPs: as said previously, while choosing a shared approach, one of the implicit results is that
many CSPs can be easily provided to the applications.
Interoperability aspects
As far as interoperability is concerned, applications designed around one of these two models
are obviously more easily adaptable to provide true eSignature interoperability at validation
level as this has only to be achieved in one central place (being the portal or within the
framework).
The one-stop shop model is usually provided at country level but it happen that sometimes, this
approach is used at a sector level.
The one-stop shop model is designed to facilitate the efficient provision of on-line services in a cost-
effective manner. It enables government organisations to focus on the rapid delivery of on-line
services, rather than in building time and time again the common underlying components required for
on-line services
It enables citizens, businesses, intermediaries and even other government organisations to
communicate with the Government from a single point of entry.
48
Preliminary Study on Mutual Recognition of
eSignatures for eGovernment applications
November 2007
Portal ID Management
Citizen_________________Application
eSignature
Besides aspects described at group level, there are features that are specifically bound to this model.
Among them:
Technical aspects specific to this model:
Access methods: The main advantage of this model is to provide a unified access method
to the various eGovernment applications via web browser or web services (relying on
international de-facto standards such OASIS WS-Security20). Communications between the
portal and the final applications are XML-based.
National Interoperability Framework: one e-government Interoperability Framework defines
the technical policies and specifications governing information flows across government and
the public sector.
Authentication: One centralised authentication module at portal level providing several
authentication levels (e.g.: level 1: user/password, level 2: one-time passwords, level 3:
certificate based).
Note: Countries having federated several eGovernment applications in one portal approach may also
have applications based on other model (due to specific security or functional requirements).
20
This is an OASIS (http://www.oasis-open.org/) Standard document produced by the Web Services
Security Technical Committee. It proposes a standard set of SOAP extensions that can be used when
building secure Web services to implement message content integrity and confidentiality.
49
Preliminary Study on Mutual Recognition of
eSignatures for eGovernment applications
November 2007
Technical trends
All applications belonging to this model have defined a common set of XML documents to be
exchanged. This set of documents is always a part of the specification of a common
framework.
All applications require that the electronic signature is applied to a XML document defined
into the framework.
No other technical trends can be deduced from the low number (3) of applications belonging
to this model.
Very often, eSignature frameworks have been introduced to allow for rapid deployment of
eGovernment applications by providing eSignature primitives such as certificate validation, card
access (CSP, PKCS#11) …
Such framework may results from national legal provisions or national initiatives to support a specific
eSociety policy (e.g. introduction of the eID card).
Besides the features described at the group level, there are features specific to this model:
Technical aspects specific to this model:
Access method: Even if the major part of the applications related to this model has web-
based interfaces, there are usually no requirements imposed by the framework.
National Interoperability Framework: there is no national interoperability framework defined
or it has not yet been implemented.
Authentication: Although that authentication is application-specific, the framework provides
certificate-based authentication functions.
50
Preliminary Study on Mutual Recognition of
eSignatures for eGovernment applications
November 2007
eSignature framework
Technical trends
The type of signature which detaches clearly of the general tendency is "qualified". This fact is not
astonishing because the applications which are classified in this model rely in general on a framework
which has been set up for a national electronic identity card which requires a signature type
"qualified". However the type of signature "advanced" is always quite present.
The figure below represents the signature type support by applications belonging to this model.
4 applications support Simple signature type – 8 applications support advanced signature type – 5
applications support qualified certificate - 16 applications support "qualified" signature type.
51
Preliminary Study on Mutual Recognition of
eSignatures for eGovernment applications
November 2007
Signature type
20
15
10
0
si mpl e adv anc ed Qual i f i ed cer t i f i cat e Qual i f i ed s i gnat ur e
Applications relying to this model have stated that they support multiple type of token but the most
supported one is the Smart card.
The figure below represents the token type support by applications belonging to this model.
Token type
30
25
20
15
10
5
Applications sign or required that specific documents type are signed. Some of them support different
type of signed document but this not a general trend.
The figure below represents the trend for application belonging to this model (“files” means not PDF
and not XML file type).
52
Preliminary Study on Mutual Recognition of
eSignatures for eGovernment applications
November 2007
4,5
4
3,5
3
2,5
2
1,5
1
0,5
0
XML PDF Web-Form files ASCII
The figure below represents the usage of signing tool type used by applications belonging to this
model.
Signing tool
7
6
5
4
3
2
1
0
Adobe Acrobat Applet/ActiveX eMail client other tools
53
Preliminary Study on Mutual Recognition of
eSignatures for eGovernment applications
November 2007
Bulgaria “Online submission of annual income tax declarations” and “VAT on Internet”
applications:
Question: “What are the software requirements on the client side (e.g. OS/specific
driver/middleware) for the use of eSignature?”
Answer: “…For the purposes of signing in .p7s format of the files that are to be attached,
a particular software DSTOOL is used. This software is freely downloadable from the
website of NIA....”
Italy “Telemaco, Signed Electronic Filing for Business Entities –Balance Sheets”
application:
Question: “What are the software requirements on the client side (e.g. OS/specific
driver/middleware) for the use of eSignature?”
Answer: “A software to sign the electronic declaration according to the Italian laws.
“Dike” is the InfoCamere free software for the digital signature available for Windows,
Mac platforms and a Linux distribution….”
There are numerous applications described in the country profiles that do not make use of a central
architecture nor of a common framework, mainly for historical reasons. They have been classified
under this second ‘ad-hoc’ group. Within this group, one can however distinguish two different
models: stand-alone applications that can interact with various external CSPs or stand-alone
applications that have set-up their own CSP inside the application.
There are several commonalities observed that are applicable to both models of this group.
Technical aspects:
Access method: Even if the major part of the applications related to this group has web-
based interfaces, access methods are defined by the applications themselves.
National Interoperability Framework: Applications are not compliant to a National
Interoperability framework (when existing).
Authentication: Specific to the application: user/password, one-time password, certificate-
based authentication...
54
Preliminary Study on Mutual Recognition of
eSignatures for eGovernment applications
November 2007
CSP’s CSP’s
55
Preliminary Study on Mutual Recognition of
eSignatures for eGovernment applications
November 2007
Technical trends
The figure below represents the signature type support by applications belonging to this model.
1 application support Simple signature type – 17 applications support advanced signature type – 34
applications support qualified certificate - 8 applications support "qualified" signature type.
Signature type
40
35
30
25
20
15
10
5
0
si mpl e advanced Qual if i ed cer ti f icate Qual if i ed si gnatur e
56
Preliminary Study on Mutual Recognition of
eSignatures for eGovernment applications
November 2007
Applications relying to this model have stated that they support multiple type of token but the most
supported one is the Smart card.
The figure below represents the token type support by applications belonging to this model.
Token type
50
40
30
20
10
0
user / pass sof t USB Smar t Car d Vir tual Smar t
Car d
Applications sign or required that specific documents type are signed. Some of them support different
type of signed document but this not a general trends.
The figure below represents the trend for application belonging to this model (“files” means not PDF
and not XML file type).
14
12
10
8
6
4
2
0
XML PDF Web-Form files ASCII
The figure below represents the usage of signing tool type used by applications belonging to this
model.
57
Preliminary Study on Mutual Recognition of
eSignatures for eGovernment applications
November 2007
Signing tool
25
20
15
10
0
Adobe Acrobat Applet/ActiveX eMail client other tools
Question: “What are the software requirements on the client side (e.g. OS/specific
driver/middleware) for the use of eSignature?”
Answer: “…On-line version works only on Internet Explorer 6.0 XML602 Filler woks only
on Windows....”
Question: “What are the software requirements on the client side (e.g. OS/specific
driver/middleware) for the use of eSignature?”
58
Preliminary Study on Mutual Recognition of
eSignatures for eGovernment applications
November 2007
Like the previous model, this one is also implemented for two main reasons:
• Either, for historical reasons: no national framework / model existed at application
development time;
• Or application specific security/ functional requirements could not be met by national
framework/model.
The major difference between this model and the previous one is that applications of this category
have no intention to open themselves to external CSPs.
Application Application
CSP CSP
59
Preliminary Study on Mutual Recognition of
eSignatures for eGovernment applications
November 2007
Technical trends
The figure below represents the signature type support by applications belonging to this model.
3 application support Simple signature type – 4 applications support advanced signature type.
Signature type
The figure below represents the token type support by applications belonging to this model.
60
Preliminary Study on Mutual Recognition of
eSignatures for eGovernment applications
November 2007
Token type
Applications sign or required that specific documents type are signed. Some of them support different
type of signed document but this not a general trends.
The figure below represents the trend for application belonging to this model (“files” means not PDF
and not XML file type).
2,5
1,5
0,5
0
XM L PDF Web-Form files ASCII
61
Preliminary Study on Mutual Recognition of
eSignatures for eGovernment applications
November 2007
The figure below represents the usage of signing tool type used by applications belonging to this
model.
Signing tool
2,5
1,5
0,5
0
Adobe Acrobat Applet/ActiveX eMail client other tools
Italy “Project CRS-SISS (Carta Regionale dei Servizi – Sistema Informativo Socio
Sanitario) » application:
Question: “What are the software requirements on the client side (e.g. OS/specific
driver/middleware) for the use of eSignature?”
4.2.2.1 Introduction
Among the 127 eGovernment applications described in detail in the annexes (Annex C) of the
Country Profile collected for the 29 countries concerned by the study (27 Member States Countries +
2 Candidate Countries (Turkey and Croatia)), we have found 90 applications that make use of
eSignatures.
The remaining 37 ones are mainly using electronic certificates for achieving strong authentication but
not for signing any documents in the sense of Article 2.1 of the EC Directive on a Community
framework for electronic signatures ([RD3]) that defines ‘electronic signature’ as data in electronic
form which are attached to or logically associated with other electronic data and which serve as a
method of authentication.
62
Preliminary Study on Mutual Recognition of
eSignatures for eGovernment applications
November 2007
The following figure illustrates how many applications, among the 90 concerned applications, are
belonging to one of the four models presented in the previous section (see section 4.2.1).
8% 3%
30%
Model 1
Model 2
Model 3
Model 4
59%
Without surprise, we noted that two thirds of these applications have followed an ad-hoc approach as
defined above (see section 4.2.1.2).
However, the trend is clearly to unify the way how applications are implementing electronic signatures
in order to allow for better interoperability in the country itself, e.g. by setting-up a National
Interoperability Framework.
63
Preliminary Study on Mutual Recognition of
eSignatures for eGovernment applications
November 2007
The “Government Gateway” portal, officially, only supports access by a client with a Microsoft
Operating System and a Microsoft Internet Browser.
Question: “What are the software requirements on the client side (e.g. OS/specific
driver/middleware) for the use of eSignature?”
64
Preliminary Study on Mutual Recognition of
eSignatures for eGovernment applications
November 2007
65
Preliminary Study on Mutual Recognition of
eSignatures for eGovernment applications
November 2007
Applications use information coming from the signature certificate to uniquely identify the user. Most
of the time this information is a national or sectoral unique number.
Bulgaria “Online submission of annual income tax declarations” and “VAT on Internet”
applications:
Question: “What information is included in the certificate, and what is the role of this
information in the functioning of the application?”
Answer: “The main identification information concerning the user is included in the
certificate (including name, address, uniform citizen number (UCN) or uniform
identification code of BULSTAT, grounds for representation etc.). The application
extracts the identification data in order to identify the user from the certificate, but not
from the declared data. If the UCN or the BULSTAT codes are not available in the
certificate, the system will not accept the certificate.”
Question: “Is the system accessible to non-nationals, and if so, how? If not, can the
system be upgraded for cross-border interaction?”
Answer: “At the moment only persons with a Danish CPR-number can have an OCES-
personal digital signature. The reason being that the registration and identification
process is based on a CPR-register. For the same reason only companies registered in
the Danish central business register can have an OCES employee- and/or company
certificate. With regards to technology the OCES standard is based on international
standards and therefore could be upgraded for cross-border interaction. The challenge
lies in the unique identification of the certificate holder.”
Question: “What information is included in the certificate, and what is the role of this
information in the functioning of the application?”
Answer: “User identity: NIF (identification number), name and family name”
66
Preliminary Study on Mutual Recognition of
eSignatures for eGovernment applications
November 2007
Question: “What information is included in the certificate, and what is the role of this
information in the functioning of the application?”
Answer: “The certificate includes the name and the national registration number (DNI) in
order to authenticate the user.”
Question: “What information is included in the certificate, and what is the role of this
information in the functioning of the application?”
Answer: “Person ID number (“Codice Fiscale”), used to uniquely identify the subject”
Within this model the “Elektronische aangifte” application is the only one using a simple signature
framework (i.e.: the national DigiD framework). Other applications are using simple signature specific
to the application, advanced signature or signature based on qualified certificate.
Question: “Does the system rely on a simple / advanced / qualified / other signature?”
Answer: “DigiD is simple, the name password combination companies use to log in is
also simple. For companies using their own administrative software (or their consultants)
it is possible to make use of qualified signatures”
67
Preliminary Study on Mutual Recognition of
eSignatures for eGovernment applications
November 2007
Austria:
- “Since March 2004, each mobile phone can be activated as citizen card. Using the
administrative signature approach, the signature creation data is held by the mobile
phone service provider A1 using hardware security modules to protect the signature
creation data. A combination of one-time authorisation codes transmitted as SMS and
personal passwords of the signatory are used as activation codes. “
68
Preliminary Study on Mutual Recognition of
eSignatures for eGovernment applications
November 2007
69
Preliminary Study on Mutual Recognition of
eSignatures for eGovernment applications
November 2007
While the majority of the applications belonging to this model sign document/web forms with standard
tool (ActiveX control, java applet, Adobe Acrobat plug-in, smart card middleware) the two following
applications require the installation of specific software.
To sign document with the “Publication system on public contracts – publication subsystem
(eNotification)” application in the Czech Republic the user has to download and install the XML602
software.
70
Preliminary Study on Mutual Recognition of
eSignatures for eGovernment applications
November 2007
Answer: “Web interface – on-line forms, uploading of off-line forms filled in XML602 filler
or Adobe .PDF and XML interface”
To sign document with the “e-VAT (e-PDV)” application in Croatia the user has to download and
install specific software (57,9 MB in size).
“…the customer has to register electronic signature by the tax web site (http://www.porezna-
uprava.hr/e-porezna/OvlastenjaFull.asp) where appropriate software has to be downloaded and
installed. “
The following application is very typical: users can obtained their electronic certificate from any
Certification Service Provider, even those installed outside UK, but the certificate must contain a
specific value in one of the certificate field. This forbids the use of general-purpose electronic
certificate.
71
Preliminary Study on Mutual Recognition of
eSignatures for eGovernment applications
November 2007
Question: “Does the system rely on a simple / advanced / qualified / other signature?”
The “Electronic Declaration System (EDS)” application uses a proprietary key solution to sign
documents. The signed documents are in a non standard format (DUF – DBF).
72
Preliminary Study on Mutual Recognition of
eSignatures for eGovernment applications
November 2007
Question: “Does the system rely on a simple / advanced / qualified / other signature?”
Answer: “Currently the eSignature provided by the State Revenue Service is different
from the qualified electronic signature as provided according to the Electronic Documents
Law. Nevertheless, the State Revenue Service is ready to accept electronic documents
signed by the qualified electronic signature.”
Answer: “Data are entered into eXtensible Mark-up Language (XML) format and
processed in DUF, DBF formats.”
Answer: “When the user has filled in his declaration, he is prompted to click on the
button “sign and submit” which appears only if the person has the signatory rights. The
signature is created using the private key data automatically saved on the eSignature
creation directory in the computer of the user. The user is requested to indicate the
location of the private key data file.”
73
Preliminary Study on Mutual Recognition of
eSignatures for eGovernment applications
November 2007
This section provides a list of all the eGovernment applications grouped by country and then by
model.
It reflects that many countries are on the way of unifying their eGovernment approach from an ad-hoc
model to an integrated model sharing the same infrastructure or the same framework.
74
Preliminary Study on Mutual Recognition of
eSignatures for eGovernment applications
November 2007
75
Preliminary Study on Mutual Recognition of
eSignatures for eGovernment applications
November 2007
76
Preliminary Study on Mutual Recognition of
eSignatures for eGovernment applications
November 2007
As reported by the national correspondents, the following signature types, according to definitions
introduced at section 4.1.3.1.1, are required for existing eProcurement applications:
77
Preliminary Study on Mutual Recognition of
eSignatures for eGovernment applications
November 2007
78
Preliminary Study on Mutual Recognition of
eSignatures for eGovernment applications
November 2007
The following figure depicts the classification by model of applications belonging to this sector.
The clear domination of model 3 follows the trend observed at the European level.
eProcurement
Model 4 Model 1
8% 0%
Model 2
33%
Model 3
59%
Technical trends
The figure below represents the signature type support by applications belonging to this sector.
0 application support Simple signature type – 6 applications support advanced signature type – 4
applications support qualified certificate - 6 applications support "qualified" signature type.
Signature type
6
5
4
3
2
1
79
Preliminary Study on Mutual Recognition of
eSignatures for eGovernment applications
November 2007
The figure below represents the token type support by applications belonging to this sector.
Token type
4,5
4
3,5
3
2,5
2
1,5
1
0,5
0
user / pass sof t USB Smar t Car d Vi r tual Smar t
Car d
As reported by the national correspondents, the following signature types are required for existing
income tax declarations applications:
80
Preliminary Study on Mutual Recognition of
eSignatures for eGovernment applications
November 2007
81
Preliminary Study on Mutual Recognition of
eSignatures for eGovernment applications
November 2007
82
Preliminary Study on Mutual Recognition of
eSignatures for eGovernment applications
November 2007
83
Preliminary Study on Mutual Recognition of
eSignatures for eGovernment applications
November 2007
The following figure depicts the classification by model of applications belonging to this sector.
The general trend of European applications is not followed by applications belonging to this model.
We have the same number of model 2 and model 3 applications.
eTAX
Model 4 Model 1
12% 6%
Model 2
41%
Model 3
41%
Technical trends
The figure below represents the signature type support by applications belonging to this sector.
6 applications support Simple signature type – 5 applications support advanced signature type – 2
application supports qualified certificate - 9 applications support "qualified" signature type.
Signature type
10
0
si mpl e advanced Qual if i ed cer ti f icate Qual i f i ed si gnatur e
84
Preliminary Study on Mutual Recognition of
eSignatures for eGovernment applications
November 2007
The figure below represents the token type support by applications belonging to this sector.
Applications sign or required that specific documents type are signed. Some of them support different
type of signed document but this not a general trends.
The figure below represents the trend for application belonging to this sector (“files” means not PDF
and not XML file type).
0
XML PDF Web-Form f iles ASCII
85
Preliminary Study on Mutual Recognition of
eSignatures for eGovernment applications
November 2007
The figure below represents the usage of signing tool type used by applications belonging to this
model.
Signing tool
10
6
Series1
4
0
Adobe Acrobat Applet/ActiveX eMail client other tools
As reported by the national correspondents, the following signature types are required for existing
VAT applications:
86
Preliminary Study on Mutual Recognition of
eSignatures for eGovernment applications
November 2007
87
Preliminary Study on Mutual Recognition of
eSignatures for eGovernment applications
November 2007
88
Preliminary Study on Mutual Recognition of
eSignatures for eGovernment applications
November 2007
The following figure depicts the classification by model of applications belonging to this sector.
The clear domination of model 3 follows the trend observed at the European level.
89
Preliminary Study on Mutual Recognition of
eSignatures for eGovernment applications
November 2007
eVAT
Model 4 Model 1
14% 5%
Model 2
23%
Model 3
58%
Technical trends
The figure below represents the signature type support by applications belonging to this sector.
6 applications support Simple signature type – 5 applications support advanced signature type – 8
application supports qualified certificate - 6 applications support "qualified" signature type.
Signature type
10
0
s i mpl e advanc ed Qual i f i ed cer t i f i c at e Qual i f i ed s i gnat ur e
The figure below represents the token type support by applications belonging to this sector.
90
Preliminary Study on Mutual Recognition of
eSignatures for eGovernment applications
November 2007
Token type
14
12
10
8
6
4
2
0
user / pass sof t USB Smar t Car d Vi r tual Smar t
Car d
91
Preliminary Study on Mutual Recognition of
eSignatures for eGovernment applications
November 2007
5.1 Introduction
From the models defined at previous stage, an impact assessment of the similarities and differences
for the eGovernment applications identified is reported below. The most important interoperability
problems are listed.
5.2 Definitions
At the light of the various country profiles analysed, we have detected a slight difference in the
interpretation of concepts (Interoperability, Supervision …).
The next sections intend to clarify the definitions.
A majority of the surveyed countries have established a list of certification service providers,
recognized for issuing certificates to be used in e-government applications. Some of the countries
maintain one central list for all applications (France, for example) while others work with separate lists
per sector or even per application.
Various country profiles demonstrate that there is confusion between these lists (registered CSP for e-
government transactions) and the lists that are kept following article 3 of the European e-signature
Directive.
Article 3 of the Directive prohibits submitting the access to the market of certification services to any
form of prior authorization (explicitly or via a “de facto” system). On the other hand the Directive
requests the Member States to set up a system for “supervision”. Any CSP providing services to the
public and claiming that its certificates are “qualified” (fulfilling the requirements of the Annexes to the
Directive) should be supervised by a supervisory body. Most of the Member States have
implemented this requirement via a notification scheme: all CSPs issuing qualified certificates to the
public have to notify their activities to the supervisory body and automatically appear on a list of
“supervised” CSPs. Some of the surveyed countries apparently have decided that all of these
“supervised” CSPs are automatically recognized as suitable certification authorities for e-government
transactions.
Article 3 of the Directive mentions also the possibility to establish voluntary accreditation schemes.
The objective of these schemes is to provide service providers with a possibility to obtain a quality
label for their services. These voluntary accreditation schemes don’t exist in all Member States and
are sometimes organised by the private sector (for example in the UK).
Various country profiles show that governments also establish accreditation schemes in the e-
government context. These accreditation schemes are not voluntary because the accreditation is, in
most of the cases, obligatory in order to access the “market” for e-government applications. One the
discussions is whether these practices are compliant with Art. 3.7 of the Directive (the so-called
“public sector” clause).
5.2.2 Interoperability
At the European level, full interoperability means that an eGovernment application of a given Member
State should accept any electronic signatures sent by any natural or legal person from any Member
State even if the signature is created using credentials coming from non-national Certification Service
Providers (CSPs).
92
Preliminary Study on Mutual Recognition of
eSignatures for eGovernment applications
November 2007
As many applications rely only on CSPs accredited by their own national accreditation body21, full
interoperability would mean that either its own national accreditation body must be able to accredit
non-national CSPs or that multilateral agreements must be established between Accreditation Bodies
from various Member States (see also sections 4.1.1.2 and 4.1.3.4)
Among all surveyed applications, no application has been assessed as interoperable in the sense of
the above definition. However, some applications claim to be interoperable under some conditions
(see section 5.2.2.1).
Interoperability
CSP
eGov
User Application
Country X Country Y
21
The public or private body charged with the elaboration of, and supervision of compliance with,
rights and obligations specific to the provision of certification services (cfr [RD3], Art 2 §13),
93
Preliminary Study on Mutual Recognition of
eSignatures for eGovernment applications
November 2007
5.2.2.1 Examples
The following application is technically and organisationally ready to accept signature created by Non-
National certificate. A foreign CSP is accredited by National accreditation authority but regulations
amendments are still needed.
Question:” Is the system accessible to non-nationals, and if so, how? If not, can the
system be upgraded for cross-border interaction?”
Answer: “Yes the system is accessible also to non-nationals under condition, that
certificate has to be issued by Certification Authority accredited by NSA. For the full
access to the system (for the full cross-border interaction) is the amendment or
supplementation of the legislative required.”
Question:” What measures, if any, have been taken to ensure interoperability with
signatures created and/or certificates issued in other countries?”
Answer: “For interoperability insurance are a few measures needed. E.g. currently is one
Czech CSP accredited in Slovakia and on the basis of this accreditation are the qualified
certificates from this CSP recognised.”
The next application is technically ready to accept signature created by Non-National certificate but
regulations amendments are still needed.
Question:” What measures, if any, have been taken to ensure interoperability with
signatures created and/or certificates issued in other countries?”
Answer: “The technical integration of alien e-IDs has been completed (to date Belgian,
Estonian, Italian, and Finish eID), but is not yet in operational use (e.g., not yet activated
in MOA-ID identification and authentication services for operational services). The steps
to be taken technically are mainly the integration of the root certificates into the MOA
modules. Legally, the identification follows a concept referred to a “recurring identity”
which cannot be used for official delivery services. Amendments of the legal basis would
be needed.”
94
Preliminary Study on Mutual Recognition of
eSignatures for eGovernment applications
November 2007
Next application is also technically ready to accept signature created by Non-National certificate but
national procedures are in preparation.
Question:” What measures, if any, have been taken to ensure interoperability with
signatures created and/or certificates issued in other countries?”
5.2.3 Cross-border
As mentioned above, many applications rely only on CSPs accredited by their own national
Accreditation Authority. Said this, they claim anyway to be opened for cross-border use which means
that non-nationals must first apply for credentials to one of the accredited CSPs.
As soon as qualified certificates are concerned, this means that non-nationals must physically register
in the country where the application is deployed.
Among all surveyed applications, 20 applications have been assessed as opened for cross-border use
in the sense of the above definition but none of them accept a signature generated by a Non-National
certificate.
95
Preliminary Study on Mutual Recognition of
eSignatures for eGovernment applications
November 2007
Cross Border
CSP
eGov
User
Application
Country X Country Y
96
Preliminary Study on Mutual Recognition of
eSignatures for eGovernment applications
November 2007
5.2.3.1 Examples
This application from Latvia requires an agreement to be taken between Non-National citizen and the
administration to accept its electronic signature generated by a national certificate.
It is clearly a “cross-Border” application. But the necessary national/sectoral measures that have to be
taken to recognise signature created by foreign certificate, do not exist.
Question:” Is the system accessible to non-nationals, and if so, how? If not, can the
system be upgraded for cross-border interaction?”
Question:” Is What measures, if any, have been taken to ensure interoperability with
signatures created and/or certificates issued in other countries?”
Answer: “The State Revenue Service has not taken any measures to ensure
interoperability with signatures created and/or certificates issued in other countries.”
97
Preliminary Study on Mutual Recognition of
eSignatures for eGovernment applications
November 2007
The following applications can be used by Non-National citizens having a certificate issued by an
accredited National CSP. Applications owners are aware that they are not interoperable with foreign
signature and mention possible solutions to be created at the European level.
Question:” Is the system accessible to non-nationals, and if so, how? If not, can the
system be upgraded for cross-border interaction?”
Answer: “As the system is based on qualified signatures, it may accept qualified
certificate from other EU member states from the legal point of view. However, in order
to verify qualified signatures from other EU member states, there would be a need for an
authentic source of CA certificates of qualified CAs from each member states. Without
such an authentic source, it is not possible to verify certificates of foreign CAs from the
technical point of view.”
Question:” Is the system accessible to non-nationals, and if so, how? If not, can the
system be upgraded for cross-border interaction?”
Answer: “Yes. Currently, all the necessary for an authority or private company is the
online or offline registration. After that, applicant receives by e-mail an electronic
certificate issued by IGCTI for system usage.”
Question:” What measures, if any, have been taken to ensure interoperability with
signatures created and/or certificates issued in other countries?”
98
Preliminary Study on Mutual Recognition of
eSignatures for eGovernment applications
November 2007
The following applications are designed to allow interoperability of electronic signature but certificate
used for the creation of the electronic signature are limited to national one. This limitation comes from
the fact that there is no foreign accredited CSP.
Question:” Is the system accessible to non-nationals, and if so, how? If not, can the
system be upgraded for cross-border interaction?”
Answer: ”System is available (when significant) through web to anyone who owns a
valid (Italian so far) certificate and plays one of the aforementioned roles in the
university...”
Limiting the usage of certificate to the national one accredited by the Italian
Government.
99
Preliminary Study on Mutual Recognition of
eSignatures for eGovernment applications
November 2007
Question:” Is the system accessible to non-nationals, and if so, how? If not, can the
system be upgraded for cross-border interaction?”
Answer: ” Yes, if a foreign tenderer has a qualified electronic signature, the system will
be made accessible for this tenderer.”
Limiting the usage of certificate to the national one accredited by the Netherlands
Government.
The application is ready for cross-border but not for interoperability at the European level because of
missing National procedure to recognise signature created by Non-national certificate.
100
Preliminary Study on Mutual Recognition of
eSignatures for eGovernment applications
November 2007
Question:” Is the system accessible to non-nationals, and if so, how? If not, can the
system be upgraded for cross-border interaction?”
Answer: ”The applications from the information system on public contracts – publication
subsystem (hereinafter “ISPC-PS”) are accessible free through the web sites of the
provider (www.isvzus.cz). However non-nationals need qualified certificates to use these
kinds of applications (qualified certificate according to the e-signature directive) – if
qualified certificate is not issued in his country, user must get qualified certificate in other
country.”
Question:” What measures, if any, have been taken to ensure interoperability with
signatures created and/or certificates issued in other countries?”
There is a last definition that has been derived from the Country Profiles: use of applications by non-
nationals residing in the country where the application is provided. In that case, non-national residents
are usually ‘comparable’ to national ones. Usually, they can apply for credentials exactly as a
national. There are cases where this is not possible, e.g. because non-nationals are not provided with
a required unique identification number (e.g. in Denmark, Finland or Spain).
101
Preliminary Study on Mutual Recognition of
eSignatures for eGovernment applications
November 2007
Non-national residents
CSP
eGov
User Application
from Country X
Country Y
Among surveyed applications, there are 24 applications that claim to be opened to non-national
residents.
102
Preliminary Study on Mutual Recognition of
eSignatures for eGovernment applications
November 2007
Most of the surveyed countries, as far as they have adopted electronic signatures in their e-
government applications, have organised this feature without taking into account electronic signatures
created by companies and individuals in other countries. The regulatory, technical and organisational
framework is always organised from a strictly national perspective. In most of the cases this national
perspective is implicit. The application presumes that the user is a national living on the country’s
territory. All kinds of practical obstacles prevent other users to access and actually use the
application.
5.3.1.1.2 Assessment
The strictly national perspective of most of the e-signature applications in the e-government sphere
could be a temporary issue. Priority is first given to e-signature features for the large majority of the
users. Serving more marginal categories, such as the occasional users from other countries, is not
considered as a first priority.
103
Preliminary Study on Mutual Recognition of
eSignatures for eGovernment applications
November 2007
5.3.1.1.3 Recommendations
One of the key observations in relation to this issue is that the national perspective is partly the
consequence of the principle of subsidiarity, which to a large extent permits Member States to make
their own choices with regard to their e-Signature policies. Eliminating this principle is neither possible
nor desirable.
However, the study has identified that there appears to be a tendency among Member States to
overlook the fact that this principle is not without its limitations, and that it does not allow them to
restrict the free movement of services (in this case, offering signature solutions with cross border
legal validity) without solid grounds. As noted above, restricting the types of acceptable electronic
signature solutions is permissible under the e-Signatures Directive, provided that the chosen
‘requirements shall be objective, transparent, proportionate and non-discriminatory and shall relate
only to the specific characteristics of the application concerned. Such requirements may not
constitute an obstacle to cross-border services for citizens.’ In practice, Member States typically
accept only their pre-approved national solutions.
This situation is certainly understandable, given the fact that applications in practice are typically
developed based on specific needs, and administrations justifiably prefer to focus on solutions that
offer an optimal benefit to a large majority of the targeted user group, rather than emphasising equal
accessibility to all potential European users. This is certainly the case for applications developed on a
regional or communal level, where the resources needed to obtain significant interoperability may be
unavailable, and where the expenses incurred to achieve such a goal would often be disproportionate
to any realised benefit. Additionally, administrations could argue that a requirement to use a specific
signature solution is not an ‘additional requirement’ in the sense of article 3.7, but rather an additional
possibility being offered to the traditional paper based procedures. In that perception, an ‘additional
requirement’ would only exist if an application were to impose demands that went beyond the general
requirements in vogue in a specific Member States. However, the implication of this interpretation
would be a de facto complete exemption of public sector applications of the basic principles of non-
discrimination and equivalence embraced by the Directive.
Member States should therefore be reminded of the letter and spirit of the public sector clause
(RECO1), and especially the limitation that additional requirements may not constitute an obstacle to
cross border services for citizens. Infringement proceedings for non-compliance with the e-Signatures
Directive however do not seem in order, given the complexity of the issue and the lack of a common
technical solution which would allow Member States from a practical perspective to accept and
validate non-national e-Signatures.
Additionally, Member States should be reminded of their notification obligations under article 11,
which requires them to notify to the Commission and the other Member States of (inter alia)
information on national voluntary accreditation schemes, including any additional requirements
pursuant to Article 3(7) (the public sector clause):
“Article 11 – Notification
1. Member States shall notify to the Commission and the other Member States the following:
104
Preliminary Study on Mutual Recognition of
eSignatures for eGovernment applications
November 2007
However, we would not argue that the notification obligation should go so far as to require all
eSignature application providers to notify the supported signature solutions to the Commission. Such
an extensive interpretation would not be productive in improving the interoperability between national
systems, as it would flood the Commission with largely unusable information and impose an undue
burden on application providers who are attempting to improve their services for their users. Rather,
the notification obligation should be read as only pertaining to national voluntary accreditation
schemes, where the Member States who provide such schemes are also required to provide any
additional requirements pursuant to the public sector clause. I.e., the notification obligation of the
Member States with regard to additional requirements is a component of their general notification
obligations with regard to voluntary accreditation schemes, and not an autonomous obligation.
Member States should be reminded of the letter and spirit of the public sector clause (art. 3.7),
including their obligation in principle not to introduce requirements which constitute an obstacle to
cross-border services for citizens; and of their notification obligations under article 11 of the Directive
which require them to notify the Commission of any additional requirements imposed in application of
article 3.7 insofar as these are a part of any voluntary accreditation scheme. Member States must be
aware of the fact that the principles of non-discrimination and equivalence to handwritten signatures
should also apply to eGovernment applications, unless the public sector clause allows them to decide
otherwise. They must provide the Commission with the necessary information to support further
initiatives should the efforts of the Member States prove insufficient.
5.3.1.1.4 Conclusions
RECO1 Member States should be reminded of the letter and spirit of the public
sector clause (art. 3.7), including their obligation in principle not to
introduce requirements which constitute an obstacle to cross-border
services for citizens; and of their notification obligations under article 11
of the Directive which require them to notify the Commission of any
additional requirements imposed in application of article 3.7 insofar as
these are a part of any voluntary accreditation scheme.
Target group: Member States
For similar applications, Member States don’t necessarily require the same type of electronic
signature. It is perfectly possible that a similar application in one Member State is only based on user-
id/password protection while another Member State requires qualified electronic signatures for the
same type of transaction. One question is whether Member State should remain entirely free to
determine independently from each other the security level of signatures in their e-government
applications. Is it acceptable that public procurement transactions can be signed with user-
id/password based electronic signatures in one country while other countries require qualified
certificates and SSCDs in this context?
5.3.1.2.2 Assessment
It is probably not possible – but perhaps also not necessary - to harmonise the security level of
electronic signatures for each type of application. Does this mean, however, that every company and
105
Preliminary Study on Mutual Recognition of
eSignatures for eGovernment applications
November 2007
individual in every Member State will eventually need to have a complete set of electronic signature
facilities (at least including a qualified electronic signature facility)?
5.3.1.2.3 Recommendations
Similar to the issue noted above, the principle of subsidiarity and the public sector clause jointly imply
that Member States have the right to determine in principle which security level they require for each
specific application type (again, keeping in mind the limitations to this freedom in the public sector
clause, and also keeping in mind other and more far reaching harmonisation initiatives for specific
application types (such as the signature requirements for electronic invoicing). This right of the
Member States to autonomously determine the importance and security risks for each application and
the resulting signature requirements does not need to present any specific problem.
However, a larger concern is the current impossibility of ‘mapping’ non-national signature solutions
into a given security category. I.e., when presented with a non-national signature solution, a Member
State will typically have no way of determining how the signature was issued in the state of origin, and
therefore what kind of security/ reliability it provides. The issue then becomes a matter of trust in non-
national registration authority (RA) policies.
Apart from the recommendation above (reminding Member States of their obligations to notify the
Commission of restrictions in their e-Signature applications, which would result in a substantial
overview of accepted CSPs abroad), it is therefore important to inform application owners of the
signature solutions offered in other countries, and to take note of their obligation in principle to ensure
compatibility with equivalent signature solutions (RECO2). The final and long term goal would be to
enable application owners to define the signature needs of their applications in terms of a
security/reliability level, such as the appropriate legal classification under the eSignatures Directive,
rather than by assessing individual CSPs on a case by case basis. In short, application owners should
be able to shift from the current situation of ad hoc decisions for each application to a system where
they require a certain security/reliability level, rather than a specific certificate or CSP. (RECO3)
5.3.1.2.4 Conclusions
RECO2 Application owners should take note of signature solutions being used in
other countries as identified by this study, and be made aware of their
obligation in principle not to exclude foreign signature solutions
whenever possible, unless specific considerations meeting the criteria
of the public sector clause would permit this.
Target group: eGovernment application owner
RECO3 Application owners should be advised to shift from the current situation
of ad hoc decisions for each application, to a system where they require
their users to employ a certain security/reliability level, such as the
appropriate legal classification under the eSignatures Directive, rather
than a specific certificate or CSP.
Target group: eGovernment application owner
106
Preliminary Study on Mutual Recognition of
eSignatures for eGovernment applications
November 2007
Many Member States require certificates issued by “recognized” certification service providers. It is
questionable whether this is compliant with Article 3.1 of the European Directive 1999/93/EC, since
this could be construed as a requirement which is “de facto” equivalent to a prior authorisation.
5.3.1.3.2 Assessment
There seems to be a need (on a Community level) for an operational interpretation of the “public
sector clause” (Art. 3.7) of the European e-signature Directive.
5.3.1.3.3 Recommendations
Consideration (10) of the e-Signatures Directive explicitly defines prior authorisation as ‘any
permission whereby the certification-service-provider concerned has to obtain a decision by national
authorities before being allowed to provide its certification services, but also any other measures
having the same effect.’ When jointly read with the public sector clause, it appears that the systematic
restriction of access to public sector services to the potential clients of specific certification service
providers which are largely inaccessible to non-nationals is contrary to the goals of the Directive.
None the less, it should also be acknowledged that this situation within the Member States does not
appear to result from a desire to shield certain (national) CSPs from competition or to otherwise
restrict the free movement of services, but rather from the legitimate need to ensure that their
services are sufficiently secured against misuse. Furthermore, it is also true that no operational
solution for the cross border validation of electronic signatures originating from a virtually unlimited
number of CSPs has been put in place, and that Member States can hardly be faulted for not
developing such solutions.
Thus, it is our opinion that, while the present national situation is at odds with the goals of the
Signatures Directive, this cannot be considered a material violation of the Directive’s ban against
prior authorisation schemes.
5.3.1.3.4 Conclusions
No further steps are in our opinion recommended at this stage for this particular issue.
Not all Member States have adopted a general all-encompassing central strategy with regard to
electronic signatures in e-government applications. There are many ad-hoc solutions and regulations
in this domain. This fragmentation can possibly hinder future interoperability initiatives.
5.3.1.4.2 Assessment
This might be a temporary issue. In most of the surveyed countries the sectoral “ad hoc” approach
seems to be a first phase in the development of transactional e-government services. Sectoral “ad
hoc” solutions are implemented because there is not yet a clear strategy on the national level.
107
Preliminary Study on Mutual Recognition of
eSignatures for eGovernment applications
November 2007
5.3.1.4.3 Recommendations
In our opinion, no corrective action in this regard is necessary. While it is true that national diversity
between e-government applications currently exists and will likely continue to exist for some time, it is
important to note that all Member States acknowledge that a lack of internal interoperability is a
serious handicap that needs to be eliminated. In short, while the existence of ad hoc solutions can be
a barrier to cross border interoperability, Member States are by and large acting to remedy this
situation, so that no further action seems necessary.
It should also be noted (as has been stressed in section 4.1.2.1.3 and 4.1.2.1.4 above) that ad hoc
solutions in some cases have been inspired and are maintained by a conscious decision to implement
a solution that most closely meets the needs of a (typically limited and specialised) user base. In such
cases, it has been deemed more important to cater to the needs of the actual user group, rather than
to implement a generic solution which is of little use to the vast majority of the users of this solution.
In our opinion, such restrictive practices are in compliance with the public sector clause, since the
requirements are ‘objective, transparent, proportionate and non-discriminatory and [...] relate only to
the specific characteristics of the application concerned’ (article 3.7 of the Directive).
5.3.1.4.4 Conclusions
No further steps are in our opinion recommended at this stage for this particular issue.
Usage of electronic signatures in e-government applications is not only regulated and organised on a
national level but often on a regional or local level. This factor should be taken into account in future
interoperability initiatives in this area.
5.3.1.5.2 Assessment
As the decentralisation of certain competences is a legal reality in many Member States, specific
initiatives in this field are neither warranted nor necessary. For interoperability purposes, it is
sufficient to ensure that the Member States are aware that any obligations in the Directive and any
recommendations in this report which are directly incumbent on them also affect any decentralised
administrations in the same manner. In other words, Member States must ensure that their
decentralised administrations observe their duties equally. (RECO4)
5.3.1.5.4 Conclusions
108
Preliminary Study on Mutual Recognition of
eSignatures for eGovernment applications
November 2007
Member States should be made conscious of the fact that their possible
national decentralisation of competences does not absolve them of their
obligations of adhering to the eSignatures Directive’s provisions, which
RECO4 includes the obligation of ensuring that local governments adhere to this
framework.
Target group: Member States
Electronic signatures are frequently linked to national unique identifiers. They are used to initiate the
process for the application of a certificate or inserted in the subject field of the certificate. The
processing of these unique identifiers is sometimes strictly regulated (e.g. reserved for designated
authorities or service providers). The current national rules in this domain don’t take into account
processing by public authorities or service providers of other Member States.
5.3.1.6.2 Assessment
Solutions have to be developed in the framework of e-ID interoperability. These will most probably
include legislative amendments in some of the surveyed countries.
5.3.1.7 Conclusions
From a pragmatic perspective, the two most significant legal issues are the national perspective in
signature solutions, and the difficulty of ‘mapping’ signature security requirements.
The first issue is the most fundamental one: when making eSignature applications available, the rules
regarding its use (regardless of the form they take) typically specify that only one or several specific
signature solutions are acceptable, to the exclusion of any others, with the chosen solutions typically
only being practically available to users residing or established within that country’s borders. This
practice is tantamount to prior authorisation, as it excludes any other signature solutions (which
almost invariably includes all non-national solutions), regardless of their reliability and security
requirements. In other words: signatures are not accepted or rejected based on their actual merits, but
based on a policy decision. While this policy decision is usually based on valid pragmatic
considerations (particularly the existence of an interoperable validation and assessment mechanism
for non-national signatures), this practically makes signature interoperability impossible.
The second problem goes to the underlying reason for these restrictions: even if Member States want
to accept non-national signature solutions, they are presently required to assess their security on a
case-by-case basis. This is an impossible task from a practical perspective, as it would require
application owners to verify the procedures and guarantees for the issuance and management of
foreign electronic signatures and see if they meet the requirements of their specific applications.
Specifically for non-qualified signatures (where legal equivalence to handwritten signatures is not a
given) this is a nontrivial problem, since no clear criteria for the determination of security levels exist.
The other identified issues are of lesser importance for the realisation of eSignature interoperability,
as they can mostly be resolved by providing a solution to the two key issues above.
109
Preliminary Study on Mutual Recognition of
eSignatures for eGovernment applications
November 2007
Usage of advanced electronic signatures is often closely linked to national identity management
scheme(s). Signature certificates are mostly issued in combination with authentication certificates
and follow the same rules and procedures. Every Member State organises its identity management
scheme(s) in a completely independent way; only where it is strictly necessary the Member States
establish solutions for non-nationals. Often (but certainly not always) these solutions require
certificates issued by local certification service providers or even an establishment or a legal
representation on the territory of the Member State.
5.3.2.1.2 Assessment
Interoperability issues might to a certain extent more or less “automatically” is solved with the
progression in the area of mutual recognition or harmonisation of e-ID schemes.
5.3.2.1.3 Recommendations
The issue of identifiers is strictly speaking an issue of identity management, which does not fall
directly within the scope of this study. None the less, it can be noted that the Member State take
vastly different approaches to unique identifiers, and that the legal regimes applicable to them vary
equally. This can have a significant impact on the use cases of electronic signature solutions (e.g. in
the case of sector specific identifiers, which are designed to be meaningless outside of their context).
Given that these choices are largely the consequence of conscious and legitimate policy decisions,
further harmonisation with regard to the choice of identifiers seems undesirable and outside of
European regulatory competence.
The issues of identity management and electronic signatures are tightly interwoven, given that the
functional use of electronic signature typically depends on the reliable identification of the signatory
(without which the signature is of little use or value). However, in practice signatures are often
incorrectly used by requiring identifiers which are only available to nationals, thus excluding any
possibility of interoperability with foreign signature solutions. This should be discouraged (RECO5)
unless warranted under the terms of the public sector clause or unless the potential user group of the
application is indeed limited to entities who can reasonably obtain a credential with the required
identifier. Application owners should be made conscious of the interoperability consequences of
requiring the use of identification attributes in signatures which are only available within their country.
As a general rule, applications should not require that electronic signatures provide access to specific
identity information which foreign signatures would not be able to provide, unless this specific identity
information is strictly necessary for the proper functioning of the application.
In a more general sense, when determining the requirements for e-signature applications, application
owners must ensure that the signature requirements are not abused to add functionality which is
unrelated to the signature functionality itself (RECO6), such as automatically filling out identity
information such as names and register numbers, unless an alternative can be offered to users whose
signatures may not include the required information. In other words, while there is of course no
objection against using electronic signatures to add functionality beyond the traditional functions of a
handwritten signature (such as consent, non-repudiation etc.), applications should not make such
added functionality mandatory when this has the unintended side effect of making the use of foreign
signature solutions impossible.
110
Preliminary Study on Mutual Recognition of
eSignatures for eGovernment applications
November 2007
5.3.2.1.4 Conclusions
As a general rule, in all cases where Member States require a certificate issued by an accredited
certification service provider, it should be irrelevant by which Member State the certification service
provider has been accredited. A certificate issued by a certification service provider and accepted for
e-government transactions in one Member State, should, as a general rule, automatically be accepted
for similar e-government transactions in other Member States.
Currently most of the countries keep their own list of “recognized” service providers and these lists
only contain service providers established on the national territory. Examples, such as the Czech
CSP on the Slovakian list of “supervised” CSPs are very exceptional.
5.3.2.2.2 Assessment
Accreditation schemes use evaluation profiles with determined security levels and requirements. One
solution could be to agree on a set of “model” evaluation profiles and on essential qualifications for
accreditation bodies which have to apply these profiles in order to perform conformity assessments
for certification service providers.
5.3.2.2.3 Recommendations
111
Preliminary Study on Mutual Recognition of
eSignatures for eGovernment applications
November 2007
One of the most difficult problems with regard to interoperability is how to combine the sometimes
radically divergent approaches adopted by Member States in terms of security requirements and
trust. For example: Denmark doesn’t require registration based on in persona appearance for the so-
called OCES-signature, which is commonly used in Danish e-government applications. Even if this
process would meet the eSignature Directive’s requirements imposed on qualified certificates22, other
Member States may be reluctant to accept the resulting signature as adequate. This is especially true
when, as in the Danish case, the resulting signature is emphatically not considered a qualified
signature, so that it is not covered by the Directive’s equivalence provisions. This makes the Member
States’ choice of whether or not to accept the resulting signature largely political, and will inevitably
imply that Member States also take into consideration whether or not their own proposed signature
solutions require registration based on in persona appearance. Other example: In Finland the FINEID
offering both signature and authentication functionality, and TUPAS only offering authentication, are
commonly supported, without any clear system of preference. Can this flexibility be exported to other
Member States?
5.3.2.3.2 Assessment
This discussion is closely linked to the one on European interoperability of e-ID schemes. One
approach is “mutual trust” whereby Member States trust each other’s registration procedures (even if
they are not based on physical presence). The other approach is to define a limited set of “trust
levels”. The latter solution can however lead to a situation whereby large groups of users from certain
Member States are excluded from (a major part of) the e-government applications in other Member
States.
5.3.2.3.3 Recommendations
Multiple solutions could be envisioned for this problem. While there are several theoretical models to
solve the technical issues in relation to the validation of signatures (i.e. the technical difficulty of
validating a certificate), none of these solve the more complicated issue of determining the
security/reliability of a non-national signature (i.e. the difficulty of determining the trustworthiness of a
signature solution). To solve the latter problem, the use of trust lists is often suggested (see below for
a discussion on this).
Provisionally however, the creation of a cross border validation model which enables the validation of
non-national electronic signatures certificates without determining their security/reliability is a useful
first step in its own right. (RECO7) Once a suitable cross border validation model has been put into
place, Member States would at a minimum have the ability of assessing the reliability of selected
non-national CSPs and deeming them acceptable for the purposes of their application. While this
does not necessarily meet the trust requirements of each specific application, this creates a first
infrastructural building block for the exchange of electronic signatures.
Thus, it is recommended that a pan-European signature certificate validation platform model is
developed to resolve the issues of certificate validation and the issue of creating trust between
existing CSPs. Such a platform would allow non-national PKI certificates to be validated in any
country. The functionality of this platform could at an initial stage be limited to certificates that are
considered qualified in the Member States, as there is less margin for national policy in this field.
22
And specifically Annex II, point d), which states that the identity of the certificate holder must be
verified ‘by appropriate means in accordance with national law’, which need not necessarily exclude
registration processes concluded fully at a distance.
112
Preliminary Study on Mutual Recognition of
eSignatures for eGovernment applications
November 2007
Given the legal status of qualified signatures as equivalent to hand written signatures, and provided
that a functional validation platform could be established, the prerogative of Member States to reject
non-national signatures based on qualified signature certificates would be reduced (especially in the
case of qualified signatures, where the rejection could only be justified based on a strict interpretation
of the criteria of the public sector clause).
In a second phase, the issue of RA assessment could be dealt with more methodically, relying e.g. on
the information yielded by the notification procedure of article 11 of the Directive, which should
contain the CSPs accepted by the Member States for their applications which are not inherently open
to non-national solutions.
However, the creation of such a validation platform could meet with a number of legal objections. It
should be noted that article 4 of the e-Signatures Directive emphatically embraces the principle that
the internal market for certification services should be permitted to operate freely, and that Member
States should not intervene in the provision of such services within the internal market:
An intervention on a European level (with a Member State mandate) could be seen as being at odds
with this restriction, as it implies indirect Member State intervention in a nascent market where private
sector parties have indeed begun to examine the possibility of rolling out cross country validation
services. Private sector certification service providers are aware of the difficulties in relation to cross
border validation. They have taken a number of initiatives to explore this market inefficiency and are
considering the research of specific solutions23. If this trend continues, the development of a signature
validation platform which operates on a European scale with a Member State mandate could be
interpreted as a violation of the free internal market provisions of the Directive. In our opinion, the
creation of such a platform should at a minimum be preceded by a consultation of the Member States
on the main policy and legal issues arising as a result of the introduction of a pan-European validation
platform (RECO8), specifically:
• The question could be raised whether or not the establishment of a validation platform
violates the provisions of article 4.1 of the Directive, and specifically whether the acceptance
of a common pan-European validation platform should be considered to be a restriction
imposed by the Member States on the provision of certification services originating in another
Member State Strictly speaking, this could be found to be the case, as the acceptance of
such a platform would deny the market of cross border validation platforms for e-government
applications to any other CSP currently developing solutions in this field (and might cause
financial harm to any CSP who have already made investments in this direction). However,
one might also support a narrower interpretation of article 4.1, and argue that a pan-European
validation platform is not at odds with the free market principles, because the main goal of the
clause is to restrict Member States from imposing restrictions on certificate services which
would hinder foreign service providers in gaining access to their markets. In contrast, a pan-
European platform would be established through common consensus between the Member
23
E.g. Det Norske Veritas has initiated some work in this field; see Report No. 2005-0673, Revision
No. 01, www.dnv.com/ict/va/va.asp
113
Preliminary Study on Mutual Recognition of
eSignatures for eGovernment applications
November 2007
States, and would thus not be an attempt from one Member State to shield its market from
foreign competition. One could additionally argue that a validation platform is not a service
‘originating in another Member State’ as described by article 4.1, since it would operate under
a joint mandate from the Member States, and thus be common to all of them and foreign to
none. As such, one might argue that the hypothesis of a validation platform established
consensually by the Member States acting jointly is not covered by article 4.1., since it is not
an attempt to shield national markets from foreign competition, but rather an attempt to open
them.
• The question could be raised whether or not the establishment of a validation platform
violates the provisions of article 4.2 of the Directive, and specifically whether the acceptance
of a common pan-European validation platform should be considered to be a restriction
imposed by the Member States on the free circulation of certification services in the internal
market. Consideration (10) of the Directive clearly states that ‘The internal market enables
certification-service-providers to develop their cross-border activities with a view to increasing
their competitiveness, and thus to offer consumers and businesses new opportunities to
exchange information and trade electronically in a secure way, regardless of frontiers; in
order to stimulate the Community-wide provision of certification services over open networks,
certification-service-providers should be free to provide their services without prior
authorisation; prior authorisation means not only any permission whereby the certification-
service-provider concerned has to obtain a decision by national authorities before being
allowed to provide its certification services, but also any other measures having the same
effect.’ Again, from a strict perspective one might consider that the internal market for cross-
border signature validation in e-government application could be harmed through the
establishment of a common validation platform, i.e. that this would constitute a measure
‘having the same effect [as prior authorisation]’. However, again it would also be possible to
consider the definition of the internal market from a more narrow perspective, by considering
that the common validation platform would only target e-government applications, but leave
e.g. private sector applications which also require cross-border validation unaffected. CSPs
would therefore still be able to develop their services for the broader cross-border validation
market, and it is indeed not unthinkable that such services in time would come to replace the
pan-European validation platform if and when private sector initiatives are capable of meeting
public sector requirements. From that perspective, cross border validation services for public
sector applications only could be likened to a certification service affecting only a closed
network, which would render article 4.2 inapplicable in accordance with Consideration (10)
quoted above (‘to stimulate the Community-wide provision of certification services over open
networks’).
• Should Member States argue against the more flexible interpretation of article 4 that has
been summarily illustrated above, they should consider what encouraging actions could be
taken to stimulate the private sector to accelerate the development of services which would
offer the same service levels as such a pan-European validation platform.
• Finally, if any action is taken by the Member States to create a pan-European validation
platform, the liability implications should be taken into account. While the validation platform
would not issue qualified certificates as such, one of its key functions is to guarantee a
certificate’s validity and value to a relying party. As a result, article 6.1 of the Directive would
apply;
“Article 6 - Liability 1. As a minimum, Member States shall ensure that by issuing a
certificate as a qualified certificate to the public or by guaranteeing such a certificate
to the public a certification-service-provider is liable for damage caused to any entity
or legal or natural person who reasonably relies on that certificate:
(a) as regards the accuracy at the time of issuance of all information
contained in the qualified certificate and as regards the fact that the certificate
contains all the details prescribed for a qualified certificate;
114
Preliminary Study on Mutual Recognition of
eSignatures for eGovernment applications
November 2007
(b) for assurance that at the time of the issuance of the certificate, the
signatory identified in the qualified certificate held the signature-creation data
corresponding to the signature-verification data given or identified in the
certificate;
(c) for assurance that the signature-creation data and the signature-
verification data can be used in a complementary manner in cases where the
certification-service-provider generates them both;
unless the certification-service-provider proves that he has not acted negligently.”
Depending on the exact implementation and scope of the pan-European validation authority,
the application of these provisions will vary. If the services of the validation platform would
only span public sector application owners, relying parties would be limited to public sector
entities, which could simplify the negotiation of suitable liability agreements between the
Member States at the time of the platform’s creation.
It is clear for all of these issues that a positive interpretation that would welcome a pan-European
validation platform could potentially have a distorting impact on the further development of the
internal European market for certification services. Therefore the opinion of the Member States on
these issues should certainly be sought through a formal consultation (RECO8).
5.3.2.3.4 Conclusions
Electronic signatures in e-government applications are in permanent evolution but not all Member
States are progressing at the same rhythm. In a majority of the Member States individuals and
citizens don’t yet have the means to create and validate advanced electronic signatures.
115
Preliminary Study on Mutual Recognition of
eSignatures for eGovernment applications
November 2007
5.3.2.4.2 Assessment
A European strategy for a better interoperability of e-signature solutions in the area of e-government
services should not necessarily follow the speed of the slowest. Pilot solutions can be proposed in
which – at least for a certain time – only the most advanced countries participate.
5.3.2.4.3 Recommendations
This specific issue does not require additional measures. It should be noted that Member States at
this time are in principle not required to offer e-Government services using a specific electronic
signature, and that there is thus no specific consequence if the users of a given Member State do not
possess the required means to use e-Government applications. While the development and
deployment of e-Government services is a policy priority in all Member States, the provisional lack
thereof does not present insurmountable difficulties. However, it is useful to reiterate that the Services
Directive will remove this freedom not to offer e-Government/e-Signature solutions to some extent,
since it requires Member States to provide single points of contact for service providers where they
can complete all procedures and formalities relating to access to a service activity and to the exercise
thereof at a distance and by electronic means (article 8). While the use of electronic signatures is not
strictly a requirement, it is difficult to imagine a Member State complying with its obligations under
this article without implementing at least some form of electronic signature.
Thus, this problem will receive significant attention in the coming years, as Member States will be
legally required to deploy functional electronic single points of contact.
5.3.2.4.4 Conclusions
Provisionally there seems to be neither a ground nor a need for further action in this field.
5.3.2.5 Conclusions
The first three issues are closely interrelated and form the crux of the organisational difficulties
surrounding the creation of eSignature interoperability, namely the question of how to create trust.
A first issue is the fact that eSignature functionality is largely dependent on being able to determine
who the signatory of any given signature is. If this cannot be determined unambiguously, the
signature is of little practical value, as it cannot fulfil the function of linking a text to its signatory.
From this perspective, the reliance on specific identifiers which are often meaningless in a foreign
context (e.g. national register numbers) offers limited value. Thus, one of the key issues in the use of
electronic signatures is that any relying party must be presented with enough information to identify
who has actually signed the underlying document. In the absence of an identity number which has
international value, recipients are usually forced to rely on a set of identity attributes which is
presented to them. However, there is no consensus on when such a set of identity attributes is
sufficient to consider someone identified. A signature from an unidentified origin has no value.
The issue of atypical registration procedures is closely linked to this. Even when a sufficiently
complete set of identification data can be presented to uniquely identify a signatory, the recipient
must still be able to rely on it, i.e. she must know with acceptable certainty that this information is
correct and factually originates from the entity claiming the attributes. This means that the relying
party must be able to confide in the registration procedures which preceded the allocation of an
electronic signature solution to a specific entity. This is a complicated matter in an international
116
Preliminary Study on Mutual Recognition of
eSignatures for eGovernment applications
November 2007
context, as there are no uniform practices or standards which can be used to judge the reliability of an
eSignature solution. In order to accept a foreign signature, an application provider would therefore
have to assess these procedures on a case-by-case basis, which is unmanageable from a practical
perspective.
The question of mutual recognition encompasses both of these aspects: application owners presently
have no way of determining which signature solution providers meet the security and reliability
requirements of their applications. At least for nonqualified signatures, this is a key problem that
transcends the technical issues of interoperability.
The other identified issues are of lesser importance for the realisation of eSignature interoperability,
as they can mostly be resolved by providing a solution to the three key issues above.
This issue concerns signatures based on certificates where the application requires the certificate to
contain a specific National/Sectoral/Regional unique number.
As already mentioned in the paragraph Choice of Unique identifiers this is a legal barrier for a full
interoperability at the European level but this is also a technical and organisational problem.
There is a clear need for application to identify the signatory of a document in order to start a
workflow processing of the document. In most of the cases that have been analysed (see section
4.2.2.3.2.1), eGovernment applications have chosen to impose their constraints on the certificates
used for signing. Indeed, for eGovernment applications, the easiest way to achieve signatory
identification is to insert a unique identifier in the certificate. This identifier is analysed by the
application during the signature validation process. If the expected identifier is not found, applications
simply stop their processing and reject the signature.
Bulgaria “Online submission of annual income tax declarations” and “VAT on Internet”
applications
“The main identification information concerning the user is included in the certificate (including name,
address, uniform citizen number (UCN) or uniform identification code of BULSTAT, grounds for
representation etc.). The application extracts the identification data in order to identify the user from
the certificate, but not from the declared data. If the UCN or the BULSTAT codes are not available in
the certificate, the system will not accept the certificate.”
117
Preliminary Study on Mutual Recognition of
eSignatures for eGovernment applications
November 2007
The “Oil & Gas Trust Scheme“ application is very typical: users can obtain their electronic certificate
from any Certification Service Provider, even those installed outside UK, but the certificate must
contain a specific value in one of the certificate field (“Subject – Organisation Unit” should hold an
additional indicator (OGTS) after the entry).
Such common practices have a great impact on the possible interoperability of the application. Prior
to be interoperable, i.e. opened to anyone able to respect legal signature requirements (e.g. use of
qualified signature), the application must modify its processing to allow use of certificates that do not
contain unique identification number.
From our analysis, 26 applications are concerned by this issue (see table below) but among the 26
only 5 applications declare to be opened for non-national person.
118
Preliminary Study on Mutual Recognition of
eSignatures for eGovernment applications
November 2007
Open to non-
Country Application/Service name
national
Belgium Tax-on-Web (http://www.taxonweb.be) No
VAT on Internet No
ETHICS No
TastSelv Borger No
Denmark
Virk.dk – a government portal for Danish businesses No
e-Taxes (http://edavki.durs.si) No
Intrastat (http://intrastat-surs.gov.si/) No
Slovenia
One-Stop-Shop - State Portal for businesses
Yes
(http://evem.gov.si)
Development IS on waste management field. No
119
Preliminary Study on Mutual Recognition of
eSignatures for eGovernment applications
November 2007
5.3.3.1.2 Assessment
The use of unique identifier “legal – organisational – technical” problem addressed in paragraphs
Choice of Unique identifiers and Incompatible use of identifiers is an interoperability problem.
Nevertheless the analysis of the survey has found 90 applications that make use of eSignatures.
Among these 90 applications 26 require a unique identifier to be present in the certificate and among
these 26 only 5 applications have been assessed as opened to non-national person.
5.3.3.1.3 Recommendations
This issue concerns signatures based on certificates where the application requires that a specific
field of the certificate contains a specific National/Sectoral/Regional unique number because there is
a clear need for application to identify the signatory of a document.
The easiest and most often used way to achieve this is to insert a unique identifier in the certificate
but this has a great impact on the possible interoperability of the application.
In the paper-based world, identification data on official documents (e.g. tax declaration) are part of
the document itself (specific fields) and are certainly not deduced from the handwritten signature.
Why should this be different in the electronic world?
Even if, strictly speaking, the issue “use of incompatible identifiers” is an issue of identity
management, which does not fall directly within the scope of this study, and in order to avoid building
barriers to interoperability, we recommend avoiding the mandatory use of a specific identifier in the
certificates.
Indeed, we recommend that application owners allow their users to duplicate the paper-based world
approach: the unique number required by the application to identify the citizen/business should not be
a mandatory part of the signature/certificate. (RECO9).
It could, for example, be part of the document being signed, e.g. by filling it in either by the
citizen/business before the signing process or automatically filled in by the application after the
authentication process of the citizen/business.
Obviously, there is a drawback as soon as the signed document will have to be exchanged between
Member States. In such situation, there is an additional strong need that the format of document is
standardised. Although defining interoperable document formats does not fall directly in the scope of
this study, we suggest to take into account the common specifications developed by the eDoc Pilot24
within CIP (Competitiveness and Innovation framework Programme)25 which directly addresses
mutual recognition and interoperability of electronic documents.
5.3.3.1.4 Conclusions
24
eDoc Workshop, 18 April 2007, Brussels,
http://ec.europa.eu/information_society/activities/ict_psp/library/call_docs/docs/edoc_workshop_report
_v3_2.pdf
25
Available at: http://ec.europa.eu/information_society/activities/ict_psp/index_en.htm
120
Preliminary Study on Mutual Recognition of
eSignatures for eGovernment applications
November 2007
To achieve the full interoperability, applications of a given Member State shall accept signatures
generated by the credentials of any natural/legal person of the EU.
Concerning the signature type the survey shows that:
• There is no simple signature based on PKI solution.
• All advanced and qualified signatures are based on PKI solution.
5.3.3.2.2 Assessment
The question to answer is: can a person, with a given type of signature provided by its own national
credential, use it to sign documents in another country. The following table illustrates this problem.
Simple application
Signature Type
or a National Framework
Advanced Possible
A simple signature (non PKI based) can’t be used where PKI based (advanced or qualified signatures)
are requested due to the fact that validation processes are not the same. The opposite situation leads
also to a non-interoperability situation.
The simple signature interoperability requirement has not been observed. The simple signature is
application specific or supported by a National framework (not designed for interoperability).
Other type of signature (all PKI based) can be compatible with the application requirements.
The case where the signatory is provided with an Advanced Signature and where the eGovernment
application requires a Qualified Signature, leads to an issue. Indeed, in such cases, eGovernment
applications should reject the eSignature because it is not valid from a legal perspective. However, it
has limited technical means to verify that the eSignature has been created or not by a SSCD:
• Either by limiting the CSPs to a (reduced) list of CSP that issue certificates where the related
private key resides in a SSCD.
This is the way followed today by many eGovernment applications. It is however a barrier to a
full European interoperability;
• Or via the use of the Qualified Certificates Statements "qCStatements extension", defined in
121
Preliminary Study on Mutual Recognition of
eSignatures for eGovernment applications
November 2007
RFC 3739. Indeed, CSPs claiming to issue certificates where the private key related to the
certified public key resides in a Secure Signature Creation Device (SSCD) MAY use this
optional statement. In that case, this optional statement contains an Identifier of the
statement (represented by an OID), made by the CSP, stating that the private key associated
with the public key in the certificate is stored in a Secure Signature Creation Device
according to Annex III of the EU Directive 1999/93/EC, as implemented in the law of the
country where the CA is established.
As shown previously (see section 5.3.3.2), interoperability is very complicated to achieve between
simple signature solution which are not PKI-based and advanced or qualified signature which are all
PKI-based solutions.
Therefore, application owners should be recommended to make use of PKI-based signatures in
applications where interoperability in the short term is a key objective (RECO10). PKI-based
signatures might not be the only possible answer but, as of today, it is, without contest, the most
widely used solution that offers potential for interoperability.
However, using PKI-based signature does not solve the issue that an eGovernment application
requiring a qualified signature has technically no means to verify that the signature provided fulfils its
requirements. Nowadays, this issue is solved at the organisational level: eGovernment applications
requiring qualified signatures only accept signatures based on qualified certificates issued by CSPs
they trust. To solve the issue at a European level, we recommend relying on a Federated Validation
Authority model, as described at section 5.3.3.7.3.4.
We recommend also that qualified certificates issued by European CSPs comply with the “Qualified
Certificate profile”26 and, in particular, make effective use of the Qualified Certificates Statements
"qCStatements extension" as proposed by the ETSI Technical Specification. (RECO11).
26
ETSI: “Qualified Certificate profile”, ETSI TS 101 862, V1.3.3, January 2006
122
Preliminary Study on Mutual Recognition of
eSignatures for eGovernment applications
November 2007
5.3.3.2.4 Conclusions
A factor limiting interoperability at the technical level is applications requiring specific non-
standardised interfaces to be installed on the user’s workstation prior to sign a document.
Here we don’t talk about the middleware necessary to ‘drive’ the token containing the credentials
necessary for the signature (e.g. smartcard driver). Indeed, from an interoperability point of view,
every user is provided by his CSP with that middleware. This should be independent of the
eGovernment applications requirements.
Besides, there are 2 eGovernment applications that impose specific software to be installed on the
client’s workstation and which are therefore not opened for “Cross-border” access.
5.3.3.3.2 Assessment
Among the 90 applications making the use of eSignature, 2 of them require specific software to be
installed on the client workstation. Moreover the software are only available for the Microsoft
Windows Operating System environment. Furthermore, to fulfil this requirement the user must have
the rights to install software which excludes the use of a workstation where the user has not the
credentials to do it (e.g. cyber café).
Imposing specific non-standardised interfaces to be installed is a clear barrier against interoperability
but limited to these 2 applications.
123
Preliminary Study on Mutual Recognition of
eSignatures for eGovernment applications
November 2007
5.3.3.4 Recommendations
In order to avoid imposing barrier against interoperability, eGovernment applications and CSPs
should use standardized interfaces or applications that are de-facto available on any platform.
Applications used for signing should be independent from the platform, such as Web Browsers.
Where standardized methods to sign a document exist - in fact no such standard for qualified
signatures with Web Browsers exists - the signature solution should use open interfaces based on
standard protocols and formats, (e.g. PKCS#11, HTTP, XML, etc) to not limit to specific platforms.
In any case, it is highly preferable that the client signature tool relies only on standardised interfaces
supported by every operating system to applications such as Internet Browsers. (RECO12)
It is also acceptable that eGovernment applications rely on de facto standard software (e.g. Adobe
Acrobat) to create their signatures. Such a solution is acceptable, even if it is less preferred when the
de facto standard software is vendor specific, which can potentially result in issues to manage
documents on the longer term, since readability is not guaranteed.
On the other hand, eGovernment applications that want to provide maximum interoperability within an
open environment should rely on CSPs that do not impose any specific non-standardised interfaces.
(RECO13)
5.3.3.5 Conclusions
Among the surveyed applications, many different types of signature formats have been found.
The majority of applications present XML documents/forms (23 over 58 eGovernment applications) to
the signatory and provides consequently a piece of program (Java applet or Active X) to sign it. In
those cases, the signature format used is most of the time based on XML-DSIG or XAdES (ETSI TS
101 903).
But, there are some applications (3) that make use of PKCS #7 (Cryptographic Message Syntax)
format. There is application that uses its own proprietary format.
Besides, there are also some applications (6) that are relying on Adobe Acrobat Reader to sign
documents.
124
Preliminary Study on Mutual Recognition of
eSignatures for eGovernment applications
November 2007
5.3.3.6.2 Assessment
Having multiple signature formats in use across Europe does not constitute an interoperability barrier
as soon as the signed documents do not need to be exchanged from an application to another.
Anyway, even if this exchange of document has not yet been deemed necessary by application
providers, it seems obvious that it will be more and more requested in the future. At that time, making
use of common formats (e.g. XAdES as proposed by ETSI) will become a necessity.
5.3.3.6.3 Recommendations
To avoid issues linked to signature format recognition, we recommend to promote the use of
international standards. (RECO14)
Today, two main signature formats are emerging:
• CAdES (CMS Advanced Electronic Signature)27: defines a number of Electronic Signature
formats that build on CMS (RFC 3852) by adding signed and unsigned signature attributes ,
resulting in support for a number of variations in the signature contents and powerful
processing requirements.
• XAdES (XML Advanced Electronic Signature)28: set of extensions to XML-DSig29 making it
suitable for advanced electronic signature. While XML-DSig is general framework for digitally
signing XML documents, XAdES specifies precise profiles of XML-DSig for use with qualified
electronic signature in the meaning of European Union Directive 1999/93/EC. One important
benefit from XAdES is that electronically signed documents can remain valid for long periods,
even if underlying cryptographic algorithms are broken.
5.3.3.6.4 Conclusions
Most of the surveyed applications rely on the validation mechanisms provided by the CSP they trust
or on the validation mechanisms provided by their national framework. In any cases, they all are only
able to validate signature that have been generated by CSPs from their own country, i.e. the CSPs
that are accredited by their national accreditation authority.
27
ETSI: “Electronic Signatures and Infrastructures (ESI); CMS Advanced Electronic Signatures
(CAdES)”, ETSI TS 101 733, V1.7.3, January 2007
28
ETSI: “XML Advanced Electronic Signatures (XAdES)”, ETSI TS 101 903, v1.3.2, March 2006
29
W3C “XML-Signature Syntax and Processing”, W3C Recommendation, 12 February 2002
http://www.w3.org/TR/xmldsig-core/
125
Preliminary Study on Mutual Recognition of
eSignatures for eGovernment applications
November 2007
In general, eGovernment applications have been developed in that way because no trust relationships
exist with other CSPs but also because they want to limit the number of CSPs that they have to
interact with.
The limited number of CSPs currently supported by eGovernment applications is a major barrier to
interoperability. If every application would have to support all European established CSPs, the
situation will quickly become unmanageable. Indeed, at the European level, if we consider an
average of 3 CSPs per country, this would mean that every eGovernment application would have to
manage relationships with more than 80 CSPs!
5.3.3.7.2 Assessment
In order to better understand the challenges that eGovernment application owners have to deal with
during signature validation, it has been found interesting to explain all the necessary steps of such
validation.
The signature validation process that must be implemented by every eGovernment applications is a
complex process composed of several steps:
30
ETSI: “X.509 V.3 Certificate Profile for Certificates Issued to Natural Persons”, ETSI TS 102 280
v1.1.1, March 2004
126
Preliminary Study on Mutual Recognition of
eSignatures for eGovernment applications
November 2007
In the case of certificate chains, the certificate validation process is even more complex
because the processing must be repeated for each certificate in the chain. Thus,
eGovernment applications are burdened with the overhead of constructing and validating the
certification paths.
Certificate chains occur when a CA is part of a trust structure where higher level or peer CAs
issue certificates for other CAs, and one or more such CA certificates must be processed
before reaching a CA that is directly trusted by the application.
4. If an advanced signature forms such as CAdES-T or XAdES-T has been used, then verify the
Time Stamp Token (TST) associated to the electronic signature,. This requires to:
a. Verify the integrity of the TST signature (see point 2 above);
b. Check the validity of the Time Stamping Authority (TSA) certificate used to sign the
TST (see point 3 above).
5.3.3.7.2.2 Issues
Syntactic parsing and checking of a certificate’s validity time are usually straightforward operations.
However, all other steps in the certificate validation processing more or less have problems related to
scaling, i.e. handling of certificates from a multitude of CSPs.
This is due to two main reasons:
• Trustworthiness of CA which is a complex process: assess assurance level, certificate
policies and certification practices statement; conduct annual audits; establish qualification
agreement (SLA, QoS …), etc.
• Lack of consistency in the semantic interpretation of certificate fields within various digital
certificate implementations. Not all European CSP give the same meaning to the same
certificate fields. Therefore, it is up to each application or national framework to develop:
A very good example of efficient validation has been set-up in Spain. Indeed Spain also encountered,
at national level, the issues described at previous section, notably lack of certificate standardisation.
The MAP multiPKI Validation Platform (called Platform @firma v.5.0.) provides validation services of
the eCertificates and eSignature of the main recognised certification service providers to many
applications of eGovernment used by all Spanish public administrations (state, regional and local). In
nowadays this Platform holds 12 certification services providers31 and 69 types of eCertificates.
31
The list of authorities is available at
http://www.dnielectronico.es/seccion_aapp/rel_autoridades.html
127
Preliminary Study on Mutual Recognition of
eSignatures for eGovernment applications
November 2007
The way how Spain has solved the validation problematic would certainly be a good practice to take
into account at the European level.
Thanks to this multiPKI Validation Platform, the Spanish government has succeeded to achieve
eSignature interoperability at national level with a positive ROI. Furthermore, the multiPKI Validation
Platform is considered, in Spain, as key-enabler for eID
The current ROI, having in mind the technical investment and the number of transactions performed
by the service, shows the following balance:
- Investment during 2006 + 2007: 3,5 mill €
- Transactions already made: 3 million (end May 2007)
- Expected figures: 8,2 million transactions expected by the end of the first year.
- Cost per transaction at the moment: 0,43 €
This means a cost-effective service, much rational than a distributed structure with all public
administrations having to develop and implement SW modules to handle eSignature creation/
verification and certificates validations against all CSP in the country. A realistic assumption is to
estimate a total cost of 3 € per traditional administrative transaction, having to move physically to the
office (papercost, time spent by the civil servant, time spent by the citizen or business company…).
Taking into account the cost of investment for developing each eGov service, it appears quite a large
margin to assume that the ROI for the MPVP has already been met.
5.3.3.7.3 Recommendations
5.3.3.7.3.1 Introduction
Solving all issues bound to eSignature validation is a hard task to achieve and will require a lot of
time and effort to be solved. We strongly believe that the recommendation of setting-up a Federation
of Validation Authorities presented at section 5.3.3.7.3.4 is the solution that will help to solve many of
the eSignature validation issues presented in the problem description and assessment sections above
(see 5.3.3.7.1 and 5.3.3.7.2).
However, as we know that it will not be possible to set-up such Federation in the short-term, we
propose, as a step-wise approach, two alternative recommendations to solve the issue of verifying the
CSPs’ trustworthiness: publish a list of supervised CSPs (see section 5.3.3.7.3.2) and implement the
European Bridge/Gateway CA (see section 5.3.3.7.3.3).
Adopting one of these two recommendations will anyhow help eGovernment applications to reach the
interoperability they need and will be reusable as a building block by the Validation Authority
Federation.
All three recommendations are only valid is valid as long as PKI-based signatures are used (see also
section 5.3.3.2) (RECO15).
128
Preliminary Study on Mutual Recognition of
eSignatures for eGovernment applications
November 2007
As depicted in the figure below, as a very first step for achieving CA trustworthiness, which is one of
the key elements of the signature validation process, we recommend publishing, on a central website,
a list of Certification Service Providers supervised32 by their respective national responsible body
(RECO16).
A similar principle has been adopted in the frame of the eEurope 2005 initiative
(http://ec.europa.eu/information_society/eeurope/2005/all_about/security/esignatures/index_en.htm).
With such list, eGovernment applications will, at least, be able to build trust relationships with the
CSPs present on the list. The drawback is that such list will only contain CSP providing Qualified
Certificates.
... ...
eGov applications
Country Y Country X
However, this basic solution does not provide all the functionality that an application would require.
E.g. there is no automatic mechanism to inform the application that a CSP has been excluded by its
national responsible body.
32
In the sense of Article 3.3 of the eSignature directive (cfr [RD3])
129
Preliminary Study on Mutual Recognition of
eSignatures for eGovernment applications
November 2007
Another mean of achieving CA trustworthiness while solving issues raised by the list of supervised
CSP, is to implement the European IDA Bridge/Gateway CA33 (EBGCA) model (RECO17) that uses
the centralised administrative structure of a bridge, and distributes trust using both cross-certifications
and Certificate Trust Lists.
Indeed the EBGCA project has proven that the concept of a Bridge/Gateway CA is the most suited to
achieve CA trustworthiness at a European level.
As shown in the following figure, the EBGCA model will allow eGovernment applications to assess CA
trustworthiness using the so-called “Trust Service Provider Lists” (TSL). A Trust Service Provider List
is a way of securely transporting information about Trust Service Providers to the different
34
participants of the European IDA Bridge/Gateway CA. The framework of ETSI TS 102 231 is used
for the issuance and management of these Trust Service Provider Lists.
EBGCA
Root
TSLs CA
Root
Root
CA
CA
HTTP - HTTPS
... ...
eGov applications
eGov applications Get certificate revocation status
Country Y Country X
We remind that in order to be able to participate in the European IDA Bridge/Gateway CA, a
European Member State has first to sign the European IDA Bridge/Gateway CA Memorandum of
Understanding (MoU) as ruled by the “Certification Practices Statements for an operational EBGCA”.
This MoU contains a series of requirements that both the European IDA Bridge/Gateway CA and each
33
Europa - IDABC, Bridge/Gateway Certification Authority, September 2004,
http://europa.eu.int/idabc/en/document/2318
34
ETSI: “Electronic Signatures and Infrastructures (ESI); Provision of harmonized Trust-service
status information”, ETSI TS 102 231, V2.1.1, March 2006,
130
Preliminary Study on Mutual Recognition of
eSignatures for eGovernment applications
November 2007
European Member State Administration are required to meet to guarantee a sufficient level of
equivalence between the services provided by each Participating European Member State CA.
From a legal perspective, in order to apply the EBGCA model for generic eSignature applications, a
number of issues would need to be resolved, in addition to the aforementioned issues identified in
section 5.3.3.7.2.2 above.
First of all, the criteria for a Member State’s solutions to be included on a TSL should be elaborated.
As noted above, this has been done through a MoU. However, if multiple signature types (with
varying security levels) are to be integrated, it may be necessary to define multiple MoUs for each
signature level, with each Member States having to evaluate in which category their solution fits.
From this perspective, the likely result will also be different levels of Trust Service Providers, either
by including trust level information on a single TSL, or by simply creating multiple TSLs (one for each
trust level). Application owners could then choose to accept CAs registered on the appropriate TSL, n i
accordance with the requirements of the application. From a pragmatic perspective it may be useful
to initially restrict the scope of such an initiative to a single TSL containing only qualified signature
certificate CSPs.
A second issue would be determining the responsibility for the EBGCA, considering the potential for
liability. An EBGCA model may have only a limited appeal to Member State administrations if it
cannot offer any guarantees with regard to the reliability of the CA’s on its list(s). Similar to the
discussion in section 5.3.3.8. above, one of the key functions of an EBGCA model is to guarantee a
certificate’s validity and value to a relying party. At least with regard to trust lists containing qualified
certificates (which would certainly be a high priority), article 6.1 of the Directive would again apply;
“Article 6 - Liability 1. As a minimum, Member States shall ensure that by issuing a certificate
as a qualified certificate to the public or by guaranteeing such a certificate to the public a
certification-service-provider is liable for damage caused to any entity or legal or natural
person who reasonably relies on that certificate:
(a) as regards the accuracy at the time of issuance of all information contained in the
qualified certificate and as regards the fact that the certificate contains all the details
prescribed for a qualified certificate;
(b) for assurance that at the time of the issuance of the certificate, the signatory
identified in the qualified certificate held the signature-creation data corresponding to
the signature-verification data given or identified in the certificate;
(c) for assurance that the signature-creation data and the signature-verification data
can be used in a complementary manner in cases where the certification-service-
provider generates them both;
unless the certification-service-provider proves that he has not acted negligently.”
Again, suitable liability agreements would need to be drafted to determine the responsibility of a
EBGCA towards the Member States, the application owners (or other relying parties) and the
participating CSPs.
In addition, the same objections related to the possible disruption of the internal market could be
raised against an EBGCA model as against a validation platform, on the same grounds as described
in section 5.3.3.8. above, with the same potential justifications applying. Again, the opinion of the
Member States on these issues should be sought through a formal consultation (RECO18).
Finally, it is also clear that the choice of applicable law may prove to be politically sensitive, and may
also be important to determine the legal validity of any disclaiming clauses.
5.3.3.7.3.4 Validation Authority Federation
In our understanding, a technical solution that would answer many of the technical challenges that
eGovernment applications are facing is to set-up a ‘Validation Authority Federation’ (RECO19). In
131
Preliminary Study on Mutual Recognition of
eSignatures for eGovernment applications
November 2007
order to explain our model, we have decided to first present the services such solution should provide
to eGovernment applications. Some examples of similar implementations are presented in a second
section. Then a section will present the technical components that have to be set-up to provide the
described services. Finally, we will describe the interfaces that our solution will have to set-up towards
the various stakeholders.
5.3.3.7.3.4.1 Services
Prior to define what would be the Validation Authority Federation architecture, it has been deemed
necessary to present the various services that such solution would have to propose as a minimum.
5.3.3.7.3.4.1.1 CA trustworthiness
One of the key issues in the validation process described above (see section 5.3.3.7.2.1) is the
assessment of the CA trustworthiness.
When thinking at a European level, CA trustworthiness can be achieved by several known
techniques:
• Hierarchy: this would mean that a common root CA would be set-up at the European level
and would issue certificate to all subordinate CAs (i.e. every Member State CAs). Such
situation has already been rejected by Member States since it would give too much power to
the root CA that would be established at European level because it can force existing
members to trust certificates of a new member simply by certifying the new Member State’s
CAs, hence removing national control over trust35.
• Cross-certification (full mesh): the effort needed, particularly at the legal side, is very huge. At
the European level, considering 3 CAs per country, this would impose more than 3500
relationships to be set-up!
• Bridge-CA: is a more promising approach. At the European level, the European IDA
Bridge/Gateway CA36 has proposed a model that uses the centralised administrative structure
of a bridge, and distributes trust using both cross-certifications and Certificate Trust Lists.
In our Validation Authority Federation model, the CA trustworthiness is a service provided by the
Federation (in combination with the Bridge/Gateway CA model) to the eGovernment applications for
all European CSPs.
Apart CA trustworthiness, we strongly believe that a Validation Authority Federation would also need
to provide centralised certificate revocation status services to the eGovernment applications avoiding
each application to establish relationships with every CSPs throughout Europe.
This is one of the main services that our Validation Authority Federation model will provide to
eGovernment applications allowing them to off-load this complex and power consuming task.
Indeed, in order to validate a certificate, a chain of multiple certificates, called a certification path,
may be needed to be validated, comprising the certificate of signer, signed by one CA, and zero or
more additional certificates of CAs signed by other CAs.
For eGovernment applications, delegating certificate path validation to a trusted validation authority
can offer significant advantages. As stated in the RFC 337937: “the time required to send the target
35
See « A bridge CA for Europe’s Public Administrations - Feasibility study », IDA, Final Report, July
2002, http://ec.europa.eu/idabc/servlets/Doc?id=17267
36
Europa - IDABC, Bridge/Gateway Certification Authority, September 2004,
http://europa.eu.int/idabc/en/document/2318
132
Preliminary Study on Mutual Recognition of
eSignatures for eGovernment applications
November 2007
certificate to the validation server, receive the response, and authenticate the response, can be
considerably less than the time required for the application to perform itself certification path discovery
and validation. Even if a certification path were readily available to the client, the processing time
associated with signature verification for each certificate in the path might (especially when validating
very long paths or using a limited processor) be greater than the delay associated with use of a
validation server”.
As a matter of fact, it could also be envisaged that a Validation Authority Federation provides
signature validation services, such as:
• Verification of the integrity of the signed data;
• Compliance of the eSignature with regards to the eGovernment application policy. E.g.
cryptographic algorithm parameters (hash algorithm, signature algorithm, …).
In addition to the previous traditional services that would be expected from a Validation Authority,
there are various value-added services that could be provided, e.g.:
• Certificate qualification, i.e. indication of the certificate quality derived certificate extensions
(e.g. Qualified Certificate Statement) or from the certificate policy;
• Certificate holder information extraction and semantic processing. I.e. providing in a
standardised XML form, name, surname, … of the certificate holder;
• Signature format transformation for long-term archiving, i.e. providing a service to transform
a signature into a long-term secure data format including validation data (e.g. XAdES-A or
CAdES-A);
• Time Stamp Token (TST) validation , i.e. verifying the integrity of the TST signature,
checking the validity of the Time Stamping Authority (TSA) certificate used to sign the TST.
Those services should be subject to Service Level Agreements defined and agreed by all interested
parties, i.e. the Validation Authority and the Certification Service Providers, ensuring any
eGovernment application’s user that a reliable, interoperable, scalable, and widespread service for
signature validation is available to them.
5.3.3.7.3.4.2 Examples
To illustrate the Validation Authority Federation model proposed, this section will present three
examples of similar models:
1. The Spanish solution38, which takes care of all eSignature and electronic certificates
validation, provides a lot of advantages:
37
RFC 3379 - Delegated Path Validation and Delegated Path Discovery Protocol Requirements,
September 2002 - http://tools.ietf.org/html/rfc3379
38
MultiPKI Validation Platform. More detailed information at: http://www.epractice.eu/cases/1984
133
Preliminary Study on Mutual Recognition of
eSignatures for eGovernment applications
November 2007
This centralised building up approach to create a common service providing eID and
eSignature features to eGovernment applications has been proved to be a rational and cost
effective approach and a key enabler for the eID in Spain. It has unburden eGovernment
applications of the hard tasks of developing SW modules to deal with the creation/
verification of the eSignature, the handling of crypto libraries, CRL and OCSP protocols for
the verification of digital certificates or the need of physical network connection to all
Certification Service Providers of the country.
2. The Council of the Notariats of the European Union (CNUE40) started to develop an electronic
signature verification platform that is designed to allow all European civil law notaries to
identify notarial electronic deeds from other countries as such, and to properly take note of
their content.
The prototype of the verification platform already allows the verification of signatures from
civil law notaries coming from France, Germany, Italy and Spain. This can indeed already be
considered a truly pan-European achievement.
3. DNV Validation Authority41 has been set-up for private organizations in 2006. It offers a new
independent third party trust service to manage the process of verifying digital signatures and
validating the accompanying digital identity (eID) certificates. DNV’s Validation Authority
services will enable effective use of digital signatures by reducing cost and complexity and
providing true interoperability between different eID certificates.
39
RFC 3379, “Delegated Path Validation and Delegated Path Discovery Protocol Requirements”,
September 2002, http://tools.ietf.org/html/rfc3379
40
www.cnue.be
41
DET NORSKE VERITAS – Validation Authority, REPORT NO. 2005-0673, REVISION NO. 01,
www.dnv.com/ict/va/va.asp
134
Preliminary Study on Mutual Recognition of
eSignatures for eGovernment applications
November 2007
The model has been presented at some big PKI events (5th Annual PKI R&D Workshop
(NIST), Porvoo 8 meeting …).
5.3.3.7.3.4.3 Components
Currently eGovernment applications need to query the certificate validation services from the CSP
having issued the certificate issued to the signing party. As explained earlier, this is a complex task.
To solve this issue, we recommend Member States to set-up a National Validation Authority (NVA)
which will allow eGovernment applications to outsource the signature validation tasks to this NVA,
exactly in the same way as the Multi-PKI Validation Platform in Spain (see section 5.3.3.7.3.4.2).
The following figure represents a National Validation Authority and shows how it may integrate with
application approach models described at section 4.2.1.
crl – ocsp
and qualification
and qualification and qualification
Server
Server
Web Portal
eGov Applications
Server
Se rver
User
RA
RA
RA
RA certificate
Sign documents
135
Preliminary Study on Mutual Recognition of
eSignatures for eGovernment applications
November 2007
The National Validation Authority proposed in our model will act as the central point of validation for
all eGovernment applications deployed in the Member State.
As is, the National Validation Authority should be able to validate any eSignatures as soon as the
signature has been created using an electronic certificate issued by a CSP located in the same
country. The services provided by the National Validation Authority should be equivalent to those
described at section 5.3.3.7.3.4.1.
One can also imagine that some Member States will not only create one National Validation Authority
but, for example, a federation of regional or sectoral Validation Authorities.
Of course, for eGovernment applications this does not solve the issue of validating eSignatures
created using an electronic certificate issued by a foreign CSP. To solve this issue, the National
Validation Authority should be able to communicate with the National Validation Authority of the
foreign country (provided that it exists). That’s the reason for the introduction of the European
Validation Authority Gateway presented in the next section.
In order to allow National Validation Authorities to communicate with each other and thus creating the
concept of Validation Authority Federation, an important component needs to be set-up at the
European level. We called it the European Validation Authority Gateway (EUVAG).
The first role of this central component is to establish the trust relationships between all National
Validation Authorities. Secondly, the EUVAG provides the link between all NVAs from a
communication point of view. Indeed, when receiving a validation request, the EUVAG will redirect
the request to the competent National Validation Authority based on the eSignature certificate
content, thus hiding the complexity of National Validation Authorities network.
The following picture represents the technical concept.
136
Preliminary Study on Mutual Recognition of
eSignatures for eGovernment applications
November 2007
Web Services
Root
Root Root
TSLs CA
CA
CA
CAs
EU Validation Authority Gateway
Generic Validation Authority
Web Services
crl – ocsp
Request signature
Request signature
validation
... ... ...
validation
crl – ocsp crl – ocsp
Sign Sign
Sign Sign User
User
certificate
certificate
The concept is based on a unique European Validation Authority Gateway that would only act as a
gateway between National Validation Authorities of the Member States. In our model, to validate an
eSignature, an eGovernment application deployed in country X would have to contact its own
National Validation Authority. If the certificate used to electronically sign originated from a
Certification Authority of country Y, then the Validation Authority from country X would have to
contact the European Validation Authority Gateway, which will in its turn redirect the validation
request to the National Validation Authority of country Y. The whole validation process will be done in
country Y in compliance with the national rules governing the certification authority and with the
knowledge of the semantics behind the certificate fields.
If the signature originating country (country Z in the previous drawing) does not have a National
Validation Authority in place, then the validation process will be left to the Generic Validation
Authority as explained in the next section.
As we know that not all Member States will set-up a National Validation Authority or perhaps not all at
the same time, we also propose to set-up a Generic Validation Authority at the European level
137
Preliminary Study on Mutual Recognition of
eSignatures for eGovernment applications
November 2007
allowing eGovernment applications of Member States which do not have a National Validation
Authority to participate to the Federation anyway.
We propose to build this European Generic Validation Authority on the basis of the European
Bridge/Gateway CA. In addition to the services provided by the EBGCA, i.e. distribution of Trusted
Status Lists, we suggest to implement certificate validation services for all CSP belonging to Member
States which have not set-up their own National Validation Authority.
At this stage, we do not believe that the proposed European Generic Validation Authority could
additionally provide all signature validation services or value-added services as described at section
5.3.3.7.3.4.1.3 and 5.3.3.7.3.4.1.4. However, even if providing semantic analysis of the certificate
might become a nightmare for the Generic Validation Authority as it doesn’t control the data, and its
interpretation, stored in the certificate; it would anyway be more efficient to achieve this semantic
analysis centrally than to leave it up to every eGovernment applications.
5.3.3.7.3.4.3.4 Interactions
The following diagram intends to explain the relationships and interactions between the different
components of the Validation Authority Federation presented above. Especially, it intends also to
explain how the model can work when not all the components are present.
138
Preliminary Study on Mutual Recognition of
eSignatures for eGovernment applications
November 2007
Country X EU Country Y
WS request
a Redirect CRL/OCSP request
4 WS response
b c
CRL/OCSP response
e d
139
Preliminary Study on Mutual Recognition of
eSignatures for eGovernment applications
November 2007
140
Preliminary Study on Mutual Recognition of
eSignatures for eGovernment applications
November 2007
5.3.3.7.3.4.4 Interfaces
Basically a Validation Authority would have to propose two interfaces: one towards eGovernment
applications and one towards the CSPs.
In our opinion, to support the services described above (see section 5.3.3.7.3.4.1), the interface
between the VA (being the National Validation Authority or the European Validation Authority
Gateway) and the eGovernment application should be based on web services, i.e. exchange of a
defined XML message via a secured standardised protocol (e.g. HTTPS42). Nowadays, web services
are supported by almost all web application environments providing an easy way of integration for
eGovernment applications.
The Validation Authority (being the National Validation Authority or the Generic Validation Authority)
should not impose new interfaces to be provided by CSPs. Therefore, it should rely on the existing
ones:
CRL
For CSP that only support a CRL interface, the VA will have to download on a regular basis the
Certificate Revocation List of the CSPs and to store it in one database. This is obviously not the
preferred interface as it could impose huge databases to be kept at the VA level.
OCSP
Online Certificate Status Protocol (OCSP) as defined in RFC2560 is a very simple request/reply
protocol that allows clients to ask an “OCSP responder” about the revocation status of one or more
certificates. The OCSP responder returns digitally signed responses regarding the status of the
certificates identified in the request. OCSP is designed to return real-time responses to client queries,
and can provide an efficient method for returning certificate status on demand.
From the VA point of view, OCSP is highly preferred to CRL.
5.3.3.7.4 Conclusions
42
HTTP over SSL
43
In the sense of Article 3.3 of the eSignature directive (cfr [RD3])
141
Preliminary Study on Mutual Recognition of
eSignatures for eGovernment applications
November 2007
Validating an electronic certificate is a complex process. First, it must be checked if the certificate
belongs to a trusted CSP (the whole certification chain has to be analysed), then the validity is
verified (does the certificate expired?) and finally the status must be verified (is the certificate
rejected?).
To achieve the certificate status check, the application can make use of different protocols: CRL (a
red list of rejected/suspended certificates downloaded from the CSP’s site), OCSP (a request
certificate status is sent to the CSP which sends back a response of "current", "expired," or
"unknown.").
SCVP (Server-based Certificate Validation Protocol) has been designed to make it easier to deploy
PKI-enabled applications by delegating path discovery and/or validation processing to a server, and
to allow central administration of validation policies within an organization.
Among surveyed applications, 72 applications have answered the question « What types of validation
protocols are used for the electronic certificate validation? (OCSP, CRLs, SCVP…) »:
• 43 are only supporting CRL as validation protocol,
• 26 support both CRLs and OCSP,
• 3 support only OCSP protocol.
None of the surveyed application support SCVP.
The responses are not surprising, as they fit perfectly with the validation protocols usually provided by
CSPs.
5.3.3.8.2 Assessment
There is potentially an issue for the three applications that only support OCSP as validation protocol.
Indeed, not all CSPs presented in the various country profiles have set-up an OCSP responder. Many
of the CSPs only provide a certificate validation mechanism based on CRLs (e.g. in Austria: A1
mobile phone signature or in Finland: FINEID citizen’s card).
Of course, the issue is more related to specific applications that have not been designed for
interoperability and that only support validation protocols provided by the CSPs they trust. To achieve
interoperability, eGovernment applications should support as many validation protocols as possible.
142
Preliminary Study on Mutual Recognition of
eSignatures for eGovernment applications
November 2007
5.3.3.8.3 Recommendations
The complexity for applications of supporting the validation protocol provided by the CSP they trust,
will automatically disappear as soon as the recommendation ‘Validation Authority Federation’ (see
section 5.3.3.7.3.4) is made available to eGovernment applications.
Indeed, by using such a model, the whole validation process will be off-loaded to the Validation
Authority preventing eGovernment applications to support multiple protocols.
5.3.3.8.4 Conclusions
No further steps are in our opinion recommended at this stage for this particular issue.
5.3.3.9 Conclusions
From a technical point of view, among the eight issues presented above, two of them are considered
as having a major impact on potential interoperability:
• Signature validation: eGovernment applications are relying on the validation mechanisms
provided by the CSPs they trust. At the National level this can be a problem due to the high
number of accredited CSPs but at the European level, if every application would have to trust
all European potential CSPs, the situation would quickly become unmanageable at the
application level.
• Incompatible use of identifiers: This issue concerns signatures based on certificates where
the application requires that the certificate to contan a specific National/Sectoral/Regional
unique number to identify the signatory of a document.
143
Preliminary Study on Mutual Recognition of
eSignatures for eGovernment applications
November 2007
eGovernment applications may impose, for security reasons, a certain key length (e.g. 2048 bits) that
is not provided by the user’s certificate. If such security requirement is met by an application, it could
prevent non-nationals users to make use of the application.
Note that the situation is nowadays controlled at the national level, where applications only supports
the signature key length provided by their national CSPs.
eGovernment applications may provide client-side software (JAVA applet/Active X or even FAT
client) that may not be supported in the user environment. Among surveyed applications, a large
number of them are only supported on Microsoft Windows operating system.
Moreover, applications may also require to exchange signed emails which would not be possible with
certain email applications (e.g. Outlook Express cannot send mail signed with Belgian eID because
the Belgian eID certificate do not contain the email address of the signatory).
5.4.3 Hardware
From an interoperability point of view, hardware requirements on the client side are not imposed by
the applications but by the type of token that is used.
However, for applications that claim to be opened for cross-border use, this may constitute a barrier
as each supported token may require its own driver which may interfere with other installed drivers
(for national use).
144
Preliminary Study on Mutual Recognition of
eSignatures for eGovernment applications
November 2007
5.5.1 eProcurement
E-Procurement is one of the sectors which are generally considered to have one of the strongest
business cases for interoperability, in the sense that efficient e-signature interoperability could affect a
large number of stakeholders (both public sector parties and private sector tenderers) who could
realise a potentially substantial cost savings through electronic procurement. Despite this fact, no
substantial interoperability has been realised yet. In part, this is due to the relative newness of the
European legal framework44 (specifically the e-Procurement Directives 2004/17 and 2004/18) and the
fact that most Member States are still in the early stages of implementation of their applications, as
described above (see the table under 4.2.4.1: 14 countries out of 29 indicated that no application was
available yet). However, a number of the aforementioned issues also play a strong role.
Specifically, the descriptions of the e-Procurement applications above clearly show that Member
States have assumed a strongly national perspective, in which it is assumed that any tenderer should
apply for the appropriate signature solution in the country involved, regardless of the form that this
may take, and even if this means that a representative of the foreign entity would need to register or
appear personally in the country where the tender was published. Cross border functionality of the
electronic platform is not yet considered to be a key priority in this regard.
Apart from this national perspective, other issues discussed above also certainly play a role in this.
For one, the required signature type (advanced – advanced using a qualified certificate – qualified
signature) complicates matters, since it would appear to be politically and legally infeasible to expect
countries to accept signature types which are not deemed adequate under their own frameworks.
Finally, the descriptions above also indicate that some countries do not even consider signatures to
be essential to the tendering process, which is e.g. witnessed in Estonia (no signature is required) and
Finland (electronic authentication is sufficient). It is clear that the Member States apply widely varying
demands to the security needs of e-procurement procedures, and that there is no consensus on the
role of (or the need for) an electronic signature. Under such circumstances, interoperability between
all Member States’ systems can only be a longer term goal.
The existence of these issues and their magnitude may seem somewhat surprising, given that the
role of electronic signatures is specifically regulated in the aforementioned directives. However, the
approach taken by both Procurement Directives is quite comparable to the basic rules of the
eSignatures Directive as outlined above:
As a basic principle, the eProcurement Directives state that ‘the tools to be used for communicating
by electronic means, as well as their technical characteristics, must be non-discriminatory, generally
available and interoperable with the information and communication technology products in general
use.’ (article 42.4 of Directive 2004/18/EC and article 48.4 of Directive 2004/17/EC). This is
comparable to the equivalence and non-discrimination rules of article 5 of the eSignatures Directive,
which in principle bars the recipient of an electronic signature from denying its validity or admissibility
on the grounds that it is in electronic form. Thus, the basic rule is that Member States are required to
provide an interoperable platform which does not preclude non-national solutions from being used.
However, in public sector applications this general rule is somewhat negated by the public sector
clause (article 3.7) of the eSignatures Directive, as discussed in detail above, allowing Member
States to make the use of electronic signatures in public sector applications ‘subject to possible
additional requirements. Such requirements shall be objective, transparent, proportionate and non-
discriminatory and shall relate only to the specific characteristics of the application concerned. Such
requirements may not constitute an obstacle to cross-border services for citizens.’
It is thus not surprising that the eProcurement Directives (which by definition are public sector
applications subject to the public sector clause of the eSignatures Directive) contain similar
provisions. According to the Directives, ‘Member States may, in compliance with Article 5 of Directive
1999/93/EC, require that electronic tenders be accompanied by an advanced electronic signature in
conformity with paragraph 1 thereof’ (article 42.5 (b) of Directive 2004/18/EC and article 48.5 (b) of
Directive 2004/17/EC). In short, even in procurement procedures, Member States may elect to
44
See http://ec.europa.eu/internal_market/publicprocurement/e-procurement_en.htm
145
Preliminary Study on Mutual Recognition of
eSignatures for eGovernment applications
November 2007
require the use of qualified signatures. As shown above, this is a common requirement in the Member
States (see section 4.2.4.1. – 5 countries out of 29 indicated that a qualified electronic signature was
required, with a further 5 indicating that at least a qualified certificate would be needed).
In itself, this could already prove to be problematic in Member States where national governments
have elected not to make qualified signatures a common part of their eGovernment strategy (as is
e.g. the case in Denmark), since it would make the acquisition of qualified signature solutions
noticeably more complex in such countries. However, even when Member States do offer qualified
signature solutions, it is far from certain that entities in that Member State would be able to participate
in tendering procedures in other countries. As the table in section 4.2.4.1 has shown, eProcurement
applications relying on qualified signatures typically accept only signatures generated through
certificates issued by CSPs which have been accepted by the application owner in that country. If an
aspiring tenderer cannot reasonable receive a qualified certificate from such a CSP (either because
this requires a physical identification before a registration authority in that country, or because it even
requires an actual establishment or domicile in that country, both of which are common
requirements), then access to an eProcurement application is practically impossible.
It goes without saying that this situation is manifestly contrary to the goals of the eProcurement
Directives (and against the basic principles of the eSignatures Directive in general). The resolution of
this specific situation is therefore no different than that of any other eSignature application in the
public sector: the absence of suitable (and affordable) interoperability solutions, and specifically of a
functional and reliable validation and trust mechanism, is the key impediment to the realisation of the
goals of the eSignatures and eProcurement Directives, more than any political consideration.
However, even apart from these issues, it is clear that e-Procurement also presents a number of
unique difficulties which are not encountered (or at least not to the same extent) in other sectors.
These will be further discussed below.
• Firstly, it should be realised that, unlike other typical eGovernment applications,
eProcurement does not typically rely on a single document being signed by a single entity.
Public procurements commonly require the participating entity to submit a number of
supporting evidentiary documents in addition to the main offer, including such documents as
social security certificates, extracts from articles of associations, declarations of non-
bankruptcy, and attestations of conformity with direct and indirect tax requirements. This is a
significantly more complex situation, as it would be an insufficient solution to merely roll
electronic versions (e.g. scans) of such documents into one digital envelope which is then
digitally signed by the tenderer.
After all, in this case, the legal value of the certificates is debatable, since their authenticity is
only backed by the tenderer, but not by the actual issuing authorities. Such a situation is
acceptable in procurements where the purchasing body has only requested copies of
evidentiary documents, but not in cases (which is the typical situation) where original
documents have been requested. If original documents have been demanded, then the
originals also need to be equipped with a suitable authenticity verification mechanism, the
most obvious solution being a signature from the issuing authority. Such solutions are not
commonly offered at this time, as many Member States are still issuing paper documents
exclusively.
Thus, a first issue to be aware of is the need of multiple signatures from multiple
stakeholders. The recipient of an electronic offer must be able to validate all of these.
• Secondly, not only do public procurements commonly involve signatures from the authorities
responsible for issuing supporting documents, it is also common for offers to be prepared and
submitted jointly, in the form of a consortium, temporary association (with or without legal
personality) or simply in the form of a prime contractor backed by one or more
subcontractors. It goes without saying that this increases the problem noted above
exponentially, as each of the participating entities may need to provide its own set of
supporting documents (potentially from many different countries and/or administrations
within these countries); and the main offer itself may need to be jointly signed by all of the
participants. This can be a problem when e.g. extending a consortium to a country that does
not commonly work with qualified signatures, when the consortium is planning to introduce a
146
Preliminary Study on Mutual Recognition of
eSignatures for eGovernment applications
November 2007
bid in a country requiring such signatures. Under extreme circumstances (and particularly in
case of last minute offers being filed), this may even lead to a discrimination against
otherwise perfectly suitable consortia partners, on the sole grounds that they cannot
electronically sign the final document.
• Thirdly, a key issue that is somewhat more prevalent in eProcurement applications than in
most other types of eSignature applications is the issue of determining the authorisation to
represent a specific entity. Obviously, from the perspective of the tenderer, this is not a
particularly exclusive issue, since e.g. VAT declarations on behalf of legal entities also
present the difficulty that the natural person signing a specific document actually has to have
a legal mandate to represent this entity. However, as noted above, the larger problem is
represented by the inclusion of signed supporting evidentiary documents.
In each of the included electronic documents, the recipient (i.e. the purchasing body) must be
able to determine not who signed the document (the exact natural person is in fact irrelevant
in this case), but in what capacity the document was signed, and whether or not the signature
suffices to consider the document an official expression of the issuing body’s authority. This
requires suitable technical and organisational solutions to be put into place to be able to
retrieve the identity and status of the issuing body from whom the supporting document
originated, and above all a suitable trust mechanism to be able to determine whether this
document is in fact lawful and meets the requirements of the procurement regulations.
It should be noted that this problem has in fact never been resolved with complete certainty in
an offline context. Reliability and authenticity of non-national documents is often assessed
based on its overall appearance (the presence of a suitable letterhead, signatures and
stamps), rather than on any conclusive validation procedure. None the less, as with the
electronic signature in general, it can be expected that eProcurement will be held to a higher
standard in this regard.
• Finally, an additional eSignature specific difficulty which has largely escaped specific scrutiny
is the issue of liability limitations. Unlike handwritten signatures, electronic signatures are
typically restricted through the issuing CSP’s Certification Practice Statement, which limits the
liability of the CSP and often restricts the validity of the signature to commitments up to a
certain threshold. Again, the combination of multiple signatures in the case of consortia, along
with the complex and various rules regarding liability in public procurements (often explicitly
requiring that each of the partners of a consortium must accept full liability for the whole of
the offer, rather than solely for its own part) makes for an unreliable situation. After all, if an
offer with a value of 10 million EUR is filed by a consortium of three partners, while one
signature has a value restriction of 5 million EUR, then a provision of joint full liability may in
fact invalidate the signature, and could thus threaten the validity of the offer as a whole. No
real solution to this problem has yet been found, to our knowledge.
Again, it should be emphasised that this problem also exists in an offline context to a certain
degree, as the articles of association of some entities may specify that the entity cannot be
represented by a single signature in contracts exceeding a certain value. In those cases too,
the validity of an offer with an unsuitable signature is debatable. However, the transition to
electronic tendering obviously exacerbates this problem, since it adds the CPS as an
additional restriction to the articles of association.
Thus, it is clear that public procurement is not only an interesting test case for electronic signatures in
eGovernment applications in general, but it is also one of the most complicated types of applications.
For this reason too, it should be considered a key priority. Resolution of the interoperability problems
faced by public procurements implies a resolution of the majority of eSignature related difficulties.
Many of the issues described above in the e-procurement section also apply to VAT declarations, in
particular the tendency to assume a purely national perspective by permitting only locally established
solutions (which is a uniform element in e-government e-signature applications); and the wide variety
147
Preliminary Study on Mutual Recognition of
eSignatures for eGovernment applications
November 2007
Income tax declarations are one of the more popular eSignature applications, being off ered in 22 of
26 responses (see section 4.2.4.2.; 3 surveyed countries did not indicate whether or not a solution
was available). The reason for this is likely twofold: first of all, the manual processing of income tax
declarations is very labour intensive, requiring that manually provided information is transferred to an
electronic form, thereafter to be processed automatically. Thus, paper based declarations represent a
large and unnecessary administrative expense, both in time and money. Additionally, such
declarations are one of the easier to implement:
• they do not usually require multiple signatures or multiple documents since declarations are
usually filed individually; with the noticeable exception of tax systems which require a joint
declaration between marital partners;
• the legal capacity of the signatory does not need to undergo extensive screening, as one
typically files ones taxes in a personal capacity. It should be noted though that some
applications include the possibility of giving a mandate to a service provider (accountant or
tax consultant);
148
Preliminary Study on Mutual Recognition of
eSignatures for eGovernment applications
November 2007
• the incentive for abuse is limited, since there is no benefit to filing false declarations under
the pretence of being a third party, apart from a possible fleeting sense of malicious
satisfaction;
• long term validity is not much of an issue, since a final tax is established in a relatively short
term; and
• the user group is extensive and largely homogeneous, consisting mostly of the national
population.
Thus, roll-out is relatively easy and cheap, and can yield high cost savings. It should therefore come
as no surprise that so many surveyed countries have chosen to deploy an income tax declaration
application; nor that the legal threshold for electronic signatures is set somewhat lower than usual: of
the 22 reported applications, only 6 require a qualified signature, 8 require a simple or advanced
signature, and in 8 cases an authentication scheme of some sort (including two factor authentication)
was sufficient. This is in line with what one might expect given the lower incentive for abuse.
With regard to specific issues, income taxes are similar to VAT declarations in the sense that they are
often closely linked to tax registers (see e.g. the French policy of allowing electronic declarations
based on a unique tax identifier), and that they therefore typically require prior registration in the
country of declaration. Again, these systems have been designed and implemented from a purely
national perspective: if the system is usable by foreigners at all, then this is only the case by using an
e-signature solution offered in the country of declaration. Finally, income tax applications again show
the full scale of possible solutions, covering most varieties of electronic signatures and several forms
of electronic authentication.
However, income tax declarations tend have a smaller focus on non-nationals than either VAT
declarations or e-Procurement, since the vast majority of income tax declarations originate either
from citizens of a country, or at least from persons who have already been registered in local
database to meet their obligations under administrative, fiscal or social security law. For this reason,
the link between eID schemes and e-signatures tends to be stronger with income tax applications.
For the exact same reason, the business case for interoperability seems weaker for income taxes
than for VAT declarations and e-procurement, which explains to a certain extent why accessibility to
foreigners is considered a lower priority goal.
In that sense, income tax applications are a convenient first indication of a country’s main e-signature
policies: the user group is large and fairly homogeneous, allowing a single e-signature solution to
cover the needs of most users in a way that provides a large benefit for these users and for tax
administrations. From a negative point of view, the interest in interoperability is much smaller for
income declarations than for the other two applications discussed above.
149
Preliminary Study on Mutual Recognition of
eSignatures for eGovernment applications
November 2007
6 List of recommendations
150
Preliminary Study on Mutual Recognition of
eSignatures for eGovernment applications
November 2007
45
In the sense of Article 3.3 of the eSignature directive (cfr [RD3])
151
Preliminary Study on Mutual Recognition of
eSignatures for eGovernment applications
November 2007
152
Preliminary Study on Mutual Recognition of
eSignatures for eGovernment applications
November 2007
7 Conclusions
While all surveyed countries have integrated some form of e-signature functionality into their e-
government applications, the level of national harmonisation varies significantly. Although a smaller
number of countries have implemented a uniform e-signature policy and infrastructure (e.g. in
Denmark or Estonia), most others are still recovering from a legacy of ad hoc solutions in need of
harmonisation. Thus, insofar as interoperability has been a concern from a regulatory perspective, the
focus has mostly been on creating national rather than cross border interoperability.
Secondly, there seems to be a definite trend towards the creation of a single centralised e-signature
infrastructure, which allows specific applications to simply ‘plug in’, thus ensuring a better (more
homogeneous) user experience and minimising redundancy. This is equally true in countries which
are attempting to align sector specific solutions (e.g. Bulgaria) as for countries that have had diverse
developments due to administrative/constitutional reasons (e.g. Germany). If continued, this trend will
obviously facilitate the realisation of cross border interoperability.
From a regulatory perspective, the most significant provisional conclusion seems to be that the
surveyed countries have made a rather extensive (and possibly excessive) use of the possibility
allowed by the Directive to impose additional requirements to the use of e-signatures in public sector
applications. Specifically, and regardless of the precise method followed, all surveyed countries
exclusively allow certificates from formally accredited or recognised service providers, where foreign
CSPs are rarely if ever accredited or recognised. The practical result of this is that every aspiring user
of an e-signature in an e-government application first needs to address himself to the appropriate
CSP (typically outside of his own borders), thus creating a significant barrier to uptake by non-
nationals.
This situation seems rather contrary to the goal expressed in article 3.7 of the Directive, which stated
that any additional requirements imposed on the use of e-signatures within public sector applications
should be “objective, transparent, proportionate and non-discriminatory and shall relate only to the
specific characteristics of the application concerned.” Given the fact that most surveyed countries
have chosen or are evolving to one blanket model for all e-government applications requiring an
electronic signature, the practical consequence is that any imposed requirement covers a large
number of applications, regardless of its exact functionality, and that it practically stops non-nationals
from using foreign e-signature applications. It seems doubtful that national practices in this regard can
be reconciled with the Directive’s objectives of creating an Internal Market for e-signatures, an
ambition which included the public sector.
From a technical point of view standard and market trends are in general followed by applications.
This is a normal behaviour for any application in order to reduce development costs and deployment
delay (why re-invent the wheel when it already exists).
The availability and the usage of a national/sectoral/regional framework to authenticate users and to
provide e-signature services also reduce the deployment delay.
The natural evolution in the design of applications has to follow:
1. The national regulatory framework
2. The standards and the market trends
The observed trend concerning the application design is a tendency to migrate from the model 4 to
the model 3 in all cases where a legal and procedural framework exists at the national level.
Where technical frameworks are available at the national/sectoral/regional level a migration from the
model 3 to the model 1/2 can be observed.
The present situation concerning the European full interoperability is that we have a gap of guidance
between the regulation (enforce interoperability) and the way to achieve it at the organisational and
technical level. This situation leads to a situation where the Member States have to rely on
153
Preliminary Study on Mutual Recognition of
eSignatures for eGovernment applications
November 2007
themselves to establish interoperability, e.g. via bilateral or multilateral agreements. There appears to
be an urgent need for Community initiative in this domain.
The evolution of applications to a European e-signature full interoperability service for citizens or
businesses should follows the same rules (availability of a framework at the European level).
To answer one of the major issues that eGovernment applications are facing, i.e. signature validation,
the most significant recommendation is to set-up a Federation of Validation Authorities.
The concept is based on a unique European Validation Authority Gateway that would only act as a
gateway between National Validation Authorities of the Member States. In our model, to validate an
eSignature, an eGovernment application deployed in country X would have to contact its own
National Validation Authority. If the certificate used to electronically sign originated from a
Certification Authority of country Y, then the Validation Authority from country X would have to
contact the European Validation Authority Gateway, which will in its turn redirect the validation
request to the National Validation Authority of country Y. The whole validation process will be done in
country Y in compliance with the national rules governing the certification authority and with the
knowledge of the semantics behind the certificate fields.
As we know that not all Member States will set-up a National Validation Authority (like country Z in the
figure) or perhaps not all at the same time, we also propose to set-up a Generic Validation Authority
at the European level allowing eGovernment applications of Member States which do not have a
National Validation Authority to participate to the Federation anyway.
We propose to build this European Generic Validation Authority on the basis of the European
Bridge/Gateway CA. In addition to the services provided by the EBGCA, i.e. distribution of Trusted
Status Lists, we suggest to implement certificate validation services for all CSPs belonging to
Member States which have not set-up their own National Validation Authority.
Root
Root Root
TSLs CA
CA
CA
CAs
EU Validation Authority Gateway
Generic Validation Authority
Web Services
crl – ocsp
Request signature
Request signature
validation
Sign Sign
Sign Sign User
User
certificate
certificate
154
Preliminary Study on Mutual Recognition of
eSignatures for eGovernment applications
November 2007
The main advantage of the whole concept is to provide a step-wise approach allowing Member States
to set-up a National Validation Authority at their best convenience, not necessarily at the same time in
every Member State.
155
Preliminary Study on Mutual Recognition of
eSignatures for eGovernment applications
November 2007
156
Preliminary Study on Mutual Recognition of
eSignatures for eGovernment applications
November 2007
157
Preliminary Study on Mutual Recognition of
eSignatures for eGovernment applications
November 2007
158
Preliminary Study on Mutual Recognition of
eSignatures for eGovernment applications
November 2007
159
Preliminary Study on Mutual Recognition of
eSignatures for eGovernment applications
November 2007
160
Preliminary Study on Mutual Recognition of
eSignatures for eGovernment applications
November 2007
161
Preliminary Study on Mutual Recognition of
eSignatures for eGovernment applications
November 2007
162
Preliminary Study on Mutual Recognition of
eSignatures for eGovernment applications
November 2007
163
Preliminary Study on Mutual Recognition of
eSignatures for eGovernment applications
November 2007
• The sum is lower than the number of surveyed applications (90). This can happen because
not all applications have answered all questions of the survey questionnaire.
Qualified Qualified
Signature type simple advanced
certificate signature
10 37 39 25
Virtual
Smart
Token type user/pass soft USB smart
Card
card
6 43 23 71 4
Signed
XML PDF Web-Form files ASCII
document type
18 12 14 10 4
The type of signature which detaches clearly of the general tendency is "qualified/based on qualified
certificate". However the type of signature "advanced" is always quite present.
The figure below represents the signature type support by applications.
164
Preliminary Study on Mutual Recognition of
eSignatures for eGovernment applications
November 2007
Signature type
45
40
35
30
25
20
15
10
5
0
si mpl e advanced Qual i f i ed cer ti f i cate Qual i f i ed si gnatur e
Applications have stated that they support multiple type of token but the most supported one is the
Smart card.
The figure below represents the token type support by applications.
Token type
80
70
60
50
40
30
20
10
0
user / pass sof t USB Smar t Car d Vi r tual Smar t
Car d
Applications sign or required that specific documents type are signed. Some of them support different
type of signed document but this not a general trend.
The figure below represents the trend for application (“files” means not PDF and not XML file type).
165
Preliminary Study on Mutual Recognition of
eSignatures for eGovernment applications
November 2007
20
18
16
14
12
10 Series1
8
6
4
2
0
XM L PDF Web-Form files ASCII
Signing tool
30
25
20
15 Series1
10
0
Adobe Acrobat Applet / Act iveX eM ail client other t ools
Italy “Project CRS-SISS (Carta Regionale dei Servizi – Sistema Informativo Socio
Sanitario) » application:
Question: “What are the software requirements on the client side (e.g. OS/specific
driver/middleware) for the use of eSignature?”
166
Preliminary Study on Mutual Recognition of
eSignatures for eGovernment applications
November 2007
Question: “What are the software requirements on the client side (e.g. OS/specific
driver/middleware) for the use of eSignature?”
Answer: “…On-line version works only on Internet Explorer 6.0 XML602 Filler woks only
on Windows....”
Question: “What are the software requirements on the client side (e.g. OS/specific
driver/middleware) for the use of eSignature?”
Question: “What are the software requirements on the client side (e.g. OS/specific
driver/middleware) for the use of eSignature?”
Answer: “…For the purposes of signing in .p7s format of the files that are to be attached,
a particular software DSTOOL is used. This software is freely downloadable from the
website of NIA....”
167
Preliminary Study on Mutual Recognition of
eSignatures for eGovernment applications
November 2007
Italy “Telemaco, Signed Electronic Filing for Business Entities –Balance Sheets”
application:
Question: “What are the software requirements on the client side (e.g. OS/specific
driver/middleware) for the use of eSignature?”
Answer: “A software to sign the electronic declaration according to the Italian laws.
“Dike” is the InfoCamere free software for the digital signature available for Windows,
Mac platforms and a Linux distribution….”
168