Struktur von PKIs re: Archivzeitstempel

vorhergehende Artikel in: PKI-X.509-CA Security
12.11.2022

Hier nochmal eine Beleuchtung der Organisation einer Public Key Infrastructure (PKI) von einem (von mir) bisher nicht betrachteten Blickwinkel

Ich möchte - nun, da sich das Projekt Timestamping Server mit der baldigen Aufname der Certificate Revocation Lists (CRLs) wieder einem Meilenstein - der Erzeugung vollgültiger Archivzeitstempel - nähert hier nochmals auf Gründe eingehen, PKIs zu strukturieren.

Mit Strukturieren ist hier die hierarchische Gliederung von Root- und Intermediary-CAs gemeint: Prinzipiell spricht technisch nichts dagegen, eine Certificate Authority (CA) zu betreiben, die - wie in dieser Darstellung abgebildet - Issuing CA für alle Arten von Zertifikaten ist:

Screenshot Quelle: https://pki-tutorial.readthedocs.io/en/latest/simple/index.html

Allerdings spricht einiges dafür, nicht nur eine Issuing - oder wie in der Darstellung genannt: Signing CA zu haben. Es macht Dinge durchaus einfacher, in der PKI die organisatorische Struktur der Entities abzubilden, für die Zertifikate erstellt werden sollen. Es kann nämlich durchaus sein, dass entlang dieser Struktur unterschiedliche Anforderungen an die Entities für die Aushändigung eines Zertifikats definiert sind. Dann ist es einfacher, dafür verschiedene CAs aufzusetzen, in deren Certificate Practise Statements (CPSs) bzw. Policies sich diese Einschränkungen klar widerspiegeln.

Das zeigt sich zum Beispiel an der (trivialen) Unterscheidung, die bereits in der Darstellung zu erkennen ist - nämlich die in Zertifikate für Personen und Geräte (Email und TLS). Daher ist es angeraten, wenigstens diese Aufteilung auch in der PKI widerzuspiegeln. Ein erster Schritt in diese Richtung wäre eine Struktur wie hier dargestellt:

Screenshot Quelle: https://pki-tutorial.readthedocs.io/en/latest/advanced/index.html

Aber auch hier erfolgt die Gliederung eher nach dem technischen Kriterium der Art des Zertifikats bzw. der Digitalen Identität (DI) - aber wie bereits oben angesprochen kann es sehr nützlich sein, eine weitere Gliederungsebene einzuführen, die die Menge der Zertifikate organisatorisch teilt. Eine beispielhafte Struktur für so etwas ist hier dargestellt:

Screenshot Quelle: https://pki-tutorial.readthedocs.io/en/latest/expert/index.html

In dieser Darstellung fehlen die ausgestellten Zertifikate - nur die CAs werden noch dargestellt. Die neue Ebene der Hierarchie, auf welcher sich die Network-CA befindet gliedert die PKI entlang organisatorischer Schnittkanten. Das könnten etwa die verschiedenen Bereiche in einem Unternehmen wie Management, Entwicklung und Produktion sein.

Eine solche Gliederung bringt aber nicht nur Vorteile durch die klarere Verantwortlichkeit jeder CA - und damit die einfachere Formulierung jedes CPS / jeder Policy. Fällt irgendwann eine der Struktureinheiten weg, muss man in dem Fall nur die jeweilige CA für ungültig erklären. Wären die Verantwortlichkeiten vermischt, müsste die CA, die auch die Zertifikate für die weggefallene Struktureinheit ausgestellt hat, sämtliche dafür ausgestellten Zertifikate für ungültig erklären. Das würde unter Umständen und abhängig von den genauen Zahlen für eine gewaltig anwachsende Größe der jeweiligen CRL führen.

Und damit sind wir wieder beim ursprünglichen Grund des Artikels angekommen: In Archivzeitstempeln werden die zur Zeit der Erzeugung des Zeitstempels gültigen Zertifikate der CAs in der gesamten Kette bis zur Root-CA sowie die jeweiligen CRLs gespeichert. Trennt man die Verantwortlichkeiten nicht klar in der PKI kann es passieren, dass Archivzeitstempel extrem aufgebläht werden.

Daher sollte man darauf achten, dass die Kette des Signer-Zertifikats einer Timestamping Authority (TSA) so gestaltet ist, dass jede darin enthaltene CA möglichst wenige Zertifikate signiert - und auch in Zukunft nur wenige signieren wird, um die potentielle Größe der Archivzeitstempel so gering wie möglich zu halten.

Artikel, die hierher verlinken

Git als beweisfestes Langzeitarchiv(?)

11.01.2023

Ich habe hier verschiedentlich über das Thema Langzeitarchivierung berichtet - unter anderem habe ich meinen Timestamping-Server nach RFC3161 so erweitert, dass er entsprechende Archivzeitstempel erstellen kann. Und so stolperte ich zwangsweise über Parallelen zwischen Git und Archivsystemen

Security QA mit Kotlin-Bibliotheken und Java

12.11.2022

Über die Probleme und Herausforderungen beim Unit-Testen im Security-Umfeld mit Kotlin-Bibliotheken...

Alle Artikel rss Wochenübersicht Monatsübersicht Github Repositories Gitlab Repositories Mastodon Über mich home xmpp


Neueste Artikel

  • Github hat keine Ahnung von Crypto und Sicherheit

    Morgen - am 1.2.2023 - soll mein neuer $dayjob anfgangen - und damit die Quelle, aus der ich die Mittel beziehe, weiterhin meine Kuchenzutaten bezahlen zu können. Das wird irgendwas mit Sicherheit sein. Und am Tag davor hat sich - wer eigentlich genau? - überlegt: "Komm, lass ihn uns nochmal so richtig auf Betriebstemperatur überkochen!". Aber - der Reihe nach...

    Weiterlesen...
  • Aktualisierung TileServer - Restrukturierung

    Ich habe meinen Tile-Server für OpenStreetMap-Daten aktualisiert

    Weiterlesen...
  • Drunken Bishop in Java

    Ich habe neulich wieder einmal Lust auf eine kleine Fingerübung gehabt und deshalb ein Verfahren in Java implementiert, das ich ursprünglich als Möglichkeit kennenlernte, zwei Schlüssel beim Versuch des Aufbaus einer Verbindung mittels SSH zu vergleichen...

    Weiterlesen...

Manche nennen es Blog, manche Web-Seite - ich schreibe hier hin und wieder über meine Erlebnisse, Rückschläge und Erleuchtungen bei meinen Hobbies.

Wer daran teilhaben und eventuell sogar davon profitieren möchte, muß damit leben, daß ich hin und wieder kleine Ausflüge in Bereiche mache, die nichts mit IT, Administration oder Softwareentwicklung zu tun haben.

Ich wünsche allen Lesern viel Spaß und hin und wieder einen kleinen AHA!-Effekt...

PS: Meine öffentlichen GitHub-Repositories findet man hier - meine öffentlichen GitLab-Repositories finden sich dagegen hier.