Elektronische Zustellung mit Fabasoft

Transkript

1 Elektronische Zustellung mit Fabasoft Christian Kastner

2

3

4 ISBN: X Alle Rechte der Verbreitung, auch durch fotomechanische Wiedergabe, Tonträger jeder Art, auszugsweiser Nachdruck oder Einspeicherung und Rückgewinnung in Datenverarbeitungsanlagen aller Art, sind vorbehalten. Es wird darauf verwiesen, dass alle Angaben in diesem Fachbuch trotz sorgfältiger Bearbeitung ohne Gewähr erfolgen und eine Haftung der Autoren oder des Verlages ausgeschlossen ist. Aus Gründen der einfacheren Lesbarkeit wird auf die geschlechtsspezifische Differenzierung, z.b. Benutzer/-innen, verzichtet. Entsprechende Begriffe gelten im Sinne der Gleichbehandlung grundsätzlich für beide Geschlechter. Fabasoft und das Fabasoft Logo sind registrierte Warenzeichen der Fabasoft AG. Microsoft, MS-DOS, Windows, das Windows-Logo, Windows 95, Windows 98, Windows Me, Windows XP, Windows NT, Windows 2000, Windows Server, Active Directory, Outlook, Excel, Word, PowerPoint, Visual Studio, Visual Basic, Visual C++ sind entweder registrierte Warenzeichen oder Warenzeichen der Microsoft Corporation. Alle anderen verwendeten Hard- und Softwarenamen sind Handelsnamen und/oder Marken der jeweiligen Hersteller. Fabasoft Intl. Software GmbH & Co KG, Linz 2005 Honauerstraße 4, 4020 Linz Tel.: +43 (732) Gestaltung: SCHRANGL PRESLMAYR SCHAURHOFER Marketing GmbH, Linz Satz: idee quadrat Werbeagentur Langanke & Stolz OEG, Linz Druck: Estermann Druck GmbH, Aurolzmünster

5 Elektronische Zustellung mit Fabasoft Christian Kastner

6 inhaltsverzeichnis 2005 Elektronische Zustellung mit Fabasoft 1 1 Einführung 11 2 Allgemeines Ziele 15 Kosteneinsparung 15 Verfahrenslaufzeit 16 Medienbruchfreier Geschäftsverkehr 16 Zugang zum behördlichen Geschäftsverkehr unabhängig von Ort und Zeit 16 Sichere Zustellung Konzepte 17 ZUSE 17 Virtuelle Poststelle Technologien und Standards 19 XML 19 Kryptographie 33 Verzeichnisdienst 38 3 Konzept: ZUSE Use Cases 43 Anfrage beim Zustellkopf 43 Erstellen und Versenden des Zustellstückes 44 Annahme des Zustellstückes durch den Zustelldienst 45 Verständigung der Natürlichen/Juristischen Person 46 Identifikation der Natürlichen/Juristischen Person 46 Abholen des Zustellstückes 46 Versenden von Zustellnachweisen 47

7 5 3.2 Infrastruktur 49 LDAP 49 MOA-Module 50 Bürgerkarte Zustellkopf 57 Einzelanfrage 57 Bulkanfrage Amtssignatur 71 Elektronische Signatur/Digitale Signatur 71 Elektronische Unterschrift 71 Definition des Begriffes Amtssignatur 72 Beweiskraft von Ausdrucken 73 Visualisierung Bescheidstruktur Zustellung Kritische Erfolgsfaktoren 84 Bürgerkarte 84 LDAP/Zustellkopf 84 Organisatorische Herausforderungen 87 Amtssignatur 87 4 Reinschrift- und Abfertigungsinfrastruktur Reinschrift erzeugen (Finalisierung) 92 Reinschrift erzeugen am Beispiel einer Erledigung 95 COOELAK@1.1001:ObjectFixFinalizer 97 COOELAK@1.1001:ResolveAddresseeFinalizer 98 COOELAK@1.1001:AddresseeXMLFinalizer 100 COOELAK@1.1001:DefaultFinalizer 100 COOELAK@1.1001:ContentFinalizer 102 COOELAK@1.1001:SeriesFinalizerEx 102

8 4.2 Abfertigung 104 Prozess 105 Resolver 106 Dispatcher Vorkonfiguration 110 Umsetzung der ZUSE-Spezifikation 5 mit Fabasoft ZS Einbettung in den Bearbeitungsprozess Erzeugen der Reinschrift Abfertigung der Erledigung 115 Adressatenauflösung 118 Generieren der Zustellstücke 119 Versenden des Zustellstückes an den Zustelldienst Annahme von Zustellstücken durch den Zustelldienst Annahme von Zustellbestätigungen Abholen von Zustellbestätigungen und Zuordnung zum Erledigungsobjekt 124 Abfrage der neuen Zustellbestätigungen 125 Abholen einer Zustellbestätigung 126 Acknowledge der Übernahme der Zustellbestätigung Konzept: Virtuelle Poststelle Virtuelle Poststelle OSCI-Transport 134 OSCI-A 135 OSCI-B Definierte Use Cases von OSCI 150 Laufzettel 150 One-Way-Message, Aktiver Empfänger 153

9 7 One-Way-Message, Passiver Empfänger 155 Request-Response, Passiver Empfänger mit Protokollierung 156 Request-Response, Passiver Empfänger ohne Protokollierung Kritische Erfolgsfaktoren 159 Public Key Infrastruktur 159 Standardisierung von Inhaltsdaten 160 Implizite Abhängigkeiten der Kommunikationspartner 161 Umsetzung der Virtuellen 7 Poststelle mit Fabasoft VPS Rahmenbedingungen 168 Zuordnung von Schlüsseln zu Benutzern 168 Zuordnung von öffentlichen Schlüsseln zu Adressaten Rollen 169 Eingang 169 Ausgang OSCI-Toolkits 172 Client-Toolkits 172 Client- und Intermediär-Toolkits Intermediär Objektmodell 173 OSCI-Rolle 173 Intermediär 175 Laufzettel Administration 182 Zustellkonfiguration 183 Zustelldienst Beziehung zwischen OSCI-Use Cases und dem Bearbeitungsprozess 184 Eingangsbehandlung 184 Ausgangsbehandlung 185

10 8 Ausblick Glossar Abbildungsverzeichnis Literaturverzeichnis Anhang - OSCI Prüfungssequenz Fehler auf Transportebene Meldungen auf Nachrichtenebene 213

11 9

12

13 11 1 Einführung In diesem Buch werden die gegenwärtig bekannten Konzepte im Bereich der Zustellung und deren Umsetzung durch die Produkte Fabasoft ZS und Fabasoft VPS dargelegt. Es wurde die Balance zwischen technischer Tiefe und informativer Breite angestrebt. Die Konzepte und deren Umsetzung werden sowohl aus technischer als auch aus organisatorischer Sicht betrachtet, um die kritischen Erfolgsfaktoren für eine effektive Nutzung aufzeigen zu können. Abbildung 1 E-Government-Kreislauf Die elektronische Zustellung ist der fehlende Baustein im E-Government-Kreislauf und soll die postalische Zustellung auf ein Minimum reduzieren. Wie aus Abbildung 1 ersichtlich, ist das der letzte fehlende Schritt im durchgängigen E-Government.

14 Abbildung 2 Vorteile einer elektronischen Zustellung Eine elektronische Zustellung, wie in Abbildung 2 dargestellt, hat für alle Kommunikationsteilnehmer Vorteile. Für die auftraggebende Organisation soll erreicht werden: Kosteneinsparung kürzere Verfahrenslaufzeit medienbruchfreier Geschäftsverkehr

