OASIS Specification Template s9

2EU Electronic Signature Legislation 3Requirements for DSS

4Working Draft 0.0.3

522 December 2008

6Specification URIs: 7This Version: 8 Draft version only 9 10Technical Committee: 11 OASIS Digital Signature Services eXtended TC 12Chair(s): 13 Stefan Drees, individual 14 Juan Carlos Cruellas, Centre d'aplicacions avançades d’Internet (UPC) 15Editor(s): 16 DSS TC. 17 18Related work: 19 This specification is related to: 20  oasis-dss-core-spec-cs-v1.0-os 21  oasis-dss-profiles-german-signature-law-spec-1.0-os 22Abstract: 23 This document is a requirements document for EU related signature generation 24Status: 25 This document is a working draft. 26 .

28Copyright © OASIS® 2008. All Rights Reserved. 29All capitalized terms in the following text have the meanings assigned to them in the OASIS Intellectual 30Property Rights Policy (the "OASIS IPR Policy"). The full Policy may be found at the OASIS website. 31This document and translations of it may be copied and furnished to others, and derivative works that 32comment on or otherwise explain it or assist in its implementation may be prepared, copied, published, 33and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice 34and this section are included on all such copies and derivative works. However, this document itself may 35not be modified in any way, including by removing the copyright notice or references to OASIS, except as 36needed for the purpose of developing any document or deliverable produced by an OASIS Technical 37Committee (in which case the rules applicable to copyrights, as set forth in the OASIS IPR Policy, must 38be followed) or as required to translate it into languages other than English. 39The limited permissions granted above are perpetual and will not be revoked by OASIS or its successors 40or assigns. 41This document and the information contained herein is provided on an "AS IS" basis and OASIS 42DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY 43WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY 44OWNERSHIP RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A 45PARTICULAR PURPOSE. 46OASIS requests that any OASIS Party or any other party that believes it has patent claims that would 47necessarily be infringed by implementations of this OASIS Committee Specification or OASIS Standard, 48to notify OASIS TC Administrator and provide an indication of its willingness to grant patent licenses to 49such patent claims in a manner consistent with the IPR Mode of the OASIS Technical Committee that 50produced this specification. 51OASIS invites any party to contact the OASIS TC Administrator if it is aware of a claim of ownership of 52any patent claims that would necessarily be infringed by implementations of this specification by a patent 53holder that is not willing to provide a license to such patent claims in a manner consistent with the IPR 54Mode of the OASIS Technical Committee that produced this specification. OASIS may include such 55claims on its website, but disclaims any obligation to do so. 56OASIS takes no position regarding the validity or scope of any intellectual property or other rights that 57might be claimed to pertain to the implementation or use of the technology described in this document or 58the extent to which any license under such rights might or might not be available; neither does it represent 59that it has made any effort to identify any such rights. Information on OASIS' procedures with respect to 60rights in any document or deliverable produced by an OASIS Technical Committee can be found on the 61OASIS website. Copies of claims of rights made available for publication and any assurances of licenses 62to be made available, or the result of an attempt made to obtain a general license or permission for the 63use of such proprietary rights by implementers or users of this OASIS Committee Specification or OASIS 64Standard, can be obtained from the OASIS TC Administrator. OASIS makes no representation that any 65information or list of intellectual property rights will at any time be complete, or that any claims in such list 66are, in fact, Essential Claims. 67The names "OASIS", [insert specific trademarked names and abbreviations here] are trademarks of 68OASIS, the owner and developer of this specification, and should be used only to refer to the organization 69and its official outputs. OASIS welcomes reference to, and implementation and use of, specifications, 70while reserving the right to enforce its marks against misleading uses. Please see http://www.oasis- 71open.org/who/trademark.php for above guidance. 72

741 Introduction...... 4 75 1.1 Terminology...... 4 76 1.2 Normative References...... 4 77 1.3 Non-Normative References...... 4 782 DSS and EU Signature Law...... 6 793 EU electronic signature directive and server-based signing...... 7 80 3.1 Sole Control...... 7 81 3.2 Reliable Protection...... 7 82 3.3 Signature legislation in EU Member States...... 8 83 3.3.1 Austria...... 8 84 3.3.2 Germany...... 9 85 3.3.3 Italy...... 9 86 3.3.4 Spain...... 9 87 3.4 Signatory Authentication...... 10 88A. Revision History...... 11 89 90

