Trust Services: building blocks for secondary legislation

Transcription

1 eias Study on an electronic identification, authentication and signature policy Trust Services: building blocks for secondary legislation Riccardo Genghini (SG&A, ewitness), Chairman ETSI TC-ESI in the context of COM(01) 38 Proposal for a Regulation on electronic identification and trust services

2

3 Structure of the presentation! A. Electronic Trust Services: possible definitions! B. Electronic registered delivery services

4 Electronic Trust Services: definitions! A1. Relevance of the issue! A. General principles! A3 Text of complemented article(s)! A4. Possible interpretations! A5. Reality checks 5.1 technical 5. legal 5.3 economical 5.4 societal! A6. Conclusion

5 Electronic Registered Delivery Services! B1. Text of Article! B. Text of complemented article(s)! B3. Related recitals! B4. Key issues / key points! B5. Implementation ideal scenario! B6. Reality checks 6.1 technical 6. legal 6.3 economical 6.4 societal! B7. Conclusion and proposed scenario

6 Electronic Trust Services: possible definitions

7 Relevance of the issue The Regulation provides a general definition of Electronic Trust Services and Qualified Electronic Trust services (Art and 3.17) So we have expressly regulated TSs: electronic signatures, seals, time stamps, registered delivery services and certificates services for website authentication and Other TSs: that is any TS normally provided for remuneration that involve (Art. 3.16): (a) the creation, verification, and validation of electronic signatures, seals or time stamps, registered delivery services and certificates related to these services or (b) the creation, verification and validation of certificates for website authentication or (c) the preservation of electronic signatures, seals or certificates related to these services. A1.

8 Relevance of the issue European Electronic Trust Services (3.16) are an open number of services Are European Qualified Trust Services (3.17) are an open number of services? Or can only the expressly regulated Qualified Trust Services be Qualified? Can Member States create or recognis e as Qualified other Trust Services, that are not expressely regulated in the Regulation? A1.

9 General Principles Legal Effect of EU Regulation Art. 88 ff. Founding Treaty EU Subsidiarity Art. 5 Founding Treaty EU Recital 76 of the Regulation No delegated acts (Art. 90 Founding Treaty EU) A.

10 Text of Article 3.16 (TS) 3.16 'trust service' means an electronic service normally provided for remuneration which consists in: (a) the creation, verification, and validation of electronic signatures, electronic seals or electronic time stamps, electronic registered delivery services and certificates related to these services or (b) the creation, verification and validation of certificates for website authentication or (c) the preservation of electronic signatures, seals or certificates related to these services; A3.

11 Text of Article 13.1, 16.3 (a) (TS) 13.1 (1) trust service providers shall be liable for damage caused intentionally or negligently to any natural or legal person due to failure to comply with the obligations under this Regulation.The burden of proving intention or negligence of a non-qualified trust service provider shall lie with a natural or legal person claiming the damage referred to in the first subparagraph (b) The role of the supervisory body shall be the following: (b) to take action, if necessary, in relation to non-qualified trust service providers established in the territory of the designating Member State, through ex post supervisory activities, when informed that they and thetrust servicesthey provide allegedly do not meet therequirements laid down in this Regulation; A3.

12 Text of the Articles 3.17, 13.1, 16.3 (QTS)! 3.17 'qualified trust service' means a trust service that meets the applicable requirements laid down in this Regulation! 13.1 () The intention or negligence of a qualified trust service provider shall be presumed unless a qualified trust service provider proves that the damage referred to in the first subparagraph occurred without the intention or negligence of that qualified trust service provider.! 16.3 (a) The role of the supervisory body shall be the following:! (a) to supervise qualified trust service providers established in the territory of the designating Member State to ensure, through ex ante and ex post supervisory activities, that they and the qualified trust services they provide meet the requirements laid down in this Regulation A3.

