PEPPOL eID and eSignature Validation Pilots PEPPOL Conference Malmö , 10 th Feb. 2010

1. Jon Ølnes, Difi (Agency for Public Management and eGovernment), Norway ... and the rest of the PEPPOL WP1 crew PEPPOL eID and eSignature Validation PilotsPEPPOL ConferenceMalmö, 10th Feb. 2010

2. The Need Signature Interoperability Goals

3. Interoperability – ultimate goals • Goal of eID holder: Sign towards any relying party using a single eID (or the eID of own choice) • Goal of relying party: Accept all signatures with assessed risk regardless of eID issuer • Additional goal: Allow any other party to verify signatures (e.g. an auditor)

4. Signatures and protocols • Why sign? • Legal/regulatory requirements – mandatory to sign • Risk management decision – security, traceability • Signature protects against your legitimate counterpart • Business protocol level • Signature in WP1 is a business protocol element • End-to-end between the communicating partners • The transport infrastructure is agnostic to signatures • Signing binds to content and format • Format conversion kills signatures • Workaround: Send both original, signed format + format after conversion (not recommended)

5. eID/eSignature Interoperability • “Front-end” interoperability • Use my card everywhere. Online service provider to accept “any” card or other suitable ID token • “Back-end” interoperability • Receiver (relying party) shall be able to validate and accept signatures and eIDs from all relevant counterparts, no matter the eID issuer of the counterpart. Not “on-line”, rather asynchronous, message passing protocols. • Other parties: Verification of signed documents may (later) be required by parties not involved in the signing process • Not explicitly in scope of PEPPOL but ensure sufficient information is available Out of scope of PEPPOL – actors sign inside their own infrastructure. Leave this to STORK.

6. Interoperability business case • Real world interoperability happens if there is a business case • A technical solution in a pilot is not enough • Deploy solutions targeting the business case • Public procurement is a good business case • PEPPOL as a pilot fuels the business case • Make the solution applicable across other areas • “Long tail” market etc. The real world challenge: ALL TRUSTED ROLES MUST HAVE A SOUND BUSINESS MODEL Government funding is one possible model Commercial viability is the only alternative

7. The Qualified Term • Common legal framework across Europe • Qualified signature shall have a guaranteed legal value • Qualified eID has a particular status as supervised/accredited even when not used for qualified signatures • European-wide interoperability intended – at least for qualified signatures but preferably also for qualified eIDs • Quality: ETSI TS 101 456 QCP/QCP+ not mandatory but in practice always used • Qualified certificate only for signatures (?) • Some (but not all) countries: Only to be used for signing, certificates for other purposes cannot be marked as qualified • What about certificates for authentication and encryption? • Only European • Some uptake in Asia but not globally

8. Non-Qualified • No common legal framework, not even in Europe • Refer to certificate policy and thus national law of the eID issuer • Or establish an agreement-based system – contract law • (CROBIES suggests to expand scope of eSignature Directive) • Certificates from outside of Europe • Certificates for other purposes than signing • Certificates issued to legal (not physical) persons • Non-qualified, lower quality eIDs in or outside Europe • Corporate PKIs and the like • .....

9. Signatures and eIDs:Validation vs acceptance • Signature and eID validation (cryptography, technical) • Complex cross-border in Europe (scaling) but achievable • Signature and eID acceptance • Acceptance criteria: Legal/regulatory requirements and/or risk assessment • eID quality sufficient? • Approval status (national/international) of eID? • Cryptographic quality sufficient? • Possibly other elements (quality of the CA itself and its owners?) • Not possible to assess using only “traditional PKI” elements • Signature policies to define acceptance criteria – quality being the main issue • “Rich validation interfaces” to assess policy fulfilment

10. The Project PEPPOLPan-European Public Procurement On-Linehttp://www.peppol.eu

11. Scope of Work, Work Packages Pre Award Tendering Post Award Procurement Payment Virtual Company Dossier (WP 2) eCatalogues (WP 3) eInvoicing (WP 5) eOrdering (WP 4) eSignature (WP 1) Open Infrastructure (WP 8) Project Management (WP 6) Awareness, Training, Consensus Building (WP7)

