Analyse PSI-Richtlinie und Metadaten Standards

Transkript

1 Dokumentation Analyse PSI-Richtlinie und Metadaten Standards Version 1.0, Klaus Stranacher Zusammenfassung: Die EU PSI-Richtlinie wurde im Juni 2013 aktualisiert und berücksichtigt nun die Entwicklungen der Open Data Bewegung. Daher wird in diesem Dokument untersucht inwiefern Sicherheitsaspekte und Vertrauenswürdigkeit der Informationen in der Richtlinie behandelt werden. Weiters beinhaltet das Dokument eine Machbarkeitsstudie hinsichtlich der Anwendbarkeit des Konzepts für ein vertrauenswürdiges Open Government Data auf die Anwendungsfälle der PSI-Richtlinie. Abschließend behandelt das vorliegende Dokument eine Analyse von Metadaten-Spezifikationen in Bezug auf die Signaturfähigkeit der Metadaten um auch Metadaten authentisch und integritätsgesichert zur Verfügung zu stellen. E-Government Innovationszentrum Inffeldgasse 16/a, A-8010 Graz Tel Fax Das E-Government Innovationszentrum ist eine gemeinsame Einrichtung des Bundeskanzleramtes und der TU-Graz

2 Inhaltsverzeichnis 1 Einleitung PSI Richtlinie Einleitung PSI-Richtlinie (2013) Machbarkeitsstudie Signaturformate Einleitung CAdES Signaturen Einleitung Struktur Eignung XAdES Signaturen Einleitung Struktur Eignung PAdES Signaturen Einleitung Struktur Eignung Metadaten Format CKAN-Metadaten Einleitung Struktur Signaturmöglichkeiten OGD Metadaten Österreich Einleitung Struktur Signaturmöglichkeiten OGD Metadaten Deutschland Einleitung Einleitung 2

3 4.3.2 Struktur Signaturmöglichkeiten Dublin Core Metadaten Einleitung Struktur Signaturmöglichkeiten MoReq Metadaten Einleitung Struktur Signaturmöglichkeiten Zusammenfassung Zusammenfassung Abbildungsverzeichnis Abbildung 2.1 Zeittafel PSI-Richtlinien, IWG und OGD Abbildung 2.2 Vertrauenswürdige Datenweiterverwendung laut PSI-Richtlinie Abbildung 3.1 SignedData Containertyp Abbildung 3.2 XMLDSIG Struktur Abbildung 3.3 XAdES-BES/EPES Struktur Abbildung 3.4 PDF-Signatur Abbildung 4.1 Metadatenstruktur OGD-AT Abbildung 4.2 Ausschnitt Metadatenstruktur Deutschland Abbildung 4.3 Ausschnitt Metadatenstruktur MoReq Einleitung 3

4 1 Einleitung Die EU PSI-Richtlinie (Public Sector Information) [Euro03] aus dem Jahre 2003 legt Anforderungen für die Weiterverwendung von Informationen des öffentlichen Sektors fest. Innerhalb Österreichs wurde diese Richtlinie im Rahmen des Informationsweiterverwendungsgesetz (IWG) [IWG05] umgesetzt. Das Ziel dieser Richtlinie bzw. des IWG war die Steigerung der Wertschöpfung durch die Weiterverwendung der Informationen, die der öffentliche Bereich bereitstellt. In den letzten Jahren hat die Open Government Data Bewegung immer mehr an Bedeutung gewonnen. So stehen beispielsweise über die Plattform data.gv.at aktuell Datensätzen und 173 registrierten Anwendungen zur Verfügung. Diese Open Government Data Bewegung konnte von der PSI-Richtlinie im Jahre 2003 nicht berücksichtigt werden, da es diese Bewegung seinerzeit schlichtweg nicht gegeben hat. Aus diesem Grund wurde die PSI-Richtlinie novelliert und die aktualisierte Fassung [Euro13] im Juni 2013 veröffentlicht. Diese Fassung bezieht Open Government Data explizit ein und erweitert auch den Anwendungsbereich der Richtlinie. In diesem Projekt soll nun untersucht werden inwiefern Sicherheitsaspekte und Vertrauenswürdigkeit der Informationen innerhalb der neuen PSI-Richtlinie behandelt werden. Es soll weiters eine Machbarkeitsstudie zur Anwendung des Konzepts für Vertrauenswürdiges Open Government Data (siehe Vorjahresprojekt OpenData und elektronische Dokumente [Stra12]) auf die Anwendungsfälle der PSI-Richtlinie erfolgen. Speziell innerhalb von Open Government Data sind entsprechende Metadaten von großer Wichtigkeit. Sie ermöglichen es detaillierte Information über die bereitgestellten Daten selbst anzugeben. Wie auch bei offenen Daten selbst, stellt sich auch bei Metadaten die Frage der Vertrauenswürdigkeit. Um nun auch authentische und integritätsgesicherte Metadaten zur Verfügung zu stellen, soll schließlich auch die Signaturfähigkeit der wichtigsten Metadaten-Formate (OGD Metadaten Österreich/Deutschland, CKAN, etc.) untersucht werden. Der Rest dieses Dokuments ist daher wie folgt aufgebaut. Abschnitt 2 befasst sich mit der (neuen) PSI-Richtlinie und beinhaltet auch die Machbarkeitsstudie. Der folgende Abschnitt 3 beschreibt mögliche Signaturverfahren für Metadaten. Abschnitt 4 gibt einen Überblick über eingesetzte Metadaten-Formate, ihre Signaturfähigkeit und gibt Empfehlungen welches Signaturformat sich für welches Metadatenformat eignet. Abschnitt 5 fasst die Ergebnisse zusammen. 1 Stichtag: Einleitung 4

