Long-Term Archiving and Notary Service

Von 2003 bis 2011 arbeitete die gleichnamige Working Group^[1] innerhalb der Internet Engineering Task Force (IETF) an Spezifikationen rund um das Thema der Nachweisfähigkeit der Integrität von elektronischen Dokumenten, speziell signierten, im Kontext der Langzeitarchivierung. Das erste Ziel war es, die im ArchiSig-Projekt gewonnenen Konzepte in einen Standard zu überführen.Nach einer weiteren Phase der Anforderungsanalyse für ein Archivsystem, das entsprechende Services zur Verfügung stellt,^[2] wurden dann weitere Austauschformate sowie Protokolle spezifiziert.

Anforderungen an ein Long-Term Archive Service

Das primäre Ziel eines Long-Term Archive Service ist die Sicherung des Nachweises eines Anspruchs, der in einem elektronischen Dokument beurkundet wird, zu einem beliebigen Zeitpunkt in der Zukunft. Ein Long-Term Archive Service muss daher Anwendungsfälle wie Testamente, Landbesitzurkunden, medizinische Daten, Kriminalfallakten, persönliche Urkunden oder Verträge elektronisch unterstützen. Ein Long-Term Archive Service muss von unterschiedlichen Anwendern wie Organisationen, Einwohner, Richtern oder Notaren in gleicherweise genutzt werden können:

• Eine Firma speichert Verträge auf dem System eines Dienstleisters
• Ein Krankenhaus speichert medizinische Daten in einem internen System.
• Eine Privatperson möchte den Beweis erbringen, dass er ein bestimmtes Dokument zu einem bestimmten Zeitpunkt besessen hat, z.B. zwecks Beweises einer Urheberschaft oder eines Vertragszusatzklausel
• Ein Gesetzeshüter will seine Kriminalfallakten derart speichern, dass dessen Integrität auch noch Jahre später demonstriert werden kann

Für jedes der genannte Beispiele gibt es das komplementäre Beispiel eines Empfängers, z.B. eine Firma erhält den Vertrag im Streitfall zugeschickt oder ein Gesetzeshüter stellt Material für eine Anklage zusammen.

Aufgrund des Langzeitaspekts muss ein Long-Term Archive Service damit umgehen können, dass benutzte Techniken mit der Zeit altern. Das gilt für

• die verwendeten Speichermedien inklusive der Lesegeräte
• Dokumentenformate wie Tagged Image File Format (TIFF) und inzwischen auch PDF/A, die zwar heute aktuell sind, aber in 20 Jahren vermutlich durch andere ersetzt werden
• für kryptographische Algorithmen, die für die Signierung eines Dokuments verwendet wurden

Im Falle der Alterung muss daher ein Long-Term Archive Service in der Lage sein,

• Daten von dem bisherigen Medien auf ein anderes verlustfrei zu migrieren oder zumindest inklusive der zugehörigen Indexdaten zu exportieren
• die Transformation eines Dokuments in ein anderes Format inkl. der Behandlung von Signaturen ordnungsgemäß durchzuführen (siehe auch den Web-Link zum Projekt TransiDoc)
• signierten Dokumenten mit einem Zeitstempel neuzusignieren (bisher nur in Deutschland rechtlich eingefordert)

Diese ordnungsgemäße Durchführung dieser Services müssen auch nach Jahren lückenlos nachgewiesen werden können (→ Notary Service).

publizierte Spezifikationen

LTANS - Long-Term Archive Service Requirements

Die LTANS Working Group ist nach der Veröffentlichung der Anforderungen (RFC 4810) in 2006 anschließend das Thema des Nachweises der Integrität und Authentizität von signierten Dokumenten angegangen.

LTANS-ERS

Ergebnis war die Veröffentlichung des RFC 4998 mit der Beschreibung des Evidence Record Syntax in 2007, der das Datenformat des lückenlosen Nachweises eines signierten Dokuments inklusive seiner Neusignierungen.

LTANS-ERS-SCVP