13 Text of Article 18 (TS + QTS) Security requirements applicable to trust service providers 1. Qualified and non-qualified trust service providers shall take appropriate technical and organisational measures to manage the risks posed to the security of the trust services they provide. Having regard to the latest technological developments, these measures shall ensure that the level of security is commensurate to thevdegree of risk. In particular, measures shall be taken to prevent and minimise the impact of security incidents and inform stakeholders of the adverse effects of any incidents.. Qualified and non-qualified trust service providers shall, without undue delay but in any case within 4 hours after having become aware of it, notify the supervisory body and, where applicable, other relevant bodies, such as the competent national body for information security or the data protection authority, of any breach of security or loss of integrity that has a significant impact on the trust service provided or on the personal data maintained therein. When the breach of security or loss of integrity is likely to adversely affect a natural or legal person to whom the trusted service has been provided, the trust service provider shall also notify the natural or legal person of the breach or loss of integrity without undue delay. Where appropriate, in particular if a breach of security or loss of integrity concerns two or more Member States, the notified supervisory body shall inform the supervisory bodies in other Member States concerned and the European Union Agency for Network and Information Security (ENISA). The notified supervisory body shall inform the public or require the trust service provider to do so, where it determines that disclosure of the breach of security or loss of integrity is in the public interest. 3. The supervisory body shall provide ENISA once a year with a summary of breach notifications received from trust service providers. 4. The Commission may, by means of implementing acts, define :! further specification of the measures referred to in paragraph 1, and! the formats and procedures, including deadlines, applicable for the purpose of paragraph.! Those implementing acts shall be adopted in accordance with the examination procedure referred to in Article 46(). A3.

14 Text of Articles to 4 (QTS) Provide a legal framework common to all QTSs In particular Art. 4 is providing a list of requirements on QTSs, that are common to all QTSs and are substantially consistent with provisions of ISO 7000 A3.

15 Legal issues 1. TSs are evidently an open set of services. How to identify the TSP that are subjected to the Regulation, in particular 13.1, 16.3 and 18?. Are QTSs a closed number? A4.

16 Legal issues 1. TSs are evidently an open set of services. How to identify the TSP that are subjected to the Regulation, in particular 13.1, 16.1 and 18?. Possible answers: 1. if the TSP falls within the broad definition of Art. 3.16, it is automatically subjected to the legal regulation of Artt. 13.1, 16.3 and 18.. The TSP is subjected to the regulation of Artt.13.1, 16.3 and 18, only if it opts into the cathegory of European Electronic Trust Service Provider A4.

17 Legal issues 1. Are QTSs a closed number?. Possible answers: 1. No, there is a broad and clear definition of QTSs, of which the QTS expressly regulated by the Regulation are just the most egregious examples (argument by art. 4). No, a QTSP providing at least one QTS, falls within the Supervision and regulation for QTS, for all TSs provided (argument by art. 3.0 'qualified trust service provider' means a trust service provider who provides one or more qualified trust services and is granted the qualified status by the supervisory body) 3. Yes, at European level, only the QTS expressly regulated by the Regulation are considered QTSs. At national level, still the legislation can create or recognise other QTSs (application of the subsidiarity principle) 4. Yes, the only QTSs allowed are those expressly regulated by the Regulation A4.

18 Reality Checks! Reality checks 5.1 technical 5. legal 5.3 economical 5.4 societal A5.

19 Conclusions +It is preferable to allow Electronic Service Providers to opt in and to ask to be subjected to Art. 13, 16 and 18. Still, if a Court decides that an electronic service falls within the definition of Art. 3.16, the service provider will be subjected to the liability rules provided by the regulation. Separation between administratrative and civil law A.

20 Conclusions To unleash innovation in the field of TSs and QTSs, it is preferable to keep open the set of TSs that can be QTSs and claim the European Trust Mark, provided that the TSP is providing at least one QTS expressly regulated by the Regulation A.

21 Qualified e-registered delivery services

22 Requirements for qualified electronic registered delivery services, art. 4. The Commission may, by means of implementing acts, establish reference numbers of standards for processes for sending and receiving data. Compliance with the requirements laid down in paragraph 1 shall be presumed where the process for sending and receiving data meets those standards. B1.

23 Requirements for qualified electronic registered delivery services, art. 4.1 Qualified electronic registered delivery services shall meet the following requirements:! (a) they must be provided by one or more qualified trust service provider(s)! (b) they must ensure with high level of confidence the identification of the sender! (c) before the delivery of the data they must ensure the identification of the addressee B.

24 Requirements for qualified electronic registered delivery services, art. 4.1 (cont ed)! (d) sending and receiving of data must be secured by an advanced electronic signature or an advanced electronic seal of qualified trust service provider in such a manner as to preclude the possibility of the data being changed undetectably! (e) any change of the data needed for the purpose of sending or receiving the data must be clearly indicated to the sender and addressee of the data A.

25 Requirements for qualified electronic registered delivery services, art. 4.1 (cont ed)! (f) the date and time of sending, receipt and any change of data must be indicated by a qualified electronic time stamp! (g) in the event of the data being transferred between two or more qualified trust service providers, the requirements in points (a) to (e) shall apply to all the qualified trust service providers A.

26 Related recitals: Interinstitutional file 01/0146 (COD) (47a) It is essential to provide for a legal framework to facilitate cross border recognition between existing national legal systems related to electronic registered delivery service. This framework could also open new market opportunities for European Union trust service providers to offer new pan-european electronic registered delivery services. A.

27 Issues and key points! Objective of the proposed regulation achieve legal effect on the certainty of crossborder e-registered delivery establish qualified e-registered delivery services EUMS may have in force national legislation establishing legal equivalence of e-registered delivery and paper registered letter! Implementing Act s (IA) scope limited to establishing reference numbers of standards for processes for sending and receiving data process intended as structured, measured set of activities designed to produce a specified output A4.

28 Issues and key points (cont ed)! Qualified e-registered delivery simply has the legal value of a presumption that a certain delivery process has been performed scope for several different e-delivery processes, with several different features for legal procedures, banking, simple s, invoicing, etc. Each of such services requires a different identification and a different level of insurance very welcome that many different standards pop up, solving issues specific to their use environment A4.

29 Issues and key points (cont ed)! Difficult to define the exact boundaries the identity of sender/receiver the authenticity of the claimed identity and their accountability and responsibility! Therefore in the field of e-registered delivery multiplicity is unavoidable the regulation should not stifle innovation the EC must have a way that allows swift recognition of new and effective standards to solve specific issues and to propose innovative e- registered delivery services A4.

30 Issues and key points (cont ed)! Trusted e-registered delivery as the new alternative to contractual agreement, in a fully digitalised environment it cannot be regulated as an alternative to registered mail and telegrams, but should be open to embrace new paradigms A4.

31 Issues and key points (cont ed)! Potential issues w.r.t. establishing e-registered delivery standards in this field, there are several different working environments and use cases that need different authentication rules (e.g.) from UPU with just object and system identification to legal XML that provides double sender and receiver strong authentication each and every use case has its merits and relevance there is a significant difference between processes in the various different contexts such as BB, BC, CC, GC etc. A4.

32 Issues and key points (cont ed)! Potential issues w.r.t. establishing e-registered delivery standards (cont ed) a single standard will never be able to address all requirements many stakeholders with vested interests, as described later however, few if any of these can be considered open solutions that would not disturb the desired level playing field A4.

33 Implementation ideal scenario! First phase (inventory) making a long list of standard candidates for processes for sending and receiving data relevant standards from ISO, ETSI, OASIS to be included standards to be validated against requirements from public sector, particularly esens project private sector, main providers of e-registered delivery services! Second phase (selection by consensus) standards to be referenced by the IA part(ies) accountable for standard development! Finally, standard reference numbers are actually established per IA A5.

34 Reality checks: technical (existing standards landscape)! ISO SWIFT services clear case for qualified e-registered delivery consortium-made, then messages standardized by ISO cannot be a relevant standard other TCs (e.g. ISO/IEC JTC 1) standardised ICT processes (e.g. software development) not related to e-registered delivery A6.1.

35 Reality checks: technical (cont ed) (existing standards landscape)! OASIS ebxml Registry TC develops specifications for interoperable registries and repositories for submission, query and retrieval of contents ebxml Messaging Services TC develops technology delivery of business transactions transport, routing, packaging using Internet technologies LegalXML for Electronic Court Filing is using XML to create and transmit legal documents among attorneys, courts, litigants, and others legally speaking it is a standard that can be referenced minor issues on public availability and on the openness of the standardisation process A6.1.