5 2 PSI Richtlinie 2.1 Einleitung Die Public Sector Information (PSI) Richtlinie hat das Ziel der Erleichterung der Weiterverwendung von Daten, die sich im Besitz von öffentlichen Stellen befinden. Die unterschiedlichen nationalen Regelungen werden hierbei als ein Hindernis für die Schaffung eines europäischen Binnenmarktes gesehen. Aus diesem Grund versucht die PSI Richtlinie eine Angleichung der Bestimmungen und Verfahren der Mitgliedstaaten zur Nutzung von Informationen des öffentlichen Sektors [Euro13]. Insbesondere wird der rechtliche Rahmen sowohl für kommerzielle als auch nicht-kommerzielle Zwecke festgelegt. Die erste Fassung der Richtlinie wurde im Jahre 2003 veröffentlicht. Inzwischen wurde eine aktualisierte Version herausgegeben, die aktuelle Entwicklungen berücksichtigt. Abbildung 2.1 veranschaulicht eine Zeittafel der verschiedenen Entwicklungen und Umsetzungen. Die erste Fassung der PSI-Richtlinie [Euro03] wurde im November 2003 veröffentlicht und musste bis Juli 2005 von den Mitgliedsstaaten umgesetzt werden. In Österreich wurde im November 2005 diese Umsetzung durch das Informationsweiterverwendungsgesetz IWG [IWG05] vollzogen. Seitens der Europäischen Kommission wurden die Umsetzungen in einzelnen Mitgliedsstaaten bis zum Juli 2008 geprüft. Im Juni 2013 wurde die novellierte Fassung der PSI-Richtlinie [Euro13] veröffentlicht, die einen deutlichen Schritt in Richtung OGD macht. Diese novellierte Richtlinie muss nun bis Juli 2015 von den Mitgliedsstaaten umgesetzt werden. Die Überprüfung der Umsetzung durch die Europäische Kommission erfolgt bis spätestens Juli Juli 2005 Deadline Umsetzung PSI-Richtlinie 01. Juli November 2003 Deadline Prüfung Umsetzung PSI-Richtlinie 2003/98/EC der PSI-Richtlinie 2003/98/EC 18. Juli 2015 Deadline Umsetzung PSI-Richtlinie 2013/37/EC 26. Juni Juli 2018 Novellierte Deadline Prüfung Umsetzung PSI-Richtlinie 2013/37/EC PSI-Richtlinie 2013/37/EC Open Government Data 19. November 2005 Veröffentlichung IWG Abbildung 2.1 Zeittafel PSI-Richtlinien, IWG und OGD. Die folgenden Unterabschnitte befassen sich detaillierter mit der novellierten Fassung der PSI-Richtlinie und beinhalten eine Machbarkeitsstudie hinsichtlich der Anwendung PSI Richtlinie 5

6 des Konzepts für Vertrauenswürdiges Open Government Data (siehe Vorjahresprojekt OpenData und elektronische Dokumente [Stra12]) auf die Anwendungsfälle der novellierten PSI-Richtlinie. 2.2 PSI-Richtlinie (2013) Die PSI-Richtlinie aus dem Jahre 2003 betrachtete die Wiederverwendung von Informationen des öffentlichen Sektors auf sehr traditionelle Art und Weise. Mit der neuen Fassung wurden die folgenden zwei Hauptänderungen vorgenommen: Die neue Fassung orientiert sich nun stark an der OGD Bewegung und nimmt einen Großteil der OGD-Prinzipien in die Richtlinie auf. Der Geltungsbereich der Richtlinie wurde erweitert. Von nun an fallen auch kulturelle Institutionen wie Museen, Archive und Bibliotheken unter die Richtlinie. Der Hauptzweck der Richtlinie ist es einen Mindestbestand an Regeln für die Weiterverwendung[ ] zu schaffen und die praktischen Mittel zur Erleichterung der Weiterverwendung vorhandener Dokumente, die im Besitz öffentlicher Stellen der Mitgliedstaaten sind [Euro13] bereitzustellen. Damit soll die Entwicklung hin zu einer Informations- und Wissensgesellschaft [Euro13] geschaffen werden. Der Begriff Weiterverwendung wird dabei in der Richtlinie genau definiert und ist die Nutzung von Dokumenten, die im Besitz öffentlicher Stellen sind, durch natürliche oder juristische Personen für kommerzielle oder nichtkommerzielle Zwecke, die sich von dem ursprünglichen Zweck im Rahmen des öffentlichen Auftrags, für den die Dokumente erstellt wurden, unterscheiden. [Euro13]. Die Richtlinie definiert weiters Anforderungen an die Bearbeitung von Anträgen auf Weiterverwendung, wobei Fristen einzuhalten sind und allfällige Ablehnungen zu begründen und mit Rechtsbehelfen zu versehen sind. Weiters werden Bedingungen für die Weiterverwendung definiert. So sollen soweit wie möglich und sinnvoll die Daten in offenen und maschinenlesbaren Formaten inkl. Metadaten zur Verfügung gestellt werden. Die Gebührenbemessung und Transparenz sind ebenfalls wichtige Bestandteile der Richtlinie. So können Gebühren prinzipiell eingehoben werden. Diese sind allerdings beschränkt und müssen transparent, nachvollziehbar und im vornhinein bekannt sein. Zusätzlich enthält die Richtlinie auch Bestimmungen zu Lizenzen. Von Seiten der öffentlichen Stelle kann die Weiterverwendung der Daten ohne Lizenz gestattet werden oder es werden bestimmte Bedingungen festgelegt. Abschließend befasst sich die Richtlinie noch mit praktischen Vorkehrungen sowie Nichtdiskriminierung und lauterer Handel. PSI Richtlinie 6

7 Bestimmungen zu Vertrauenswürdigkeit, Authentizität oder Integrität der Daten finden sich mit Ausnahme der Bestimmungen zu personenbezogenen Daten nicht in der Richtlinie. Folgende Tabelle 1 stellt die allgemeinen OGD Prinzipien der PSI-Richtlinie gegenüber. Sie zeigt inwiefern sich zu den OGD Prinzipien eine Entsprechung in der PSI Richtlinie finden lässt. Tabelle 1 OGD Prinzipien und ihr Entsprechung in der PSI-Richtlinie (2013). OGD Prinzip laut [OGDAT] Vollständigkeit: Die veröffentlichten Datensätze soll so vollständig wie möglich, sie bilden den ganzen Umfang dessen ab, was zu einem bestimmten Thema dokumentiert ist. Weiters sollen Metadaten mitgeliefert werden, die die Rohdaten beschreiben und erklären. Vor der Veröffentlichung müssen noch Datenschutz-, Sicherheitsoder Zugangsbeschränkungen geprüft werden. Insbesondere personenbezogene Daten sind von einer Veröffentlichung ausgenommen. Primärquelle: "Die Daten werden von der Verwaltung an ihrem Ursprung gesammelt und veröffentlicht. Dies geschieht mit dem höchstmöglichen Feinheitsgrad, nicht in aggregierten oder sonst wie modifizierten Formaten". Zeitnahe Zurverfügungstellung: Die Daten sollen innerhalb eines angemessenen Zeitraums zur Verfügung gestellt werden. Insbesondere für dynamische Inhalte ist das von großer Bedeutung. Entsprechung in PSI-Richtlinie [Euro13] Eine explizite Erwähnung der Vollständigkeit der Daten findet sich in der PSI-Richtlinie nicht. Informationen, die personenbezogene Daten beinhalten, sind von einer Weiterverwendung aber ebenso ausgeschlossen (Artikel 1 Absatz 2 cc). Der Begriff Weiterverwendung ist in Artikel 2 definiert. Er besagt, dass Weiterverwendung die Nutzung von Dokumenten, die im Besitz öffentlicher Stellen sind, durch natürliche oder juristische Personen für kommerzielle oder nichtkommerzielle Zwecke, die sich von dem ursprünglichen Zweck im Rahmen des öffentlichen Auftrags, für den die Dokumente erstellt wurden, unterscheiden.. In diesem Sinne kann die öffentliche Stelle als Primärquelle angesehen werden. Formell definiert die Richtlinie keine Bedingungen für eine zeitnahe Zurverfügungstellung. In der Einleitung der Richtlinie wird als Grund 12 aber angeführt: [ ]Sobald ein Antrag auf Weiterverwendung bewilligt wurde, sollten die öffentlichen Stellen die Dokumente innerhalb einer Zeitspanne zur Verfügung stellen, die es ermöglicht, deren volles PSI Richtlinie 7

