Skip to content
Snippets Groups Projects
Commit 2cb864bb authored by Lilith Wittmann's avatar Lilith Wittmann
Browse files

fix multiple wrong fields in context of jwks

parent 44b3eb38
No related branches found
No related tags found
1 merge request!26doc(encryption_keys): fix lots of missing/br0ken links, spelling and todos
Hide whitespace changes
Inline Side-by-side
docs/Detailinformationen/Authentifizierung_von_Usern.md
+ 18
− 15
View file @ 2cb864bb
...@@ -30,7 +30,7 @@ Der Onlinedienst muss zur Registrierung bei FIT-Connect neben den Angaben dazu, ...@@ -30,7 +30,7 @@ Der Onlinedienst muss zur Registrierung bei FIT-Connect neben den Angaben dazu,
| Feld | Inhalt | **Erläuterung** | | Feld | Inhalt | **Erläuterung** |
| ------------------ | ---------- | ------------------------------------------------------------ | | ------------------ | ---------- | ------------------------------------------------------------ |
| Hashingalgorithmus | SHA-512 | Gibt den Algorithmus der zur digitalen Signatur des Keys 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)) | | Hashingalgorithmus | SHA-512 | Algorithmus der zur digitalen Signatur des Keys 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)) | | 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) | | 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) |
...@@ -44,11 +44,11 @@ Die vom Onlinedienst generierten JWT-Tokens müssen nach [RFC 7519](https://tool ...@@ -44,11 +44,11 @@ Die vom Onlinedienst generierten JWT-Tokens müssen nach [RFC 7519](https://tool
Entsprechend [RFC 7519 Abschnnitt 8](https://tools.ietf.org/html/rfc7519#section-8): Entsprechend [RFC 7519 Abschnnitt 8](https://tools.ietf.org/html/rfc7519#section-8):
| Feld | Inhalt | **Erläuterung** | | Feld | Inhalt | **Erläuterung** |
| ---- | ------ | ---------------------------------------------- | | ---- | ------ | ----------------------------------------------- |
| typ | JWT | Es handelt sich um einen JWT-Token. | | typ | JWT | Es handelt sich um einen JWT-Token. |
| alg | RS512 | Der JWT Token verwendet RSASSA-PSS und HA-512. | | alg | RS512 | Der JWT Token verwendet RSASSA-PSS und SHA-512. |
| | | | | | | |
**Beispiel** **Beispiel**
...@@ -63,13 +63,14 @@ Entsprechend [RFC 7519 Abschnnitt 8](https://tools.ietf.org/html/rfc7519#section ...@@ -63,13 +63,14 @@ Entsprechend [RFC 7519 Abschnnitt 8](https://tools.ietf.org/html/rfc7519#section
Entsprechend den [standartisierten Feldern](http://www.iana.org/assignments/jose/jose.xhtml#web-signature-encryption-algorithms): Entsprechend den [standartisierten Feldern](http://www.iana.org/assignments/jose/jose.xhtml#web-signature-encryption-algorithms):
| Feld | Inhalt | **Erläuterung** | | Feld | Inhalt | **Erläuterung** |
| ----- | ------------------------- | ------------------------------------------------------------ | | ------- | ------------------------- | ------------------------------------------------------------ |
| iat | Unix Timestamp | Zeitpunkt wann der Token ausgestellt wurde als Unix Timestamp. | | iat | Unix Timestamp | Zeitpunkt wann der Token ausgestellt wurde als Unix Timestamp. |
| exp | Unix Timestamp | Zeitpunkt wann der Token abläuft als Unix Timestamp (Token sollte max. 2 Stunden gültig sein vgl [BSI APP.3.1](https://www.bsi.bund.de/SharedDocs/Downloads/DE/BSI/Grundschutz/Kompendium_Einzel_PDFs/06_APP_Anwendungen/APP_3_1_Webanwendungen_Edition_2020.pdf?__blob=publicationFile&v=1)). | | exp | Unix Timestamp | Zeitpunkt wann der Token abläuft als Unix Timestamp (Token sollte max. 2 Stunden gültig sein vgl [BSI APP.3.1](https://www.bsi.bund.de/SharedDocs/Downloads/DE/BSI/Grundschutz/Kompendium_Einzel_PDFs/06_APP_Anwendungen/APP_3_1_Webanwendungen_Edition_2020.pdf?__blob=publicationFile&v=1)). |
| scope | Liste von Destination-IDs | Eine Liste der Destination-IDs, für die der JWT eine Übermittlung erlaubt. | | scope | Liste von Destination-IDs | Eine Liste der Destination-IDs, für die der JWT eine Übermittlung erlaubt. |
| sid | UUID4 der Session | Eine unique ID zur Identifizierung der Session (muss garantiert für jede Übermittlung anders sein) | | sid | UUID4 der Session | Eine unique ID zur Identifizierung der Session (muss garantiert für jede Übermittlung anders sein) |
| iss | ID des Onlinedienstes | Wird bei der Anmeldung des Onlinedienstes festgelegt und dient zur Identifizierung am API-Gateway | | iss | ID des Onlinedienstes | Wird bei der Anmeldung des Onlinedienstes festgelegt und dient zur Identifizierung am API-Gateway |
| domains | Liste von Domains | Eine Liste der Domains, von denen der Onlineservice Anträge übermitteln kann. Sie muss einem Subset der Domains entsprechen, die im domains Feld des Onlinedienst-JWT angegeben wurden. (Subdomains müssen explizit angegeben werden) |
**Beispiel** **Beispiel**
...@@ -125,11 +126,13 @@ Nach dem Anlegen eines Antragsübertragungsprozesses kann auf diesen nur mit JWT ...@@ -125,11 +126,13 @@ Nach dem Anlegen eines Antragsübertragungsprozesses kann auf diesen nur mit JWT
Das API-Gateway muss die JWT-Tokens validieren: Das API-Gateway muss die JWT-Tokens validieren:
1. Überprüfen, ob diese noch gültig sind und der JWT-Token maximal für 2h ausgestellt wurde. 1. Überprüfen, ob diese noch gültig sind und
1. der User-JWT-Token maximal für 2h ausgestellt wurde.
2. der Onlinedienst-JWT-Token für max. 24h ausgestellt wurde.
2. Mithilfe des Public Keys des Authentifizierungsservers die Signatur des Onlinedienst-JWT überprüfen. 2. Mithilfe des Public Keys des Authentifizierungsservers die Signatur des Onlinedienst-JWT überprüfen.
3. Mithilfe des im JWT-Token des Onlinedienst enthaltenen Public Key die Signatur des User JWT überprüfen 3. Mithilfe des im JWT-Token des Onlinedienst enthaltenen Public Key die Signatur des User JWT überprüfen
4. Überprüfen, ob die Destination-ID teil der in den Scopes (**scope** Parameter in den JWT Tokens) beider JWT-Tokens ist. (Zugangsberechtigung des Onlinedienstes und des Users) 4. Überprüfen, ob die Destination-ID teil der in den Scopes (**scope** Parameter in den JWT Tokens) beider JWT-Tokens ist. (Zugangsberechtigung des Onlinedienstes und des Users)
5. Überprüfen, ob die Website (origin), von der der Antrag abgesendet wurde, für die jeweilige Session-ID freigegeben ist. (Verhindern von gefälschten Onlinediensten, die nicht den FIT-Connect-Standards entsprechen) 5. Überprüfen, ob die Website (origin), von der der Antrag abgesendet wurde, im domain Feld beider JWKs verzeichnet ist. (Verhindern von gefälschten Onlinediensten, die nicht den FIT-Connect-Standards entsprechen)
Das API-Gateway kann aufgrund der folgenden Parameter Rate-Limiting für API-Calls (angepasst an die jeweiligen Use Cases des Onlineservices) betreiben: Das API-Gateway kann aufgrund der folgenden Parameter Rate-Limiting für API-Calls (angepasst an die jeweiligen Use Cases des Onlineservices) betreiben:
......
docs/Detailinformationen/Encryption.md
+ 1
− 1
View file @ 2cb864bb
...@@ -86,7 +86,7 @@ Das dabei entstandene Zertifikat muss zur dem Fachverfahren gehörende Destinati ...@@ -86,7 +86,7 @@ Das dabei entstandene Zertifikat muss zur dem Fachverfahren gehörende Destinati
### Anlegen eines Zustellpunktes ### Anlegen eines Zustellpunktes
Ein Zustellpunkt benötigt mindestens immer ein erlaubtes schema sowie einen Verschlüsselungs- und einen Signaturkey. 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.
#### Beispiel #### Beispiel
......
docs/Detailinformationen/Encryption_Key_Requirements.md
+ 6
− 4
View file @ 2cb864bb
...@@ -40,10 +40,11 @@ Das generierte X.509 Zertifikat, alle Intermediate Zertifikate und das Wurzelzer ...@@ -40,10 +40,11 @@ Das generierte X.509 Zertifikat, alle Intermediate Zertifikate und das Wurzelzer
| ------- | ------------------------------------- | ------------------------------------------------------------ | | ------- | ------------------------------------- | ------------------------------------------------------------ |
| kty | RSA | Gibt den Keytype nach [RFC 7517 Abschnitt 4](https://tools.ietf.org/html/rfc7517#section-4) an. | | 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)) | | 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)) |
| alg | PS512 | Gibt den Algorithmus der zur digitalen Signatur des Zertifikats verwendet werden muss an. Dieser muss im Fall von FIT-Connect immer PS512 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)) |
| 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)) | | 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)) | | 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)) | | 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)) |
Das bedeutet, der JSON Web Key zur Verschlüsselung muss diesem Format entsprechen: Das bedeutet, der JSON Web Key zur Verschlüsselung muss diesem Format entsprechen:
...@@ -74,10 +75,11 @@ Die Auswahl welcher JSON Web Key aus der Liste der zur Verfügung gestellten Key ...@@ -74,10 +75,11 @@ Die Auswahl welcher JSON Web Key aus der Liste der zur Verfügung gestellten Key
| ------- | ------------------------------------- | ------------------------------------------------------------ | | ------- | ------------------------------------- | ------------------------------------------------------------ |
| kty | RSA | Gibt den Keytype nach [RFC 7515 Abschnitt 4](https://tools.ietf.org/html/rfc7515#section-4) an. | | 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)) | | 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)) |
| alg | PS512 | Gibt den Algorithmus der zur digitalen Signatur des Zertifikats verwendet werden muss an. Dieser muss im Fall von FIT-Connect immer PS512 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)) |
| 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)) | | 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)) | | 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. | | 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)) |
Das bedeutet, der JSON Web Key zur Prüfung von digitalen Signaturen muss dem folgenden Format entsprechen: Das bedeutet, der JSON Web Key zur Prüfung von digitalen Signaturen muss dem folgenden Format entsprechen:
...@@ -107,7 +109,7 @@ Zur Verschlüsselung des eigentlichen Antragsinhalts wird ein s Schlüssel verwe ...@@ -107,7 +109,7 @@ Zur Verschlüsselung des eigentlichen Antragsinhalts wird ein s Schlüssel verwe
Verschlüsselugnsverfahren Der Content im verschlüsselten JSON Web Encryption Objekt muss mit den folgenden Methoden verschlüsselt werden: Verschlüsselugnsverfahren 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)) - 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) - 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))
#### JSON Web Encryption Header (JOSE) #### JSON Web Encryption Header (JOSE)
...@@ -124,7 +126,7 @@ Im Header des JSON Web Encryption Objektes werden die Metadaten zu den verschlü ...@@ -124,7 +126,7 @@ Im Header des JSON Web Encryption Objektes werden die Metadaten zu den verschlü
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 (vgl. [RFC 8417](https://tools.ietf.org/html/rfc8417)) wird das Verfahren [JSON Web Signature](https://tools.ietf.org/html/rfc7515) verwendet.
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 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 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.
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://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.
......
0% or .
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment