IDA Interchange of Data between Administrations

1. IDAInterchange of Data between Administrations A ‘bridge CA’ for Europe’s public administrations European Signatures vs Global Signatures EESSI, Rome, 7th April 2003 Paul E Murphy IDA, Enterprise Directorate General European Commission

2. IDA programme of DG Enterprise • IDA bridge CA project • history • current developments • Some PKI issues

3. The IDA programme • Interchange of Data between Administrations • Enterprise Directorate General, European Commission • 1999 - 2004

4. The IDA programme • Co-ordinates the exchange of information between the MS and EC in support of: • the management of the single market • the Community decision-making process • a wide range of Community policies

5. What does IDA do? • Sectoral projects for information exchange in support of the Single Market • Agriculture, Employment, Environment, Health, Enterprises, Statistics, etc.

6. What does IDA do? • Generic Services • TESTA (IP network), Public Key Infrastructure (PKI CUG), CIRCA (workgroup) • Common tools and techniques • MoReq, architecture guidelines for interoperability, STATEL, etc.

7. IDA PKICUG • IDA issues X.509v3 electronic certificates • to members of IDA Networks • for use in: • SSL • S/MIME • electronic signature • Now proposes a ‘bridge CA’

8. Why? • eEurope Action Plan • support for electronic signatures in public administration • Member States ’ policy • ability to use the electronic certificates issued by their national CAs in pan-European business • IDA policy • encourage interoperability, use of standards, use of e-signature, etc. • Conclusions from previous projects

9. Feasibility study • Collect and summarise the views of the Member States • Raise major potential issues • legal and political • organisational • technical • Discuss possible solutions • Propose further steps

10. Legal and political aspects A series of issues to be agreed prior to operations • No reluctance to the principle of mutual recognition of national Certification Authorities • some level of national control was requested • The major issue raised was the understanding of electronic signatures • qualified certificates versus non-qualified • understanding of (in particular) Article 5 of the European Directive • requirement to establish equivalence rules between qualified certificates throughout Europe • The liability of the authorities issuing certificates should be limited to the respect of attribution procedures

11. Ways to manage the common organisation Governance • Comply with existing IDA rules • Organisational instance to be defined, including: • a Governing Body composed of representatives • of the Member States and of the European Institutions ? • of the participating Certification Authorities ? • a specific team to manage operations • a technical infrastructure depending on the architecture chosen • Definition and application of procedures • agreement of a given CA to be recognised by the bridge • periodic verification of compliance

12. Required services to all user profiles Core functionality • Exchange and renewal of cross-certificates or of any equivalent information (e.g. signed lists of trusted root certificates) • Publication of general information • Certificate Policies • Publication of certification information • trusted CA certificates • certificate revocation lists • Publication of technical interoperability specifications • According to the solution chosen, availability of a test bed to validate the interoperability of a given CA with the other ones

13. Set up an intermediate infrastructure Major recommendation • A set of organisational measures and of technical tools participating in establishing permanent, secure and reliable trust between the Public Key Infrastructures established by the Member States for the usage of their public sector • The primary goal is to help civil servants to recognise the valid credentials of their correspondents in other Member States, hence to establish a secure environment for electronic data exchange • as a secondary goal, the same service could be provided to companies and individuals to recognise civil servants • Optionally, other PKIs, in particular those providing Public Key Certificates to the major partners of the Administrations, could be recognised as well

14. Suggested organisation Governing body Member States European Institutions Member CAs Policy Authority Management team Technical assessors

15. The basic charter of collaboration Memorandum of Agreement • Must be established before any operational start up • Should cover the following descriptions • responsibility, commitments and liability of all participating authorities • rules for the governance of the intermediate infrastructure • building blocks of the certificate policies, including • profile of contents • assurance levels • management procedures • services provided and expected from the infrastructure by the participating and relying parties • procedures for an applicant party to become a participating authority

16. Possible ways to interconnect the Public Key Infrastructures Architecture • Hierarchy • a central Certification Authority recognises each CA of the Member States or of national organisations • relying parties just trust the central CA • Mesh • the Certification Authorities of the Administrations or of public bodies directly recognise each other • each relying party justs trust its own CA that in turn trusts the remote CA • Web / trust model • a repository of trusted Certification Authorities • each relying party trusts all distributed certificates of the list • Hub-and-spoke infrastructure ("bridge") • a central technical infrastructure cross-recognises each concerned CA • each relying party justs trusts its own CA that trusts the bridge that in turn trusts the remote CA

17. A central Certification Authority recognises each CA of the Member States or of national organisations • Relying parties just trust the central CA Hierarchical

18. The Certification Authorities of the Administrations directly recognise each other • Each relying party justs trust its own CA that in turn trusts the remote CA Mesh (peer-to-peer cross certification)

19. Web / trust (distribution of trusted lists) • A repository of trusted Certification Authorities • Each relying party trusts all distributed certificates of the list

