diff --git a/docs/Detailinformationen/Encryption.md b/docs/Detailinformationen/Encryption.md
index 6d3eb8d05605329127b33b4522a3025f601f3224..768fa91e97dbc197a2811c254d7934308a42de5c 100644
--- a/docs/Detailinformationen/Encryption.md
+++ b/docs/Detailinformationen/Encryption.md
@@ -1,48 +1,49 @@
# Verschlüsselte Übertragung
## Einleitung
-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.
+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.
Die Informationen auf dieser Seite sind relevant, wenn man:
-- ein **Fachverfahren** mit fitconnenct-Anbindung entwickelt oder aufsetzt
-- einen **Onlinedienst** mit fitconnenct-Anbindung entwickelt oder aufsetzt
+- ein **Fachverfahren** mit FIT-Connect-Anbindung entwickelt oder aufsetzt
+- einen **Onlinedienst** mit FIT-Connect-Anbindung entwickelt oder aufsetzt
-### 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 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.
+### Warum ist Ende-zu-Ende-Verschlüsselung 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 FIT-Connect ist die Zielsetzung einen möglichst einfachen, sicheren und klar definierten Standard zu etablieren. Deshalb ist die verschlüsselte Übertragung von Antragsdaten ein integraler Bestandteil von FIT-Connect. Eine Übertragung von Antragsdaten erfolgt mit FIT-Connect ausschließlich verschlüsselt.
## Grundlagen zur sicheren Implementierung von FIT-Connect
### Ende-zu-Ende-Verschlüsselung
-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.
+FIT-Connect basiert auf dem Ansatz von Ende-zu-Ende-Verschlüsselung. Das bedeutet, dass 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 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.
+Zur Realisierung einer Ende-zu-Ende-Verschlüsselung vom Endgerät der Anwender:in bis zum Fachverfahren einer Behörde, dürfen Daten nicht unverschlüsselt oder nur per TLS gesichert an ein Backend übermittelt und erst dort die für FIT-Connect spezifizierte Verschlüsselung angewendet werden. Sollte eine längerfristige Speicherung der Antragsdaten nötig sein, 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
+### Zertifikate von Zustellpunkten müssen der Verwaltungs-PKI entstammen
-Jeder verwendete Public Key (idR. in Form eines JSON Web Keys) muss von einer Verwaltungs-PKI signiert werden. JSON Web Keys müssen immer mit der komplette Zertifikatskette bis zum Wurzelzertifikat ausgeliefert werden, um clientseitig korrekt validierbar zu sein.
+Jeder verwendete Public Key (idR. in Form eines JSON Web Keys) muss einem digitalen Zertifikat entstammen und von einer Zertifizierungsstelle innerhalb der Verwaltungs-PKI signiert werden. JSON Web Keys müssen immer mit der komplette Zertifikatskette bis zum Wurzelzertifikat ausgeliefert werden, um clientseitig korrekt validierbar zu sein.
### Kryptografisches Material muss vor der Verwendung immer geprüft werden
-Die für die Verschlüsselung verwendeten JSON Web Keys müssen signiert werden, über eine Verwaltungs-PKI verifizierbar sein und auch bei der Verwendung durch den verschlüsselnden Client vollständig mit Hilfe der Verwaltungs-PKI verfiziert werden.
+Die für die Verschlüsselung verwendeten JSON Web Keys müssen vor Verwendung anhand des zugehörigen Zertifikats aus der Verwaltungs-PKI auf Gültigkeit überprüft werden.
+
<img src="../../assets/images/encryption/pki-check.png" alt="PKI-um Man-in-the-Middle zu verhindern" width="400" height="320" >
-Es wird nicht unterstützt nicht vertrauenswürdige Schlüssel für die Verschlüsselung von Anträgen zu verwenden. Das soll Angriffe wie Man-in-the-middle-Attacken erschweren.
+Nicht vertrauenswürdige Schlüssel dürfen nicht für die Verschlüsselung von Anträgen verwendet werden. Das soll Angriffe wie Man-in-the-middle-Attacken verhindern.
## Architektur
Kern von FIT-Connect ist der Zustelldienst, der über die beiden APIs "Application Sender API" und "Application Subscriber API" den Absender (Sender) und Empfänger (Subscriber) eines Antrags verbindet.
-Jedes fitconenct-System verfügt über einen Endpunkt, an den Anträge gesendet werden (Fachverfahren/Destination) und einen oder mehrere Endpunkte von denen Anträge verschlüsselt versendet werden (in der Regel: Onlinedienst, App, …).
+Jedes antragsempfangende System (Fachverfahren / virtuelle Poststelle) verfügt über einen oder mehrere Endpunkt, an den Anträge gesendet werden (Zustellpunkt) und einen oder mehrere Endpunkte von denen Anträge verschlüsselt versendet werden (in der Regel: Onlinedienst, App, …).
-Ein Antrag wird an eine Destination (Zielort) geschickt. Diese Destination legt der Empfänger über die "Application Subscriber API" an. Der Absender muss die ID der Destination kennen und kann dann Anträge über die "Application Sender API" an diese ID senden.
+Ein Antrag wird an einen Zustellpunkt (Zielort) geschickt. Diesen Zustellpunkt legt der Empfänger über die "Application Subscriber API" an. Der Absender muss die Destination-ID des Zustellpunktes kennen und kann dann Anträge über die "Application Sender API" an diese Destination-ID senden.
### Application Sender API
-Der Absender muss die Destination-ID vorliegen haben und erfagt über die Application Sender API die Informationen zur Destination. Diesen entnimmt er die Liste der möglichen Schemas und wählt eines aus. Sofern es sich um eine verschlüsselte Übertragung handelt, wählt er einen öffentlichen Schlüssel.
+Der Absender muss die Destination-ID vorliegen haben und erfagt über die Application Sender API die Informationen zum Zustellpunkt. Diesen entnimmt er die Liste der möglichen Schemas und wählt eines aus. Sofern es sich um eine verschlüsselte Übertragung handelt, wählt er einen öffentlichen Schlüssel.
Derzeit muss die Destination-ID manuell vom Empfänger an den Absender übergeben werden. Dies soll in Zukunft automatisch mithilfe bestehender Mechanismen, z.B. XZufi oder DVDV passieren.
@@ -50,15 +51,15 @@ Das gewählte Schema wird in den Metadaten des Antrags (Application Metadata) ei
### Application Subscriber API
-Über die Application Subscriber API werden die Destinations verwaltet, an die die Anträge gesenet werden. Eine Destination enthält eine Liste von Schemas, welche Formate der Empfänger akzeptiert.
+Über die Application Subscriber API werden die Destinations verwaltet, an die die Anträge gesendet werden. Eine Destination enthält eine Liste von Schemas, welche Formate der Empfänger akzeptiert.
-Der Empfänger kann in der Destination mehrere Schemas und mehrere öffentliche Schlüssel hinterlegen. Der Absender sucht sich davon für die Übertragung ein Schema udn einen öffentlichen Schlüssel aus. Es wird empfohlen, genau ein Schema und genau einen öffentlichen Schlüssel anzubieten.
+Der Empfänger kann in der Destination mehrere Schemas und mehrere öffentliche Schlüssel hinterlegen. Der Absender sucht sich davon für die Übertragung ein Schema und einen öffentlichen Schlüssel aus. Es wird empfohlen, genau ein Schema und genau einen öffentlichen Schlüssel anzubieten.
Es ist geplant, dass die hinterlegten öffentlichen Schlüssel so organisiert werden, dass ein kontrolliertes Key-Rollover stattfinden kann. Dazu werden zu den Schlüsseln die Gültigkeitszeiträume ergänzt.
### Ablauf eines Antrags aus Bürger*innen-Client-Perspektive
-Wenn eine Bürger*in nun einen Antrag im Web oder in einer App übermitteln möchte läuft das in der Regel wie folgt ab:
+Wenn eine Bürger*in nun einen Antrag im Web oder in einer App übermitteln möchte, läuft das in der Regel wie folgt ab:
- Bürger*in findet den passenden Antrag über einen Zuständigkeitsfinder.
- Die Applikation erhält aus dem Zuständigkeitsfinder die passende Destination-ID zum Antrag.
@@ -73,11 +74,11 @@ Wenn eine Bürger*in nun einen Antrag im Web oder in einer App übermitteln möc
### Erstellung eines FIT-Connect-kompatiblen JSON Web Keys
-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.
+JSON Web Keys sind das Austauschformat in dem kryptografische Schlüssel 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 zwischen 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:
-1. Lokale Generierung eines X.509 zugrundelgienden RSA-Keys. `openssl genrsa -out fachverfahren1.meineverwaltung.de.key 4096`
+1. Lokale Generierung eines X.509 zugrundeliegenden RSA-Keys. `openssl genrsa -out fachverfahren1.meineverwaltung.de.key 4096`
2. Generierung des Zertifikatsrequests `openssl req -new -sha256 -key fachverfahren1.meineverwaltung.de.key -out fachverfahren1.meineverwaltung.de.csr`
3. Dieser Zertifikatsrequest muss nun von einer Verwaltungs-PKI signiert werden.
4. Das von der Verwaltungs-PKI signierte Zertifikat muss nun in einen JWK umgewandelt werden: … **TODO(Lilith): einfügen nachdem wir das einmal gemacht haben**
@@ -86,7 +87,7 @@ Das dabei entstandene Zertifikat muss zur dem Fachverfahren gehörende Destinati
### Anlegen eines Zustellpunktes
-Ein Zustellpunkt benötigt mindestens immer ein erlaubtes schema sowie einen Verschlüsselungs- und einen Signaturkey. Diese müssen in das Format JSON Web Key konvertiert und über den Zustelldienst als JSON Web Geist bereitgestellt werden.
+Ein Zustellpunkt benötigt mindestens immer ein erlaubtes Fachdaten-Schema sowie einen Verschlüsselungs- und einen Signaturkey. Diese müssen in das Format JSON Web Key konvertiert und über den Zustelldienst als JSON Web Key bereitgestellt werden.
#### Beispiel
@@ -140,18 +141,18 @@ Ein Zustellpunkt benötigt mindestens immer ein erlaubtes schema sowie einen Ver
### Überprüfen der Json Web Keys
-Die Json Web Keys müssen vor der Verwendung im Client auf ihre Inntegrität geprüft werden. Das umfasst insbesondere folgende Punkte:
+Die JSON Web Keys müssen vor der Verwendung im Client auf Gültigkeit geprüft werden. Das umfasst insbesondere folgende Punkte:
- Überprüfung gegen eine Certificate Revocation List und/oder einen OCSP-Endpunkt mit signierten Antworten.
- Überprüfung der Zertifikats-Kette bis zum Wurzelzertifikat (BSI).
### Aufbau der Ãœbertragung
-Eine Übertragung über FIT-Connect besteht aus einem Metadatensatz, optionalen Fachdaten und beliebig vielen (0-∞) Dokumenten (Anlagen). Ein Teil der Metadaten enthälten transportrelevante Informationen und werden deshalb unverschlüsselt übertragen. Alle nicht transportrelevanten Metadaten, die Fachdaten und Anlagen werden verschlüsselt übertragen.
+Eine Übertragung über FIT-Connect besteht aus einem Metadatensatz, optionalen Fachdaten und beliebig vielen (0-∞) Dokumenten (Anlagen). Ein Teil der Metadaten enthälten transportrelevante Informationen und werden deshalb unverschlüsselt übertragen. Alle nicht transportrelevanten Metadaten, die Fachdaten und Anlagen werden verschlüsselt übertragen.
-Die Metadaten, Fachdaten und Anlagen werden immer mit dem Encoding "jwe" (JSON Web Encryption RFC 7516) verschlüsselt. Als Datenformat für die Übertragung wird die sogenannte [JWE-Compact Serialisierung](https://tools.ietf.org/html/rfc7516#section-7.1) verwendet. Alle angehängten Dokumente müssen als Binärdateien und nicht als Strings enkodiert verschlüsselt werden.
+Die Metadaten, Fachdaten und Anlagen werden gemäß dem Standard JSON Web Encryption RFC 7516) verschlüsselt. Als Datenformat für die Übertragung wird die sogenannte [JWE-Compact Serialisierung](https://tools.ietf.org/html/rfc7516#section-7.1) verwendet. Alle angehängten Dokumente müssen als Binärdateien und nicht als Strings enkodiert verschlüsselt werden.
-Zur Verschlüsselung werde die Json Web Keys mit dem Typ "wrap_key" verwendet.
+Zur Verschlüsselung wird ein JSON Web Key mit dem Typ "wrap_key" verwendet.
#### Beispiel (Metadaten)
@@ -187,7 +188,7 @@ Beispiel:
PUT /delivery-service-beta7/sender/destinations/e1009dea-d97e-4104-b389-bf653d8bd30e/applications/6f7b00f1-2f0c-46da-93c9-ca020aa1758f/data HTTP/1.1
Content-Type: application/jose
Authorization: Bearer eyJhbGciOiJSUzI1NiIsImtpZCI6IjM1ZTM2Nzk2LTM1NDAtNDUwMy1iYT...
-
+
eyJlbmMiOiJBMjU2R0NNIiwiYWxnIjoiUlNBLU9BRVAtMjU2In0.yTSVS7re6hZKO46aDriHrRFOyc5-
3TIIrvcKUf2qAfGdH7InufWPCrDyEnazSDI7HtOa5X2MU3iUnmmiEuP-Lef76xTPv2lmL4_lyhW5D8zq
7zbrIaIaVhtg7ekF1r9Oy9nLsEBQWLD4EWda2PfAibV7iQbOVMn1rVk4DzKtCykj5RSrH96i-lbPVFl-
@@ -198,6 +199,3 @@ OcFhj3XGUshVKec2nRhtCZPOMPTIjxFpozsiRetjZo9LFHzRcvr1eSS_hpteKJ3ltioY9nzt1IX2JqQm
TGtY.VGOCnGM9LEZP5mUO.LQeKj4SKqsUNsBp4ZRN_56QbS8MQ01YTzRVFStk.Z0YMEua9kvCV7LkeJH
kprA
```
-
-
-
diff --git a/docs/Detailinformationen/Encryption_Key_Requirements.md b/docs/Detailinformationen/Encryption_Key_Requirements.md
index eb56c824c93b5a6cd6bcd05033ba2be39a598269..69c199902a2072f91b613392c7363cdcb9c61c76 100644
--- a/docs/Detailinformationen/Encryption_Key_Requirements.md
+++ b/docs/Detailinformationen/Encryption_Key_Requirements.md
@@ -1,50 +1,54 @@
# Anforderungen an das kryptografische Material
-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), eine 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 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](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.
+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.
#### Allgemeine Anforderungen an die JSON Web Keys und JSON Web Encryption
-Die [Liste der standartisierten Algorithmen](https://www.iana.org/assignments/jose/jose.xhtml#web-signature-encryption-algorithms) für Signaturen und Verschlüsselung mit JWS/JWE 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 des Kriteriums, welche Algorithmen am häufigsten in Softwarebiblotheken verwendet werden und deswegen einfach zu implementieren sein sollten.
+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/JWT 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.
### 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 FIT-Connect-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. Dem für die **Signaturprüfung von digitalen Eingangsbestätigungen** verwendete JSON Web Key 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:
+Für die den JSON Web Keys zugrundeliegenden X.509-Zertifikate gelten die folgenden kryptographischen Vorgaben:
-| 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 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) |
+| 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) |
-### Signatur der X.509 Zertifikate durch die Verwaltung-PKI
+### Signatur der X.509 Zertifikate durch die Verwaltung-PKI
-Die X.509-Zertifikate müssen durch eine Verwaltungs-PKI signiert werden. Als Verwaltungs-PKIs werden alle Zertifizierungsstellen, die ein Wurzelzertifikat des BSI verwenden und sich an die vom [BSI definierten Regelungen für Wurzelzertifizierungsstellen](https://www.bsi.bund.de/DE/Themen/Oeffentliche-Verwaltung/Moderner-Staat/Verwaltungs-PKI/Dokumente/dokumente_node.html) halten, bezeichnet.
+Die 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.
-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.
+Bei der Erstellung und Signatur der Zertifikate 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.
-**Für die Verwendbarkeit in FIT-Connect sind insbesondere die folgenden Anforderungen an die Verwaltungs-PKI besonders wichtig:**
+**Für die Nutzung von Zertifikaten in FIT-Connect sind die folgenden Anforderungen von besonderer Bedeutung:**
-- 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.
-- Oder sie müssen einen 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) bereitstellen.
+- Zertifikate müssen der [Verwaltungs-PKI](https://www.bsi.bund.de/VPKI) entstammen.
+- 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.
-### Zusammensetzung des JSON Web Keys zur Verschlüsselung
+### Vorgaben für JSON Web Keys zur Verschlüsselung
-Das generierte X.509 Zertifikat, alle Intermediate Zertifikate und das Wurzelzertifikat müssen zum PEM-Format konvertiert, base64 encodiert und mit denen im JSON Web Key Standard vorgesehenen Metadaten versehen werden. Der dabei entstandene JSON Web Key muss über die folgenden Attribute (nach [RFC 7517](https://tools.ietf.org/html/rfc7517#section-4)) verfügen.
+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-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 7517](https://tools.ietf.org/html/rfc7517#section-4) verfügen.
+
+Die Auswahl, welcher JSON Web Key aus der Liste der zur Verfügung gestellten Keys verwendet werden muss, wird anhand der `kid` entschieden. Deshalb ist diese verpflichtend anzugeben und muss pro Destination-ID einmalig sein.
| Feld | Inhalt | **Erläuterung** |
| ------- | ------------------------------------- | ------------------------------------------------------------ |
-| 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)) |
-| 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)) |
-| n | der Public Key zum Zertifikat | Der Modulus des Public Key zum Zertifikat (x5c) "Base64urlUInt" enkodiert. (vgl. [RFC 7518 - Abschitt 6.3.1.1](https://www.rfc-editor.org/rfc/rfc7518.html#section-6.3.1.1)) |
-| e | AQAB | Der Exponent des Public Key zum Zertifikat (x5c) (vgl. [RFC 7518 - Abschitt 6.3.1.2](https://www.rfc-editor.org/rfc/rfc7518.html#section-6.3.1.2)) |
+| 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. |
+| x5t | Zertifikatsfingerprint | Der Fingerprint des Zertifikats gemäß [RFC 7516, Abschnitt 4.1.6](https://datatracker.ietf.org/doc/html/rfc7516#section-4.1.6) |
+| 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:
@@ -52,34 +56,33 @@ Das bedeutet, der JSON Web Key zur Verschlüsselung muss diesem Format entsprech
{
"kty": "RSA",
"key_ops": ["wrapKey"],
- "alg": "PS512",
+ "alg": "RSA-OAEP-256",
"kid": "……(Key ID)……",
"x5t": "……(Fingerprint)……",
"x5c": [
- "……(base64 encoded root cert)……",
+ "……(base64 encoded cert)……",
"……(base64 encoded intermediate cert)……",
- "……(base64 encoded cert)……"
+ "……(base64 encoded root cert)……"
]
}
```
-### Zusammensetzung des JSON Web Keys zur Signaturprüfung von Eingangsbestätigungen
-
-Zur Signaturprüfung wird das verfahren JSON Web Signature ([RFC 7515](https://tools.ietf.org/html/rfc7515)) eingesetzt. Der dafür im Keyset bereitgestellte Key unterscheidete sich vom für die JSON Web Encryption bereitgestellten Key primär durch seine Funktion und nicht durch die verwendeten kryptographischen Methoden. Das soll vor allem zu einer Vereinfachung der Implementierung führen.
+### Vorgaben für JSON Web Keys zur Signaturprüfung
-Das generierte X.509 Zertifikat, alle Intermediate Zertifikate und das Root Zertifikat müssen zu PEM konvertiert, base64 encodiert und mit den im JSON Web Key Standard vorgesehenen Metadaten versehen werden. Der dabei entstandene JSON Web Key muss über die folgenden Attribute (nach [RFC 7515](https://tools.ietf.org/html/rfc7515#section-4)) verfügen.
+Eine Signaturprüfung erfolgt in FIT-Connect auf Basis des Standards JSON Web Signature gemäß [RFC 7515](https://tools.ietf.org/html/rfc7515).
-Die Auswahl welcher JSON Web Key aus der Liste der zur Verfügung gestellten Keys verwendet werden muss, wird anhand der "kid" entschieden. Deshalb ist diese verpflichtend anzugeben und muss pro Destination-ID einmalig sein. Es wird empfohlen eine UUID nach [RFC 4122](https://tools.ietf.org/html/rfc4122) zu verwenden.
+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 | 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)) |
-| 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. |
-| n | der Public Key zum Zertifikat | Der Modulus des Public Key zum Zertifikat (x5c) "Base64urlUInt" enkodiert. (vgl. [RFC 7518 - Abschitt 6.3.1.1](https://www.rfc-editor.org/rfc/rfc7518.html#section-6.3.1.1)) |
-| e | AQAB | Der Exponent des Public Key zum Zertifikat (x5c) (vgl. [RFC 7518 - Abschitt 6.3.1.2](https://www.rfc-editor.org/rfc/rfc7518.html#section-6.3.1.2)) |
+| 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. |
+| x5t | Zertifikatsfingerprint | Der Fingerprint des Zertifikats gemäß [RFC 7517, Abschnitt 4.5](https://datatracker.ietf.org/doc/html/rfc7517#section-4.7) |
+| 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:
@@ -91,50 +94,53 @@ Das bedeutet, der JSON Web Key zur Prüfung von digitalen Signaturen muss dem fo
"kid": "……(Key ID)……",
"x5t": "……(Fingerprint)……",
"x5c": [
- "……(base64 encoded root cert)……",
- "……(base64 encoded intermediate cert)……",
"……(base64 encoded cert)……"
+ "……(base64 encoded intermediate cert)……",
+ "……(base64 encoded root cert)……",
]
}
```
-Abgelaufene oder nichtmehr Verwendete JSON Web Keys für signaturen müssen nach Ende der Verwendung weiterhin solange die signierten Security Event Tokens abrufbar sind - **mindestens jedoch für weitere mindestens 24 Monate** - ü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.
+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 Verschlüsselung des Antragsinhalts mit JSON Web Encryption
-Zur Verschlüsselung des eigentlichen Antragsinhalts wird ein s Schlüssel verwendet. Dieser symmetrische Schlüssel wird dann mit den JSON Web Keys, die vom **Fachverfahren** bereitgestellt werden und die Verwendungsart **"wrapKey"** haben müssen, asymmetrisch verschlüsselt.
+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.
### Verschlüsselungsverfahren
-Verschlüsselugnsverfahren Der Content im verschlüsselten JSON Web Encryption Objekt muss mit den folgenden Methoden verschlüsselt werden:
+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"- Feld im JSON: "enc"): "A256GCM" (definiert in [RFC 7518 Abschnitt 4.1](https://tools.ietf.org/html/rfc7518#section-4.1))
-- Asymmetrisches Verschlüsselungsverfahren, um den "Content Encryption Key" zu verschlüsseln ("alg"): "RSA-OAEP-256" (definiert in [RFC 7518 Abschnitt 4.3](https://tools.ietf.org/html/rfc7518#section-4.3))
+- 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 (JOSE)
+#### JSON Web Encryption Header
-Im Header des JSON Web Encryption Objektes werden die Metadaten zu den verschlüsselten Antragsdaten übergeben. Diese Headerinformationen werden in der Umsetzung als Base64URL Safe encodiert.
+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 Felder müssen im JOSE-Header bei der Übertragung verschlüsselter Daten in FIT-Connect 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“ Verfahren symmetrisch verschlüsselt wurde. Hierfür werden die im Header per "kid" referenzierten öffentlichen Schlüssel genutzt. Der JSOE Header wird in [RFC 7516](https://tools.ietf.org/html/rfc7516) definiert und der Bezeichner des Algorithmus in [RFC 7518 Abschnitt 4.1](https://tools.ietf.org/html/rfc7518#section-4.1). |
-| enc | A256GCM | Symmetrisches Verschlüsselungsverfahren zur Verschlüsselung des Payloads. Nach [RFC 7518 5.1](https://tools.ietf.org/html/rfc7518#section-5.1) |
+| 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", aus dem von der Subscriber-API bereitgestellten Keysets, der zur Verschlüsselung des unter enc verschlüsselten symmetrischen Keys verwendet wurde (siehe [RFC 7516 4.1.4](https://tools.ietf.org/html/rfc7516#section-4.1.4)). Als Format der ID wird UUID nach [RFC 4122](https://tools.ietf.org/html/rfc4122) empfohlen. |
+| 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) |
+
## Algorithmen zur Signierung von Security Event Tokens
-Für die Bereitstellung von signierten Statusinformationen über Security Event Tokens (vgl. [RFC 8417](https://tools.ietf.org/html/rfc8417)) wird das Verfahren [JSON Web Signature](https://tools.ietf.org/html/rfc7515) verwendet.
+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 Public Key, zu dem auf dem Server verwendeten Signaturschlüssel, muss über den JSON Web Key Endpunkt (DVDV) als Key mit der Funktion "verify" verfügbar sein.
+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://www.rfc-editor.org/rfc/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.
+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.
-Zu Übermittlung der Signatur wird das in [RFC 7515 Abschnitt 7.1](https://tools.ietf.org/html/rfc7515#section-7.1) beschriebene "JWS Compact Serialization" Verfahren verwendet. Die folgende Attribute müssen teil des Base64URL Safe encodierten JOSE Headers sein:
+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 folgende Attribute müssen bei der Verwendung in FIT-Connect zwingend Teil des Base64URL Safe encodierten JOSE Headers sein:
| Feld | Inhalt | Erläuterung |
| ---- | ------------------ | ------------------------------------------------------------ |
-| alg | PS512 | Legt RSASSA-PSS mit SHA512 als Standard für die Signatur fest (vgl. [RFC 7518 Abschnitt 3.5](https://www.rfc-editor.org/rfc/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. (vgl. [RFC7515 Abschnitt 4.1.4](https://tools.ietf.org/html/rfc7515#section-4.1.4)) |
-| | | |
-
+| 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) |