Überarbeitung docs/Detailinformationen/Encryption.md

docs/Detailinformationen/Encryption.md

 # 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
 ```
-
-
-