8 wirtschaftliches Potenzial zu nutzen. [ ]. Leichter Zugang: Die Daten sollen möglichst einfach und barrierefrei zugänglich sein. Physische und technische Hürden sollen vermieden werden. Maschinenlesbar: Um Daten automatisiert verarbeiten zu können sollen diese in einem maschinenlesbaren Format zur Verfügung gestellt werden. Diskriminierungsfreiheit: "Jede Person kann zu jeder Zeit auf die Daten zugreifen, ohne sich identifizieren oder eine Rechtfertigung für ihr Handeln abgeben zu müssen". Verwendung offener Standards: Für die Veröffentlichung der Daten sollen offene Standards verwendet werden. Lizensierung: Die Projektgruppe Cooperation Open Government Data Österreich empfiehlt eine Lizenzierung unter Creative Commons Namensnennung 3.0 Österreich 2. Urheber-, patent- und markenrechtliche Fragen müssen zuvor abgeklärt werden. Dokumentation (Dauerhaftigkeit): Die veröffentlichten Daten sind umfassend mit Metadaten dokumentiert In Artikel 9 werden praktische Vorkehrungen definiert: Die Mitgliedstaaten treffen praktische Vorkehrungen, die eine Suche nach den zur Weiterverwendung verfügbaren Dokumenten erleichtern [ ]. Bezüglich Maschinenlesbarkeit besagt Artikel 5 Absatz (1): Öffentliche Stellen stellen ihre Dokumente in allen vorhandenen Formaten oder Sprachen und, soweit möglich und sinnvoll, in offenem und maschinenlesbarem Format [ ] zur Verfügung. Artikel 10 Absatz (1) besagt: Die Bedingungen für die Weiterverwendung von Dokumenten sind für vergleichbare Kategorien der Weiterverwendung nichtdiskriminierend.. Weiters definiert Artikel 11 ein Verbot von Ausschließlichkeitsvereinbarungen, d.h. die Weiterverwendung von Informationen steht allen Marktteilnehmerinnen und Marktteilnehmern offen. Laut Artikel 5 Absatz (1) sollen Informationen als auch die Metadaten [ ]so weit wie möglich formellen, offenen Standards entsprechen. In Artikel 8 werden lizenzrechtliche Aspekte betrachtet. So können veröffentlichende Stellen die Weiterverwendung ohne Lizenz gestatten oder mittels einer Lizenz entsprechende Bedingungen formulieren. In Artikel 5 Absatz (1) wird festgelegt, dass die veröffentlichten Informationen [ ]mit 2 PSI Richtlinie 8

9 und über lange Zeit hinweg zu finden. den zugehörigen Metadaten zur Verfügung gestellt werden sollen. Nutzungskosten: Nutzungskosten werden seitens der OGD Bewegung als ein Hindernis angesehen. Die Creative Commons Namensnennung 3.0 Österreich Lizenz sieht derzeit auch keine Nutzungskosten vor. 2.3 Machbarkeitsstudie Im Gegensatz zu OGD definiert die PSI Richtlinie in Artikel 6 Grundsätze zur Gebührenbemessung. So legt Absatz (1) fest: Werden Gebühren für die Weiterverwendung von Dokumenten erhoben, so sind diese Gebühren auf die durch die Reproduktion, Bereitstellung und Weiterverbreitung verursachten Grenzkosten beschränkt.. Es können also Gebühren eingehoben werden, jedoch ist die Höhe der Gebühren begrenzt. Auch müssen die Gebühren transparent sein, d.h. im Voraus bekannt sein. Dieser Abschnitt umfasst eine Machbarkeitsstudie inwiefern auf die Anwendungsfälle der PSI-Richtlinie das Konzept für ein vertrauenswürdiges Open Government Data angewendet werden kann. Dieses Konzept wurde im Projekt OpenData und elektronische Dokumente [Stra12] vorgestellt. Prinzipiell werden dabei zur Sicherstellung der Authentizität und Integrität der veröffentlichten Daten elektronische Signatur angewandt. Hierbei werden die Daten vor der Veröffentlichung von der bereitstellenden Stelle signiert und beziehende Stelle kann die Signatur der Daten prüfen. Bei einer positiven Signaturprüfung sind die Daten authentisch und integritätsgesichert. Aus dem vorhergehenden Abschnitt geht hervor, dass sich die PSI-Richtlinie stark an die OGD Bewegung herangenähert hat. Die einzige Unterscheidung kann hinsichtlich der Nutzungskosten getroffen werden. Die OGD Bewegung sieht Nutzungskosten als klaren Nachteil, wohingegen die PSI-Richtlinie die Einnahme von Nutzungskosten grundsätzlich erlaubt (auch wenn eine Kostenbeschränkung definiert ist). Dieser Unterschied hat jedoch keinen technischen Einfluss bezüglich der Anwendbarkeit auf das Konzept des vertrauenswürdigen Open Government Data. Abbildung 2.2 zeigt das leicht abgewandelte Konzept für eine vertrauenswürdige Datenweiterverwendung laut PSI-Richtlinie und zeigt die vertrauenswürdige Datenweiterverwendung. Hierbei befinden sich die originalen Daten in der Domäne der öffentlichen Stellen, d.h. der Daten Bereitstellerin bzw. des Daten Bereitstellers. Diese werden dann von der öffentlichen Behörde mit deren privatem Schlüssel signiert. Je nach Datenformat ist hier ein entsprechendes Signaturformat zu wählen siehe auch Projektdokumentation Analyse Signaturverfahren für OGD [Stra13]. Des Weiteren können auch die dazugehörigen Metadaten signiert werden (siehe Abschnitt PSI Richtlinie 9

10 4). Diese signierten Daten werden danach bereitgestellt und die Weiterverwenderin bzw. der Weiterverwender kann diese Daten beziehen. Die Signatur der Daten kann schließlich überprüft werden. Bei einer positiven Prüfung kann die Weiterverwenderin bzw. der Weiterverwender davon ausgehen, dass die Daten vertrauenswürdig sind, d.h. die Daten wurden nicht verändert und sie sind von der angegebenen öffentlichen Stelle ausgegeben. Auch aus Sicht der öffentlichen Stelle gibt es einen wesentlichen Vorteil. Die Weiterverwenderin bzw. der Weiterverwender kann nicht behaupten falsche bzw. nicht von der öffentlichen Stelle gewollte Daten erhalten zu haben. Beliebige (nicht vertrauenswürdige) Domäne SIGNATUR PRÜFUNG Domäne Daten Bereitsteller/in Domäne Daten Weiterverwender/in Lorem ipsum Lorem dolor ipsum sit amet, Lorem dolor ipsum consetetur sit amet, dolor sadipscing consetetur sit amet, elitr, sadipscing consetetur sed diam elitr, sadipscing nonumy sed diam elitr, eirmod nonumy sed diam tempor eirmod invidunt nonumy tempor eirmod invidunt tempor invidunt SIGNATUR ERSTELLUNG Lorem ipsum Lorem dolor ipsum sit amet, Lorem dolor ipsum consetetur sit amet, dolor sadipscing consetetur sit amet, elitr, sadipscing consetetur sed diam elitr, sadipscing nonumy sed diam elitr, eirmod nonumy sed diam tempor eirmod invidunt nonumy tempor eirmod invidunt tempor invidunt Original Datenquelle Vertrauenswürdige Daten Abbildung 2.2 Vertrauenswürdige Datenweiterverwendung laut PSI-Richtlinie. PSI Richtlinie 10