15 1. Einleitung 13 Für uns, Natürliche/Juristische Personen, soll der Zugang zum behördlichen Geschäftsverkehr unabhängig von Ort und Zeit sowie eine sichere elektronische Zustellung möglich sein. Auf den Punkt gebracht: Das Papier soll weg, aber die gewohnte Zustellqualität und Authentizität muss erhalten bleiben. Die Natürliche/Juristische Person will den Geschäftsverkehr mit der Behörde, wo auch immer und sei es im Urlaub, einsehen können. Aber nicht nur der Ort ist ein Kriterium, sondern auch die Zeit. Es soll nicht mehr nötig sein, auf das Postamt pilgern zu müssen, um den Bescheid abzuholen. In den nächsten Kapiteln wird konkret auf folgende Konzepte und deren verwendete Standards eingegangen: ZUSE (Österreich) Virtuelle Poststelle (Deutschland, Schweiz) Im Anschluss an die Konzepte wird die Umsetzung in den Fabasoft Produkten Fabasoft ZS und Fabasoft VPS und deren Integration in die Ein- und Ausgangsbearbeitung sowie in die Abfertigungsinfrastruktur der Fabasoft egov-suite ausführlich vorgestellt. So schließt sich der Kreis von der Theorie bis zur Umsetzung.

16

17 15 2 allgemeines In diesem Kapitel werden die Ziele der elektronischen Zustellung, die gegenwärtigen Konzepte im Bereich Zustellung und die dafür verwendeten Standards vorgestellt. Die Konzepte werden in weiteren Kapiteln ausführlich behandelt. Die Standards werden zum allgemeinen Verständnis dargestellt und können nicht mehr als eine Einführung sein. Die Standards werden in drei Kategorien unterteilt: XML Kryptographie Verzeichnisdienste 2.1 Ziele Wie schon in Abbildung 2 dargestellt, hat die elektronische Zustellung folgende Ziele: Kosteneinsparung Kürzere Verfahrenslaufzeiten Medienbruchfreier Geschäftsverkehr Zugang zum behördlichen Geschäftsverkehr unabhängig von Ort und Zeit Sichere elektronische Zustellung Vor dem Einstieg in die einzelnen Konzepte werden die Ziele konkretisiert. Kosteneinsparung Was kostet eine postalische Zustellung in Form eines Einschreibens mit Rückschein? In Österreich sind das 7,10 [Post05]. Die elektronische Zustellung soll und wird in diesem Bereich eine Kosteneinsparung bringen. Auch wenn es noch keine konkreten Preise für eine elektronische Zustellung gibt, kann davon ausgegangen werden, dass die Kosteneinsparung erheblich sein wird.

18 Verfahrenslaufzeit Wie kann die Zustellung Einfluss auf die Verfahrenslaufzeit nehmen? Die elektronische Zustellung kann die Zeit, die für die postalische Zustellung und für eine etwaige Abholung einer Zustellung beim Postamt aufgewendet werden muss, auf annähernd null reduzieren. Medienbruchfreier Geschäftsverkehr Durch eine elektronische Zustellung wird es endlich möglich, den Geschäftsverkehr sowohl aus Sicht der Behörde als auch aus Sicht der Natürlichen/Juristischen Person völlig medienbruchfrei, also ohne Umweg über Papier und die entsprechende Nacherfassung mittels Scannen, durchzuführen. Zustelldienste werden darüber hinaus in der Lage sein, Zusatzdienste wie einen Dokumentensafe zur Verfügung zu stellen. Zugang zum behördlichen Geschäftsverkehr unabhängig von Ort und Zeit Die Natürliche/Juristische Person kann sich die Sendungen zu jedem Zeitpunkt und am Ort ihrer Wahl anschauen. Die Sendung wird unmittelbar nachdem der Sachbearbeiter sie versandt hat, beim Empfänger verfügbar. Zudem fällt der Weg zum Postamt weg. In Anbetracht von Rationalisierung und Schließungen von Postämtern kann das durchaus von Bedeutung werden. Sichere Zustellung In der Zeit von Viren, Trojanern und ähnlichem elektronischen Ungetier bekommt die Vertraulichkeit und Authentizität einen großen Stellenwert. Um das gleiche subjektive Vertrauen herzustellen, das man der bisherigen postalischen Zustellung entgegenbringt, ist eine Menge an Technologie notwendig. Diese Technologie wie Zertifikate, SmartCards, SmartCard-Reader etc. gilt es flächendeckend ins Feld zu bringen. Ohne ihre Verbreitung ist der Erfolg der elektronischen Zustellung gefährdet.

19 2. Allgemeines. 2.1 Ziele 2.2 Konzepte 17 Um das Vertrauen in die elektronische Zustellung zusätzlich zu stärken, ist es notwendig, dass die Natürliche/Juristische Person die Authentizität der Sendung nachvollziehen kann. 2.2 Konzepte ZUSE Das ZUSE-Konzept wurde von der Stabsstelle IKT-Strategie des Bundes definiert. Es umfasst folgende Bereiche: Amtssignatur Bescheidstruktur Zustellung Dieses Konzept wird zukünftig in Österreich eingesetzt und verwendet unter anderem die folgenden Standards: XML SOAP SOAP with Attachments XMLDSIG LDAP PKCS#7 CMS S/MIME In Kapitel 3 wird ausführlich auf das Konzept eingegangen.

20 Virtuelle Poststelle Das Konzept der Virtuellen Poststelle ist sowohl Bestandteil des DOMEA Konzeptes 2.0 als auch der Initiative Bund-Online Die Virtuelle Poststelle basiert auf dem OSCI-Protokoll, mit dem sie oft gleichgesetzt wird. Obwohl das OSCI- Protokoll ein nicht unerheblicher Bestandteil der Virtuellen Poststelle ist, umfasst diese auch andere, in einem kausalen Zusammenhang mit dem OSCI-Protokoll stehende Dienste. Die Virtuelle Poststelle interagiert mit einem Vorgangsbearbeitungssystem in den Bereichen: Eingangsbearbeitung Ausgangsbearbeitung Neben Deutschland hat das OSCI-Protokoll auch in der Schweiz Einzug gehalten, wobei davon ausgegangen werden kann, dass das OSCI-Protokoll auch dort eine gewisse Verbreitung erreichen wird. Das OSCI-Protokoll definiert keine Inhalte, sondern ausschließlich wie diese übertragen werden. Seine Aufgabe ist es dabei, Integrität Vertraulichkeit Verfügbarkeit Authentizität zeitliche Bestimmtheit und Nachweisbarkeit sicherzustellen. Dieses Konzept setzt unter anderem die folgenden Standards ein: XML SOAP

21 2. Allgemeines. 2.2 Konzepte 2.3 Technologien und Standards 19 SOAP with Attachments XMLDSIG XMLENC PKCS#7 PKCS#1-V1.5 PKCS#12 In Kapitel 6 wird auf die Virtuelle Poststelle und das OSCI-Protokoll ausführlich eingegangen. Im Rahmen dieses Kapitels wird eine kurze Einführung in die jeweiligen Standards gegeben. 2.3 Technologien und Standards XML XML = Extensible Markup Language [XML00]. XML ist ein einfaches, textbasiertes Format, das sowohl leicht lesbar als auch strukturiert sein soll. Es wurde als Subset von SGML definiert. XML hat sich zu einer entscheidenden Technologie bei lose verbundenen Systemen entwickelt, da es nur wenige Anforderungen an die verarbeitenden Systeme stellt. Ein XML-Dokument ist die Summe von XML-Entitäten, wobei ein XML-Dokument genau ein Wurzelelement hat. <?xml version= 1.0 encoding= utf-8?> <Book> <Author>Henry Ford</Author> <Preface>Prefatory text</preface> <Intro>This is a book.</intro> <Book> Quelltext 1: Einfaches XML-Beispiel

