[Epic] Optimierung Zertifikatshandling

Why

Betreiber von FV haben Schwierigkeiten mit der Zertifkatsgenerierung (TEST-Umgebung) und dem Ableiten von JWKs aus X509-Zertifiakten (STAGE-/PROD-Umgebung).

Aktuell haben wir im Umgang mit den Zertifikaten zwei Haupt-Nutzergruppen.

1. Entwickler / Fachverfahrenshersteller
2. Behördenmitarbeiter: Fachlich Verantwortliche - teilweise mit Unterstützung von IT-Admins aber eher mit überwiegend wenig IT Basiswissen (Es gibt in den Behörden auch teilweise IT-affinere Ansprechpartner - für die Vereinfachung würden wir diese aber in die Nutzergruppe 1 einordnen.)

Nutzergruppe 1 Entwickler: Diese Nutzer entsprechen unserer ursprünglich angenommenen Zielgruppe. Hier haben wir auch im Rahmen der Anbindungsprojekte kaum Probleme rund um unsere Tools. Zumeist können Sie gut mit unseren Tools(Python) / unserer Doku arbeiten. Hauptdiskussionen haben wir hier rund um das Verständnis und Beantragungsprozess zu den V-PKIs. Oftmals kann also auch ein Dienstleister dem Behördenmitarbeiter bei dem Beantragungs-, Umwandlungs- und Bereitstellungsprozess nicht angemessen helfen.

Nutzergruppe 2 Behördenmitarbeiter: Die Betreuung dieser Nutzergruppe ist ziemlich aufwendig. Sie spielen aber bei den meisten Fachverfahren eine große Rolle. Verweis auf die Doku ist meistens nicht ausreichend. Doku wird oft nicht gelesen, oder falsch befolgt. Letztendlich müssen wir bei den meisten "über die Schulter schauen" um die entsprechenden JWKs zu bekommen (Test & Prod). Oft arbeiten diese User auch auf eingeschränkten Rechnern, auf denen eine Installation von Python oder sonstiger Software problematisch und mit viel Aufwand verbunden ist.

Zunehmend stellen wir fest das viele Fachverfahren eher "old-school" betrieben werden - lokale EXE-Datei, eine auf einem Netzlaufwerk abgelegte Software oder ähnliches. Bei dem Betrieb der Fachverfahren ist oft das Know-How nicht so wie ursprünglich angenommen ausgeprägt und die Administration der Fachverfahren nur bei Bedarf mit dem Dienstleister gemeinsam nach dem "über die Schulter schauen"-Verfahren durchgeführt wird. Viele Fachverfahrenshersteller überlassen die Konfiguration der Verfahren für FIT-Connect auch der jeweiligen Behörde (Fachadmin - Nutzergruppe 2). Auch bereits in der Testphase werden meist schon Personen aus der Nutzergruppe 2 früh eingebunden.

Goal

Beide Nutzergruppen können einfach ihre Aufgaben rund um das Zertifikatshandling bearbeiten, ohne zu viel Betreuungsaufwand beim Anbindungsmanagement oder Support zu benötigen.

Links, Notes, Remarks

• Ursprüngliches Issue mit Anforderungen zum jetzigen Python-Tool: #2 (closed)

Vorgehen

... details (old)

- [X] Der bisherige Diskussionsstand (von vor ca. 6 Monaten) wird hier zusammengefasst -> Ausgangslage + Bisherige Entscheidungen - https://git.fitko.de/fit-connect/arch/-/blob/ideas/gerd-aschemann/public/backlog/ideas/gerd-aschemann/certificate-app/certificate-app.adoc - [X] Auf dieser Basis tragen wir alle weiteren Anforderungen und Constraints zusammen und legen Bewertungsmaßstäbe fest, welche davon eine Lösung erfüllen muss - [ ] ggf. gibt es dabei Widersprüche, z.B. zwischen Security-Constraints und Usability-Wünschen, diese müssen aufgelöst oder priorisiert werden - [ ] Marco stößt die Security Bewertung mit Gerd, Hauke, Markus & BSI an - [ ] Bewertung der Angriffsszenarien (speziell die JS Varianten) - [X] Die Anforderungen sollen durch typische Benutzungsszenarien genauer verdeutlicht werden - [X] Mögliche Lösungsvarianten werden skizziert - [X] Auf dieser Basis erstellen wir eine Entscheidungsmatrix/-Baum von (gewerteten) Anforderungen/Constraints und Lösungsvarianten https://git.fitko.de/fit-connect/arch/-/blob/ideas/gerd-aschemann/public/backlog/ideas/gerd-aschemann/certificate-app/certificate-app.adoc - [X] Wir wählen eine (oder ggf. mehrere Varianten für unterschiedliche UseCases) aus 1. [ ] Pilotierung in JS der Testzertifikatsgenerierung (für NON-IT affine User) #1160 2. [ ] parallel: Abschluss der Arbeiten in den Java & .NET SDKs sofern Kapa verfügbar (#664 (closed), #665, #667 (closed), #668 (closed)) - als Vorarbeit für die SSP-API 2. [ ] Konzeption der Option "P12-Container im Fachverfahren" (SSP-API SDKs) 3. [ ] Entscheidung auf Basis BSI-Diskussion, wie die JS-SDK integriert wird (SSP, ZIP in GilLab, sonstiges) 4. [ ] Implementierung der Entscheidung 5. [ ] zu prüfen: Implementierung der Ableitung aus V-PKIs im JS-SDK #1161 (closed)