36 Reality checks: technical (cont ed) (existing standards landscape)! UPU (Universal Postal Union) established an Electronic PostMark (EPM) published as an OASIS standard, including a profile of the OASIS Digital Signature Service! ETSI ETSI TS Registered Electronic Mail v.1.1 REM architecture (Part 1) Data structures and formats for messages and Evidences (Part ) Information Security Policy Requirements for provision of REM services (Part 3) REM Conformance requirements (Part 4) Interoperability Profiles for SMTP-based REM (Part 5) A6.1.

37 Reality checks: technical (cont ed) (existing standards landscape)! Other specifications related to XML BPMN provides a graphical notation to facilitate human communication between business users and technical users, of complex business processes XPDL provides an XML file format that can be used to interchange process models between tools! Several e-registered delivery services already in operation, in different domains as Land Registration, Insurance, public Registered (both completely electronic as well as hybrid) A6.1.

38 Reality checks: technical (cont ed) (existing standards landscape)! European e-sens Project e-sens is building on the previous Large Scale Pilot (LSP) outcomes in 3 competence clusters: e- Delivery, Semantics and e-documents, as well as e-identity and e-signatures e-delivery competence cluster addressing issues that have not been solved during cooperation of STORK (e-delivery-pilot), PEPPOL, SPOCS and e-codex A6.1.

39 Reality checks: technical (cont ed) (existing standards landscape)! European e-sens Project (cont ed) some will already be tackled by e-codex project but not all of the issues can be solved, e.g. common format for end entity addresses common format for SAML token for end entity authentication, based on STORK SML/SMP-based discovery to be used with ebms3 establishing trust (gateway authentication), e.g., through Trust Lists (TLs technically defined by the ETSI TSL specification) as used in SPOCS for e-delivery services and/or through a dedicated PKI as used in PEPPOL A6.1.

40 Reality checks: technical (cont ed) (existing standards landscape)! European e-sens Project (cont ed) the edelivery subgroup will create an extended set of open specifications (a Common Framework for e-delivery) a reference implementation (Re-usable Generic Tools) applications in new domains inside the e-sens LSP will be based on this reference implementation (i.e., on a subset of the generic tools) a migration plan will be created for the existing infrastructures of previous LSPs, and the e- Delivery subgroup will provide support for the migration of existing software A6.1.

41 Reality checks: technical (cont ed) (existing standards landscape)! Connecting Europe Facility (CEF) CEF includes the Digital Service Infrastructure (DSI) established to connect Member State players they keep freedom at national level DSI will enable cross-border delivery of services of common interest as such, e-delivery CEF-DSI is the critical layer underpinning the technical implementation of e- registered delivery services across the EU A6.1.

42 Reality checks: technical (cont ed) (existing standards landscape)! Conclusion rich space, with many actors and competing standards, with various degrees of openness Article 4.1 states: Compliance with the requirements laid down in paragraph 1 shall be presumed where the process for sending and receiving data meets those standards for e- registered delivery services provided by EU TSPs if the model of legal notifications and registered mail will be adopted in the IA, innovation will be killed on the onset; e-registered delivery services will be used only in closed users environments (SWIFT) or if made mandatory by national law (Italian PEC) A6.1.

43 Reality checks: technical (cont ed) (existing standards landscape)! Conclusion to specify processes for the functionality and interoperability of the qualified e-registered delivery services, preserving the innovation, it may be necessary to specify a prioritisation yielding a primary focus, defining on which processes to concentrate first a vocabulary to define the key characteristics of processes (name, steps, dependencies, actors, data used, input, transformations, outcome,...) a vocabulary to electronically identify and authenticate actors in the e-registered delivery process such as Sender, Receiver, Service Provider, Services, etc. A6.1.

44 Reality checks: technical (cont ed) (existing standards landscape)! Conclusion ( ) it may be necessary to specify safeguards (security mechanisms) that implement these, particularly with regard to authentication of the actors (be it IT systems, human beings or legal entities) this may in some cases involve the use of national/eu Enterprise and Citizen Registers, the use of identifiers such as VAT number, as well as quality assurance of those registers agreement on the use of and reliance on time in the processes technical formats, procedures and practices for performing interactions with end-users on both the sending and receiving sides; intra-process interactions in case multiple actors are involved (e.g. multiple e- registered delivery services, relying on different QTSPs) A6.1.