22 Was ist nun eine Entität? Wie aus Quelltext 1 ersichtlich, handelt es sich bei Book, Author, Preface und Intro um XML-Entitäten. Bei erster Betrachtung von Quelltext 1 kann man sich der Verwandtschaft zu HTML (ohne Berücksichtigung der Elementnamen) nicht verwehren. Formal gesehen ist HTML eine spezielle Ausprägung von XML, wobei zu berücksichtigen ist, dass HTML nicht den Grundsatz der Wellformedness (vgl Wellformed XML) erfüllt. Wellformed XML Jedes Element, wie beispielsweise Book, hat ein öffnendes (<Book>) und ein schließendes Tag (</Book>). Warum ist HTML nicht wellformed? HTML erfüllt diese Regel nicht, da manche Tags kein schließendes Element erfordern, wie beispielsweise das IMG-Tag (= Image). Damit der Grundsatz der Wellformedness erfüllt werden kann, wurde XHTML definiert, das alle bekannten HTML-Tags enthält, mit dem Unterschied, dass alle Elemente ein öffnendes und ein schließendes Tag erfordern. Valid XML Warum ist ein wellformed XML-Dokument nicht automatisch auch valide? Die Validität eines XML-Dokumentes manifestiert sich in ihren inhaltlichen Beziehungen und Regeln. Kann man anhand von Quelltext 1 prüfen, ob das vorliegende XML-Dokument valide ist? Nein, denn es existiert keine Information, was als valides XML-Dokument angesehen wird. Um die Entscheidung treffen zu können, ob ein XML-Dokument valide ist, ist eine Schema-Definition in Form einer Document Type Definition (DTD) oder eines XML-Schemas notwendig.

23 2. Allgemeines. 2.3 Technologien und Standards 21 Ein Schema definiert Art und Typ der Entität Reihenfolge der Entitäten und die Regeln über den Inhalt der Entitäten. DTD (Document Type Definition) <?xml version="1.0" encoding="utf-8"?> <!ELEMENT Book (Author, Preface, Intro)> <!ELEMENT Author ANY> <!ELEMENT Preface ANY> <!ELEMENT Intro ANY> Quelltext 2: Einfaches Beispiel für eine DTD Die in Quelltext 2 dargestellte DTD ist das korrespondierende Schema, das das XML-Dokument (Quelltext 1) validieren könnte. Eine DTD kann Inhalte definieren, jedoch nicht komplexe, inhaltliche Regeln. Darüber hinaus ist es nicht möglich, Namespaces zu definieren. Gegenwärtig werden DTDs immer mehr durch XML-Schemata verdrängt. Vor allem in Bezug auf Webservices wird ausschließlich XML-Schema eingesetzt. Aus diesem Grund hat XML-Schema die größere Bedeutung für dieses Buch und für die Zukunft. DTDs werden nur aus Gründen der Vollständigkeit erwähnt. Zurzeit werden DTDs unter anderem in OpenOffice oder HTML 4 verwendet.

24 XML-Schema <?xml version= 1.0 encoding= UTF-8?> <xs:schema xmlns:xs= elementformdefault= qualified attributeformdefault= unqualified > <xs:element name= Book > <xs:complextype> <xs:sequence> <xs:element name= Author /> <xs:element name= Preface /> <xs:element name= Intro /> </xs:sequence> </xs:complextype> </xs:element> </xs:schema> Quelltext 3: Einfaches Beispiel für ein XML-Schema Die Schemata, wie in Quelltext 2 und Quelltext 3 dargestellt, sind äquivalent und würden das XML-Dokument, wie in Quelltext 1 dargestellt, validieren. Im Unterschied zu DTDs verwenden XML-Schemata ausschließlich XML-Elemente. Sobald von Webservices die Rede ist, sind XML-Schemata im Spiel. SOAP wird somit mit XML-Schema assoziiert. In diesem sehr einfachen Beispiel wird definiert, dass das Element Book drei Subelemente, Author, Preface und Intro, hat. Die Sequenz von Author, Preface und Intro muss eingehalten werden, damit es als valide erkannt wird. Die drei Elemente Author, Preface und Intro können alle Werte annehmen. Es wird keine Einschränkung definiert. Dieses Beispiel dient zur Illustration. Reale Schemata haben eine beträchtlich höhere Komplexität. SOAP Simple Object Access Protocol (SOAP) [SOAP00] ist ein einfaches Protokoll zum Austausch von Informationen in einem dezentralen, verteilten Umfeld. Es ist ein XML-basiertes Protokoll, das aus drei Teilen besteht (siehe Abbildung 3).

25 2. Allgemeines. 2.3 Technologien und Standards 23 Abbildung 3 Aufbau einer SOAP- Nachricht [SOAP03a] Prinzipiell ist SOAP an kein spezifisches Transportmedium gebunden, jedoch hat die Vergangenheit gezeigt, dass es praktisch nur mit HTTP verwendet wird. Es ist somit allgemein anerkannt, dass SOAP mit HTTP assoziiert wird. Quelltext 4 stellt eine einfache SOAP-Nachricht dar. Für den empfangenden Endpunkt ist in der Regel nur das Element soap-env:body relevant, denn dieses Element enthält die Daten, die bearbeitet werden müssen und für die eine Antwort (= Response) generiert werden muss. Was immer auch der empfangende Endpunkt als Antwort liefert, wird durch das zugehörige XML-Schema definiert. Das XML-Schema kann somit als gemeinsame Vereinbarung angesehen werden. Die beiden Endpunkte vereinbaren, was sie einander übermitteln.

26 Beispiel einer SOAP-Anfrage <?xml version="1.0" encoding="utf-8"?> <soapenv:envelope xmlns:soapenv=" xmlns:xsd=" xmlns:xsi=" xsi:schemalocation=" soapgetmessageid.xsd oscisig.xsd oscienc.xsd"> <soapenv:header> <osci:controlblock Id="XREF-1" SequenceNumber="0" soapenv:actor=" soapenv:mustunderstand="1" xmlns:osci=" <osci:challenge>7debmh43i9i89</osci:challenge> </osci:controlblock> <osci:desiredlanguages Id="XREF-2" LanguagesList="de" soapenv:actor=" soapenv:mustunderstand="1" xmlns:osci=" </soapenv:header> <soapenv:body Id="XREF-0"> <osci:getmessageid xmlns:osci=" </soapenv:body> </soapenv:envelope> Quelltext 4: Beispiel für einen SOAP-Request SOAP with Attachments SOAP with Attachments (SwA) [SwA00] ist eine Möglichkeit, Dokumente verschiedenen MIME-Typs ( text/xml, application/pdf, etc.) in einer Message zu transportieren. Dazu wird eine Multipart/Related MIME-Message verwendet, wobei der erste Part den SOAP-Envelope enthält. Es kommen dabei folgende RFCs zur Anwendung: MIME [RFC2045] Multipart/Related Media Typ [RFC2387] URI Schemata [RFC2111] MIME Encapsulation [RFC2257] Welches Ziel wird damit verfolgt? Es hat vor allem den Zweck, Attachments in ihrer binären Form zu übertragen. Somit ist es nicht notwendig, sie in eine kanonische Form wie z.b. BASE64 zu bringen.