• Diese und nur diese wird/werden dann ggf. noch genauer ausgearbeitet und umgesetzt -> sie gehen in die Planung für das Team, welches sie am besten umsetzen kann und werden bei Bedarf auf Stories heruntergebrochen
• Erneute Diskussionen sind in Zukunft zu vermeiden, indem man prüft, ob vermeintlich neue Anforderungen und Lösungsideen nicht schon bewertet/priorisiert wurden. Nur, wenn es neue wichtige Anforderungen oder neue essenzielle Lösungsvarianten gibt, sollte die Diskussion erneut geführt werden.

Bewertung aus der Projekthistorie

• Aus Security-Gründen darf der Private Key eines V-PKI-Zertifikats niemals die Organisation (Behörde) verlassen, auf die das Zertifikat ausgestellt wurde. Ausnahme ist die Weitergabe an einen beauftragten IT-Dienstleister, der ein Fachverfahren im Auftrag der Behörde betreibt. In keinem Fall sollte der Private Key des V-PKI-Zertifikats das konkrete IT-System verlassen, auf dem das Fachverfahren der Behörde betrieben wird.
• Daher ist eine Ableitung von JWKs aus X509-Zertifiakten (pkcs-Container) über die UI des Self-Service-Portals nicht möglich.
• Auch eine Ableitung von JWKs aus X509-Zertifiakten im Browser via JavaScript ist aus Security-Gründen keine Option (ein Angreifer, der das SSP kompromittiert, könnte sich sonst Zugriff zu vielen V-PKI-Zertifikaten verschaffen).
• Daher gibt es die Zertifikatsgenerierungs- und konvertierungstools in https://git.fitko.de/fit-connect/fit-connect-tools

Handlungsoptionen

... details (old)

#### Zertifikatserstellung und -konvertierung im SSP - Ausgeschlossen aufgrund bisheriger Entscheidungen

Anm. Wojtek: ggf. könnte eine ZIP-Datei mit einer HTML Datei und einem Integrierten JS-Skript ein "fauler" Kompromiss sein aber für die Anwender gut bedienbar sein.

Integration in CLIs

• Java-SDK: Ableiten von JWKs aus X509-Zertifiakten im CLI-Client: #667 (closed)
• .NET-SDK: Ableiten von JWKs aus X509-Zertifiakten im CLI-Client: #668 (closed) #668 (closed)
• Java-SDK: Generierung von Test-JWKs via CLI-Client (Testzertifikate): #664 (closed)
• .NET-SDK: Generierung von Test-JWKs via CLI-Client (Testzertifikate): #668 (closed)

Anm. Wojtek: Fokus müsste hier darauf liegen, dass auch keine Java-Bibliotheken, .NET Bibliotheken oder sonstiges installiert werden muss und es auf den stark eingeschränkten Rechnern lauffähig ist.

GUI-Tool

• Es könnte evaluiert werden, ob Betreiber:innen eines Fachverfahrens mit einem GUI-Tool besser klar kämen.

Anm. Wojtek: Auch hier wäre die "Installierbarkeit" wichtig.

P12-Container im Fachverfahren (Anm. Laura)

• "Hinterlegung des P12-Containers im Fachverfahren wäre ein sehr guter und Nutzer:innenfreundlicher Ansatz." #926 (comment 61639)

Stories

1. Generierung von Test-JWKs via SDK-Client (über einen P12 Container)
   1. Java SDK #664 (closed)
   2. .NET SDK #665
   3. JavaScript SDK #1160 (veröffentlichen erst nach Freigabe Security)
2. Ableiten von JWKs aus V-PKI Zertifikaten im SDK-Client (über einen P12 Container)
   1. Java SDK #667 (closed)
   2. .NET SDK #668 (closed)
   3. JavaScript SDK #1161 (closed) (veröffentlichen erst nach Freigabe Security)
3. Unterstützung von PEM/DER-Zertifikaten im Zertifikats-Tool #469 (closed) - in die Einzelstories integriert

Acceptance criteria

1. Java SDK können Test-JWKs generieren und JWK aus V-PKI Zertifikaten ableiten
2. ,NET SDK können Test-JWKs generieren und JWK aus V-PKI Zertifikaten ableiten
3. JavaScript SDK können Test-JWKs generieren und JWK aus V-PKI Zertifikaten ableiten
4. Es werden in allen SDKs Zertifikate im p12-Format oder als PEM/DER-kodierte Zertifikate unterstützt
5. ...
6. Definition of Done was checked.

Potential follow-up activities

• Übernahme der Funktionalitäten in die CLI-Tools
• Nutzbarkeit der Funktionalitäten für die SDKs der Destination-API sicherstellen
• Integration der JavaScript Funktionalitäten in eigene herunterladbare HTML Seite (oder im SSP)

Open questions