7EU Signature Legislation Requirements for DSS [8 April 2008] 8Copyright © OASIS® 2008. All Rights Reserved. Page 3 of 11 911 Introduction 92This document contains a set of high-level requirements related to the use of the Digital Signature Service 931.0 OASIS Standard in the European Union. These requirements could be elaborated in a DSS-X profile 94or white paper. The goal of such a profile or white paper would be to map the legal requirements on to 95DSS features and discuss any specific additional requirements or recommended best practices.

961.1 Terminology 97The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD 98NOT”, “RECOMMENDED”, “MAY”, and “OPTIONAL” in this document are to be interpreted as described 99in [RFC2119].

1001.2 Normative References 101 [1999/93/EC] Directive 1999/93/EC of the European Parliament and of the Council of 13 102 December 1999 on a Community framework for electronic signatures. 103 http://eur-lex.europa.eu/LexUriServ/LexUriServ.do? 104 uri=CELEX:31999L0093:EN:HTML 105 [2003/511/EC] COMMISSION DECISION of 14 July 2003 on the publication of reference 106 numbers of generally recognised standards for electronic signature products in 107 accordance with Directive 1999/93/EC of the European Parliament and of the 108 Council http://eur-lex.europa.eu/LexUriServ/LexUriServ.do? 109 uri=OJ:L:2003:175:0045:0046:EN:PDF 110 [Codice] Codice dell’amministrazione digitale. http://www.cnipa.gov.it/site/_files/Opuscolo 111 %2013II.pdf 112 [CWA 14169] CEN Workshop Agreement 14169. Secure signature-creation devices “EAL 4+”. 113 March 2004. ftp://ftp.cenorm.be/PUBLIC/CWAs/e-Europe/eSign/cwa14169-00- 114 2004-Mar.pdf 115 [DSS Core] Digital Signature Service Core Protocols, Elements, and Bindings Version 1.0 116 http://docs.oasis-open.org/dss/v1.0/oasis-dss-core-spec-v1.0-os.pdf 117 [DSS SigG] German Signature Law Profile of the OASIS Digital Signature Service version 118 1.0. 119 http://docs.oasis-open.org/dss/v1.0/oasis-dss-profiles_german_signature_law- 120 spec-v1.0-os.pdf. 121 [RFC2119] S. Bradner, Key words for use in RFCs to Indicate Requirement Levels, 122 http://www.ietf.org/rfc/rfc2119.txt, IETF RFC 2119, March 1997. 123 [SAML 1.1] Assertions and Protocol for the OASIS Security Assertion Markup Language 124 (SAML) V1.1 125 http://www.oasis-open.org/committees/download.php/3406/oasis-sstc-saml-core- 126 1.1.pdf 127 [SAML AuthCtxt] Authentication Context for the OASIS Security Assertion Markup Language 128 (SAML) V2.0 129 http://docs.oasis-open.org/security/saml/v2.0/saml-authn-context-2.0-os.pdf

1301.3 Non-Normative References 131 [DSS-X 20080303] Detlef Huehnlein, posting to DSS-X mailing list. 132 http://lists.oasis-open.org/archives/dss-x/200803/msg00006.html. 133 [DSS-X 20080306] Clemens Orthacker, posting to DSS-X mailing list. 134 http://lists.oasis-open.org/archives/dss-x/200803/msg00014.html.

10EU Signature Legislation Requirements for DSS [8 April 2008] 11Copyright © OASIS® 2008. All Rights Reserved. Page 4 of 11 135 [DSS-X 20080307] Andreas Kuehne, posting to DSS-X mailing list. 136 http://lists.oasis-open.org/archives/dss-x/200803/msg00015.html 137 [FESA-ades] Forum of European Supervisory Authorities for Electronic Signatures (FESA). 138 Working Paper on Advanced Electronic Signatures 139 http://www.fesa.eu/public-documents/WorkingPaper-AdvancedSignature- 140 20041012.pdf 141 [FESA-sbss] Forum of European Supervisory Authorities for Electronic Signatures (FESA). 142 Public Statement on Server Based Signature Services. October 17, 2005. 143 http://www.fesa.eu/public-documents/PublicStatement- 144 ServerBasedSignatureServices-20051027.pdf. 145 [RFC 4226] HOTP: An HMAC-Based One-Time Password Algorithm. 146 http://www.ietf.org/rfc/rfc4226.txt. 147 [RFC 4792] The EAP Protected One-Time Password Protocol (EAP-POTP). 148 http://www.ietf.org/rfc/rfc4793.txt. 149 [Signatur] Law Governing Framework Conditions for Electronic Signatures and Amending 150 Other Regulations. Inofficial version for industry consultation for official German 151 text please refer to the Official Journal (Bundesgesetzblatt – BGBl. Teil I S. 876 152 vom 21. Mai 2001) 153 http://www.bundesnetzagentur.de/media/archive/3612.pdf 154 [Tuvit.93145] TUVIT certification of the product Multisign Enterprise. 155 http://www.bundesnetzagentur.de/media/archive/10695.pdf.