27 2. Allgemeines. 2.3 Technologien und Standards 25 Das Einbetten von Inhalten in Form von BASE64 hat zur Folge, dass sich die zu übertragende Datenmenge erheblich erhöht und somit den Memory-Footprint bei der Gegenseite nachhaltig negativ beeinflusst, sofern in dieser ein DOM-Parser verwendet wird. Inplace-Contents sind im Gegenzug leichter zu verarbeiten als eine MIME-Message. Bei geringen Volumina kann die Wahl von Inplace-Contents in Form von BASE64 durchaus akzeptabel sein, da der Implementierungsaufwand für einen MIME-Message Parser doch erheblich ist. Bei großen Volumina sollte aber auf Inplace-Contents verzichtet werden. Mittels SOAP with Attachments wäre die prinzipielle Möglichkeit eines SMTP-Bindings vorhanden. Es fehlen nur noch die Transportheader wie From To Subject etc. Die Vergangenheit hat gezeigt, dass sich diese Form des Transports nicht durchgesetzt hat. Auch wenn SOAP with Attachments nicht über den Status einer Note hinausgekommen ist, hat es sich als de facto- Standard etabliert und wird noch einige Zeit existieren, bis es vom kürzlich veröffentlichten Standard XML-binary Optimized Packaging [XOP05] abgelöst wird. Das XML-binary Optimized Packaging verfolgt einen ähnlichen Ansatz wie SOAP with Attachments. Zusätzlich existiert die Möglichkeit einer PKCS#7-Signatur. Den Fabasoft Standardsoftwareprodukten stehen beide Arten, SOAP und SOAP with Attachments, zur Verfügung. Die Fabasoft Webservice-Infrastruktur übernimmt die Aufgabe des Erzeugens und des Zerlegens einer MIME- Message. Dem Webservice wird es als eine Menge von Inhalten zur Verfügung gestellt, mit denen es auf einfache Weise arbeiten kann. Das häufigste Szenario in diesem Bereich ist ohnehin das Ablegen der Inhalte. Das Webservice kann sich voll auf seine eigentliche Aufgabe konzentrieren und muss sich nicht um die Serialisierung und Deserialisierung kümmern.

28 Beispiel für eine SOAP with Attachments-Nachricht MIME-Version: 1.0 Content-Type: Multipart/Related; boundary=mime_boundary; type=text/xml; start="< Content-Description: This is the optional message description. MIME_boundary Content-Type: text/xml; charset=utf-8 Content-Transfer-Encoding: 8bit Content-ID: < Content-Location: <?xml version= 1.0?> <SOAP-ENV:Envelope xmlns:soap-env=" <SOAP-ENV:Body>.. <thesignedform href="cid: </SOAP-ENV:Body> </SOAP-ENV:Envelope> MIME_boundary Content-Type: image/tiff Content-Transfer-Encoding: binary Content-ID: < Content-Location: TIFF image... MIME_boundary Quelltext 5: Beispiel für eine SOAP with Attachments-Nachricht [SwA00] XMLDSIG XMLDSIG steht für eine digitale Signatur von XML-Elementen. Die W3C Recommendation XML-Signature Syntax and Processing [XDSG02] definiert, wie digitale Signaturen in XML-Dokumenten angebracht und interpretiert werden müssen.

29 2. Allgemeines 2.3 Technologien und Standards 27 Wie auch bei einer normalen digitalen Signatur unterschreibt der Signator mit seinem privaten Schlüssel. Was wird bei einer digitalen Signatur unterschrieben? Es wird der Hash des zu signierenden binären Stromes mit dem privaten Schlüssel verschlüsselt. Ein Hash ist eine mit einem Hashverfahren, wie beispielsweise SHA1 oder MD5, erstellte Zahl, die eindeutig den Inhalt repräsentiert. Rein mathematisch gesehen sind Hashverfahren Verfahren, die für unterschiedliche Inhalte idente Zahlen produzieren können. Für eine Signatur sind allerdings Hashverfahren notwendig, die unter keinen Umständen gleiche Zahlen produzieren. Jegliche Veränderung hat einen veränderten Hashwert zur Folge. Es ist also völlig ausreichend, ein Zeichen im binären Strom zu verändern um zu einem anderen Ergebnis zu kommen. Damit ist auch völlig irrelevant, ob die Veränderung irgendeine Auswirkung auf die Information an sich hat. Abbildung 4 Bildung von Hashwerten

30 Wenn man einen SHA1 über beide XML-Dokumente erzeugt (Abbildung 4), die sich in genau einem Space (vor Element Author) unterscheiden, so sieht man deutlich, dass sich der jeweils gebildete Hashwert ganz erheblich unterscheidet. Hashalgorithmen müssen die Anforderung erfüllen, dass sie für zwei verschiedene Datenströme verschiedene Hashwerte und für zwei gleiche Datenströme den gleichen Hashwert liefern müssen. Hat sich am Informationsgehalt etwas verändert? Nein. In beiden Fällen ist der Informationsgehalt des Elementes Author der gleiche. Eigentlich will man, dass die XML-Elemente, wie in Abbildung 4 dargestellt, den gleichen Hashwert liefern. Es ist also ein Verfahren notwendig, damit das linke und das rechte XML-Dokument in Abbildung 4 binär die gleiche Darstellung hat. Aus Sicht von XML sind die XML-Dokumente valide, da Whitespaces keinen Einfluss auf die Validität von XML-Dokumenten haben. Dieses Verfahren nennt man Kanonisierung, also Gleichmachen. Eine der Regeln bei der Kanonisierung ist es, überflüssige Whitespaces zu entfernen und mehrere aufeinander folgende Whitespaces auf einen Whitespace zu reduzieren. Die Kanonisierung von XML-Elementen ist also eine Grundvoraussetzung für eine digitale Signatur. Nur so kann sichergestellt werden, dass der Hashwert der gleiche ist, egal wie viele nötige und/oder unnötige Whitespaces das XML-Dokument enthält. Wird keine Kanonisierung durchgeführt, kann es sehr leicht dazu kommen, dass eigentlich gleiche XML-Dokumente verschiedene Hashwerte liefern, obwohl sie sich im Sinne von XML-Dokumenten nicht unterscheiden. Kann für ein augenscheinlich identes Dokument nicht der gleiche Hashwert berechnet werden, so wird eine Verifizierung der Signatur nicht erfolgreich verlaufen. Es entsteht der Anschein, dass das signierte XML-Dokument verändert worden ist, obwohl logisch nichts verändert wurde. Eine XML-Signatur zeichnet sich durch eine Menge von Transformationen aus. Unter Transformation ist eine Manipulation der Daten zu verstehen, wobei das Ergebnis ein gültiges XML-Dokument sein muss. Eine weitere Transformation könnte die Darstellung des XML-Inhaltes mittels XSLT-Stylesheets sein. Das Ergebnis aller Transformationen wird als Basis für die Berechnung des Hashwertes herangezogen. Der resultierende Hashwert wird mittels privatem Schlüssel verschlüsselt. Das Ergebnis der Verschlüsselung ist der Signaturwert.

