The OpenEvidence Project

1. The OpenEvidence Project Peter Sylvester, EdelWeb IETF - N° 57, Wien 2003-07-17 PKIX working group

2. OpenEvidence project • EU IST 5th framework • Accompanying measures • special action open source • duration april 2002 - Jan 2004 • budget 0.9 M€

3. Domain and goals • Paperless organisations • Legal value of dematerialized documents • Provide effectively enabling required techno • In addition to electronic signatures and certificates • Pragmatic approach • Implementable models • Open Source Approach

4. OpenEvidence Context • Emerging legal environments for • Recognition of electronic signatures • Long-term validity of electronic documents • Model : Third parties services for evidence creation and validation • Techniques • Time stamping, notarization, archiving, signature validation, … • Problems • Proprietary solutions, competition, secret agendas, .. • Thus, slow standardization (many years) • Even: competing technologies

5. State of the art • Much work in different areas • IETF, OASIS, ISO, ETSI, CEN, … • Vendors vs committees vs implementers • competition via technology differences • Need to distinguish facts from fiction • Language confusion • e.g. time stamping use cases

6. Electronic signature timesytamping Babylonian Problems EU Directive of Electronic Signatures

7. OpenEvidence Approach • Combine existing prototype solutions into open source • Only chance to avoid (brain-damaged?) costly proprietary solutions • Only way to foster actual deployment of dematerailization • No technology wars • no. XML vs ASN1 • No archiving vs time stamping • No signature vs hash linking • Use knowledge from real implementers

8. OpenEvidence Partners • EdelWeb - Groupe ON-X - France • techno provider and coordination • Cybernetica - Estonia • techno provider • C & A - Italy • techno provider • EADS Telecom • user and testbed

9. Deliverables • Actual Open Source • Client software • Access to servers, document handling • Server software • TSAs, DVCS, normalized journal formats • Creation and validation of evidences • Documentation • Open-Source Community Support • Experiments in test bed • Long term service, • User management • cessation of activity

10. Materialised document world • Users need to proove they possess a document at one particular time • Notary : confirm that at one time, two persons have agreed on the content of a document (witness) • At any time in the future, parties need to proove their agreement • Document content may be confidential • Document content can be controlled (by a governemental representative)

11. Consequences for dematerialisation • A tamper resistant proof of possession must be delivered by a trusted third party, • Trusted time stamp associated to the document • Validation service required • Long term archiving of documents and proof • Content protection in archive • Access possible by a content auditor

12. Technical deliverables • A reference implementation of Notarisation services(RFC 3029), • A minimal Notarisation client tool, • A enhanced GUI Notarisation client tool, • Test programs for all pieces of software, • Test bed application

13. Complementary deliverables • Trusted Time Stamping daemon (RFC 3161), • Hash Linking Time Stamping daemon, • journal and archiving of data modelled in XML.

14. Out of scope services • PKI and PMI, • Back end archival server with physical protection, • HTTP Front end, • Database Management System, • Redundant storage system,

15. OpenEvidence Summary • Integration of technology for evidence creation and validation • Context : dematerialised documents • Long-term validity • Complementary technologies • RFC 3029, RFC 3161 • Hash Linking Schemes for timestamping • Tests in application contexts • Demonstrator service, archive server

16. Timestamping • Different application contexts • short term high volume data • stock exchange order synchronisation • long term stability od documents • Complementary techno • RFC 3161, RFC 3029, Hash linking • signatures short term authentication • hash linking, publishing, and phys. Protection for long term

17. Long term protection • Digital signatures insufficient • Protect in space but not in time • Need redundant methods • like in real life • so far, only physical archiving • but: not enough experience • A attesttation from an archive = • electronic signature

18. User Control Application Context Notarisation Security measures Service Service Control & Audit OpenEvidence OpenEvidence Security Model Based on ISO 17799 or BS 7799

19. Secure journal and archive • Useful for common criteria • User hierarchies • Cessation of activity (partial and total) • Limited duration of storage (but not fixed) • certified transfer,archival with assertion • No deletion • Secure by hash linking and physical prot. • Auditable by random validation

20. DataCerts DataCerts Example Architecture (DVCS) Client A Client B Documents & DataCerts Documents & DataCerts Client A Client B DVCS interface OpenEvidence Broker Internal TSA Internal CA External interfaces:, CRL, OCSP, TSP, archivage, … AC externes TSAs Archiveur TSAs CAs Archival service Other TTPs

21. WP6 – Pilot Experimentation 2 official test beds have been defined : • Certified Mail (EADS-T) • File seals (EdelWeb) • Together with C&A for 3161 time stamp.

22. OpenEvidence and PKIX • Data Validation is on agenda • RFC 3161, RFC 3029 • Need updates • ntegration of hash linking • profiling for data validation • … • Certification and signature validation • semantic validation