Analyse PSI-Richtlinie und Metadaten Standards
←
→
Transkription von Seiteninhalten
Wenn Ihr Browser die Seite nicht korrekt rendert, bitte, lesen Sie den Inhalt der Seite unten
Analyse PSI-Richtlinie und
Dokumentation
Metadaten Standards
Version 1.0, 04.12.2013
Klaus Stranacher – klaus.stranacher@egiz.gv.at
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 Das E-Government Innovationszentrum ist eine gemeinsame
Einrichtung des Bundeskanzleramtes und der TU-Graz
Innovationszentrum
Inffeldgasse 16/a, A-8010 Graz
Tel. +43 316 873 5514
Fax. +43 316 873 5520
E-Mail post@egiz.gv.at
www.egiz.gv.at
Inhaltsverzeichnis
1 Einleitung .................................................................................................................................... 4
2 PSI Richtlinie................................................................................................................................ 5
2.1 Einleitung ............................................................................................................................. 5
2.2 PSI-Richtlinie (2013) ............................................................................................................. 6
2.3 Machbarkeitsstudie............................................................................................................ 9
3 Signaturformate....................................................................................................................... 11
3.1 Einleitung ........................................................................................................................... 11
3.2 CAdES Signaturen ............................................................................................................ 12
3.2.1 Einleitung ................................................................................................................ 12
3.2.2 Struktur .................................................................................................................... 13
3.2.3 Eignung ................................................................................................................... 15
3.3 XAdES Signaturen ............................................................................................................. 15
3.3.1 Einleitung ................................................................................................................ 15
3.3.2 Struktur .................................................................................................................... 16
3.3.3 Eignung ................................................................................................................... 17
3.4 PAdES Signaturen ............................................................................................................. 18
3.4.1 Einleitung ................................................................................................................ 18
3.4.2 Struktur .................................................................................................................... 18
3.4.3 Eignung ................................................................................................................... 20
4 Metadaten Format ................................................................................................................. 21
4.1 CKAN-Metadaten ............................................................................................................ 21
4.1.1 Einleitung ................................................................................................................ 21
4.1.2 Struktur .................................................................................................................... 21
4.1.3 Signaturmöglichkeiten ......................................................................................... 22
4.2 OGD Metadaten Österreich ........................................................................................... 22
4.2.1 Einleitung ................................................................................................................ 22
4.2.2 Struktur .................................................................................................................... 22
4.2.3 Signaturmöglichkeiten ......................................................................................... 24
4.3 OGD Metadaten Deutschland ...................................................................................... 24
4.3.1 Einleitung ................................................................................................................ 24
Einleitung 24.3.2 Struktur .................................................................................................................... 24
4.3.3 Signaturmöglichkeiten ......................................................................................... 25
4.4 Dublin Core Metadaten .................................................................................................. 26
4.4.1 Einleitung ................................................................................................................ 26
4.4.2 Struktur .................................................................................................................... 26
4.4.3 Signaturmöglichkeiten ......................................................................................... 26
4.5 MoReq Metadaten .......................................................................................................... 26
4.5.1 Einleitung ................................................................................................................ 26
4.5.2 Struktur .................................................................................................................... 27
4.5.3 Signaturmöglichkeiten ......................................................................................... 28
4.6 Zusammenfassung............................................................................................................ 28
5 Zusammenfassung .................................................................................................................. 29
Abbildungsverzeichnis
Abbildung 2.1 – Zeittafel PSI-Richtlinien, IWG und OGD. ........................................................ 5
Abbildung 2.2 – Vertrauenswürdige Datenweiterverwendung laut PSI-Richtlinie. ........... 10
Abbildung 3.1 – SignedData Containertyp. ........................................................................... 15
Abbildung 3.2 – XMLDSIG Struktur. ........................................................................................... 17
Abbildung 3.3 – XAdES-BES/EPES Struktur. ............................................................................... 18
Abbildung 3.4 – PDF-Signatur. .................................................................................................. 19
Abbildung 4.1 – Metadatenstruktur OGD-AT. ........................................................................ 23
Abbildung 4.2 – Ausschnitt Metadatenstruktur Deutschland. ............................................. 25
Abbildung 4.3 – Ausschnitt Metadatenstruktur MoReq2010. ............................................... 27
Einleitung 31 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 1 1043 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: 29.11.2013 Einleitung 4
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 2018.
01. Juli 2005 18. Juli 2015
Deadline
Deadline Umsetzung
Umsetzung Deadline
Deadline Umsetzung
Umsetzung
PSI-Richtlinie
PSI-Richtlinie PSI-Richtlinie
PSI-Richtlinie 2013/37/EC
2013/37/EC
01. Juli 2008 26. Juni 2013 18. Juli 2018
17. November 2003 Deadline
Deadline Prüfung
Prüfung Umsetzung
Umsetzung Novellierte
Novellierte Deadline
Deadline Prüfung
Prüfung Umsetzung
Umsetzung
PSI-Richtlinie
PSI-Richtlinie 2003/98/EC
2003/98/EC der
der PSI-Richtlinie
PSI-Richtlinie 2003/98/EC
2003/98/EC PSI-Richtlinie
PSI-Richtlinie 2013/37/EC
2013/37/EC PSI-Richtlinie
PSI-Richtlinie 2013/37/EC
2013/37/EC
Open Government Data
19. November 2005
Veröffentlichung
Veröffentlichung IWG
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 5des 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 6Bestimmungen 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] Entsprechung in PSI-Richtlinie [Euro13]
Vollständigkeit:
Die veröffentlichten Datensätze soll „so Eine explizite Erwähnung der Vollständigkeit
vollständig wie möglich, sie bilden den der Daten findet sich in der PSI-Richtlinie
ganzen Umfang dessen ab, was zu nicht. Informationen, die
einem bestimmten Thema dokumentiert personenbezogene Daten beinhalten, sind
ist“. Weiters sollen Metadaten mitgeliefert von einer Weiterverwendung aber ebenso
werden, die „die Rohdaten beschreiben ausgeschlossen (Artikel 1 Absatz 2 cc).
und erklären“. Vor der Veröffentlichung
müssen noch Datenschutz-, Sicherheits-
oder Zugangsbeschränkungen geprüft
werden. Insbesondere
personenbezogene Daten sind von einer
Veröffentlichung ausgenommen.
Primärquelle:
"Die Daten werden von der Verwaltung Der Begriff Weiterverwendung ist in Artikel 2
an ihrem Ursprung gesammelt und definiert. Er besagt, dass
veröffentlicht. Dies geschieht mit dem Weiterverwendung „die Nutzung von
höchstmöglichen Feinheitsgrad, nicht in Dokumenten, die im Besitz öffentlicher
aggregierten oder sonst wie modifizierten Stellen sind, durch natürliche oder juristische
Formaten". 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.
Zeitnahe Zurverfügungstellung:
Die Daten sollen innerhalb eines Formell definiert die Richtlinie keine
angemessenen Zeitraums zur Verfügung Bedingungen für eine zeitnahe
gestellt werden. Insbesondere für Zurverfügungstellung. In der Einleitung der
dynamische Inhalte ist das von großer Richtlinie wird als Grund 12 aber angeführt:
Bedeutung. „[…]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 7wirtschaftliches Potenzial zu nutzen. […]“.
Leichter Zugang:
Die Daten sollen „möglichst einfach und In Artikel 9 werden praktische
barrierefrei“ zugänglich sein. Physische Vorkehrungen definiert: „Die
und technische Hürden sollen vermieden Mitgliedstaaten treffen praktische
werden. Vorkehrungen, die eine Suche nach den
zur Weiterverwendung verfügbaren
Dokumenten erleichtern […]“.
Maschinenlesbar:
Um Daten automatisiert verarbeiten zu Bezüglich Maschinenlesbarkeit besagt
können sollen diese in einem Artikel 5 Absatz (1): „Öffentliche Stellen
maschinenlesbaren Format zur stellen ihre Dokumente in allen
Verfügung gestellt werden. vorhandenen Formaten oder Sprachen
und, soweit möglich und sinnvoll, in
offenem und maschinenlesbarem Format
[…]“ zur Verfügung.
Diskriminierungsfreiheit:
"Jede Person kann zu jeder Zeit auf die Artikel 10 Absatz (1) besagt: „Die
Daten zugreifen, ohne sich identifizieren Bedingungen für die Weiterverwendung
oder eine Rechtfertigung für ihr Handeln von Dokumenten sind für vergleichbare
abgeben zu müssen". 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.
Verwendung offener Standards:
Für die Veröffentlichung der Daten sollen Laut Artikel 5 Absatz (1) sollen
offene Standards verwendet werden. Informationen als auch die Metadaten
„[…]so weit wie möglich formellen, offenen
Standards entsprechen“.
Lizensierung:
Die Projektgruppe Cooperation Open In Artikel 8 werden lizenzrechtliche Aspekte
Government Data Österreich empfiehlt betrachtet. So können veröffentlichende
eine Lizenzierung unter Creative Stellen die Weiterverwendung ohne Lizenz
Commons Namensnennung 3.0 gestatten oder mittels einer Lizenz
Österreich 2. Urheber-, patent- und entsprechende Bedingungen formulieren.
markenrechtliche Fragen müssen zuvor
abgeklärt werden.
Dokumentation (Dauerhaftigkeit):
Die veröffentlichten Daten „sind In Artikel 5 Absatz (1) wird festgelegt, dass
umfassend mit Metadaten dokumentiert die veröffentlichten Informationen „[…]mit
2 http://creativecommons.org/licenses/by/3.0/at/deed.de
PSI Richtlinie 8und über lange Zeit hinweg zu finden“. den zugehörigen Metadaten zur
Verfügung“ gestellt werden sollen.
Nutzungskosten:
Nutzungskosten werden seitens der OGD Im Gegensatz zu OGD definiert die PSI
Bewegung als ein Hindernis angesehen. Richtlinie in Artikel 6 Grundsätze zur
Die Creative Commons Namensnennung Gebührenbemessung. So legt Absatz (1)
3.0 Österreich Lizenz sieht derzeit auch fest: „Werden Gebühren für die
keine Nutzungskosten vor. 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.
2.3 Machbarkeitsstudie
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 94). 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 Domäne
Daten Daten
Bereitsteller/in Weiterverwender/in
Lorem ipsum Lorem ipsum
Lorem
dolor ipsum
sit amet, Lorem
dolor ipsum
sit amet,
Lorem
dolor ipsum
sit amet, Lorem
dolor ipsum
sit amet,
consetetur consetetur
dolor sit amet,
consetetur dolor sit amet,
consetetur
sadipscing elitr, SIGNATUR sadipscing elitr,
consetetur
sadipscing elitr, consetetur
sadipscing elitr,
sed diam ERSTELLUNG sed diam
sadipscing elitr,
sed diam sadipscing elitr,
sed diam
nonumy eirmod nonumy eirmod
sed diam
nonumy sed diam
temporeirmod
invidunt nonumy
temporeirmod
invidunt
nonumy
temporeirmod
invidunt nonumy
temporeirmod
invidunt
tempor invidunt tempor invidunt
Original Vertrauenswürdige
Datenquelle Daten
Abbildung 2.2 – Vertrauenswürdige Datenweiterverwendung laut PSI-Richtlinie.
PSI Richtlinie 103 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 113.2 CAdES Signaturen
3.2.1 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 101 733 [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üsseln6.
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 12Tabelle 2 – CAdES Signaturformate.
Format Beschreibung
CAdES-BES Ist stark äquivalent zu CMS, mit dem Unterschied,
(Basic Electronic Signature) dass das Signaturzertifikat zusätzlich durch die
Signatur geschützt ist.
CAdES-EPES Erweitert CMS bzw. CAdES-BES dahingehend, dass
(Explicit Policy-based eine explizite Signatur-Richtlinie angegeben werden
Electronic Signature) kann. Die Richtlinie ist mitsigniert ist und muss bei der
Signaturprüfung angewendet werden.
CAdES-T Ist eine BES oder EPES Signatur plus einen
(Electronic signature with Signaturzeitpunkt von einem vertrauenswürdigen
Time) Zeitstempeldienst.
CAdES-C Hierbei werden zusätzlich Referenzen auf alle
(Electronic Signature with verwendeten Zertifikate der Zertifikatskette
Complete validation data angeführt.
references)
CAdES-X Long Zusätzlich zu CAdES-C werden hier die konkreten
(EXtended Long format) Werte der Zertifikate und die konkreten Werte der
Revozierungs-Informationen hinzugefügt.
CAdES-A Erweitert CAdES-X Long um einen oder mehrere
(Archival Form) 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.
3.2.2 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• 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 143.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
SignerInfo
digestAlgorithms
... version
signerIdentifier
encapsulatedContentInfo
digestAlgorithm
certificates signedAttributes
... ...
crls signatureAlgorithm
...
signature
signerInfos unsignedAttributes
... ...
Abbildung 3.1 – SignedData Containertyp.
3.3 XAdES Signaturen
3.3.1 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 101 903 [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 15Der folgende Abschnitt beschreibt detaillierter den Aufbau und die Struktur von
XMLDSIG bzw. XAdES.
3.3.2 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 16Abbildung 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.
3.3.3 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 17Abbildung 3.3 – XAdES-BES/EPES Struktur. 3.4 PAdES Signaturen 3.4.1 Einleitung PAdES steht für PDF Advanced Electronic Signatures und ist ebenso ein ETSI-Standard, der als ETSI TS 102 778[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. 3.4.2 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, 13Es 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
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
Signature Directory
ByteRange
520
Contents:
=Signatur
CMS/CAdES
(nicht mitsigniert)
Signatur
870
%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 193.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
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 4.1.1 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. 4.1.2 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 15 http://ckan.org/ 16 http://okfn.org/ Metadaten Format 21
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
4.1.3 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
4.2.1 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 17.
4.2.2 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
17DCAT-AP steht für Data Catalog Vocabulary Application profile for data portals in Europe und
kann unter https://joinup.ec.europa.eu/asset/dcat_application_profile/description bezogen
werden.
Metadaten Format 22in Österreich. Abbildung 4.1 zeigt diese Metadatenstruktur, aufgeteilt auf den
verpflichtenden Metadatenkern und den optionalen Metadatenfeldern.
Abbildung 4.1 – Metadatenstruktur OGD-AT.
Metadaten Format 234.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 4.3.1 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. 4.3.2 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. 18 http://www.w3.org/DesignIssues/Notation3 19 https://github.com/fraunhoferfokus/ogd-metadata Metadaten Format 24
Abbildung 4.2 – Ausschnitt Metadatenstruktur Deutschland 20. 4.3.3 Signaturmöglichkeiten Die deutsche Metadatenstruktur basiert auf CKAN und JSON. Dadurch treffen dieselben Implikation wie im Abschnitt 4.1.3 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 http://htmlpreview.github.io/?https://github.com/fraunhoferfokus/ogd- metadata/blob/master/OGPD_JSON_Schema.html Metadaten Format 25
4.4 Dublin Core Metadaten 4.4.1 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. 4.4.2 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. Dublin Core Einbettung Listing 4.2 – Teil eines HTML-Dokuments mit Dublin Core Metadaten Einbettung. 4.4.3 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 4.5.1 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 21 http://dublincore.org/documents/dcmi-terms/ 22 http://dublincore.org/ Metadaten Format 26
Jahre 2011 (MoReq2010) aktualisiert 23 . Hierbei wird auch ein umfangreiches Set an
Metadaten zur Verfügung gestellt.
4.5.2 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 MoReq2010.
23http://moreq2010.eu/pdf/moreq2010_vol1_v1_1_en.pdf
24Verfügbar unter
http://www.moreq.info/index.php?option=com_jotloader&view=categories&cid=41_371130ad7
49f06a3bb2089d7dbbc2465&Itemid=137&lang=en
Metadaten Format 274.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 25 26 x
Metadaten Metadatenstruktur für OGD basierend auf
Österreich RDF.
OGD Repräsentiert ein Metadatenstruktur für x
Metadaten OGD basierend auf CKAN und JSON.
Deutschland
Dublin Core Metadaten Spezifikation zur Beschreibung x x
Metadaten von unterschiedlichen Ressourcen.
MoReq Metadaten des elektronische x x
Metadaten Aktenführungsstandards MoReq2010.
25 CAdES nur für textbasiertes Notation 3 Format.
26 XAdES sowohl für XML-Serialisierung als auch für Notation 3.
Metadaten Format 285 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
Dokumentenhistorie Version Datum Autor(en) Anmerkung 0.1 31.10.2013 K.Stranacher Erstversion 0.2 15.11.2013 K.Stranacher Abschnitt 2 aktualisiert 0.3 25.11.2013 K.Stranacher Abschnitt 4 aktualisiert 0.4 02.12.2013 K.Stranacher Abschnitt 1 aktualisiert 1.0 04.12.2013 K.Stranacher Finalisierung Zusammenfassung 30
Referenzen
[Euro00] 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.12-20 19.01.2000.
[Euro03] 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.
[Euro06] Richtlinie 2006/123/EG des Europäischen Parlaments und des Rates vom
12. Dezember 2006 über Dienstleistungen im Binnenmarkt.
[Euro10] 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, 19.05.2010.
[Euro11] 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, 25.02.2011.
[Euro13] 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.
[HoHa13] Johann Höchtl und Christian Habernig; Gegenüberstellungen der OGD-
Metadaten Ausarbeitungen von Deutschland und Österreich; 08.03.2013,
[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. 125. 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, 30.07.2012, http://reference.e-
government.gv.at/uploads/media/OGD-1-1-0_20120730.pdf
[OGDMD] Projektgruppe Cooperation Open Government Data Österreich,
OGDMetadaten, White Paper, Version 2.1, 15.10.2012,
http://reference.e-government.gv.at/uploads/media/OGD-
Metadaten_2_1_2012_10.pdf
[PAdES] ETSI, Electronic Signatures and Infrastructures (ESI); PDF Advanced
Electronic Signature Profiles; Part 3: PAdES Enhanced - PAdES-BES and
PAdES-EPES Profiles, TS 102 778-3, V 1.2.1
[PDF] ISO, Document management - Portable document format - Part 1: PDF
1.7, ISO 32000-1:2008
[SigG10] Bundesgesetz über elektronische Signaturen (Signaturgesetz - SigG)
StF: BGBl. I Nr. 190/1999, letzte Änderung: BGBl. I Nr. 75/2010
[StKZ13] 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. 124-131.
[Stra12] K. Stranacher, EGIZ Projekt-Dokumentation OpenData und elektronische
Dokumente, Version 1.0, 14.November 2012
[Stra13] K. Stranacher, EGIZ Projekt-Dokumentation Analyse Signaturverfahren für
OGD, Version 1.0, 21.November 2013
Zusammenfassung 31[XAdES] ETSI, Electronic Signatures and Infrastructures (ESI); XML Advanced
Electronic Signatures (XAdES), TS 101 903, V 1.4.1
[XML] Bray et al., Extensible Markup Language (XML) 1.0 (Fifth Edition), W3C
Recommendation, 26 November 2008.
[XMLDSIG] W3C Empfehlung, XML Signature Syntax and Processing (Second Edition),
2008, http://www.w3.org/TR/xmldsig-core/
Zusammenfassung 32Sie können auch lesen
