PKI-Kopplung in der Praxis

Ein Knackpunkt beim Einsatz von Public-Key-Kryptographie ist die Authentizität der verwendeten öffentlichen Schlüssel. Sicherzustellen, dass ein in der Kennung angegebener Name authentisch ist beziehungsweise ein Public Key auch wirklich seinem vorgeblichen Besitzer gehört, ist dabei Aufgabe von Public-Key-Infrastrukturen (PKIs). Innerhalb einer PKI wird durch eine Zertifizierungsinstanz (Certification Authority, CA) die Zusammengehörigkeit eines öffentlichen Schlüssels zu einem bestimmten Besitzer per elektronischer Signatur in einem Zertifikat bestätigt. Zur Prüfung eines Benutzer-Zertifikats bedarf es daher eines (geprüften) CA-Zertifikats sowie dem Vertrauen in diese CA.

Gäbe es eine weltumspannende PKI, die für alle Menschen Zertifikate erzeugt, so würde ein einziger Vertrauensanker genügen, um global vertraulich und sicher zu kommunizieren. Die Realität sieht jedoch anders aus: PKIs dieser Größenordnung haben sich nicht durchgesetzt, nicht zuletzt weil Zertifkate oft für ganz bestimmte Zwecke eingesetzt werden, bei denen sowohl das benötigte Sicherheitsniveau als auch das Vertrauen in externe Zertifizierungsinstanzen variiert.

So überlässt man beispielsweise das Ausstellen von (SSL-)Zertifikaten für Webserver durchaus großen Zertifizierungsdienstleistern, die – beispielsweise durch eine Webtrust-Zertifizierung – das notwendige Vertrauen gewonnen haben, um ihr CA-Zertifikat in die gängigen Anwendungen integrieren zu dürfen. Für die Authentifizierung des Zugriffs auf ein Hochsicherheitsnetz wird man jedoch eher nur einer selbst betriebenen CA vertrauen, deren Sicherheitsniveau genau an die benötigten Anwendungen angepasst wurde. Auch die erheblichen Kosten für Zertifikate kommerzieller Anbieter können ein Grund sein, selbst eine CA zu betreiben. Dies gilt besonders für den Einsatz von Benutzer-Zertifikaten, wo man deutlich größere Mengen von Zertifikaten benötigt als für einzelne Server.

Die heutige PKI-Landschaft besteht daher aus vielen Vertrauensinseln verschiedener Zertifizierungsinstanzen, die nach sehr unterschiedlichen Regeln (Policies) Zertifikate erteilen und verwalten, wodurch auch die Qualität der ausgestellten Zertifikate variiert. Um solche Inseln zu verbinden und ihre "Bewohner" für die eigene PKI nutzbar zu machen, muss man entweder das fremde Stammzertifikat selbst prüfen und einbinden oder auf so genannte Cross-Zertifikate und damit auf die Prüfung durch eine bereits vertraute CA zurückgreifen.

Weitere Verfahren zum Verbinden von PKIs sind zum Beispiel das Sammeln von CA-Zertifikaten in einer (ggf. signierten) Datei, die Anwendungen in einem Schritt importieren können, oder die Implementierung einer übergeordneten (Super-)CA, die für die zu verbindenden CAs jeweils neue CA-Zertifikate erzeugt. Das erste Verfahren wurde beispielsweise vom TERENA Academic CA Repository ( [externer Link]

www.TACAR.org) gewählt, um die Wurzel-Zertifikate der europäischen Forschungsnetze der Trans-European Research and Education Networking Association (TERENA) zu verteilen.

Alle diese Verfahren setzen jedoch voraus, dass auch die benutzten Anwendungen damit umgehen können. Die Auswertung von Zertifikatketten mit Cross-Zertifikaten stellt beispielsweise zusätzliche Anforderungen an die Zertifikat-Analyse-Logik: So besteht im Falle einer einzelnen CA der Graph aller Zertifikate jeweils aus einem Baum, wobei die CA jeweils die Wurzel bildet, Äste führen zu untergeordneten CAs, welche wiederum zu den Anwenderzertifikaten verzweigen. Das gegenseitige Ausstellen von Cross-Zertifikaten zweier CAs erzeugt jedoch eine Schleife – darauf müssen die Algorithmen vorbereitet sein, die Anwendungen zum Validieren von Zertifikatketten verwenden (vgl. Abb. 1).

Test-Szenarien