11 3 Signaturformate Anmerkung: Um dieses Dokument in sich abgeschlossen zu halten, wurde dieser Abschnitt dem Abschnitt 2 aus der Dokumentation des Projekts Analyse Signaturverfahren für OGD [Stra13] entnommen. 3.1 Einleitung Die rechtliche und organisatorische Basis für elektronische Signaturen im E-Government Kontext ist durch die EU Signaturrichtlinie [Euro00] und ihre nationale Umsetzung im österreichischen Signaturgesetz [SigG10] gegeben. Das Signaturgesetz legt dabei unterschiedliche Ausprägungen von Signaturen mit unterschiedlichen Rechtswirkungen fest. So ist eine fortgeschrittene elektronische Signatur, die mit einer sicheren Signaturerststellungseinheit erstellt wurde und auf einem qualifizierten Zertifikate beruht, der handschriftlichen Unterschrift, bis auf wenige Ausnahmen, gleichgestellt. Durch die große Anzahl an unterschiedlichen Signaturformaten sowohl standardisierte als auch proprietäre entstanden Interoperabilitätsprobleme, speziell im grenzüberschreitenden Kontext. Um hier zu einer Harmonisierung beizutragen und folglich die Interoperabilität zu steigern, wurde von der Europäischen Kommission Referenzformate für fortgeschrittene elektronische Signaturen definiert. Diese Referenzformate sind in der EU Kommissionsentscheidung 2011/130/EU [Euro11] festgelegt. Für die Analyse der Signaturformate sind daher auch nur diese Referenzformate von besonderem Interesse. Die Referenzformate sind: 1. CAdES-BES/EPES Signaturen 2. XAdES-BES/EPES Signaturen 3. PAdES-BES/EPES (Teil 3) Signaturen In den folgenden Abschnitten werden diese drei Formate detaillierter betrachtet und untersucht. Signaturformate 11

12 3.2 CAdES Signaturen Einleitung CAdES steht für CMS Advanced Electronic Signature und ist ein ETSI-Standard, der auf CMS (Cryptographic Message Syntax) basiert und als ETSI TS [CAdES] 3 veröffentlicht ist. Ziel dieses Standards war es CMS dahingehende zu erweitern, um den Anforderungen für fortgeschrittene elektronischen Signaturen aus der EU Signaturrichtlinie gerecht zu werden. Das Basisformat CMS basiert dabei auf PKCS#7 und ist im RFC 5652 [RFC5652] spezifiziert. CMS erlaubt sowohl das Verschlüsseln als auch das Signieren von Daten. Die CMS Spezifikation sieht vor, dass sämtliche Daten in so genannten ContentInfo-Containern abgelegt werden. Die Daten selbst werden dabei ASN.1 4 codiert. Diese Container können ineinander verschachtelt werden und enthalten einen Containertyp, wobei folgende Typen unterstützt werden: Data: Dieser Typ bezeichnet beliebige Daten SignedData: Bezeichnet signierte Daten (siehe Abschnitt 3.2.2) EnvelopedData und EncryptedData: Mit diesem Typ werden verschlüsselte Daten gekennzeichnet. DigestData: Damit wird gekennzeichnet, wenn Daten um einen zusätzlichen Hashwert zur Integritätssicherung, erweitert werden. AuthenticatedData: Damit sind Daten gekennzeichnet, die mit einem MAC 5 gesichert sind. In anderen RFCs sind auch weitere Containertypen definiert, wie beispielsweise der Typ SignedAndEnvelopedData [RFC2315]. Das ermöglicht es Daten zuerst zu signieren und anschließend zu verschlüsseln 6. Für CAdES wurden nun, basierend auf CMS, Erweiterungen spezifiziert, die es ermöglichen fortgeschrittene elektronische Signaturen abzubilden. Die CAdES- Spezifikation [CAdES]definiert dabei mehrere Formate, die in der folgenden Tabelle 2 angeführt sind. 3 Es gibt hierbei mehrere Versionen diese Standards. Wir verweisen an dieser Stelle auf jene Version, die in der EU Kommissionsentscheidung 2011/130/EU zu den Referenzformaten festgelegt ist. 4 Abstract Syntax Notation 1. Ist eine Beschreibungssprache zur Definition, Strukturierung und Repräsentation von Daten. 5 Message Authentication Code. 6 Eine fast idente Möglichkeit bietet hier die CMS Spezifikation selbst, indem man einen SignedData-Container in einen EnvelopedData-Container aufnimmt. Signaturformate 12

13 Tabelle 2 CAdES Signaturformate. Format Beschreibung CAdES-BES (Basic Electronic Signature) Ist stark äquivalent zu CMS, mit dem Unterschied, dass das Signaturzertifikat zusätzlich durch die Signatur geschützt ist. CAdES-EPES (Explicit Policy-based Electronic Signature) Erweitert CMS bzw. CAdES-BES dahingehend, dass eine explizite Signatur-Richtlinie angegeben werden kann. Die Richtlinie ist mitsigniert ist und muss bei der Signaturprüfung angewendet werden. CAdES-T (Electronic signature with Time) Ist eine BES oder EPES Signatur plus einen Signaturzeitpunkt von einem vertrauenswürdigen Zeitstempeldienst. CAdES-C (Electronic Signature with Complete validation data references) Hierbei werden zusätzlich Referenzen auf alle verwendeten Zertifikate der Zertifikatskette angeführt. CAdES-X (EXtended Long format) Long Zusätzlich zu CAdES-C werden hier die konkreten Werte der Zertifikate und die konkreten Werte der Revozierungs-Informationen hinzugefügt. CAdES-A (Archival Form) Erweitert CAdES-X Long um einen oder mehrere Archiv-Zeitstempel um zukünftigen Schwächen der kryptographischen Verfahren vorzubeugen. Im folgenden Abschnitt wird der Containertyp für signierte Daten als auch die CAdES- Erweiterungen für das BES bzw. EPES Format beschrieben Struktur Dieser Abschnitt befasst sich detaillierter mit dem Containertyp SignedData. Abbildung 3.1 zeigt dabei den Aufbau bzw. die Struktur dieses Typs, der aus folgenden Elementen besteht: Signaturformate 13

