Skip to content

CLI-Tool zur Ableitung von JWKs aus Zertifikaten

Beantragte Zertifikate aus der DOI-CA liegen zunächst als p12-Keystore vor. Um die darin enthaltenen Zertifikate für die Hinterlegung im Zustelldienst nutzbar zu machen, sollen aus diesem Keystore entsprechende JSON Web Keys abgeleitet werden. Hierzu soll ein entsprechendes Tool entwickelt werden, dass die Anforderungen aus [docs#18 (moved)] umsetzt. Eine Konvertierung von Schlüsseln/Zertifikaten im Self-Service-Portal oder im Zustelldienst ist damit nicht mehr nötig.

Referenzen

Akzeptanzkriterien

  • Das Tool wird ausschließlich über die Kommandozeile bedient.
  • Das Tool ist Betriebssystemunabhängig (läuft min. auf Windows und Linux Server)
  • Das Tool nimmt eine p12-Datei als Input via Kommandozeilenparameter entgegen.
    • Wird eine fehlerhafte Datei oder eine Datei falschen Typs übergeben, soll eine aussagekräftige Fehlermeldung ausgegeben werden.
  • Das Tool fragt dann nach dem Passwort der p12-Datei via stdin.
    • Wird ein falsches Passwort eingegeben, soll eine aussagekräftige Fehlermeldung ausgegeben werden.
  • Das Tool prüft ob die in der p12-Datei hinterlegten Zertifikate aus der DOI-CA stammen und verifiziert die Zertifikatskette.
    • Schlägt die Prüfung der CA und der Zertifikatskette fehl, soll eine aussagekräftige Fehlermeldung ausgegeben werden.
  • Das Tool leitet aus der übergebenen p12-Datei 4 JWKs ab. Dazu prüft das Tool, ob die in den Zertifikaten enthaltenen KeyUsages eine solche Ableitung erlauben und gibt im Fehlerfall eine aussagekräftige Fehlermeldung zurück:
    • JWK mit öffentlichem Schlüssel und key_ops ["wrapKey"] für Verschlüsselung,
    • JWK mit privatem Schlüssel und key_ops ["unwrapKey"] für Entschlüsselung.
    • JWK mit öffentlichem Schlüssel und key_ops ["verifiy"] für Signaturprüfung,
    • JWK mit privaten Schlüssel und key_ops ["sign"] für Signaturerstellung.
  • Alternativ zur Übergabe einer p12-Datei kann über einen Kommandozeilenparameter auch ein selbstgeneriertes Keypair erstellt werden (für die Testumgebung).
  • Alle erzeugten Schlüssel entsprechen den kryptographischen Vorgaben. Insb. enthalten die öffentlichen Schlüsseln die vollständige Zertifikatskette.
  • Die Key-IDs der Zertifikate entsprechen folgender Anforderung "The content of kid header parameter shall be the base64 (IETF RFC 4648) encoding of one DER-encoded instance of type IssuerSerial type defined in IETF RFC 5035." aus https://www.etsi.org/deliver/etsi_ts/119100_119199/11918201/01.01.01_60/ts_11918201v010101p.pdf, siehe #90
  • Das Tool speichert keine Private Keys nach /tmp. Stattdessen kann per Parameter angegeben werden, wo die Keys gespeichert werden sollen. Default-Wert ist das aktuelle Verzeichnis (working directory).
  • Das Tool überschreibt keine bestehenden Dateien. Dieses Verhalten kann via Parameter (z.B. --force/-f) überschrieben werden.
  • Abhängigkeiten werden via https://python-poetry.org/ gemanaged
  • Die Nutzung der Tools ist in der Dokumentation im Artikel Ableitung eines FIT-Connect-kompatiblen JSON Web Keys aus einem Zertifikat beschrieben. Als Ausgangspunkt kann der Artikel Erstellen von JSON Web Keys für Testzwecke dienen.
  • Testpasswort rausnehmen.

Neue Punkte vom 24.02:

  • JWKs Testen.
  • Poetry.lock Datei hinzufügen.
  • Black als Dev dependancy.
  • Beispiel zur Nutzung des Tools in die Readme.
  • Umgebung als Input parameter (Test, Prod, testing only).
    • Eigene CA für das Testing hinzufügen (MKCert).
  • KeyId anpassen (-wrapkey / -verify) damit die JWKs unterschiedliche IDs haben.
  • CI einrichten.
  • Self signed certificate raus nehmen. Hierfür wird das bestehende tool weiter genutzt. -> noch zu entscheiden
Edited by Marco Holz