Notwendinge Attribute des JWK auf `required` setzen

changed milestone to %beta7

reopened

added 1 deleted label

Ich habe die Key ID "kid" bereits auf required gesetzt. @Marco_Holz müssen weitere Propertys auf "required" gesetzt werden?

changed the description

Ja. Ich schaue nochmal drüber.

added workflow::Peer Review label and removed 1 deleted label

removed workflow::Peer Review label

added 1 deleted label

Bei der Abbildung von Zertifikaten als JWK muss das Attribut key_ops gesetzt werden. Siehe https://git.fitko.de/fit-connect/FIT-Connect-PoC/-/issues/49#note_2132

Entwurf: https://git.fitko.de/fit-connect/spec-dvdv/-/blob/main/schemas/jwk.yaml

Sollte nach https://git.fitko.de/fit-connect/api/-/blob/main/docs/Detailinformationen/Encryption_Key_Requirements.md doch eher wie folgt aufgebaut sein:

kty: Required. Muss aber konstant "RSA" sein.
key_ops: Enum ["verify"] or ["wrapKey"]
alg: Enum "PS512" or "RSA-OAEP-256"
x5c: Required
kid: Required
n: Required
e: Required. Muss aber konstant "AQAB" sein.

Wir könnten das ganze sogar noch ein Stück weit einschränken und hier noch auftrennen zwischen Public Keys für die Verschlüsselung (alg=RSA-OEAP-256, keyops=["wrapKey"]) und Public Keys für die Signaturprüfung (alg=PS512, keyops=["verify"])

Die Prüfung können wir im Zustelldienst machen aber ich werde die nicht mit in die API einbauen mit oneOf. Kommt dann in die Doku.

DOCS: https://www.gnupg.org/documentation/manuals/gcrypt-devel/RSA-key-parameters.html

Ist auch hier https://datatracker.ietf.org/doc/html/rfc7517#section-9.3 beschrieben. Konkretes Beispiel für einen Private Key: https://datatracker.ietf.org/doc/html/rfc7517#appendix-C.1

Mir gings dabei konkret um die ganzen Ein-Buchstaben Dinger. n p k d e. Kann sich ja keiner merken.

Ja. Die Dokumentation im GnuPG-Projekt verwendet allerdings andere Bezeichner als Im JOSE-Standard.

Prüfung:

Fehlende Checks:

if ((isVerify && isWrapKey) || (!isVerify && !isWrapkey)) {
  throw new JwkNotValidException("key_ops parameter must be set to either 'verify' or 'wrapKey'");
}

if (apiJWK.getE().getValue() != "AQAB") {
  throw new JwkNotValidException("RSA-Exponent (parameter e) must be set to 'AQAB'");
}

if (apiJWK..getKty().getValue() != "RSA") {
  throw new JwkNotValidException("Key type (kty) must be set to ''RSA'");
}

Bitte zusätzlich auch irgendwo prüfen, dass alle required-Attribute tatsächlich gesetzt sind.

Wo finde ich denn Unit-Tests dazu? Bitte die bestehenden Unit-Tests ergänzen, sodass diese auch die Einhaltung der neuen Checks prüfen.

Die Prüfung geschieht sowohl über von der OpenAPI generierten Code als auch über Businesslogik. Die fehlen daher nicht, sind aber im generierten Code:

[IT] Wenn man bei key_ops etwas außer verify oder wrapKey einträgt bekommt man einen 4xxer. Prüfung bei der Deserialisierung im generierten Code.
[IT] Wenn man bei alg was außer PS512 oder RSA-OAEP-256 angibt bekommt man einen 4xxer. Prüfung bei der Deserialisierung im generierten Code.
[IT] Wenn man bei kty was außer RSA angibt bekommt man einen 4xxer. Prüfung bei der Deserialisierung im generierten Code.
[IT] Wenn man bei e was außer AQAB angibt bekommt man einen 4xxer. Prüfung bei der Deserialisierung im generierten Code.
[UT] Wenn man eine unsinnige Kombination angibt, wie verify mit RSA-OAEP-256 oder anders herum bekommt man auch einen 4xxer:

[IT] https://bitbucket.fjd.de/projects/FITCON/repos/zustelldienst-api-tests/browse/src/test/java/zustellservice/destination/destination-key-management.feature

{
  "issue": "If key is used for verification, please use PS512.",
  "detail": "You are trying to send an invalid JWK. Make sure it conforms to these constraints: kty=RSA, e=AQAB, key_ops/alg=verify/PS512 or wrapKey/RSA-OAEP-256",
  "type": "https://fitko.uber.space/problem/jwk-not-valid",
  "title": "JWK not valid",
  "status": 422
}

Mir ging es nicht um die eigentliche Prüfung der Vorgaben aus der API-Spec im Zustelldienst, sondern um Unit-Tests, die die Zustelldienst-Implementierung prüfen.

telefonisch geklärt

@Marco_Holz schließen wenn für dich ok

1. Der Fehlercode (aktuell: "message-not-readable") könnte noch etwas aussagekräftiger sein, z.B. "invalid-json-web-key"
1. Für die Prüfung auf die Existenz der Werte kid, n und e gibt es noch keine Integrationstests
1. Für die Prüfung der Schlüssellänge gibt es noch keinen Integrationstest
1. Wenn der Parameter use angegeben ist, dann muss bei use=sig zwingend der Wert key_ops=verify und bei use=enc zwingend der Wert key_ops=wrapKey gesetzt sein. Siehe https://datatracker.ietf.org/doc/html/rfc7517#section-4.3
- use-Attribut wird aktuell vom Zustelldienst verworfen.
1. Für alg=RSA-OAEP und alg-RS512 sollte es jeweils noch einen fehlschlagenden Integrationstest geben.

Siehe auch mein Kommentar in https://git.fitko.de/fit-connect/api/-/issues/51#note_3638

Aktuell werden Deserialisierungprobleme die aus der API ersichtlich sind mit message-not-readable quittiert. Wenn das customizable sein soll müssen wir weg vom generierten Code aus der API-Spec. Anders ist das nicht möglich. Ich stimme zu dass es noch aussagekräftiger sein kann. Das kommt aber mit höherem manuellen Aufwand in der Codegenerierung (bzw. eben der nicht-Codegenerierung). Machen oder nicht machen?
Korrekt, wird aber durch die Codegenerierung geprüft.
Korrekt, wird aber durch die Codegenerierung geprüft. Ich sehe aber ein dass man hier einen IT schreiben sollte. Kommt.
Der Parameter use ist laut API nicht vorgesehen.
Da das nicht über die API-Spec getestet ist (weil Businesslogik) prüfen wir das in Unittests https://bitbucket.fjd.de/projects/FITCON/repos/zustelldienst/raw/src/test/java/de/fiep/zustelldienst/component/JWKValidatorTest.java?at=refs%2Fheads%2Fmain.

Wir testen in Integrationstests nie alles vollständig ab. Das ist einfach nicht nötig.

Ich denke, ein eigener Fehlercode für ungültig JWKs hätte einen echten Mehrwert für Konsument:innen der API. Macht das debugging ungemein einfacher. Den zusätzlichen manuellen Aufwand sollten wir denke ich hinnehmen. Wir können gerne anfang nächster Woche nochmal darüber sprechen, welche konkreten Aufwände das bedeutet.
Dennoch bitte Tests ergänzen.
, bitte ergänzen :)
Er kann aber dennoch von API-Clients falsch gesetzt werden. Können wir aber auch gerne in FCON-136 behandeln.
Test für alg-RS512 , Test für alg=RSA-OAEP . Bitte noch ergänzen :)

Ack. Ich denke wir brauchen hier einfach eine Story für bessere Fehlermeldungen.
Done
Done
Mag sein, aber übermittelt wird der in der API aber nicht. Daher sehen wir den nie.
Ich dachte wir erlauben nur alg=RSA-OAEP-256 und nicht alg=RSA-OAEP? Der Wert ist damit gar nicht in der API vorgesehen. Das Problem ist aber das gleiche wie bei 1.

Wir stoßen hier halt an die Grenzen was mit generiertem Code machbar ist und müssen entscheiden ob jetzt der richtige Zeitpunkt ist die Fehlermeldungen zu verfeinern oder andere Themen anzugehen. Vorteil am agilen Vorgehen: Wir können das jetzt auch tun

added 1 deleted label

assigned to @Jonas_Groeger and unassigned @Marco_Holz

mentioned in commit 9d47a031

added workflow::Peer Review label

Gemäß dem aktuellsten Kommentar von @Jonas_Groeger es umgesetzt, aber mir ist noch nicht 100% klar, ob es eine vollständige Testabdeckung impliziert. (Ich gehe aber stark davon aus)

Kann geschlossen werden, wenn das Systemverhalten mit API-Tests nachgewiesen ist.

changed title from Notwendinge Attribute des JWK auf required setzen to Notwendinge Attribute des JWK auf required setzen{+ (https://jira.fjd.de/browse/FCON-7)+}

changed title from Notwendinge Attribute des JWK auf required setzen{- (https://jira.fjd.de/browse/FCON-7)-} to Notwendinge Attribute des JWK auf required setzen