14 Version: Repräsentiert die Versionsnummer der Spezifikation bzw. dieses Containertyps. DigestAlgorithms: Gibt eine Sammlung der Hashalgorithmen an, die innerhalb von signerinfos verwendet werden. EncapsulatedContentInfo: Repräsentiert die signierten Daten und gibt neben den signierten Daten (Container: econtent) auch den Typ der Daten (Container: econtenttype) an. Sind die signierten Daten in diesem Container enthalten, dann handelt es sich um eine enveloping Signatur. Ist der Container econtent leer, so handelt es sich um eine detached Signatur und die Daten befinden sich extern. Certificates: Beinhaltet (optional) Zertifikate, die zur Signaturprüfung herangezogen werden. Crls: Beinhaltet (optional) Informationen über den (Widerrufs-)status von Zertifikaten. SignerInfos: Repräsentiert die eigentliche Signatur und hat den Containertyp SignerInfo. Abbildung 3.1 zeigt ebenso diesen SignerInfo Typ, der aus folgenden Elementen aufgebaut ist: Version: Repräsentiert die Versionsnummer der Spezifikation bzw. dieses Containertyps. SignerIdentifier: Spezifiert das Signaturzertifikat bzw. den öffentlichen Schlüssel. DigestAlgorithm: Gibt den Hashalgorithmus an, der zur Erzeugung des Hashwertes verwendet wurde. SignedAttributes: Sind zusätzlich signierte Attribute, die in die Signatur miteinbezogen sind. Innerhalb dieser signierten Attribute sind jene Werte vorhanden, die für eine CAdES-BES 7 bzw. CAdES-EPES 8 Signatur notwendig sind. SignatureAlgoritm: Spezifiziert den verwendeten Signaturalgorithmus. Signature: Repräsentiert den Signaturwert. UnsignedAttributes: Sind zusätzliche Attribute, die jedoch nicht in die Signatur miteingebunden sind. 7 Zum Beispiel: Attribut signingtime, das den Signaturzeitpunkt angibt. 8 Zum Beispiel: Attribut: id-aa-ets-sigpolicyid, dass die Signatur-Richtlinie spezifiziert. Signaturformate 14

15 3.2.3 Eignung Mittels CAdES-Signaturen können prinzipiell beliebige Daten signiert werden, da die zu signierenden Daten als binäre Strings behandelt werden und das Format der Daten keinen Einfluss hat. SignedData version digestalgorithms... encapsulatedcontentinfo certificates... SignerInfo version signeridentifier digestalgorithm signedattributes... crls... signaturealgorithm signature signerinfos... unsignedattributes... Abbildung 3.1 SignedData Containertyp. 3.3 XAdES Signaturen Einleitung Analog zu CAdES wurde der Standard XAdES ins Leben gerufen um basierend auf XML-Signaturen (XMLDSIG) fortgeschrittene elektronische XML-basierte Signaturen zu ermöglichen. XAdES steht hierbei für XML Advanced Electronic Signature und ist, ebenso wie CAdES, ein ETSI Standard, veröffentlich unter ETSI TS [XAdES] 9. Analog zu CAdES wurden in XAdES ebenso mehrere Formate definiert. Deren Bedeutung folgt dabei jenen, die in Tabelle 2 angegeben sind. Für unsere Anwendungsfälle sind wiederum nur die Referenzformate XAdES-BES bzw. XAdES-EPES von Bedeutung. 9 Es gibt hierbei mehrere Versionen diese Standards. Wir verweisen an dieser Stelle auf jene Version, die in der EU Kommissionsentscheidung 2011/130/EU zu den Referenzformaten festgelegt ist. Signaturformate 15

16 Der folgende Abschnitt beschreibt detaillierter den Aufbau und die Struktur von XMLDSIG bzw. XAdES Struktur XMLDSIG ist ein Standard für XML-basierte Signaturen und ist als de-facto Standard als W3C-Empfehlung spezifiziert [XMLDSIG]. Abbildung 3.2 veranschaulicht die prinzipielle Struktur einer XMLDSIG Signatur. Sie besteht aus folgenden Elementen: SignedInfo: Dieses Element kapselt sämtliche Informationen zur Signatur und ist jenes Element über das die Signatur berechnet wird. o CanonicalizationMethod: Definiert einen Kanonisierungsalgorithmus, der dazu dient eine Datennormalisierung 10 über das SignedInfo-Element durchzuführen. o SignatureMethod: Definiert den Signaturalgorithmus mit dem die Daten signiert sind o Reference: Es können ein oder mehrere Referenzen auf signierte Daten angegeben werden. Die Angabe erfolgt dabei über das Attribut URI. Es können hierbei, wie bei CAdES, enveloping und detached Signaturen erzeugt werden. Zusätzlich werden auch enveloped 11 Signaturen unterstützt. Abgesehen von dem Attribute URI können bzw. müssen noch folgende Elemente angegeben werden: Transforms: Optional können Transformationen angegeben werden. Diese werden vor der Hashberechnung auf die in der URI angegebenen Daten angewendet. Das Endresultat dieser Transformationen ist dann der Input für die Hashberechnung. DigestMethod: Spezifiziert den Hashalgorithmus. DigestValue: Repräsentiert den berechneten Hashwert. SignatureValue: Repräsentiert den Signaturwert über das SignedInfo-Element (inklusive der Hashwerte der Referenzen). KeyInfo: Ist ein optionales Element und beinhaltet üblicherweise das Signatorzertifikat. Object: In diesem Element befinden sich Datenobjekte, die normalerweise über einen Referenz in SignedInfo referenziert sind. 10 Diese Kanonisierung eliminiert beispielsweise Whitespaces aus dem SignedInfo-Element, die bei einer Signaturprüfung ansonsten zu Problemen führen können. 11 Hierbei umschließen die signierten Daten die Signatur, d.h. die Signatur ist in den Daten eingebettet. Signaturformate 16

