The OpenEvidence Project Peter Sylvester, EdelWeb IETF - N° 57, Wien PKIX working group

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

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

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

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

Babylonian Problems Electronic signature timestamping EU Directive of Electronic Signatures

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

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

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

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)

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

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

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

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

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

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

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 An attesttation from an archive = electronic signature

OpenEvidence Security Model Based on ISO or BS 7799

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

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

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.

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