imported>TaxonBot: Bot: Auflösung doppelter toter Links nach https://de.wikipedia.org/w/index.php?title=Wikipedia:Bots/Anfragen&oldid=266185123#Aufl%C3%B6sung_der_doppelten_Toten_Links

2026-04-17T09:37:48Z

Bot: Auflösung doppelter toter Links nach https://de.wikipedia.org/w/index.php?title=Wikipedia:Bots/Anfragen&oldid=266185123#Aufl%C3%B6sung_der_doppelten_Toten_Links

Neue Seite

'''Long-Term Archiving and Notary Service''' ist ein Begriff aus der [[Kryptologie]].

Von 2003 bis 2011 arbeitete die gleichnamige Working Group<ref>{{Webarchiv |url=http://www.ietf.org/html.charters/ltans-charter.html |text=IETF LTANS Working Group |wayback=20090710130327 |archiv-bot=2019-04-28 06:25:38 InternetArchiveBot}}</ref> innerhalb der Internet Engineering Task Force ([[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,<ref>[https://tools.ietf.org/wg/ltans/ LTANS Status Page]</ref> 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 [[Urheber]]schaft 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 [[Kryptographie|kryptographische]] [[Algorithmus|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 Weblink 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 ging nach der Veröffentlichung der Anforderungen (<nowiki>RFC 4810</nowiki><ref>{{RFC-Internet |RFC=4810 |Titel=Long-Term Archive Service Requirements |Datum=2007-03}}</ref>) im Jahr 2006 das Thema des Nachweises der [[Integrität (Informationssicherheit)|Integrität]] und [[Authentizität]] von signierten Dokumenten an.
; LTANS-ERS
: Ergebnis war die Veröffentlichung des <nowiki>RFC 4998</nowiki><ref name="RFC4998" /> mit der Beschreibung des [[Evidence Record Syntax]] im Jahr 2007, der das [[Datenformat]] des lückenlosen Nachweises eines signierten Dokuments inklusive seiner Neusignierungen spezifiziert.
; LTANS-ERS-SCVP
: Der anschließend veröffentlichte <nowiki>RFC 5276</nowiki><ref>{{RFC-Internet |RFC=5276 |Titel=Using the Server-Based Certificate Validation Protocol (SCVP) to Convey Long-Term Evidence Records |Datum=2008-08}}</ref> 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 ([[Elektronische Signatur|Zertifikatspfad]]) inklusive der [[Elektronische Signatur|Sperrlisten]], die während der ersten Verifikation von den [[Elektronische Signatur|Zertifizierungsdiensteanbietern]] erhalten wurden, werden von dem SCVP-Service für zukünftige Anfragen gespeichert.
; LTANS-XMLERS
: Der Spezifikation von <nowiki>RFC 4998</nowiki><ref name="RFC4998" /> folgend, wurde 2011 ebenfalls ein äquivalenter Standard <nowiki>RFC 6283</nowiki><ref>{{RFC-Internet |RFC=6283 |Titel=Extensible Markup Language Evidence Record Syntax (XMLERS) |Datum=2011-07}}</ref> im XML-Format verabschiedet. Beide (<nowiki>RFC 4998</nowiki> und <nowiki>RFC 6283</nowiki>) sind in ihrer Funktion gleichwertig, sichern den lückenlosen Nachweis eines signierten Dokuments inklusive seiner Neusignierungen und unterscheiden sich hauptsächlich durch die jeweils von ihnen genutzten Formate (<nowiki>RFC 4998</nowiki> nutzt ANS.1, <nowiki>RFC 6283</nowiki> 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<ref>[https://tools.ietf.org/html/draft-ietf-ltans-dssc-09 Data Structure for the Security Suitability of Cryptographic Algorithms – LTANS-DSSC.] Internet-Draft.</ref> 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 [[Signaturgesetz (Deutschland)|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<ref>[https://tools.ietf.org/html/draft-ietf-ltans-ltap-08 Long-term Archive Protocol – LTANS-LTAP.] Internet-Draft.</ref> 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.

Seit 2010 existieren Lösungen, bei denen die Beweiswerte direkt im Dokumentencontainer abgelegt und versiegelt werden. Proprietäre, separate Systeme zur Verwaltung der Evidence Records können dadurch komplett entfallen.<ref>[http://docs.ts.fujitsu.com/dl.aspx?id=ab50bf6a-06de-4464-bae0-bfbaa6ef1752 Produktbeschreibung: SecDocs - Beweiserhaltene Langzeitarchivierung]</ref>

== Zertifizierung ==

Die Technische Richtlinie TR-03125<ref>{{Webarchiv |url=https://www.bsi.bund.de/ContentBSI/Publikationen/TechnischeRichtlinien/tr03125/index_htm.html |text=BSI TR-03125 Beweiswerterhaltung kryptographisch signierter Dokumente |wayback=20110928111010 |archiv-bot=2019-04-28 06:25:38 InternetArchiveBot}}</ref> des BSI ([[Bundesamt für Sicherheit in der Informationstechnik]]) nutzt die [[Evidence Record Syntax]] zur Beweisführung und erlaubt entsprechende Zertifizierungen<ref>[https://www.bsi.bund.de/SharedDocs/Zertifikate/CC/Sonstiges/0685.html BSI-DSZ-CC-0685-2012.] bsi.bund.de {{Toter Link |url=https://www.bsi.bund.de/SharedDocs/Zertifikate/CC/Sonstiges/0685.html |date=2019-04 |archivebot=2019-04-28 06:25:38 InternetArchiveBot}}</ref> auf der Basis des Schutzprofils (Protection Profile)<ref>{{Toter Link |datum=2019-04 |url=https://www.bsi.bund.de/ContentBSI/Themen/ZertifizierungundAnerkennung/ZertifierungnachCCundITSEC/SchutzprofileProtectionProfile/schutzprofile.html |text=Common Criteria Protection Profile for an ArchiSafe Compliant Middleware for Enabling the Long-Term Preservation of Electronic Documents (ACM PP). |archivebot=2019-04-28 06:25:38 InternetArchiveBot}} bsi.bund.de</ref> [[ArchiSafe]].<ref>[https://www.bsi.bund.de/SharedDocs/Downloads/DE/BSI/Publikationen/TechnischeRichtlinien/TR03125/BSI_TR-ESOR_M1.pdf?__blob=publicationFile ArchiSafe-Modul.] (PDF) bsi.bund.de</ref><ref>{{Webarchiv |url=http://www.commoncriteriaportal.org/files/ppfiles/pp0049a.pdf |text=Certification Report BSI-CC-PP-0049-2008. |format=PDF; 543 kB |wayback=20120130050907 |archiv-bot=2019-04-28 06:25:38 InternetArchiveBot}} commoncriteriaportal.org</ref>

== 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 Weblink) legt auf Basis des [[SOAP]] als auch REST-Protokolls fest, wie Anwendungen Content in entsprechende [[Repository|Repositories]] (u. a. auch Archive) in Aktenstrukturen in Bezug auf Zugriffsrechte ablegen, suchen und wiederfinden können.

== Weblinks ==
* [[Content Repository for Java Technology API|Content Management Interoperability Service]]
* [http://www.oasis-open.org/who/ Mission Statement.] OASIS.

== Einzelnachweise ==
<references>
<ref name="RFC4998">
{{RFC-Internet |RFC=4998 |Titel=Evidence Record Syntax (ERS) |Datum=2007-08}}
</ref>
</references>

{{SORTIERUNG:LongTerm Archiving and Notary Service}}
[[Kategorie:Kryptologie]]
[[Kategorie:Archivwesen]]
[[Kategorie:Notariat]]

Long-Term Archiving and Notary Service - Versionsgeschichte

imported>TaxonBot: Bot: Auflösung doppelter toter Links nach https://de.wikipedia.org/w/index.php?title=Wikipedia:Bots/Anfragen&oldid=266185123#Aufl%C3%B6sung_der_doppelten_Toten_Links