31 2. Allgemeines 2.3 Technologien und Standards 29 Um die Signatur verifizieren zu können, muss prinzipiell der Hashwert des signierten Inhaltes berechnet werden. In vielen Szenarien wird aber nicht das blanke XML, sondern eine besondere Ansicht, wie beispielsweise eine Übersichtsseite, signiert. Damit auch dies wieder verifiziert werden kann, ist es notwendig, alles mit der Signatur mitzuübertragen, was zum Nachrechnen der Signatur notwendig ist. In diesem Fall redet man von Transformationen im Sinne einer digitalen Signatur. Man darf diese allerdings nicht mit XML-Transformationen verwechseln: Eine Transformation im Sinne einer digitalen Signatur kann die Ausprägung einer XML-Transformation haben. Ausgehend vom Inhalt werden alle signaturrelevanten Transformationen angebracht, um zu jenem binären Strom zu kommen, der schlussendlich signiert wird. Ausgehend vom transformierten Inhalt wird ein Hash gebildet, der mit dem Signaturwert verglichen wird. Wie schon in Abbildung 4 dargestellt, wird der Hashwert von einem binären Strom gebildet. Damit jetzt <value> </value> und <value> </value> gleich sind, muss das XML in eine kanonische Form gebracht werden. Die Kanonisierung definiert Regeln und Vorschriften, wie beispielsweise Whitespaces (Space, CR, NL, ) zu behandeln sind, damit immer der gleiche, eindeutige binäre Strom entsteht, der signiert werden kann. Die einfache Kanonisierungsregel ist, alle mehrfachen Spaces auf ein Space zu reduzieren. Kann diese Voraussetzung, warum auch immer, nicht erfüllt werden, wird die erneute Anwendung der Methoden zu einem anderen Ergebnis führen. Somit kann die vorliegende digitale Signatur nicht verifiziert werden. <ds:signature xmlns:ds=" <ds:signedinfo> <ds:canonicalizationmethod Algorithm=" <ds:signaturemethod Algorithm=" <ds:reference URI="content0"> <ds:digestmethod Algorithm=" <ds:digestvalue>nl0exd3moz6vgwmcx/5mk6ogq48=</ds:digestvalue> </ds:reference> <ds:reference URI="cid:ras_gdp.jpg"> <ds:digestmethod Algorithm="

32 <ds:digestvalue>vwq3wiive0idfpdootv/uqo6jwg=</ds:digestvalue> </ds:reference> <ds:reference URI="content1"> <ds:transforms> <ds:transform Algorithm=" </ds:transforms> <ds:digestmethod Algorithm=" <ds:digestvalue>vkupjf5aw/9f0p4l4znpe3i2yyc=</ds:digestvalue> </ds:reference> <ds:reference URI="content2"> <ds:transforms> <ds:transform Algorithm=" </ds:transforms> <ds:digestmethod Algorithm=" <ds:digestvalue>su069llkzrajt8bkcacn2q3uc7m=</ds:digestvalue> </ds:reference> </ds:signedinfo> <ds:signaturevalue>fvyyeqrnt0avgwxy61/dgko+hj2qygjxlezyrvyubylk6q6qiee6y/t/4 0CEbyCROa4HeXmLuefi DeqOiHTeMtgcVEaMddN8CkHn4w25925jOnvVqSxHbk3xYdJOpyMN5iCf0HappBlQ+vAkiLWmVuX4 uqsw+usmel0zyhyn7we=</ds:signaturevalue> <ds:keyinfo> <ds:retrievalmethod URI="author0_signature_issuer:_ address </ds:keyinfo> </ds:signature> Quelltext 6: Beispiel einer XML-Signatur XMLENC XMLENC steht für die Verschlüsselung von XML-Elementen. Die W3C Recommendation XML Encryption Syntax and Processing [XMLENC02] definiert, wie eine Verschlüsselung in XML-Dokumenten angebracht und interpretiert wird.

33 2. Allgemeines 2.3 Technologien und Standards 31 <xenc:encrypteddata xmlns:xenc= MimeType="Multipart/Related"> <xenc:encryptionmethod Algorithm=" <ds:keyinfo> <xenc:encryptedkey> <xenc:encryptionmethod Algorithm=" 1_5"/> <ds:keyinfo> <ds:x509data> <ds:x509certificate>miic4jccakugawibagie7z+htdanbgkqhkig9w0baqufa DCBpzELMAkGA1UEBhMCZGUxIzAhBgNV BAoTGiBicmVtZW4tb25saW5lLXNlcnZpY2VzIENBMSowKAYDVQQLEyFicmVtZW4tb25saW5lLXNl cnzpy2vzienbifrly2huawsxjdaibgnvbamtg2jyzw1lbi1vbmxpbmutc2vydmljzxmgq0egmjeh MB8GCSqGSIb3DQEJARYSaW5mb0Bib3MtYnJlbWVuLmRlMB4XDTA0MDkxMDEzMTIzNFoXDTA2MDkx MDEzMTIzNFowdTELMAkGA1UEBhMCREUxDDAKBgNVBAoTA2JvczELMAkGA1UECxMCUEUxKTAnBgNV BAMTIFRlc3QgWmVydGlmaWthdCBPU0NJLU1hbmFnZXIgVlBTMSAwHgYJKoZIhvcNAQkBFhFib3NA Ym9zLWJyZW1lbi5kZTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAp6Y0E0K1AI9DWG4JvZUr j0gosp4oqyivyek78avrtlx0bvn5bdmqcs8aaxbb06lmf5kctzjolkzmfexstqg9xe1w2sxguths AeK9zNv2AoqfNCdidwt7BiYpPapoGrn67kDY9XtYNG0t5CMiXpzB2THWVRLzwfNTZ2hhFWZm1IEC AwEAAaNMMEowCwYDVR0PBAQDAgP4MB0GA1UdDgQWBBTcok4XaNCo0ickYJ0V8FIOYl6gKTARBglg hkgbhvhcaqeebamcbaawcqydvr0tbaiwadanbgkqhkig9w0baqufaaobgqa74s1ubc9ieqc4u37d QgDCqtAym8RIiEYlaV8dbIa11jDPQG3SotZV2lzxqtTaRNHiDXqnQp1SmeSRN/3etB0jcY2ojuPt ANgUhsOE8nPzzZCG431P73RIPfT+NRm2uXFc3+xSiFlSxu0fYPU+idJyLwXBQNdjMfIzVNe0rL==< /ds:x509certificate> </ds:x509data> </ds:keyinfo> <xenc:cipherdata> <xenc:ciphervalue>ljgzdalm3g3apxzidhkxpicngwreoxungo7ye5hveqzfhthfd2hwx4cvzo Br7/uBcMJhs3nOVdcw kbkbflzfoofzgcglpjqblzlofimv+sionqd721r1iu7utuhmww6ntbdyhjvtobtgrzrcdmh58ta1 XSJeM9lbcBJUuiQWuBU=</xenc:CipherValue> </xenc:cipherdata> </xenc:encryptedkey> </ds:keyinfo> <xenc:cipherdata> <xenc:cipherreference URI="cid:osci_enc"> <xenc:transforms> <ds:transform Algorithm=" </xenc:transforms> </xenc:cipherreference> </xenc:cipherdata> </xenc:encrypteddata> MIME_boundary

34 Content-Type: text/base64 Content-Transfer-Encoding: 8bit Content-ID: <osci_enc> xkgkre3vyserh4huqifyntbcjhyvpwz7rvywrkf8/cirklw1w6gvlookbaq1auhgsx9zbxx8fi0j LyXgufBGRih3qTgK9pYjRAiODw== MIME_boundary Quelltext 7: Beispiel für ein verschlüsseltes XML-Dokument Das Beispiel in Quelltext 7 repräsentiert die Elemente, die für eine XML-Verschlüsselung notwendig sind. Das MIME-Attachment osci_enc symbolisiert die verschlüsselte Nachricht. Im Element xenc: CipherReference wird mittels cid:osci_enc referenziert. Im Element xenc: EncryptedData/xenc:EncryptionMethod wird definiert, dass die Daten mittels verschlüsselt werden. Dazu wird ein tripledes-cbc als symmetrische Verschlüsselung verwendet. Durch das Element xenc: EncryptedKey/xenc:EncryptionMethod wird der Verschlüsselungsalgorithmus für den symmetrischen Schlüssel definiert. In diesem konkreten Fall wird ein PKCS#1-V1.5 verwendet. PKCS#1 definiert die Verschlüsselung mittels öffentlichem Schlüssel, d.h. der symmetrische Schlüssel wird mit dem öffentlichen Schlüssel verschlüsselt. Eine solche Verschlüsselung kann nur mit dem passenden privaten Schlüssel entschlüsselt werden, d.h. es kann nur genau jene Person den symmetrischen Schlüssel wiederherstellen, die den privaten Schlüssel besitzt. Warum braucht man zwei Verschlüsselungsmethoden? Auch wenn asymmetrische Methoden sicher sind, so haben sie einen erheblichen Performancenachteil. Aus diesem Grund benutzt man performante symmetrische Algorithmen zum Verschlüsseln von großen Datenmengen und verschlüsselt nur den symmetrischen Schlüssel mit Hilfe eines asymmetrischen Algorithmus. Damit macht man sich die Vorteile beider Methoden zu Nutze. Es wird die Performance der symmetrischen und die Sicherheit der asymmetrischen Algorithmen ausgenutzt.

