European Electronic Signature Standardization

1. European Electronic Signature Standardization Hans Nilsson, iD2 Technologies, S Patrick van Eecke, ICRI, University of Leuven, B Nick Pope, Security & Standards, UK Denis Pinkas, Bull, F For more information: www.ict.etsi.org

2. EESSI:European Electronic Signature Standardization Industry Initiative led by ICT Standards Board (CEN, ETSI, ...) Based on a mandate from European Commission Support the requirements of the EU Directive AND The requirements for standards from users and industry First phase: Inventory and work programme Supported by an expert team, reported on July 1 Next phase: Implementation of work programme

3. Agenda for today The EU Directive and its implications for standardization A standardization framework for electronic signature Standards for CSPs Standards for signature creation and verification products Interoperability standards Proposed work programme and how to participate

4. The EU Directive and its implications for Standardization Presented by Patrick Van Eecke, ICRI K.U.Leuven This presentation is not a formal interpretation of the Directive on Electronic Signatures and thus does not represent the position of the European Commission

5. Status of the directive • 13 May 1998: Proposal of draft directive by the Commission • 23 October 1998: Publication of draft directive in O.J. • 13 January 1999: European Parliament opinion in First Reading • 22 April 1999: Political agreement on the Common Position by Telecommunications Council • 24 June 1999: Common position of the Council • Autumn 1999: Second reading by the Parliament and Council • End 1999: Final adoption • Implementation: within 18 months after adoption (2001)

6. Definitions • Electronic signature • Certification service provider (CSP) • Advanced electronic signature • Signature creation/verification data • Signature creation/verification device • Qualified certificate • “Qualified Signature”

7. Scope of the Directive

8. forbidden allowed 1. Authorisation (obligatory) 2. Accreditation (voluntary) Obligation for Member States to control via supervision E.g. self-declaration scheme with subsequent control by governmental body or private institution CSP issuing qualified certificates to the public Internal market 3. Supervision

9. Qualified signatures Qualified signature: advanced electronic signature + qualified certificate + secure signature creation device Legal Recognition • General principle (art. 5.2): Legal effect for all electronic signatures • Second principle (art.5.1): certain electronic signatures get the same legal effect as hand-written signature Electronic signatures Advanced electronic signatures

10. Requirements Annex I: Qualified certificate Annex II: Certification Service Providers issuing qualified certificates Annex III: Secure Signature Creation Device Recommendations Annex IV: Signature Verification The Annexes

11. Liability causes Incorrect contents of the certificate Person identified in certificate does not hold corresponding signature creation data Incorrect matching of signature creation and verification data (if CSP provides these data) Malfunctioning of the CRL Exemptions CSP can prove he has not acted negligently Certificate is used contrary to the limits on the use of the certificate Liability Only for CSP fulfilling Annex II and issuing/guaranteeing qualified certificates to the public

12. International aspects if: • Foreign CA fulfils same requirements + accreditation by Member State or • A European CA guarantees for the foreign CA or • Recognition by treaty with EU Foreign certificates = Qualified certificates

13. Electronic signature committee • Representatives of the Member States and chaired by a representative of the Commission • Clarifying the requirements of the annexes; • Establishing the criteria for the designation of national bodies which determine the conformity of secure signature creation devices with Annex III (see Article 3.2b); • Determining the generally recognised standards for electronic signature products which would comply with the requirements laid down in point (e) of Annex II and Annex III (see Article 3.3). • EESSI recommendation: • Adding an advisory group to the Committee • consisting of industry experts

14. A Standardization Framework for Electronic Signature Presented by Hans Nilsson iD2 Technologies

15. Types of Electronic Signatures

16. Levels of standardization and regulation National implementation EU Directive National Legislation Signature Law Directive Level 1 Ordinance Annexes National Decree(high-level reqs) Level 2 Supervision Technical Rules International functional andquality standards Level 3 Conformityassessment Standards Internationalinteroperability standards Level 4

