E-Government-Initiative für D und den Personalausweis

Transkript

1 E-Gvernment-Initiative für D und den Persnalausweis Krdinierungsstelle für das autmatisierte Mahnverfahren beim Justizministerium Baden-Württemberg Knzept: Einsatz vn eid und D im autmatisierten gerichtlichen Mahnverfahren Das Bundesministerium des Innern ist nicht verantwrtlich für den Inhalt der Ergebnisdkumente, die im Rahmen der E-Gvernment-Initiative für D und den Persnalausweis erstellt wurden. Deshalb werden die jeweils Verantwrtlichen im Impressum auf der letzten Seite der Dkumente genannt. Sie stehen Ihnen für inhaltliche Fragen zur Verfügung.

2 Einsatz vn eid und D im autmatisierten gerichtlichen Mahnverfahren Krdinierungsstelle für das autmatisierte Mahnverfahren beim Justizministerium Baden-Württemberg 02_knzept_eid_und_d _im_mahnverfahren_jum_bw.dcx 1/27

3 Inhaltsverzeichnis 1 Einführung und Zusammenfassung Nutzung der Online-Ausweisfunktin Anfrderungen an prttypische Umsetzung Infrastruktur-Erweiterungen des Online-Mahnverfahrens Ntwendige Anpassungen im Online-Mahnverfahren Umsetzungsknzept Technische Umsetzung Integratin des Gvernikus-Bürgerknts Zielarchitektur OMA mit Ablauf der Online-Ausweisfunktin Fachliche Umsetzung Nutzung vn D Grundlagen der D -Kmmunikatin D -Adressen und Accunts Bestätigungsnachrichten Zugriffsmöglichkeiten auf D -Knten Webbrwser D -Gateway OSCI-/D -Gateway Einsatz vn D im autmatisierten Mahnverfahren D -Adressen der Mahngerichte Architekturansätze Vraussetzungen und grundsätzlicher Przessablauf Empfhlene Variante: Standard-D -Gateway Alternativvariante 1: OSCI-/D -Gateway Alternativvariante 2: Spezielles D -Gateway für Mahnanträge _knzept_eid_und_d _im_mahnverfahren_jum_bw.dcx 2/27

4 Abbildungsverzeichnis Abbildung 1: Einbindung Persnalausweis in OMA-Architektur... 8 Abbildung 2: Auswahl einer Identifizierung mit der Online-Ausweisfunktin... 9 Abbildung 3: Hinweise zur Nutzung des Persnalausweises Abbildung 4: Weiterleitung zum Lgin des Bürgerknts Abbildung 5: Aufruf der AutentApp und Sicherheitshinweis Abbildung 6: Auswahl der zu übermittelnden Daten Abbildung 7: Rückübermittlung der Daten an das Online-Mahnverfahren Abbildung 8: Bestätigung des Antragversands Abbildung 9: Beispiel für die Nutzung der AusweisApp Abbildung 10: Anbindung über Standard-D -Gateway Abbildung 11: Anbindung über OSCI-/D -Gateway Abbildung 12: Anbindung über ein spezielles D -Gateway für Mahnanträge _knzept_eid_und_d _im_mahnverfahren_jum_bw.dcx 3/27

5 1 Einführung und Zusammenfassung Das Justizministerium Baden-Württemberg ist die bundesweit verantwrtliche Krdinierungsstelle für das autmatisierte Mahnverfahren. Alle 16 Bundesländer sind diesem bundesweit technisch einheitlichen Verfahren angeschlssen. Aufgrund der Neufassung vn 690 Abs. 3 ZPO zum müssen maschinell lesbare Anträge künftig nicht mehr unterschrieben sein, eine Authentifizierung mittels Online-Ausweisfunktin (eid-funktin des Persnalausweises) ist dann ausreichend. Diese zusätzliche Frm der Antragslegitimatin muss neben die vrhandenen Frmen (z.b. EGVP und qualifizierte elektrnische Signatur) gestellt und implementiert werden. Die Antragstellung vn Naturparteien (Bürgerinnen und Bürger swie Unternehmen mit eigenen Rechtsabteilungen) sll zukünftig mittels Online-Ausweisfunktin und D erflgen. Bundesweit werden durch Naturparteien ca. 1,8 Millinen Anträge pr Jahr gestellt. Das autmatisierte Mahnverfahren ist eine länderübergreifende Anwendung, s dass eine breite Nachnutzbarkeit in anderen Bundesländern gegeben ist. Die technische Einheitlichkeit begünstigt dies zusätzlich. Das hiermit vrgelegte Knzept beschreibt die Einführung der Online-Ausweisfunktin und vn D im zivilprzessualen Mahnverfahren. Die Integratin der Online-Ausweisfunktin in das Prtal zur Antragstellung im autmatisierten Mahnwesen (OMA) wird anhand einer prttypischen Umsetzung erläutert, die auf der CeBIT 2014 präsentiert wurde. Dabei werden swhl przessuale und rganisatrische als auch technische Aspekte betrachtet. Die Einbindung der Online-Ausweisfunktin in den Online-Mahnantrag erwies sich als technisch deutlich weniger aufwändig als zunächst befürchtet. Aus diesen sehr psitiven Erfahrungen resultierten Bestrebungen, die Nutzung der Online-Ausweisfunktin im autmatisierten Mahnverfahren früher als geplant zuzulassen. Zum besseren Verständnis der Nutzung vn D im autmatisierten Mahnverfahren werden zunächst einige Grundlagen der D -Kmmunikatin erläutert. Danach werden drei Architekturansätze vrgestellt und hinsichtlich ihrer Vr- und Nachteile bewertet. Sie unterscheiden sich im Wesentlichen dadurch, dass unterschiedliche D -Gateways zum Einsatz kmmen. Gegenwärtig ist nch nicht entschieden, welche Optin in welchem zeitlichen Rahmen umgesetzt werden sll. Das vrliegende Knzept wurde gemeinsam vn dem Justizministerium Baden-Württemberg und dem Pilt-Amtsgericht Hagen mit Unterstützung der E-Gvernment-Initiative des Bundesministerium des Innern (BMI) heraus erstellt. 02_knzept_eid_und_d _im_mahnverfahren_jum_bw.dcx 4/27