20. A central technical infrastructure cross-recognises each CA • Each relying party justs trusts its own CA that trusts the bridge that in turn trusts the remote CA Bridge model

21. Modified bridge CA model Bridge model + web / trust model

22. A compromise between the proposed models Suggested BCA model • The bridge trusts (i.e. accepts to certify) each proposed member CA • ‘Root certificates be distributed by the bridge under the form of signed lists • relying parties trust each CA recorded in the list • Member States could update the list and re-sign it • ‘Cross-certification’ with the bridge CA • - relying parties trust their own CA that is cross-certified with the bridge that in turn trusts remote CAs that are cross-certified with the bridge • Member States may implement validation authorities inside their own administrations or public bodies

23. Consultation of certificates Consultation of status Relying party Relying party Relying party Local verification Functioning of the suggested architecture DOMAIN A DOMAIN C Bridge CA CA A CA C Cross certification Simple certification CA A CA B CA C … (signed bridge CA) Validation authority Simple certification DOMAIN B CA B

24. A set of European-level policies Certificate policies • A Policy Authority should be created by the Governing Body to: • define the intended usage of families of certificates • establish the associated assurance levels and minimum management procedures • draw up and publish the resulting Certificate Policies • European policies (possibly sectoral) rather than national policies • simpler management • unique understanding • no need for complex mapping • In the long term, the identity of policies should be registered into the certificates and the relying parties requested to verify the proper usage of certificates

25. Current Phase: 1 • Step-by-step approach • Draft Memorandum of Agreement / Understanding • Outline Certificate Policy • Outline Technical Requirements for participating CAs • CTL Feasibility Study • Outline Operational Procedures • Outline of Pilot and Test Plan

26. Current Phase: 2 • Memorandum of Agreement / Understanding for participating Member States • Bridge CA Certificate Policy • Technical Requirements for participating CAs • Bridge CA Technical Architecture • Recommendations on use of CTLs • Bridge CA Operational Procedures • Agreed Pilot and Test Plan

27. Next Phase • Pilot of Bridge CA: • Generate CTLs; • Generate Cross-Certificates • Publicly accessible directory • Test: • Operation of bridge CA • Bridge CA in a simulated IDA network • Member State to Member State exchanges • Bridge CA Certificate Practices Statement • Bridge CA Certificate Policy • Technical Requirements for participating CAs • Bridge CA Technical Architecture • Recommendations on use of CTLs • Bridge CA Operational Procedures • Agreed Pilot and Test Plan

28. Then • Decision Time

29. Bridge CA feasibility study • http://europa.eu.int/ISPO/ida/jsps/index.jsp?fuseAction=showDocument&parent=news&documentID=581

30. European vs Global Signatures? • IDA needs ‘pan-European’ signatures • ability to use electronic certificates in trans-border applications (e.g. public e-procurement) • Establish trust in CAs in other Member States • cross-certification? • Mutual recognition? • Bridge CA? • Allow for local control

31. European vs Global Signatures? • Establish the authenticity and validity of electronic certificates issued in a Member State other then the relying party’s • European level certificate policies • Correspondence with national certificate policies • Interoperability

32. Why do we introduce PKIs? • Work electronically with business partners • Reduce costs or increase profits • Increase operational efficiency • Be more effective in achieving objectives • Provide value added services that cannot be provided with paper-based working • Government policy (public administration)

33. Basic requirements for PKIs • Provide a real business benefit • Cost-effective • Easy / easier than paper-based equivalents • Easy to set up • Easy to operate • Interoperable with other PKIs • Add value

34. Some PKI Problems • S/MIME v2: Authentication and confidentiality • Scalability • Certificate Policies • The way people and organisations work • Encryption • Other problems

35. How work is performed • Personal certificates vs. functional organisational units • Functional certificates • organisational units are not legal entities • non-repudiation • electronic signature • ‘Registration’ of organisational units

36. How work is performed • PKI • Personal certificates • Work • Organised on functional units • Shared functional certificates

37. How work is performed • Role-based certificates • The role confirms the authority of the certificate holder • The role may determine the validity of the business event • Volatility of personnel • X.509 v3 certificate extensions • Interoperability and language problems

38. Other problems • Directory and discovery problems • Trust relationships • ‘Bridge’ CA • Ability to follow a certification path • Certificate revocation status checking • CRLs, OCSP, etc. • Cross-certification • etc.

39. What do we need? • Interoperable standards-based products that are: • Available from multiple suppliers, • Interoperable with or can • Exchange information with the • Office products typically found in modern enterprises and public sector organisations, and • Work across Europe’s borders. • Agreed PKI models that are congruent with the way business is carried out

40. IDA programme of DG Enterprise • IDA bridge CA project • history • current developments • Some PKI issues

41. Thank you Paul E. Murphy IDA programme European Commission (SC 15 02/65) B-1040 Brussels, Belgium fax: +32 2 299 0286 e-mail: Paul-E.Murphy@cec.eu.int