diff --git a/assets/images/oauth/JWT-Konzept.png b/assets/images/oauth/JWT-Konzept.png
new file mode 100644
index 0000000000000000000000000000000000000000..4bbbfb3950afbb307e6ddd925bf07d8e8aefea55
Binary files /dev/null and b/assets/images/oauth/JWT-Konzept.png differ
diff --git a/docs/Detailinformationen/Authentifizierung_von_Usern.md b/docs/Detailinformationen/Authentifizierung_von_Usern.md
index 22ab6324c98d5ff7e6b58257f26af89ed4e1765e..2526e784a53b64a4fc21cd5f3f9f1d746712a466 100644
--- a/docs/Detailinformationen/Authentifizierung_von_Usern.md
+++ b/docs/Detailinformationen/Authentifizierung_von_Usern.md
@@ -1,28 +1,36 @@
# Authentifizierung von Usern an Zustelldiensten
-Jeder Onlineantragsdienst muss bei fitconnenct registriert sein, um fitconnect Formulare darstellen und übermitteln zu können. Bei der Registrierung von Onlinediensten wird festgelegt, welche Anträge die Onlinedienste auf welchen Domains ausspielen dürfen. Im Rahmen dieses Prozesses wird für jeden Onlinedienst ein Public Key hinterlegt.
+Jeder Onlineantragsdienst muss bei FIT-Connect registriert sein, um FIT-Connect Formulare darstellen und übermitteln zu können. Bei der Registrierung von Onlinediensten wird festgelegt, welche Anträge die Onlinedienste auf welchen Domains ausspielen dürfen. Im Rahmen dieses Prozesses wird für jeden Onlinedienst ein Public Key hinterlegt. Nach der Anmeldung erhält jeder Onlineantragsdienst OAuth2-Credentials für den Authentifizierungstyp "Client-Credentials".
-Eine Registrierung eines Onlinedienstes ist über das Self-Service-Portal der FITKO möglich. (TODO: link)
+Eine Registrierung eines Onlinedienstes ist über das Self-Service-Portal der FITKO möglich. (TODO: link) Dort müssen folgende Informationen über einen Onlinedienst hinterlegt werden:
-Wenn ein Onlinedienst nun einem User ermöglichen möchte, einen Antrag zu übermitteln, muss dieser auf Basis des zum Public Key gehörenden Private Key einen JWT Token erzeugen, der Informationen dazu enthält, welcher Onlinedienst dem User erlaubt, einen Antrag an welche Destinationen zu übermitteln. Wenn der User nun einen Antrag an den Onlinedienst übermittelt, kann das fitconnect API-Gateway nachvollziehen, von wo ein Antrag übermittelt wird und somit überprüfen, ob der User/Onlinedienst dafür autorisiert ist.
+- Freigegebene Domains, von denen der Onlinedienst Formulare übermittelt.
+- Erlaubte Destination-IDs, an die Anträge übermittelt werden dürfen.
+- Ein Public Key des Onlinedienstes, die er für die Erstellung von JWTs benutzt.
+
+Wenn ein Onlinedienst einem User ermöglichen möchte, einen Antrag zu übermitteln, muss er mithilfe seiner Client-Credentials beim FIT-Connect-Authentifizierungsserver einen JWT-Access-Token (Onlinedienst-Token) abrufen. Dieser Onlinedienst-Token enthält den Public-Key, der für den Onlinedienst bei der Anmeldung festgelegt wurde, im signierten Datensatz.
+
+Nun muss der Onlinedienst auf Basis des zum Public Key gehörenden Private Key einen weiteren JWT Token (User-Token) erzeugen, der Informationen dazu enthält, das der Onlinedienst dem User erlaubt, einen Antrag an eine spezifische Destinationen zu übermitteln.
+
+Wenn der User nun einen Antrag an den Onlinedienst übermittelt, muss dieser sowohl den User-Token als auch den Onlinedienst-Token im Header mitübermitteln. Mithilfe der beiden Tokens kann das FIT-Connect API-Gateway nachvollziehen, von wo ein Antrag zu welcher Destination übermittelt wird und kann somit überprüfen, ob der User/Onlinedienst dafür autorisiert ist.
<img src="../../assets/images/oauth/JWT_konzept.png" alt="JWT Konzept" width="400"/>
### Warum ist die anonyme Authentifizierung notwendig?
-Im Rahme von fitconnenct soll das massenhafte absenden (spammen) von Anträgen über Ratelimiting verhindert werden und es sollen nur vertrauenswürdige Webseiten, die dem fitconnnenct Standards entsprechen, die Möglichkeit bekommen, Anträge über fitconnect zu übermitteln. Um diese Maßnahmen umsetzen und einen User über mehrere Requests hinweg sicher identifizieren zu können, ist eine Form der anonymen Authentifizierung notwendig.
+Im Rahmen von FIT-Connect soll das massenhafte absenden (spammen) von Anträgen über Ratelimiting verhindert werden und es sollen nur vertrauenswürdige Webseiten, die dem FIT-Connect-Standards entsprechen, die Möglichkeit bekommen, Anträge über FIT-Connect zu übermitteln. Um diese Maßnahmen umsetzen und einen User über mehrere Requests hinweg sicher identifizieren zu können, ist eine Form der anonymen Authentifizierung notwendig.
-## Generierung des JWT-Tokens beim Onlinedienst
+## Generierung der JWT-Tokens
-Jedes Backend eines fitconnect Onlineantragsdienstes muss über ein Backend verfügen, welches JWT-Tokens für diese Instanz erzeugen und an den Browser des Users übermitteln kann. Es sollte dabei eine geeignete Form von Rate-Limiting, für die Ausstellung der Public Keys passend zum Usecase des Onlinedienstes implementieren. Es sollte die Menge der mit einem JWT-Token freigegebenen Destinationen minimieren. **Es dürfen in denen vom Onlineservice generierten JWT-Tokens keinen Informationen hinterlegt werden, die zur Identifikation des Users führen könnten.**
+Jedes Backend eines FIT-Connect Onlineantragsdienstes muss über ein System verfügen, welches JWT-Tokens für diese Instanz erzeugen und an den Browser des Users übermitteln kann. Es sollte dabei eine geeignete Form von Rate-Limiting, für die Ausstellung der Public Keys passend zum Usecase des Onlinedienstes implementieren. Es sollte die Menge der mit einem JWT-Token freigegebenen Destinationen minimieren. **Es dürfen in denen vom Onlineservice generierten JWT-Tokens keinen Informationen hinterlegt werden, die zur Identifikation des Users führen könnten.**
-### Anforderungen an das Keypair
+### Anforderungen an die Keypairs
-Der Onlinedienst muss zur Registrierung bei fitconnect neben den Angaben dazu, welche Destinationen er unter welchen Domains verwendenden möchte, auch noch einen Public Key eines Keypairs, das nach folgenden Standards erzeugt wurde, übermitteln:
+Der Onlinedienst muss zur Registrierung bei FIT-Connect neben den Angaben dazu, welche Destinationen er unter welchen Domains verwendenden möchte, auch noch einen Public Key eines Keypairs, das nach folgenden Standards erzeugt wurde, übermitteln:
| Feld | Inhalt | **Erläuterung** |
| ------------------ | ---------- | ------------------------------------------------------------ |
-| Hashingalgorithmus | SHA-512 | Gibt den Algorithmus der zur digitalen Signatur des Keys verwendet werden muss an. Dieser muss im Fall von fitconnect immer SHA-512 sein. (vgl. [BSI TR-02102-1 Tabelle 4.1](https://www.bsi.bund.de/SharedDocs/Downloads/DE/BSI/Publikationen/TechnischeRichtlinien/TR02102/BSI-TR-02102.html)) |
+| Hashingalgorithmus | SHA-512 | Gibt den Algorithmus der zur digitalen Signatur des Keys verwendet werden muss an. Dieser muss im Fall von FIT-Connect immer SHA-512 sein. (vgl. [BSI TR-02102-1 Tabelle 4.1](https://www.bsi.bund.de/SharedDocs/Downloads/DE/BSI/Publikationen/TechnischeRichtlinien/TR02102/BSI-TR-02102.html)) |
| Keylänge | 4096 | Länge des zugrundeliegenden RSA-Keys. Diese entspricht der Empfehlung des BSIs für ab dem Jahr 2023. (vgl. [BSI TR-02102-1 Tabelle 3.1](https://www.bsi.bund.de/SharedDocs/Downloads/DE/BSI/Publikationen/TechnischeRichtlinien/TR02102/BSI-TR-02102.html)) |
| Signaturstandard | RSASSA-PSS | Entspricht dem Standard beschrieben in [RFC 4056](https://tools.ietf.org/html/rfc4056) und vom BSI empfohlen in [BSI TR-02102-1 Abschnitt 5.4.1.](https://www.bsi.bund.de/SharedDocs/Downloads/DE/BSI/Publikationen/TechnischeRichtlinien/TR02102/BSI-TR-02102.html) |
@@ -51,7 +59,7 @@ Entsprechend [RFC 7519 Abschnnitt 8](https://tools.ietf.org/html/rfc7519#section
}
```
-#### Body
+#### Body des User-JWT-Tokens
Entsprechend den [standartisierten Feldern](http://www.iana.org/assignments/jose/jose.xhtml#web-signature-encryption-algorithms):
@@ -76,24 +84,56 @@ Entsprechend den [standartisierten Feldern](http://www.iana.org/assignments/jose
```
+#### Body des Onlinedienst-JWT-Tokens
+
+Entsprechend den [standartisierten Feldern](http://www.iana.org/assignments/jose/jose.xhtml#web-signature-encryption-algorithms):
+
+| Feld | Inhalt | **Erläuterung** |
+| ------- | ----------------------------- | ------------------------------------------------------------ |
+| iat | Unix Timestamp | Zeitpunkt wann der Token ausgestellt wurde als Unix Timestamp. |
+| exp | Unix Timestamp | Zeitpunkt wann der Token abläuft als Unix Timestamp (Token sollte max. 24 Stunden gültig sein vgl [BSI APP.3.1](https://www.bsi.bund.de/SharedDocs/Downloads/DE/BSI/Grundschutz/Kompendium_Einzel_PDFs/06_APP_Anwendungen/APP_3_1_Webanwendungen_Edition_2020.pdf?__blob=publicationFile&v=1)). |
+| scope | Liste von Destination-IDs | Eine Liste der Destination-IDs, für die der JWT eine Übermittlung erlaubt. |
+| epk | Public Key des Onlinedienstes | Der Public Key, der dem Onlinedienst bei der Anmeldung zugeordnet wurde im JWK Format nach [RFC-7517](https://tools.ietf.org/html/rfc7517) |
+| aud | ID des Onlinedienstes | Wird bei der Anmeldung des Onlinedienstes festgelegt und dient zur Identifizierung des Onlineservices |
+| domains | Liste von Domains | Eine Liste der Domains, von denen der Onlineservice Anträge übermitteln kann. (Subdomains müssen explizit angegeben werden) |
+
+**Beispiel**
+
+```json
+{ Â
+ "iat":"1620072619", Â
+ "exp":"1620079819",
+ "scope": ["b49f13e6-4e05-4ca1-9f15-45a25f2c3312", "da68af39-65cf-4c4a-a990-c6fd5e791710"],
+ "epk": {
+ "kty": "RSA",
+ "e": "AQAB",
+ "key_ops": ["verify"],
+ "alg": "PS512",
+ "n": "...Public Key..."
+ },
+ "aud": "639c5be8-eb9c-4741-834e-4ad11629898a"
+ "domains": ["example.com", "sub.example.com"]
+}
+```
-## Validierung durch die Sender-API/API-Gateway
+## Validierung der JWT-Tokens durch die Sender-API/API-Gateway
-Bei jedem eingegangen Antrag muss der JWT-Token des Users validiert werden, um so Missbrauch der Antragsübermittlungsschnittstelle zu verhindern und nur korrekt implementierten fitconnect-Clients Zugang zur Antragsübermittlung zu geben.
+Bei jedem eingegangen Antrag muss der JWT-Token des Users validiert werden, um so Missbrauch der Antragsübermittlungsschnittstelle zu verhindern und nur korrekt implementierten FIT-Connect-Clients Zugang zur Antragsübermittlung zu geben.
-Nach dem Anlegen eines Antragsübertragungsprozesses kann auf diesen nur mit JWT-Tokens von demselben Onlinedienst und mit derselben Session-ID zugegriffen werden.
+Nach dem Anlegen eines Antragsübertragungsprozesses kann auf diesen nur mit JWT-Tokens von demselben Onlinedienst und mit derselben Session-ID zugegriffen werden.
Das API-Gateway muss die JWT-Tokens validieren:
1. Überprüfen, ob diese noch gültig sind und der JWT-Token maximal für 2h ausgestellt wurde.
-2. Mithilfe des Public Keys die Signatur des JWT überprüfen. (Public Key wird auf Basis des **sid** ausgewählt)
-3. Überprüfen, ob die gewünschte Destination-ID teil der in Scopes angegebenen Destination-IDs und für diesen Onlineservice freigegeben ist. (Zugangsberechtigung des Onlinedienstes)
-4. Überprüfen, ob die Website (origin), von der der Antrag abgesendet wurde, für die jeweilige Session-ID freigegeben ist. (Verhindern von gefälschten Onlinediensten, die nicht den fitconnect-Standards entsprechen)
+2. Mithilfe des Public Keys des Authentifizierungsservers die Signatur des Onlinedienst-JWT überprüfen.
+3. Mithilfe des im JWT-Token des Onlinedienst enthaltenen Public Key die Signatur des User JWT überprüfen
+4. Überprüfen, ob die Destination-ID teil der in den Scopes (**scope** Parameter in den JWT Tokens) beider JWT-Tokens ist. (Zugangsberechtigung des Onlinedienstes und des Users)
+5. Überprüfen, ob die Website (origin), von der der Antrag abgesendet wurde, für die jeweilige Session-ID freigegeben ist. (Verhindern von gefälschten Onlinediensten, die nicht den FIT-Connect-Standards entsprechen)
Das API-Gateway kann aufgrund der folgenden Parameter Rate-Limiting für API-Calls (angepasst an die jeweiligen Use Cases des Onlineservices) betreiben:
- sid
- IP-Addresse des Users
- Website von der der Antrag übermittelt wird bzw. das Fehlen eines Referers
-- Onlineservice-ID
+- Onlineservice-ID
\ No newline at end of file
diff --git a/docs/Detailinformationen/Encryption.md b/docs/Detailinformationen/Encryption.md
index 57a27cbeee0e932065698a864410a2da5712bb58..0b081b97e1453a2211ea68a8c015546bb1a4b095 100644
--- a/docs/Detailinformationen/Encryption.md
+++ b/docs/Detailinformationen/Encryption.md
@@ -1,7 +1,7 @@
# Verschlüsselte Übertragung
## Einleitung
-fitconnect verwendet zur Übertragung von Antragsdaten und Metadaten mit direktem Bezug zu Anträgen, abgesehen von den für die Übermittlung zwingend notwendigen Daten (z.B. Destination-ID), Ende-zu-Ende-Verschlüsselung. Diese ist auf Basis der Standards [JSON Web Encryption (JWE)](https://tools.ietf.org/html/rfc7516) unter Zuhilfenahme von [JSON Web Keys (JWK)](https://tools.ietf.org/html/rfc7517) umgesetzt.
+FIT-Connect verwendet zur Übertragung von Antragsdaten und Metadaten mit direktem Bezug zu Anträgen, abgesehen von den für die Übermittlung zwingend notwendigen Daten (z.B. Destination-ID), Ende-zu-Ende-Verschlüsselung. Diese ist auf Basis der Standards [JSON Web Encryption (JWE)](https://tools.ietf.org/html/rfc7516) unter Zuhilfenahme von [JSON Web Keys (JWK)](https://tools.ietf.org/html/rfc7517) umgesetzt.
Die Informationen auf dieser Seite sind relevant, wenn man:
- ein **Fachverfahren** mit fitconnenct-Anbindung entwickelt oder aufsetzt
@@ -9,17 +9,17 @@ Die Informationen auf dieser Seite sind relevant, wenn man:
### Warum ist Ende-zu-Ende-Verschlüsselung so wichtig?
Im Kontext von Anträgen an Behörden werden häufig höchstsensible Daten übermittelt, die im Rahmen von [Vorgaben des BSI](https://www.bsi.bund.de/SharedDocs/Downloads/DE/BSI/Publikationen/TechnischeRichtlinien/TR03107/TR-03107-1.pdf?__blob=publicationFile&v=4) nur Ende-zu-Ende-Verschlüsselt übertragen werden dürfen.
-Bei fitconnect ist die Zielsetzung einen möglichst einfachen, sicheren und klar definierten Standard zu etablieren. Deshalb ist richtig implementierte Kryptografie ein fundamentaler Teil von fitconenct und kann nicht ohne diese umgesetzt werden.
+Bei FIT-Connect ist die Zielsetzung einen möglichst einfachen, sicheren und klar definierten Standard zu etablieren. Deshalb ist richtig implementierte Kryptografie ein fundamentaler Teil von fitconenct und kann nicht ohne diese umgesetzt werden.
-## Grundlagen zur sicheren Implementierung von fitconnect
+## Grundlagen zur sicheren Implementierung von FIT-Connect
### Ende-zu-Ende-Verschlüsselung
-Fitconnect basiert auf dem Ansatz von Ende-zu-Ende-Verschlüsselung. Das bedeutet das Daten immer vom Endgerät der Nutzer*in bis in die Zielbehörde bzw. das Fachverfahren asymmetrisch verschlüsselt sein müssen.
+FIT-Connect basiert auf dem Ansatz von Ende-zu-Ende-Verschlüsselung. Das bedeutet das Daten immer vom Endgerät der Nutzer*in bis in die Zielbehörde bzw. das Fachverfahren asymmetrisch verschlüsselt sein müssen.
<img src="../../assets/images/encryption/tls-no-tls.png" alt="Ende-zu-Ende-Verschlüsselung Bedeutung" width="400" height="320">
-Es ist nicht erlaubt, das Daten unverschlüsselt oder nur per TLS gesichert an ein Backend zu übermitteln und erst dort die für fitconnect spezifizierte Verschlüsselung anzuwenden. Sollte eine längerfristige Speicherung der Antragsdaten benötigt werden, so muss diese immer clientseitig (z.B. in der IndexDB des Browsers, per Download, …) erfolgen.
+Es ist nicht erlaubt, das Daten unverschlüsselt oder nur per TLS gesichert an ein Backend zu übermitteln und erst dort die für FIT-Connect spezifizierte Verschlüsselung anzuwenden. Sollte eine längerfristige Speicherung der Antragsdaten benötigt werden, so muss diese immer clientseitig (z.B. in der IndexDB des Browsers, per Download, …) erfolgen.
### Kryptografisches Material muss immer von einer Verwaltungs-PKI signiert sein
@@ -71,9 +71,9 @@ Wenn eine Bürger*in nun einen Antrag im Web oder in einer App übermitteln möc
## Bereitstellung eines Destination-Endpunktes
-### Erstellung eines fitconnect-kompatiblen JSON Web Keys
+### Erstellung eines FIT-Connect-kompatiblen JSON Web Keys
-JSON Web Keys sind das Austauschformat in dem kryptografisches Material in fitconnect zwischen der Destination und dem Onlinedienst ausgetauscht werden. Die kryptografischen Anforderungen an die Keys findet man unter **TODO**. Die Keys sollten bereits dort generiert werden, wo sie am Ende eingesetzt werden. Ein unnötiges übertragen von Privat Keys zischen Servern/Computern sollte vermieden werden. Sollte dies doch notwendig sein, so muss die Übermittlung wenn dann nur verschlüsselt erfolgen.
+JSON Web Keys sind das Austauschformat in dem kryptografisches Material in FIT-Connect zwischen der Destination und dem Onlinedienst ausgetauscht werden. Die kryptografischen Anforderungen an die Keys findet man unter **TODO**. Die Keys sollten bereits dort generiert werden, wo sie am Ende eingesetzt werden. Ein unnötiges übertragen von Privat Keys zischen Servern/Computern sollte vermieden werden. Sollte dies doch notwendig sein, so muss die Übermittlung wenn dann nur verschlüsselt erfolgen.
Im folgenden eine beispielhafte Schritt-für-Schritt-Anleitung um einen JSON-Web-Key zu generieren:
diff --git a/docs/Detailinformationen/Encryption_Key_Requirements.md b/docs/Detailinformationen/Encryption_Key_Requirements.md
index 81d47f21ebb5aadfc32d74e8e75f1091d6742d92..5c8bb595a7fe95955d7cc4584d9df4dff31ee255 100644
--- a/docs/Detailinformationen/Encryption_Key_Requirements.md
+++ b/docs/Detailinformationen/Encryption_Key_Requirements.md
@@ -1,22 +1,22 @@
# Anforderungen an das kryptografische Material
-Fitconnect verwendet zur Übertragung von Antragsdaten und Metadaten mit direktem Bezug zu Anträgen, abgesehen von den für die Übermittlung zwingend notwendigen Daten (z.B. Destination-ID), Ende-zu-Ende-Verschlüsselung. Diese ist auf Basis der Standards [JSON Web Encryption (JWE)](https://tools.ietf.org/html/rfc7516) unter Zuhilfenahme von [JSON Web Keys (JWK)](https://tools.ietf.org/html/rfc7517) umgesetzt.
+FIT-Connect verwendet zur Übertragung von Antragsdaten und Metadaten mit direktem Bezug zu Anträgen, abgesehen von den für die Übermittlung zwingend notwendigen Daten (z.B. Destination-ID), Ende-zu-Ende-Verschlüsselung. Diese ist auf Basis der Standards [JSON Web Encryption (JWE)](https://tools.ietf.org/html/rfc7516) unter Zuhilfenahme von [JSON Web Keys (JWK)](https://tools.ietf.org/html/rfc7517) umgesetzt.
-Außerdem bietet fitconnect digital signierte Eingangsbestätigungen für Anträge. Die ausgestellten Signaturen werden auf Basis von [Security Event Tokens](https://tools.ietf.org/html/rfc8417) erzeugt und die dazugehörigen Public Keys mit Hilfe von [JSON Web Keys (JWK)](https://tools.ietf.org/html/rfc7517) implementiert.
+Außerdem bietet FIT-Connect digital signierte Eingangsbestätigungen für Anträge. Die ausgestellten Signaturen werden auf Basis von [Security Event Tokens](https://tools.ietf.org/html/rfc8417) erzeugt und die dazugehörigen Public Keys mit Hilfe von [JSON Web Keys (JWK)](https://tools.ietf.org/html/rfc7517) implementiert.
#### Allgemeine Anforderungen an die JSON Web Keys und JSON Web Encryption
-Beim Einsatz von Verschlüsselung ist es elementar, dass die dabei verwendeten kryptografischen Methoden sicher sind. Unter Berücksichtigung der Vorgaben des BSI in der Richtlinie [TR-02102-1](https://www.bsi.bund.de/SharedDocs/Downloads/DE/BSI/Publikationen/TechnischeRichtlinien/TR02102/BSI-TR-02102.html) wurde die [Liste der standartisierten Algorithmen](https://www.iana.org/assignments/jose/jose.xhtml#web-signature-encryption-algorithms) auf die, welche sich am besten zur Implementierung von fitconnect eignen, eingeschränkt. Diese Auswahl erfolgte insbesondere auf Basis des Kriteriums, welche Algorithmen am häufigsten in Softwarebiblotheken verwendet werden und deswegen einfach zu implementieren sein sollten.
+Beim Einsatz von Verschlüsselung ist es elementar, dass die dabei verwendeten kryptografischen Methoden sicher sind. Unter Berücksichtigung der Vorgaben des BSI in der Richtlinie [TR-02102-1](https://www.bsi.bund.de/SharedDocs/Downloads/DE/BSI/Publikationen/TechnischeRichtlinien/TR02102/BSI-TR-02102.html) wurde die [Liste der standartisierten Algorithmen](https://www.iana.org/assignments/jose/jose.xhtml#web-signature-encryption-algorithms) auf die, welche sich am besten zur Implementierung von FIT-Connect eignen, eingeschränkt. Diese Auswahl erfolgte insbesondere auf Basis des Kriteriums, welche Algorithmen am häufigsten in Softwarebiblotheken verwendet werden und deswegen einfach zu implementieren sein sollten.
### Regeln zur Erstellung des JSON Web Keys zur Verschlüsselung von Antragsdaten und der Signatur von Eingangsbestätigungen
-Dem JSON Web Key zur **Verschlüsselung von Antragsdaten** muss ein für die Empfangsbehörde des Antrags signiertes X.509 Zertifikat zugrundeliegen. Der JSON Web Key, der zur **Signaturprüfung von digitalen Eingangsbestätigungen verwendet wird,** muss ein für die Behörde, die den Antrag im fitconnect-System zwischenspeichert oder empfängt, signiertes X.509 Zertifikat zugrundeliegen.
+Dem JSON Web Key zur **Verschlüsselung von Antragsdaten** muss ein für die Empfangsbehörde des Antrags signiertes X.509 Zertifikat zugrundeliegen. Der JSON Web Key, der zur **Signaturprüfung von digitalen Eingangsbestätigungen verwendet wird,** muss ein für die Behörde, die den Antrag im FIT-Connect-System zwischenspeichert oder empfängt, signiertes X.509 Zertifikat zugrundeliegen.
Die den JSON Web Keys zugrundeliegenden X.509-Zertifikate müssen auf Basis der folgenden Standards erstellt werden:
| Feld | Inhalt | **Erläuterung** |
| ------------------ | ---------- | ------------------------------------------------------------ |
-| Hashingalgorithmus | SHA-512 | Gibt den Algorithmus der zur digitalen Signatur des Zertifikats verwendet werden muss an. Dieser muss im Fall von fitconnect immer SHA-512 sein. (vgl. [BSI TR-02102-1 Tabelle 4.1](https://www.bsi.bund.de/SharedDocs/Downloads/DE/BSI/Publikationen/TechnischeRichtlinien/TR02102/BSI-TR-02102.html)) |
+| Hashingalgorithmus | SHA-512 | Gibt den Algorithmus der zur digitalen Signatur des Zertifikats verwendet werden muss an. Dieser muss im Fall von FIT-Connect immer SHA-512 sein. (vgl. [BSI TR-02102-1 Tabelle 4.1](https://www.bsi.bund.de/SharedDocs/Downloads/DE/BSI/Publikationen/TechnischeRichtlinien/TR02102/BSI-TR-02102.html)) |
| Keylänge | 4096 | Länge des zugrundeliegenden RSA-Keys. Diese entspricht der Empfehlung des BSIs für ab dem Jahr 2023. (vgl. [BSI TR-02102-1 Tabelle 3.1](https://www.bsi.bund.de/SharedDocs/Downloads/DE/BSI/Publikationen/TechnischeRichtlinien/TR02102/BSI-TR-02102.html)) |
| Signaturstandard | RSASSA-PSS | Entspricht dem Standard beschrieben in [RFC 4056](https://tools.ietf.org/html/rfc4056) und vom BSI empfohlen in [BSI TR-02102-1 Abschnitt 5.4.1.](https://www.bsi.bund.de/SharedDocs/Downloads/DE/BSI/Publikationen/TechnischeRichtlinien/TR02102/BSI-TR-02102.html) |
@@ -26,7 +26,7 @@ Die X.509-Zertifikate müssen durch eine Verwaltungs-PKI signiert werden. Als Ve
Bei der Erstellung und Signierung der Zertifikate sind alle Regeln und Standards aus BSI [TR-02103](https://www.bsi.bund.de/SharedDocs/Downloads/DE/BSI/Publikationen/TechnischeRichtlinien/TR02103/BSI-TR-02103.pdf?__blob=publicationFile&v=4) zu beachten.
-**Für die Verwendbarkeit in fitconnect sind insbesondere die folgenden Anforderungen an die Verwaltungs-PKI besonders wichtig:**
+**Für die Verwendbarkeit in FIT-Connect sind insbesondere die folgenden Anforderungen an die Verwaltungs-PKI besonders wichtig:**
- Sie müssen eine Verwaltungs-PKI sein, sprich das [Wurzelzertifikat muss vom BSI stammen.](https://www.bsi.bund.de/DE/Themen/Oeffentliche-Verwaltung/Moderner-Staat/Verwaltungs-PKI/Wurzelzertifizierungsstelle/wurzelzertifizierungsstelle_node.html;jsessionid=E33702EEFB110FA230DDA266C9512436.internet471)
- Sie müssen über CRL Distribution Points (siehe 8.5 BSI [TR-02103](https://www.bsi.bund.de/SharedDocs/Downloads/DE/BSI/Publikationen/TechnischeRichtlinien/TR02103/BSI-TR-02103.pdf?__blob=publicationFile&v=4) ) verfügen.
@@ -40,7 +40,7 @@ Das generierte X.509 Zertifikat, alle Intermediate Zertifikate und das Wurzelzer
| ------- | ------------------------------------- | ------------------------------------------------------------ |
| kty | RSA | Gibt den Keytype nach [RFC 7517 Abschnitt 4](https://tools.ietf.org/html/rfc7517#section-4) an. |
| key_ops | [wrapKey] | Gibt die Funktion des Keys (Verschlüsselung des Verschlüsellungskeys) an. (nach [RFC 7517 Abschnitt 4.3](https://tools.ietf.org/html/rfc7517#section-4.3)) |
-| alg | PS512 | Gibt den Algorithmus der zur digitalen Signatur des Zertifikats verwendet werden muss an. Dieser muss im Fall von fitconnect immer PS512 sein. (vgl. [BSI TR-02102-1 Tabelle 4.1](https://www.bsi.bund.de/SharedDocs/Downloads/DE/BSI/Publikationen/TechnischeRichtlinien/TR02102/BSI-TR-02102.html)) |
+| alg | PS512 | Gibt den Algorithmus der zur digitalen Signatur des Zertifikats verwendet werden muss an. Dieser muss im Fall von FIT-Connect immer PS512 sein. (vgl. [BSI TR-02102-1 Tabelle 4.1](https://www.bsi.bund.de/SharedDocs/Downloads/DE/BSI/Publikationen/TechnischeRichtlinien/TR02102/BSI-TR-02102.html)) |
| x5c | die Zertifikatskette (base64 encoded) | Entspricht der Zertifikatskette vom Wurzelzertifikat bis zum Zertifikat selbst. ([Abschnitt 4.7 RFC 7518](https://tools.ietf.org/html/rfc7517#section-4.7)) |
| x5t | der Zertifikatsfingerprint | Der Fingerprint des Zertifikats selbst. ([Abschnitt 4.8 RFC 7518](https://tools.ietf.org/html/rfc7517#section-4.8)) |
| kid | eindeutige ID des Keys | Diese ID wird verwendet, um sie bei der Verschlüsselung des asymmetrischen Keys zur Verschlüsselung des Symetrischen Keys zur Inhaltsverschlüsselung zu referenzieren und somit darzustellen, welcher Key zur Entschlüsselung benötigt wird (siehe [RFC 7516 4.1.6](https://tools.ietf.org/html/rfc7516#section-4.1.6)) |
@@ -74,7 +74,7 @@ Die Auswahl welcher JSON Web Key aus der Liste der zur Verfügung gestellten Key
| ------- | ------------------------------------- | ------------------------------------------------------------ |
| kty | RSA | Gibt den Keytype nach [RFC 7515 Abschnitt 4](https://tools.ietf.org/html/rfc7515#section-4) an. |
| key_ops | [verify] | Gibt die Funktion des Keys (Verschlüsselung des Verschlüsellungskeys) an. (nach [RFC 7517 Abschnitt 4.3](https://tools.ietf.org/html/rfc7517#section-4.3)) |
-| alg | PS512 | Gibt den Algorithmus der zur digitalen Signatur des Zertifikats verwendet werden muss an. Dieser muss im Fall von fitconnect immer PS512 sein. (vgl. [BSI TR-02102-1 Tabelle 4.1](https://www.bsi.bund.de/SharedDocs/Downloads/DE/BSI/Publikationen/TechnischeRichtlinien/TR02102/BSI-TR-02102.html)) |
+| alg | PS512 | Gibt den Algorithmus der zur digitalen Signatur des Zertifikats verwendet werden muss an. Dieser muss im Fall von FIT-Connect immer PS512 sein. (vgl. [BSI TR-02102-1 Tabelle 4.1](https://www.bsi.bund.de/SharedDocs/Downloads/DE/BSI/Publikationen/TechnischeRichtlinien/TR02102/BSI-TR-02102.html)) |
| x5c | die Zertifikatskette (base64 encoded) | Entspricht der Zertifikatskette vom Wurzelzertifikat bis zum Zertifikat selbst. ([Abschnitt 4.7 RFC 7518](https://tools.ietf.org/html/rfc7517#section-4.7)) |
| x5t | der Zertifikatsfingerprint | Der Fingerprint des Zertifikats selbst. ([Abschnitt 4.1.7 RFC 7515](https://tools.ietf.org/html/rfc7515#section-4.1.7)) |
| kid | eindeutige ID des Keys | Diese ID wird verwendet, um zur Prüfung der Signatur den richtigen Key auswählen zu können. (siehe [RFC 7515 4.1.4](https://tools.ietf.org/html/rfc7515#section-4.1.4)) Als Format der ID wird UUID nach [RFC 4122](https://tools.ietf.org/html/rfc4122) empfohlen. |