6 2 Nutzung der Online-Ausweisfunktin Die flgende Knzeptin der Integratin der Online-Ausweisfunktin des Persnalauseises in das bereits bestehende Prtal zur Antragstellung im autmatisierten Mahnverfahren ( ist aufgrund Neufassung 690 Abs. 3 ZPO bis zu realisieren. Im Rahmen dieses Knzepts wird die Umsetzung eines ersten Prttyps beschrieben, der auf der Cebit 2014 präsentiert wurde. Die Aufnahme des Prduktivbetriebs wird, wie gesetzlich zulässig, zum erflgen. Derzeit bestehen Bemühungen, Persnalausweis und elektrnischen Aufenthaltstitel schn zu einem früheren Zeitpunkt einsetzen zu können. Das Knzept zeigt unter anderem, welche Mittel ntwendig sind, um die Online- Ausweisfunktin in Testumgebungen zu nutzen. 2.1 Anfrderungen an prttypische Umsetzung Die flgenden Anfrderungen beziehen sich auf eine nicht prduktive Unterstützung des Persnalausweises in der sgenannten Test-Public Key Infrastructure (Test-PKI) Infrastruktur-Erweiterungen des Online-Mahnverfahrens Für die Nutzung der Online-Ausweisfunktin im autmatisierten Mahnverfahren sind flgende Infrastrukturerweiterungen erfrderlich: - Zur Autrisierung des Auslesevrgangs in der Test-PKI ist die Bereitstellung eines Berechtigungszertifikats in der Test-PKI ntwendig. Im Chip des Persnalausweises ist das Wurzel-(Rt-)Zertifikat der EAC-Public Key Infrastructure (EAC-PKI) gespeichert. Damit ist der Persnalausweis in der Lage zu überprüfen, b die ihm präsentierten Zertifikate echt sind. - Zum Übermitteln der Daten aus dem Persnalausweis ist die Bereitstellung eines eid-servers und die Einbindung des erfrderlichen Test-Berechtigungszertifikats ntwendig. Ein eid-server ermöglicht es Diensteanbietern, die Online- Ausweisfunktin in ihre bereits existierenden IT-Systeme einzubinden. Der eid- Server übernimmt die elektrnische Kmmunikatin zwischen dem Online-Angebt der Behörde und dem Persnalausweis der Bürgerin der des Bürgers. Das heißt, er übernimmt die sichere Kmmunikatin mit der Client-Sftware (z.b. AusweisApp) und dem Persnalausweis-Chip und gibt ausgelesene Daten an den Dienst weiter. - Für Test und Demnstratin der Anwendung ist die Bereitstellung vn Persnalausweisen der Test-PKI ntwendig Ntwendige Anpassungen im Online-Mahnverfahren Für die Nutzung der Online-Ausweisfunktin sind flgende Anpassungen im Online- Mahnverfahren erfrderlich: - Beim Start der Anwendung wird die Auswahl des Authentifizierungsverfahrens getrffen. Hier muss eine neue Optin zur Auswahl der Online-Ausweisfunktin des Persnalausweises der des Elektrnischen Aufenthaltstitels ergänzt werden. - Das bestehende Online-Mahnverfahren nutzt die qualifizierte elektrnische Signatur. Im Fall einer Authentifizierung mit der Online-Ausweisfunktin muss anstatt der Mas- 02_knzept_eid_und_d _im_mahnverfahren_jum_bw.dcx 5/27

7 ke Drucken/Signieren eine neue Webseite ergänzt werden, die die Identifikatin mit der Online-Ausweisfunktin aufruft. - Das Mahnverfahren wird um eine Kmpnente erweitert, die die Kmmunikatin mit dem eid-server übernimmt. Die Persnalausweis-Daten selbst werden dem Server übermittelt und dann über eine Schnittstelle dem Mahnverfahren zur Verfügung gestellt. Für den Zugriff stellt der eid-service-prvider eine Java-Prgrammbiblithek zur Verfügung - Die Verbindung zwischen eid-server und OMA muss mit einem zu erstellenden SSL- Zertifikat abgesichert werden. Dieses Zertifikat wird dann in den eid-hilfsbiblitheken knfiguriert. Die Erstellung des Zertifikats ist in der Dkumentatin des eid-server Prviders beschrieben. - Es muss eine Auswahl der zu nutzenden Schnittstelle zum eid-server getrffen werden, z.b. SAML, WebService, eid-biblithek der Bürgerknt-Schnittstelle(siehe auch Kapitel ). - Der aus dem Persnalausweis übermittelte Datensatz muss zum (ggf. erfrderlichen) Nachweis der Identifikatin im Vrgang gespeichert werden. - Bei Persnalausweis-Nutzung sll zur Übermittlung der Daten aus OMA ein Enterprise EGVP 1 mit synchrnem Nachrichtenversand verwendet werden. Das Enterprise EGVP schickt den Antrag des Nutzers selbstständig weiter, hne dass der Nutzer ein EGVP installieren muss. Durch die synchrne Nachrichtenübermittlung kann dem Nutzer die Übermittlung direkt bestätigt werden - evtl. durch eine zusätzliche Maske in OMA. 2.2 Umsetzungsknzept Das flgende Kapitel beschreibt die fachliche und technische Umsetzung im erstellten Prttyp Technische Umsetzung Zur Kmmunikatin mit dem eid-server kann der SAML-Standard- der eine Web-Service- Schnittstelle verwendet werden. Diese Schnittstellen sind in der technischen Richtlinie TR spezifiziert. Zusätzlich bieten ID-Server-Prvider die Nutzung eigener Abstraktinsschichten(z.B. Bürgerknten) an. Im Fall des Online-Mahnantrags wurde das Gvernikus- Bürgerknt zur Vereinfachung der Kmmunikatin mit dem eid-server genutzt. Das Bürgerknt nutzt nur ein Berechtigungszertifikat und bindet Fachverfahren über eine Mandanten-ID an das System an. Für die Fachverfahren (in diesem Fall OMA) bringt dies den Vrteil, dass ein einfacher Zugriff auf die Online-Ausweisfunktin möglich ist, hne Schnittstellen zum eid-server direkt bedienen zu müssen. 1 Ein Enterprise EGVP stellt eine serverseitige Variante des EGVP dar. Dies ermöglicht einen Versand vn EGVP Nachrichten auf Serverseite hne das ein Nutzer einen EGVP Client installieren muss. 2 Siehe 02_knzept_eid_und_d _im_mahnverfahren_jum_bw.dcx 6/27

8 Über klar definierte Schnittstellen können Anwendungen die zum Auslesen der Daten eingesetzten Applikatinen AusweisApp bzw. AutentApp aufrufen. Die dazu ntwendigen technischen Abstimmungen knnten mit wenigen telefnischen Absprachen erledigt werden. Danach ist es allein Sache der rufenden Anwendung, wie sie mit den bereitgestellten Persnalausweis-Daten umgeht Integratin des Gvernikus-Bürgerknts Das Gvernikus-Bürgerknt frdert die Übermittlung vn Vrnamen, Nachname, Geburtsdatum und Adresse vm Persnalausweis an. Andere Ausweisdaten werden über das Bürgerknt nicht unterstützt. Diese Daten genügen für die im Mahnverfahren an dieser Stelle nötigen Prüfungen (Identität und Przessfähigkeit). Zurzeit unterstützt das Test-Bürgerknt die Gvernikus AutentApp und die AusweisApp. Die AusweisApp wird aktuell nur vn den neueren Versinen des Micrsft Internet Explrers unterstützt. Die Kmmunikatin zum Bürgerknt basiert auf einer Ausprägung des HTTPS-Prtklls. Anfragen an das Bürgerknt werden als HTTP-GET der HTTP-Pst aus OMA an das Bürgerknt geschickt. Die HTTP Anfrage ist parametrisierbar (z.b. um Festzulegen welche Daten aus dem Persnalausweis ausgelesen werden) und wird verschlüsselt. Beim Aufruf wird der Nutzer an das EntranceServlet des Bürgerknts weitergeleitet. In der Aufruf URL sind Parameter wie z.b. die Mandanten-Id enthalten. Nach erflgreicher Analyse der übergebenen Parameter wird der Nutzer an eine Webseite des Bürgerknts weitergeleitet auf der die Entscheidung bzgl. Nutzung vn AusweisApp der Gvernikus AutentApp getrffen wird. Die Kmmunikatin mit dem eid-server wird vm Bürgerknt übernmmen. Nach dem Auslesevrgang wird der Nutzer zurück zu OMA geleitet. Die mit der Online- Ausweisfunktin ausgelesenen Daten werden als verschlüsselter String per HTTP Pst an OMA zurückgegeben Zielarchitektur OMA mit Ablauf der Online-Ausweisfunktin Die OMA-Zielarchitektur stellt sich unter Nutzung der Online-Ausweisfunktin wie flgt dar: 02_knzept_eid_und_d _im_mahnverfahren_jum_bw.dcx 7/27

9 EGVP Intermediär Gericht mit Online Ausweisfunktin OMA PA Biblithek 10 Enterprise EGVP Intermediär mit Online Ausweisfunktin Gericht 3 Bürger Bürgerknt 7 4 eid- Server Ablaufbeschreibung Abbildung 1: Einbindung Persnalausweis in OMA-Architektur 1. Der Nutzer ruft den Online-Mahnantrag auf und wählt nach Antragsdatenerstellung die Übermittlungsptin PA/eAT. 2. Der Online-Mahnantrag erstellt einen HTTP Request mit Parametern für das Bürgerknt (u.a. Mandantennummer, SPData, URL für Rückgabe der Daten) und antwrtet dem Brwser des Nutzers mit einem Redirect auf das EntranceServlet des Bürgerknts. Der Online-Mahnantrag gibt damit die Steuerung an das Bürgerknt ab. 3. Der Brwser des Nutzers führt einen Redirect auf das Bürgerknt durch und wartet auf Antwrt 4. Das Bürgerknt erzeugt eine Sessin im eid-server 5. Das Bürgerknt bietet dem Nutzer die Auswahl zwischen AusweisApp und AutentApp an 6. Die AutentApp der die AusweisApp, frdert Name, Adresse und Geburtsdatum des Nutzers an. Der Nutzer kmmuniziert nun über den eid-client direkt mit eid-server. Der Brwser des Nutzers wartet in dieser Zeit auf Antwrt vm Bürgerknt. Die Kmmunikatin mit dem eid-server entspricht der Beschreibung aus der Technischen Richtlinie TR-3130 des BSI. 02_knzept_eid_und_d _im_mahnverfahren_jum_bw.dcx 8/27

10 7. Die Nutzung der Online-Ausweisfunktin ist abgeschlssen. Das Bürgerknt hlt die Antwrt vm eid-server ab. 8. Bürgerknt schickt Redirect mit verschlüsselter Antwrt des eid-servers an Brwser des Nutzers zurück 9. Redirect des Brwser des Nutzers zum Online-Mahnantrag zurück 10. Bestätigt der Nutzer, werden die Daten in die Schnittstelle zur weiteren Verarbeitung bei Gericht übernmmen. Zur Übermittlung der ergänzten Antragsdaten wird eine unsignierte EGVP-Nachricht erzeugt, die synchrn an das elektrnische Pstfach des empfangenden Gerichts übermittelt wird. 11. Durch die synchrne Nachrichtenübermittlung kann dem Nutzer die Übermittlung direkt bestätigt werden. Der Vrgang ist abgeschlssen. OMA kann auch auf gewhntem Weg hne eid-nutzung verwendet werden. In diesem Fall wird zur Antragslegitimatin, die hier nicht weiter beschriebene Verwendung vn EGVP mit qualifizierter elektrnischer Signatur angebten Fachliche Umsetzung Die flgende Beschreibung bezieht sich nur auf die Testanwendung des Online- Mahnantrags. Der Prttyp führt auf Online-Mahnantrag-Seite keinerlei Plausibilisierung der Daten durch. Die Nutzung der eid-funktin des Persnalausweises kann s auch hne jegliche Antragsdaten vrgeführt werden. Auch die übermittelten Ausweisdaten werden nicht plausibilisiert. Das Online-Mahnverfahren bietet auf der Maske Drucken/Signieren nun zusätzlich die Auswahl der Onlinefunktin des Persnalausweises. Abbildung 2: Auswahl einer Identifizierung mit der Online-Ausweisfunktin Es flgen Hinweise zur Nutzung der Online-Funktin (Kartenleser betriebsbereit, Persnalausweis aufgelegt). 02_knzept_eid_und_d _im_mahnverfahren_jum_bw.dcx 9/27

11 Abbildung 3: Hinweise zur Nutzung des Persnalausweises Durch Auswahl des Buttns übertragen wird die Identifikatin mit der Online Ausweisfunktin angestßen. Der Nutzer wird dazu auf die Webseite des genutzten temprären Bürgerknts weitergeleitet. Nach Abschluss des Auslesevrgangs werden die Daten im Hintergrund an die Anwendung übermittelt und der Nutzer autmatisch zurück in das Online- Mahnverfahren geleitet. Das tempräre Bürgerknt ermöglicht eine einfache Nutzung der Online-Ausweisunktin hne Aufruf der kmplexen SAML- der Web-Service-Schnittstellen. Abbildung 4: Weiterleitung zum Lgin des Bürgerknts Das Bürgerknt überlässt dem Nutzer die Entscheidung, b er die AutentApp der die AusweisApp zum Auslesen der Daten aus dem Persnalausweis nutzen möchte. Wird die AutentApp gewählt, s wird ein Java Applet zum Auslesen der Daten geladen. 02_knzept_eid_und_d _im_mahnverfahren_jum_bw.dcx 10/27

12 Abbildung 5: Aufruf der AutentApp und Sicherheitshinweis Das Bürgerknt liest Vrname(n), Name, Anschrift und Geburtstag aus dem Persnalausweis aus. Je nach Kartenlesegerät kann die PIN auf dem Bildschirm der auf der Tastatur des Kartenlesegeräts eingegeben werden. 02_knzept_eid_und_d _im_mahnverfahren_jum_bw.dcx 11/27

13 Abbildung 6: Auswahl der zu übermittelnden Daten Das Gvernikus-Bürgerknt übergibt die übermittelten Daten per Umleitung zurück an den Online-Mahnantrag. Im Online-Mahnantrag werden die Daten aus dem Persnalausweis übernmmen und zur Bestätigung angezeigt. 02_knzept_eid_und_d _im_mahnverfahren_jum_bw.dcx 12/27

14 Abbildung 7: Rückübermittlung der Daten an das Online-Mahnverfahren Jetzt kann der Antrag versendet werden ( Versenden -Buttn). Der vm Bürgerknt übermittelte Datensatz muss gespeichert werden, um später die Nutzung der Online- Ausweisfunktin nachweisen zu können. Abbildung 8: Bestätigung des Antragversands 02_knzept_eid_und_d _im_mahnverfahren_jum_bw.dcx 13/27

15 Wählt der Nutzer bei Anmeldung am Bügerknt die AusweisApp zur Identifizerung aus, öffnet sich die flgende Bildschirmmaske. Abbildung 9: Beispiel für die Nutzung der AusweisApp 02_knzept_eid_und_d _im_mahnverfahren_jum_bw.dcx 14/27

16 3 Nutzung vn D Für die Nutzung vn D geht es zunächst darum, grundsätzliche Architektur- und rganisatrische Entscheidungen zu treffen. Die Verwendung vn D in weiteren Kmmunikatinsprzessen zwischen Antragsteller, Mahngericht und Antragsgegner ist grundsätzlich möglich, wird hier aber nicht betrachtet. 3.1 Grundlagen der D -Kmmunikatin D -Adressen und Accunts D -Adressen sind grundsätzlich wie -Adressen aufgebaut. Ihre Struktur richtet sich danach, b es sich um natürliche der juristische Persnen, Persnengesellschaften bzw. öffentliche Stellen handelt: Natürliche Persnen: - Struktur: Vrname.Nachname@D -Anbieter.d .de - Beispiel: franz.meier@gmx.d .de - Anmerkungen: Vrname kann abgekürzt werden. Falls Vrname.Nachname bereits vrhanden ist, kann eine Nummer angefügt werden. Grundsätzlich kann auch eine andere zugelassene D -Dmäne anstatt d .de verwendet werden (z.z. nicht üblich). Natürliche Persnen können auch Pseudnyme (mit dem Frmat pn_...@... ) verwenden. Juristische Persnen, Persnengesellschaften und öffentliche Stellen: - Struktur: beliebig@juristische-persn.d .de - Beispiel: mahngericht@ag-hagen.d .de - Anmerkungen: Als 3rd-Level-Dmain steht immer der D -Knt-Inhaber (im Beispiel: ag-hagen ), d.h. an der 3rd-Level-Dmain einer D -Adresse sll immer erkennbar sein, wer der Inhaber des D -Knts ist. Die Bezeichnung der 3rd-Level-Dmain einer juristischen Persn, Persnengesellschaft der öffentliche Stelle muss gemäß D -Gesetz immer in direktem Bezug zu ihrer Firma, Namen der snstiger Bezeichnung stehen. Vr kann eine beliebige Bezeichnung gewählt werden. Es können zusätzlich beliebige 4th- und 5th-Level-Dmains gewählt werden, z.b. mahnantrag@mahngericht.ag-hagen.d .de Grundsätzlich kann auch eine andere zugelassene D -Dmäne anstatt d .de verwendet werden (z.z. nicht üblich). Die vn D entfalteten Rechtswirkungen beziehen sich immer auf den D -Kntinhaber, als auf die als 3rd-Level-Dmain genannte Institutin. 02_knzept_eid_und_d _im_mahnverfahren_jum_bw.dcx 15/27

17 3.1.2 Bestätigungsnachrichten Beim Versand vn D s können auf Wunsch des Absenders Bestätigungsnachrichten angefrdert werden. Dabei handelt es sich um spezielle, vm D -Anbieter des Absenders der Empfängers qualifiziert elektrnisch signierte D s, die an den Absender und z.t. zusätzlich an den Empfänger geschickt werden. Flgende Bestätigungsnachrichten sind möglich: - Versandbestätigung Sie wird vm D -Anbieter des Absenders erstellt und an den Absender geschickt, sbald die D vm Absender-Prvider versendet wurde. - Eingangsbestätigung Sie wird vm D -Anbieter des Empfängers swhl an den Absender als auch an den Empfänger der D geschickt, sbald die zugehörige D in das D - Knt des Empfängers eingelegt wurde. - Abhlbestätigung Sie wird vm D -Anbieter des Empfängers swhl an den Absender als auch an den Empfänger der D geschickt, sbald die zugehörige D in das D - Knt des Empfängers eingelegt wurde und dieser sich (auf hhem Sicherheitsniveau) an seinem D -Knt angemeldet hat. Abhlbestätigungen dürfen nur vn öffentlichen Stellen angefrdert werden Zugriffsmöglichkeiten auf D -Knten Webbrwser Grundsätzlich kann jeder D -Nutzer per Webbrwser auf sein D -Knt zugreifen und s D s versenden und empfangen. Die Anmeldung am D -Knt kann auf nrmalem Sicherheitsniveau (Benutzerkennung + Kennwrt) der hhem Sicherheitsniveau (z.b. mittels SMS-TAN der Chipkarte) erflgen. Empfangene D s können exprtiert und s in anderen Systeme abgelegt und/der weiterverwendet werden. Bei Bedarf können im D -Knt sgenannte Unterknten mit eigenen D - Adressen und Zugangsdaten eingerichtet werden. Grundsätzlich ist es als möglich, dass ein Mahngericht auf sein D -(Unter-)Knt per Webbrwser zugreift. Damit sind die Möglichkeiten einer autmatisierten Bearbeitung eingegangener D s aber äußerst begrenzt D -Gateway In der Regel werden juristische Persnen und öffentliche Stellen D mittels D - Gateway nutzen. Das Gateway kann in unterschiedlicher Art und Weise eingesetzt werden: - Sftware, die vm D -Nutzer selbst installiert und betrieben wird - Hard-/Sftwaresystem (Appliance), das ebenfalls vm D -Nutzer selbst installiert und betrieben wird 02_knzept_eid_und_d _im_mahnverfahren_jum_bw.dcx 16/27

18 - System, das vm D -Anbieter betrieben und dem Nutzer zur Verfügung gestellt wird - System ( mandantenfähiges D -Gateway ), das vn einem Dritten betrieben und dem Nutzer zur Verfügung gestellt wird, z.b. durch ein kmmunales Rechenzentrum für die angeschlssenen Kmmunen der durch ein Landesrechenzentrum für alle Landesbehörden. Die gegenwärtig verfügbaren D -Gateways wandeln vereinfacht gesprchen De- Mails in s um und umgekehrt. Das D -Gateway ist auf der einen Seite mit dem D -Knt des jeweiligen Nutzers beim D -Anbieter verbunden. Die Verbindung ist verschlüsselt. Die Authentisierung des Gateways beim D -Anbieter erflgt auf hhem Sicherheitsniveau (i.d.r. mittels Chipkarte). Auf der anderen Seite ist das Gateway mit einem -/SMTP-Relay der -Server verbunden, an den die empfangenen D s ausgeliefert und vn dem die zu versendenden De- Mails 3 entgegengenmmen werden. Grundsätzlich erflgt der (einfache) Versand und Empfang vn D s über ein Gateway (mit angebundenem -Server) in flgenden Schritten: Versand einer D durch eine öffentliche Stelle (z.b. Amtsgericht): - Ein Sachbearbeiter erstellt in seinem -Client (z.b. Outlk, Thunderbird, Ntes) ggf. unter Verwendung eines entsprechenden D -Plugins.ä. eine Mail an eine D -Adresse und sendet diese ab. - Die Mail gelangt auf den -Server und wird drt anhand der Empfänger-Adresse als D identifiziert, z.b. anhand der Endung d .de. - Der -Server sendet die Mail (als D -Entwurf ) an das D -Gateway. - Das D -Gateway prüft zunächst anhand einer sg. Adress-Mapping-Tabelle, b der Absender überhaupt berechtigt ist, eine D zu versenden. Wenn ja, dann ändert es die Absenderadresse der Mail auf die gewünschte (neue) D - Absenderadresse, z.b. vn mahngericht@ag-hagen.de auf mahngericht@aghagen.d .de. - Das Gateway liefert die Mail an das D -Knt des Absenders (z.b. Amtsgericht Hagen) beim D -Anbieter aus. - Der D -Anbieter versieht die Mail mit der gesetzlichen Zeit, vergibt eine eindeutige ID und setzt weitere Sicherheitsmerkmale. Damit ist die Mail (D -Entwurf) eine (echte) D und kann an den Empfänger ausgeliefert werden. 3 Strenggenmmen handelt es sich hierbei nch nicht um D s, sndern um D -Entwürfe. Erst beim D -Anbieter werden bestimmte Header-Daten in der D gesetzt (z.b. Message-ID, Prüfsumme, gesetzliche Zeit usw.), wdurch der D -Entwurf zur (echten) D wird. 02_knzept_eid_und_d _im_mahnverfahren_jum_bw.dcx 17/27

19 Der Empfang einer D durch eine öffentliche Stelle (z.b. Amtsgericht) stellt sich ähnlich dar: - Die D trifft im D -Pstfach der öffentlichen Stelle beim D -Anbieter ein. - Das D -Gateway der öffentliche Stelle fragt in bestimmten Abständen beim Anbieter an, ab D s zur Abhlung bereit liegen. - Wenn ja, werden die D s an das Gateway übertragen. - Das Gateway prüft anhand der Adress-Mapping-Tabelle, auf welche (interne) - Adresse die Empfänger-D -Adresse umgeschrieben werden sll (z.b. vn mahngericht@ag-hagen.d .de auf mahngericht@ag-hagen.de) und nimmt diese Adresstransfrmatin vr. - Die D wird an das entsprechende Pstfach (z.b. des Mahngerichts) auf dem E- Mail-Server ausgeliefert und kann drt (wie eine auch) abgerufen, weitergeleitet usw. werden OSCI-/D -Gateway Wie bereits beschrieben, wandeln die gegenwärtig verfügbaren D -Gateways D s in s (und umgekehrt). In ganz ähnlicher Art und Weise sind Gateways denkbar, die D s in OSCI-Nachrichten wandeln und umgekehrt. Dazu hat das BSI im Mai 2013 ein Feinknzept Gateway für die Verknüpfung vn D und OSCI vrgelegt. Darin wird insbesndere beschrieben, wie das Gateway D s vm D -Anbieter abruft, diese unter Zuhilfenahme des EGVP-Verzeichnisdienstes (auf S.A.F.E.-Basis) in eine OSCI-Nachricht wandelt und über den OSCI-Intermediär an das EGVP ausliefert. Auch der entgegensetze Przess wird erläutert. Der vn Gvernikus Gmbh & C. KG (vrmals Bremen Online Services) angebtene Gvernikus MultiMessenger erfüllt bereits einen Teil der Anfrderungen an ein OSCI-/D - Gateway. Der Einsatz eines OSCI-/D -Gateways ist dann angezeigt, wenn unbedingt OSCI- Nachrichten benötigt werden für Versand und/der Empfang. Dies ist insbesndere dann der Fall, wenn vrhandene Fachverfahren der andere Backendsysteme das OSCI- Nachrichtenfrmat erfrdern. Dabei sllte berücksichtigt werden, dass bei einer Kpplung vn OSCI und D Sicherheitseigenschaften vn OSCI entbehrlich werden: - (Qualifizierte elektrnische) Signatur Insbesndere zur Erfüllung vn Schriftfrmerfrdernissen werden OSCI-Nachrichten häufig qualifiziert elektrnisch signiert. Gemäß 130a ejustice-gesetz können elektrnische Dkumente nun auch hne qualifizierte elektrnische Signatur der verantwrtenden Persn eingereicht werden, wenn dies auf einem sicheren Übermittlungsweg, als z.b. als (absenderbestätigte) D , erflgt. - Verschlüsselung OSCI bietet eine Ende-zu-Ende-Verschlüsselung zwischen Absender und Empfänger. Dies ist bei D nicht der Fall, da nur die Transprtkänale verschlüsselt werden, was eine Umschlüsselung (Ent- und erneute Verschlüsselung) beim D - 02_knzept_eid_und_d _im_mahnverfahren_jum_bw.dcx 18/27

20 Anbieter erfrdert. Drt werden die D s verschlüsselt gespeichert. Da die De- Mail-Anbieter allerdings bzgl. Sicherheit und Datenschutz zertifiziert sind, kann in fast allen Fällen auf eine durchgängige Ende-zu-Ende-Verschlüsselung verzichtet werden. Auf Wunsch des Absenders können aber auch D s Ende-zu-Ende verschlüsselt werden nicht auf Basis OSCI. Die D -Anbieter müssen dies unterstützen. - Quittungen (Laufzettel) In der D -Kmmunikatin gelten grundsätzlich nur die D -eigenen Quittungsmechanismen - d.h. insbesndere, dass eine D beim Empfänger dann als eingegangen gilt, sbald sie in das D -Pstfach des Empfängers bei seinem De- Mail-Anbieter eingelegt wurde. Zu diesem Zeitpunkt erhält der Absender (auf Wunsch) darüber eine Bestätigung ( Eingangsbestätigung ) und Fristen beginnen ggf. zu laufen. Aus Sicht vn D und den damit verknüpften Rechtswirkungen ist es völlig unerheblich, wann der Empfänger die D aus seinem Pstfach abhlt und wie dies geschieht, per Webbrwser bzw. nrmalen der OSCI-/D - Gateway. In dieser Hinsicht hätte der OSCI-Laufzettel seine Bedeutung verlren. OSCI-Kmpnenten könnten aber dazu verwendet werden, die z.t. an D s angebrachten qualifizierten elektrnischen Signaturen zu prüfen. Zusammenfassend kann festgehalten werden, dass OSCI rein aus Sicherheitsgründen in einer D -Kmmunikatin entbehrlich ist. Wird das OSCI-Nachrichtenfrmat nicht aus anderen Gründen unbedingt benötigt, kann auf OSCI und damit auch auf ein OSCI-/D - Gateway verzichtet werden. 3.2 Einsatz vn D im autmatisierten Mahnverfahren D -Adressen der Mahngerichte Die 12 Mahngerichte in Deutschland sind den entsprechenden Amtsgerichten zugerdnet, z.b. ist das Mahngericht Hagen eine Abteilung des Amtsgerichts Hagen. Da die Amtsgerichte zukünftig einen Zugang für D eröffnen müssen, sllte ein D - Knt pr Amtsgericht bei einem akkreditierten D -Anbieter einrichtet werden, vrzugsweise mit der D -Dmain amtsgericht-xyz.d .de, z.b. ag-hagen.d .de Eine 1:1-Übertragung des -Adressfrmates des AG Hagen in D ist nicht hne weiteres möglich, da ein D -Knt mit der Adresse ag-hagen.nrw.d .de nicht dem AG Hagen, sndern NRW gehören würde - welche knkrete Landesbehörde sich auch immer hinter NRW verbirgt. Dies wäre nur dann möglich, wenn die hinter NRW stehende Behörde die gesamte Verantwrtung für alle ein- und ausgehenden D s des Knts nrw.d .de übernehmen würde. Dies hieße beispielsweise, dass alle vm Mahngericht Hagen versendeten D s nicht vm AG Hagen, sndern vn der hinter NRW stehenden Behörde verschickt würden. Das dürfte vermutlich nicht gewllt sein. Theretisch ist auch ein D -Knt mit einer Adresse der Frm mahnwesen.d .de denkbar. Dies hieße aber, dass es eine öffentliche Stelle gibt, deren Namen in direktem Bezug mit Mahnwesen steht (D -Gesetz) und die die gesamte Verantwrtung 02_knzept_eid_und_d _im_mahnverfahren_jum_bw.dcx 19/27

21 für alle 12 Mahngerichte übernimmt. Eine D vn einem D -Knt mit der Adresse mahnwesen.d .de würde dann nicht mehr vn den einzelnen Mahngerichten/Amtsgerichten verschickt, sndern vn der hinter mahnwesen stehenden öffentlichen Stelle. Dies dürfte vermutlich ebenfalls nicht gewllt sein. Aus den genannten Gründen empfiehlt sich die Verwendung flgender D -Dmains: - Amtsgerichte: amtsgericht-xyz.d .de der ag-xyz.d .de.ä. - Mahngerichte (keine eigenen D -Knten): Adressierung als 4th-Level-Dmain, d.h. eine Bezeichnung hinter Adressierung über eine Bezeichnung vr : mahngericht@ag-xyz.d .de, z.b. mahngericht@ag-hagen.d .de Architekturansätze Vraussetzungen und grundsätzlicher Przessablauf Die nachstehend genannten Vraussetzungen und der grundsätzliche Przessablauf gelten für alle in den flgenden Kapiteln erläuterten Architekturansätze. Vraussetzungen Der Antragsteller besitzt ein D -Knt bei einem akkreditierten D -Anbieter seiner Wahl z.b. franz.meier@web.d .de Das Mahngericht, an das sich der Antragsteller wenden möchte, besitzt ebenfalls ein D -Knt z.b. mahngericht@ag-hagen.d .de Der Antragsteller hat Zugriff auf das Online-Mahnverfahren (OMA) unter OMA ist der Lage, dem Antragsteller den (per D an das Mahngericht zu versendenden) Antrag in einer geeigneten Frm zur Verfügung zu stellen (z.b. PDF- Dkument und/der TXT-/XML-Datei, ). OMA ist der Lage, dem Antragsteller den (per D an das Mahngericht zu versendenden) Antrag in einer geeigneten Frm zur Verfügung zu stellen (z.b. PDF- Dkument und/der TXT-/XML-Datei, ). Nutzer können ihre Antragsdaten durch Einsatz einer geeigneten Sftware auch selbst erstellen und lkal abspeichern. Die Übertragung unterscheidet sich danach nicht vn der Übertragung vn mit OMA erstellten Antragsdaten. Grundsätzlicher Przessablauf 1. Der Antragsteller erstellt einen Mahnantrag in OMA (inkl. aller Plausibilitäts- und Vllständigkeitschecks). 2. Der Antragsteller entscheidet sich (in OMA) für den Versand des Mahnantrags per D . 02_knzept_eid_und_d _im_mahnverfahren_jum_bw.dcx 20/27

22 3. Dem Antragsteller werden die erfrderlichen Dateien zum Dwnlad bereitgestellt. Welche Frmate hier verwendet werden sllen, muss nch geklärt werden (PDF- Dkument und/der TXT-/XML-Datei, ). 4. Der Antragsteller speichert die Dateien lkal auf seinem Rechner ab ein autmatisches Anfügen der Dateien als Anhang einer D ist aufgrund der erfrderlichen Authentisierung am D -Knt nicht möglich. 5. Der Antragsteller erstellt eine neue D (z.b. an ) und hängt die erfrderlichen Dateien an. Hier ist nch zu klären, wie verhindert werden kann, dass der Antragstellung relevante Daten im Betreff der im Bdy der D mitschickt, die im Mahngericht nur schwer autmatisiert verarbeitet werden können. 6. Der Antragsteller versendet die D an das Mahngericht und kann auf Wunsch eine Versandbestätigung und Eingangsbestätigung (per D ) anfrdern. 7. Die D mit den Antragsdaten geht im D -Knt des Amtsgerichtes ein. 8. Die D wird in der Regel durch ein Gateway vm D -Knt abgerufen. Der Zugriff per Webbrwser auf das D -Knt wird hier nicht betrachtet, da dadurch eine autmatisierte Weiterverarbeitung kaum möglich ist. 9. In Abhängigkeit vm eingesetzten Gateway wird die D gewandelt in: (SMTP) OSCI-Nachricht Text- der XML-Dateien.ä. Alle drei Varianten werden in den flgenden Kapiteln betrachtet. 10. Die Inhalte der - der OSCI-Nachrichten bzw. die vm Gateway erzeugten Dateien werden (ggf. über weitere Zwischenschritte) in den EDA Manager eingelesen und drt weiter bearbeitet. 02_knzept_eid_und_d _im_mahnverfahren_jum_bw.dcx 21/27

23 Empfhlene Variante: Standard-D -Gateway Architekturübersicht Abbildung 10: Anbindung über Standard-D -Gateway Przessablauf Da sich die Abläufe bis einschließlich Abhlung der D s vm D -Knt des Amtsgerichts durch das Gateway in dieser und den flgenden beiden Varianten nicht unterscheiden (siehe Vraussetzungen und grundsätzlicher Przessablauf), wird davn ausgegangen, dass sich die D mit dem Mahnantrag (Anhang) bereits auf dem Gateway befindet. In der empfhlenen Variante kmmt ein Standard-Gateway zum Einsatz, das swhl durch das Amtsgericht selbst als auch zentral betrieben werden kann. Das Gateway ändert auf Basis einer Adress-Mapping-Tabelle zunächst die Empfängeradresse (z.b. vn auf Ferner ist im Gateway die Adresse eines SMTP-Relays/-Servers hinterlegt, an das/den die empfangenen D s (quasi als s mit zusätzlichen Headerdaten) ausgeliefert werden. Da für das Mahnverfahren (im Mahngericht Hagen) nicht der vrhandene -Server des Amtsgerichts verwendet werden sll, wird ein SMTP-Relay zwischengeschaltet, dass z.b. alle Mails an die Adresse an einen speziellen -Server (für das Mahnwesen) weiterleitet und alle anderen Mails an den vrhandenen -Server des Amtsgerichts. Als -Server kann eine (kstenfreie) Standard-Sftware eingesetzt wer- 02_knzept_eid_und_d _im_mahnverfahren_jum_bw.dcx 22/27

24 den, da dieser lediglich die Aufgabe hat, sich um Versand und Empfang der ein- und ausgehenden (De-)Mails zu kümmern. Diese -Server sllten in identischer Knfiguratin in allen Mahngerichten zum Einsatz kmmen, um den Supprt zu erleichtern. Die Mails auf dem -Server des Mahnverfahrens können in einem weiteren Schritt durch eine Transfrmatinskmpnente s aufbereitet werden, dass die erfrderlichen Daten (z.b. als TXT-Datei) in den EDA Manager übertragen und drt verarbeitet werden können. Diese Kmpnente müsste den -Server nach anstehenden Eingängen abfragen und diese abrufen. Jede eingegangene (De-)Mail muss hinsichtlich ihrer Headerdaten ausgewertet und daraus eine entsprechende Steuerdatei erzeugt werden. Darüber hinaus muss der Nachrichtenbdy in eine Datei mit geeigneter Struktur transfrmiert werden. Alle Daten sind danach im Eingangsverzeichnis des EDA-Managers abzuspeichern. Zum Versand vn D s muss die Transfrmatinskmpnente die erfrderlichen Daten vm EDA-Manager entgegennehmen und daraus eine (De-)Mail erzeugen, die über den E- Mail-Server und das SMTP-Relay an das D -Gateway ausgeliefert wird. Bewertung Für diese Variante spricht, dass Standard-D -Gateways verwendet werden, die vraussichtlich zukünftig swies für die Amtsgerichte zum Einsatz kmmen. Die Bearbeitung der eingehenden (De-)Mails mit den Antragsdaten kann recht einfach durch eine eigenentwickelte Transfrmatinskmpnente vrgenmmen werden. Dafür sind Headerdaten, Nachrichtenbdy und Anhänge der eingegangenen (De-)Mail s aufzubereiten, dass die Daten an den EDA-Manager übergeben werden können. 02_knzept_eid_und_d _im_mahnverfahren_jum_bw.dcx 23/27

25 Alternativvariante 1: OSCI-/D -Gateway Architekturübersicht Abbildung 11: Anbindung über OSCI-/D -Gateway Diese Variante geht zunächst wieder davn aus, dass nur die D s mit Mahnanträgen, die an ein bestimmtes Unterknt des Amtsgerichts gerichtet sind, z.b. mittels OSCI-/D -Gateway abgerufen werden. Alle anderen D s werden vn einem Standard-D -Gateway vm D -Knt abgehlt und an einen E- Mail-Server des Amtsgerichts ausgeliefert. Weitere Varianten sind denkbar: 1. Das OSCI-/D -Gateway ruft weitere D -Unterpstfächer ab und liefert die drt eingegangenen D s als OSCI-Nachrichten an entsprechende OSCI- Pstfächer auf dem Intermediär aus. Die anderen D s werden vm Standard- Gateway an den -Server des Amtsgerichts geschickt. 2. Das OSCI-/D -Gateway ruft alle D s aus dem Knt des Amtsgerichts ab und liefert diese als OSCI-Nachrichten aus. In diesem Fall kann das Standard-De- Mail-Gateway entfallen. 02_knzept_eid_und_d _im_mahnverfahren_jum_bw.dcx 24/27

26 Przessablauf Das OSCI-/D -Gateway empfängt alle an ein bestimmtes Unterpstfach, z.b. gerichteten D s mit Mahnanträgen und wandelt diese in OSCI-Nachrichten um. Die OSCI-Adresse des Empfängers muss dazu ggf. aus dem EGVP- Adressverzeichnis (auf S.A.F.E.-Basis) abgerufen werden. Danach wird die OSCI-Nachricht im entsprechenden OSCI-Pstfach eines OSCI-Intermediärs abgelegt. Vn drt aus erflgt die weitere Bearbeitung und die Übergabe der Daten an den EDA Manager entsprechende dem bereits heute implementierten Przess unter EGVP-Nutzung. Bewertung Ein Vrteil dieser Variante ist, dass die Przessschritte ab OSCI-Intermediär bereits implementiert sind. Grundsätzlich ist es für eine OSCI-Nachricht im OSCI-Pstfach auf dem Intermediär hne Belang, b sie drthin über die OSCI-/EGVP-Infrastruktur der vn einem OSCI-/D -Gateway gelangt ist. Nachteilig ist, dass ein OSCI-/D -Gateway mit der erfrderlichen Funktinalität gegenwärtig nch nicht verfügbar ist zukünftig könnten allerdings Lösungen angebten werden. Schwerer wiegt die Tatsache, dass der EDA Manager keinen Input im OSCI-Frmat benötigt. Die erfrderlichen Antragsdaten können ihm als Text-Datei zur Verfügung gestellt werden. Da überdies beim Einsatz vn D die Sicherheitsmerkmale vn OSCI entbehrlich werden (vergleiche OSCI-/D -Gateway) spricht wenig für ein OSCI-/D - Gateway für Mahnanträge. 02_knzept_eid_und_d _im_mahnverfahren_jum_bw.dcx 25/27

27 Alternativvariante 2: Spezielles D -Gateway für Mahnanträge Architekturübersicht Przessablauf Abbildung 12: Anbindung über ein spezielles D -Gateway für Mahnanträge Die im D -Knt des Amtsgerichts eingegangenen D s müssen unterschiedlich behandelt werden, da es sich nur zum Teil um Mahnanträge handelt. Dazu ist im D -Knt ein sgenanntes Unterknt einzurichten, z.b. für die Adresse Alle D s in diesem Unterknt werden durch ein spezielles Mahnwesen-Gateway abgehlt und derart transfrmiert, dass die erfrderlichen Daten, z.b. als TXT-Datei sfrt an den EDA Manager übergeben werden können. Alle anderen an das Amtsgericht gerichteten D s werden vn einem Standard-D - Gateway vm D -Knt abgehlt und an einen -Server des Amtsgerichts ausgeliefert. Drt können sie wie gewöhnliche s weitergeleitet, gespeichert, bearbeitet usw. werden. Bewertung Gegenwärtig existiert kein spezielles D -Gateway für Mahnanträge. Dies müsste entwickelt werden. Die D -Anbieter halten sich zur Zeit mit der Bereitstellung einer (universellen) D -Schnittstelle für die Anbindung vn Drittanbieter-Gateways sehr zurück. Aus diesem Grunde ist eine starke Abhängigkeit einer Mahnwesen-Gateway-Entwicklung vn den Vrgaben der D -Anbieter gegeben, was die Entwicklung ggf. behindern, aber auf jeden Fall wesentlich verteuern würde. 02_knzept_eid_und_d _im_mahnverfahren_jum_bw.dcx 26/27

28 Es dürfte deutlich einfacher sein, die eingegangenen D s zunächst durch ein Standard- Gateway an einen -Server ausliefern und diese dann durch eine eigenentwickelte Transfrmatinskmpnente bearbeiten zu lassen, um die für den EDA Manager erfrderlichen Frmate zu erzeugen. S wäre man kmplett unabhängig vm jeweiligen D - Anbieter. 02_knzept_eid_und_d _im_mahnverfahren_jum_bw.dcx 27/27

29 Herausgeber Bundesministerium des Innern IT-Stab, Referat ITI4 Alt-Mabit 101 D, Berlin Bezugsquelle Bundesministerium des Innern Internet: Internet: Tel.: Veröffentlicht Nvember 2014 HINWEIS Das Bundesministerium des Innern ist nicht verantwrtlich für den Inhalt der Ergebnisdkumente, die im Rahmen der E-Gvernment-Initiative für D und den Persnalausweis erstellt wurden. Bitte wenden Sie sich bei inhaltlichen Fragen direkt an die hier genannten Ansprechpartner. Verantwrtlich für den Inhalt dieses Ergebnisdkumentes Krdinierungsstelle für das autmatisierte Mahnverfahren beim Justizministerium Baden-Württemberg Herr Ralf Selbmann Schillerplatz 4, Stuttgart Tel.: Internet: Diese Veröffentlichung ist Teil der Öffentlichkeitsarbeit der Bundesregierung. Sie w ird kstenls abgegeben und ist nicht zum Verkauf bestimmt.