12. High level project plan • May 2008 – April 2009: Requirements and design • May 2009 – April 2010 (or a bit later): Implementation • May 2010 – November 2011: Pilots running • Must take a rather pragmatic approach to make things work in this time frame • EU Commission points at PEPPOL as a promising approach for e-signature interoperability across Europe

13. Public Procurement as a Case Study PEPPOL eSignature Interoperability

14. The Public Procurement DirectivesNote: Cover tendering only Qualified signatures not available in all member states and use limited in many member states. And qualified is a European term. And not all eIDs will be qualified even in Europe • “Directives oblige any public purchaser in the EU to effectively recognize, receive and process tenders submitted, if required, with aqualified signature and their accompanying certificates, regardless of their origin within the EU or their technical characteristics” • “The existing significant differences between qualified signatures …. should therefore be reason for great concern. The interoperability problems detected despite the existence of standards …. pose a real and possibly persistent obstacle to cross-border e-procurement.”

15. Other Procurement Processes • Public Procurement Directives cover tendering only • Service Directive requires e-signatures • E-invoicing – e-signature primary mechanism • Can be avoided (“EDI Clause” of VAT Directive) if other mechanisms are guaranteed to provide authenticity and integrity end to end • Can e-signatures be avoided in the PEPPOL case? • Note: European e-invoicing landscape is changing • Order process, catalogue etc. not covered by EU defined legal requirements for e-signature • May be national, legal requirements

16. Paper-Based E-signature Paradigm • Qualified eID must be issued to a natural person • Only a person can produce a qualified signature • But e-invoices are usually not signed in a user interface • Personal signature is a problem • An e-signature binds to the name in the eID • Why does that name have to be a person name? • E.g. corporate signatures on e-invoices (person is not relevant) • What about automated orders/invoices between systems with no person involved? • But we are largely stuck with personal signatures in Europe • Possible compromise: Inner, personal signature, outer corporate signature (e.g. invoice issuer)

17. PEPPOL Deliverable D1.1 • Functional specifications for cross-border use of eSignatures in public procurement – 7 parts: • Background and Scope • E-tendering Pilot Specifications • Signature Policies • Architecture and Trust Models • XKMS v2 Interface Specification • OASIS DSS Interface Specification • eID and e-Signature Quality Classification http://www.peppol.eu/deliverables/wp-1

18. Signature Policies (1)Commitment Rules and Protocols • Commitment rules – binding of person names to enterprises, roles and authorizations • Alternative 1: Accept signed documents (optimistic approach) • Alternative 2: Registration procedure to establish bindings • Alternative 3: Virtual Company Dossier (VCD) and attestations • Alternative 4: Corporate eID (not acceptable in many countries) • Alternative 5: Employee eID (not widely deployed) • Alternative 6: Inner personal + outer corporate signatures (requires solutions for issuing of corporate eIDs) • Business protocols • Which documents shall/should/can be signed in an eCommerce protocol? • Implications of these signatures – might be from authentication and integrity protection to a legally binding offer or contract • Adding signatures to business protocol specifications

19. Signature Policies (2)Signature Validation Policy • Signature validation policy elements (ETSI TR 102 038) • Rules to be followed by signer • Rules to be followed by verifier • Rules for use of certification authorities (CA) • Rules regarding time stamps and TSAs (Time Stamp Authority) • Rules on use of AAs (Attribute Authority) • Rules on use of algorithms • Quality and procedural requirements for these elements • Receiver (relying party) sets policy requirements • May be determined by legislation/regulations • Transparent, non-discriminatory rules needed • E.g. not just a list of accepted CAs – today’s usual situation

20. Pragmatic approach • Signature policy according to ETSI • Shall have a unique OID (Object Identifier) • Always in human readable form • Parts may be machine processable • According to PEPPOL (pragmatic due to pilot scope) • Define the relevant parts, not necessarily complete • Never mind the OID • Quality parts must be made machine processable • PEPPOL is largely about automated system-system interactions • Procedural rules must be transparent and may be processable

