Prüfung der in Zustellpunkten hinterlegten Zertifikate (Part I) [M]

Warum?

In der Produktivumgebung muss der Zustelldienst die Verwendung von Zertifikaten aus der V-PKI überprüfen und technisch erzwingen. Im Gegensatz zur Testumgebung dürfen hier keine selbstsignierten Zeritifkate verwendet werden.

Referenzen / Infos

• In folgendem Issue (#142 (closed)) wird die Prüfung durch den Nutzer dokumentiert. Arbeiten an der Implementierung der Prüfung im Zustelldienst können idealerweise für die Dokumentation und Codebeispiele nachgenutzt werden.
• Root-Zertifikate: https://www.bsi.bund.de/DE/Themen/Oeffentliche-Verwaltung/Moderner-Staat/Verwaltungs-PKI/Wurzelzertifizierungsstelle/Zertifikate/zertifikate_node.html
• Nimbus nutzt die JCA (Java Cryptography Architecture) des JDK/JRE per default zum Prüfen der Zertifikate und Signaturen. BouncyCastle ist ein alternativer Provider, der von Nimbus unterstützt wird
• CEF Digital hat eine Bibliothek entwickelt (Digital Signature Service), die u.a. auch Zertifikate validieren kann:
  • https://ec.europa.eu/digital-building-blocks/wikis/display/CEFDIGITAL/Digital+Signature+Service+-++DSS
  • https://github.com/esig/dss/blob/master/dss-cookbook/src/main/asciidoc/dss-documentation.adoc
• Implementierung kann in #297 (closed) wiederverwendet werden bzw. wird dort bereits umgesetzt.
• Technische Richtlinie TR02103: X.509-Zertifikate und Zertifizierungspfadvalidierung des BSI

Akzeptanzkriterien

1. Keys werden auf Gültigkeit inkl. der hinterlegten Zertifikatskette geprüft
   • Überprüfung, dass der JWK eine Schlüssellänge von mind. 4096 Bits aufweist.
   • 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. Alternative Umsetzung: Der Zustelldienst wift einen Fehler, wenn das use-Attribut angegeben ist. Siehe https://datatracker.ietf.org/doc/html/rfc7517#section-4.3
   • Der im Attribut x5c hinterlegte öffentliche Schlüssel muss mit dem Schlüssel im JWK (Attribute n und e) übereinstimmen.
   • Die im x5c hinterlegte Zertifikatskette ist gültig, d.h. die folgenden Anforderungen sind eingehalten:
     • Die Einhaltung der Vorgaben aus https://datatracker.ietf.org/doc/html/rfc7517#section-4.7 wird durch den Zustelldienst technsich erzwungen.
     • Das x5c-Attribut enthält genau drei Zertifikate (Zertifikatskette bestehend aus Zertifikat, CA-Zertifikat (DOI-CA) und Root-Zertifikat). Gemäß https://datatracker.ietf.org/doc/html/rfc7517#section-4.7 müssen die Zertifikat in genau dieser Reihenfolge angegeben sein. - Es wurde überprüft, dass der öffentliche Schlüssel mit dem im JSON Web Key hinterlegten Zertifikat übereinstimmt (Attribute n und e)
     • Es wurde die Zertifikats-Kette bis zum Wurzelzertifikat (BSI) überprüft.
     • Es wurde die Zertifikats-Kette mittels eines Validierungsdienstes (gegen eine Certificate Revocation List (CRL) und/oder einen OCSP-Endpunkt) mit signierten Antworten überprüft
2. Keys, die Anforderungen nicht erfüllen, können nicht hochgeladen und nicht abgerufen werden.
   • Eine vollständige Prüfung wird beim Upload, vor der Speicherung, überprüft
   • Eine vollständige Prüfung wird vor der Herausgabe über die API überprüft (Erläuterung: Wird das hinterlegte Zertifikat nach dem Upload zurückgezogen oder für ungültig erklärt, dann darf dieses Zertifikat nicht abgerufen werden können.)
3. Für den Betrieb in der Testumgebung besteht die Möglichkeit, die Prüfung von Zertifikaten via Config-Flag abzuschalten. In der Testumgebung ist insb. die Nutzung von selbst-erstellen JWKs ohne Zertifikat aus einer PKI möglich.
4. Root-Zertifikate müssen beim Dienst hinterlegt werden und regelmäßig auch auf Aktualisierung überprüft werden (hinsichtlich neuer Zertifikate [aktuell ein paar mal im Jahr kommt ein neues dazu])
5. Neu: Die Prüfung erfolgt auch, wenn sie abgeschaltet ist. Dabei werden jedoch nur Fehler geloggt. Die Fehler/Exceptions werden im letzten Schritt jedoch ignoriert.
6. Neu: Die Vorgaben der Technische Richtlinie TR02103 sind eingehalten.
7. Es wurde ein Follow-Up-Ticket zum Prüfen der Logs und Schafschalten der Config angelegt. (planning#575)