35 2. Allgemeines 2.3 Technologien und Standards 33 Kryptographie PKCS #1 PKCS#1 beschreibt eine Methode zum Verschlüsseln von Daten mit Hilfe von öffentlichen Schlüsseln. PKCS#1 wird für das Erzeugen digitaler Signaturen und digitaler Hüllen, wie sie durch PKCS#7 beschrieben sind, verwendet. Digitale Signaturen Für digitale Signaturen wird der binäre Strom, der signiert werden soll, zuerst auf einen Digest mit Hilfe eines Digest-Algorithmus wie MD5 reduziert und anschließend mit dem privaten RSA-Schlüssel verschlüsselt. Der eigentliche binäre Strom zusammen mit dem verschlüsselten Digest bilden eine digitale Signatur im Sinne von PKCS#7. Digitale Hüllen Bei der Verwendung von digitalen Hüllen wird zunächst der binäre Strom mit einem einmaligen Schlüssel verschlüsselt, wobei ein symmetrischer Verschlüsselungsalgorithmus wie DES zur Anwendung kommt. Anschließend wird der Verschlüsselungsschlüssel mit dem öffentlichen RSA-Schlüssel verschlüsselt. Der verschlüsselte Inhalt und der verschlüsselte Verschlüsselungsschlüssel bilden gemeinsam die digitale Hülle im Sinne von PKCS#7. Konkret wird eine digitale Hülle in der XML-Encryption [XMLENC02] eingesetzt. PKCS #7 PKCS#7 ist eine generische Syntax für binäre Daten, bei denen kryptographische Methoden angewendet worden sind, wie beispielsweise Signaturen.

36 PKCS#7 erlaubt Rekursionen, wie beispielsweise verschachtelte Signaturen (Counter Signatures). PKCS#7 wird auch mit S/MIME in Verbindung gebracht. Wo ist die Beziehung? Bei einer signierten wird der signierte MIME-Part durch ein PKCS#7-Objekt repräsentiert. PKCS #12 PKCS#12 ist eine ASN.1-Syntax, mit der es möglich ist, Informationen über die persönliche Identität auf sichere Weise zu transportieren. Die Sicherung erfolgt über eine PIN. Konkret kann man PKCS#12 zum sicheren Transport von Schlüsselpaaren nutzen. Der Zugriff auf den privaten Schlüssel wird nur durch die richtige PIN gewährt. PKCS#12-Zertifikate kommen sowohl im Bereich des OSCI-Protokolles als auch im Bereich der Serversignatur zum Einsatz. Certificate Revocation List (CRL) Jeder Zertifikatsdiensteanbieter muss zumindest die Möglichkeit der Abfrage von Sperrlisten (= CRL) zur Verfügung stellen. Eine CRL, wie in Abbildung 5 dargestellt, listet alle Zertifikate auf, die gesperrt worden sind. Für jedes Zertifikat, das gesperrt worden ist, sind folgende Daten aufgezeichnet: Seriennummer Zeitpunkt Grund Abbildung 5 zeigt weiters, dass diese konkrete CRL List alle zwei Stunden aktualisiert wird (siehe Attribut Next update ). Die Zeitspanne zwischen zwei Aktualisierungen liegt im Ermessen des Zertifikatsdiensteanbieters, jedoch sollte sie möglichst kurz sein. Bei jeder Signaturprüfung ist die CRL vom Zertifikatsdiensteanbieter abzuholen und zu überprüfen, ob die Seriennummer des Signaturzertifikates in der Sperrliste enthalten ist. Wenn die

37 2. Allgemeines 2.3 Technologien und Standards 35 Abbildung 5 Certificate Revocation List Seriennummer enthalten ist, gilt die Signatur als ungültig, sofern das Zertifikat zum Zeitpunkt der Signatur gesperrt war. Kann eine CRL nicht abgeholt werden, kann nicht schlüssig entschieden werden, ob nun eine digitale Signatur zu einem bestimmten Zeitpunkt gültig war. Eine Signatur ist nur dann gültig, wenn das Zertifikat zum Zeitpunkt der Unterschrift gültig, also nicht zurückgezogen war. Wie weiß man nun, woher man die Certificate Revocation List bekommt? Abbildung 6 zeigt, dass in jedem Zertifikat ein Attribut CRL Distribution Points enthalten ist, das angibt, woher die Certificate Revocation List abzuholen ist. In diesem Fall ist die CRL durch eine LDAP-Anfrage abholbar.

38 Abbildung 6 CRL Distribution Points Bei dieser Methode muss die aktuelle CRL regelmäßig abgeholt werden, wobei die Größe einer CRL nicht zu unterschätzen ist. Alternativ kann zur Prüfung, ob ein Zertifikat nicht zurückgezogen worden ist, OCSP (siehe Abschnitt OCSP) verwendet werden. Ob OCSP durch den Zertifikatediensteanbieter zur Verfügung gestellt wird, liegt in dessen Ermessen. Gegenwärtig ist OCSP noch relativ wenig verbreitet. Zeitstempel Für das Erzeugen eines Zeitstempels im Sinne des RFC 3161 (= TSP-Protokoll) ist eine TSA (= Timestamp-Authority) erforderlich. Die Aufgabe einer TSA ist es, einen Nachweis zu erbringen, dass eine Menge von Daten (Hash über eine Menge von Daten) zum Zeitpunkt der Aktivierung des Zeitstempels existiert hat.

39 2. Allgemeines 2.3 Technologien und Standards 37 Abbildung 7 Erstellung eines Zeitstempels Die TSA hat jede Anfrage zu signieren. Für die Signatur ist ein Schlüssel mit einem besonderen Verwendungszweck notwendig. Es kann also nicht mit jedem Schlüssel signiert werden. Ein Client überträgt nicht den ganzen Inhalt an die TSA, sondern nur einen Hash, der mit einer Hashfunktion erzeugt wird, die unidirektional und unempfindlich auf Kollision ist. Als solche Hash-Algorithmen kommen MD5 oder SHA-1 in Frage. Eine TSA ist nicht verpflichtet, jeden Hashalgorithmus zu unterstützen. Die TSA kann für sich entscheiden, welche Hashalgorithmen sie als sicher einstuft und verwenden will. Dieser Umstand ist bei der Implementierung eines TSP-Clients zu berücksichtigen. Die TSA hat auf den Umstand der Nichtakzeptanz von Hashalgorithmen durch eine entsprechende Fehlermeldung hinzuweisen. Das Ergebnis eines Zeitstempels ist ein von der TSA signiertes Dokument, das sowohl die Signatur als auch gesicherte Information über den Zeitpunkt der Signatur enthält. Als Zeitpunkt gilt hier GMT-Time oder Zulu-Zeit.

