Preliminary Study on Mutual Recognition of eSignatures for eGovernment applications 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:

Author’s name: Siemens - Time.lex Company’s name: Siemens IT Solutions and Services - Time.lex Company’s address (optional): Company’s logo (optional)

Contract No. 1, Framework contract ENTR/05/58-SECURITY, Specific contract N°1

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.

This paper can be downloaded from the IDABC website: http://europa.eu.int/idabc/ http://ec.europa.eu/idabc/en/document/6485/ © European Communities, 2007 Reproduction is authorised, except for commercial purposes, provided the source is acknowledged.

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 1 1.1 1.2 2 2.1 2.2 3 4 4.1 DOCUMENTS APPLICABLE DOCUMENTS REFERENCE DOCUMENTS GLOSSARY DEFINITIONS ACRONYMS INTRODUCTION ANALYSIS
EGOVERNMENT AND ESIGNATURE REGULATIONS

3 7 7 7 8 8 10 11 14 14 14 14 14 16 18 18 24 27 28 37 41 41 42 42 43 44 47 47 48 54 62 62 64 64 68

4.1.1 THE EUROPEAN LEGAL FRAMEWORK 4.1.1.1 Basic principles 4.1.1.2 Public sector clause: article 3.7 4.1.1.3 eSignatures and authentication 4.1.2 NATIONAL REGULATORY APPROACH MODELS 4.1.2.1 General strategy 4.1.2.2 National competence and organisation 4.1.3 NATIONAL ESIGNATURE REQUIREMENTS 4.1.3.1 Dominant Signature types 4.1.3.2 Choice of Unique identifiers 4.1.3.3 Technological choices 4.1.3.4 Cross border acceptance 4.1.4 NATIONAL TRENDS AND EXPECTATIONS 4.1.4.1 State of eSignatures 4.1.4.2 Interoperability requirements 4.1.4.3 Long term validity and storage 4.2
EGOVERNMENT APPLICATIONS USING ELECTRONIC SIGNATURES

4.2.1 APPLICATION APPROACH MODELS 4.2.1.1 Group 1: shared service approach 4.2.1.2 Group 2: ad-hoc approach 4.2.2 CLASSIFICATION BY MODEL 4.2.2.1 Introduction 4.2.2.2 Model 1: One-stop shop model 4.2.2.3 Model 2: common eSignature framework model 4.2.2.4 Model 3: Generic CSPs model

4

Preliminary Study on Mutual Recognition of eSignatures for eGovernment applications November 2007

4.2.2.5 Model 4: Application Specific CSP model 4.2.3 CLASSIFICATION BY COUNTRY 4.2.4 CLASSIFICATION BY SECTOR 4.2.4.1 eProcurement applications 4.2.4.2 Income tax applications 4.2.4.3 VAT applications 5 5.1 5.2 IMPACT ASSESSMENT AND RECOMMENDATIONS INTRODUCTION DEFINITIONS 5.2.1 SUPERVISION VS. ACCREDITATION 5.2.2 INTEROPERABILITY 5.2.2.1 Examples 5.2.3 CROSS-BORDER 5.2.3.1 Examples 5.2.4 NON-NATIONAL RESIDENTS IDENTIFIED INTEROPERABILITY ISSUES AND RECOMMENDATIONS 5.3.1 AT LEGAL LEVEL 5.3.1.1 National perspective 5.3.1.2 Security levels – legal qualification of signature types 5.3.1.3 European eSignature directive compliance 5.3.1.4 Ad-Hoc solutions 5.3.1.5 Multiple government levels 5.3.1.6 National rules on identifiers 5.3.1.7 Conclusions 5.3.2 AT ORGANISATIONAL LEVEL 5.3.2.1 Link to eID schemes 5.3.2.2 Mutual recognition 5.3.2.3 Atypical registration procedures 5.3.2.4 Multiple speeds 5.3.2.5 Conclusions 5.3.3 AT TECHNICAL LEVEL 5.3.3.1 Incompatible use of identifiers 5.3.3.2 Signature Type 5.3.3.3 Dedicated Interface requirements 5.3.3.4 Recommendations 5.3.3.5 Conclusions 5.3.3.6 Signature format 5.3.3.7 Signature validation 5.3.3.8 Validation protocol 5.3.3.9 Conclusions LIST OF POTENTIAL INTEROPERABILITY ISSUES AT TECHNICAL LEVEL 5.4.1 KEY LENGTH

72 74 77 77 80 86 92 92 92 92 92 94 95 97 101 103 103 103 105 107 107 108 109 109 110 110 111 112 115 116 117 117 121 123 124 124 124 125 142 143 144 144

5.3

5.4

5

Preliminary Study on Mutual Recognition of eSignatures for eGovernment applications November 2007

5.4.1.1 Problem description 5.4.2 CLIENT SOFTWARE 5.4.2.1 Problem description 5.4.3 HARDWARE 5.4.3.1 Problem description 5.5 INTEROPERABILITY ISSUES IN KEY E-GOVERNMENT SECTORS 5.5.1 EPROCUREMENT 5.5.2 VAT DECLARATIONS 5.5.3 INCOME TAXES LIST OF RECOMMENDATIONS CONCLUSIONS ANNEX A: PATTERNS CROSS-COMPARISON T HE COMPREHENSIVE REGULATORY APPROACH T HE CENTRALISED REGULATORY APPROACH T HE EPROCUREMENT SECTOR T HE ET AX AND EVAT SECTORS ANNEX B: TECHNICAL TRENDS SUMMARIZED

144 144 144 144 144 144 145 147 148 150 153 156 156 158 161 162 164

6 7 8 8.1 8.2 8.3 8.4 9

6

Preliminary Study on Mutual Recognition of eSignatures for eGovernment applications November 2007

1 Documents
1.1 Applicable Documents
[AD1] Framework Contract ENTR/05/58-SECURITY

1.2 Reference 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 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/eurlex/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://eurlex.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/eurlex/pri/en/oj/dat/2004/l_134/l_13420040430en00010113.pdf [RD8] [RD9]

[RD4]

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

Advanced electronic signature: an electronic signature which meets the following requirements: (a) it is uniquely linked to the signatory; (b) it is capable of identifying the signatory; (c) it is created using means that the signatory can maintain under his sole control; and (d) it is linked to the data to which it relates in such a manner that any subsequent change of the data is detectable; Again, this definition may cover non-PKI solutions.

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
A2A ..............................................Administration to Administration A2B .............................................. Administration to Businesses A2C .............................................. Administration to Citizens CA................................................ Certification Authority CRL.............................................. Certificate Revocation Lists CSP.............................................. Certificate Service Provider eID ...............................................Electronic Identity OCSP ...........................................Online Certificate Status Protocol OTP..............................................One-Time Password PKCS ...........................................Public-Key Cryptography Standards PKI ...............................................Public Key Infrastructure SA ................................................ Supervision Authority SOAP ........................................... Simple Object Access Protocol SCVP ...........................................Server-based Certificate Validation Protocol SSCD ...........................................Secure Signature Creation Device USB.............................................. Universal Serial Bus TTP ..............................................Trusted Third Party TSA..............................................Time Stamp Authority TST ..............................................Time Stamp Token XAdES ......................................... XML Advanced Electronic Signature XML ............................................. eXtensible Markup Language XML-DSIG.................................... XML Digital Signature

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.

This report aims at: comparing existing solutions and requirements from the countries and identifying similarities and differences on the legal as well as on the technical levels. A topology of eGovernment applications/services will be built based on their legal and technical requirements. detecting potential interoperability issues, i.e. legal and technical obstacles for using electronic signatures in cross-border e-government transactions.

-

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

-

prepare conclusions and recommendations on addressing interoperability issues related to the mutual recognition of electronic signatures for eGovernment applications/services

The report focuses on legal as well as on technical aspects of electronic signatures in e-government applications. The legal framework pertaining to the use of e-signatures in e-government applications can be a deciding factor in its uptake. Particularly, the framework needs to meet the requirements of all involved parties: it needs to offer legal certainty with regard to the requirements to be met by the used esignature 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
4.1 eGovernment and eSignature regulations
4.1.1 The European legal framework

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.

4.1.1.1 Basic principles 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.”

4.1.1.2 Public sector clause: article 3.7 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:

“Article 3 – Market Access 1. Member States shall not make the provision of certification services subject to prior authorisation. 2. Without prejudice to the provisions of paragraph 1, Member States may introduce or maintain voluntary accreditation schemes aiming at enhanced levels of certification-service provision. All conditions related to such schemes must be objective, transparent, proportionate and non-discriminatory. Member States may not limit the number of accredited certification service providers for reasons which fall within the scope of this Directive. 3. […]” 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:

“Also, the Directive’s rules on voluntary accreditation seem to be misunderstood by national governments. Many European countries wrongfully consider voluntary accreditation schemes as a means of controlling whether or not a Certification Service Provider operates in compliance with the provisions of the Directive. Another alarming observation is that the voluntary accreditation schemes, in many European countries, are in practice, not really voluntary. A typical example being that many national e-government programmes only accept accredited CSPs to participate in the programme, and thus indirectly oblige a CSP to get an accreditation. This evolution is certainly not in line with the Directive’s vision. Concerning the so-called ‘public sector exception’ of Article 3.7, which allows Member States to make the use of electronic signatures in the public sector subject to possible additional requirements, we have seen divergences in both the interpretation and implementation of this provision. It seems clear that in many countries the use of electronic signatures in the public sector is subject to additional (security) requirements. Communicating electronically with public authorities is in many countries possible only through the use of signatures based on a Qualified Certificate issued by an accredited CSP. Member States need to be reminded that applying additional conditions can only be justified by objective reasons and should only relate to the specific characteristics of the application concerned. Also, Member States need to ensure that basic competition rules are not being infringed by their initiatives.” (p.5)

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

Finally, in its recommendations, the ELSIGN Study stated:

“[…] 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.

4.1.1.3 eSignatures and authentication 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/modinisidm/twiki/bin/view.cgi/Main/GlossaryDoc#4_5_Authentication
9

See inter alia the Modinis eIDM Glossary, https://www.cosic.esat.kuleuven.be/modinisidm/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 nonrepudiation, 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 egovernment 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

Example: the Maltese approach:
“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.

4.1.2 National regulatory approach models

A first question that needs to be assessed is how the surveyed countries generally regulate their esignature 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.

4.1.2.1 General strategy 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.

Example: the Belgian approach:
“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

Country Belgium Croatia Cyprus Czech Republic Denmark Estonia Finland France

Normative source: The act of 9 July 2001 laying down a legal framework for electronic signatures and certification services Electronic signature act, Narodne novine, no. 10/2002 Legal Framework for Electronic Signatures and Associated Matters Law of 2004 Act on electronic signature 227/2000 Coll. Act no. 417 of 1 October 2000 on Electronic Signatures Digital Signature Act (hereinafter DSA) on March 8, 2000 The Act on Electronic Signatures (14/2003); and the Act on Electronic Services and Communication in the Public Sector (13/2003) Act of 13 March 2000 regarding several provisions related to electronic documents and the electronic signature; and the Arrêté of 26 July 2004 with regard to the qualification of certification service providers issuing digital certificates and to the accreditation of the bodies in charge of the evaluation of CSPs. Presidential Decree 150/2001 of 25 June 2001 Act XXXV of 29 May 2001 on electronic signatures Electronic Documents Law effective as of 1 January 2003 Law on Electronic Signature No VIII-1822 of 11 July 2000 Regulation of 1 June 2001 on electronic signatures, electronic payments and the creation of an electronic commerce committee Act of 8 May 2003 on electronic signatures Regulation of the Ministry Council from August, 7th, 2002 concerning technical and organisational requirements for qualified certification authorities, certification policies for qualified certificates issued by them, and technical requirements for secure signature creation and verification devices Law no. 455/2001 regarding the electronic signature Act of 15 March 2002 on electronic signature Act on Qualified Electronic Signatures

Greece Hungary Latvia Lithuania Luxembourg The Netherlands Poland

Romania Slovakia Sweden

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, einclusion, 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

Example: the Austrian approach:
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: […]”

Example: the German approach:
“On 13 September 2006 the federal Government passed a new programme with the name “EGovernment 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.”
th

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:

Country
Austria Germany Italy Portugal Slovenia Spain Turkey