21. Procedural Rules, PEPPOL • Signature formats (SDO – Signed Data Object) • Few requirements on sender, receiver must cope • Longer term: XAdES/CAdES/PAdES (lack software support at present) • Include certificates, possibly path, in SDO • Requirements for signature verification process • Define certificate validation process (path validation etc.) • Revocation checking at receiver, no OCSP required from sender • Requirements for quality and approval status of eIDs and eSignatures • Do not use a TSA on sending side! Receiver may use Time Stamp Auth. • Sending side TSA means a huge interoperability problem on mutual recognition of TSAs across Europe – role not defined in all MSs • Logging, archival, records creation • Local matter to receiver – information must be available Sending side must comply with these

22. Rich Service Interfaces • Certificate validation: Profile of XKISS part of XKMS v2 • Based on German profile • Returns assertion on certificate(s) • Quality assertions • Procedural rules (path validation, revocation checking) • Entire, signed document: Profile of OASIS DSS validation • Based on earlier work in Norway • Whole signed document or pairs of signatures and hash values • Not necessary to send document content • Returns overall assertion on document and individual assertions on each signature and certificate

23. Interoperability levels • Legal interoperability - ensure legal acceptance across borders • Qualified eID/signature, agreements based, policy based • Qualified is not non-discriminatory today since not available in all MSs • Organisational interoperability • Use of signatures in (business) processes • Binding to (organisational) roles and authorisations • Signature acceptance (quality etc.) criteria • Business process standards/specifications, (business) registers or attribute certificates, standard/transparent risk management criteria and quality assessments • Semantic interoperability • Making use of names and identifiers • Alignment/standardisation, normalisation, translation, identity management • Technical interoperability • Signature processing requirements • Formats, communication protocols, interfaces, algorithms • Standardisation

24. Federated Validation Services … Qualified CAs … Other CAs OCSP (or CRL) XKMS or OASIS DSS XKMS Response signed by ”local” VS Signer’s CA Trust status list service Validation Service Signer Validation Service Country 1 Receiver Country 2

25. Validation Service vs Authority • Service: Process eIDs (and signatures), issue assertion, responsible only for its own actions • Assertions are validation responses • Refer to CAs (their policies and national laws) for liability • Sufficient for qualified level (?) • Authority: Independent liability for validation assertion • Assertions are authority statements • One trust anchor for the relying party • Uniform liability for all eIDs of same quality • From national law (of the CAs) to contract law • Very important for scaling – globally and not only Europe • May be very important for non-qualified eIDs/eSignatures

26. Validation Service vs Local • VS used to handle all eID issuers that are not handled locally • Tune this as desired from 100 % locally to 100 % by VS • Pure add-on to existing solutions • Add a VS interface to handle all not handled locally • VS may issues “external” validation assertion • An advantage in some cases even for “local” eID issuers

27. Piloting eSignatures

28. Pilots scheduling • 1st May 2010 – ready for test pilots • XKMS responders from bos (Bremen Online Services) • “National” responders for some countries • Request chaining • Autumn 2010 – until production pilots 1st November • Expanding the above to more countries and CAs • Planned addition of commercial validation service and the OASIS DSS interface • Until end October 2011 • Testing, refinement, further development

29. Current Test Pilot TeleSec TC-Trust Bundesnotarkammer Commfides Buypass InfoCert Actalis LISIT Certigna BANQUE POPULAIRE

30. XKMS Responder • The XKMS responder was delivered to partners end of January by Bremen Online Services • This is version 0.9 (test pilot version) • Software components/libraries (workshop on January 27th) • VMWare Image (DVD) • Configuration according to documentation was done by bos • Example: the German responder: http://212.48.116.113:8080/PeppolWebAdmin/WebAdmin • Version 1.0 will be delivered by May 1st 2010 for production pilot

31. Validation Software • First version of validation software client is available from Bremen Online Services • PEPPOL Signer 2.2.0.0 • Certificate validation via XKMS responders • HTML inspection sheet • Handling of signatures: PKCS#7 detached and enveloped and PDF inline • German qualified signatures • Next version with XAdES support by end of march

32. Need real pilot cases • Co-operate with PEPPOL WP3-5 on signed orders, order confirmations, invoices, catalogues • Ongoing co-operation with PEPPOL WP2 on signatures for VCD (Virtual Company Dossier) • Need to test signed tenders due to the EU Directives on public procurement

33. Basis for signature policies Quality Classification of eIDs and eSignatures

