Ich habe das Projekt zu Pflege und Management einer PKI aus beliebig vielen CAs erweitert.

Das Projekt wurde zunächst um einige kleinere Verbesserungen der Dokumentation erweitert - unter anderem betrifft das die explizite Anleitung zur Beantragung und Ausstellung von Zertifikaten für beliebig viele E-Mail-Adressen - zum Beispiel zur Verwendung von S/Mime zur vertraulichen EMail-Kommunikation:

Nutzt man diese Möglichkeit, benötigt man auch im Besitz mehrerer EMail-Adressen lediglich ein Zertifikat, da die EMail-Adressen - genau wie für Serverzertifikate, die für mehrere Hostnamen ausgestellt werden - einfach als Subject Alternative Names (SAN) angegeben werden können.

Funktional wurden die Skripte dahingehend erweitert, dass es möglich ist, die nutzerdefinierten OIDs nicht nur für custom Policies einzusetzen, sondern damit auch nutzerdefinierte Extensions und weitere Felder für den Distinguished Name (DN) zu definieren. Dazu werden bei der Erstellung einer Issuing CA entsprechende Konfigurationsdateien erstellt, die durch die End Entities zur Erzeugung des Zertifikatsrequests benutzt werden können. In diesen Dateien sind Platzhalter für sämtliche bei der Erstellung der CA definierten custom OIDs sowohl als Erweiterung des DN, als auch als custom Erweiterung enthalten. Vor Aktivierung der CA sind diese Platzhalter entsprechend zu aktivieren.

Entsprechende Platzhalter existieren ebenfalls in der Konfigurationsdatei für den Betrieb der CA - auch dort müssen die entsprechenden Änderungen - passend zu denen in den CSR-Konfigurationen - aktiviert werden. Ein entsprechender Abschnitt, der diese Änderungen demonstriert, wurde in die Dokumentation eingefügt.

Weiterhin wurde erste Tests zur Verwendung des Projektes für Cross-Zertifizierungen erfolgreich ausgeführt:

Erstellt man zwei PKI - je eine für Domain A und Domain B - wie hier dargestellt, so vertraut user1 einer EMail von user2 nicht, da dessen Zertifikat +ber keine von user1 als vertrauenswürdig eingestufte Wurzel verfügt.

Dieses Bild zeigt die Vertrauensketten, die user1 und user2 kennen - sie liegen jeweils in der eigenen Domain.

Beide könnten nun überein kommen, den Wurzelzertifikaten der jeweils anderen Domain das Vertrauen auszusprechen. Dann sind aber beide auf die Integrität und Vertrauenswürdigkeit der jeweils anderen Root CA angewiesen. Besser ist es, wenn dieses gegenseitige Vertrauen entkoppelt wird wie in der nächsten Abbildung dargestellt:

Dadurch, dass in Domain A eine CA eingerichtet wurde, die das Zertifikat der Identity CA B beglaubigt, entsteht eine Vertrauenskette, die user1 nutzen kann, um Zertifikate der Identity CA B zu prüfen - er muss dazu jetzt nicht mehr der Root CA (oder der Intermediary CA) der Domain B vertrauen. Außerdem kann ein Administrator auf einfache Art und Weise diese Kopplung wieder aufheben - er benötigt dazu nicht die Unterstützung der Administratoren aus Domain B - falls er den Verdacht hat, dass Domain B kompromittiert worden ist. Dazu muss er einfach das Zertifikat, das durch die Bridge cA für Identity CA B ausgestellt wurde widerrufen. Die untenstehende Abbildung zeigt die zwei bekannten Vertrauensketten und die durch die Bridge CA zusätzlich hinzugekommene:

Die Administration der Domain B kann sich entscheiden, dasselbe Vorgehen spiegelbildlich ebenfalls auszuführen - damit wird auch die Herkunft des Begriffes Cross Certification plausibel: Würde man diese zusätzliche Vertrauenskette ebenfalls noch in die Darstellung integrieren, würden sich die zwei kreuzen.

Artikel, die hierher verlinken

Kommentar hinzufügen (via ) Kommentare ansehen (via )

Kommentar hinzufügen (via ) Kommentare ansehen (via )