From 444ce85e01541a8c219e8a4b4d446dd6cde60fcd Mon Sep 17 00:00:00 2001
From: Marco Holz <marco.holz@fitko.de>
Date: Tue, 29 Jun 2021 10:53:44 +0200
Subject: [PATCH] =?UTF-8?q?Kryptographische=20Vorgaben=20in=20eigene=20Dat?=
 =?UTF-8?q?ei=20=C3=BCberf=C3=BChrt?=
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

---
 docs/details/crypto.md      | 150 +++++++++++++++++++++++++++++++++++
 docs/details/encryption.mdx | 154 +-----------------------------------
 docs/details/event-log.md   |   1 +
 sidebars.js                 |   1 +
 4 files changed, 153 insertions(+), 153 deletions(-)
 create mode 100644 docs/details/crypto.md

diff --git a/docs/details/crypto.md b/docs/details/crypto.md
new file mode 100644
index 00000000..405da8fb
--- /dev/null
+++ b/docs/details/crypto.md
@@ -0,0 +1,150 @@
+# Vorgaben für kryptographische Verfahren
+
+FIT-Connect verwendet zur Übertragung von Antragsdaten und Metadaten mit direktem Bezug zu Anträgen eine Ende-zu-Ende-Verschlüsselung. Diese ist auf Basis des Standards [JSON Web Encryption (JWE)](https://tools.ietf.org/html/rfc7516) unter Verwendung von Schlüsseln gemäß des Standards [JSON Web Keys (JWK)](https://tools.ietf.org/html/rfc7517) umgesetzt.
+
+Zudem bietet FIT-Connect digital signierte Eingangsbestätigungen für Anträge. Die ausgestellten Signaturen werden auf Basis von [Security Event Tokens (SET)](https://tools.ietf.org/html/rfc8417) erzeugt und die dazugehörigen Schlüssel gemäß des Standards [JSON Web Keys (JWK)](https://tools.ietf.org/html/rfc7517) implementiert.
+
+Die [Liste der standardisierten Algorithmen](https://www.iana.org/assignments/jose/jose.xhtml#web-signature-encryption-algorithms) für Signaturen und Verschlüsselung mit JWE/JWS wird für die Nutzung in FIT-Connect unter Berücksichtigung der Vorgaben des BSI gemäß der Richtlinie [TR-02102-1](https://www.bsi.bund.de/SharedDocs/Downloads/DE/BSI/Publikationen/TechnischeRichtlinien/TR02102/BSI-TR-02102.html) eingeschränkt. Diese Einschränkung der zu unterstützenden Algorithmen senkt die Komplexität in Implementierungen der angebundenen Systeme und erfolgte unter Berücksichtigung der praktischen Nutzbarkeit der Algorithmen durch eine breite Unterstützung in Implementierungen der Standards.
+
+## Vorgaben für eingesetzte X.509-Zertifikate
+Dem JSON Web Key zur *Verschlüsselung von Antragsdaten* muss ein für die Empfangsbehörde der Einreichung signiertes X.509 Zertifikat zugrundeliegen. Dem für die *Signaturprüfung von digitalen Eingangsbestätigungen* verwendete JSON Web Key muss ein für die Behörde, die den Einreichung im FIT-Connect-System zwischenspeichert oder empfängt, signiertes X.509 Zertifikat zugrundeliegen. Bei der Erstellung von Zertifikaten und der Zertifikatsprüfung sind die Regelungen 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.
+
+Die verwendeten X.509-Zertifikate müssen der Verwaltungs-PKI entstammen. CA-Zertifikate der Zertifizierungsstellen innerhalb der Verwaltungs-PKI werden gemäß den [Vorgaben des BSI zur Verwaltungs-PKI](https://www.bsi.bund.de/VPKI) durch die Wurzelzertifizierungsstelle des BSI ausgestellt. Für Zertifikate müssen 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)) oder ein OCSP-Endpunkt (siehe 8.5.5 BSI [TR-02103](https://www.bsi.bund.de/SharedDocs/Downloads/DE/BSI/Publikationen/TechnischeRichtlinien/TR02103/BSI-TR-02103.pdf?__blob=publicationFile&v=4)) mit signierten Antworten nach [RFC 6125](https://tools.ietf.org/html/rfc6125) bereitstehen.
+
+Für die den JSON Web Keys zugrundeliegenden X.509-Zertifikate gelten die folgenden kryptographischen Vorgaben:
+
+| Feld                 | Inhalt     | **Erläuterung**                                              |
+| -------------------- | ---------- | ------------------------------------------------------------ |
+| Hashfunktion         | SHA-512    | Hashfunktion, die bei der Signatur des Zertifikats verwendet werden muss. (vgl. [BSI TR-02102-1 Tabelle 4.1](https://www.bsi.bund.de/SharedDocs/Downloads/DE/BSI/Publikationen/TechnischeRichtlinien/TR02102/BSI-TR-02102.html)). |
+| asym. Schlüssellänge | 4096 Bit   | Länge des zugrundeliegenden RSA-Schlüssels (vgl. [BSI TR-02102-1 Tabelle 3.1](https://www.bsi.bund.de/SharedDocs/Downloads/DE/BSI/Publikationen/TechnischeRichtlinien/TR02102/BSI-TR-02102.html)) |
+| Signaturalgorithmus  | 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) |
+
+## Vorgaben zur Ver- und Entschlüsselung von Daten
+### Vorgaben für JSON Web Keys zur Verschlüsselung
+
+Eine Verschlüsselung erfolgt in FIT-Connect auf Basis des Standards JSON Web Encryption gemäß [RFC 7516](https://tools.ietf.org/html/rfc7516).
+
+Zur Nutzung von Zertifikaten in FIT-Connect müssen diese in das JSON Web Key (JWK)-Format konvertiert werden. Das eingesetzte Zertifikat, alle Zertifikate im Zertifizierungspfad und das Wurzelzertifikat MÜSSEN dabei im Attribut `x5c` des JSON Web Key hinterlegt werden.
+
+Die Auswahl, welcher JSON Web Key aus der Liste der zur Verfügung gestellten Keys bei der Verschlüsselung verwendet werden muss, wird anhand der `kid` (Key ID) entschieden. Deshalb MUSS im JSON Web Key eine Key-ID angegeben sein.
+
+Der JSON Web Key muss über die folgenden Attribute gemäß [RFC 7517](https://tools.ietf.org/html/rfc7517#section-4) verfügen:
+
+
+| Feld      | Inhalt                                    | Erläuterung |
+| --------- | ----------------------------------------- | ----------- |
+| `kty`     | `"RSA"`                                   | Keytype gemäß [RFC 7517, Abschnitt 4](https://tools.ietf.org/html/rfc7517#section-4) |
+| `key_ops` | `["wrapKey"]`                             | Funktion des Keys (Verschlüsselung des symmetrischen Verschlüsselungskeys) gemäß [RFC 7517, Abschnitt 4.3](https://tools.ietf.org/html/rfc7517#section-4.3) |
+| `alg`     | `"RSA-OAEP-256"`                          | Vorgesehener Algorithmus zur Ver- und Entschlüsselung in Kombination mit diesem JWK. Vorgabe gemäß [BSI TR-02102-1, Abschnitt 3.6](https://www.bsi.bund.de/SharedDocs/Downloads/DE/BSI/Publikationen/TechnischeRichtlinien/TR02102/BSI-TR-02102.html) |
+| `x5c`     | *Die gemäß RFC kodierte Zertifikatskette* | Zertifikatskette vom Teilnehmer:innen-Zertifikat bis zum Wurzelzertifikat einschließlich aller Zwischenzertifikate gemäß [Abschnitt 4.7 RFC 7518](https://tools.ietf.org/html/rfc7517#section-4.7). Hinweis: Gemäß RFC muss das erste Zertifikat der hinterlegten Zertifikatskette dem Teilnehmer:innen-Zertifikat entsprechen. |
+| `kid`     | *Eindeutige ID des Keys*                  | Eindeutige ID zur Referenzierung des JSON Web Key gemäß [RFC 7516, Abschnitt 4.1.6](https://tools.ietf.org/html/rfc7516#section-4.1.6) dar. Es wird empfohlen, hierfür eine UUID gemäß [RFC 4122](https://tools.ietf.org/html/rfc4122) zu verwenden. |
+| `n`       | *Modulus des Public Key zum Zertifikat*   | Der Modulus des Public Key gemäß [RFC 7518, Abschitt 6.3.1.1](https://tools.ietf.org/html/rfc7518.html#section-6.3.1.1) ("Base64urlUInt" enkodiert) |
+| `e`       | `"AQAB"`                                  | Der Exponent des Public Key gemäß [RFC 7518, Abschitt 6.3.1.2](https://tools.ietf.org/html/rfc7518.html#section-6.3.1.2)) |
+
+Das bedeutet, der JSON Web Key zur Verschlüsselung muss diesem Format entsprechen:
+
+```json
+{
+  "kty": "RSA",
+  "key_ops": ["wrapKey"],
+  "alg": "RSA-OAEP-256",
+  "n": "……(Public Key)……",
+  "e": "AQAB",
+  "kid": "……(Key ID)……",
+  "x5t": "……(Fingerprint)……",
+  "x5c": [
+      "……(base64 encoded cert)……",
+      "……(base64 encoded intermediate cert)……",
+      "……(base64 encoded root cert)……"
+  ]
+}
+```
+
+### Algorithmen zur Verschlüsselung des Antragsinhalts mit JSON Web Encryption
+
+Zur Verschlüsselung des eigentlichen Antragsinhalts wird ein symmetrisches Verschlüsselungsverfahren mit symmetrischem Schlüssel verwendet. Dieser symmetrische Schlüssel wird mit den asymmetrischen JSON Web Keys, die vom **Fachverfahren** generiert werden und die Verwendungsart **"wrapKey"** haben müssen, asymmetrisch verschlüsselt.
+
+Der Content im verschlüsselten JSON Web Encryption Objekt muss mit den folgenden Methoden verschlüsselt werden:
+
+- Symmetrisches Verschlüsselungsverfahren zur Verschlüsselung der Formularinhalts- sowie der Metadaten ("Payload"): AES-256 mit der Betriebsart Galois/Counter-Mode (GCM) gemäß [TR-02102, Abschnitt 2.1](https://www.bsi.bund.de/SharedDocs/Downloads/DE/BSI/Publikationen/TechnischeRichtlinien/TR02102/BSI-TR-02102.html)
+- Asymmetrisches Verschlüsselungsverfahren, um den symmetrischen Schlüssel zu verschlüsseln: RSA-OAEP-256 (RSA mit Optimal Asymmetric Encryption Padding (OAEP) unter Verwendung der Mask Generation Function MGF1 und der Hashfunktion SHA-256). Vorgabe gemäß [BSI TR-02102-1, Abschnitt 3.6](https://www.bsi.bund.de/SharedDocs/Downloads/DE/BSI/Publikationen/TechnischeRichtlinien/TR02102/BSI-TR-02102.html)
+
+#### JSON Web Encryption Header
+Im Header des JSON Web Encryption Objektes werden die Verschlüsselungs-Metadaten zu den verschlüsselten Inhaltsdaten übergeben. Header-Attribute werden in [RFC 7516](https://tools.ietf.org/html/rfc7516) definiert. Zu Übermittlung der verschlüsselten Daten wird das in [RFC 7516 Abschnitt 7.1](https://tools.ietf.org/html/rfc7516#section-7.1) beschriebene Verfahren "JWE Compact Serialization" verwendet.
+
+Die folgenden Attribute müssen im JOSE-Header bei der Übertragung verschlüsselter Daten zwingend definiert sein:
+
+| Feld   | Inhalt             | Erläuterung |
+| ------ | ------------------ | ----------- |
+| `alg`  | `"RSA-OAEP-256"`   | Asymmetrisches Verschlüsselungsverfahren, um den „Content Encryption Key“ (CEK) zu verschlüsseln, mit dem der Payload über das in „enc“ angegebene Verfahren symmetrisch verschlüsselt wurde. Hierfür wird der im Header per "kid" referenzierte öffentliche Schlüssel genutzt. Bezeichner des Algorithmus gemäß [RFC 7518, Abschnitt 4.1](https://tools.ietf.org/html/rfc7518#section-4.1). Vorgabe gemäß [BSI TR-02102-1, Abschnitt 3.6](https://www.bsi.bund.de/SharedDocs/Downloads/DE/BSI/Publikationen/TechnischeRichtlinien/TR02102/BSI-TR-02102.html) |
+| `enc`  | `"A256GCM"`        | Symmetrisches Verschlüsselungsverfahren zur Verschlüsselung des Payloads. Bezeichner gemäß [RFC 7518 5.1](https://tools.ietf.org/html/rfc7518#section-5.1). Vorgabe gemäß [TR-02102, Abschnitt 2.1](https://www.bsi.bund.de/SharedDocs/Downloads/DE/BSI/Publikationen/TechnischeRichtlinien/TR02102/BSI-TR-02102.html) |
+| `zip`  | `"DEF"`            | Der Komprimieriungsalgorithmus für die Inhaltsdaten nach [RFC 7516 Abschnit 4.1.3](https://tools.ietf.org/html/rfc7516#section-4.1.3) |
+| `kid`  | *ID des Public Keys* | Die ID des JSON Web Keys mit dem Attribute "wrapKey", der zur Verschlüsselung des symmetrischen Keys verwendet wurde. Gemäß [RFC 7516, Abschnitt 4.1.6](https://tools.ietf.org/html/rfc7516#section-4.1.6)). Als Format der ID wird UUID nach [RFC 4122](https://tools.ietf.org/html/rfc4122) empfohlen. |
+| `cty`  | *MIME-Type der Inhaltsdaten* | MIME-Type der Inhaltsdaten (Fachdaten, Medatadaten) nach [RFC 7516, Abschnitt 4.1.12](https://tools.ietf.org/html/rfc7516#section-4.1.12) |
+
+## Vorgaben zur Signaturerstellung und -prüfung
+### Vorgaben für JSON Web Keys zur Signaturprüfung
+
+Eine Signaturprüfung erfolgt in FIT-Connect auf Basis des Standards JSON Web Signature gemäß [RFC 7515](https://tools.ietf.org/html/rfc7515).
+
+Zur Nutzung von Zertifikaten in FIT-Connect müssen diese in das JSON Web Key-Format konvertiert werden. Das eingesetzte Zertifikat, alle Zertifikate im Zertifizierungspfad und das Wurzelzertifikat müssen dabei im Attribut `x5c` des JSON Web Key hinterlegt werden.
+
+Der JSON Web Key muss über die folgenden Attribute gemäß [RFC 7515](https://tools.ietf.org/html/rfc7515#section-4) verfügen.
+
+| Feld      | Inhalt                                    | **Erläuterung**                                              |
+| --------- | ----------------------------------------- | ------------------------------------------------------------ |
+| `kty`     | `"RSA"`                                   | Keytype gemäß [RFC 7517, Abschnitt 4](https://tools.ietf.org/html/rfc7517#section-4) |
+| `key_ops` | `["verify"]`                              | Funktion des Keys (Prüfung von digitalen Signaturen) gemäß [RFC 7517, Abschnitt 4.3](https://tools.ietf.org/html/rfc7517#section-4.3) |
+| `alg`     | `"PS512"`                                 | Vorgesehener Algorithmus zur Erstellung und Prüfung von Signaturen in Kombination mit diesem JWK. Vorgabe gemäß [BSI TR-02102-1, Abschnitt 5.4.1](https://www.bsi.bund.de/SharedDocs/Downloads/DE/BSI/Publikationen/TechnischeRichtlinien/TR02102/BSI-TR-02102.html) |
+| `x5c`     | *Die gemäß RFC kodierte Zertifikatskette* | Zertifikatskette vom Teilnehmer:innen-Zertifikat bis zum Wurzelzertifikat einschließlich aller Zwischenzertifikate gemäß [Abschnitt 4.7 RFC 7518](https://tools.ietf.org/html/rfc7517#section-4.7). Hinweis: Gemäß RFC muss das erste Zertifikat der hinterlegten Zertifikatskette dem Teilnehmer:innen-Zertifikat entsprechen. |
+| `kid`     | *Eindeutige ID des Keys*                  | Eindeutige ID zur Referenzierung des JSON Web Key gemäß [RFC 7515, Abschnitt 4.1.4](https://tools.ietf.org/html/rfc7515#section-4.1.4) dar. Es wird empfohlen, hierfür eine UUID gemäß [RFC 4122](https://tools.ietf.org/html/rfc4122) zu verwenden. |
+| `n`       | *Modulus des Public Key zum Zertifikat*   | Der Modulus des Public Key gemäß [RFC 7518, Abschitt 6.3.1.1](https://tools.ietf.org/html/rfc7518.html#section-6.3.1.1) ("Base64urlUInt" enkodiert) |
+| `e`       | `"AQAB"`                                  | Der Exponent des Public Key gemäß [RFC 7518, Abschitt 6.3.1.2](https://tools.ietf.org/html/rfc7518.html#section-6.3.1.2)) |
+
+Das bedeutet, der JSON Web Key zur Prüfung von digitalen Signaturen muss dem folgenden Format entsprechen:
+
+```json
+{
+  "kty": "RSA",
+  "key_ops": ["verify"],
+  "alg": "PS512",
+  "n": "……(Public Key)……",
+  "e": "AQAB",
+  "kid": "……(Key ID)……",
+  "x5t": "……(Fingerprint)……",
+  "x5c": [
+      "……(base64 encoded cert)……"
+      "……(base64 encoded intermediate cert)……",
+      "……(base64 encoded root cert)……",
+  ]
+}
+```
+
+Nicht mehr verwendete JSON Web Keys für Signaturen müssen nach Ende der Verwendung weiterhin bis zum Ende ihrer Gültigkeitsdauer über den Endpunkt (bzw. die Destination-ID) abrufbar sein. Das soll sicherstellen, das auch bei bereits versendete Anträgen weiterhin der Antragsstatus verifiziert werden kann.
+
+### Algorithmen zur Signaturerstellung
+
+Für die Bereitstellung von signierten Statusinformationen über Security Event Tokens gemäß [RFC 8417](https://tools.ietf.org/html/rfc8417) wird der Standard [JSON Web Signature](https://tools.ietf.org/html/rfc7515) eingesetzt.
+
+Zur Signatur der Event Tokens verfügt der Server, der die Tokens ausstellt, über einen Signaturschlüssel. Bei der Verwaltung der Signaturschlüssel sind insbesondere die Hinweise in [BSI TR-03116-4, Abschnitt 6](https://www.bsi.bund.de/SharedDocs/Downloads/DE/BSI/Publikationen/TechnischeRichtlinien/TR03116/BSI-TR-03116-4.html) und [BSI TR-02102-1, Abschnitt 8](https://www.bsi.bund.de/SharedDocs/Downloads/DE/BSI/Publikationen/TechnischeRichtlinien/TR02102/BSI-TR-02102.html) zu beachten. Der zu dem auf dem Server verwendeten Signaturschlüssel zugehörige Public Key muss als JSON Web Key bereitgestellt werden.
+
+Als Algorithmus für die Signatur muss RSASSA-PSS in Verbindung mit SHA-512 eingesetzt werden. Das Entspricht dem Standard beschrieben in [RFC 7518 Abschnitt 3.5](https://tools.ietf.org/html/rfc7518.html#section-3.5) und wird vom BSI als Signaturverfahren 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) empfohlen.
+
+#### JSON Web Signature Header
+Zu Übermittlung der Signatur wird das in [RFC 7515, Abschnitt 7.1](https://tools.ietf.org/html/rfc7515#section-7.1) beschriebene Verfahren "JWS Compact Serialization" verwendet.
+
+Die folgenden Attribute müssen im JOSE-Header bei der Übertragung signierter Daten zwingend definiert sein:
+
+| Feld  | Inhalt             | Erläuterung |
+| ----- | ------------------ | ----------- |
+| `alg` | `"PS512"`          | Legt RSASSA-PSS mit SHA512 als Algorithmus für die Signatur fest. Bezeichner gemäß [RFC 7518, Abschnitt 3.5](https://tools.ietf.org/html/rfc7518.html#section-3.5) |
+| `kid` | *ID des Public Keys* | Die ID des JSON Web Keys mit dem Attribute "verify" aus dem von der Subscriber-API bereitgestellten Keysets, der zur Verifizierung der Signatur dient. Gemäß [RFC7515, Abschnitt 4.1.4](https://tools.ietf.org/html/rfc7515#section-4.1.4). |
+| `cty` | *MIME-Type der Inhaltsdaten* | MIME-Type der Inhaltsdaten (Fachdaten, Medatadaten) nach [RFC 7515, Abschnitt 4.1.10](https://tools.ietf.org/html/rfc7515#section-4.1.10) |
+
+
+## Vorgaben für JSON Web Tokens (JWTs)
+Alle generierten JWT-Tokens MÜSSEN den Vorgaben aus [RFC 7519](https://tools.ietf.org/html/rfc7519) entsprechen und über folgende Header-Attribute verfügen:
+
+| Feld  | Inhalt  | Erläuterung |
+| ----- | ------- | ----------- |
+| `alg` | `PS512` | Zur Signaturerstellung wird der Signaturalgorithmus RSASSA-PSS mit SHA-512 und MGF1 mit SHA-512 verwendet. |
diff --git a/docs/details/encryption.mdx b/docs/details/encryption.mdx
index aa80e860..3e43f926 100644
--- a/docs/details/encryption.mdx
+++ b/docs/details/encryption.mdx
@@ -6,7 +6,7 @@ title: Verschlüsselung
 
 ## Einleitung
 
-FIT-Connect verwendet zur Übertragung von Antragsdaten und Antragsmetadaten (abgesehen von den für die Übermittlung zwingend notwendigen Daten, z.B. Destination-ID) eine Ende-zu-Ende-Verschlüsselung. Diese ist auf Basis der Standards [JSON Web Encryption (JWE)](https://tools.ietf.org/html/rfc7516) und [JSON Web Keys (JWK)](https://tools.ietf.org/html/rfc7517) umgesetzt.
+FIT-Connect verwendet zur Übertragung von Antragsdaten und Antragsmetadaten (abgesehen von den für die Übermittlung zwingend notwendigen Daten, z.B. Destination-ID) eine Ende-zu-Ende-Verschlüsselung. Diese ist auf Basis der Standards [JSON Web Encryption (JWE)](https://tools.ietf.org/html/rfc7516) und [JSON Web Keys (JWK)](https://tools.ietf.org/html/rfc7517) umgesetzt. Bei der Implementierung der Ende-zu-Ende-Verschlüsselung MÜSSEN die [Vorgaben für kryptographische Verfahren](./crypto.md) beachtet werden.
 
 Die Informationen auf dieser Seite sind relevant, wenn man:
 
@@ -212,155 +212,3 @@ OcFhj3XGUshVKec2nRhtCZPOMPTIjxFpozsiRetjZo9LFHzRcvr1eSS_hpteKJ3ltioY9nzt1IX2JqQm
 TGtY.VGOCnGM9LEZP5mUO.LQeKj4SKqsUNsBp4ZRN_56QbS8MQ01YTzRVFStk.Z0YMEua9kvCV7LkeJH
 kprA
 ```
-
-
-# Vorgaben für kryptographische Verfahren
-
-FIT-Connect verwendet zur Übertragung von Antragsdaten und Metadaten mit direktem Bezug zu Anträgen eine Ende-zu-Ende-Verschlüsselung. Diese ist auf Basis des Standards [JSON Web Encryption (JWE)](https://tools.ietf.org/html/rfc7516) unter Verwendung von Schlüsseln gemäß des Standards [JSON Web Keys (JWK)](https://tools.ietf.org/html/rfc7517) umgesetzt.
-
-Zudem bietet FIT-Connect digital signierte Eingangsbestätigungen für Anträge. Die ausgestellten Signaturen werden auf Basis von [Security Event Tokens (SET)](https://tools.ietf.org/html/rfc8417) erzeugt und die dazugehörigen Schlüssel gemäß des Standards [JSON Web Keys (JWK)](https://tools.ietf.org/html/rfc7517) implementiert.
-
-Die [Liste der standardisierten Algorithmen](https://www.iana.org/assignments/jose/jose.xhtml#web-signature-encryption-algorithms) für Signaturen und Verschlüsselung mit JWE/JWS wird für die Nutzung in FIT-Connect unter Berücksichtigung der Vorgaben des BSI gemäß der Richtlinie [TR-02102-1](https://www.bsi.bund.de/SharedDocs/Downloads/DE/BSI/Publikationen/TechnischeRichtlinien/TR02102/BSI-TR-02102.html) eingeschränkt. Diese Einschränkung der zu unterstützenden Algorithmen senkt die Komplexität in Implementierungen der angebundenen Systeme und erfolgte unter Berücksichtigung der praktischen Nutzbarkeit der Algorithmen durch eine breite Unterstützung in Implementierungen der Standards.
-
-## Vorgaben für eingesetzte X.509-Zertifikate
-Dem JSON Web Key zur *Verschlüsselung von Antragsdaten* muss ein für die Empfangsbehörde der Einreichung signiertes X.509 Zertifikat zugrundeliegen. Dem für die *Signaturprüfung von digitalen Eingangsbestätigungen* verwendete JSON Web Key muss ein für die Behörde, die den Einreichung im FIT-Connect-System zwischenspeichert oder empfängt, signiertes X.509 Zertifikat zugrundeliegen. Bei der Erstellung von Zertifikaten und der Zertifikatsprüfung sind die Regelungen 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.
-
-Die verwendeten X.509-Zertifikate müssen der Verwaltungs-PKI entstammen. CA-Zertifikate der Zertifizierungsstellen innerhalb der Verwaltungs-PKI werden gemäß den [Vorgaben des BSI zur Verwaltungs-PKI](https://www.bsi.bund.de/VPKI) durch die Wurzelzertifizierungsstelle des BSI ausgestellt. Für Zertifikate müssen 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)) oder ein OCSP-Endpunkt (siehe 8.5.5 BSI [TR-02103](https://www.bsi.bund.de/SharedDocs/Downloads/DE/BSI/Publikationen/TechnischeRichtlinien/TR02103/BSI-TR-02103.pdf?__blob=publicationFile&v=4)) mit signierten Antworten nach [RFC 6125](https://tools.ietf.org/html/rfc6125) bereitstehen.
-
-Für die den JSON Web Keys zugrundeliegenden X.509-Zertifikate gelten die folgenden kryptographischen Vorgaben:
-
-| Feld                 | Inhalt     | **Erläuterung**                                              |
-| -------------------- | ---------- | ------------------------------------------------------------ |
-| Hashfunktion         | SHA-512    | Hashfunktion, die bei der Signatur des Zertifikats verwendet werden muss. (vgl. [BSI TR-02102-1 Tabelle 4.1](https://www.bsi.bund.de/SharedDocs/Downloads/DE/BSI/Publikationen/TechnischeRichtlinien/TR02102/BSI-TR-02102.html)). |
-| asym. Schlüssellänge | 4096 Bit   | Länge des zugrundeliegenden RSA-Schlüssels (vgl. [BSI TR-02102-1 Tabelle 3.1](https://www.bsi.bund.de/SharedDocs/Downloads/DE/BSI/Publikationen/TechnischeRichtlinien/TR02102/BSI-TR-02102.html)) |
-| Signaturalgorithmus  | 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) |
-
-## Vorgaben zur Ver- und Entschlüsselung von Daten
-### Vorgaben für JSON Web Keys zur Verschlüsselung
-
-Eine Verschlüsselung erfolgt in FIT-Connect auf Basis des Standards JSON Web Encryption gemäß [RFC 7516](https://tools.ietf.org/html/rfc7516).
-
-Zur Nutzung von Zertifikaten in FIT-Connect müssen diese in das JSON Web Key (JWK)-Format konvertiert werden. Das eingesetzte Zertifikat, alle Zertifikate im Zertifizierungspfad und das Wurzelzertifikat MÜSSEN dabei im Attribut `x5c` des JSON Web Key hinterlegt werden.
-
-Die Auswahl, welcher JSON Web Key aus der Liste der zur Verfügung gestellten Keys bei der Verschlüsselung verwendet werden muss, wird anhand der `kid` (Key ID) entschieden. Deshalb MUSS im JSON Web Key eine Key-ID angegeben sein.
-
-Der JSON Web Key muss über die folgenden Attribute gemäß [RFC 7517](https://tools.ietf.org/html/rfc7517#section-4) verfügen:
-
-
-| Feld    | Inhalt                                    | **Erläuterung**                                              |
-| ------- | ----------------------------------------- | ------------------------------------------------------------ |
-| kty     | "RSA"                                     | Keytype gemäß [RFC 7517, Abschnitt 4](https://tools.ietf.org/html/rfc7517#section-4) |
-| key_ops | ["wrapKey"]                               | Funktion des Keys (Verschlüsselung des symmetrischen Verschlüsselungskeys) gemäß [RFC 7517, Abschnitt 4.3](https://tools.ietf.org/html/rfc7517#section-4.3) |
-| alg     | "RSA-OAEP-256"                            | Vorgesehener Algorithmus zur Ver- und Entschlüsselung in Kombination mit diesem JWK. Vorgabe gemäß [BSI TR-02102-1, Abschnitt 3.6](https://www.bsi.bund.de/SharedDocs/Downloads/DE/BSI/Publikationen/TechnischeRichtlinien/TR02102/BSI-TR-02102.html) |
-| x5c     | *Die gemäß RFC kodierte Zertifikatskette* | Zertifikatskette vom Teilnehmer:innen-Zertifikat bis zum Wurzelzertifikat einschließlich aller Zwischenzertifikate gemäß [Abschnitt 4.7 RFC 7518](https://tools.ietf.org/html/rfc7517#section-4.7). Hinweis: Gemäß RFC muss das erste Zertifikat der hinterlegten Zertifikatskette dem Teilnehmer:innen-Zertifikat entsprechen. |
-| kid     | *Eindeutige ID des Keys*                  | Eindeutige ID zur Referenzierung des JSON Web Key gemäß [RFC 7516, Abschnitt 4.1.6](https://tools.ietf.org/html/rfc7516#section-4.1.6) dar. Es wird empfohlen, hierfür eine UUID gemäß [RFC 4122](https://tools.ietf.org/html/rfc4122) zu verwenden. |
-| n       | *Modulus des Public Key zum Zertifikat*   | Der Modulus des Public Key gemäß [RFC 7518, Abschitt 6.3.1.1](https://tools.ietf.org/html/rfc7518.html#section-6.3.1.1) ("Base64urlUInt" enkodiert) |
-| e       | "AQAB"                                    | Der Exponent des Public Key gemäß [RFC 7518, Abschitt 6.3.1.2](https://tools.ietf.org/html/rfc7518.html#section-6.3.1.2)) |
-
-Das bedeutet, der JSON Web Key zur Verschlüsselung muss diesem Format entsprechen:
-
-```json
-{
-  "kty": "RSA",
-  "key_ops": ["wrapKey"],
-  "alg": "RSA-OAEP-256",
-  "n": "……(Public Key)……",
-  "e": "AQAB",
-  "kid": "……(Key ID)……",
-  "x5t": "……(Fingerprint)……",
-  "x5c": [
-      "……(base64 encoded cert)……",
-      "……(base64 encoded intermediate cert)……",
-      "……(base64 encoded root cert)……"
-  ]
-}
-```
-
-### Algorithmen zur Verschlüsselung des Antragsinhalts mit JSON Web Encryption
-
-Zur Verschlüsselung des eigentlichen Antragsinhalts wird ein symmetrisches Verschlüsselungsverfahren mit symmetrischem Schlüssel verwendet. Dieser symmetrische Schlüssel wird mit den asymmetrischen JSON Web Keys, die vom **Fachverfahren** generiert werden und die Verwendungsart **"wrapKey"** haben müssen, asymmetrisch verschlüsselt.
-
-Der Content im verschlüsselten JSON Web Encryption Objekt muss mit den folgenden Methoden verschlüsselt werden:
-
-- Symmetrisches Verschlüsselungsverfahren zur Verschlüsselung der Formularinhalts- sowie der Metadaten ("Payload"): AES-256 mit der Betriebsart Galois/Counter-Mode (GCM) gemäß [TR-02102, Abschnitt 2.1](https://www.bsi.bund.de/SharedDocs/Downloads/DE/BSI/Publikationen/TechnischeRichtlinien/TR02102/BSI-TR-02102.html)
-- Asymmetrisches Verschlüsselungsverfahren, um den symmetrischen Schlüssel zu verschlüsseln: RSA-OAEP-256 (RSA mit Optimal Asymmetric Encryption Padding (OAEP) unter Verwendung der Mask Generation Function MGF1 und der Hashfunktion SHA-256). Vorgabe gemäß [BSI TR-02102-1, Abschnitt 3.6](https://www.bsi.bund.de/SharedDocs/Downloads/DE/BSI/Publikationen/TechnischeRichtlinien/TR02102/BSI-TR-02102.html)
-
-#### JSON Web Encryption Header
-Im Header des JSON Web Encryption Objektes werden die Verschlüsselungs-Metadaten zu den verschlüsselten Inhaltsdaten übergeben. Header-Attribute werden in [RFC 7516](https://tools.ietf.org/html/rfc7516) definiert. Zu Übermittlung der verschlüsselten Daten wird das in [RFC 7516 Abschnitt 7.1](https://tools.ietf.org/html/rfc7516#section-7.1) beschriebene Verfahren "JWE Compact Serialization" verwendet.
-
-Die folgenden Attribute müssen im JOSE-Header bei der Übertragung verschlüsselter Daten zwingend definiert sein:
-
-| Feld | Inhalt             | **Erläuterung**                                              |
-| ---- | ------------------ | ------------------------------------------------------------ |
-| alg  | "RSA-OAEP-256"     | Asymmetrisches Verschlüsselungsverfahren, um den „Content Encryption Key“ (CEK) zu verschlüsseln, mit dem der Payload über das in „enc“ angegebene Verfahren symmetrisch verschlüsselt wurde. Hierfür wird der im Header per "kid" referenzierte öffentliche Schlüssel genutzt. Bezeichner des Algorithmus gemäß [RFC 7518, Abschnitt 4.1](https://tools.ietf.org/html/rfc7518#section-4.1). Vorgabe gemäß [BSI TR-02102-1, Abschnitt 3.6](https://www.bsi.bund.de/SharedDocs/Downloads/DE/BSI/Publikationen/TechnischeRichtlinien/TR02102/BSI-TR-02102.html) |
-| enc  | "A256GCM"          | Symmetrisches Verschlüsselungsverfahren zur Verschlüsselung des Payloads. Bezeichner gemäß [RFC 7518 5.1](https://tools.ietf.org/html/rfc7518#section-5.1). Vorgabe gemäß [TR-02102, Abschnitt 2.1](https://www.bsi.bund.de/SharedDocs/Downloads/DE/BSI/Publikationen/TechnischeRichtlinien/TR02102/BSI-TR-02102.html) |
-| zip  | "DEF"              | Der Komprimieriungsalgorithmus für die Inhaltsdaten nach [RFC 7516 Abschnit 4.1.3](https://tools.ietf.org/html/rfc7516#section-4.1.3) |
-| kid  | *ID des Public Keys* | Die ID des JSON Web Keys mit dem Attribute "wrapKey", der zur Verschlüsselung des symmetrischen Keys verwendet wurde. Gemäß [RFC 7516, Abschnitt 4.1.6](https://tools.ietf.org/html/rfc7516#section-4.1.6)). Als Format der ID wird UUID nach [RFC 4122](https://tools.ietf.org/html/rfc4122) empfohlen. |
-| cty  | *MIME-Type der Inhaltsdaten* | MIME-Type der Inhaltsdaten (Fachdaten, Medatadaten) nach [RFC 7516, Abschnitt 4.1.12](https://tools.ietf.org/html/rfc7516#section-4.1.12) |
-
-## Vorgaben zur Signaturerstellung und -prüfung
-### Vorgaben für JSON Web Keys zur Signaturprüfung
-
-Eine Signaturprüfung erfolgt in FIT-Connect auf Basis des Standards JSON Web Signature gemäß [RFC 7515](https://tools.ietf.org/html/rfc7515).
-
-Zur Nutzung von Zertifikaten in FIT-Connect müssen diese in das JSON Web Key-Format konvertiert werden. Das eingesetzte Zertifikat, alle Zertifikate im Zertifizierungspfad und das Wurzelzertifikat müssen dabei im Attribut `x5c` des JSON Web Key hinterlegt werden.
-
-Der JSON Web Key muss über die folgenden Attribute gemäß [RFC 7515](https://tools.ietf.org/html/rfc7515#section-4) verfügen.
-
-| Feld    | Inhalt                                    | **Erläuterung**                                              |
-| ------- | ----------------------------------------- | ------------------------------------------------------------ |
-| kty     | "RSA"                                     | Keytype gemäß [RFC 7517, Abschnitt 4](https://tools.ietf.org/html/rfc7517#section-4) |
-| key_ops | ["verify"]                                | Funktion des Keys (Prüfung von digitalen Signaturen) gemäß [RFC 7517, Abschnitt 4.3](https://tools.ietf.org/html/rfc7517#section-4.3) |
-| alg     | "PS512"                                   | Vorgesehener Algorithmus zur Erstellung und Prüfung von Signaturen in Kombination mit diesem JWK. Vorgabe gemäß [BSI TR-02102-1, Abschnitt 5.4.1](https://www.bsi.bund.de/SharedDocs/Downloads/DE/BSI/Publikationen/TechnischeRichtlinien/TR02102/BSI-TR-02102.html) |
-| x5c     | *Die gemäß RFC kodierte Zertifikatskette* | Zertifikatskette vom Teilnehmer:innen-Zertifikat bis zum Wurzelzertifikat einschließlich aller Zwischenzertifikate gemäß [Abschnitt 4.7 RFC 7518](https://tools.ietf.org/html/rfc7517#section-4.7). Hinweis: Gemäß RFC muss das erste Zertifikat der hinterlegten Zertifikatskette dem Teilnehmer:innen-Zertifikat entsprechen. |
-| kid     | *Eindeutige ID des Keys*                  | Eindeutige ID zur Referenzierung des JSON Web Key gemäß [RFC 7515, Abschnitt 4.1.4](https://tools.ietf.org/html/rfc7515#section-4.1.4) dar. Es wird empfohlen, hierfür eine UUID gemäß [RFC 4122](https://tools.ietf.org/html/rfc4122) zu verwenden. |
-| n       | *Modulus des Public Key zum Zertifikat* | Der Modulus des Public Key gemäß [RFC 7518, Abschitt 6.3.1.1](https://tools.ietf.org/html/rfc7518.html#section-6.3.1.1) ("Base64urlUInt" enkodiert) |
-| e       | "AQAB"                                  | Der Exponent des Public Key gemäß [RFC 7518, Abschitt 6.3.1.2](https://tools.ietf.org/html/rfc7518.html#section-6.3.1.2)) |
-
-Das bedeutet, der JSON Web Key zur Prüfung von digitalen Signaturen muss dem folgenden Format entsprechen:
-
-```json
-{
-  "kty": "RSA",
-  "key_ops": ["verify"],
-  "alg": "PS512",
-  "n": "……(Public Key)……",
-  "e": "AQAB",
-  "kid": "……(Key ID)……",
-  "x5t": "……(Fingerprint)……",
-  "x5c": [
-      "……(base64 encoded cert)……"
-      "……(base64 encoded intermediate cert)……",
-      "……(base64 encoded root cert)……",
-  ]
-}
-```
-
-Nicht mehr verwendete JSON Web Keys für Signaturen müssen nach Ende der Verwendung weiterhin bis zum Ende ihrer Gültigkeitsdauer über den Endpunkt (bzw. die Destination-ID) abrufbar sein. Das soll sicherstellen, das auch bei bereits versendete Anträgen weiterhin der Antragsstatus verifiziert werden kann.
-
-### Algorithmen zur Signaturerstellung
-
-Für die Bereitstellung von signierten Statusinformationen über Security Event Tokens gemäß [RFC 8417](https://tools.ietf.org/html/rfc8417) wird der Standard [JSON Web Signature](https://tools.ietf.org/html/rfc7515) eingesetzt.
-
-Zur Signatur der Event Tokens verfügt der Server, der die Tokens ausstellt, über einen Signaturschlüssel. Bei der Verwaltung der Signaturschlüssel sind insbesondere die Hinweise in [BSI TR-03116-4, Abschnitt 6](https://www.bsi.bund.de/SharedDocs/Downloads/DE/BSI/Publikationen/TechnischeRichtlinien/TR03116/BSI-TR-03116-4.html) und [BSI TR-02102-1, Abschnitt 8](https://www.bsi.bund.de/SharedDocs/Downloads/DE/BSI/Publikationen/TechnischeRichtlinien/TR02102/BSI-TR-02102.html) zu beachten. Der zu dem auf dem Server verwendeten Signaturschlüssel zugehörige Public Key muss als JSON Web Key bereitgestellt werden.
-
-Als Algorithmus für die Signatur muss RSASSA-PSS in Verbindung mit SHA-512 eingesetzt werden. Das Entspricht dem Standard beschrieben in [RFC 7518 Abschnitt 3.5](https://tools.ietf.org/html/rfc7518.html#section-3.5) und wird vom BSI als Signaturverfahren 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) empfohlen.
-
-#### JSON Web Signature Header
-Zu Übermittlung der Signatur wird das in [RFC 7515, Abschnitt 7.1](https://tools.ietf.org/html/rfc7515#section-7.1) beschriebene Verfahren "JWS Compact Serialization" verwendet.
-
-Die folgenden Attribute müssen im JOSE-Header bei der Übertragung signierter Daten zwingend definiert sein:
-
-| Feld | Inhalt             | Erläuterung                                                  |
-| ---- | ------------------ | ------------------------------------------------------------ |
-| alg  | "PS512"            | Legt RSASSA-PSS mit SHA512 als Algorithmus für die Signatur fest. Bezeichner gemäß [RFC 7518, Abschnitt 3.5](https://tools.ietf.org/html/rfc7518.html#section-3.5) |
-| kid  | *ID des Public Keys* | Die ID des JSON Web Keys mit dem Attribute "verify" aus dem von der Subscriber-API bereitgestellten Keysets, der zur Verifizierung der Signatur dient. Gemäß [RFC7515, Abschnitt 4.1.4](https://tools.ietf.org/html/rfc7515#section-4.1.4). |
-| cty  | *MIME-Type der Inhaltsdaten* | MIME-Type der Inhaltsdaten (Fachdaten, Medatadaten) nach [RFC 7515, Abschnitt 4.1.10](https://tools.ietf.org/html/rfc7515#section-4.1.10) |
-
-
-## Vorgaben für JSON Web Tokens (JWTs)
-Alle generierten JWT-Tokens MÜSSEN den Vorgaben aus [RFC 7519](https://tools.ietf.org/html/rfc7519) entsprechen und über folgende Header-Attribute verfügen:
-
-| Feld  | Inhalt  | **Erläuterung** |
-| ----- | ------- | --------------- |
-| `alg` | `PS512` | Zur Signaturerstellung wird der Signaturalgorithmus RSASSA-PSS mit SHA-512 und MGF1 mit SHA-512 verwendet. |
diff --git a/docs/details/event-log.md b/docs/details/event-log.md
index e4b47613..b72745a5 100644
--- a/docs/details/event-log.md
+++ b/docs/details/event-log.md
@@ -3,6 +3,7 @@
 Im Ereignisprotokoll werden relevante Ereignisse (events) aufgezeichnet.
 Beim Abruf des Ereignisprotokoll liefert die API ein Array von JSON Web Token (JWT) gemäß [RFC 7519](https://datatracker.ietf.org/doc/html/rfc7519).
 Der JWT ist einen Security Event Token (SET) gemäß [RFC 8417](https://datatracker.ietf.org/doc/html/rfc8417).
+Bei der Erstellung und Prüfung der Security Event Token MÜSSEN die [Vorgaben für kryptographische Verfahren](./crypto.md) beachtet werden.
 
 ## Aufbau eines Security Event Token (SET)
 
diff --git a/sidebars.js b/sidebars.js
index f410463f..63a9b658 100644
--- a/sidebars.js
+++ b/sidebars.js
@@ -74,6 +74,7 @@ module.exports = {
       items: [
         'details/encryption',
         'details/event-log',
+        'details/crypto',
         {
           type: 'category',
           label: 'Authentifizierung',
-- 
GitLab