45 Reality checks: legal! Currently qualified e-registered delivery is existent only in some EU Member States and effectively used only when made mandatory private citizens do not accept such services, because they understand correctly that the possibility to enact their rights depends mainly on the proper functioning of their computers (or handheld devices) this is, in effect, too risky, particularly because the current existing e-registered delivery models mimic legal notifications and registered mail A6..

46 Reality checks: legal (cont ed)! From a legal standpoint in open environments registered e-delivery is better suited to prove that someone that has an obligation to act/inform, has duly acted according to the law only in closed environments (like legal notifications, judicial proceedings, etc.) registered (if sent and received by professionals) can be used for putting an obligation to act on the receiver the regulation properly sets the definition of (qualified) registered e-delivery, leaving to the national legislation to define its evidential value A6..

47 Reality checks: legal (cont ed)! If IA will choose a legal-mail (registered mail) model for e-registered delivery, it will be used only if required by the law and will ultimately address areas where only national legislation applies (Article. of the Regulation) the consequence would be that Articles 41 and 4 would be unable to support the creation of a (single) European market for registered e-delivery, entrenching existing incumbents in their (national) dominant role this would be against the main goal of the regulation of creating a single market of European Trust Service Providers (Recitals Nr. 4, 5 and 6) A6..

48 Reality checks: legal (cont ed)! If the regulation accepts the broader technical definition of registered e-delivery, in this case national legislator will be able to refer to the regulation and to the published standards in order to define the proof value and the usage context of registered e-delivery! Only the National legislator has the competence to define its legal/evidential value of the different registered e-delivery services, beyond what stated in Article 41 section 1 and of the Regulation A6..

49 Reality checks: economical! From an economical perspective, e-registered delivery is a broad market field. It can be argued that some of the e-registered delivery services or e-transactions executions can actually be called e-registered delivery! To grow this market, it is recommended to avoid both: any stifling of innovation; and creation of unfair competitive advantage A6.3.

50 Reality checks: economical (cont ed)! E-registered delivery can be qualified as a clear area for growth, and the creation of a fair level playing field is important in fact, all the inventors and implementers of early registered e-delivery services, have been small European companies or even individuals! A too high barrier to entrance set by the EC or by the EUMS, would stifle innovation and force innovative companies to licence to larger market players their innovative technology for e-delivery if no (adequate) guarantees are provided, to much risk is translated onto the relying parties A6.3.

51 Reality checks: societal! Attention should be paid to not introducing or enforcing a digital divide between persons/ organisations that have access to electronic processes, and those that have not! Equal attention should be given to the processing of privacy-sensitive information, particularly with regard to selling and re-selling transaction related information that might disclose behaviour or preferences A6.4.

52 Conclusion and proposed scenario! Important that e-registered delivery is and remains open to innovation! In this perspective, any future scenario should establish a mechanism that allows European and International Standard Organisations, to submit a proposal for an e-registered delivery standard to be referenced by the EU Commission A7.

53 Conclusion and proposed scenario (cont ed)! ( ) any future scenario should mandate a transparent review of the proposed standard, checking that it does not lack none of the properties required by Regulation 105/01/ EU, in particular transparent standardisation process open standardisation process accessible by everybody, either through» membership to the standardisation committee, or» a national standardisation body standard publicly available to everybody free, or or upon payment (like CEN and ISO standards) A7.

54 Conclusion and proposed scenario (cont ed)! Furthermore, consideration should be given to the fact that innovative solution must have the opportunity to become qualified services, even if they solve just specific issues and serve well defined communities A7.

55 Conclusion and proposed scenario (cont ed)! National legislation may impose restrictive conditions for registered e-delivery, like millions of Euro of minimum stock capital, or the possession of a postal license this would create national monopolies and force innovative companies to sell to incumbents their innovative solutions, instead of addressing with them directly the market EC shall ensure that a fine balance will be struck between capital requirements, insurance, living will dispositions, so that business security and continuity is ensured in the field of registered e- services and of more in general for (Q)TSPs A7.

56 Thanks for the attention! Questions?