13EU Signature Legislation Requirements for DSS [8 April 2008] 14Copyright © OASIS® 2008. All Rights Reserved. Page 5 of 11 1562 DSS and EU Signature Law 157The Digital Signature Services 1.0 [DSS Core] defines a non-proprietary protocol for consumers and 158providers of digital signing and verification services to interact. DSS enables a concept called server 159based signature services, where the signature creation data are not stored in a signature creation device 160located at the signatory, but in a central hardware security module or other (secure) signature creation 161device located at the signature service provider. 162The European Electronic Signature Directive [1999/93/EC] defines the legal framework for the use of 163electronic signatures in the European Union. It defines the concepts of electronic signatures and 164advanced electronic signatures. It also defines the legal effects of advanced electronic signatures which 165are based on a qualified certificate and which are created by a secure-signature-creation device as 166well as other electronic signatures. The Directive has been transposed into the legislation of the various 167EU member states. 168Many potential users of DSS will be interested in learning if DSS can be used to create advanced 169electronic signatures (perhaps even advanced electronic signatures based on a qualified certificate and 170which are created by a secure-signature-creation device), and if yes, which potential additional 171requirements would need to be met. To serve the needs of these users, it is proposed that the DSS-X TC 172creates a document that: 173 Documents and explains the requirements in the EU Directive that are relevant for DSS signing; 174 Possibly, documents current practice in selected member states; 175 Discusses any specific additional requirements (e.g. on signatory authentication) 176 Recommends best practices 177This document provides some initial input to such a document. 178

16EU Signature Legislation Requirements for DSS [8 April 2008] 17Copyright © OASIS® 2008. All Rights Reserved. Page 6 of 11 1793 EU electronic signature directive and server-based 180 signing 181DSS enables a concept of server-based signing. The EU Directive defines two requirements that are 182relevant to such server-based signatures: 183 Article 2 requires that an advanced electronic signature is created using means that the signatory can 184 maintain under his sole control. 185 Annex III requires that secure signature-creation devices must, by appropriate technical and 186 procedural means, ensure that the signature-creation data used for signature generation can be 187 reliably protected by the legitimate signatory against the use of others.

1883.1 Sole Control 189The requirement of sole control means that the signatory must take measures to maintain control over his 190key. To satisfy this requirement, the use of special hardware as signature creation device is not required 191[FESA-ades]. However, the signatory must take measures to maintain control over his key. The security 192concept and the system configuration of the server must ensure that only the signatory, who is either a 193natural or a legal person, has control over the corresponding signature creation data. 194For server-based signature services, the signatory is not present in person, but the service provider can 195provide confidence that appropriate security measures have been taken to properly protect the signatory’s 196key. For this reason, the members of the Federation of European Supervisory Authorities for Electronic 197Signatures believe that “sole control at least of the signature creation data can be achieved and that 198advanced electronic signatures can be created by a server based signature service” [FESA-sbss].

1993.2 Reliable Protection 200The concept of “reliable protection” is expressed in appendix III of the EU Directive. A subsequent 201Commission Decision [2003/511/EC] furthermore clarifies that these requirements of Annex III are met by 202a specific generally recognized standard, [CWA 14169] which expresses requirements on secure 203signature creation devices (SSCD). This specification requires: 204 A “trusted path” for user authentication if the human interface is not provided by the target of 205 evaluation. 206 A “trusted channel” between the signature creation application and the secure signature creation 207 device. 208 These channels are shown in Figure 1 Trusted Path and Trusted Channel in CWA 14169.