40 Da die TSA den Hash signiert, wird die Authentizität des Hashes durch die TSA bescheinigt. Der RFC definiert keinen Transport, sondern bietet mehrere Möglichkeiten an: dateibasiert Socket (Port: 318) HTTP Auch wenn der RFC keinen vorrangigen Transport definiert, so hat sich HTTP als Transport etabliert. Verzeichnisdienst LDAP Lightweight Directory Access Protocol (LDAP) ist durch den RFC 1777 definiert. Es handelt sich dabei um ein TCPbasiertes Nachrichtenprotokoll für den Zugriff auf ein X.500-Verzeichnis. Ein X.500-Verzeichnis ist hierarchisch angeordnet. Es existiert eine Wurzel, die durch ihre RootDN beschrieben wird. Jeder Knoten, also auch die Wurzel, kann Kinder haben, wobei jedes Kind durch ihren DN (= Distinguished Name) eindeutig beschrieben ist. Jeder dieser Knoten kann durch Daten näher beschrieben werden und ist einer Klasse zugeordnet, wie beispielsweise top. Jede Klasse ist wiederum durch ihre Attribute beschrieben, wie beispielsweise cn, sn. Attribute können sowohl rein textuelle als auch binäre Werte annehmen. Abbildung 8 zeigt einen konkreten Eintrag einer natürlichen Person bei der A-Trust. Im linken Teil der Abbildung findet sich das Ergebnis einer Abfrage mittels Webinterface bei der A-Trust wieder ( &givenname=&dir=f&cn=&cin=&sm=suche%20namen&ch=15&lang=ge&mch=4). Im rechten Teil der Abbildung sind die konkret gespeicherten Daten zu sehen (ldap://ldap.a-trust.at: 389/eidcertificateserialnumber=61741,ou=a-sign-Premium-Enc01,o= ATrust,c=AT??base?(cn=*christian kastner*)).

41 2. Allgemeines 2.3 Technologien und Standards 39 Abbildung 8 LDAP-Eintrag LDAP-Verzeichnisse werden vor allem zum Speichern von Benutzerdaten verwendet und sind auf große Datenmengen ausgelegt. Sie kommen auch bei der Zustellung zum Einsatz. Dabei werden alle für die Abfragen des Zustellkopfes notwendigen Daten gespeichert. Ein LDAP-Verzeichnis kann mit Hilfe einer speziellen Abfragesprache abgefragt werden. Sie orientiert sich am Aufbau des Verzeichnisses und erlaubt die Attribute einzuschränken und durch Operatoren zu verknüpfen. OCSP Das Online Certificate Status Protocol (OCSP) [RFC2560] bietet einer Anwendung die Möglichkeit, online zu überprüfen, ob ein Zertifikat zurückgezogen wurde. Im Gegensatz zum Überprüfen einer CRL muss nicht die ganze Information auf den Client geholt werden. Vielmehr kann ein OCSP-Client gezielt Statusinformation zu einer kleinen Menge an Zertifikaten anfordern. Das Zertifikat definiert, woher Sperrlisten bzw. wohin OCSP-Anfragen zu stellen sind.

42 Zusammenfassung Abbildung 9 Allgemeines

43 2. Allgemeines 2.3 Technologien und Standards 41

44

45 43 3 Konzept: ZUSE Das Konzept ZUSE wurde von der Stabsstelle IKT-Strategie des Bundes definiert. Es umfasst sowohl die Bereiche der Zustellung als auch die Erstellung von Bescheiden. Dieses Konzept definiert die rechtssichere Zustellung für Österreich. Dies gilt auch für alle relevanten gesetzlichen Grundlagen, auf die in diesem Kapitel Bezug genommen wird. 3.1 Use Cases Die elektronische Zustellung wird im Backoffice der Behörde/Dienststelle im Zuge der Abfertigung ausgelöst. Eine elektronische Zustellung, wie in Abbildung 10 dargestellt, gliedert sich in folgende Teilschritte: Anfrage beim Zustellkopf Erstellen und Versenden des Zustellstückes Annahme des Zustellstückes durch den Zustelldienst Verständigung der Natürlichen/Juristischen Person Identifikation der Natürlichen/Juristischen Person Abholen des Zustellstückes Versenden des Zustellnachweises. Anfrage beim Zustellkopf Eine Natürliche/Juristische Person kann sich beim Zustelldienst ihres Vertrauens registrieren. Es ist zulässig, dass eine Natürliche/Juristische Person bei mehr als einem Zustelldienst registriert ist. Der Zustellkopf kennt alle akkreditierten Zustelldienste. Er befragt die Verzeichnisdienste der bekannten Zustelldienste nach den angefragten Natürlichen/Juristischen Personen und liefert die kumulierten Teilergebnisse der einzelnen Zustelldienste.

46 Abbildung 10 Zustellprozess Kann eine Person keinem Zustelldienst zugeordnet werden, so kann die Anwendung für diese Person keine elektronische Zustellung einleiten. Die Behörde ist gezwungen, auf postalischem Weg zuzustellen. Im Abschnitt 3.3 wird auf den Komplex Zustellkopf detailliert eingegangen. Erstellen und Versenden des Zustellstückes Damit einem beliebigen Zustelldienst, der die ZUSE-Spezifikation unterstützt, ein Zustellstück übermittelt werden kann, muss die Anwendung ein Zustellstück erzeugen, welches der Zustelldienst verstehen kann. Das Zustellstück gliedert sich in zwei Teile: die Metadaten, wie Absender und Empfänger, und das eigentliche Schriftstück. Das Schriftstück wird durch einen beliebigen Inhalt oder durch die XML-Bescheidstruktur repräsentiert.

47 3. Konzept: ZUSE 3.1 Use-Cases 45 Im Falle einer XML-Bescheidstruktur muss diese elektronisch signiert worden sein, um die formalen Anforderungen des 19 E-Government-Gesetzes [EGovG04] zu erfüllen. Wenn von der Natürlichen/Juristischen Person ein Verschlüsselungszertifikat bei der Registrierung beim Zustelldienst angegeben wurde, so ist die Anwendung verpflichtet, das Schriftstück zu verschlüsseln. Im Abschnitt 3.5 wird auf die XML-Bescheidstruktur genauer eingegangen. Wird die XML-Bescheidstruktur verwendet, kann das Schriftstück in alternativen Formaten wie beispielsweise PDF übermittelt werden. Die elektronische Signatur im Sinne des 19 E-Government-Gesetzes [egovg04] ist dabei entsprechend zu visualisieren. Sowohl für die XML-Bescheidstruktur als auch für die Amtssignatur im Sinne des 19 E-Government-Gesetzes [EGovG04] wurden entsprechende Richtlinien von der Stabsstelle IKT-Strategie des Bundes erlassen. Das elektronische Zustellstück wird jenem Zustelldienst zur weiteren Bearbeitung übergeben, bei dem der Adressat gemeldet ist. Die Versendung erfolgt mittels synchroner SwA-Anfrage. Wie weiß die Anwendung, wohin sie das Zustellstück senden muss? Diese Information liefert der Zustellkopf bei der Anfrage für eine Natürliche/Juristische Person. Annahme des Zustellstückes durch den Zustelldienst Der Zustelldienst hat das Zustellstück auf seine formale Korrektheit zu prüfen. Er muss demnach prüfen, ob eine Natürliche/Juristische Person registriert ist Natürliche/Juristische Person nicht abwesend ist Kann die formale Prüfung nicht erfolgreich abgeschlossen werden, so ist das Zustellstück zurückzuweisen. Insbesondere ist für den Zustelldienst wichtig, die Abwesenheit des Empfängers zu prüfen. Würde diese Tatsache ignoriert werden, so würde 34 Abs. 4 Zustellgesetz [ZustG82] zur Anwendung kommen. Die Zustellung wird in diesem Fall erst an dem der Rückkehr an die Abgabestelle folgenden Tag wirksam.

48 Verständigung der Natürlichen/Juristischen Person Kann die formale Prüfung erfolgreich abgeschlossen werden, so hat der Zustelldienst das Zustellstück zu speichern und muss die Natürliche/Juristische Person von der Existenz neuer Zustellstücke mittels elektronischer Benachrichtigung wie SMS und/oder oder auf postalischem Wege in Kenntnis setzen. Diese Verständigung teilt ausschließlich mit, dass neue Zustellstücke zur Abholung bereit sind. Dies kann mit der üblichen gelben Benachrichtigung auf Papier verglichen werden. Das Zustellstück wird nicht postalisch versandt. Im Falle einer RSx-Zustellung gilt implizit, dass zweimal elektronisch und einmal postalisch benachrichtigt werden muss. Im Falle einer Nicht-RSx-Zustellung definiert die absendende Organisation die Anzahl und Art der Benachrichtigungen. Sobald das Zustellstück im "Verfügungsbereich", also im Postfach, eintrifft, gilt das Zustellstück als zugestellt. Identifikation der Natürlichen/Juristischen Person Gemäß 35 Abs. 1 Zustellgesetz [ZustG82], Die elektronische Abholung des bereitgehaltenen Dokuments ist nur einem Betroffenen zu ermöglichen, der sich als Empfänger bei der Abholung mit Hilfe der Bürgerkarte eindeutig identifiziert und authentifiziert hat., darf nur die berechtigte Natürliche/Juristische Person den Zugang zum Postfach erhalten. Für die Prüfung der Identität und zur Authentifizierung kann das MOA-Modul MOA-ID verwendet werden. Dies wird später noch detailliert erläutert. Abholen des Zustellstückes War die Natürliche/Juristische Person in der Lage, ihre Identität gegenüber dem Zustelldienst nachzuweisen, kann sie die neuen Zustellstücke einsehen und per weiterleiten oder auf den lokalen Arbeitsplatz herunterladen.

49 3. Konzept: ZUSE 3.1 Use-Cases 47 Versenden von Zustellnachweisen Wie in 35 Abs. 2-3 Zustellgesetz [ZustG82] definiert, (2) Hat die Behörde die elektronische Zustellung mit Zustellnachweis angeordnet, so wird dieser Nachweis durch die elektronische Signatur des Empfängers beim Abholvorgang erbracht. An die Stelle der sicheren elektronischen Signatur darf aufgrund besonderer Vereinbarung mit dem Zustelldienst eine an die Verwendung sicherer Technik gebundene automatisiert ausgelöste Signatur treten. Der Zugriff auf das in der technischen Einrichtung hinterlegte Dokument ist dem Betroffenen erst nach Einlangen dieses Nachweises beim Zustelldienst zu ermöglichen. (3) Der Zustelldienst hat die eingegangenen Zustellnachweise zu protokollieren und die Information über die erfolgreiche Zustellung an die Auftrag gebende Behörde weiterzuleiten., wird nach einer erfolgreichen Identifizierung beim Zustelldienst die Annahme der Zustellstücke durch eine elektronische Signatur bestätigt. Im Rahmen des Logins wird ein Dokument unterschrieben, mit dem bestätigt wird, dass alle bis zu diesem Zeitpunkt eingelangten Schriftstücke angenommen wurden. Die auftraggebende Organisation (Behörde) wird durch einen positiven Zustellnachweis von der Abholung in Kenntnis gesetzt. Die auftraggebende Organisation muss zur automatisierten Annahme der Zustellnachweise ein SOAP-Webservice zur Verfügung stellen, das die Zustellnachweise entgegennimmt. Dieses SOAP-Webservice muss aus Sicht des Zustelldienstes im Internet erreichbar sein. Aufgrund sicherheitsrelevanter Aspekte kann das nur ein Satellit in der DMZ sein. Wie eine Anwendung mit Zustellnachweisen weiter verfährt, liegt in ihrem Ermessen. Die Anwendung wird die Zustellnachweise bei den entsprechenden Erledigungen ablegen. Wird das Zustellstück nicht innerhalb der Frist abgeholt, so wird ein negativer Zustellnachweis an die auftraggebende Organisation versendet. Die Handhabung negativer Zustellnachweise obliegt der Anwendung bzw. der auftraggebenden Organisation. Eine mögliche Reaktion auf eine solche Situation könnte eine erneute, aber postalische Abfertigung sein. Die rechtsverbindlichen Fristen laufen unabhängig davon, ob das Zustellstück vom Zustelldienst abgeholt wird, da die Zustellung als erwirkt gilt, sobald das Zustellstück im Verfügungsbereich des Zustelldienstes eintrifft, also sobald die erste Verständigung übermittelt wurde. Spätestens eine Woche nach Einlangen des Zustellstückes beim Zustelldienst fangen die rechtsverbindlichen Fristen an zu laufen.

50 Hat die Natürliche/Juristische Person ihre Abwesenheit deklariert, so soll der Zustelldienst das Zustellstück zurückweisen; schon alleine um einen etwaigen Zustellmangel im Sinne des 7 Zustellgesetzes [ZustG82] zu verhindern. Eine Anwendung darf nicht davon ausgehen, dass ein Zustelldienst diesen Umstand prüfen wird. Zusammenfassung Abbildung 11 ZUSE-Prozess

51 3. Konzept: ZUSE 3.1 Use-Cases 3.2 Infrastruktur Infrastruktur LDAP Jeder Zustelldienst hat einen Verzeichnisdienst in der Ausprägung eines LDAP-Services zu betreiben. In diesem Verzeichnis werden alle notwendigen Informationen nach einem definierten Schema abgelegt. Die gespeicherten Informationen werden vom Zustellkopf abgefragt, um entscheiden zu können, bei welchen Zustelldiensten eine Natürliche/Juristische Person angemeldet ist. Dieses LDAP-Service muss vom Zustellkopf erreichbar sein. Kann der Zustellkopf das LDAP-Service nicht erreichen, so kann er nicht entscheiden, ob eine bestimmte Natürliche/Juristische Person beim betroffenen Zustelldienst registriert ist. Warum muss ein LDAP-Service zur Verfügung gestellt werden? Alternative Abfragemethoden wären prinzipiell denkbar, aber es ist davon auszugehen, dass jegliche andere Methode ineffizient wäre. Wie aus Abbildung 12 ersichtlich, werden folgende Daten im LDAP-Verzeichnis aufgezeichnet: ZbPK (= gvzbpk) Name (= cn, sn, givenname) Geburtsdatum (= gvbirthdate) Anschrift (= street, l, c, postalcode) akzeptable Dateiformate (= gvacceptedformat) Abwesenheit (= gvabsentfrom, gvabsentutil) Verschlüsselungszertifikat (= usercertificate) Im LDAP-Verzeichnis werden somit alle notwendigen operativen Daten gespeichert. Eine Natürliche/Juristische Person wird anhand ihrer ZbPK identifiziert. Wofür steht ZbPK? Es ist dies das bereichsspezifische Personenkennzeichen [BerAbgrV04] für den Bereich Zustellung. Auffällig ist, dass neben normalen Personendaten auch persönliche Daten wie das Geburtsdatum gespeichert werden. Das Geburtsdatum ist für die RSx-Zustellungen