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

The OpenEvidence Project

Peter Sylvester, EdelWebIETF - N° 57, Wien

2003-07-17PKIX working group

OpenEvidence project EU IST 5th framework Accompanying measures special action open source duration april 2002 - 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

User Application Context

Service

Control

Notarisation

Service

Control & Audit

Securitymeasures

OpenEvidence

Based on ISO 17799 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

OpenEvidenceBroker

External interfaces:, CRL, OCSP, TSP, archivage, …

AC externes Archiveur

Client A Client B

CAs TSAs Archival service Other TTPs

Internal CA Internal TSA

DataCerts 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