17. International Conformity Assessment Accreditation body for Certification bodies EN 45010 Assessment of Certification bodies Certification body Certification body for products for management systems EN 45011 EN 45012 Certification of Certification of Products Management Systems Manufacturer/ Manufacturer/ Supplier Supplier

18. Formal certification vs Manufacturer’s Declarations • New Approach directives • only “essential requirements” • Detailed standards published in Official Journal • Conformity assessment “modules”: • Formal evaluation by Notified Body, or • Manufacturer’s Declaration • The ES Directive is not strictly a New Approach directive ! • Formal evaluation required for • Secure signature creation devices (Annex III) • Trustworthy systems used by CSPs (Annex Iie) • Industry would like to see the use of both Formal evaluations and Manufacturer’s Declarations!

19. Technical Framework for Qualified Electronic Signatures • Although “technology neutral”, the Directive implicitly defines a technical framework • We need to define a “first sets of components” that can be used • A proposed first set that can be used: • Asymmetric cryptography (digital signatures) • Certificate based verification using X.509 • Public Key Infrastructure with CAs and Directories • Smart cards and other hardware tokens for private key protection • Reasons for this selection: • Generally accepted, existing standards • Urgent need for standardized use of these technologies! • Other sets of components can be introduced as soon as there is a need and basis for standardization

20. Quality & Functional Standards forCertification Service Providers Presented by Nick Pope Security & Standards Consultancy Ltd

21. Certification Service Provider (CSP) Services • Certification Authority • Registration Authority • Directory • Time-stamping • Attribute Authority • Trusted Archive • Notarisation

22. General Requirements Security Management of CSPs • Technology / service independent requirements • Reliability • Personnel, management administration • Policy documentation e.g BS 7799, ISO TR 13335 (GMITS)

23. CSP Issuing Qualified Certificates Annex II - Requirements • Reliability • Revocation & timing of revocations • Verify subject identity / attributes • Personnel and management • Trustworthy systems, cryptographic modules • Financial / liability • Protect against forgery, confidentiality • Record relevant information • Keep keys secret

24. CSP Issuing Qualified Certificates Minimum Policy Requirements • Security Management • Technical Requirements “Qualified” Certificate Policy Internet RFC 2527 Framework for Certificate Policies

25. CSP Issuing Qualified Certificates Trustworthy systems & cryptographic modules • Standard for Trusted Systems e.g. Common Criteria Protection Profile CS-2 • Standard for Cryptographic Security e.g. Equivalent to FIPS 140-1

26. Certification Service Provider (CSP) Services CSP Service Relating to Qualified Certificates • Certification Authority • Registration Authority • Directory Other CSP Services • Time-stamping • Attribute Authority • Trusted Archive • Notarisation

27. CSP Issuing Time Stamps • Security Management Requirements • Technical Requirements • Use of Trusted Systems

28. Other CSP Services • Attribute Authorities • Trusted Archive • Notarisation Needs better understanding of requirements

29. Requirement for CSP Quality & Functional Standards • CSP Security Management • Security Management & Certificate Policy for CSPs Issuing Qualified Certificates • Use of Trusted Systems for CSPs Issuing Qualified Certificates • Security Management & Policy for CSPs Issuing Time Stamps

30. Functional and Quality Standards forSignature Creation and Verification Products Presented by Hans Nilsson iD2 Technologies

31. Secure Signature Creation Devices (Annex III) • “Practically occur once, secrecy reasonably assured” • high quality key generation and key protection • strong algorithms, sufficient key length • PIN/password, resistant to dictionary attacks and exhaustive search • Signature created inside device, key never leaves device? • no backup copy, or copy of device? • => smart card or other hardware device! • Security requirement standard needed • Germany, Italy: ITSEC security target • US, Canada: FIPS 140-1 cryptographic module • Eurosmart Common Criteria Protection Profiles: • Smartcard Integrated Circuit • Smartcard IC with embedded software