34. What can be ObjectivelyVerified at Receiving Side? • Signer’s environment • Only to the extent described by the certificate policy • E.g. use of SSCD or not • Quality of certificate • Described by certificate policy (possibly also CPS etc.) • Assurance – is CA operation compliant with its policy? • National (international?) approval status • E.g. is the CA listed as supervised issuer of qualified certificates? • Cryptographic quality • Hash algorithm • Public key algorithm and key size • Receiver should not be forced to read certificate policies or examine trust status lists

35. Certificate Policy:Claimed Quality of Certificate 6: QCP+ – qualified signature level 5: QCP – qualified certificate but not qualified signature (4+: NCP++ – NCP with certified SSCD) 4: NCP+ – highest available for authentication and legal persons 3: NCP 2: LCP 1: Low but policy exists or other assessment possible 0: Very low or not assessable (e.g. no policy exists) • All policy indications are “or similar” to accommodate non-European certificates (e.g. map FBCA levels) • Could add more levels if desired .....

36. Certificate Quality Classification eID quality levels: 0-6

37. Certificate Assurance Leveland Legal Status 7: Accredited – external compliance audit 6: Supervised – external compliance audit 5: External compliance audit and certification 4: External compliance audit 3: Supervision without compliance audit 2: Internal compliance audit at CA 1: Independent document review 0: Self-assessment only • 6-7 is the European regime for qualified certificates • Reuse assessments done in conjunction with FBCA, SAFE Bridge-CA and others

38. Quality Classification – Assurance Approval status levels: 0-7

39. Quality Classification – Crypto • Cryptographic Quality • Hash quality for signatures (note: controlled by signing software) • Public key algorithm and key length quality • Based on recommendations from ETSI, NIST and other sources • Quality 0: Inadequate – should not be trusted • E.g. MD5 hash • Quality 1: Reasonably secure for 3 years • E.g. SHA-1 hash, RSA-1024 • Quality 2: Regarded as trustworthy for 5-10 years • E.g. SHA-224, RSA-2048 • Quality 3-5: Increasing levels of security

40. Signature Quality • eID quality (0-6) • 6: Qualified signature policy level • 5: Qualified certificate policy level • eID assurance level (0-7) • 6-7: Supervised/accredited eID issuer • Hash algorithm quality (0-5) • Controlled by signing software, not by eID issuer • 1: SHA-1 hash (up to 3 years perspective) • 2: SHA-224 (5-10 years perspective) • Public key algorithm and key length quality (0-5) • 1: RSA-1024 • 2: RSA-2048

41. Conclusions • Public procurement is really B2B scenario • With public agency in “B” role • Signatures required – validation and acceptance needed • Cryptographic validity • Signature policy adherence • Names -> organization, roles, authorizations • What must be signed? • Signature formats and verification rules • Quality and assurance (approval status) requirements • Trust models for validation “proofs” • Standards based interfaces – should be standardised • Quality classification scheme – should be standardised • Can we solve this scenario, we are near a general solution!

42. Contact Furtherinformation can be obtained from the regional contact points below and at http://www.peppol.eu Denmark, Estonia, Finland, Ireland, Iceland, Ireland Lithuania, Latvia, Norway, Sweden, UK/Scotland please contact: Mr. André HODDEVIK(Project Director) Email: andre.hoddevik@peppol.no Austria, Czech Republic, France, Hungary, Poland, Slovakia, Slovenia, Switzerland and Western Balkan please contact: Mr. Peter SONNTAGBAUER(Public Relation Director) Email: peter.sonntagbauer@brz.gv.at Belgium, Germany, Luxembourg, Netherlands please contact: Ms. Maria A. WIMMEREmail: wimmer@uni-koblenz.de Bulgaria, Cyprus, Italy, Greece, Malta,Portugal, Spain, Romaniaplease contact: Mr. Giancarlo DE STEFANO Email: giancarlo.destefano@tesoro.it

43. Contact for presenter Jon Ølnes Senior Advisor National Programme for eID Infrastructure in Public Sector Difi – Agency for Public Management and eGovernment P.O.Box 8115 Dep, N-0032 Oslo, Norway http://www.difi.no jon.olnes@difi.no +47 478 46 094