Der anschließend veröffentlichte RFC 5276 spezifiziert die Schnittstelle zu dem Service, bei dem ein Evidence Record zu einem Objekt angefordert wird. Das Objekt wurde zuvor schon einmal in diesem als SCVP-Service genannten System registriert. Sämtliche Zertifikate (Zertifikatspfad) inklusive der Sperrlisten, die während der ersten Verifikation von den Zertifizierungsdiensteanbietern erhalten wurden, werden von dem SCVP-Service für zukünftige Anfragen gespeichert.

LTANS-XMLERS

Der Spezifikation von RFC 4998 folgend, wurde 2011 ebenfalls ein equivalenter Standard RFC 6283 im XML-Format verabschiedet. Beide (RFC 4998 und RFC 6283) sind in ihrer Funktion gleichwertig, sichern den lückenlosen Nachweises eines signierten Dokuments inklusive seiner Neusignierungen und unterscheiden sich hauptsächlich durch die jeweils von ihnen genutzten Formate (RFC4998 nutzt ANS.1, RFC 6283 nutzt XML).

Spezifikationen in Bearbeitung

Die LTANS Working Group arbeitet an den folgenden weiteren RFCs:

LTANS-DSSC

Die Spezifikation Data Structure for the Security Suitability of Cryptographic Algorithms^[3] beschreibt die Datenstruktur einer Information über die Stärke eines Kryptographischen Algorithmus in der Vergangenheit, der Gegenwart als auch der Zukunft, wie sie von einer Organisation wie der Bundesnetzagentur zur Verfügung gestellt werden soll. Stand heute werden die Algorithmenstärken in einem PDF-Dokument jährlich von der Bundesnetzagentur im Kontext des Signaturgesetzes veröffentlicht und manuell in SCVP-Systemen eingepflegt werden. Mit der DSSC-formatierten Datei sollen SCVP-Systeme zukünftig in der Lage sind, entsprechende Information automatisiert zu verarbeiten.

LTANS-LTAP

Das Long-term Archive Protocol^[4] dient als einheitliche Schnittstelle, um seitens einer Anwendung Daten mit einem Long-term Archive Service auszutauschen, z.B. um sie zur Aufbewahrung zu übergeben, nach ihnen zu suchen oder sie für eine Anzeige wiederzubeschaffen.

Umsetzungen

Bisher umgesetzt wurde hauptsächlich die Evidence Record Syntax inklusive entsprechender Datenhaltung in einer SQL-Datenbank durch deutschen Hersteller von Signaturanwendungskomponenten (siehe Artikel Evidence Record Syntax) mit bisher eigenen, proprietären Schnittstellen.

Zertifizierung

Die Technische Richtlinie TR-03125 ^[5] des BSI ([Bundesamt für Sicherheit in der Informationstechnik]) nutzt die [Evidence Record Syntax] zur Beweisführung und erlaubt entsprechende Zertifizierungen nach einem verabschiedeten Schutzprofil.

Kritik

Zur Kritik am Neusignieren qualifiziert signierter Dokumente, die in einem elektronischen Archiv gespeichert sind, siehe den Artikel ArchiSig.

Ob sich der Internet-Draft LTANS-LTAP durchsetzen wird, mag bezweifelt werden. Inzwischen haben sich alle marktbeherrschenden Hersteller wie IBM, SAP, Microsoft, EMC und ORACLE zur Definition des Standards CMIS unter der Oberhoheit der Organization for the Advancement of Structured Information Standards (OASIS) zusammengefunden. Der Content Management Interoperability Service (siehe Web-Link) legt auf Basis des SOAP als auch REST-Protokolls fest, wie Anwendungen Content in entsprechende Repositories (u.a. auch Archive) in Aktenstrukturen in Bezug auf Zugriffsrechte ablegen, suchen und wiederfinden können.

Weblinks

• ArchiSig-Projektseite
• TansiDoc-Projektseite
• Content Management Interoperability Service
• OASIS - Mission Statement

Einzelnachweise

1. ↑ IETF LTANS Working Group
2. ↑ LTANS Status Page
3. ↑ Internet-Draft: Data Structure for the Security Suitability of Cryptographic Algorithms - LTANS-DSSC
4. ↑ Internet-Draft: Long-term Archive Protocol - LTANS-LTAP
5. ↑ BSI TR-03125 Beweiswerterhaltung kryptographisch signierter Dokumente