17 Abbildung 3.2 XMLDSIG Struktur. Die, auf dieser Struktur aufbauenden, XAdES Erweiterungen werden durch eine zusätzliche Referenz umgesetzt. Diese zusätzliche Referenz verweist auf ein (weiteres) Objekt, dass die so genannten XAdES-Eigenschaften beinhaltet. Diese Eigenschaften definieren zusätzliche Werte zur Signatur, wie sie u.a. für die Erfüllung der Anforderungen an fortgeschrittene elektronische Signaturen benötigt werden. Abbildung 3.3 zeigt die Struktur einer XAdES-BES/EPES Signatur, wobei das angegeben Objekt diese XAdES-Eigenschaften repräsentiert. Diese XAdES-Properties bestehen aus folgenden signierten Eigenschaften 12 : Signing Time: Beinhaltet den Zeitpunkt der Signaturerstellung im UTC-Format. SingingCertificate: Dieses Element enthält eine eindeutige Referenz auf das Signatorzertifikat. SignaturePolicyIdentifier: Optional, für eine XAdES-EPES Signatur, kann eine Signatur-Richtlinie angegeben werden. DataObjectFormat: In diesem Element wird der MIME-Type der signierten Daten mitgeliefert Eignung XAdES-Signaturen eignen sich offensichtlich speziell für XML-basierte bzw. text-basierte Daten. Andere Daten lassen sich prinzipiell auch über eine Base64-Codierung signieren. Dies hat jedoch eindeutige Performance-Nachteile. 12 Es werden hier nur Eigenschaften angeführt, die laut EU Kommissionsentscheidung 2011/130/EU [Euro11] benötigt werden. Signaturformate 17

18 Abbildung 3.3 XAdES-BES/EPES Struktur. 3.4 PAdES Signaturen Einleitung PAdES steht für PDF Advanced Electronic Signatures und ist ebenso ein ETSI-Standard, der als ETSI TS [PAdES] 13 veröffentlicht ist. Der Standard setzt dabei auf dem PDF- Standard [PDF] auf und umfasst Einschränkungen und Erweiterungen um den Anforderungen für fortgeschrittene elektronische Signaturen zu genügen. Dafür wurden in PAdES Teil 3 Profile für PAdES-BES und PAdES-EPES Signaturen spezifiziert. Für Langzeitanwendungen sind entsprechende Profile in PAdES Teil 4 standardisiert. Der folgende Abschnitt befasst sich detaillierter mit der Struktur von PDF-Signaturen und darauf aufbauend mit PAdES-Signaturen Struktur Der PDF-Standard [PDF] legt fest inwiefern Signaturen in PDF-Dokumente eingebettet werden können. Durch diese Einbettung sind nur enveloped Signaturen möglich, 13 Es gibt hierbei mehrere Versionen diese Standards. Wir verweisen an dieser Stelle auf jene Version, die in der EU Kommissionsentscheidung 2011/130/EU zu den Referenzformaten festgelegt ist. Signaturformate 18

19 enveloping oder detached Signaturen werden nicht unterstützt. Die Signatur selbst basiert dabei auf CMS und wird mittels eines so genannten Signature Directory in das PDF Dokument eingebettet (siehe hierzu auch Abbildung 3.4). Das Signature Directory besteht dabei aus zwei Einträgen. Der erste Eintrag ist eine ByteRange und der zweite enthält die eigentliche Signatur. Die ByteRange gibt dabei an welche Bytes in einem PDF Dokument signiert sind. Da die Signatur selbst im PDF Dokument enthalten ist, muss diese ausgenommen werden. D.h. im abgebildeten Beispiel sind die Bytes 520 bis 870 von der Signatur ausgenommen und werden für die Signaturberechnung auf Null gesetzt. Diese Nullwerte werden nach dem Signaturvorgang mit den Signaturdaten aufgefüllt. PDF Dokument Byte 0 PDF Inhalt =Signatur (nicht mitsigniert) Signature Directory ByteRange Contents: CMS/CAdES Signatur %EOF 1100 Abbildung 3.4 PDF-Signatur. PAdES-Signaturen bedienen sich hierbei desselben Mechanismus des Einbettens der Signatur über das Signature Directory. Im Gegensatz zu herkömmlichen PDF-Signaturen wird jedoch anstatt einer CMS-Signatur eine CAdES-Signatur eingebettet. Um nun eine PAdES-BES bzw. PAdES-EPES Signatur zu erstellen muss einen entsprechende CAdES-BES bzw. CAdES-EPES Signatur erstellt werden. Signaturformate 19

20 3.4.3 Eignung PAdES-Signaturen eignen sich prinzipiell nur für PDF-Dateien. Mittels XFA 14 (XML Forms Architecture) würden sich prinzipiell auch XML-Daten signieren lassen, hat jedoch in der Praxis keine Relevanz. 14 Hiermit lassen sich XML-kodierte Daten in PDF-Dokumenten übertragen. Signaturformate 20

21 4 Metadaten Format Metadaten sind ein wichtiger Bestandteil von vielen Anwendungen, die Daten verarbeiten. Metadaten sind sozusagen Daten über diese Daten und beinhalten üblicherweise eine Beschreibung der eigentlichen Nutzdaten um eine fehlerfreie Verarbeitung und Interpretation der Nutzdaten zu ermöglichen. Sowohl im Bereich von Open Government Data als auch der PSI-Richtlinie stellen Metadaten eine entscheidende Rolle dar. Sie erlauben es den Benutzerinnen und Benutzern von OGD oder PSI die eigentlichen Daten in den richtigen Kontext zu bringen. Analog zur Frage der Vertrauenswürdigkeit der Nutzdaten, stellen sich auch bei Metadaten die Fragen der Authentizität und Integrität. So führen falsche Metadaten, zu einer falschen Interpretation der Nutzdaten und somit auch zu falschen Ergebnissen. Daher ist es für bestimmte Anwendungen auch sinnvoll die Metadaten authentisch und integritätsgesichert zur Verfügung zu stellen. Auch hier sind elektronische Signaturen das Mittel der Wahl um die Vertrauenswürdigkeit der Metadaten sicherzustellen. Aus diesem Grund befassen sich die folgenden Unterabschnitte mit der Signaturfähigkeit von Metadaten-Formaten. Die Selektion der Metadaten-Formate basiert dabei auf einem konkreten Österreich-Bezug oder durch eine weite Verbreitung im internationalen Umfeld. 4.1 CKAN-Metadaten Einleitung CKAN steht für Comprehensive Knowledge Archive Network 15 und ist ein Open-Source Datenmanagement-System für das Speichern und Verteilen von Daten. Bereitgestellt wird es von der Open Knowledge Foundation (OKFN) 16. Hierbei definiert CKAN auch eine Metadatenstruktur, die als Ausgangsbasis für viele Open Data Anwendungen dient. So hat sich CKAN in den letzten Jahren als de-facto Standard für Open Data Kataloge herauskristallisiert Struktur Das CKAN Metadatenmodell bietet eine Reihe von unterschiedlichen Metadaten an. Der Austausch bzw. der Export von Metadaten erfolgt dabei über das JSON-Format. JSON steht für JavaScript Object Notation und ist ein kompaktes, textbasiertes Metadaten Format 21