32. Secure signature creation process and environment Not required in the Directive, but guidelines are still needed for: • User interface • User urged to verify the information before signing • Willful act: PIN every time? Mouse-click enough? • Handling of signing device and PIN (in contract with CSP) • …… • Operating environment and management • Secure or unsecure card reader • Protection against malicious software

33. Signature verification (Annex IV) Only recommendations in the Directive, but guidelines needed for: • Human and computer-based verification • Short-term authentication: • All information used for verification shall be “displayed” • Certificate chain shall be verified • Revocation checks shall be performed • Long-term validation of electronic signatures: • evidence for independent adjudicator • requires time-stamping

34. Interoperability standardization requirements for Electronic Signatures Presented by Denis Pinkas Bull

35. Syntax and encoding • Specification of the syntax and encoding format of an Electronic Signature, including support for multiple signatures and roles • Enhance CMS – S/MIME and add “ time-stamping ” to support long term validation (*). • ETSI TC Security is working in this area. • Standard for the use of X.509 public key certificates as qualified certificates • Support of the on-going work in IETF PKIX and after its completion, consider if any item is missing (*) For long term Electronic Signature validation see: • http://www.id2tech.com/news/pdf/ES_validation.pdf • http://www.openmaster.com/whitepapers/es_validation.pdf

36. Syntax and encoding (continued) • Profile for Certificates Revocation Lists (CRLs), Authority Revocation Lists (ARLs), OSCP responses and Time Stamps. • ETSI TC Security should address this requirement. • Standard for storing private keys and other PKI objects on smart cards • The PKCS#15 standard may provide the starting point, but this might be continued by ISO/ JTC1/ SC17. • Standard for description of the constituents of a signature policy understandable both by a human being and a computer. • ETSI TC Security should address this requirement • Standard to reference signature policies.

37. Additional needs • Establish a repository for certificate policies, signature policies or contract types. • The ICC repository being set up under the E-terms initiative could be used. • Define generic roles relevant to current transactions or contracts • An appropriate international organization should define them (ICC or UNICITRAL)

38. Studies are needed for ... • Solving name forms and name collisions both from a technical and legal point of view. • topic partly addressed by the PKIX WG that may have to be complemented. • The handling of name and certificate policy constraints in the verification of a certification path. • RFC 2459 does not fully address this concern and an extension to that document should be studied and then proposed to the PKIX working group. • A better understanding of the signature policies.

39. Studies are also needed for (continued) ... • The way to handle large numbers of revoked certificates. • The way to handle suspended certificates in the context of their use in Electronic Signatures. • The roles of notaries in an electronic world both from a technical perspective and a business perspective.

40. Protocols • For access to a Time Stamping service. • For access to a repository holding time-stamped certificates and scalable revocation information. • To allow registration without the need to exchange a secret by out-of-bands means. • To allow registration involving smart cards and in particular smart cards being able to generated key pairs. • A profiling of the On Line Certificate Status protocol issued by the IETF may be needed. • A profiling of the Time Stamping protocol under study by the PKIX working group may be needed, once this protocol is published by the IETF.

41. Application Program Interfaces (API) • Define APIs to allow access to various PKI infrastructures on top of the operational and management PKIX protocols. • Experiment the IDUP non repudiation APIs in conjunction with a standard format for electronic signatures in order to test both portability and interoperability.

42. Work programme and participation

43. High-priority work areas

44. How can YOU participate?? • CEN/ISSS Workshop for Electronic Signatures • Initial planning meeting: October 11, Brussels • Workshop kickoff: December 16-17, Brussels • Result: CEN Workshop Agreements • Contact: luc.vandenberghe@cenorm.be or hans.nilsson@id2tech.com • ETSI SEC: Electronic Signatures Infrastructure WG • Information on October 11 • ESI WG meeting: November 23 • Result: ETSI Standards • Contact: gyorgy.g.endersz@telia.se