Normative source:
The E-Government Act of 1 March 2004 E-Government 2.0 programme Extensive set of rules, including d.lgs. 82/05, the Digital Administration Code (“Codice dell’amministrazione digitale” Resolution of the Council of Ministers No. 108/2003 the Plan of Action for the EGovernment eGovernment Strategy of the Republic of Slovenia for the period 2006 to 2010 Plan de Medidas 2006-2008 para la mejora de la Administración (Measures Plan to improve the Administration The Information Society Transformation Policy (high level action plan)

21

Preliminary Study on Mutual Recognition of eSignatures for eGovernment applications November 2007

4.1.2.1.3 Sector Based 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 esignature solutions have been introduced.

Example: the Maltese approach:
“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: i. the Inland Revenue Department’s (IRD) eGovernment services for: • on-line submission of social security forms (for employers who employ ten or more employees) • on-line submission of tax and social security forms and the related payments of tax contributions (for Tax Practitioners for their corporate taxpayers) ii. the Vehicle Licenses Online for: • vehicle-owners who wish to pay their road license online • vehicle-owners who wish to check the due date of the next Vehicle Roadworthiness Testing • Insurance agents who wish to provide the road-license payment to their clients through an authenticated login”

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

Country
Malta

Normative source:
Specific systems for internal revenue and transportation sectors apart from the generic regulation ( Chapter 426 of the Laws of Malta, subsequently amended by Legal Notice 251 of 2006) Electronic Commerce Act 2000 is applicable to e-signatures in general, but sector specific rules exist as well

Ireland

4.1.2.1.4 Ad hoc legal frameworks 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.

Example: the Bulgarian approach:
“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.”

A similar situation presently exists in Slovenia:

Example: the Slovenian approach:
“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:

Example: the UK approach:
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 selffinancing 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 egovernment 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:

Country
Bulgaria United Kingdom

Normative source:
The Electronic Documents and Electronic Signatures Act is an attempt to coordinate eSignature policy; but harmonization is not yet complete. Existing legislation is being amended on a case by case basis.

4.1.2.2 National competence and organisation 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.

Example: the Belgian approach:
“eGovernment, in particular horizontal integration, is driven by the following services: 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

Similarly, the German report notes:

Example: the German approach:
“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 13 14 15

http://www.bundonline2005.de/ http://www.bmi.bund.de/ http://www.magazine-deutschland.de/bl_overview.php

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:

Example: the Polish approach
“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.”

4.1.3 National eSignature requirements

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

4.1.3.1 Dominant Signature types 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.

4.1.3.1.1 Overview table of signature requirements In this section, we will provide a short overview of the requirements imposed on the principal esignature 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.

Country Austria

Signature requirements Qualified signature

Detail / Other info The so called ‘Citizen Card concept’ is a voluntary concept, typically but not necessarily (e.g. mobile phones) rolled out through smart cards. Uses sector specific variations on a unique ID number (the so called ‘SourcePIN’). Foreign solutions can be integrated by mapping. So called ‘administrative signatures’ are being phased out (deadline: end 2007), but are considered as equivalent to qualified signatures.

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

Country Belgium

Signature requirements Qualified signature

Detail / Other info Through mandatory eID card containing national register number. Qualified soft certificates from accredited CSPs are becoming secondary to the eID card. The so called ‘Universal Electronic Signature’, a soft certificate containing the Uniform Citizen Number. Software certificate from (one) accredited CSP Signature functionality is to some extent emulated through authentication procedures, but no real e-signature applications were identified. Soft certificate from accredited CSP, can be stored on smart card if desired So called ‘OCES’, a soft certificate containing a personal identification number (but not the holder’s central personal number, which is the unique identifier used in the public sector). Through mandatory eID card containing personal ID number. The TUPAS bank identification system is a two-factor password authentication method, which does not use signatures. In contrast, the FINEID system is an eID card with certificates for authentication and signatures. Soft non-qualified certificate in compliance with PRIS V1 from an accredited CSP, can be stored on smart card or USB stick if desired Soft certificate from accredited CSPs, can be stored on smart card if desired Electronic signatures are only used in specific projects by public officials, not yet by the general public. Soft certificates from accredited CSPs, often stored on smart cards. The main system is the Irish Public Services Broker, which functions as a central portal using a username/password system for authentication purposes. However, the outcome is described as a simple signature. For a limited number of user groups, qualified signatures are also in use. Certificates from accredited CSPs using SSCDs, usually delivered through the eID card (an authentication card issued by municipalities) or a national services card (a combination authentication/signature card issued by several public administrations). Development is still in early stages: the sole CSP issuing qualified software certificates thus far is Latvijas Pasts, and the sole application is tax declaration.

Bulgaria Croatia Cyprus

Qualified certificate Qualified certificate Authentication

Czech Republic Denmark

Qualified certificate Advanced signature

Estonia Finland

Qualified signature Authentication; qualified certificate

France

Advanced signature Qualified signatures Qualified certificate Advanced signature and qualified certificate Simple and qualified electronic signature / Authentication Qualified signature

Germany Greece Hungary

Ireland

Italy

Latvia

Qualified signature

29

Preliminary Study on Mutual Recognition of eSignatures for eGovernment applications November 2007

Country Lithuania

Signature requirements Qualified signature / Authentication

Detail / Other info There are some services, based on electronic signature (not only for authentication), Citizens can read legal acts published in official magazine (http://www.valstybes-zinios.lt). For authentication in government services portal (http://www.epaslaugos.lt/govgate/index.do?language=lt) is possible to use qualified certificates or banking systems. An advanced electronic signature on a smart card is offered by LuxTrust; qualified certificates are planned but not yet rolled out. In practice, username/password authentication is frequently used instead of electronic signatures. The baseline solution is the eID (electronic identity) which can be issued to the holders of a Maltese eID card, and which consists only of a username and password. Future implementations will rely on advanced and qualified certificates for higher levels of security as required by the application (not yet implemented). Both PKI Overheid (a hierarchy of accredited CSPs, using soft certificates) and DigiD (actually an authentication system; requires a Social Security Number) are in common use; an eID card by the name of eNIK is planned. Commercial CA certificates (from accredited CSPs) are allowed for some applications and available to foreigners. Advanced and qualified certificates are issued by accredited CSPs, either as soft certificates or on a smart card. A requirement for qualified certificates is most common in egovernment applications, although many applications require their own solutions. Present status is still fragmented. Advanced and qualified certificates are issued by commercial CSPs, either as soft certificates or on a smart card; authentication functionality is used as well. An e-Card with a qualified signature certificate is planned and will likely become the dominant technology in the future, but it has not yet been deployed. Soft certificate from accredited CSPs. Qualified certificate from accredited CSPs stored on SSCD or soft certificates, often stored on smartcards. An eID card is planned No uniform policy yet, but most applications rely on qualified software certificates from accredited CSPs. Smart cards will be deployed to the public in 2007-2008 (public sector officials already use smart cards). The mandatory eID card (DNI) contains qualified certificates for authentication and e-signatures. While deployment has begun only recently, it will likely become the dominant technology in the future. Soft certificates from accredited CSPs are also in common use; they can be stored on a smart card.

Luxembourg

Advanced signature / authentication Authentication / advanced signature and qualified certificate

Malta

The Netherlands

Authentication / Qualified certificate

Poland

Advanced signature

Portugal

Advanced/qualified signatures / Authentication

Romania Slovakia

Qualified certificate Advanced and qualified signatures Qualified certificate

Slovenia

Spain

Qualified signature

30

Preliminary Study on Mutual Recognition of eSignatures for eGovernment applications November 2007

Country Sweden

Signature requirements Qualified signature (see comment)

Detail / Other info Swedish eIDs (either soft certificates or smart cards) can contain certificates for authentication and e-signature purposes, and contain the Swedish personal identity number. These eIDs are issued by several recognised private sector institutions (typically banks). It is noteworthy that the issuing banks do not declare their certificates to be qualified, but that they are in practice accorded a trust level which seems comparable. The general legal framework is currently considered to be unclear, stressing only the use of qualified certificates as a prerequisite for equivalence to handwritten signatures. No egovernment applications using e-signatures were identified. No rigid distinction between authentication and signature. Access through the Government Gateway Portal (either userID/password or certificate based, depending on the application) permits signature functionality. CAs must be accredited, but advanced/qualified certificates are generally not a formal criterion.

Turkey

Qualified certificate

United Kingdom

Authentication / Simple certificate

4.1.3.1.2 Typical and atypical examples 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 first example is the Danish solution model:

Example: the Danish approach
“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

Example: the German approach
“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.

Example: the Estonian approach
“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.

4.1.3.1.2.3 The Dutch example – authentication as an interim solution

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

The Dutch example:
“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 (SOFInumber) 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.

4.1.3.1.2.4 The Finnish approach – public/private sector collaboration

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.

Example: the Finnish approach
“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.

4.1.3.1.2.5 The Bulgarian approach – higher regulatory threshold

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:

Example: the Bulgarian approach:
“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:

Example: the Bulgarian approach:
“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

Example: the Austrian approach:
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.

4.1.3.2

Choice of Unique identifiers

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 nonnationals 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).

Example: the Danish approach:
“At the moment only persons with a Danish [Central Personal Register]-number can have an OCESpersonal 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

Example: the Belgian approach:
“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 nonprotected 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.

Example: the Danish approach:
“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 esignature 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.

Example: the Belgian approach:
“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:

Example: the Slovenian approach:
“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:

Example: the Finnish approach
“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:

Example: the Austrian approach:
“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

Authority for natural persons is not done for legal persons.”

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:

Example: the Polish approach
“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.”

4.1.3.3

Technological choices

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

4.1.3.4

Cross border acceptance

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: • by relying on the aforementioned national register numbers as unique identifiers for certificates (which essentially precludes any non-national entity from using the e-signature application unless they are willing to take the disproportional step of establishing themselves in the service’s country of origin); or by using national register numbers as an initial identifier necessary in the application procedure for a certificate “recognized” by the public administration (foreigners without such national identifier are automatically excluded from the application procedure); or by allowing only a limited group of recognised (i.e. accepted from a purely practical perspective) or accredited (i.e. having successfully completed a formal voluntary accreditation process as defined in the eSignatures Directive article 2.13) CSPs to offer valid certificates. It should be noted that no surveyed country requires a CSP to be established within its borders before it can be deemed acceptable; thus, on the surface this would not appear to be an encumbrance to cross-border interoperability. However, in practice not a single country has identified a foreign CSP who has received the required accreditation or recognition18. This is not so much a result of an unwillingness to accredit such CSPs, but rather for an insufficient business case to CSPs to justify requesting the accreditation or recognition.

• •

The result however is that validation of non-national certificates is not functional in practice, meaning that national PKI hierarchies remain largely isolated by country.

4.1.4 National trends and expectations
A summary of trends and expectations can be provided at this stage.

4.1.4.1 State of eSignatures 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.

Example: the Austrian approach:
“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.

4.1.4.2

Interoperability requirements

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.

Example: the Bulgarian approach:
“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

Example: the Danish approach:
“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.

4.1.4.3

Long term validity and storage

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:

Example: the Slovenian approach:
“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 metadata 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:

Example: the Estonian approach:
“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.

This kind of secure log system provides for dual purposes: • auditability – in case of disputes there are means to prove that some validity confirmation was (not) issued, was issued before/after some other event, etc. • long term validity preservation of digital signatures – even after complete breakdown of all keys and RSA algorithm one can prove that document signed at past is valid – by matching confirmation data with log data. 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.

4.2 eGovernment applications using electronic signatures
4.2.1 Application approach models
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

4.2.1.1 Group 1: shared service approach 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).

4.2.1.1.1 Model 1: One-stop shop model 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 costeffective 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

Browser

Soap Appl

Portal Citizen_________________Application

ID Management eSignature

Application

Application

Application

CSP’s

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

Example: the UK approach By deciding upon the portal approach for access to eGovernment services, the UK has been able to implement a wide, and growing, range of services to the public and to commercial organisations without having to expend repeated effort in getting the identity management piece implemented. By this means also, if (or when) the Government implements an eID card it will be relatively straightforward to make use of it in providing access to all of the services that are available via the Government Gateway.

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.

4.2.1.1.2 Model 2: common eSignature framework 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 webbased 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

Application

Application

Application

eSignature framework

CSP’s

CSP’s

CSP’s

Example: the Spanish approach The launch of the electronic national identity card has been complemented by the creation of a multiPKI Validation Platform supported by the MAP that provides freely eSignature and eCertificate validation services to eGovernment services (currently there are about 180 available services using the platform). The multiPKI Validation Platform validates electronic certificates and eSignatures issued by the main Certification Authorities of the country, among them, the eID Certification Authority, and also provides time-stamping services and an eSignature program that allows citizens to eSign documents in various eSignature standards locally before being submitted over the Internet. The service is offered to eGovernment applications of all public administrations (state, regional and local). The platform has been built up on open source and open standards.

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 5 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 0 us er / pas s s of t USB Smar t Car d V i r t ual 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 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

Signed document type
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

Example of other signing tools:

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….”

4.2.1.2 Group 2: ad-hoc approach 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 webbased 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, certificatebased authentication...

54

Preliminary Study on Mutual Recognition of eSignatures for eGovernment applications November 2007

4.2.1.2.1 Model 3: Generic CSPs model Usually, this model is implemented for two main reasons: • • Either, for historical reasons: no national framework / model existed at application development time; Or application specific security/ functional requirements (e.g. specific key size) could not be met by national framework/model.

It must be noted that many of the applications developed following this model have planned to move to a shared service approach in the future.

Application

Application

Application

CSP’s
Technical aspects specific to this model:

CSP’s

eSignature type: The eSignature type is imposed by the application: can be either of type Simple, Advanced or Qualified. eSignature validation: Every application validates eSignatures against CSPs they trust. Credential or token type: The credential/token type 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). … Organisational aspects: CSPs: Applications of this model may support one or several CSPs but addition of a new CSP requires a modification of the application. Interoperability aspects Applications of this model are not closed to interoperability but to achieving this interoperability would require sound modifications of every application.

55

Preliminary Study on Mutual Recognition of eSignatures for eGovernment applications November 2007

Example: the Slovenian approach To speed up the rate at which on-line public services are made available for citizen and companies several steps have already been made. As stated in Slovenian eGovernment Strategy national interoperability framework is needed to attain the planned development of eGovernment until 2010. SEP-2010 defines interoperability framework as linking of all elements (standards and recommendations, uniform architecture, open standards and solutions, guidelines) in a national interoperability framework for eGovernment services and solutions, which will provide organisational, semantic and technical interoperability (including e-signature) and at the same time creative cooperation in the preparation of an interoperability framework for pan-European services. With this in mind the development of national interoperability framework has just started along with the broad program dedicated to the electronic connection and interchange of data between national registers. The two programs will be developed in parallel since they are to share common results and solutions. 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.

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

Signed document 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 5 0 Adobe Acrobat Applet/ActiveX eMail client other tools

Example of other signing tools:

Czech Republic “Publication system on public contracts – publication subsystem (eNotification) » application:

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

Hungary “Electronic Firm Registration/Electronic Company Register” application:

Question: “What are the software requirements on the client side (e.g. OS/specific driver/middleware) for the use of eSignature?”

Answer: “…They use ‘e-Szignó’, a professional signature creation application capable of creating ETSI TS 101 903 compliant XML signatures.....”

58

Preliminary Study on Mutual Recognition of eSignatures for eGovernment applications November 2007

4.2.1.2.2 Model 4: Application Specific CSP model 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

X
CSP CSP

Technical aspects specific to this model: eSignature type: Only Simple or Advanced eSignature. Applications based on this model do not provide for qualified eSignatures mainly because their own CSPs do not comply with the requirements imposed by national regulations. eSignature validation: Each application validates the certificate against its own CSP. Credential or token type: as the applications of this model provide their own CSP, usually they only support software-based credentials. Organisational aspects: CSPs: Applications operate their own CSP which is not accredited by a National Authority. Interoperability aspects Applications falling in this category provide no interoperability at all. It’s a strong design decision.

59

Preliminary Study on Mutual Recognition of eSignatures for eGovernment applications November 2007

Example: the Polish approach The situation is worse in the case of unqualified signatures usage. Usually they are used in closed systems, implemented for particular purposes and encompassing limited users’ populations. The tendency to establish more and more internal certification authorities for Public administration IT systems purposes is another serious mistake. Therefore it is hard to obtain interoperability in public administration systems themselves, but most of all it is the great problem for communication with external systems. For that problem two solutions could be considered: to use certificates issued by commercial CAs only, or to establish one or few CAs only for public administration purposes.

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
5 4 3 2 1 0 si mpl e adv anced Qual i f i ed c er 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 model.

60

Preliminary Study on Mutual Recognition of eSignatures for eGovernment applications November 2007

Token type
5 4 3 2 1 0 user / pas s sof t USB Smar t C ar d V i r t ual 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).

Signed document type
2,5 2 1,5 1 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 2 1,5 1 0,5 0 Adobe Acrobat Applet/ActiveX eMail client other tools

Example of other signing 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?”

Answer: “…Signature application implemented by CRS-SISS project....”

4.2.2 Classification by model
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.

Example: the Slovenian approach “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.”

63

Preliminary Study on Mutual Recognition of eSignatures for eGovernment applications November 2007

Example: the Bulgarian approach “Since at the present moment there are no unified rules concerning the development of the information systems of the state bodies enforced, the rules for acceptance, issuance, exchange and storage of electronic documents within the state administration and the integration of new eGovernment services is independent of any common strategy and thus it is not-coordinated. Every administrative body applies its own particular rules for the eGovernment services it provides but these rules are not in compliance with the rules, practices and requirements established by other bodies. A positive step for the development of the Bulgarian eGovernment and for ensuring the interoperability of the applications is the elaboration of draft of the new eGovernance Act and the adoption of the Bulgarian National Interoperability Framework.”

4.2.2.2 Model 1: One-stop shop model 4.2.2.2.1 List of applications belonging to the model Country Ireland Slovakia United Kingdom Application / Service Name Irish Public Services Broker - www.reachservices.ie Central Portal of Public Administration Government Gateway

4.2.2.2.2 Major differences observed 4.2.2.2.2.1 Software requirements The “Government Gateway” portal, officially, only supports access by a client with a Microsoft Operating System and a Microsoft Internet Browser.

UK “Government Gateway” application:

Question: “What are the software requirements on the client side (e.g. OS/specific driver/middleware) for the use of eSignature?”

Answer: “Windows 95 or NT 4 (SP3) or higher with Internet Explorer 5.01 or above”