22 Datenformat. Es dient dem Datenaustausch und ist dabei sowohl maschinen- als auch menschenlesbar (siehe auch Listing 4.1). {"printrequests": [{"label":"bezeichnung","typeid":"_wpg","mode":2}, {"label":"bezeichnung#","typeid":"_wpg","mode":2}, {"label":"quelle","typeid":"_txt","mode":1}, {"label":"version","typeid":"_txt","mode":1}...],"results": {"Attribut:Eindeutiger Identifikator":... } } Listing 4.1 JSON-Beispiel Signaturmöglichkeiten JSON bietet mit JSON Web Signature (JWS) eine Möglichkeit der Signatur an, unterstützt aber keine fortgeschrittenen Signaturen. Durch das textbasierte Format, kommen sowohl CAdES als auch XAdES Signaturen in Frage. Welcher Signaturvariante der Vorzug gegeben wird hängt dabei vom konkreten Anwendungsfall ab. 4.2 OGD Metadaten Österreich Einleitung OGD Metadaten Österreich (OGD-AT) wurden von der Cooperation OGD Österreich spezifiziert. Die aktuelle Version 2.1 ist unter [OGDMD] veröffentlicht. Dabei sieht die Spezifikation einen Metadatenkern aus 9 Pflichtfeldern und 20 zusätzlich empfohlenen optionalen Metadatenfeldern vor. OGD-AT ist dabei ein Profil von DCAT-AP Struktur DCAT ist ein RDF Vokabular um die Interoperabilität zwischen Datenkatalogen zu vereinfachen. Es definiert dabei ein Schema um Datensätze in Datenkatalogen zu beschreiben. Mit DCAT-AP steht ein Applikationsprofil für Datenportale in Europa zur Verfügung. Dieses Profil wird dazu genutzt um Daten den öffentlichen Sektor zu beschreiben. Im einfachsten Anwendungsfall dient es dazu Suchanfrage über mehrere und grenzüberschreitende Portale zu ermöglichen. Möglich wird das durch den Austausch von Datensatz-Beschreibungen über die involvierten Datenportale. OGD-AT ist wiederum ein Profil von DCAT-AT und repräsentiert eine Metadatenstruktur für OGD 17 DCAT-AP steht für Data Catalog Vocabulary Application profile for data portals in Europe und kann unter bezogen werden. Metadaten Format 22

23 in Österreich. Abbildung 4.1 zeigt diese Metadatenstruktur, aufgeteilt auf den verpflichtenden Metadatenkern und den optionalen Metadatenfeldern. Abbildung 4.1 Metadatenstruktur OGD-AT. Metadaten Format 23

24 4.2.3 Signaturmöglichkeiten Die Grundbasis für OGD-AT ist ein RDF-Vokabular. So ein RDF Vokabular kann dabei grundsätzlich über zwei Formate serialisiert werden. Einerseits als XML Format und andererseits als Notation 3 Format. Notation 3 18 ist dabei eine kompakte und textbasierte Serialisierung von RDF. Offensichtlich eignen sich für die XML-Serialisierung XAdES-Signaturen perfekt. Prinzipiell kann die XML-Serialisierung auch mit CAdES signiert werden. Dies erscheint aber wenig sinnvoll und praktikabel. Für das textbasierte Notation 3 Format sind sowohl CAdES als auch XAdES-Signaturen möglich. 4.3 OGD Metadaten Deutschland Einleitung Die Metadatenstruktur Deutschland wurde von Frauenhofer Fokus spezifiziert und via Github 19 veröffentlicht. Ähnlich wie Österreich besteht die Struktur aus 15 Pflichtfeldern und 35 optionalen Feldern. Die Metadatenstruktur baut dabei auf CKAN und JSON auf Struktur Abbildung 4.2 zeigt einen Ausschnitt der Metadatenstruktur Deutschland. Diese Struktur ähnelt sehr der österreichischen Metadatenstruktur. Eine Gegenüberstellung der Metadatenstrukturen von Österreich und Deutschland ist unter [HoHa13] verfügbar Metadaten Format 24

25 Abbildung 4.2 Ausschnitt Metadatenstruktur Deutschland Signaturmöglichkeiten Die deutsche Metadatenstruktur basiert auf CKAN und JSON. Dadurch treffen dieselben Implikation wie im Abschnitt zu. D.h. durch das textbasierte Format, kommen sowohl CAdES als auch XAdES Signaturen in Frage. Welcher Signaturvariante der Vorzug gegeben wird hängt dabei vom konkreten Anwendungsfall ab. 20 Verfügbar über Metadaten Format 25

26 4.4 Dublin Core Metadaten Einleitung Dublin Core Metadaten sind eine Menge von Definitionen zur Beschreibung von Ressourcen 21 (Dokumente, Bilder oder anderen Objekten). Spezifiziert wurden diese Metadaten von der Dublin Core Metadata Initiative (DCMI) 22. Dublin Core Metadaten werden in vielen unterschiedlichen Anwendungsfällen eingesetzt, die entsprechende Metadaten benötigen Struktur Dublin Core Metadaten bestehen aus 15 Kernelementen und weiteren Feldern, womit weitere Details, Kategorisierungen und detailliertere Beschreibungen angegeben werden können. Die Metadaten können dabei auf Basis RDF/XML angegeben werden oder direkt in HTML-Dokumente eingebettet werden. Ein Beispiel so einer HTML- Einbettung zeigt Listing 4.2. <head profile=" <title>dublin Core Einbettung</title> <link rel="schema.dc" href=" /> <link rel="schema.dcterms" href=" /> <meta name="dc.format" scheme="dcterms.imt" content="text/html" /> <meta name="dc.subject" content="beispiel HTML" /> <meta name="dc.creator" content="max Mustermann" /> <meta name="dcterms.modified" scheme="dcterms.w3cdtf" content=" " /> </head> Listing 4.2 Teil eines HTML-Dokuments mit Dublin Core Metadaten Einbettung Signaturmöglichkeiten Sowohl für die Variante RDF/XML und Einbettung in HTML eigenen sich XAdES- Signaturen für die Signatur von Dublin Core Metadaten am besten. 4.5 MoReq Metadaten Einleitung MoReq steht für Modular Requirements for Records Systems und ist ein Standard für elektronische Aktenführung. Von der Europäischen Kommission erstmals im Jahre 2001 veröffentlicht wurde die Spezifikation einmal im Jahre 2008 (MoReq2) und nochmals im Metadaten Format 26

27 Jahre 2011 (MoReq2010) aktualisiert 23. Hierbei wird auch ein umfangreiches Set an Metadaten zur Verfügung gestellt Struktur Die Metadatenstruktur von MoReq2010 ist über ein XML-Schema 24 vorgegeben. Daraus folgt, dass die Metadaten im XML Format gespeichert werden und auch in diesem Format zur Verfügung gestellt werden. Abbildung 4.3 zeigt hierbei einen kleinen Ausschnitt des XML Schemas der Metadatenstruktur. Abbildung 4.3 Ausschnitt Metadatenstruktur MoReq Verfügbar unter 49f06a3bb2089d7dbbc2465&Itemid=137&lang=en Metadaten Format 27