210Figure 1 Trusted Path and Trusted Channel in CWA 14169 211The requirements for trusted path and trusted channel are not described in detail in [CWA 14169], but it is 212stated that these must support encryption. As means of authentication, the example of a smart card is 213given. A smart card is a personalized device that authenticates the associated individual using a PIN or 214biometrics, which in turn controls access to the private signing key. In [FESA-sbss], it is stated that “FESA 215members cannot rule out that server based signature services could be used for creating qualified 216electronic signatures. At present, however, this seems to be rather unlikely.” 217The DSS protocol [DSS Core] defines multiple ways of transporting the data to be signed in a 218. The identity of the signatory can be encoded using a optional 219input. This identity can be authenticated using a security binding or based on information based on a 220 optional input. DSS Core provides multiple security bindings that provide 221confidentiality and authenticate both the DSS client and the DSS server. The supporting information can 222be a password or a Security Assertion Markup Language 1.1 token [SAML 1.1]. SAML tokens can be 223digitally signed by the authentication service provider. It can be argued that these features allow DSS to 224provide functionality similar to the concepts of “trusted path” and “trusted channel” using its mechanisms 225of signatory authentication, at equivalent levels of protection.

2263.3 Signature legislation in EU Member States 227The EU Electronic Signature Directive has been incorporated in the national legislation of the various EU 228member states. Some countries support the use of server-based signing. The following information is 229derived from messages posted on the DSS-X TC mailing list.

2303.3.1 Austria 231Until the end of 2007 the Austrian so-called "Verwaltungssignatur" (based on certificates which basically 232have less strict requirements for the issuing CAs) could be used equivalently to a qualified signature 233(under specific circumstances). Based on this Verwaltungssignatur, Mobilkom Austria (an Austrian 234telecom provider) provided a server based signature using out-of-band authentication via one-time codes 235sent to registered cell phones. Due to economic reasons, however, Mobilkom Austria did not pursue the 236certification of this solution or qualified signatures.In Austria this is still a topic worth discussion. [DSS-X 23720080306].

22EU Signature Legislation Requirements for DSS [8 April 2008] 23Copyright © OASIS® 2008. All Rights Reserved. Page 8 of 11 2383.3.2 Germany 239The OASIS DSS TC produced, among other profiles, a German Signature Law Profile of the OASIS 240Digital Signature Service version 1.0 [DSS SigG]. 241"DSS-like" systems may be used in Germany to produce (and of course verify) qualified electronic 242signatures [DSS-X 20080303]. An example of product passing certification is presented in [Tuvit.93145]. 243The German signature law requires in article 17 that “[the] presentation of data to be signed requires 244signature-application components that will first clearly indicate the production of a qualified electronic 245signature and enable the data to which the signature refers to be identified.” [Signatur]. The word 'first' is 246interpreted in a way that the certificate owner must be aware beforehand of a qualified signature creation. 247One usual way to fulfill this requirement is to implement a time frame where signing requests may be 248reviewed. This is a way to not require an explicit click for each and every signature. There are no explicit 249time frames given. It's just a traditional way to fulfill the legal requirements and to comply with the idea 250that our regulatory body recognizes as best practices [DSS-X 20080307].

2513.3.3 Italy 252The Italian decree for digital signatures permits using signature creation devices that passed some known 253security certification. This is described in section 35, article 5 of [Codice].

