### Signaturprüfung eines vom empfangenden System ausgestellten SET
Um die Signatur eines SET zu überprüfen, welches von einem empfangenden System ausgestellt wurde, ist es notwendig, auf den verwendeten Schlüssel zugreifen zu können.
Die Schlüssel eines empfangenden Systems sind über die Destination in Form eines JSON Web Key (JWK) Sets öffentlich verfügbar.
Welche Schritte notwendig sind und wie die Prüfung letztendlich durchgeführt wird, wird im Folgenden anhand eines Beispiels beschrieben.
Um die Signatur eines von einem empfangenden System ausgestellen SET zu überprüfen ist es notwendig, auf den verwendeten Schlüssel zugreifen zu können.
Der bzw. die Schlüssel sind öffentlich verfügbar und können über die Submission API abgerufen werden.
:::caution Hinweis
Der Mechanismus zum Abrufen von kryptografischen Schlüsseln des empfangenden Systems wird sich bis zur Veröffentlichung der finalen API-Spezifikation noch einmal ändern.
:::
Als Ausgangslage dient das Token mit dem folgenden Header und der entsprechenden Payload.
Aus dem Header wird die `kid` benötigt, sowie die `submissionId` aus dem Payload.
Konkret sind das hier
#### Ausgangslage: Das SET
Als Ausgangslage dient das folgende SET.
Aus dem Header wird die Schlüssel-ID aus dem Feld `kid` benötigt.
Aus dem Payload benötigen wir das Feld `submissionId`.
Die Verifikation mit dem Schlüssel ist dann ziemlich geradlinig.
Es wird noch überprüft, ob der Schlüssel den passenden Algorithmus hat und dann die eigentliche Verifikation über die Methode der Bibliothek durchgeführt.
#### Validierung des SET mit Hilfe des JWK
Die Verifikation des SET mit dem eben abgerufenen JWK ist dann ziemlich geradlinig.
Es wird zunächst geprüft ob der Schlüssel den passenden Algorithmus hat. Anschließend wird die eigentliche Verifikation durch die Bibliothek durchgeführt.
Viele Daten, die über den Zustelldienst übertragen werden, enthalten schützenswerte Informationen und müssen verschlüsselt werden. Eine Übertragung über FIT-Connect besteht aus einem Metadatensatz, optionalen Fachdaten und beliebig vielen (0-∞) Dokumenten (Anlagen). Die Metadaten, Fachdaten und Anlagen werden gemäß dem Standard [JSON Web Encryption (JWE)](https://tools.ietf.org/html/rfc7516) 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 kodiert verschlüsselt werden.
Über FIT-Connect versendete Daten sind oft schützenswert und müssen daher verschlüsselt werden.
Gegeben, dass ein öffentlicher Teil eines JWK eines Zustellpunktes [vorhanden ist](./get-destination.mdx#informationen-des-zustellpunktes-erhalten), können mit diesem Daten für diesen Zustellpunkt verschlüsselt werden. Ein Beispiel für den öffentlichen Teil eines JWK ist unten aufgeführt.
Eine Übertragung über FIT-Connect besteht aus
```json
* einem Metadatensatz
* einem Fachdatensatz (optional)
* beliebig vielen Dokumenten (optional)
Alle drei Datensatzarten müssen mit [JSON Web Encryption (JWE)](https://tools.ietf.org/html/rfc7516) verschlüsselt und mit [JWE-Compact Serialisierung](https://tools.ietf.org/html/rfc7516#section-7.1) serialisiert werden.
Dokumente müssen als Binärdateien und nicht als Zeichenketten kodiert verschlüsselt werden.
Der [vorher abgerufene Zustellpunkt](./get-destination.mdx#informationen-des-zustellpunktes-erhalten) beinhaltet die Schlüssel-ID des Verschlüsselungsschlüssels unter dem Feld `encryptionKid`.
Damit können wir den JWK des Zustellpunktes abrufen um Daten zu verschlüsseln.
```shell title="Beispiel: Abruf des JWK eines Zustellpunktes"
Mit diesem Schlüssel könnten jetzt die oben genannten Datenssätze verschlüsselt werden.
Die so verschlüsselten Daten können ausschließlich von diesem Zustellpunkt mit gelesen werden.
Bevor wir mit der Verschlüsselung loslegen können müssen wir den eben abgerufenen JWK noch auf Gültigkeit überprüfen.
## Überprüfen des öffentlichen Schlüssel (Zertifikatsprüfung)
:::note Hinweis
In der Testumgebung ist die Absicherung der öffentlichen Schlüssel eines Zustellpunktes durch Zertifikate optional. Eine Prüfung der Zertifikate kann in diesem Fall zu Testzwecken entfallen.
In der Testumgebung ist die Absicherung der öffentlichen Schlüssel eines Zustellpunktes durch Zertifikate optional.
Eine Prüfung der Zertifikate kann in diesem Fall zu Testzwecken entfallen.
:::
Die JSON Web Keys MÜSSEN vor der Verwendung zwingend im Client auf Gültigkeit geprüft werden. Das umfasst insbesondere folgende Schritte:
JWKs MÜSSEN vor der Verwendung zwingend im Client auf Gültigkeit geprüft werden. Diese Prüfung umfasst folgende Schritte:
- Überprüfung, dass der JSON Web Key für die Verschlüsselung geeignet ist (`"keyops": ["wrap_key"]`)
- Überprüfung, dass der öffentliche Schlüssel mit dem im JSON Web Key hinterlegten Zertifikat übereinstimmt (Attribute `n` und `e`)
- Überprüfung der Zertifikats-Kette bis zum Wurzelzertifikat (BSI)
- Überprüfung gegen eine Certificate Revocation List und/oder einen OCSP-Endpunkt mit signierten Antworten
Weitere Informationen zur Gültigkeitsprüfung finden sich in der technischen Richtlinie [BSI TR-02103](https://www.bsi.bund.de/SharedDocs/Downloads/DE/BSI/Publikationen/TechnischeRichtlinien/TR02103/BSI-TR-02103.pdf?__blob=publicationFile&v=4).
Weitere Informationen zur Gültigkeitsprüfung finden sich in der technischen Richtlinie [BSI TR-02103](https://www.bsi.bund.de/SharedDocs/Downloads/DE/BSI/Publikationen/TechnischeRichtlinien/TR02103/BSI-TR-02103.pdf?__blob=publicationFile&v=4) des BSI.
:::note Hinweis
An dieser Stelle werden noch detailliertere Informationen und konkrete Implementierungsbeispiele zur Prüfung der JSON Web Keys ergänzt.
...
...
@@ -130,8 +153,10 @@ Mit diesem umgewandelten Schlüssel können nun Zeichenketten und Binärdaten ve
```java
JWEHeader header = new JWEHeader(JWEAlgorithm.RSA_OAEP_256, EncryptionMethod.A256GCM);
// Zeichenkette
Payload payload = new Payload("{ \"Hello\": \"World\"}");
/// Alternativ, bei einer Datei
// InputStream (z.B. für Datei)
Payload payload = new Payload(aFileInputStream.readAllBytes());
JWEObject jweObject = new JWEObject(header, payload);