diff --git a/docs/details/crypto.md b/docs/details/crypto.md
index 3e0d4b964b41979315d0cdfbac5883f02cc402c2..273f24d897a161993375c7f1e1a8a49f8fc750c5 100644
--- a/docs/details/crypto.md
+++ b/docs/details/crypto.md
@@ -46,16 +46,17 @@ Das bedeutet, der JSON Web Key zur Verschlüsselung muss diesem Format entsprech
```json
{
"kty": "RSA",
- "key_ops": ["wrapKey"],
+ "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)……"
+ "……(base64 encoded cert)……",
+ "……(base64 encoded intermediate cert)……",
+ "……(base64 encoded root cert)……"
]
}
```
diff --git a/docs/getting-started/encryption.md b/docs/getting-started/encryption.md
index 4d468535a0c61771c00b81154621c6b432451493..edbb920ea0c6c656b87b2a07bd2ec73de0d1b29f 100644
--- a/docs/getting-started/encryption.md
+++ b/docs/getting-started/encryption.md
@@ -1,71 +1,33 @@
# Verschlüsselte Übertragung
-FIT-Connect verwendet zur Übertragung von Antragsdaten und Antragsmetadaten, abgesehen von den für die Übermittlung
-zwingend notwendigen Daten, 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, 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.
-Die JSON Web Keys werden hierbei aber aus Zertifikaten abgeleitet und die öffentlichen Teile in einem Zustellpunkt für
-die Verwendung durch ein Fachverfahren hinterlegt. Es können mehrere JWKs hinterlegt werden, welche entweder für die
-Verschlüsselung oder Signaturprüfung verwendet werden können.
+Die JSON Web Keys werden hierbei aber aus Zertifikaten abgeleitet und die öffentlichen Teile in einem Zustellpunkt für die Verwendung durch ein Fachverfahren hinterlegt.
+Es können mehrere JWKs hinterlegt werden, welche entweder für die Verschlüsselung oder Signaturprüfung verwendet werden können.
:::note Hinweis
-Die Zertifikate und damit verbundenen JWKs müssen in regelmäßigen Intervallen rolliert werden, was sich
-an der Gültigkeitsdauer der Zertifikate orientiert.
+Die Zertifikate und damit verbundene JWKs haben eine begrenzte Gültigkeitsdauer und müssen gemäß den Vorgaben der Zertifikatsinfrastruktur in regelmäßigen Intervallen erneuert werden.
:::
-## Vorgaben für eingesetzte X.509-Zertifikate
-
Die Voraussetzung, damit Clients Daten verschlüsseln bzw. Signaturen prüfen können, ist ein gültiges X.509-Zertifikat
aus der Verwaltungs-PKI. 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.
-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 X.509-Zertifikate gelten in FIT-Connect die folgenden kryptografischen 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) |
-
-Ein entsprechendes Zertifikat kann über die folgenden Schritte erstellt werden:
-
-1. Lokale Generierung eines X.509 zugrundeliegenden RSA-Keys.
-
- ```bash
- openssl genrsa -out fachverfahren1.meineverwaltung.de.key 4096
- ```
-
-2. Generierung des Zertifikatsrequests
-
- ```bash
- openssl req -new -sha512 -key fachverfahren1.meineverwaltung.de.key -out fachverfahren1.meineverwaltung.de.csr
- ```
+Weitere Vorgaben für die eingesetzten X.509-Zertifikate sind unter [Vorgaben für kryptographische Verfahren in FIT-Connect](https://docs.fitko.de/fit-connect/docs/details/crypto#vorgaben-f%C3%BCr-eingesetzte-x509-zertifikate) dokumentiert.
:::note Hinweis
-Nicht alle Felder, die `openssl` hier erfragt müssen ausgefüllt werden. Jedoch sollten so viele wie
-möglich nach bestem Wissen ausgefüllt werden.
+Der Ablauf der Zertifikatsbeantragung ist je nach zuständiger Registrierungsstelle unterschiedlich. Details zur Beantragung von Zertifikaten werden an dieser Stelle noch ergänzt.
:::
-3. Dieser Zertifikatsrequest muss nun von einer Verwaltungs-PKI signiert werden. Der Ablauf ist je nach zuständiger
- Verwaltungs-PKI unterschiedlich, wodurch den jeweiligen Anweisungen bzw. Schritten zur Beantragung zu folgen ist.
-
## Erstellung eines FIT-Connect-kompatiblen JSON Web Keys
JSON Web Keys sind das Austauschformat in dem kryptografische Schlüssel in FIT-Connect zwischen der Destination und dem
-Onlinedienst ausgetauscht werden. Die Schlüssel sollten erst dort generiert werden, wo sie am Ende eingesetzt werden.
-Ein unnötiges Übertragen von privaten Schlüsseln zwischen Servern/Computern sollte vermieden werden. Sollte dies doch
-notwendig sein, so muss die Übermittlung nur verschlüsselt erfolgen.
+Onlinedienst ausgetauscht werden. Private Schlüssel sollten nach Möglichkeit dort generiert werden, wo sie am Ende eingesetzt werden.
+Ein Übertragen von privaten Schlüsseln zwischen Servern/Computern sollte vermieden werden.
+Sollte dies doch notwendig sein, so muss die Übermittlung nur verschlüsselt erfolgen.
Im Folgenden eine beispielhafte Schritt-für-Schritt-Anleitung, um aus einem Zertifikat aus der Verwaltungs-PKI einen
JSON-Web-Key zu erzeugen:
@@ -91,38 +53,3 @@ insbesondere folgende Punkte:
Weitere Informationen zur Gültigkeitsprüfung finden sich im
BSI [TR-02103](https://www.bsi.bund.de/SharedDocs/Downloads/DE/BSI/Publikationen/TechnischeRichtlinien/TR02103/BSI-TR-02103.pdf?__blob=publicationFile&v=4)
und im Abschnitt "[Anforderungen an das kryptografische Material](#Vorgaben-für-kryptographische-Verfahren)" .
-
-### Vorgaben für JSON Web Keys zur Verschlüsselung {#encryption-requirements}
-
-Der resultierende JWK muss, falls er für die Verschlüsselung genutzt werden soll, in FIT-Connect ü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)……",
- "x5c": [
- "……(base64 encoded cert)……",
- "……(base64 encoded intermediate cert)……",
- "……(base64 encoded root cert)……"
- ]
-}
-```