2543.3.4 Spain 255Directive 1999/93/EC was transposed in Spain by “Digital Signature Law” (Law 59/2003), which 256establishes that there are three types of digital signature: simple, advanced and qualified. 257Simple electronic signature is defined by article 3.1 as a “[...] set of information in digital format that can 258be used by the signer as a mean of identification”. Article 3.9 says that it won’t be possible to deny effects 259just because is in electronic format. The use of password mechanism is the paradigmatic example. 260Advanced electronic signature is defined by article 3.2. Trough this type of digital signature is possible to 261identify the signer and all changes made after the signature respect to the signed data. The information 262used to create this type of signature is linked to the signer and can be controlled by him in an exclusive 263way. It is also impossible to deny legal effects to this type of signature just because is in electronic 264format. 265Qualified electronic signature is defined by article 3.3 as an advanced electronic signature based on a 266qualified certificate and generated by using a Secure Signature Creation Device (SSCD). This type of 267electronic signature is equivalent to handwritten signature. 268The Spanish “Digital Signature Law” says that in order to certificate a device as a SSCD the technical 269specifications published in the Official Journal of the European Union - Commission Decision of 14 July 2702003 … [2003/511/EC] - should be followed. 271The Spanish “Digital Signature Law” considers that the requirements to be met by a SSCD are those 272specified by the technical standards referenced by the Commission Decision of 14 July 2003 [2003/511/EC] 273– i.e. those specified by [CWA 14169]. 274The “Digital Signature Law” gives a special relevance and has a trend to promote the use of qualified 275electronic signature. 276But in 2007 it was approved the “Electronic access of the citizens to public services Law” (Law 27711/2007) which creates a multilevel legal framework for electronic identity and digital signature in relations 278among citizens and public administrations, and among several administrations. 279This law mentions “Administrative Organ’s certificates” to refer to a digital certificate which can be used to 280digitally sign documents, in the name of an Administrative Organ, by an automated process – i.e. for 281automated administrative activity. The subject of such a digital certificate can be a person (civil servant) or 282the Public Administration which shall be responsible in case of incident.

25EU Signature Legislation Requirements for DSS [8 April 2008] 26Copyright © OASIS® 2008. All Rights Reserved. Page 9 of 11 283About the security requirements for these certificates and related signatures: the law just says 1 that “(it) 284must be a digital certificate conforming to the requirements of the Digital Signature Law”. In fact, the first 285Certification Authorities that issued this kind of certificates have defined two different profiles: “High Level 286- Administrative Organ’s certificates” which are issued in a SCCD, and “Medium Level - Administrative 287Organ’s certificates” which are issued in a “PKC#12” file that should be “properly managed”.

2883.4 Signatory Authentication 289Most common implementations of [CWA 14169] are based on smart card technology, which provide an 290additional level of protection by requiring a physical proximity of signatory and the signing device. In 291server-based signing, the physical proximity that is inherent in a smart card solution is missing. Smart 292cards typically allow their owner to unlock the private key using a relatively “weak” authentication method 293such as a PIN. When the private key is stored on a server, and access to the server is based on a 294protocol like DSS, such an identification mechanism can be argued to be unacceptably weak. However, 295there are no specifications that define what “minimal” level of authentication would be acceptable for 296server-based signing. If the threshold is set too high (e.g. requiring strong authentication using a smart 297card containing a qualified certificate), many of the reasons for using a protocol like DSS in the first place 298no longer apply. If set too low, users and supervisory authorities will doubt that the level of protection 299offered by the signing service is sufficient. 300One Time Password (OTP) is a two factor authentication mechanism that shares some of the advantages 301of smart cards without requiring any client software or hardware on the user machine. A DSS profile 302describing the use of OTP authentication with DSS signature devices may recommend best practices and 303emerging initiatives to standardize OTP functionality, and to transmit OTP tokens in DSS. It may be 304necessary to specify additional restrictions or mechanisms for the use of OTP with DSS, such as: 305  Make sure that only once the token is assigned to a user, the user can perform a signature 306 operation. 307  Make sure that it will not possible to re-assign an OTP device to a user, any such "re- 308 assignment" will require deleting the signature key. 309  Define the mechanism to manage the link between a token (serial number, user ID), a user, and 310 the appropriate signing key stored in the DSS device. 311Alternatively, in the case that a simple password is used and found acceptable, does a change password 312mechanism exist? 313Assuming some “appropriate” level of authentication, the DSS core could be updated to support the more 314recent 2.0 version of SAML which provides a concept of “authentication contexts” [SAML AuthCtxt], and 315allows a server (such as a DSS signing server) to instruct an Identity service provider to authenticate the 316signatory at a level equal to or stronger than some minimal level.

318[optional; should not be included in OASIS Standards] 319 Revision Date Editor Changes Made 0.0.1 2008-03-31 Pim van der Eijk First Draft 0.0.2 2008-04-07 Pim van der Eijk Feedback from Ezer Farhi incorporated 0.0.3 2008-04-14 Pim van der Eijk Feedback from Detlef Huehnlein 0.0.4 2008-12-22 Pim van der Eijk Added section 3.3.4 with input from Catcert

320 321