4.2.2.3 Model 2: common eSignature framework model 4.2.2.3.1 List of applications belonging to the model Country Austria Application / Service Name FINANZOnline ( http://finanzonline.bmf.gv.at ) Electronic delivery (www.zustellung.gv.at)

64

Preliminary Study on Mutual Recognition of eSignatures for eGovernment applications November 2007

Country

Application / Service Name Meldebestätigung (https://meldung.cio.gv.at/egovMB/) Versicherungszeitenauszug – Link Public Procurement (pilot project tested with std AT certificate on smart card)

Belgium Bulgaria

Tax-on-Web (http://www.taxonweb.be) Online submission of annual income tax declarations VAT on Internet

Germany

eVergabe DEHSt Virtual Post Office (VPS2)

Denmark

ETHICS TastSelv Borger Virk.dk – a government portal for Danish businesses Netborger.dk

Estonia Spain

Internet Voting Registro Telemático (Online Registry) PROFIT Política Industrial (AVANZ@)

Finland

Lomake.fi public sector online forms service ElmaTYVI Pro at http://tyvi.elma.fi

Italy

Uniwex. Unimoney. Telemaco, Signed Electronic Filing for Business Entities – Balance Sheets PCTT (Processo Civile Telematico) Intercent-ER.

The Netherlands Slovakia Sweden

Elektronische aangifte EKR – Electronic communication interface eINK, Personal income taxes declarations (Sw: Inlämning av självdeklarationsuppgifter) http://www.skatteverket.se

65

Preliminary Study on Mutual Recognition of eSignatures for eGovernment applications November 2007

4.2.2.3.2 Major differences observed 4.2.2.3.2.1 Use of unique Identifier 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.”

Denmark Republic “OCES signature”:

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 OCESpersonal 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.”

Spain “Registro Telemático” application:

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

Spain “PROFIT Política Industrial (AVANZ@)” application:

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

Italy “PCTT (Processo Civile Telematico)” application:

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”

4.2.2.3.2.2 Signature type 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.

The Netherlands “Elektronische aangifte” application:

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

4.2.2.3.2.3 Use of virtual smart card

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

4.2.2.4 Model 3: Generic CSPs model 4.2.2.4.1 List of applications belonging to the model Country Bulgaria Application / Service Name Electronic market for small public procurements: Social security declarations on Internet eGovernment portal of the Bulgarian government ePortal of the Employment Agency Croatia e-VAT e-Pension Insurance Registration (e-Mirovinsko) Czech Republic Publication system on public contracts – publication subsystem (eNotification). Government Gateway - DIS system Tax-on-Web (http://adis.mfcr.cz/adis/jepo) Germany Spain OptiMahnOffice Taxes at Virtual Office DELT@ (Declaración Electrónica de Trabajadores Accidentados) LexNet RESEVI Finland Epoline eOLF (Epoline Online Filing)

68

Preliminary Study on Mutual Recognition of eSignatures for eGovernment applications November 2007

Country France

Application / Service Name TeleTVA TeleIR Achatpublic.com impots.gouv.fr Tele-c@rtegrise

Hungary

Electronic Firm Registration/Electronic www.irmcegszolgalat.hu

Company

Register Gate

Registration on the Client http://www.magyarorszag.hu/ugyfelkapu/regisztracio

Electronic tax and contribution declarations for citizens https://www.magyarorszag.hu/allampolgar/szolgaltatasok/jarulek for entrepreneurs https://www.magyarorszag.hu/allampolgar/szolgaltatasok/ebev.htm l Declaration of persons entitled for health insurance: DSend system Electronic messaging system transmitting time stamped and encrypted messages certified with electronic signature Electronically authenticated private pension fund declarations system e-Önkormányzat – eLocal Government Portal of the Local Government of Budapest 13th district http://www.bp13.hu/wps/portal/e-onkormanyzat: e-Local Government system of the Local Government of Hódmez•vásárhely, City with County Rights Italy The Netherlands Poland Portugal Romania Servizi telematici Entratel e Fisconline. TenderNed e-GIODO (http://egiodo.giodo.gov.pl) Online Incorporation of companies National Electronic System component e-government. (http://www.e-guvernare.ro),

e-Procurement (http://www.e-licitatie.ro).

69

Preliminary Study on Mutual Recognition of eSignatures for eGovernment applications November 2007

Country Slovenia

Application / Service Name e-Taxes (http://edavki.durs.si) e-SJU – Portal for electronic services of public administration (http://e-uprava.gov.si/storitve/) EPOS (e-business) Intrastat (http://intrastat-surs.gov.si/) One-Stop-Shop - State Portal for businesses (http://evem.gov.si) Annual Reports Financial Accounts Statistics Salary Reporting Multilateral Compensation Development IS on waste management field. On-line access to health insurance data E-business in agriculture Animal disease notification system – ADNS Registration Authority Application

Slovakia Sweden

eTax – Online electronic services ( http://www.drsr.sk ) eSKD (Electronic Tax Return, Sw: Inlämning av moms och arbetsgivaruppgifter) http://www.skatteverket.se Företagsregistrering (http://www.foretagsregistrering.se) (Company Registration eService)

Turkey United Kingdom

Inward Processing Regime Oil & Gas Trust Scheme

4.2.2.4.2 Major differences observed 4.2.2.4.2.1 Signature type Simple signature is not used by applications belonging to this model. 4.2.2.4.2.2 Software requirements 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

Czech Republic “Publication system on public contracts – publication subsystem (eNotification)” application:

Question: “External interface”

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

Croatia “e-VAT (e-PDV)” application:

“…the customer has to register electronic signature by the tax web site (http://www.poreznauprava.hr/e-porezna/OvlastenjaFull.asp) where appropriate software has to be downloaded and installed. “

4.2.2.4.2.3 Use of specific application identifier in the certificate 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.

United Kingdom “Oil & Gas Trust Scheme” application: When describing additional requirements for certificate fields: “These additional requirements include: … • “Subject – Organisation Unit” should hold an additional indicator (OGTS) after the entry to identify that the certificate has been issued in accordance with the Oil and Gas Trust Scheme, e.g. DTI (OGTS); …”

71

Preliminary Study on Mutual Recognition of eSignatures for eGovernment applications November 2007

4.2.2.5 Model 4: Application Specific CSP model 4.2.2.5.1 List of applications belonging to the model Country Croatia Ireland Ireland Italy Latvia Slovakia United Kingdom Application / Service Name University administration programme ISVU Revenue On-line Service ROS Companies Registration Office E-Filing Project CRS-SISS (Carta Regionale dei Servizi – Sistema Informativo Socio Sanitario). Electronic Declaration System (EDS) Electronic Public Procurement (EVO) – eTendering module e-Conveyancing

4.2.2.5.2 Major differences observed 4.2.2.5.2.1 Use of additional client attribute In this example the identifier is the IP address of client workstation. The “University administration programme ISVU)” application uses the IP address, a username and a password to sign documents.

Bulgaria “University administration programme ISVU)” application:

Question: “Does the system rely on a simple / advanced / qualified / other signature?”

Answer: “System relies on electronic signature based on assigned username and password and also the IP address for that person”

4.2.2.5.2.2 Non standard eSignature/Document format 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

Latvia “Electronic Declaration System (EDS)” application:

Question: “Does the system rely on a simple / advanced / qualified / other signature?”

Answer: “The system relies on non-PKI eSignature authentication.”

Latvia “Electronic Declaration System (EDS)” application:

Question: “Expected future developments”

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

Latvia “Electronic Declaration System (EDS)” application:

Question: “Data structures processed by the application”

Answer: “Data are entered into eXtensible Mark-up Language (XML) format and processed in DUF, DBF formats.”

Latvia “Electronic Declaration System (EDS)” application:

Question: “How are the signature/certificate presented to the application?”

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

4.2.3 Classification by country
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.

Country Austria

Model model 2

Application / Service Name FINANZOnline ( http://finanzonline.bmf.gv.at ) Electronic delivery (www.zustellung.gv.at) Meldebestätigung (https://meldung.cio.gv.at/egovMB/) Versicherungszeitenauszug – Link Public Procurement (pilot project tested with std AT certificate on smart card)

Belgium Bulgaria

model 2 model 2

Tax-on-Web (http://www.taxonweb.be) Online submission of annual income tax declarations VAT on Internet

model 3

Electronic market for small public procurements: Social security declarations on Internet eGovernment portal of the Bulgarian government ePortal of the Employment Agency

model 4 Croatia model 3

University administration programme ISVU e-VAT e-Pension Insurance Registration (e-Mirovinsko)

Czech Republic

model 3

Publication system on public contracts – publication subsystem (eNotification). Government Gateway - DIS system Tax-on-Web (http://adis.mfcr.cz/adis/jepo)

Germany

model 2

eVergabe DEHSt Virtual Post Office (VPS2)

model 3 Denmark model 2

OptiMahnOffice ETHICS TastSelv Borger Virk.dk – a government portal for Danish businesses Netborger.dk

Estonia Spain

model 2 model 2

Internet Voting Registro Telemático (Online Registry)

74

Preliminary Study on Mutual Recognition of eSignatures for eGovernment applications November 2007

Country

Model

Application / Service Name PROFIT Política Industrial (AVANZ@)

model 3

Taxes at Virtual Office DELT@ (Declaración Electrónica de Trabajadores Accidentados) LexNet RESEVI

Finland

model 2

Lomake.fi public sector online forms service ElmaTYVI Pro at http://tyvi.elma.fi

model 3 France model 3

Epoline eOLF (Epoline Online Filing) TeleTVA TeleIR Achatpublic.com impots.gouv.fr Tele-c@rtegrise

Hungary

model 3

Electronic Firm Registration/Electronic www.irmcegszolgalat.hu

Company

Register Gate

Registration on the Client http://www.magyarorszag.hu/ugyfelkapu/regisztracio

Electronic tax and contribution declarations for citizens https://www.magyarorszag.hu/allampolgar/szolgaltatasok/jarulek for entrepreneurs https://www.magyarorszag.hu/allampolgar/szolgaltatasok/ebev.htm l Declaration of persons entitled for health insurance: DSend system Electronic messaging system transmitting time stamped and encrypted messages certified with electronic signature Electronically authenticated private pension fund declarations system e-Önkormányzat – eLocal Government Portal of the Local Government of Budapest 13th district http://www.bp13.hu/wps/portal/e-onkormanyzat: e-Local Government system of the Local Government of Hódmez•vásárhely, City with County Rights Ireland model 1 model 4 Irish Public Services Broker - www.reachservices.ie Revenue On-line Service ROS Companies Registration Office E-Filing Italy model 2 Uniwex. Unimoney.

75

Preliminary Study on Mutual Recognition of eSignatures for eGovernment applications November 2007

Country

Model

Application / Service Name Telemaco, Signed Electronic Filing for Business Entities –Balance Sheets PCTT (Processo Civile Telematico) Intercent-ER.

model 3 model 4 Latvia The Netherlands Model 4 model 2 model 3 Poland Portugal Romania model 3 model 3 model 3

Servizi telematici Entratel e Fisconline. Project CRS-SISS (Carta Regionale dei Servizi – Sistema Informativo Socio Sanitario). Electronic Declaration System (EDS) Elektronische aangifte TenderNed e-GIODO (http://egiodo.giodo.gov.pl) Online Incorporation of companies National Electronic System component e-government. (http://www.e-guvernare.ro),

e-Procurement (http://www.e-licitatie.ro). Slovenia model 3 e-Taxes (http://edavki.durs.si) e-SJU – Portal for electronic services of public administration (http://e-uprava.gov.si/storitve/) EPOS (e-business) Intrastat (http://intrastat-surs.gov.si/) One-Stop-Shop - State Portal for businesses (http://evem.gov.si) Annual Reports Financial Accounts Statistics Salary Reporting Multilateral Compensation Development IS on waste management field. On-line access to health insurance data E-business in agriculture Animal disease notification system – ADNS Registration Authority Application Slovakia model 1 model 2 model 3 model 4 Sweden model 2 eServices of Trade Register EKR – Electronic communication interface eTax – Online electronic services ( http://www.drsr.sk ) Electronic Public Procurement (EVO) – eTendering module eINK, Personal income taxes declarations (Sw: Inlämning av självdeklarationsuppgifter) http://www.skatteverket.se

76

Preliminary Study on Mutual Recognition of eSignatures for eGovernment applications November 2007

Country

Model model 3

Application / Service Name eSKD (Electronic Tax Return, Sw: Inlämning av moms och arbetsgivaruppgifter) http://www.skatteverket.se Företagsregistrering (http://www.foretagsregistrering.se) (Company Registration eService)

Turkey United Kingdom

model 3 model 1 model 3 model 4

Inward Processing Regime Government Gateway Oil & Gas Trust Scheme e-Conveyancing

4.2.4 Classification by sector
4.2.4.1 eProcurement applications 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:

Country Austria Belgium

Model model 2 model 2

Signature requirements Qualified signature Qualified signature Qualified certificate

Detail / Other info http://www.auftrag.at; a pilot has been run, but use of the application is not yet generalised. http://www.jepp.be/; currently only the notification platform is available; but the legal framework indicates that qualified signatures will be required, likely through the national eID card. http://www.aop.bg; currently only the notification platform is available; but the legal framework indicates that the so called ‘Universal Electronic Signature’ will be used, a qualified soft certificate. Smaller procurements can be done through http://smallsrv.minfin.bg/), also using the Universal Electronic Signature. http://www.nn.hr/; no specific application, but electronic tenders are allowed under general regulations. No e-signature functionality yet. Opportunities are published through www.isvzus.cz; no specific application

Bulgaria

model 3

Croatia Cyprus Czech Republic

model 3 n.a. model 3

Qualified certificate None yet Advanced signature with qualified certificate Advanced signature Signatures are not required Authentication; no signature

Denmark Estonia

model 2 n.a.

http://www.innovasion.dk/, through the ETHICS application, using the so called ‘OCES’, an advanced soft certificate. Opportunities are published through https://riigihanked.riik.ee/ but this portal has e-signature functionality for authentication purpose on the basis of PIN1 code. Applications include http://www.hankintailmoitukset.fi, http://palvelut.tieke.fi/tati/, www.hymonet.com, www.kilpanet.com, http://www.hansel.fi/index.php?id=286&action=empty&lang=en&s=1. None of these use e-signatures at this time.

Finland

n.a.

77

Preliminary Study on Mutual Recognition of eSignatures for eGovernment applications November 2007

Country France Germany

Model model 3 model 2

Signature requirements Advanced signature Qualified signature and advanced signature None yet None yet

Detail / Other info www.achatpublic.com and www.marchespublics.net. http://www.evergabe-online.de/, a web platform using qualified (through smart card) and advanced (through soft certificate) signatures.

Greece Hungary

n.a. n.a.

No e-signature functionality yet. http://kszfweb.econet.hu/portal/; no e-signature functionality yet (although advanced electronic signatures should be valid, there is presently no application supporting their use). www.etenders.ie is the main portal, but thus far it does not use e-signature functionality. http://www.consip.it/ (or e.g. http://www.intercent.it/ for local procurements). In principle, the portal uses qualified signatures on a smart card, but for some more limited services simple signatures are also accepted. An eProcurement application exists, but it relies on a username/password system. CPPW is the main portal, but thus far it does not use e-signature functionality. www.marches.public.lu is the main portal, but thus far it does not use esignature functionality. http://www.contracts.gov.mt is the main portal, but thus far it does not use e-signature functionality. In 2006 a new site has been launched, www.tenderned.nl This site coordinates on a national level electronic Public Procurement Portals include www.ppp.pwpw.pl, www.e-przetarg.pl and www.etender.pl. Applications are being deployed, but do not use e-signatures yet. http://www.e-licitatie.ro

Ireland Italy

n.a. model 2

None yet Qualified signature

Latvia Lithuania Luxembourg Malta The Netherlands Poland Portugal Romania

n.a. n.a. n.a. n.a. model 3 model 3 n.a. model 3

None yet None yet None yet None yet Qualified signature Qualified signature None yet Qualified certificate and advanced signature Advanced signature None yet None yet Not specified

Slovakia Slovenia Spain Sweden

model 4 n.a. n.a. n.a.

https://evo.gov.sk is the main portal. Electronic Public Procurement (EVO) – eTendering module http://www.gov.si/mf/slov/index.htm is the main portal, but thus far it does not use e-signature functionality. http://catalogopatrimonio.meh.es/pctw/lic_electr.aspx is the main portal, but thus far it does not use e-signature functionality. No national e-procurement portal exists, but specific administrations may request offers and accept electronically signed submissions. There is no common norm for the signature type required. No application has been identified yet. http://www.gateway.gov.uk/. While e-signatures are technically allowed, all applications currently use a username/password authentication system instead of a signature.

Turkey United Kingdom

n.a. n.a.

None yet None yet

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 8%

Model 1 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
7 6 5 4 3 2 1 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

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

4.2.4.2 Income tax applications As reported by the national correspondents, the following signature types are required for existing income tax declarations applications:

Country Austria

Model model 2

Signature requirements Simple/Qualifi ed signature

Detail / Other info FINANZOnline (http://finanzonline.bmf.gv.at). providing services: • Portal application

To citizens: tax returns of employed persons, application for family allowance, personal income taxes of entrepreneurs, VAT declarations of entrepreneurs, inspection of tax accounts; To companies: VAT declarations, income tax declarations, corporation tax declarations; To municipalities: declaration of taxable basis for municipal tax

• •

80

Preliminary Study on Mutual Recognition of eSignatures for eGovernment applications November 2007

Country Belgium

Model model 2

Signature requirements Simple / Qualified signature

Detail / Other info Tax-on-Web (http://www.taxonweb.be). The system relies: • • either on the qualified signature provided by the e-ID card; or on the advanced signature provided by the federal token.

Note that the federal token is particularly interesting for people who are not yet in the possession of an e-ID but want to obtain access to secured online services. However, the token also presents certain limitations, specifically with regard to the user group (which only covers natural persons who possess three numbers, thus excluding legal entities and certain non-nationals, namely those who have no national identity card and can thus not present an identity card number). Thus, for users outside of this group (who have no e-ID card or token), the service is presently not accessible. Bulgaria model 2 Qualified certificate The system https://inetdec.taxadmin.minfin.bg/ relies on Universal Electronic Signatures. Note that the application collects the identification number (UCN) not from the electronic declaration but from the certificate supporting the electronic signature of the user. All tax declarations other than VAT declaration are not possible to be done in electronic form. TAXISnet (http://taxisnet.mof.gov.cy) is a special network provided free of charge by the Inland Revenue Department, through which Taxpayers-Natural Persons may submit initial Tax Returns by use of electronic communication methods. All kind of taxes can be declared on-line via the application tax-onweb (http://adis.mfcr.cz/adis/jepo) provided by the Czech Tax Administration. Note that Qualified certificates used for eSignature (adjoin to tax submission) must contain the unique identification of a taxpayer. Based on this identification the personal data of a subscriber can be determined. TastSelv Borger (http://tastselv.skat.dk/). The OCES signature can be used also for authentication.

Croatia Cyprus

n.a. n.a.

None yet None yet

Czech Republic

model 3

Advanced signature with qualified certificate

Denmark Estonia Finland

model 2 n.a. model 2

Advanced signature No information Qualified signature Advanced signature

A large amount of electronic forms and applications for multiple purposes, notably tax declarations, can be obtained from a website set up by the Ministry of Finance (www.lomake.fi). The central portal for tax declarations in France is http://www.impots.gouv.fr. For individuals, online tax declaration is possible and widely used. Users register with their unique fiscal number and a password, and thereafter receive an on-line certificate. After that, he/she fills in the form and uses the issued certificate to sign. The signature application is included into the TéléIR application.

France

model 2

Germany Greece

n.a. n.a.

No information None yet Income Tax Return Forms may be found electronically in at the Ministry of Economy and Finance Department’s website at: http://www.taxisnet.gr Electronic tax and contribution declarations for citizens (https://www.magyarorszag.hu/allampolgar/szolgaltatasok/jarulek)

Hungary

model 3

Advanced signature

81

Preliminary Study on Mutual Recognition of eSignatures for eGovernment applications November 2007

Country Ireland

Model model 4

Signature requirements Qualified signature

Detail / Other info Revenue On-line Service (ROS) is a central government online tax system for the following categories of taxpayers: - self-employed individuals, business, practitioners and, most recently, employees. The system is accessible at www.ros.ie. Note that Revenue Commissioners acts as its own Certification Authority.

Italy Latvia

model 2 model 4

Qualified signature Simple signature

Fisconline (http://fisconline.agenziaentrate.it) is targeted to individual tax payers and small enterprises. Electronic Declaration System (EDS) (http://www2.vid.gov.lv). Note that the system makes use of electronic signatures provided and managed by the State Revenue Service on the basis of a signed agreement. Electronic Tax Declaration System (EDS) (http://deklaravimas.vmi.lt) was launched in March 2004. It enables individuals and legal entities to submit tax reports in digital format (via Internet, e-mail, CD and etc.). The system does not use advanced / qualified eSignatures at the moment. The Ministry of Finances provides a (http://www.impotsdirects.public.lu/formulaires/index.html) electronic forms (Adobe Acrobat) can be downloaded. website where

Lithuania

n.a.

None yet

Luxembou rg Malta

n.a.

None yet

n.a.

None yet

Inland Revenue (https://secure.gov.mt/ird/irdnet/login.aspx?auth=eid) is providing individual taxpayers with the facility to submit their Income Tax Return over the Internet. The system is based on eID Level 1 authentication mechanism (using a username and password). Citizens may fill-in their electronic income tax declaration via http://www.belastingdienst.nl/particulier/aangifte.html. In such case, the use of DigiD is required in case of electronic income tax declaration. DigiD is used as a normal electronic signature. Note that a Social Fiscal number (SOFI-nummer) is needed to apply for a DigiD. Ministry of Finances has decided to establish e-podatki (e-tax) system to enable companies and individuals to transmit tax returns via electronic means. It is planned to start the system at the beginning of 2008. E-Declarations is a web platform (www.dgci.gov.pt) that enables the communication of citizens and companies with the Portuguese Tax Department (Direcção-Geral dos Impostos). Through this platform all electronic forms for tax purposes can be obtained. The system relies on the identification of the user (the user provides the TAX number) and a password (from 8 up to 16 characters)

The Netherland s

model 2

Simple signature

Poland

n.a.

None yet

Portugal

n.a.

None yet

Romania

model 3

Qualified signature

National Electronic System (http://www.e-guvernare.ro) is the easy to use central access point to online public information and services. Through this portal, private companies can electronically fill, transmit to central administration their fiscal declarations. Currently, by legislation, only 6 declarations may be filled and transmitted electronically by a limited number of companies.

82

Preliminary Study on Mutual Recognition of eSignatures for eGovernment applications November 2007

Country Slovakia

Model model 3

Signature requirements Simple/Qualifi ed signature

Detail / Other info eTax application (http://www.drsr.sk) is an integrated system of online services, intended for electronic communication between tax authorities and citizens and enterpriser. The system is accessible also to non-nationals under condition, that certificate has to be issued by Certification Authority accredited by Slovakian National Security Authority.

Slovenia

model 3

Qualified signature

The Slovenia eTax system (http://edavki.durs.si/OpenPortal/Pages/StartPage/StartPage.aspx) is a complete business solution combining a web portal with back office integration and the highest level of security based on qualified certificates (authentication and digital signature are based on qualified digital certificates). Note that the service is presently accessible only for Slovene qualified certificates.

Spain

model 3

Advanced / Qualified signature

Personal income taxes can be declared on-line via the application provided by the Tax Agency Virtual Office (https://aeat.es). Note that the service is currently accessible for all users that have a NIF (Spanish Identification Number) and a certificate issued by one of the recognised Spanish CSP (http://www.aeat.org/prestelem/certauto.htm). Personal income taxes can be declared on-line via the website of the Swedish National Tax Board (http://www.skatteverket.se). The application relies on the eID framework. Note that non-nationals who are registered in Sweden and therefore are eligible for tax have a personal identity number, which allow them to acquire an eID.

Sweden

model 3

Advanced signature

Turkey United Kingdom

n.a. model 1

No information Simple signature Income Tax Declarations can be submitted on-line vie the Government Gateway (http://www.gateway.gov.uk/).

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 12%

Model 1 6%

Model 3 41%

Model 2 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 8 6 4 2 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).

Signed document type
6 5 4 3 2 1 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 8 6 Series1 4 2 0 Adobe Acrobat Applet/ActiveX eMail client other tools

4.2.4.3 VAT applications As reported by the national correspondents, the following signature types are required for existing VAT applications:

Country Austria

Model model 2

Signature requirements Simple/Qualifi ed signature

Detail / Other info FINANZOnline (http://finanzonline.bmf.gv.at). providing services: • Portal application

To citizens: tax returns of employed persons, application for family allowance, personal income taxes of entrepreneurs, VAT declarations of entrepreneurs, inspection of tax accounts; To companies: VAT declarations, income tax declarations, corporation tax declarations; To municipalities: declaration of taxable basis for municipal tax

• • Belgium model 3 Qualified signature

VAT can be declared online via the Intervat application (www.minfin.fgov.be). Note that only the three accredited commercial CSP certificates are legally accepted for electronic declarations. The system https://inetdec.taxadmin.minfin.bg/ relies on Universal Electronic Signatures. It is intended to Bulgarian VAT payers (registered under the Value Added Tax Act persons). Note that the application extracts the identification number of the user - legal entity (its BULSTAT uniform identification code) from the very certificate e-PDV (http://www.porezna-uprava.hr/e-porezna/ePDV.asp). Note that the application requires using dedicated software on the client’s workstation (57,9Mb) that is only available for Windows.

Bulgaria

model 2

Qualified certificate

Croatia

model 3

Qualified certificate

86

Preliminary Study on Mutual Recognition of eSignatures for eGovernment applications November 2007

Country Cyprus Czech Republic

Model n.a. model 3

Signature requirements None yet

Detail / Other info TAXISnet (http://taxisnet.mof.gov.cy) is a special network through which VAT Tax Returns and payment of Tax can be submitted. All kind of taxes can be declared on-line via the application tax-onweb (http://adis.mfcr.cz/adis/jepo) provided by the Czech Tax Administration. Note that Qualified certificates used for eSignature (adjoin to tax submission) must contain the unique identification of a taxpayer. Based on this identification the personal data of a subscriber can be determined. TastSelv Erhverv (http://www.skat.dk/SKAT.aspx?oID=199611). The application is accessible to non-nationals who have a SE-number (are paying VAT to Denmark). Non-nationals can only get access by pin-code as OCES signatures are not offered to non-nationals.

Advanced signature with qualified certificate

Denmark

model 2

Advanced signature

Estonia Finland

n.a. model 2

No information Qualified certificate ElmaTYVI Pro (http://tyvi.elma.fi) is an electronic client service through which companies and associations can use web forms and send reports (e.g. tax returns) to the authorities and other organisations that collect statutory data. TYVI is a joint service of many authorities. TéléTVA (http://tva.dgi.minefi.gouv.fr/). Note that: Enterprises have to obtain their digital certificate from a certification service provider recognized on a list published by the Ministry of Finance (see: http://www.telecom.gouv.fr/rubriques-menu/entreprises-economienumerique/certificats-references-pris-v1/categories-famillescertificats-references-pris-v-1-506.html. The signature application is included into the TéléTVA application.

France

model 3

Advanced signature

Germany Greece

n.a. n.a.

No information None yet The TAXISnet service (http://www.taxisnet.gr) provides services to individual and corporate taxpayers, including electronic submission of income tax forms, personalised online notification of the results of the tax return clearance process, electronic issuing of certificates by fax, electronic submission of VAT forms, and payment via banking system services. Businesses, organisations and natural persons subject to taxation can submit their tax declarations and fulfil their data supply obligations using the electronic tax declaration system eBev (https://www.magyarorszag.hu/allampolgar/szolgaltatasok/ebev.html ). Revenue On-line Service (ROS) is a central government online tax system for the following categories of taxpayers: - self-employed individuals, business, practitioners and, most recently, employees. The system is accessible at www.ros.ie. Note that Revenue Commissioners acts as its own Certification Authority.

Hungary

model 3

Advanced signature

Ireland

model 4

Advanced signature

Italy

model 3

Qualified signature

Entratel (https://entratel.agenziaentrate.it) is used by professional tax middlemen (accountants, counsellors, centres of assistance on tax declarations) and by large enterprises.

87

Preliminary Study on Mutual Recognition of eSignatures for eGovernment applications November 2007

Country Latvia

Model model 4

Signature requirements Simple signature

Detail / Other info Electronic Declaration System (EDS) (http://www2.vid.gov.lv). Note that the system makes use of electronic signatures provided and managed by the State Revenue Service on the basis of a signed agreement. Electronic Tax Declaration System (EDS) (http://deklaravimas.vmi.lt) was launched in March 2004. It enables individuals and legal entities to submit tax reports in digital format (via Internet, e-mail, CD and etc.). The system allows using qualified eSignatures certificates for authentication at the moment. The eTVA system (see https://saturn.etat.lu/etva/index.do) currently relies on simple signature (username/password) which should be seen as a validation of the operation.

Lithuania

n.a.

None yet

Luxembou rg Malta The Netherland s

model 4

Simple signature No information Qualified certificate

n.a. model 2

As of January 2005 all companies are obliged to file electronic tax declarations electronically via http://www.belastingdienst.nl/zakelijk/aangifte.html. Businesses use a personal name/password to log in. They have obtained this information via their Social-Fiscal number and can also use DigiD. If they do not use the internet forms but their own administrative software they can either use qualified signatures (e.g. Diginotar is specifically indicated as a CSP where to obtain a digital signature), or a name/password can be asked for.

Poland

model 3

Qualified signature

e-poltax system (https://e-poltax.mf.gov.pl) has been set-up for some businesses (if yearly netto incomes exceed 5 millions EUR) to provide following services: (a) an application for electronic documents exchange with Inland Revenue Service, (b) an off-line application enabling to sign and to send electronic tax returns to Inland Revenue Service, (c) an electronic documents schemes repository. It is some kind of temporary solution final solution before set-up of eDeklaracje (e-declarations) project foreseen in 2008.

Portugal

model 3

Simple signature

E-Declarations is a web platform (www.dgci.gov.pt) that enables the communication of citizens and companies with the Portuguese Tax Department (Direcção-Geral dos Impostos). Through this platform all electronic forms for tax purposes can be obtained. The system relies on the identification of the user (the user provides the TAX number) and a password (from 8 up to 16 characters)

Romania

model 3

Qualified certificate

National Electronic System (http://www.e-guvernare.ro) is the easy to use central access point to online public information and services. Through this portal, private companies can electronically fill, transmit to central administration their fiscal declarations. Currently, by legislation, only 6 declarations may be filled and transmitted electronically by a limited number of companies.

88

Preliminary Study on Mutual Recognition of eSignatures for eGovernment applications November 2007

Country Slovakia

Model model 3

Signature requirements Qualified certificate

Detail / Other info eTax application (http://www.drsr.sk) is an integrated system of online services, intended for electronic communication between tax authorities and citizens and enterpriser. The system is accessible also to non-nationals under condition, that certificate has to be issued by Certification Authority accredited by Slovakian National Security Authority.

Slovenia

model 3

Qualified certificate

The Slovenia eTax system (http://edavki.durs.si/OpenPortal/Pages/StartPage/StartPage.aspx) is a complete business solution combining a web portal with back office integration and the highest level of security based on qualified certificates (authentication and digital signature are based on qualified digital certificates). Note that the service is presently accessible only for Slovene qualified certificates.

Spain

model 3

Advanced / Qualified signature

VAT taxes can be declared on-line, via the application provided by the Tax Agency Virtual Office (https://aeat.es). Note that the service is currently accessible for all users that have a NIF (Spanish Identification Number) and a certificate issued by one of the recognised Spanish CSP (http://www.aeat.org/prestelem/certauto.htm). VAT return may be submitted electronically via the Swedish National Tax Board website (http://www.skatteverket.se), by using an eID and provided previous notification to the National Tax Board.

Sweden

model 3

Qualified signature No information Simple signature

Turkey United Kingdom

n.a. model 1

Electronic VAT Returns can be submitted on-line vie the Government Gateway (http://www.gateway.gov.uk/).

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 14%

Model 1 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 8 6 4 2 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 Impact Assessment and Recommendations
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.

5.2.1 Supervision vs. Accreditation
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 egovernment 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 egovernment 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 Application

User

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.

Slovakia “eTax – Online electronic services” application:

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.

Austria “FINANZOnline” application:

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.

Czech Republic “Publication system on public contracts – publication subsystem (eNotification)” application:

Question:” What measures, if any, have been taken to ensure interoperability with signatures created and/or certificates issued in other countries?”

Answer: “Ministry of informatics prepares best practice on procedures in cross-border recognition of qualified certificates.”

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

User

eGov Application

Country X

Country Y

Country

Austria

Bulgaria Czech Republic Finland Hungary Latvia The Netherlands Romania Slovakia Sweden United Kingdom Italy

Application/Service name FINANZOnline ( http://finanzonline.bmf.gv.at ) Electronic delivery (www.zustellung.gv.at) Meldebestätigung (https://meldung.cio.gv.at/egovMB/) Versicherungszeitenauszug – Link Electronic market for small public procurements: Publication system on public contracts – publication subsystem (eNotification). Epoline eOLF (Epoline Online Filing) Electronic Firm Registration/Electronic Company Register www.irmcegszolgalat.hu Electronic Declaration System (EDS) TenderNed e-Procurement (http://www.e-licitatie.ro). Electronic Public Procurement (EVO) – eTendering module Företagsregistrering (http://www.foretagsregistrering.se) (Company Registration eService) Oil & Gas Trust Scheme Uniwex. Intercent-ER.

96

Preliminary Study on Mutual Recognition of eSignatures for eGovernment applications November 2007

Country France Germany Turkey

Application/Service name Servizi telematici Entratel e Fisconline. impots.gouv.fr eVergabe Inward Processing Regime Cross-border applications

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.

Latvia “Electronic Declaration System (EDS)” application:

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 system is accessible to non-nationals if they have concluded the Agreement.”

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.

Hungary “Electronic Firm www.irmcegszolgalat.hu” application:

Registration/Electronic

Company

Register

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

Romania “eProcurement (http://www.e-licitatie.ro).” application:

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?”

Answer: “There is an interoperability project in development, named “Bridge CA”.”

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.

Italy “Uniwex” application:

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

The Netherlands “e-Procurement” application:

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

But at the following question

Question:” Which institutions, providers, etc. are involved in the signature scheme, and how do they relate?”

The answer was:

Answer: “Diginotar, Gemnet CSP, ESG: providers of electronic signatures, certified by OPTA.”

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

Czech Republic “Publication system on public contracts – publication subsystem (eNotification)” application:

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?”

Answer: “Ministry of informatics prepares best practice on procedures in cross-border recognition of qualified certificates.”

5.2.4 Non-National residents
There is a last definition that has been derived from the Country Profiles: use of applications by nonnationals 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 Application

User from Country X

Country Y

Among surveyed applications, there are 24 applications that claim to be opened to non-national residents. Country Bulgaria Finland Application/Service name University administration programme ISVU Lomake.fi public sector online forms service Registration on the Client Gate http://www.magyarorszag.hu/ugyfelkapu/regisztracio Electronic tax and contribution declarations for citizens https://www.magyarorszag.hu/allampolgar/szolgaltatasok/jarulek for entrepreneurs https://www.magyarorszag.hu/allampolgar/szolgaltatasok/ebev.html Declaration of persons entitled for health insurance: DSend system Electronic messaging system transmitting time stamped and encrypted messages certified with electronic signature Electronically authenticated private pension fund declarations system e-Önkormányzat – eLocal Government Portal of the Local Government of Budapest 13th district http://www.bp13.hu/wps/portal/e-onkormanyzat: Irish Public Services Broker - www.reachservices.ie Revenue On-line Service ROS Companies Registration Office E-Filing Elektronische aangifte

Hungary

Ireland The Netherlands

102

Preliminary Study on Mutual Recognition of eSignatures for eGovernment applications November 2007

Country Portugal Romania Slovenia

Slovakia Spain Sweden United Kingdom France Croatia

Application/Service name Online Incorporation of companies National Electronic System (http://www.e-guvernare.ro), component egovernment. One-Stop-Shop - State Portal for businesses (http://evem.gov.si) Registration Authority Application EKR – Electronic communication interface eServices of Trade Register eTax – Online electronic services ( http://www.drsr.sk ) RESEVI eINK, Personal income taxes declarations (Sw: Inlämning av självdeklarationsuppgifter) http://www.skatteverket.se Government Gateway Achatpublic.com e-Pension Insurance Registration (e-Mirovinsko)

5.3 Identified interoperability issues and recommendations
Our survey of usages of advanced electronic signatures in e-government applications in the Member States has revealed the following interoperability issues. The objective of this list is to provide a first basis for a discussion in the perspective of future European strategies in this area. The list has been divided into three categories: legal issues, technical issues and organisational issues. It should be noted that such classifications always imply a certain element of subjectivity, since many of these issues (e.g. the frequent link between e-signature solutions and electronic identity management systems) entail components from all three categories. None the less, an effort has been made to group each issue into the category which was considered to be predominant.

5.3.1 At Legal level
5.3.1.1 National perspective 5.3.1.1.1 Problem description Most of the surveyed countries, as far as they have adopted electronic signatures in their egovernment 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:

(a) information on national voluntary accreditation schemes, including any additional requirements pursuant to Article 3(7); […]” When Member States choose to restrict access to public sector applications based on the signature type being used (including a limitation to certain CAs or to one’s own eID card), it can be argued that article 11.1.(a) requires them to notify the Commission and other Member States of this restriction. If this were to be done systematically, this would greatly facilitate any interoperability activities, as an accurate overview of accepted signature solutions would be easily available.

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

5.3.1.2 Security levels – legal qualification of signature types 5.3.1.2.1 Problem description 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 userid/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 nonnational 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

5.3.1.3 European eSignature directive compliance 5.3.1.3.1 Problem description 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.

5.3.1.4 Ad-Hoc solutions 5.3.1.4.1 Problem description 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 solution can be s 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.

5.3.1.5 Multiple government levels 5.3.1.5.1 Problem description 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 Priority might be given to the promotion of interoperability of e-signatures in e-government applications at the national level. The current solutions at regional and local levels might also progressively adapt to national strategies and solutions in a further stage of development. 5.3.1.5.3 Recommendations 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

RECO4

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 includes the obligation of ensuring that local governments adhere to this framework. Target group: Member States

5.3.1.6 National rules on identifiers 5.3.1.6.1 Problem description Electronic signatures are frequently linked to national unique identifiers. They are u sed 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

5.3.2 At Organisational level
5.3.2.1 Link to eID schemes 5.3.2.1.1 Problem description 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

RECO5

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. Target group: eGovernment application owner 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 when this would impair interoperability. There is no objection against using electronic signatures to add functionality (such as automatically filling out identity information or automated error correction) beyond the traditional functions of a handwritten signature (such as expression of consent, non-repudiation etc.); however, applications should not make such added functionality mandatory when this has the unintended side effect of making the use of foreign signature solutions impossible, unless an alternative can be offered to users whose signatures may not offer the added functionality. Target group: eGovernment application owner

RECO6

5.3.2.2 Mutual recognition 5.3.2.2.1 Problem description 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

See section 5.3.1.2 above for recommendations on this issue.

111

Preliminary Study on Mutual Recognition of eSignatures for eGovernment applications November 2007

5.3.2.3 Atypical registration procedures 5.3.2.3.1 Problem description 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 socalled 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:

“Article 4 – Internal market principles 1. Each Member State shall apply the national provisions which it adopts pursuant to this Directive to certification-service-providers established on its territory and to the services which they provide. Member States may not restrict the provision of certification-services originating in another Member State in the fields covered by this Directive. 2. Member States shall ensure that electronic-signature products which comply with this Directive are permitted to circulate freely in 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 panEuropean 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 certificationservice-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 crossborder 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 signatureverification 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

RECO7

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. Target group: Member States. Because of the internal market provisions of the Directive, the creation of pan-European validation 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 such a platform. Target group: European Commission and Member States

RECO8

5.3.2.4 Multiple speeds 5.3.2.4.1 Problem description 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.

5.3.3 At Technical level

5.3.3.1 Incompatible use of identifiers 5.3.3.1.1 Problem description 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.”

Italy “PCTT (Processo Civile Telematico)” application: “Person ID number (“Codice Fiscale”), used to uniquely identify the subject”

UK “OGTS (Oil & Gas Trust Scheme)” application: “Subject – Organisation Unit” should hold an additional indicator (OGTS) after the entry to identify that the certificate has been issued in accordance with the Oil and Gas Trust Scheme, e.g. DTI (OGTS)

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

Country Belgium

Application/Service name Tax-on-Web (http://www.taxonweb.be) Online submission of annual income tax declarations VAT on Internet

Open to nonnational No No No No No No No No No No Yes No Yes Yes No No No Yes No No No No Yes No No No

Bulgaria

Social security declarations on Internet eGovernment portal of the Bulgarian government ePortal of the Employment Agency ETHICS TastSelv Borger

Denmark Virk.dk – a government portal for Danish businesses Provide the Application/Service Name: Netborger.dk Lomake.fi public sector online forms service Finland ElmaTYVI Pro at http://tyvi.elma.fi Ireland The Netherlands Poland Revenue On-line Service ROS Elektronische aangifte e-GIODO (http://egiodo.giodo.gov.pl) e-Taxes (http://edavki.durs.si) Intrastat (http://intrastat-surs.gov.si/) Slovenia One-Stop-Shop - State Portal for businesses (http://evem.gov.si) Development IS on waste management field. Spain Taxes at Virtual Office Registro Telemático (Online Registry) PROFIT Política Industrial (AVANZ@) Sweden Företagsregistrering (http://www.foretagsregistrering.se) (Company Registration eService) Telemaco, Signed Electronic Filing for Business Entities – Balance Sheets PCTT (Processo Civile Telematico) Czech Republic Tax-on-Web (http://adis.mfcr.cz/adis/jepo)

Italy

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

RECO9

The unique number required by the application to identify the citizen/business should not be a mandatory part of the signature/certificate. Target group: eGovernment application owner

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

5.3.3.2 Signature Type 5.3.3.2.1 Problem description 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.

Destination application requirements in country B Simple Simple signature are specific to an application or a National Framework Advanced Qualified

Person in Country A Signature Type

Simple Advanced

Possible

Qualified

Possible

Possible

Signature Type interoperability

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. Unfortunately, the Qualified Certificates Statements are optional. Furthermore, apparently only Spain and Austria seem to make use of them. 5.3.3.2.3 Recommendations 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

RECO10

Application owners should be recommended to make use of PKI-based signatures in applications where interoperability in the short term is a key objective Target group: eGovernment application owner

RECO11

Compliance with ETSI Qualified Certificate profile is recommended. Target group: eGovernment application owner

5.3.3.3 Dedicated Interface requirements 5.3.3.3.1 Problem description A factor limiting interoperability at the technical level is applications requiring specific nonstandardised 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.

Country Croatia

Application/Service name e-PDV (http://www.porezna-uprava.hr/e-porezna/ePDV.asp). This application requires using dedicated software on the client’s workstation (57,9Mb) that is only available for Microsoft Windows. Publication system on public contracts – publication subsystem (eNotification) This application requires using dedicated software on the client’s workstation that is only available for Microsoft Windows. Applications using dedicated software

Czech Republic

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

RECO12

The client signature tool should use standardized interfaces or applications that are de-facto available on any platform. Target group: eGovernment application owner

RECO13

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. Target group: eGovernment application owner

5.3.3.6 Signature format 5.3.3.6.1 Problem description 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

RECO14

Promote the use of international standards (CAdES or XAdES) as eSignature formats. Target group: European Commission, Member States, International standardisation bodies

5.3.3.7 Signature validation 5.3.3.7.1 Problem description 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 29

ETSI: “XML Advanced Electronic Signatures (XAdES)”, ETSI TS 101 903, v1.3.2, March 2006

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 5.3.3.7.2.1 Validation steps 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:

1. Parsing and syntax checking of the signature;

2. Check the integrity of the signed data by: a. Computing the signature using the same cryptographic algorithm parameters (hash algorithm, signature algorithm, signature format and public key), b. Comparing the newly computed signature to the attached signature. The validation fails at this point if they are not the same 3. Check the validity of the certificate used to perform the electronic signature by: a. Parsing and syntax checking of the certificate and its contents, including some semantic checking like use of certificate compared to allowed use (key usage extension) and presence of mandatory fields and critical extensions. Those checks should be made in compliance with the common profile for X.509 based certificates as defined by the ETSI technical specification TS 102 28030. b. Determining CA trustworthiness: i. Assessment that the CA is trustworthy, and that the quality of the certificate is sufficient related to the intended use of the certificate; ii. Validation of the CA’s signature on the certificate. This requires a trusted copy of the CA’s own public key, either directly available, or obtained from further certificates in a certificate chain. c. Checking that the certificate is within its validity period, given by timestamps in the certificate against the time of signing.

d. Checking that the certificate is not revoked, i.e. declared invalid by the CSP before the end of the validity period. This is usually achieved thanks to the following techniques: CRL or OCSP.
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: – – – Ad-hoc parsing by “certificate type”, Specific OCSP/CRL connections, Ad-hoc syntax and semantic checks of certificates.

5.3.3.7.2.3 Good practice example 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

5.3.3.7.3.2 List of supervised CSP 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.

European Web site
Published List of supervised CSPs by country

...
crl – ocsp Get certificate revocation status

...
crl – ocsp

eGov applications eGov applications Sign documents
Register users and Provide credentials

User certificate

Register users and Provide credentials

Sign documents
User certificate

RA

User certificate

RA

Sign documents

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

5.3.3.7.3.3 European Bridge/Gateway CA 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
TSLs
Root CA Root CA Root CA

HTTP - HTTPS Download TSL & Root CA

...
crl – ocsp

...
crl – ocsp

eGov applications

Get certificate revocation status

eGov applications

Sign documents
Register users and Provide credentials

User certificate

Register users and Provide credentials

Sign documents
User certificate

RA

User certificate

RA

Sign documents

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-serviceprovider 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. 5.3.3.7.3.4.1.2 Certificate Validation 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”. 5.3.3.7.3.4.1.3 Signature Validation 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; Technical signature compliance, i.e. verification of the signature compliance to technical standards (e.g. CAdES or XAdES); Compliance of the eSignature with regards to the eGovernment application policy. E.g. cryptographic algorithm parameters (hash algorithm, signature algorithm, …).

5.3.3.7.3.4.1.4 Value-added services 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

Hiding of the eSignature/certificate validation work to the eGovernment application by offloading it to a trusted server. This off-loading mechanism is called Delegated Path 39 Validation/ Delegated Path Discovery ; Transitivity of agreements with all the CA established in the country reduce the need to establish N*M agreements CSP-Public Administration and the technical connection to each CSP; Provision of the whole certificate validation steps as described above (see section 5.3.3.7.2.1), i.e. certificate syntax checking, CA trustworthiness, validation of certificate expiration and validation of certificate status; Translation of the fields of the certificate X.509 to a normalized XML schema (holder’s name, surname and national ID; certificate’s issuer information: name of CA, legal address, …; certificate’s usage, type of certificate, ...), saving the effort to eGovernment Portals; Service is non intrusive with administrative procedures (based on Web Service technology).

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 41

www.cnue.be

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 The Validation Authority Federation model is composed of several components. In each Member States, there should be a National Validation Authority in place. At the European level, there should be a European Validation Authority Gateway allowing all National Validation Authorities to communicate with each other. As we know that not all Member States will set-up a National Validation Authority or perhaps not all at the same time, we propose also 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 anyway participate to the Federation. This Generic Validation Authority should be seen as an extension of the European Bridge/Gateway CA. 5.3.3.7.3.4.3.1 National Validation Authority 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.

National Validation Authority
...
crl – ocsp

National Validation Authority
Web Services Web Services Web Services

Model 3 & 4

Model 1

Server

Server

eGov Applications

Web Portal

Model 2

Request certificate Receive certificate validation Validation status and qualification

Request certificate Receive certificate validation Validation status and qualification

Request certificate Receive certificate validation Validation status and qualification

Server Se rver

Register users and Provide credentials

Server Server

eGov Applications
User certificate

eGov Applications

RA RA RA RA

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.

5.3.3.7.3.4.3.2 European Validation Authority Gateway 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

Validation Authority Federation
TSLs
Root CAs Web Services

EBGCA

Root Root Root CA CA CA

Generic Validation Authority
crl – ocsp

EU Validation Authority Gateway
Web Services

Request signature validation

...
crl – ocsp

...
crl – ocsp National Validation Authority Web Services

Request signature validation

...
crl – ocsp National Validation Authority Web Services
Request signature validation

User certificate

Request certificate status

Request signature validation

eGov apps Sign
User certificate

eGov apps Sign Sign

eGov apps Sign
User certificate

Country Z

Country X

Country Y

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.

5.3.3.7.3.4.3.3 Generic Validation Authority 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
eGov Appl NVA-X

EU
EU VA G NVA-Y

Country Y
Issuing CA

WS request

WS request

Redirect

CRL/OCSP request

a 1
WS response

b
WS response

c f

d
CRL/OCSP response

g
WS request WS request

e
Generic VA Redirect CRL/OCSP request CRL/OCSP response

2

a
WS response

b
WS response

c

g
WS request

f
Redirect

d e

CRL/OCSP request

a 3
WS response

b e
WS request

c
CRL/OCSP response

d

a 4
WS response

Redirect

CRL/OCSP request CRL/OCSP response

b

e

c d

139

Preliminary Study on Mutual Recognition of eSignatures for eGovernment applications November 2007

Case 1: the “normal” case. In the ideal situation, where the Validation Authority Federation is fully deployed, i.e. every Member States has set-up its own National Validation Authority, there will be no need to have a Generic Validation Authority at the European level. In this situation, an eGovernment application of Country X will request, via web services (a), the validation of an eSignature to its National Validation Authority. If the signature has been created using a certificate issued by a CSP which is not from the same country, NVA-X will request, via web services (b), the signature validation to the European Validation Authority Gateway. This latter will redirect the request to NVA-Y (c), i.e. the National Validation Authority of the foreign country where the CSP is located. NVA-Y will perform all signature validation tasks. Notably, it will request the certificate revocation status from the issuing CSP (d). NVA-Y will then send the response to the validation request directly to NVA-X (f), which will, in its turn, forward it to the eGovernment application (g).

Case 2: the “no NVA-Y” case. In the second case, we suppose that no National Validation Authority has been set-up in the Member State where the signing certificate has been issued. This second case will show how the Generic Validation Authority is involved in the whole validation process. In this situation, an eGovernment application of Country X will request, via web services (a), the validation of an eSignature to its National Validation Authority. If the signature has been created using a certificate issued by a CSP which is not from the same country, NVA-X will request, via web services (b), the signature validation to the European Validation Authority Gateway. As the NVA-Y doesn’t exist, the gateway will redirect the request to the Generic Validation Authority (c) will perform certificate validation tasks, i.e. it will request the certificate revocation status from the issuing CSP (d). The Generic Validation Authority will then send the response to the validation request directly to NVA-X (f), which will, in its turn, forward it to the eGovernment application (g).

Case 3: the “no NVA-X” case. In the third case, we suppose that no National Validation Authority has been set-up in the Member State of the eGovernment application, i.e. the eGovernment application has no National Validation Authority to help in the validation of the eSignature. This case shows how the European Validation Authority Gateway will replace the missing NVA-X. In this situation, an eGovernment application of Country X will request, via web services (a), the validation of an eSignature to the European Validation Authority Gateway. This latter will redirect the request to NVA-Y (b), i.e. the National Validation Authority of foreign country where the CSP is located. NVA-Y will perform all signature validation tasks. Notably, it will request the certificate revocation status from the issuing CSP (c). NVA-Y will then send the response to the validation request directly to the eGovernment application (e).

Case 4: the “no NVA-X nor NVA-Y” case. In the fourth case, we suppose that there is no National Validation Authority at all. This case will show how the European Validation Authority Gateway and the Generic Validation Authority will help the eGovernment application to validate the eSignature. In this situation, an eGovernment application of Country X will request, via web services (a), the validation of an eSignature to the European Validation Authority Gateway. As the NVA-Y doesn’t exist, the gateway will redirect the request to the Generic Validation Authority (b), which will perform certificate validation tasks, i.e. it will request the certificate revocation status from the issuing CSP (c). The Generic Validation Authority will then send the response to the validation request directly to the eGovernment application (e).

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. 5.3.3.7.3.4.4.1 Interfaces towards eGovernment applications 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.

5.3.3.7.3.4.4.2 Interfaces towards CSPs 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

RECO15

New eGovernment applications should be encouraged to make use of PKI-based signatures if cross border interoperability is considered of importance Target group: eGovernment application owner

RECO16

Publish, on a central website, a list of Certification Service Providers supervised43 by their respective national responsible body Target group: European Commission

42 43

HTTP over SSL 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

RECO17

Implement the European IDA Bridge/Gateway CA (EBGCA) model that uses the centralised administrative structure of a bridge, and distributes trust using both cross-certifications and Certificate Trust Lists. Target group: European Commission

RECO18

The same legal concerns as voiced by RECO8 apply, and the same consultation of the Member States should be sought. Target group: European Commission; Member States

RECO19

Set-up a pan-European ‘Validation Authority Federation’ Target group: European Commission; Member States

5.3.3.8 Validation protocol 5.3.3.8.1 Problem description 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

5.4 List of potential interoperability issues at technical level
Besides issues that have been clearly identified, there are still some possible issues that may arise in the future. Those potential interoperability issues are listed here below.

5.4.1 Key length
5.4.1.1 Problem description 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.

5.4.2 Client software
5.4.2.1 Problem description 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
5.4.3.1 Problem description 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).

5.5 Interoperability issues in key e-government sectors
The list above outlines the interoperability issues that have been generally identified in existing egovernment applications. However, the distribution of these issues between e-government sectors is fairly uneven, in the sense that certain issues are significantly more prevalent or have a much stronger impact in some services than in others. This is an important consideration for interoperability purposes, since applications in some sectors show more potential (i.e. a better business case) for interoperability than others. For this reason, the three sectors discussed above (e-procurement, income tax declarations and VAT declarations) will be examined in more detail below, with a discussion of the main interoperability issues.

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 nondiscriminatory 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 nonbankruptcy, 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.

5.5.2 VAT Declarations
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

of solutions being offered (ranging from no signature/authentication to simple signatures, advanced signature, advanced with qualified certificates, and qualified signatures; see section 4.2.4.3, which specifically shows a fairly equal spread between simple and advanced signatures (accepted in 13 applications out of 29) and qualified signatures (accepted in 12 out of 29)). None the less, there are also a number of issues identified above which are more typical for VAT declarations. First of all, VAT administrations tend to have a tradition of operating as a distinct administrative unit within each country, relying on their own registers (or at least on common tax registers). For this reason, it is perhaps not surprising to find that there is a strong link between esignatures in VAT applications and eID schemes for tax payers. This can be witnessed by the fact that several of the application descriptions indicate that a specific unique identifier must be included in the signature certificate or must be presented in another manner (e.g. in Bulgaria, Czech Republic, Portugal and Spain). Obviously, this implies that interoperability cannot be realised if the applications functionally require such identifiers (e.g. in order to process the declarations) or if administrations are unwilling to accept declarations which lack such identifiers (e.g. because it presents a disproportionate administrative burden). As with eProcurement above, one of the key problems is the matter of mandates and representations, since VAT declarations are typically filed on behalf of a legal entity. However, unlike tenders, such declarations are typically not filed by the direct legal representative of the legal entity (general managers, CEOs, directors…), but rather by one or more members of the administrative staff of the legal entity, or even by an external service provider. Thus, the issue of being able to determine the legal capacity of the signatory and whether or not the signatory can in fact represent a specific legal entity is of paramount importance in VAT declarations. Equally interesting is the fact that, due to the nature of VAT declarations and the inherent necessity of accommodating foreign users, most countries have implemented VAT solutions which are explicitly available to foreign users. However, these always require prior registration in the country of declaration. In effect, this is also how the mandate issue above is usually resolved, as such registration procedures require an explicit mandate to be given by the legal entity to a specific natural person. It is also interesting to note that certain countries (e.g. Denmark) have implemented ad hoc solutions for foreign users which effectively result in two separate systems (with different security levels or a different legal status) for one application. Thus, the issue of cross border interoperability in VAT declarations has not yet been resolved, largely due to a lack of a common eSignature interoperability solution, coupled with the need for a simple mandate management system that allows the recipient to easily assess if a given natural person is indeed qualified to represent a legal entity.

5.5.3 Income taxes
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

ID RECO1

Description

Target group

Member States should be reminded of the letter and spirit of Member States 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. Application owners should take note of signature solutions eGovernment being used in other countries as identified by this study, and application owner 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. Application owners should be advised to shift from the current eGovernment situation of ad hoc decisions for each application, to a system application owner 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. Member States should be made conscious of the fact that their Member States possible national decentralisation of competences does not absolve them of their obligations of adhering to the eSignatures Directive’s provisions, which includes the obligation of ensuring that local governments adhere to this framework. Application owners should be made conscious of the eGovernment interoperability consequences of requiring the use of application owner identification attributes in signatures which are only available within their country. When determining the requirements for e-signature eGovernment applications, application owners must ensure that the signature application owner requirements are not abused to add functionality which is unrelated to the signature functionality itself when this would impair interoperability. There is no objection against using electronic signatures to add functionality (such as automatically filling out identity information or automated error correction) beyond the traditional functions of a handwritten signature (such as expression of 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, unless an alternative can be offered to users whose signatures may not offer the added functionality.

RECO2

RECO3

RECO4

RECO5

RECO6

150

Preliminary Study on Mutual Recognition of eSignatures for eGovernment applications November 2007

ID RECO7

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

Target group Member States

RECO8

Because of the internal market provisions of the Directive, the European creation of pan-European validation platform should at a Commission and minimum be preceded by a consultation of the Member States Member States on the main policy and legal issues arising as a result of the introduction of such a platform. The unique number required by the application to identify the eGovernment citizen/business should not be a mandatory part of the application owner signature/certificate. Application owners should be recommended to make use of eGovernment PKI-based signatures in applications where interoperability in application owner the short term is a key objective Compliance with recommended. ETSI Qualified Certificate profile is eGovernment application owner

RECO9

RECO10

RECO11 RECO12 RECO13

The client signature tool should use standardized interfaces or eGovernment applications that are de-facto available on any platform. application owner eGovernment applications that want to provide maximum eGovernment interoperability within an open environment should rely on application owner CSPs that do not impose any specific non-standardised interfaces. Promote the use of international standards (CAdES or XAdES) as eSignature formats. European Commission, Member States, International standardisation bodies eGovernment application owner European Commission

RECO14

RECO15

New eGovernment applications should be encouraged to make use of PKI-based signatures if cross border interoperability is considered of importance Publish, on a central website, a list of Certification Service Providers supervised45 by their respective national responsible body

RECO16

RECO17

Implement the European IDA Bridge/Gateway CA (EBGCA) European model that uses the centralised administrative structure of a Commission bridge, and distributes trust using both cross-certifications and Certificate Trust Lists. The same legal concerns as voiced by RECO8 apply, and the European same consultation of the Member States should be sought. Commission, Member States

RECO18

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

ID RECO19

Description Set-up a pan-European ‘Validation Authority Federation’.

Target group European Commission, Member States

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 egovernment 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 nonnationals. 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.

Validation Authority Federation
TSLs
Root CAs Web Services

EBGCA

Root Root Root CA CA CA

Generic Validation Authority
crl – ocsp

EU Validation Authority Gateway
Web Services

Request signature validation

...
crl – ocsp

...
crl – ocsp National Validation Authority Web Services

Request signature validation

...
crl – ocsp National Validation Authority Web Services
Request signature validation

User certificate

Request certificate status

Request signature validation

eGov apps Sign
User certificate

eGov apps Sign Sign

eGov apps Sign
User certificate

Country Z

Country X

Country Y

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

8 Annex A: Patterns Cross-comparison
8.1 The Comprehensive regulatory approach
The eGovernment applications are filtered on the “comprehensive” regulatory approach. Country Austria Regulatory approach Comprehensive Sectors eTax, eVAT Model model 2 Application/Service Name FINANZOnline ( http://finanzonline.bmf.gv. at ) Electronic delivery (www.zustellung.gv.at) Meldebestätigung (https://meldung.cio.gv.at/ egovMB/) Versicherungszeitenausz ug – Link Public Procurement (pilot project tested with std AT certificate on smart card) e-Taxes (http://edavki.durs.si) e-SJU – Portal for electronic services of public administration (http://euprava.gov.si/storitve/) EPOS (e-business) Intrastat (http://intrastatsurs.gov.si/) One-Stop-Shop - State Portal for businesses (http://evem.gov.si) Annual Reports Financial Accounts Statistics Salary Reporting Multilateral Compensation Signature type simple – qualified signature simple – qualified signature simple – qualified signature simple – qualified signature Qualified signature Qualified certificate Qualified certificate

Austria

Comprehensive

Horizontal

model 2

Austria

Comprehensive

Residence

model 2

Austria

Comprehensive

Social Security

model 2

Austria

Comprehensive

eProcurement

model 2

Slovenia Slovenia

Comprehensive Comprehensive

eTax Horizontal

model 3 model 3

Slovenia Slovenia Slovenia

Comprehensive Comprehensive Comprehensive

Custom Statistics Horizontal

model 3 model 3 model 3

Qualified certificate Qualified certificate Qualified certificate Qualified certificate Qualified certificate Qualified certificate Qualified certificate Qualified certificate Advanced / Qualified certificate

Slovenia Slovenia

Comprehensive Comprehensive

eBusiness eBusiness

model 3 model 3

Slovenia Slovenia

Comprehensive Comprehensive

Salary Report eTax

model 3 model 3

Slovenia Slovenia

Comprehensive Comprehensive

Environment eHealth

model 3 model 3

Development IS on waste management field. On-line access to health insurance data

156

Preliminary Study on Mutual Recognition of eSignatures for eGovernment applications November 2007

Country Slovenia

Regulatory approach Comprehensive

Sectors Agriculture

Model model 3

Application/Service Name E-business in agriculture

Signature type Qualified certificate Qualified certificate Qualified certificate Advanced / Qualified signature Advanced signature Advanced signature

Slovenia

Comprehensive

Animal

model 3

Slovenia

Comprehensive

model 3

Animal disease notification system – ADNS Registration Authority Application Taxes at Virtual Office

Spain

Comprehensive

eTax, eVAT

model 3

Spain Spain

Comprehensive Comprehensive

education Social Security

model 2 model 3

Spain

Comprehensive

Information society eJustice Insurance education eTax eTax

model 2

Registro Telemático (Online Registry) DELT@ (Declaración Electrónica de Trabajadores Accidentados) PROFIT Política Industrial (AVANZ@) LexNet RESEVI Uniwex. Unimoney. Telemaco, Signed Electronic Filing for Business Entities – Balance Sheets PCTT (Processo Civile Telematico) Intercent-ER. Servizi telematici Entratel e Fisconline. Project CRS-SISS (Carta Regionale dei Servizi – Sistema Informativo Socio Sanitario). eVergabe

Spain Spain Italy Italy Italy

Comprehensive Comprehensive Comprehensive Comprehensive Comprehensive

model 3 model 3 model 2 model 2 model 2

Advanced / Qualified signature Qualified signature Advanced signature Qualified signature Qualified signature Qualifiied signature

Italy Italy Italy Italy

Comprehensive Comprehensive Comprehensive Comprehensive

eJustice eProcurement eTax eHealth

model 2 model 2 model 3 model 4

Qualified signature Qualified signature Qualified signature Advanced signature

Germany

Comprehensive

eProcurement

model 2

Germany Germany Turkey

Comprehensive Comprehensive Comprehensive

Environment eJustice eBusiness

model 2 model 3 model 3

DEHSt Virtual Post Office (VPS2) OptiMahnOffice Inward Processing Regime

Advanced / Qualified signature Qualified signature Qualified signature Qualified certificate

157

Preliminary Study on Mutual Recognition of eSignatures for eGovernment applications November 2007

8.2 The Centralised regulatory approach
The eGovernment applications are filtered on the “centralised” regulatory approach. Country Regulatory Sectors Model Application/Service approach Name Belgium Centralised eTax model 2 Tax-on-Web Signature type simple qualified signature Qualified certificate

Czech Republic

Centralised

eProcurement

model 3

Publication system on public contracts – publication subsystem (eNotification). Government Gateway - DIS system ETHICS TastSelv Borger Virk.dk – a government portal for Danish businesses Provide the Application/Service Name: Netborger.dk Internet Voting Lomake.fi public sector online forms service ElmaTYVI Pro Epoline eOLF (Epoline Online Filing) Electronic Firm Registration/Electron ic Company Register

Czech Republic Denmark Denmark Denmark

Centralised

Horizontal

model 3

Qualified certificate advanced signature advanced signature advanced signature

Centralised Centralised Centralised

eProcurement eTax Horizontal

model 2 model 2 model 2

Denmark

Centralised

Horizontal

model 2

advanced signature Qualified signature Qualified certificate Qualified certificate Qualified certificate Advanced signature and Qualified certificate(f or some functions) Qualified certificate

Estonia Finland

Centralised Centralised

voting Horizontal

model 2 model 2

Finland Finland

Centralised Centralised

eTax patent

model 2 model 3

Hungary

Centralised

eBusiness

model 3

Hungary

Centralised

Horizontal

model 3

Registration on the Client Gate

158

Preliminary Study on Mutual Recognition of eSignatures for eGovernment applications November 2007

Country

Regulatory approach Centralised

Sectors

Model

Application/Service Name Electronic tax and contribution declarations for citizens & for entrepreneurs Declaration of persons entitled for health insurance: DSend system Electronic messaging system transmitting time stamped and encrypted messages certified with electronic signature Electronically authenticated private pension fund declarations system e-Önkormányzat – eLocal Government Portal of the Local Government of Budapest 13th district e-Local Government system of the Local Government of Hódmez•vásárhely, City with County Rights Electronic Declaration System (EDS) TenderNed Elektronische aangifte e-GIODO Online Incorporation of companies

Signature type Advanced signature

Hungary

eTax

model 3

Hungary

Centralised

eHealth

model 3

Advanced signature Advanced signature

Hungary

Centralised

eHealth

model 3

Hungary

Centralised

ePension

model 3

Hungary

Centralised

Horizontal

model 3

Qualified certificate and Advanced signature Advanced signature / Qualified certificate

Hungary

Centralised

Horizontal

model 3

Advanced signature / Qualified certificate

Latvia

Centralised

eTax

model 4

Simple signature Qualified certificate Qualified certificate Qualified certificate Qualified signature / Advanced signature

The Netherlands The Netherlands Poland Portugal

Centralised Centralised Centralised Centralised

eProcurement eTax, eVAT Personal Data Protection eProcurement

model 3 model 2 model 3 model 3

159

Preliminary Study on Mutual Recognition of eSignatures for eGovernment applications November 2007

Country

Regulatory approach Centralised

Sectors

Model

Application/Service Name National Electronic System, component e-government. e-Procurement (elicitatie) EKR – Electronic communication interface eServices of Trade Register eTax – Online electronic services ( http://www.drsr.sk ) Electronic Public Procurement (EVO) – eTendering module eINK, Personal income taxes declarations eSKD (Electronic Tax Return) Företagsregistrering (Company Registration eService) TeleTVA TeleIR Achatpublic.com impots.gouv.fr Tele-c@rtegrise e-VAT e-Pension Insurance Registration (eMirovinsko) Tax-on-Web

Signature type Qualified certificate Qualified certificate Advanced signature Qualified signature Qualified signature Advanced signature

Romania

eTax

model 3

Romania Slovakia

Centralised Centralised

eProcurement Custom

model 3 model 2

Slovakia Slovakia

Centralised Centralised

Trade eTax

model 1 model 3

Slovakia

Centralised

eProcurement

model 4

Sweden

Centralised

eTax

model 2

Qualified signature Qualified signature Qualified signature

Sweden Sweden

Centralised Centralised

eTax, eVAT eBusiness

model 3 model 3

France France France France France Croatia Croatia

Centralised Centralised Centralised Centralised Centralised Centralised Centralised

eVAT eTax eProcurement eTax eTax eVAT ePension

model 3 model 3 model 3 model 3 model 3 model 3 model 3

Advanced signature Advanced signature Advanced signature Advanced signature Advanced signature Qualified certificate Qualified certificate Qualified certificate

Czech Republic

Centralised

eTax

model 3

160

Preliminary Study on Mutual Recognition of eSignatures for eGovernment applications November 2007

8.3 The eProcurement sector
The eGovernment applications are filtered on the eProcurement sector. Country Austria Regulatory approach Comprehensiv e Sectors eProcurement Model model 2 Application/Service Name Public Procurement (pilot project tested with std AT certificate on smart card) Electronic market for small public procurements: Publication system on public contracts – publication subsystem (eNotification). ETHICS TenderNed e-Procurement (http://www.elicitatie.ro). Electronic Public Procurement (EVO) – eTendering module Intercent-ER. Achatpublic.com eVergabe Signature type Qualified signature

Bulgaria

AdHoc Fw

eProcurement

model 3

Qualified certificate Advanced signature

Czech Republic

Centralised

eProcurement

model 3

Denmark The Netherlands Romania

Centralised Centralised Centralised

eProcurement eProcurement eProcurement

model 2 model 3 model 3

Slovakia

Centralised

eProcurement

model 4

advanced signature Qualified signature Qualified certficate / Advanced signature Advanced signature Qualified signature Advanced signature Advanced signature / Qualified signature

Italy France Germany

Comprehensiv e Centralised Comprehensiv e

eProcurement eProcurement eProcurement

model 2 model 3 model 2

161

Preliminary Study on Mutual Recognition of eSignatures for eGovernment applications November 2007

8.4 The eTax and eVAT sectors
The eGovernment applications are filtered on the eTax and eVAT sectors. Country Austria Regulatory approach Comprehensive Sectors eTax, eVAT eTax Model model 2 Application/Servic e Name FINANZOnline Signature type simple – qualified signature simple – qualified signature Qualified certificate

Belgium

Centralised

model 2

Tax-on-Web

Bulgaria

AdHoc Fw

eTax

model 2

Online submission of annual income tax declarations

Bulgaria Denmark Finland Finland Hungary

AdHoc Fw Centralised Centralised Centralised Centralised

eVAT eTax eTax eVAT eTax

model 2 model 2 model 2 model 2 model 3

VAT on Internet TastSelv Borger Lomake ElmaTYVI Pro Electronic tax and contribution declarations for citizens & for entrepreneurs Revenue On-line Service ROS Electronic Declaration System (EDS) Elektronische aangifte National Electronic System, component e-government. e-Taxes Multilateral Compensation eTax – Online electronic services

Qualified certificate advanced signature Qualified certficate Qualified certficate Advanced signature

Ireland Latvia

Sector based Centralised

eTax eTax

model 4 model 4

Qualified signature Simple signature qualified certficate Qualified signature Qualified certificate Qualified certificate Qualified signature

The Netherland s Romania

Centralised

eTax, eVAT eTax

model 2

Centralised

model 3

Slovenia Slovenia Slovakia

Comprehensive Comprehensive Centralised

eTax eTax eTax

model 3 model 3 model 3

162

Preliminary Study on Mutual Recognition of eSignatures for eGovernment applications November 2007

Country Spain

Regulatory approach Comprehensive

Sectors eTax, eVAT eTax

Model model 3

Application/Servic e Name Taxes at Virtual Office eINK, Personal income taxes declarations eSKD (Electronic Tax Return) TeleTVA TeleIR impots.gouv.fr Tele-c@rtegrise Unimoney. Telemaco, Signed Electronic Filing for Business Entities – Balance Sheets Servizi telematici Entratel e Fisconline. impots.gouv.fr Tele-c@rtegrise e-VAT Tax-on-Web

Sweden

Centralised

model 2

Signature type Advanced / Qualified signature Advanced signature Advanced signature Advanced signature Advanced signature Advanced signature Advanced signature Qualified signature Qualified signature

Sweden France France France France Italy Italy

Centralised Centralised Centralised Centralised Centralised Comprehensive Comprehensive

eTax, eVAT eVAT eTax eTax eTax eTax eTax

model 3 model 3 model 3 model 3 model 3 model 2 model 2

Italy

Comprehensive

eTax

model 3

Qualified signature Advanced signature Advanced signature Qualified certificate Qualified certficate

France France Croatia Czech Republic

Centralised Centralised Centralised Centralised

eTax eTax eVAT eTax

model 3 model 3 model 3 model 3

163

Preliminary Study on Mutual Recognition of eSignatures for eGovernment applications November 2007

9 Annex B: Technical trends summarized
In section “4.2.1 Application approach models” technical trends by model are presented. This annex summarized the values. Note: In this summary, two phenomenon can appear: • • The sum is greater than the number of surveyed applications (90). This is the case when e.g. one application supports several token types; 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.

Signature type

simple 10

advanced 37

Qualified certificate 39

Qualified signature 25 Smart Card 71 files 10 other tools 20 Virtual smart card 4 ASCII 4

Token type

user/pass 6

soft 43 PDF 12 Applet/Active X 26

USB 23 Web-Form 14 eMail client 1

Signed document type

XML 18

Signing tool

Adobe Acrobat 5

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

Signed document type
20 18 16 14 12 10 8 6 4 2 0 XM L PDF Web-Form files ASCII Series1

The figure below represents the usage of signing tool type.

Signing tool
30 25 20 1 5 10 5 0 Adobe Acrobat Applet / Act iveX eM ail client other t ools Series1

Example of other signing tools (extracted from the country profiles):

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?”

Answer: “…Signature application implemented by CRS-SISS project....”

166

Preliminary Study on Mutual Recognition of eSignatures for eGovernment applications November 2007

Czech Republic “Publication system on public contracts – publication subsystem (eNotification) » application:

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

Hungary “Electronic Firm Registration/Electronic Company Register” application:

Question: “What are the software requirements on the client side (e.g. OS/specific driver/middleware) for the use of eSignature?”

Answer: “…They use ‘e-Szignó’, a professional signature creation application capable of creating ETSI TS 101 903 compliant XML signatures.....”

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

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

Sign up to vote on this title
UsefulNot useful