28 4.5.3 Signaturmöglichkeiten MoReq Metadaten liegen im Format XML vor. Daher eignen sich auch XAdES- Signaturen am besten für die Signatur dieser Metadaten. 4.6 Zusammenfassung In den vorhergehenden Unterabschnitten wurden die gängigsten Metadaten-Formate analysiert speziell hinsichtlich ihrer Signaturfähigkeit. Tabelle 3 fasst die Ergebnisse zusammen. Es konnte für jedes Metadaten-Format zumindest ein sinnvolles und praktikables Signaturformat gefunden werden. Wobei speziell XAdES und CAdES je nach Format die beste Wahl sind. PAdES-Signaturen sind in keinem Anwendungsfall für Metadaten Signaturen sinnvoll. Tabelle 3 Signaturfähigkeit. Format Kurzbeschreibung CAdES XAdES PAdES CKAN Metadaten des Open Source x Comprehensive Knowledge Archive Network. OGD Repräsentiert die österreichische x Metadaten Österreich Metadatenstruktur für OGD basierend auf RDF. OGD Metadaten Deutschland Dublin Core Metadaten MoReq Metadaten Repräsentiert ein Metadatenstruktur für OGD basierend auf CKAN und JSON. Metadaten Spezifikation zur Beschreibung von unterschiedlichen Ressourcen. Metadaten des elektronische Aktenführungsstandards MoReq2010. x x x x x 25 CAdES nur für textbasiertes Notation 3 Format. 26 XAdES sowohl für XML-Serialisierung als auch für Notation 3. Metadaten Format 28

29 5 Zusammenfassung In dem vorliegenden Dokument wurde die novellierte Fassung der PSI-Richtlinie evaluiert und eine Machbarkeitsstudie für vertrauenswürde Daten, die unter der PSI- Richtlinie zur Verfügung gestellt werden, erstellt. Die novellierte PSI-Richtlinie ist dabei ein klares Bekenntnis zu Open (Government) Data, wodurch das Konzept für vertrauenswürdiges OGD aus dem Projekt OpenData und elektronische Dokumente [Stra12] ohne substanzielle Änderung angewendet werden kann. Der zweite Aspekt dieses Dokuments befasste sich mit möglichen und passenden Signaturformaten für Metadaten-Formate. Dabei spielen Metadaten ein entscheidende Rolle zur Beschreibung zur Verfügung gestellter Daten und Dokument. Sicherheitsaspekte wie Authentizität und Integrität spielen auch hier eine wichtige Rolle. Der Fokus bei der Signaturfähigkeitsanalyse wurde dabei auf die Referenzformate CAdES, XAdES und PAdES der EU Kommissionsentscheidung 2011/130/EU gelegt. Für die gängigsten Metadaten-Formate wurde zumindest jeweils ein Referenz-Signaturformat gefunden, womit die Metadaten authentisch und integritätsgesichert veröffentlicht werden können. Zusammenfassung 29

30 Dokumentenhistorie Version Datum Autor(en) Anmerkung K.Stranacher Erstversion K.Stranacher Abschnitt 2 aktualisiert K.Stranacher Abschnitt 4 aktualisiert K.Stranacher Abschnitt 1 aktualisiert K.Stranacher Finalisierung Zusammenfassung 30

31 Referenzen [Euro00] [Euro03] [Euro06] [Euro10] [Euro11] [Euro13] [HoHa13] European Union (1999), Directive 1999/93/EC of the European Parliament and of the Council of 13 December 1999 on a Community framework for electronic signatures, Official Journal L 13, pp European Union (2003), Directive 2003/98/EC of the European Parliament and the Council of 17 November 2003 on the re-use of public sector information. Richtlinie 2006/123/EG des Europäischen Parlaments und des Rates vom 12. Dezember 2006 über Dienstleistungen im Binnenmarkt. European Commission, Communication from the Commission to the European Parliament, the Council, the European Economic and Social Committee and the Committee of the Regions A Digital Agenda for Europe, COM/2010/0245, European Commission Decision, Establishing minimum requirements for the cross-border processing of documents signed electronically by competent authorities under Directive 2006/123/EC of the European Parliament and of the Council on services in the internal market, notified under document C(2011) 1081, 2011/130/EU, European Union (2013), Directive 2013/37/EU of the European Parliament and of the Council of 26 June 2013 amending Directive 2003/98/EC on the re-use of public sector information. Johann Höchtl und Christian Habernig; Gegenüberstellungen der OGD- Metadaten Ausarbeitungen von Deutschland und Österreich; , [IWG05] Bundesgesetz über die Weiterverwendung von Informationen öffentlicher Stellen (Informationsweiterverwendungsgesetz IWG), StF: BGBl. I Nr. 135/2005 (NR: GP XXII RV 1026 AB 1150 S BR: AB 7425 S. 727.) [OGDAT] Projektgruppe Cooperation Open Government Data Österreich, Rahmenbedingungen für Open Government Data Plattformen, White Paper, Version 1.1.0, , [OGDMD] Projektgruppe Cooperation Open Government Data Österreich, OGDMetadaten, White Paper, Version 2.1, , Metadaten_2_1_2012_10.pdf [PAdES] [PDF] [SigG10] [StKZ13] [Stra12] [Stra13] ETSI, Electronic Signatures and Infrastructures (ESI); PDF Advanced Electronic Signature Profiles; Part 3: PAdES Enhanced - PAdES-BES and PAdES-EPES Profiles, TS , V ISO, Document management - Portable document format - Part 1: PDF 1.7, ISO :2008 Bundesgesetz über elektronische Signaturen (Signaturgesetz - SigG) StF: BGBl. I Nr. 190/1999, letzte Änderung: BGBl. I Nr. 75/2010 K. Stranacher, V. Krnjic, T. Zefferer, Trust and Reliability for Public Sector Data, in Proceedings of International Conference on e-business and e- Government 2013, Issue 73, 2013, pp K. Stranacher, EGIZ Projekt-Dokumentation OpenData und elektronische Dokumente, Version 1.0, 14.November 2012 K. Stranacher, EGIZ Projekt-Dokumentation Analyse Signaturverfahren für OGD, Version 1.0, 21.November 2013 Zusammenfassung 31

32 [XAdES] [XML] [XMLDSIG] ETSI, Electronic Signatures and Infrastructures (ESI); XML Advanced Electronic Signatures (XAdES), TS , V Bray et al., Extensible Markup Language (XML) 1.0 (Fifth Edition), W3C Recommendation, 26 November W3C Empfehlung, XML Signature Syntax and Processing (Second Edition), 2008, Zusammenfassung 32