In einem umfangreichen Test hat daher die DFN CERT Services GmbH einige Szenarien zum Verbinden von PKIs auf das Zusammenspiel mit gängigen Anwendungen und Betriebssystemen untersucht. Die getesteten Anwendungen umfassen Mail-Clients und Web-Browser unter Windows 2000/XP sowie (SuSE) Linux. Im Einzelnen wurden aufgrund ihrer Verbreitung Internet Explorer und Outlook Express sowie Outlook XP (unter Microsoft Windows), Mozilla, Firefox/Thunderbird und Opera (alle OS) sowie Kmail und KDE Konqueror (nur SuSE Linux) ausgewählt.

----------Anfang Textkasten----------

Kasten überspringen

Public-Key Cryptography Standards

Die Public-Key Cryptography Standards (PKCS) definieren Datenformate für den Austausch von Schlüsselmaterial und verschlüsselten Nachrichten. Urheber dieser Dokumente ist RSA Security – die PKCS sind über [externer Link] www.rsasecurity.com/rsalabs/pkcs/ frei erhältlich. Einige der von 1–15 durchnummerierten PKCS tauchen immer wieder im Zusammenhang mit Zertifikaten oder Smartcards auf – andere sind weniger bekannt:

PKCS #1 – RSA Cryptography Standard: Beschreibt die Implementierung des RSA-Algorithmus mit den Operationen für Verschlüsselung und Signatur.
PKCS #2 – RSA Key Syntax Standard: wurde mittlerweile in PKCS #1 integriert.
PKCS #3 – Diffie-Hellman Key Agreement Standard: beschreibt die Implementierung des Diffie-Hellman-Schlüsselaustauschverfahrens, mit dem zwei Kommunikationspartner sich auf einen gemeinsamen geheimen Kommunikationsschlüssel einigen können.
PKCS #4 – RSA Encryption of Message Digests: wurde mittlerweile in PKCS #1 integriert.
PKCS #5 – Password-Based Cryptography Standard: macht Vorschläge für Verfahren, um aus Passwörtern Schlüssel herzuleiten, die zum Verschlüsseln und Signieren verwendet werden können.
PKCS #6 – Extended-Certificate Syntax Standard: eine Zwischenlösung, um Erweiterungen für X.509v1-Zertifikate zu realisieren – ist seit X.509v3 veraltet.
PKCS #7 – Cryptographic Message Syntax Standard: spezifiziert ein Nachrichtenformat, um Daten mit kryptographischen Informationen "anzureichern" – hiermit werden typischerweise Signaturen, Widerrufslisten und Zertifikate übertragen. Das Format erlaubt Rekursion, sodass Daten zunächst signiert und die resultierende PKCS-#7-Nachricht anschließend verschlüsselt wieder als PKCS-#7-Nachricht abgelegt werden kann. S/MIME-E-Mails benutzen beispielsweise ein PKCS-#7-Attachment, um Signaturen und Zertifikate zu übertragen.
PKCS #8 – Private-Key Information Syntax Standard: beschreibt ein Format zum Speichern von Private Keys; dabei werden diese Schlüssel mit einer Passphrase chiffriert.
PKCS #9 – Selected Attribute Types: definiert überwiegend Attribute, die in verschiedenen anderen Formaten (PKCS #7, #10, #12 und #15) verwendet werden; hierzu gehört beispielsweise das Challenge Passwort in einer Zertifizierungsanfrage (PKCS #10). Ein großer Teil der Attribute dient der Beschreibung von Personen, zu denen Keys oder Zertifikate gehören (z. B. Geburtsort, Pseudonym oder E-Mail-Adresse).
PKCS #10 – Certification Request Syntax Standard: beschreibt das Format von Zertifizierungsanfragen. Diese liefern die notwendigen Informationen, die von einer CA zum Erzeugen eines Zertifikats benötigt werden; sie enthalten den öffentlichen Schlüssel, den Namen des Antragstellers sowie einige zusätzliche Attribute, signiert mit dem Private Key des Antragstellers.
PKCS #11 – Cryptographic Token Interface Standard: spezifiziert eine generische Schnittstelle, um Soft- und Hardware-Token von Anwendungen aus anzusprechen (z. B. Browser, Mail-Clients).
PKCS #12 – Personal Information Exchange Syntax Standard: definiert ein Datenformat, das in der Regel dazu dient, Zertifikate von CAs und Individuen, Private Keys und CRLs zu speichern; Teile dieser Daten können verschlüsselt sein. Das Datenformat ist sehr flexibel gehalten, was einerseits die Speicherung nahezu beliebiger Daten ermöglicht, andererseits jedoch die Implementierung erschwert (vgl. Peter Gutmanns Kritik auf www.cs.auckland.ac.nz/~pgut001/pubs/pfx.html). In der Praxis ermöglicht es unter anderem, zusammen mit dem Private Key und Zertifikat eines Benutzers auch die zugehörigen Zertifikate der ausstellenden CA(s) zu verteilen.
PKCS #13 – Elliptic Curve Cryptography Standard: ist noch in Arbeit und soll einige Aspekte von Verschlüsselungsverfahren auf der Basis elliptischer Kurven umfassen, beispielsweise die Schlüsselgenerierung und entsprechende digitale Signaturen.
PKCS #14 – Pseudorandom Number Generation Standard: befasst sich mit der Implementierung von Pseudo-Zufallszahlen-Generatoren und befindet sich ebenfalls noch in der Entwicklung.
PKCS #15 – Cryptographic Token Information Format Standard: spezifiziert ein Dateisystem für Chipkarten, das es ermöglicht in gleicher Weise auf verschiedene Smartcards zuzugreifen.

----------Ende Textkasten----------

Die Szenarien mit Sub-CAs ermöglichen es, nicht nur komplette PKIs zu verbinden, sondern Vertrauen auch nur für Teilbereiche einer fremden PKI auszudrücken. Das letzte Szenario behandelt das Aktualisieren eines auslaufenden Wurzelzertifikats: Dies ist in der Regel ein aufwändiger Prozess, da ein neues Wurzelzertifikat keine bereits bekannten Signaturen trägt und daher per se nicht vertrauenswürdig ist. Durch ein Cross-Zertifikat von der "vorigen" CA kann das Vertrauen von der bereits bestehenden PKI auf das neue Wurzelzertifikat übertragen werden – ein solches Vorgehen wird in RFC 2510 "Internet X.509 Public Key Infrastructure Certificate Management Protocols" vorgeschlagen ( [externer Link]

www.rfc-editor.org/rfc/rfc2510.txt).

Alle diese Szenarien sind jedoch auf die Unterstützung durch die Anwendungen angewiesen – erwartungsgemäß hielten die Tests einige Überraschungen bereit, obwohl das generelle Maß an Unterstützung der Szenarien recht gut ausfiel (vgl. Tab. 1 und Tab. 2).

Anwendung	Betriebssystem	Szenario 1 (PKCS #12)			Szenario 2 (PKCS #7)			Szenario 3 (SuperCA)			Szenario 4 (Cross Root-Root)			Szenario 5 (Cross Root-Sub)			Szenario 6 (Cross Sub-Sub)			Szenario 7 (Cross New PKI)
Anwendung	Betriebssystem	Import	Prüfung	Verschlg.	Import	Prüfung	Verschlg.	Import	Prüfung	Verschlg.	Import	Prüfung	Verschlg.	Import	Prüfung	Verschlg.	Import	Prüfung	Verschlg.	Import	Prüfung	Verschlg.
Outlook Express 6.0 SP1	Windows 2000	+	+	+	+	+	+	+	+	+	+	+	+	+	+	+	+	+	+	+	+	± ¹
Outlook Express 6.0 SP1	Windows XP	+ ²	+	+	+	+	+	+	+	+	+	+	+	+	+	+	+	+	+	+	+	± ¹
Outlook XP	Windows 2000	+	+	+	+	+	+	+	+	+	+	+	+	+	+	+	+	+	+	+	+ ³	± ¹
Outlook XP	Windows XP	+ ²	+	+	+	+	+	+	+	+	+	+	+	+	+	+	+	+	+	+	+ ³	± ¹
Mozilla 1.7.2	Windows 2000	+ ⁴	+	+	− ⁵	+	+	+ ⁶	+	+	+	+	+	+	+	+	+	+	+	− ⁷	− ⁸	± ¹
	Windows XP	+ ⁴	+	+	− ⁵	+	+	+ ⁶	+	+	+	+	+	+	+	+	+	+	+	− ⁷	− ⁸	± ¹
	SuSE Linux 9.2	+ ⁴	+	+	− ⁵	+	+	+ ⁶	+	+	+	+	+	+	+	+	+	+	+	− ⁷	− ⁸	± ¹
Thunderbird 1.0	Windows 2000	+ ⁴	+	+	− ⁵	+	+	+ ⁶	+	+	+	+	+	+	+	+	+	+	+	− ⁷	− ⁸	± ¹
	Windows XP	+ ⁴	+	+	− ⁵	+	+	+ ⁶	+	+	+	+	+	+	+	+	+	+	+	− ⁷	− ⁸	± ¹
	SuSE Linux 9.2	+ ⁴	+	+	− ⁵	+	+	+ ⁶	+	+	+	+	+	+	+	+	+	+	+	− ⁷	− ⁸	± ¹
Kmail 1.7 (KDE 3.3)	SuSE Linux 9.2	+ ⁹	+ ¹⁰	+	+ ⁹	+ ¹⁰	+	+ ⁹	− ^10,¹¹	− ¹²	+	− ^10,¹¹	− ¹²	+	− ^10,¹¹	− ¹²	+	− ^10,¹¹	− ¹²	+	− ^10,¹¹	− ¹²
Fußnoten		¹ nach Gültigkeitsablauf ist keine Verschlüsselung mehr möglich, ² Änderung der Default-Werte im Zertifikatsspeicher notwendig, ³ nach Gültigkeitsablauf schägt die Signaturprüfung fehl, ⁴ nach Import ist manuelle Anpassung der "Vertrauens-Wurzel" notwendig, ⁵ nur erstes Zertifikat importiert, ⁶ manueller Import mehrerer Zertifikate erforderlich, ⁷ "Alt-mit-Neu"-Cross-Zertifikat-Import schlägt fehl, ⁸ Anwendung reagiert nicht mehr nach "Alt-mit-Neu"-Cross-Zertifikat-Import, ⁹ Konfigurationsanpassung beim GPG-Agent erforderlich, ¹⁰ manuelle Anpassung der "Vertrauens-Wurzel" notwendig, ¹¹ nicht alle Zertifikatsketten werden ausgewertet und Auftreten von Fehlrückweisungen, ¹² je nach Prüfergebnis (vgl. Fußnote 11)

Tabelle 1: Ergebnis-Matrix zu E-Mail-Funktionen

Anwendung	Betriebssystem	Szenario 1 (PKCS #12)		Szenario 2 (PKCS #7)		Szenario 3 (SuperCA)		Szenario 4 (Cross Root-Root)		Szenario 5 (Cross Root-Sub)		Szenario 6 (Cross Sub-Sub)		Szenario 7 (Cross New PKI)
Anwendung	Betriebssystem	Import	Prüfung	Import	Prüfung	Import	Prüfung	Import	Prüfung	Import	Prüfung	Import	Prüfung	Import	Prüfung
Internet Explorer 6.0 SP1	Windows 2000	+	+	+	+	+	+	+	+	+	+	+	+	+	+ ¹³
Internet Explorer 6.0 SP1	Windows XP	+	+	+	+	+	+	+	+	+	+	+	+	+	+ ¹³
Mozilla 1.7.2	Windows 2000	+ ⁴	+	− ⁵	+	+ ⁶	+	+	+	+	+	+	+	− ⁷	− ⁸
	Windows XP	+ ⁴	+	− ⁵	+	+ ⁶	+	+	+	+	+	+	+	− ⁷	− ⁸
	SuSE Linux 9.2	+ ⁴	+	− ⁵	+	+ ⁶	+	+	+	+	+	+	+	− ⁷	− ⁸
Firefox 1.0	Windows 2000	+ ⁴	+	− ⁵	+	+ ⁶	+	+	+	+	+	+	+	− ⁷	− ⁸
	Windows XP	+ ⁴	+	− ⁵	+	+ ⁶	+	+	+	+	+	+	+	− ⁷	− ⁸
	SuSE Linux 9.2	+ ⁴	+	− ⁵	+	+ ⁶	+	+	+	+	+	+	+	− ⁷	− ⁸
Opera 7.54	Windows 2000	+ ⁴	+	+ ¹⁴	+	+	± ¹⁵	+	± ¹⁵	+	± ¹⁵	± ¹⁶	± ¹⁵	− ⁷	± ¹⁵
	Windows XP	+ ⁴	+	+ ¹⁴	+	+	± ¹⁵	+	± ¹⁵	+	± ¹⁵	± ¹⁶	± ¹⁵	− ⁷	± ¹⁵
	SuSE Linux 9.2	+ ⁴	+	+ ¹⁴	+	+	± ¹⁵	+	± ¹⁵	+	± ¹⁵	± ¹⁶	± ¹⁵	− ⁷	± ¹⁵
Konqueror (KDE 3.3)	SuSE Linux 9.2	− ¹⁷	+	−	+	+ ⁶	+	+	+	+	± ¹¹	+	± ¹¹	+	− ¹⁸
Fußnoten		⁴ nach Import ist manuelle Anpassung der "Vertrauens-Wurzel" notwendig, ⁵ nur erstes Zertifikat importiert, ⁶ manueller Import mehrerer Zertifikate erforderlich, ⁷ "Alt-mit-Neu"-Cross-Zertifikat-Import schlägt fehl, ⁸ Anwendung reagiert nicht mehr nach "Alt-mit-Neu"-Cross-Zertifikat-Import, ¹¹ nicht alle Zertifikatsketten werden ausgewertet und Auftreten von Fehlrückweisungen, ¹³ nach Gültigkeitsablauf erscheinen Warnmeldungen, ¹⁴ nach Import müssen Warnmeldungen deaktiviert werden, ¹⁵ Anpassungen bei Server-Zertifikatskette notwendig, ¹⁶ Import von Cross-Zertifikaten nur mithilfe von Tricks möglich, ¹⁷ nur Import von Benutzerzertifikat und -schlüssel erfolgt, ¹⁸ Fehlrückweisungen von Root-B- und "Alt-mit-neu"-Zertifikatsketten

Tabelle 2: Ergebnis-Matrix zu Browser-Funktionen

Importformate

Das erste Problem der Zertifikatverteilung stellt schon der Import in die Anwendungen dar: Übernimmt eine CA das Erzeugen der Schlüssel für ihre Anwender, so werden PKCS#12-Dateien benutzt, um den geheimen Schlüssel, das Benutzer-Zertifikat und die zugehörigen CA-Zertifikate zu übermitteln. Den PKCS#12-Import unterstützen zwar alle getesteten Anwendungen, allerdings werden nicht immer die zugehörigen CA-Zertifikate mit importiert – sehr häufig müssen nach dem Import noch weitere Einstellungen für jedes neue Zertifikat manuell vorgenommen werden.

Schwieriger gestaltete sich der Versuch, mehrere Wurzel-Zertifkate in einem PKCS#7-File auszuliefern. Die Mehrzahl aller Anwendungen importiert dann jeweils nur das erste Zertifikat, obwohl der PKCS#7-Standard mehrere Zertifikate durchaus vorsieht. Insbesondere geben einige Anwendungen keine Meldungen über die von ihnen ignorierten CA-Zertifikate aus, sodass der unvollständige Import (zunächst) unbemerkt bleibt.

Der Import von Zertifikaten in Web-Browser muss zudem jeweils von Hand gestartet werden, entweder aus einer lokalen Datei oder durch Aufrufen einer URL, die auf eine Zertifikat-Datei verweist. Bei Mail-Anwendungen kann der Import auch transparent für den Benutzer erfolgen: Dazu können die Clients aus empfangenen Mails automatisch enthaltene Zertifikate importieren. In der Regel geschieht dies mindestens mit Benutzer-Zertifikaten, deren CA bereits als vertrauenswürdig eingestuft ist.

CA-Strukturen

Änderungen in der Struktur der Zertifikat-Graphen können das Verteilen von CA-Zertifikaten vereinfachen. Beispielsweise kann man für eine Gruppe von CAs eine Super-CA einrichten, wobei die Wurzel-Zertifikate der CAs durch CA-Zertifikate ersetzt werden, welche die Super-CA ausstellt. Dann muss nur noch das Zertifikat der Super-CA vertrauenswürdig verteilt werden. Die Anwendungen sollten allerdings berücksichtigen, dass es nun für eine CA zwei Zertifikate geben kann: nämlich das alte Wurzel-Zertifikat und das neue, von der Super-CA ausgestellte. Die meisten Anwendungen können dies erwartungsgemäß, jedoch gibt es auch hier einzelne Ausnahmen: kmail/GPG machen Fehler beim Auswerten der möglichen "Vertrauenspfade" und auch Opera verfolgt nicht alle Pfade korrekt.

Doch schon Cross-Zertifikate verändern den Zertifikat-Graphen und bilden ebenfalls neue Pfade zu Zertifikaten. Der erste Test mit Cross-Zertifikaten zwischen zwei Wurzel-CAs wurde von der Mehrheit der Anwendungen gut bestanden, nur der Web-Browser Opera scheint mit Cross-Zertifkaten insgesamt Schwierigkeiten zu haben. Bei kmail tauchten in der S/MIME-Implementierung von GnuPG (gpgsm) Unregelmäßigkeiten in der Zertifikatbehandlung auf, die auf die Reihenfolge des Imports von Zertifikaten zurückgingen – diese sollen mittlerweile jedoch behoben sein.

Der Austausch von Wurzelzertifikaten ist ein interessanter Anwendungsfall. Das Aufsetzen einer neuen Wurzel-CA wird immer dann unumgänglich, wenn der Gültigkeitszeitraum des alten "Roots" ausläuft. Leider funktionierte dies nur bei den getesteten Microsoft-Anwendungen reibungslos. Im Falle der Mail-Programme Outlook und Outlook Express wird das neue Wurzel-Zertifikat automatisch aus einer E-Mail importiert; allerdings verschwindet das Vertrauen in das neue Zertifikat, wenn das alte Wurzel-Zertifikat und das von ihr ausgestellte Cross-Zertifikat auslaufen.

Andere Anwendungen weigern sich jedoch bereits, das zweite Cross-Zertifikat, das von der neuen Wurzel erzeugt wurde, überhaupt zu importieren. Bei Thunderbird werden die Cross-Zertifikate zwar nicht automatisch aus einer E-Mail gelesen, ein manueller Import funktioniert jedoch. Werden beide Cross-Zertifikate importiert, so ist jedoch keine Mozilla-Anwendung mehr in der Lage, die aktuelle Zertifikat-Kette anzuzeigen – hier hängen die Applikationen offenbar in einer Endlos-Schleife.

Viel zu tun

Das Verbinden mehrerer bestehender PKIs bleibt weiterhin eine mühsame Aufgabe. Werden nur Microsoft-Anwendungen eingesetzt, so ergeben sich zwar nur Schwierigkeiten beim Erneuern eines Wurzel-Zertifikats. Alle anderen Anwendungen zeigen jedoch Mängel: Oftmals gestaltet sich schon der Import von neuen Zertifikaten als schwierig, manchmal ist aber auch die Auswertung der Vertrauenspfade im Zertifikatgraphen fehlerhaft.

Dies hat gewöhnlich zur Folge, dass kein Vertrauen in die neu eingebundenen Zertifikate besteht, in einigen Fällen kommt es sogar zu Abstürzen der Anwendungen. Hier sind die Hersteller der gängigen Anwendungen gefordert, die notwendigen Algorithmen zu implementieren.

Dies gilt umso mehr als die Tests nur sehr einfache Szenarien berücksichtigt haben. Neuere Standards spezifizieren bereits Erweiterungen in den verwendeten Cross-Zertifikaten, die beispielsweise Auskunft geben über die Äquivalenz der zugrunde liegenden Zertifizierungsregeln (sog. Policy Mappings). Anwendungen könnten damit dann die neu eingebundenen PKIs je nach gefordertem Sicherheitsniveau differenziert behandeln.

Der vollständige "PKI-Linking-Report: Connecting Public-Key-Infrastructures" ist in englischer Sprache frei verfügbar und kann per Internet von [externer Link]

www.dfn-pca.de/bibliothek/reports/pki-linking/ bezogen werden.

PKI-Kopplung in der Praxis

Ordnungsmerkmale

erschienen in: <kes> 2005^#4, Seite 6

Rubrik: Systeme und ihr Umfeld

Schlagwort: Public Key Infrastructures

Zusammenfassung: Um die heutigen Insellösungen verschiedener Public-Key-Infrastrukturen zu verbinden, gibt es mehrere Möglichkeiten, deren praktische Umsetzung im Zusammenspiel mit gängigen Applikationen eine Studie der DFN CERT Services unlängst näher ergründet hat.

Autor: Von Olaf Gellert, Hamburg

Test-Szenarien

Public-Key Cryptography Standards

Importformate

CA-Strukturen

Viel zu tun

PKI-Kopplung in der Praxis

Ordnungsmerkmale

erschienen in: <kes> 2005#4, Seite 6

Rubrik: Systeme und ihr Umfeld

Schlagwort: Public Key Infrastructures

Zusammenfassung: Um die heutigen Insellösungen verschiedener Public-Key-Infrastrukturen zu verbinden, gibt es mehrere Möglichkeiten, deren praktische Umsetzung im Zusammenspiel mit gängigen Applikationen eine Studie der DFN CERT Services unlängst näher ergründet hat.

Autor: Von Olaf Gellert, Hamburg

Test-Szenarien

Public-Key Cryptography Standards

Importformate

CA-Strukturen

Viel zu tun

erschienen in: <kes> 2005^#4, Seite 6