Kommunikation in einem Trustcenter - HRZ - Technische Universität ...

Technische Universität Darmstadt
Fachbereich Informatik
Fachgebiet Kryptographie und Computeralgebra
Prof. Dr. rer. nat. Johannes Buchmann
Kommunikation in einem Trustcenter
Intra Trustcenter Protocol Version 1.2 Entwurf und Design
Diplomarbeit von Jochen Becker
Betreuer:
Dr.-Ing. Vangelis Karatsiolis
Darmstadt, 20. Juli 2007

Ehrenwörtliche Erklärung
Hiermit versichere ich, die vorliegende Diplomarbeit ohne Hilfe Dritter und nur mit den angegebenen
Quellen und Hilfsmitteln angefertigt zu haben. Alle Stellen, die aus den Quellen
entnommen wurden, sind als solche kenntlich gemacht worden. Diese Arbeit hat in gleicher
oder ähnlicher Form noch keiner Prüfungsbehörde vorgelegen.
Darmstadt, am 20. Juli 2007
iii

Kurzdarstellung
Ein Trustcenter besteht aus einzelnen Komponenten die miteinander interagieren. Zwingend
notwendig für diese Interaktion ist die Kommunikation der einzelnen Komponenten
untereinander. Dazu wird eine Protokoll benötigt, welches jegliche Art der Kommunikation
in einer Trustcenterumgebung erfassen und verarbeiten beziehungsweise weitergeben kann.
Dieses Protokoll muss auch hohe Sicherheitsanforderungen aus dem PKI-Umfeld erfüllen.
In dieser Arbeit werden aktuell eingesetzte Protokolle für die Codierung von Informationen
und Kommunikation innerhalb eines Trustcenters vorgestellt.
Im Gegensatz zu den meisten verwendeten Protokollen basiert das Intra Trustcenter Protocol
nicht auf dem nur maschinenlesbaren Datenformat ASN.1, sondern auf dem sowohl
maschinen- wie auch menschenlesbaren Datenformat XML.
Kern der hier vorliegenden Arbeit ist der Entwurf von Intra Trustcenter Protocol Version
1.2. Hierbei werden Anforderungsaspekte an ein Intra Trustcenter Management Protokoll
anhand von Szenarien vorgestellt. Die für die Abdeckung dieser Szenarien notwendigen
Nachrichten sollen modelliert und in Form eines XML-Schema implementiert werden. Im
Anschluss soll der Fortschritt gegenüber der Vorgängerversion aufgezeigt und die Neuheiten
nochmal zusammengefasst werden.
Abschließend wird noch ein Ausblick auf mögliche Verbesserungen und Erweiterungen von
Intra Trustcenter Protocol gegeben.
iv

Inhaltsverzeichnis
Kurzdarstellung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . iv
Abbildungsverzeichnis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . vii
Tabellenverzeichnis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ix
Quelltextverzeichnis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xi
1. Einleitung 1
2. Public-Key Infrastrukturen 3
2.1. Überblick . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
2.2. Bestandteile einer Public Key Infrastruktur . . . . . . . . . . . . . . . . . . 3
2.2.1. Registration Authority . . . . . . . . . . . . . . . . . . . . . . . . . . 3
2.2.2. Certification Authority . . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.2.3. Flexiprovider . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
3. Codierungsformate 9
3.1. Extensible Markup Language . . . . . . . . . . . . . . . . . . . . . . . . . . 9
3.2. Abstract Syntax Notation One . . . . . . . . . . . . . . . . . . . . . . . . . 10
3.3. Bewertung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
4. Trustcenter Management Protokolle 13
4.1. Public Key Cryptography Standard #7 . . . . . . . . . . . . . . . . . . . . 13
4.2. Public Key Cryptography Standard #10 . . . . . . . . . . . . . . . . . . . . 13
4.3. XML Key Management Specification . . . . . . . . . . . . . . . . . . . . . . 14
4.4. Certificate Management Protocol . . . . . . . . . . . . . . . . . . . . . . . . 14
5. Szenarien 17
5.1. Kernvorgänge . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
5.1.1. Beantragung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
5.1.2. Ausstellung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
5.1.3. Auslieferung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
5.1.4. Aktivierung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
5.1.5. Veröffentlichung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
5.1.6. Erneuerung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
5.1.7. Revokation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
5.2. Weitere Vorgänge . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
5.2.1. Gültigkeitsprüfung . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
5.2.2. Externe Schlüsselerzeugung . . . . . . . . . . . . . . . . . . . . . . . 21
5.2.3. Vertrauensanker erneuern . . . . . . . . . . . . . . . . . . . . . . . . 22
5.2.4. Informations- und Fehlerübermittlung . . . . . . . . . . . . . . . . . 23
v

Inhaltsverzeichnis
6. Intra Trustcenter Protocol 25
6.1. Designziele . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
6.1.1. Intra Trustcenter Protocol Version 1.0 . . . . . . . . . . . . . . . . . 27
6.1.2. Intra Trustcenter Protocol Version 1.1 . . . . . . . . . . . . . . . . . 28
6.2. Intra Trustcenter Protocol Version 1.2 . . . . . . . . . . . . . . . . . . . . . 29
6.2.1. XML-Schema Definition . . . . . . . . . . . . . . . . . . . . . . . . . 29
6.2.2. Informationssicherheit . . . . . . . . . . . . . . . . . . . . . . . . . . 30
6.2.3. Nachrichten . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
6.2.4. Analyse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
7. Fazit und Ausblick 41
7.1. Fazit zu Version 1.2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
7.2. Ausblick auf Intra Trustcenter Protocol Version 2.0 . . . . . . . . . . . . . . 41
A. ITP-Nachrichten Quelltexte 43
B. Intra Trustcenter Protocol Version 1.2 Schema 55
C. ITP-Tag Referenz 65
D. Vergleich ITP mit CMP 67
E. Gesetzestexte 69
E.1. Signaturgesetz § 7 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69
E.2. Signaturgesetz § 10 Absatz 1 . . . . . . . . . . . . . . . . . . . . . . . . . . 69
E.3. Signaturverordnung § 5 Absatz 2 Satz 2 . . . . . . . . . . . . . . . . . . . . 70
E.4. Signaturverordnung § 7 Absatz 2 . . . . . . . . . . . . . . . . . . . . . . . . 70
E.5. Signaturverordnung § 15 Absatz 2 Satz 2b) . . . . . . . . . . . . . . . . . . 70
Begriffe 71
Literaturverzeichnis 73
vi

Abbildungsverzeichnis
2.1. Struktur von Flexitrust . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.2. Komponenten von Flexitrust . . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.3. Lebenszyklus eines Schlüssels . . . . . . . . . . . . . . . . . . . . . . . . . . 6
5.1. Zertifizierungsvorgänge in einer PKI . . . . . . . . . . . . . . . . . . . . . . 17
5.2. Revokation eines Zertifikats . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
5.3. Ablauf einer OCSP Anfrage nach SigG . . . . . . . . . . . . . . . . . . . . . 22
5.4. Externe Schlüsselerzeugung . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
5.5. Schlüsselerzeugung auf einer Chipkarte . . . . . . . . . . . . . . . . . . . . . 23
6.1. Übersicht über verschiedene Module in der PKI . . . . . . . . . . . . . . . . 27
vii

Abbildungsverzeichnis
viii

Tabellenverzeichnis
3.1. Gegenüberstellung ASN.1 und XML . . . . . . . . . . . . . . . . . . . . . . 11
6.1. Felder des Kopfteils . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
6.2. Felder des Fussteiles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
6.3. ITP Version 1.2 Nachrichtentypen . . . . . . . . . . . . . . . . . . . . . . . 33
6.4. Felder der CertificateRequest-Nachricht . . . . . . . . . . . . . . . . . . . . 34
6.5. Felder der Activation-Nachricht . . . . . . . . . . . . . . . . . . . . . . . . . 34
6.6. Felder der Revocation-Nachricht . . . . . . . . . . . . . . . . . . . . . . . . 35
6.7. Felder der Recovery-Nachricht . . . . . . . . . . . . . . . . . . . . . . . . . 36
6.8. Felder der CertificateTransport-Nachricht . . . . . . . . . . . . . . . . . . . 36
6.9. Felder der KeyTransport-Nachricht . . . . . . . . . . . . . . . . . . . . . . . 37
6.10. Felder der Information-Nachricht . . . . . . . . . . . . . . . . . . . . . . . . 37
6.11. Felder der Notify-Nachricht . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
C.1. ITP Version 1.0 — XML-Tags im Überblick . . . . . . . . . . . . . . . . . . 65
C.2. ITP Version 1.1 — XML-Tags im Überblick . . . . . . . . . . . . . . . . . . 66
ix

Tabellenverzeichnis
x

Quelltexte
A.1. Standardnachricht von ITP Version 1.0 . . . . . . . . . . . . . . . . . . . . 43
A.2. Syntax einer ITP-Nachricht Version 1.0 . . . . . . . . . . . . . . . . . . . . 43
A.3. Syntax einer ITP-Nachricht Version 1.1 . . . . . . . . . . . . . . . . . . . . 44
A.4. Standard CertificateRequest-Nachricht . . . . . . . . . . . . . . . . . . . . . 45
A.5. Standard Activation-Nachricht . . . . . . . . . . . . . . . . . . . . . . . . . 46
A.6. Kürzeste Activation-Nachricht . . . . . . . . . . . . . . . . . . . . . . . . . . 47
A.7. Standard CertificateTransport-Nachricht . . . . . . . . . . . . . . . . . . . . 48
A.8. Standard KeyTransport-Nachricht . . . . . . . . . . . . . . . . . . . . . . . 50
A.9. Standard Recovery-Nachricht . . . . . . . . . . . . . . . . . . . . . . . . . . 52
A.10.Standard Revocation-Nachricht . . . . . . . . . . . . . . . . . . . . . . . . . 53
B.1. ITP 1.2 Schema . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
D.1. Aktivierungsnachricht von ITP . . . . . . . . . . . . . . . . . . . . . . . . . 67
D.2. Aktivierungsnachricht in CMP . . . . . . . . . . . . . . . . . . . . . . . . . 67
xi

Quelltexte
xii

1. Einleitung
In heutigen Zeiten werden immer mehr Prozesse elektronisch abgebildet und durchgeführt.
Da hierzu eine eindeutige Identifizierung von der beteiligten Komponenten notwendig ist,
werden digitale Identitäten ausgestellt. Jede Komponente, somit auch jede Person, die
an diesen Prozessen beteiligt ist, besitzt eine eigene eindeutige digitale Identität. Zum
Speichern dieser Identitäten wird auf Public-Key-Verfahren zurückgegriffen. Hier erhält
jede Komponente einen privaten Schlüssel, der niemandem weiter bekannt ist, und den
dazugehörige öffentliche Schlüssel. Dieser wird von einer vertrauenswürdigen Instanz zusammen
mit weiteren Informationen in einem Zertifikat gespeichert. Diese Zertifikate werden
veröffentlicht, so dass sie für andere Komponenten und Dritte zugänglich sind. Eine
Public-Key Infrastruktur (PKI) ist für diese Aufgaben konzipiert. In dieser werden Vertrauensmodelle
abgebildet und ein strukturiertes Vertrauen etabliert. Innerhalb einer PKI
gibt es den Trustcenter (TC), der die wichtigsten Komponenten bereitstellt. Alle Komponenten
müssen untereinander Kommunizieren, um sich Informationen zu beschaffen und
auszutauschen. Aktuell werden hierfür Protokolle verwendet die direkt an einer streng
hierarchischen PKI Struktur festhalten und Zertifikate nach X.509 verarbeiten. Auch ein
Verknüpfung von mehreren Protokollen wird zur Erfüllung der Aufgabe der Kommunikation
in einem TC benutzt. Ein Problem dieser Protokolle ist die Verwendung von Codierungsformaten,
die die Daten als Binärcode übertragen. Ein direkte Überprüfung dieser
Daten ist durch ein reines Betrachten des Paketes nicht möglich.
Die Anforderungen die an eine PKI und vor allem den TC gestellt werden, ergeben sich
aus aus allgemeinen Anforderungen an IT-Systeme und den Sicherheitsanforderungen aus
dem PKI-Umfeld. Weiterhin können sich Sicherheitsanforderungen aus dem speziellen Anwendungsgebiet
oder auch aus gesetzlichen Vorgaben ergeben.
Für diese Aufgaben wurde das Intra Trustcenter Protocol (ITP) entworfen und bereits
einer ersten Revision unterzogen. Die Konzepte und Ideen auf denen diese Arbeit aufbaut,
sind bereits 2004 veröffentlicht worden [28]. Ziel dieser Arbeit ist das Design und der
Entwurf von ITP Version 1.2 und die erstmaligen Einführung einer formellen Beschreibung
der Nachrichten. Hierfür soll auf XML-Schema zurückgegriffen werden. Die Struktur und
die einzelnen Elemente des Schema sollen aufgezeigt und erklärt werden. Dieses Schema soll
die bisherigen ”freien” Nachrichten ersetzen und zukünftige Nachrichten ohne Verletzung
der Allgemeinheit der Nachrichten vereinheitlichen. Es soll ein Meilenstein auf dem Weg
zur ITP Version 2.0 bilden. Das Schema soll generisch genug angelegt werden, so dass
andere Konzepte und Strukturen von Vertrauensmodellen durch ITP auch erfasst werden
können. Dabei soll auf vorhandene und etablierte Mechanismen zurückgegriffen werden.
Die vorliegende Arbeit ist wie folgt aufgebaut: Nach der Einführung in Kapitel 1 wird in
Kapitel 2 eine Überblick über eine PKI gegeben. Die einzelnen Hauptbestandteile eines TC
werden näher erläutert. In Kapitel 3 werden die zwei Codierungsformate XML und ASN.1
vorgestellt und bewertet. Kapitel 4 gibt einen Einblick in die vier am weitest verbreiteten
1

1. Einleitung
Management-Protokolle (PKCS #7, PKCS #10, XMKS und CMP). Die Szenarien die
im PKI Umfeld auftreten und für die Entwicklung von ITP 1.2 zu Grunde liegen werden
in Kapitel 5 aufgeführt. Hierbei gibt es eine Trennung in die Kernvörgänge und weitere
Operationen in einem TC. In Kapitel 6 wird ITP vorgestellt. Zu Beginn werden die Designziele
von ITP aufgeführt und die Versionen 1.0 und 1.1 vorgestellt. Der Abschnitt 6.2
befasst sich mit dem Entwurf von Version 1.2. In diesem werden die einzelnen Nachrichten
spezifiziert und deren Elemente und Attribute vorgestellt. Im Anschluss wird der Fortschritt
gegenüber der direkten Vorgängerversion analysiert. Kapitel 7 bildet das Fazit zu
ITP Version 1.2 und gibt einen Ausblick auf die Version 2.0.
Alle in dieser Arbeit verwendeten Quelltexte sind in Anhang A abgedruckt. Dort finden
sich Beispiele für die ITP-Nachrichten in Version 1.2. Das gesamte Schema von ITP Version
1.2 ist in Anhang B abgedruckt. Dies bietet die Möglichkeit eines Einblicks in die
genaue Spezifikation der Nachrichten. Im Vergleich dazu ist eine TAG-Referenz der beiden
Vorgängerversionen in Anhang C gegeben. Ein direkte Vergleich zwischen ITP und
CMP wird anhand der Aktivierungsnachricht in Anhang D geben. Die in dieser Arbeit
verwendeten Gesetzesgrundlagen finden sich in der aktuell gültigen Fassung in Anhang E.
2

2. Public-Key Infrastrukturen
2.1. Überblick
Eine Public-Key Infrastruktur (PKI) bietet die Möglichkeit Vertrauen zu etablieren. Jeder
Benutzer und jedes System in diesem Umfeld wird mit mindestens einer digitalen Identität
ausgestattet. Durch eine hierarchische Struktur ergibt sich ein Vertrauensverhältnis,
welches die PKI selbst schützen muss.
Der klassische technische Aufbau besteht aus einer Registration Authority (RA) und einer
Certification Authority (CA) [19]. Es soll möglich sein die einzelnen Komponenten
dezentral zu platzieren und gegebenenfalls auch mehrere Instanzen einer Komponente zu
haben. Auch in der Wahl der verwendeten Algorithmen wird Flexibilität gefordert. Ohne
großen Aufwand sollte ein zu schwacher Algorithmus gegen einen stärkeren Algorithmus
ausgetauscht werden können.
2.2. Bestandteile einer Public Key Infrastruktur
Am Beispiel der PKI von Flexitrust [45] werden in diesem Unterabschnitt die wichtigsten
in einem Trustcenter beteiligten Komponenten aufgeführt und erklärt. Die Abbildung 2.1
zeigt die Struktur der PKI-Software. Flexitrust gliedert sich in die drei Hauptkomponenten
Registration Authority, Key Authority und Certificate Management Authority (Abbildung
2.2). Flexitrust unterscheidet sich von der klassischen Aufteilung insofern, dass die Aufgaben
der CA in eine Offline-Komponente (Key Authority) und eine Online-Komponente
(Certificate Management Authority) aufgeteilt sind. Die kryptographischen Algorithmen
sind in den Flexiprovider ausgelagert.
2.2.1. Registration Authority
Die Aufgabe einer Registration Authority (RA) ist die gesamte verwaltungstechnische
Erfassung der Benutzer beziehungsweise der untergeordneten Instanzen einer PKI, welche
ein Zertifikat benötigen. Sie kann dezentral organisiert werden. Somit können mehrere
RA innerhalb einer PKI vorhanden sein. Ist dies der Fall, so muss bei der Namensvergabe
darauf geachtet werden, dass die Namen eindeutig vergeben werden und eindeutig bleiben.
Die Hauptaufgabe der RA ist die eindeutige und richtige Zuordnung der Instanz (Sub-CA,
Host, Benutzer), die ein Zertifikat erhalten möchten. Diese Kontrolle kann zur Zeit nur
durch einen Menschen erfolgen, da es für ein TC anfangs nicht möglich ist, einen Mitarbeiter
direkt erkennen und zuordnen zu können. Hat dieser jedoch innerhalb der PKI einmal
eine Identität erhalten, so kann man den Benutzer anhand dieser Identität identifizieren
und weitere Vorgänge automatisieren. Diese Bindung zwischen dem Antragsteller, dessen
3

2. Public-Key Infrastrukturen
Abbildung 2.1.: Struktur von Flexitrust
Antrag und der Bestätigung durch die RA muss durch den ganzen Prozess der Ausstellung
der digitalen Identität nachvollziehbar und geschützt sein.
2.2.2. Certification Authority
Die Certification Authority (CA) ist für die gesamte Verwaltung der Zertifikate innerhalb
einer PKI-Umgebung verantwortlich. Es werden Registrierungsanfragen entgegengenommen,
Schlüssel erzeugt, Zertifikate erstellt und diese signiert. Bei Flexitrust ist die CA
in Offline- und Online-Komponente unterteilt. Die Offline-Komponente nimmt hierbei die
sicherheitskritischen Aufgaben wahr. Die Online-Komponente ist die direkte Schnittstelle
zu den Benutzern.
Offline-Komponente - Key Authority
Die Offline-Komponente, im folgenden Key Authority (KA) genannt, ist für alle Operationen
mit dem Schlüssel innerhalb der PKI verantwortlich [47]. Sie ist das am stärksten zu
schützende Element einer PKI. Hierbei gilt es den gesamten Lebenszyklus eines Schlüssels
zu schützen (Abbildung 2.3). Angefangen mit der sicheren Erzeugung, über die Speicherung
auf einer Chipkarte oder als Soft-Token [40], den geschützten Transport des privaten
Schlüsselteiles zum Benutzer, Verknüpfung des öffentlichen Schlüssels mit den Benutzerdaten
in Form eines Zertifikats, Signatur des Benutzerzertifikats und die Bereitstellung des
öffentlichen Zertifikats für den öffentlichen Verzeichnis. Hinzu kommt, wenn es erforderlich
ist, eine Sicherung und Archivierung des privaten Schlüssel innerhalb der PKI für die
Möglichkeit der Wiederherstellung bei Verlust. Diese letzt genannten Operationen sind
kritische Vorgänge bei denen die Sicherheitsanforderungen meist über das Vier-Augen-
4

2.2. Bestandteile einer Public Key Infrastruktur
Abbildung 2.2.: Komponenten von Flexitrust
Prinzip hinausgehen. Um den Lebenszyklus eines Schlüssels zu komplementieren sei an
dieser Stelle die Benutzung und die Zerstörung nach Ablauf der Gültigkeit oder im Falle
der Revokation erwähnt. Die Revokationsinformationen werden ebenfalls von der KA
erstellt.
Eine KA erstellt und bearbeitet jeden Schlüssel beziehungsweise jedes Zertifikat einer PKI
und daher gilt hier sehr starker Schutz. Deshalb ist die KA eine Offline Komponente, dass
bedeutet sie ist in keinerlei Netzwerk integriert. Diese zusätzliche Sicherheitsmaßnahme
zieht auch eine Komplexitätssteigerung der Anforderung an ein Managementprotokoll nach
sich.
Online-Komponente - Certificate Management Authority
Die direkte Benutzerinteraktion übernimmt die Online-Komponente Certificate Management
Authority (CMA). Sie übernimmt das Management der Zertifikate und verwaltet
die Sperrinformationen von Zertifikaten. Sie sorgt für die Verfügbarkeit von Sperrinformationen.
Diese kann entweder durch die Veröffentlichung der Certificate Revocation List
(CRL) geschehen oder direkt mittels des Online Certificate Status Protocols (OCSP) [36]
5

2. Public-Key Infrastrukturen
Schlüsselerzeugung
Hinterlegung
Wiederherstellung
Speicherung Transport Benutzung Zerstörung
Abbildung 2.3.: Lebenszyklus eines Schlüssels
verfügbar sein. Die gesamte Benutzerinteraktion läuft über die CMA ab. Die Aufgaben
hierbei sind der Versand der Zertifikate, die Auslieferung der Tokens, die Erstellung von
Pin-Briefen und die Annahme sowie Weiterleitung der Sperrung eines Zertifikats.
Ist die Auslieferung eines Zertifikats erfolgt und dieses aktiviert worden, so wird das dazugehörige
öffentliche Zertifikate durch die CMA in einem zentralen Verzeichnisdienst [27]
bereitgestellt. Hierzu wird eine gemeinsame Datenbank mit der RA gepflegt.
Externe Schlüsselerzeugungseinheit
Aus Sicherheitsgründen kann es notwendig sein ein Schlüsselpaar nicht in der KA sondern
in einer externen Einheit zu erzeugen. Gründe hierfür können sehr hohe Sicherheitsanforderung
an den Schlüssel sein oder dass die Anzahl der zu erzeugenden Schlüsselpaare einer
KA überfordert. Hierbei muss sichergestellt sein, dass die generierten Schlüssel, falls der
private Schlüssel transportiert werden müsste, stark geschützt sind. Eine Methode kann
der Einsatz von Chipkarten sein. Auf diesen ist meist eine direkte Schlüsselerzeugung
möglich. Damit ist der private Schlüssel durch das Betriebssystem und den Aufbau der
Chipkarte vor dem Auslesen und damit dem Zugriff geschützt. Ist eine direkte Erzeugung
auf der Chipkarte nicht möglich, so wird der private Schlüssel auf die Karte geschrieben
und kann nicht mehr ausgelesen werden.
2.2.3. Flexiprovider
Der Flexiprovider stellt für Flexitrust alle kryptographischen Algorithmen zur Verfügung.
Innerhalb des Flexiproviders können kryptographische Algorithmen zur Verschlüsselung,
Signaturerzeugung und zur Ermittelung von Prüfsummen schnell und sicher implementiert
werden. Flexitrust nutzt diese Schnittstelle um verschiedene Algorithmen einfacher
verwenden zu können. Somit ist jeder im Flexiprovider implementierte und geprüfte Algorithmus
unmittelbar für die gesamte PKI von Flexitrust verfügbar. Der Flexiprovider
kann auch als eigenständige Bibliothek für kryptographische Funktionen in Anwendungen
6

2.2. Bestandteile einer Public Key Infrastruktur
integriert werden. Er basiert auf der Java Cryptography Architecture (JCA/JCE) [44] und
ist zu dieser kompatibel.
Die Ausgliederung der Algorithmen sorgt für eine einfachere Evaluation des Quelltexts
und damit einer Erhöhung der Sicherheit in der gesamten PKI. Sind neue Algorithmen
zu implementieren so erfolgt dies nur an einer Stelle. Die Implementierung muss einmalig
evaluiert werden. Dadurch ist es möglich die Sicherheit in der PKI trotz neuer Algorithmen
aufrecht zu erhalten.
7

2. Public-Key Infrastrukturen
8

3. Codierungsformate
Die vorhandene Heterogenität der heutigen IT-Systemen im Bereich der Hardware, Betriebssysteme,
Anwendungen und Programmiersprachen sorgt für eine Vielzahl unterschiedliche
verwendeter Datenformate. Die Darstellung von Zeichenketten, Zahlen, Zeitangaben
und anderen Informationen finden sich oft in jeweils eigenen Datentypen wieder.
Ein direkter Austausch zwischen diesen Systemen ist nicht möglich. Die Vernetzung der
IT-Systeme und damit die Möglichkeit der direkten Datenübertragung von einem System
zu einem Anderen bringt die Notwendigkeit für mindestens ein gemeinsames Format mit.
Die zwei Codierungsformate Extensible Markup Language und Abstract Syntax Notation
One sorgen für eine vereinheitliche Darstellung von Daten. Sie sind beide standardisiert
und somit kann für eine Datenübermittlung auf diese zurückgegriffen werden.
3.1. Extensible Markup Language
Durch die klare Struktur von Extensible Markup Language (XML) [12] ist es möglich
Daten unabhängig von der Darstellung zu strukturieren und zu erfassen. Mit Hilfe der
XML-TAGs [20, 34] kann eine Datendarstellung in XML jederzeit eindeutig interpretiert
werden, da die zusammengehörigen Elemente klar erkennbar sind. Die Übertragung selbst
erfolgt in Form von Text-Zeichen. Somit kann jedes System und jede Plattform ohne großen
Aufwand die Daten einlesen und verarbeiten. Anschließend können die Daten auf verschiedensten
Wegen übermittelt werden. Angefangen mit einfachen Dateien auf Speichersticks,
über Email oder auch eine direkte Netzwerkverbindung sind möglich.
XML ermöglicht die direkte Darstellung der Informationen, die signiert oder verschlüsselt
werden sollen. Dazu kann auf die zwei vorhandenen Standards XML Digital Signature [5]
und XML Encryption [4] zurückgegriffen werden.
XML bietet durch seine Klartextdarstellung die Möglichkeit die Daten direkt vor und nach
der Verarbeitung zu betrachten und zu analysieren. Sollte hierbei ein Fehler festgestellt
werden, sei es durch eine maschinelle syntaktische Prüfung oder eine semantische Prüfung
durch eine Person, so kann der Fehler unverzüglich korrigiert werden. Diese Korrektur kann
automatisch und auch manuell erfolgen. Am Ende sollte das gesamte veränderte Dokument
erneut überprüft werden. Mit XML-Schema [21] bietet XML selbst eine Schemasprache
an, welche diesen Vorgang durch die Vorgabe einer klaren Struktur ermöglicht.
XML leistet in der Kryptographie durch seine einfache und klare Struktur einen bedeutenden
Vorteil im Bereich der Langzeitarchivierung und Darstellung von Informationen. Es
ist ein offenes Format und kann somit beliebig erweitert werden. Auch ist bei zukünftigen
Rechnersystemen eine Verarbeitung der Daten ohne großen Aufwand möglich.
9

3. Codierungsformate
3.2. Abstract Syntax Notation One
Die Abstract Syntax Notation One (ASN.1) wurde als gemeinsamer Standard der International
Telecommunication Union – Telecommunication Standardization Sector [2] und
der International Organization for Standardization [8] verabschiedet. Es ist als Protokoll
in der Anwendungsschicht angesiedelt und nutzt in der darunter liegenden Darstellungsschicht
verschiedene Encoding Rules um Daten für den Transport vorzubereiten. Die meist
verwendeten Encoding Rules sind: Basic Encoding Rule (BER), Canonical Encoding Rule
(CER) und Distinguished Encoding Rule (DER) [3]. Daten werden nach einer diesen
Encoding Rules binär codiert und anschließend übermittelt. BER, CER und DER bieten
in der Verarbeitung eine kompaktere Darstellung der Daten und ermöglichen somit eine
schnellere Datenübertragung. Mit der XML Encoding Rule (XER) [1] besteht die Möglichkeit
der Codierung von Daten in XML-Syntax. Es ist nach [7] sogar vorgesehene XML
Schema Definitionen in ASN.1 zu konvertieren.
Aktuell wird ASN.1 als Standardverfahren für die Codierung und Übertragung von Zertifikaten
oder Revokationslisten verwendet. Jedoch liefert ASN.1 eine recht breite Angriffsfläche,
da die Parser und Interpreter in der Verarbeitungssoftware durch die komplexe
Struktur oft fehlerhaft implementiert sind und somit nicht korrekt arbeiten. Eine Fehlersuche
ist nur schwer möglich, da durch eine Betrachtung des Datenstroms kein direkter
Zugang zu den Daten vorhanden ist und somit nicht aufgedeckt werden kann, welche Daten
in die weiterverarbeitende Software gelangen.
Einen tieferen Einblick in ASN.1 liefern die Werke ASN.1 Complete [32] und ASN.1 Communication
[17].
3.3. Bewertung
Da IT-Systeme Daten in einer Binärcodierung verarbeiten ermöglicht ASN.1 durch seine
Darstellung in Binärcode ein direkte Verarbeitung der Daten. Im Gegensatz zu XML,
welches einen Umwandlungsschritt der Text-Zeichen in binären weiterverarbeitbaren Code
benötigt. Verschiedene Systeme benutzen auch unterschiedliche Binärcodierungen und
somit kann es bei ASN.1 vorkommen, dass Daten falsch interpretiert werden. Durch den
überall notwendigen Zwischenschritt bei XML ist es möglich die Daten für jedes System
zur Verfügung zustellen und vor der Verarbeitung selbst in ein möglichst effizientes und
auf die Plattform angepasstes Format zu codieren.
Beide Formate können in Software implementiert werden. Die Programmierung eines
ASN.1 Parsers ist auf Grund der Komplexität von ASN.1 sehr schwer und eine fehlerhafte
Implementierung kann dazu führen, dass Softwaresysteme abstürzen. Die Ursache
hierfür liegt in fehlerhaft interpretierten oder bewusst falsch codierten ASN.1 Nachrichtenpaketen,
die verarbeitet werden sollten. XML hat durch seine klare Darstellung und der
Möglichkeiten sowohl einer syntaktischen als auch einer semantischen Überprüfung vor der
Verarbeitung, Vorteile gegenüber ASN.1. Durch die Anordnung der TAGs und die klare
Vorgabe mittels einer Schema-Definition kann der Parser die Daten eindeutig Interpretieren
und zur Verarbeitung weitergeben. XML unterstützt durch seine Menschenlesbarkeit
eine einfache Fehlersuche, welche in ASN.1 durch die Binärcodierung nicht möglich ist.
10

3.3. Bewertung
Der entscheidender Vorteil von XML in einem Sicherheitsbereich ist die Menschenlesbarkeit
und eine daraus resultierende Möglichkeit der semantischen Überprüfung. Ein Anwender
oder Administrator kann jedes Datenpaket betrachten und einer semantischen Prüfung
unterziehen. Hierbei kann Punkt für Punkt überprüft werden, ob alle notwendigen Daten
korrekt angegeben wurden oder keine zusätzliche störende gar schädlichen Information
enthalten sind. Wird ein Problem erkannt, so kann unmittelbar darauf reagiert werden. Bei
ASN.1 ist diese semantische Überprüfung nicht einfach möglich. Wählt man die Codierung
nach ASN.1 - DER, so werden die Daten in einer langen Reihe von ”Datentyp - Wertlänge
- Wert” (Type Length Value) übermittelt. Dies unübersichtliche Darstellung ist kaum
menschenlesbar.
Durch die Menschenlesbarkeit wird eine Evaluation vereinfacht und XML unterstützt aktiv
Audit-Prozesse. Diese Prozesse finden sich im Bereich der Qualitätssicherung in Form von
Vorgangsbeschreibungen oder Protokollierung wieder.
Die Signatur oder Verschlüsselung von Binärcode ist im Sicherheitsumfeld stark umstritten,
da der Signierer hier nicht sehen kann, was er genau unterschreibt. So besteht die
Möglichkeit bei der Codierung der Daten in Binärcode zusätzliche Informationen einzuschleusen,
welche dann unbemerkt mit signiert oder verschlüsselt werden. Dies ist bei
XML nicht möglich, da hier mit Klartext gearbeitet wird. Die Daten sind vor einer Signatur
oder Verschlüsselung lesbar und der Signierer weiß was er signiert beziehungsweise
verschlüsselt hat. Es soll stets gelten ”What you see is, what you sign” [43]. Ein Ausnahme
bilden verschlüsselte Daten, sowie die Signaturen selbst. Diese können nur als binäre
Daten gespeichert und dem entsprechend übermittelt werden.
XML ist ohne Probleme von jedem IT-System lesbar und auf lange Sicht eine Option
zur Speicherung und Strukturierung von Daten. Im Bereich der Langzeitsicherheit und
Langzeitarchivierung von digitalen oder digitalisierten Daten wird fast ausschließlich mit
XML als Codierungsformat gearbeitet [31].
Ein abschließenden Überblick über die zwei Codierungsformate inklusive eine groben Bewertung
findet sich in Tabelle 3.1.
XML ASN.1
maschinenlesbar + +
menschenlesbar + -
Softwareimplementierung + 0
Langzeitlesbarkeit + 0
Syntaktische überprüfbar + +
Semantisch überprüfbar + -
Legende: + = Vorteil / 0 = neutral / - = Nachteil
Tabelle 3.1.: Gegenüberstellung ASN.1 und XML
11

3. Codierungsformate
12

4. Trustcenter Management Protokolle
In diesem Kapitel werden aktuell verwendete Trustcenter Management Protokollen vorgestellt.
Es werden die vier Protokolle Public Key Cryptography Standard #7 und #10,
XML Key Management Specification und Certificate Management Protocol betrachtet.
XML Key Management Specification verwendet, wie der Name schon erahnen lässt, als
Codierungsformat XML die restlichen Protokolle nutzen ASN.1.
Weiterhin gibt es die folgende Protokolle, auf die hier im einzelnen nicht eingegangen wird:
Certificate Request Message Format [42], Certificate Message Syntax [24] und Certificate
Management Messages over CMS [37].
4.1. Public Key Cryptography Standard #7
Public Key Cryptography Standard (PKCS) #7 [39] ist ein Standard für eine Datenübertragung.
Er stellt vier verschiedene Datentypen bereit in die Informationen eingebettet und
übermittelt werden können: Klartextinformationen, signierte Informationen, verschlüsselte
Informationen und signierte eingepackte Informationen. Es besteht auch die Möglichkeit
diese Datentypen ineinander zu Schachteln. PKCS #7 ist als Container zu verstehen, in
den man beliebige viele Informationen einlagern und diese anschließend dem Empfänger
bei Bedarf signiert und oder verschlüsselt zukommen lassen kann. Es gibt keine spezifischen
Festlegungen oder Strukturierung der Daten.
Ein Anwendungsgebiet ist der Datenverkehr via Email. Hier wird eine Absicherung mit
S/MIME [18] vorgenommen. S/MIME selbst benutzt PKCS #7 als Container für die
Information. Diese werden einfach eingebettet, übermittelt und auf der Gegenseite wieder
ausgepackt.
4.2. Public Key Cryptography Standard #10
PKCS #10 [41] erfasst nur die Anforderung auf die Signatur eines Zertifikats. Diese Anfrage
muss den eindeutigen Namen des Anfragenden, das heißt den öffentlichen Schlüssel,
enthalten. Die gesamten Daten der Anfrage müssen mit dem privaten Schlüssel des Anfragenden
unterzeichnet sein. Die Anfrage enthält einen Identifikator des Signaturalgorithmus
und die Signatur des Anfragenden. Optional sind weitere Attribute möglich, welche dann
ebenfalls in die Signatur einfließen.
Diese Nachricht wird zur Signatur an die Zertifizierungsstelle geschickt. Die Rücksendung
eines Zertifikats in Form eines X.509 Zertifikats [26] ist nicht mehr Bestandteil von PKCS
#10. Hierfür wird auf andere Verfahren, beispielsweise das zuvor erwähnte Protokoll PKCS
#7, zurückgegriffen.
13

4. Trustcenter Management Protokolle
Aktuell wird dieser Standard in vielen PKI-Umgebungen unter anderem auch Flexitrust
verwendet, um die Zertifikatsanfragen entgegen zunehmen.
4.3. XML Key Management Specification
Extended Key Management System Version 2.0 (XKMS) [23] ist ein auf XML-basierendes
Protokoll. XKMS soll als Webservice-Schnittstelle für die Benutzer die komplizierten und
komplexen Vorgänge einer PKI verbergen. Für das Protokoll selbst muss keine PKI gemäß
X.509 oder PGP [13] vorhanden sein. Jedoch ist dieses Protokoll mittels einer API darauf
ausgelegt, solche Infrastrukturen zu unterstützen. XKMS greift für die Verarbeitung auf
die Standards XML Digital Signature und XML Encryption zurück. Es teilt sich in zwei
Bereiche XML Key Information Service Specification (X-KISS) und XML Key Registration
Service Specification (X-KRSS).
X-KISS als direkte Benutzerschnittstelle bearbeitet die Informationsauskünfte über Zertifikate.
Es kann die Lokalisierung der Informationen über ein Zertifikat oder den verwendeten
Schlüssel vornehmen, sowie in einem zweiten Schritt die Informationen überprüfen. Hierbei
kann die Gültigkeit der Zertifikatsinformationen sowie der eigentlichen Signatur abgefragt
werden. Zusammengefasst kann man sagen, dass X-KISS die Operationen rund um das
XML Digital Signature Element für den Benutzer transparent anbietet.
X-KRSS deckt die Aufgaben der Verwaltung von Zertifikaten ab. Unter anderem sind die
Registrierung von Zertifikaten und die Verknüpfung von Zertifikat mit dem dazugehörigen
Schlüssel angebotene Operationen. Ebenso ist die Neuausstellung, die Revokation und
auch eine Wiederherstellung des privaten Schlüsselteiles in der API vorgesehen. Wird
nur eine öffentlicher Schlüssels verarbeitet, so ist auch eine Überprüfung auf den Besitz
des passenden privaten Schlüssels möglich. Das Protokoll kann direkt mit RSA und DSA
Schlüsseln umgehen, darüber hinaus bietet es selbst eine Umgebung, die die Anbindung
von weiteren und eventuell neueren Algorithmen ermöglicht.
Aktuell wird XKMS zum Beispiel in einem Grid Computing Projekt verwendet [38].
4.4. Certificate Management Protocol
Das Certificate Management Protocol (CMP) [11] ist im September 2005 eingereicht
worden. Es arbeitet zusammen mit dem Protokoll Certificate Request Message Format
(CRMF) [42], welches zum gleichen Zeitpunkt eingereicht wurde. Mit dieser Veröffentlichung
haben beide Protokolle ihre Vorgänger abgelöst. Die erste Version von CMP und
CRMF [10, 35] kannte keine optionalen Felder. Sind Informationen nicht angegeben worden
und wurden sie für den weiteren Verlauf nicht nötig, so sind diese an sich Pflichtelemente
nicht ausgefüllt. Die Nachfolge Version führte als eine Änderung optionalen Elemente ein
und somit gab es die Möglichkeit ”legal” Elemente auslassen zu können.
CMP ist entwickelt worden, um die PKI-Struktur sowie den Zertifikateaufbau nach X.509
zu verwalten. Es ermöglicht die Kommunikation zwischen den einzelnen Komponenten
einer PKI, sowie einem Clientsystem und der CA. Durch die Vorgabe der Struktur und
der Inhalte der PKI wurde das gesamte Protokoll genau daraufhin ausgerichtet. Es werden
sämtliche Elemente in den Zertifikaten unterstützt und eine Kommunikation ist zwi-
14

4.4. Certificate Management Protocol
schen der RA, CA, einem Verzeichnisdienst sowie Clientsystem möglich. Der Transport
der Nachrichten ist nicht vorgegeben und kann somit auf verschiedene Arten erfolgen. In
vielen Nachrichten ist ein Handshake-Verfahren eingebaut, welches nur bei einer direkten
Netzwerkverbindung funktioniert.
Im RFC zu CMP sind verschiedene Szenarien aufgeführt die CMP komplett unterstützt.
CMP behandelt viele verschiedene Situationen mit eigenen Nachrichten und Mechanismen.
Diese vielen vorgegebenen Nachrichten sind eine gute Grundlage für eine Implementierung,
sie ist jedoch sehr speziell und nur mit hohem Aufwand komplett zu bewerkstelligen. Viele
der vorgesehenen Mechanismen sind so spezifisch, dass sie außerhalb des vorgesehenen
Rahmens nur durch spezielle Anpassungsschritte verwendet werden können. Es ist zur
starr, als das es auf anderen PKI-Modellen sinnvoll eingesetzt werden könnte.
15

4. Trustcenter Management Protokolle
16

5. Szenarien
In diesem Kapitel werden Szenarien aus dem Bereich einer Public-Key Infrastruktur aufgezeigt.
Zur Vereinfachung ist die PKI in der Struktur Benutzer, RA, CA und Verzeichnisdienst
gegeben. Die in Kapitel 2 vorgestellten Komponenten RA und CMA sind in der
CA zusammengefasst.
Im Ersten Abschnitt werden die Vorgänge aufgeführt, die unmittelbar mit dem Zertifikat
zusammenhängen oder an dieses geknüpft sind. Hierbei handelt es sich um die Beantragung,
Ausstellung, Auslieferung, Aktivierung, Veröffentlichung des öffentlichen Teiles,
Erneuerung und Revokation des Zertifikats. Der Zweite Abschnitt befasst sich mit den
Verwaltungsoperationen, die von Dritten gegenüber der PKI oder dem Zertifikat erfolgen.
Betrachtet wird die Überprüfung des Zertifikats mittels Certificate Revocation List, Delta
Certificate Revocation List oder Online Certificate Status Protokoll und die externe
Schlüsselerzeugung. Ein weiterer verwaltungstechnischer Vorgang ist die Erneuerung des
Vertrauensankers, welcher zu Ende des Abschnitts erläutert wird.
5.1. Kernvorgänge
In diesem Abschnitt werden die unmittelbaren Vorgänge erläutert, welche vom Erlangen
bis zum Zurückziehen eines Zertifikats notwendig sind. Zur besseren Übersicht sind in
Abbildung 5.1 alle Vorgänge und beteiligten Komponenten dargestellt.
RA
1. Beantragen 2. Ausstellen
Benutzer
4. Aktivieren
3. Ausliefern
Verzeichnisdienst
CA = KA & CMA
5. Veröffentlichen
Abbildung 5.1.: Zertifizierungsvorgänge in einer PKI
17

5. Szenarien
5.1.1. Beantragung
Bei einer Beantragung eines neuen Zertifikats werden die persönlichen Daten des Benutzers
durch die RA geprüft und ihre Echtheit bestätigt. Anhand dieser Daten wird ein Zertifikat
für den Benutzer ausgestellt. Es besteht die Möglichkeit, dass der Benutzer nur die
Zertifizierung seines öffentlichen Schlüssels haben möchte. Dieser Schlüssel muss dann bei
Beantragung vorliegen und wird an die CA weitergeleitet. Für eine spätere Überprüfung
auf die Echtheit des Benutzers kann ein Transportpasswort verwendet werden. Es besteht
auch die Möglichkeit, dass ein Benutzer ein Revokationspasswort festlegt, mit dem er später
sein Zertifikat revozieren kann und es selbst vor einer nicht autorisierten Revokation
schützt. Sind keine Passwörter angeben, so werden diese meist von der CA erstellt und
nur dem Benutzer zugänglich gemacht.
5.1.2. Ausstellung
Von den validierten Daten des Benutzers werden alle notwendigen Daten für die Erstellung
des Zertifikats an die CA weitergeleitet. Bringt der Benutzer bereits einen öffentlichen
Schlüssel mit, so ist dieser auf dem Weg zur CA gegen einen Austausch und eine Manipulation
zu schützen.
Der bereits vorhandene oder ein neu zu erzeugender Schlüssel wird in einem Zertifikat mit
der Benutzeridentität verbunden. Dieses Zertifikat wird anschließend von der CA signiert
und ist damit in die Hierarchie der PKI eingeordnet.
5.1.3. Auslieferung
Bei der Auslieferung wird das fertige Zertifikat dem Benutzer übermittelt. Ein Schutz bei
der Auslieferung bietet das Transportpasswort. Es besteht die Möglichkeit, dass dieses
von der PKI vorgegeben wird oder der Benutzer es bei der Beantragung bereits hinterlegt
hat. Das Zertifikat und der private Schlüssel wird anschließend mit dem Transportpasswort
verschlüsselt und dem Benutzer übermittelt. Dieser kann als einziger Geheimnisträger
das Zertifikat gültig entschlüsseln. Falls es sich um die Auslieferung eines reinen öffentlichen
Zertifikats handelt, der private Schlüssel nicht von der PKI selbst erzeugt wurde,
so ist ein Proof-of-Possession-Mechanismus (PoP) nötig. Mittels diesem Verfahren muss
der Benutzer nachweisen, dass er im Besitz des korrespondierendem privaten Schlüssels
ist und somit auch gültiger Empfänger für das Zertifikat. Diese Überprüfung kann auch
bei der Beantragung erfolgen und wäre dann zum Zeitpunkt der Auslieferung nicht mehr
notwendig.
5.1.4. Aktivierung
Im gewöhnlichen PKI Umfeld ist eine Aktivierung eines Zertifikats nicht notwendig. Es
wird davon ausgegangen, dass ein Zertifikat mit der Auslieferung als gültig anzusehen
ist. Jedoch ist für die Einhaltung des deutschen Signaturgesetzes (E.3) eine Aktivierung
zwingend notwendig. Der Benutzer muss das Zertifikat aktivieren und damit nachweisen,
dass er es erhalten hat und verwenden kann. Gegebenenfalls erfolgt in diesem Schritt eine
18

5.1. Kernvorgänge
Überprüfung gemäß der Forderung nach PoP. Hierfür könnte das Aktivierungspasswort
mit dem öffentlichen Schlüssel verschlüsselt sein.
Für die Aktivierung eines Zertifikats muss dieses eindeutig zugeordnet werden können.
Ebenso muss diese Nachricht vom Benutzer bis zur CA unverändert übertragen werden
oder eine Veränderung erkennbar sein. Es sollte jedoch dem Benutzer ermöglicht werden,
eine Aktivierung auch zu verweigern. Gründe hierfür wären eine Änderung der Policy,
welche an das Zertifikat geknüpft ist, nicht ausreichende Sicherheitsstandards (Schlüssellänge
zu kurz oder Verwendung eines falschen kryptographischen Verfahrens) oder im
schlimmsten Fall eine nicht aufgeforderte beziehungsweise nicht reguläre Erneuerung des
Zertifikats.
5.1.5. Veröffentlichung
Um Dritten die Möglichkeit der Überprüfung einer Signatur oder die Übermittlung von
verschlüsselten Daten zu geben, sind die öffentlichen Zertifikate in einem Verzeichnisdienst
gespeichert. Dritte können das Zertifikat abrufen und die darin enthaltenen Informationen
überprüfen und nutzen. Eine Veröffentlichung des Zertifikats kann auch unterbunden
beziehungsweise unterdrückt werden. Diese Verzeichnisdienst ist meist als Lightweight Directory
Access Protocol organisiert [27].
5.1.6. Erneuerung
Wird ein Zertifikat verlängert, so muss ein Neues mit dem bereits gegebenem öffentlichen
Schlüssel erstellt werden. Die Erneuerung erfolgt in den Schritten: Beantragung, Ausstellung,
Auslieferung und Veröffentlichung. Eine erneute Überprüfung auf den Besitz des
privaten Schlüssel ist nicht notwendig, da der Benutzer diesen bereits verwendet hatte und
demnach besitzt. Für den Fall, dass ein neuer Schlüssel notwendig und verwendet ist, kann
erneut eine Prüfung mittels PoP erfolgen. Ebenso kann bei der Beantragung auf bereits
im abgelaufenen oder ablaufenden Zertifikate enthaltenen Daten zurückgegriffen werden.
Damit ist der gesamte Vorgang voll automatisierbar. Etwaige automatisch erstellte Passwörter
können dem Benutzer unter der zu Zuhilfenahme seines aktuellen Zertifikates sicher
übermittelt werden.
5.1.7. Revokation
Falls ein Zertifikat ungültig wird, muss der Benutzer diese Information der CA mitteilen
(Abbildung 5.2). Der Zeitpunkt der Sperrung ist der Zeitpunkt der Bekanntgabe gegenüber
dem TC. Der Benutzer hat ein Revokationspasswort erhalten, mit dem er der RA
nachweisen kann, dass er Eigentümer des zu revozierenden Zertifikats ist. Alle Informationen
werden dann von der RA an die CA weitergeleitet. Die CA fügt die Sperrinformation,
sofern die Komponenten vorhanden sind, in die CRL ein und leitet sie an den OCSP-
Provider weiter. Hier sind diese Komponenten in Form des Verzeichnisdienstes modelliert.
Wird dann eine Statusanfrage bezüglich des revozierten Zertifikats gestellt, so fällt sie
negativ aus. Eine weitergehende Betrachtung der Revokationsanfrage erfolgt in Abschnitt
5.2.1.
19

5. Szenarien
RA
1. Meldung 2. Revokation
Benutzer
5.2. Weitere Vorgänge
Verzeichnisdienst
CA = KA & CMA
3. Veröffentlichen
Abbildung 5.2.: Revokation eines Zertifikats
In einer PKI gibt es neben den Kernvorgängen noch weitere Operationen. Hierbei sei die
Überprüfung auf die Gültigkeit eines Zertifikats, die externe Schlüsselerzeugung und die
Erneuerung des Zertifikats der Wurzelinstanz genannt.
5.2.1. Gültigkeitsprüfung
In einer PKI ist es wichtig überprüfen zu können, ob ein Zertifikat nicht aus anderen
Gründen als dem Ablauf des Gültigkeitszeitraums ungültig geworden ist. Hierfür werden
verschiedene Konzepte verwendet, um diese Informationen auf der einen Seite zu erfassen
und zu verwalten, auf der anderen Seite sie auch für Dritte verfügbar und erreichbar
zu haben. Diese Forderungen finden sich auch in der Signaturverordnung §7 Absatz 2
(E.4) wieder. Die zwei großen Vertreter dieser Konzepte sind Certificate Revocation Lists
(CRL) (ein als seit langem schon etabliertes und auch offline verfügbares Verfahren) und
Online Certificate Status Protocol (OCSP). OCSP ist, wie der Name schon sagt, ein Online
Protokoll. Es benötigt einen funktionierenden Internetzugang und eine Verbindung zum
OCSP-Server. Auf diese zwei Verfahren wird im folgenden noch genauer eingegangen.
Weiterhin gibt es noch Konzepte und Verfahren wie Novomodo [6]. Bei diesem Verfahren
wird die Revokationsinformation schon bei der Erstellung in das Zertifikat eingebracht
und mit signiert. Hierbei handelt es sich um den Hashwert eines Geheimnisses. Wird das
Geheimnis bekannt, so ist das Zertifikat revoziert.
Die Verfahren haben gemeinsam, dass sie zur Revozierung eines Zertifikats eine eindeutige
Zuordnung der Zertifikats benötigen. Für Systeme nachdem X.509 Standard wird diese
aus dem Aussteller und der Seriennummer gebildet.
(Delta) Certificate Revocation List
Eine Certificate Revokation List (CRL) oder auch eine Delta Certificate Revocation List
(dCRL) [25] wird von einer CA erstellt, um alle revozierten Zertifikate zu verwalten. Eine
CRL wird zu bestimmten Zeitpunkten erstellt und enthält alle Zertifikate die bis zu diesem
20

5.2. Weitere Vorgänge
Zeitpunkt revoziert worden sind. Da eine CRL ein Liste ist die stets wächst, wurde zur
Reduzierung des Datentransfers das Konzept der dCRL eingeführt. Hierbei werden immer
in Bezug auf eine komplette Liste (BaseCRL) die neu revozierten und noch nicht in einer
BaseCRL erfassten Zertifikate gesammelt und bereitgestellt. Die Delta CRL zusammen
mit der referenzierten BaseCRL ergeben die Liste aller zurückgezogenen Zertifikat zum
Zeitpunkt der Erstellung der dCRL.
Ein Client ruft diese Liste ab und kann danach ohne eine Internetverbindung Zertifikate
auf ihre Gültigkeit hin überprüfen. Für ein Auffrischung der Informationen muss ein
Client entweder eine zu seiner bereits vorhandenen CRL passende dCRL laden oder eine
komplette neue CRL. Die Aktualität der Information ist immer in der Geschwindigkeit, in
der eine CA eine CRL beziehungsweise dCRL bereitgestellt und der Client diese vorliegen
hat.
Online Certificate Status Protocol
Das Online Certificate Status Protocol (OCSP) [36] ermöglicht eine direkte Überprüfung
einzelner Zertifikate. Somit kann unmittelbar festgestellt werden, ob ein Zertifikat zum
Zeitpunkt der Überprüfung noch gültig ist. In Abbildung 5.3 ist ein Prüfungsschema innerhalb
des OCSP-Anbieters dargestellt. Es sind folgende drei Antworten möglich: unknown
(der Aussteller ist unbekannt), revoked (das Zertifikate wurde zurückgezogen), good (das
Zertifikat ist nicht revoziert). Die dritte Antwortmöglichkeit muss im Rahmen des deutschen
Signaturgesetzes (E.5) gegeben werden. Hierbei wird geprüft, ob das Zertifikat bekannt
ist und dieses dann anschließend explizit als gültig erklärt.
OCSP bietet gegenüber CRL zwei entscheidende Vorteile. Das erste ist die Echtzeit-
Information über den Status eines Zertifikats. Den zweiten Vorteil bildet die Größe der Anfrage
beziehungsweise der Datenpakete die übermittelt werden. Das Nutzen eines OCSP-
Server kann das übermittelte Datenvolumen auf das notwendigste reduzieren. Weiterhin
können sich mehrere CA durchaus einen OCSP-Server teilen. Dieser liefert dann die Status-
Informationen über die Zertifikate der angeschlossenen CA in Echtzeit aus.
5.2.2. Externe Schlüsselerzeugung
Auf Grund von Sicherheitsanforderungen kann es durchaus möglich sein, dass Schlüssel
auf einer sicheren externen Einheit erzeugt werden müssen (Abbildung 5.4). Die CA stellt
hierzu eine Anfrage an die externe Einheit. Die externe Einheit erzeugt den Schlüssel und
dieser muss dann auf sicherem Wege wieder zur CA übermittelt werden. Hierbei ist der
Schutz des privaten Schlüssel als sehr hoch einzustufen. Es besteht auch die Möglichkeit der
Erzeugung des Schlüsselpaares auf eine Chipkarte (Abbildung 5.5) und somit ist der private
Schlüssel vor externem Zugriff geschützt. Die CA muss im Anschluss die Benutzerdaten
mit dem öffentlichen Schlüssel kombinieren, das Zertifikate erstellen und signieren. Dieses
Zertifikat kann auf gewöhnlichem Wege ohne zusätzlichen Schutz an den Benutzer und
den Verzeichnisdienste übermittelt werden. Der private Schlüssel wird auf der Chipkarte
geschützt.
21

5. Szenarien
verify issuer
check CRL
check Certificate
good
Aussteller bekannt
nicht revoziert
Zertifikat bekannt
Aussteller unbekannt
enthalten in CRL
Zertifikat unbekannt
unknown
revoked
unknown
Abbildung 5.3.: Ablauf einer OCSP Anfrage nach SigG
5.2.3. Vertrauensanker erneuern
Eine Erneuerung des Zertifikats beziehungsweise des Schlüssels der Wurzelinstanz einer
PKI ist die kritischste Operation in einer PKI. An dieser Stelle muss ein Zertifikat verwendet
werden, das selbst signiert ist. Es gibt keine übergeordnete Instanz die die Authentizität
dieser Wurzel bestätigen kann. Auch ist es der am besten zu schützende Vorgang in einer
PKI, da dieses Zertifikat allen anderen Zertifikaten übergeordnet ist und man mit dem
Besitz des dazugehörigen privaten Schlüssels die gesamte PKI kontrollieren kann [14].
Die Vorgänge die hierbei ablaufen sind meist individuell und müssen für jede eingesetzte
PKI-Software einzeln angepasst werden. Sie sind ähnliche den Vorgängen bei dem erstmaligen
Aufsetzen der PKI (Bootstrap). Daher gibt es im Bereich der Kommunikationsprotokolle
keine großen Anforderungen.
Dieser Prozess kann auch völlig automatisiert ablaufen. In dem die CA mitteilt, dass ihr
Zertifikat abläuft und die entsprechenden Prozesse eigenständig auslöst. Zum Schluss kann
es sein, dass den restlichen Komponenten innerhalb der PKI die Erneuerung des Zertifikats
im Vertrauensanker mitgeteilt werden muss Eine semiautomatische Reaktion kann auch
erfolgen. Hierbei müssen dann die Systembetreuer auf die Nachricht der CA reagieren und
die Prozesse manuell ausführen.
Bei einer CA, die nicht am Netzwerk angeschlossen ist, müssen alle Zertifikate per Datenträger
zu dieser gebracht werden und anschließend wieder in signierter Form zurück
übermittelt werden. Dieses Vorgehen bietet eine maximal Sicherheit für die CA.
22

Benutzer
RA
1. Schlüsselanforderung
Verzeichnisdienst
CA = KA & CMA
Abbildung 5.4.: Externe Schlüsselerzeugung
Benutzer
RA
5.2. Weitere Vorgänge
Schlüsselerzeuger
CA = KA & CMA
2. öffentlichen Schlüssel übermitteln
Verzeichnisdienst
2. Schlüsselübertragung
1. Anforderung zur Schlüsselgenerierung
Chipkarte
Abbildung 5.5.: Schlüsselerzeugung auf einer Chipkarte
5.2.4. Informations- und Fehlerübermittlung
Bei der Verarbeitung von Informationen können Fehler auftreten. Diese müssen gemeldet
werden und Maßnahmen getroffen werden um sie zu beheben. Eine falsche Fehlermeldung
kann zu nicht erwünschten Reaktionen führen. Daher müssen Fehlermeldungen korrekt
erstellt und übermittelt werden. Sie sind genauso zu schützen wie normale Nachrichten
innerhalb des TC. Ein Fehlermeldung sollte von jeder Komponente an jede Komponente
gesendet werden können. Konkrete Mechanismen zur eigentlichen Fehlerbehebung obliegen
der Anwendung.
Gleiches gilt für den allgemeinen Informationsaustausch, auch dieser muss geschützt werden.
Nehme man als Beispiel ein autonomes voll automatisiertes Trustcenters an, hier darf
kein Fehlverhalten auf Grund von falschen Informationen ausgelöst werden.
23

5. Szenarien
24

6. Intra Trustcenter Protocol
Das Intra Trustcenter Protocol (ITP) wurde entworfen, um primär die Kommunikation innerhalb
eines Trustcenters zu ermöglichen. Ein großer Teil an Managementaufgaben wird
mit Version 1.2 abgedeckt werden und bis zur fertigen Version 2.0 sollen alle Managementaufgaben
erfasst sein. Eine direkte Interaktion mit dem Benutzer ist bisher nicht vorgesehen;
das Protokoll ist jedoch generisch genug entwickelt, um dies zu ermöglichen. Aktuell
wird die Aufgabe der direkten Benutzerinteraktion durch anderen Protokolle abgedeckt.
6.1. Designziele
Die Grundidee hinter ITP ergeben sind die folgenden sieben Kernanforderungen: Allgemeingültigkeit,
Erweiterbarkeit, Unabhängigkeit, Automatisierbarkeit, Skalierbarkeit,
Nachvollziehbarkeit und Sicherheit. im Folgenden werden diese Punkte einzeln aufgeführt.
Allgemeingültigkeit
Innerhalb eines Trustcenters sollen alle auftretenden Daten verarbeitet werden können. Es
sollte keine Einschränkungen auf bestimmte Datentypen oder Art beziehungsweise Anzahl
der Komponenten geben. Die Daten selbst sollten, soweit als möglich, in strukturierter und
lesbarer Form vorliegen. Sie sollten nicht in generischen Datencontainer liegen, da diese
keinerlei Einblick und Rückschluss auf den Inhalt liefern. Die binärcodierte Daten sollten
nur im Fall der Signatur oder der Verschlüsselung vorhanden sein, an diesen Stellen sind
sie unvermeidlich. Die Strukturierung der Daten bietet auch die Möglichkeit einer gezielten
Absicherung von Teilen des Paketes beziehungsweise die Möglichkeit, nur die notwendigen
Teile zu verschlüsseln.
Erweiterbarkeit
Um die in Zukunft wachsenden und sich ändernden Anforderungen weiterhin zu unterstützen
muss das Protokoll, sowohl im Bereich der Daten und Datentypen erweiterbar sein.
Auch ein Veränderung der Komponenten innerhalb der gesamten Infrastruktur gilt es abzudecken.
Es muss die Möglichkeit gegeben sein, heute noch nicht benötigte Nachrichten
zu modellieren und erst in Zukunft verfügbar beziehungsweise notwendig Infrastrukturkomponenten
zu integrieren (Hardware Kryptomodule [33]).
Unabhängigkeit
Für ein Managementprotokoll sollte auf keinen Fall eine Abhängigkeit von einer starren
Struktur von genau einem Trustcenter oder auch Trustcentertyp existieren. Auch die Arbeitsabläufe
innerhalb einer PKI sind verschieden und sollten daher nicht starr in einem
25

6. Intra Trustcenter Protocol
Protokoll abgebildet werden. Ebenso ist eine Unabhängigkeit auch bei der Wahl der Transportmedien
und -arten gegeben: online, offline, USB-Stick, Diskette, EMail.
Automatisierbarkeit
Die Vorgängen innerhalb eines Trustcenters können verschiedene Prozesse automatisiert
werden. Von Seiten des Protokolls muss dafür eine Unterstützung vorhanden sein. Vor allem
fällt hier runter das Erstellen und Überprüfen von Signaturen und damit die Wahrung
der Authentizität der Daten und Anfragen. Eine vollkommen automatische Ausstellung
und Verteilung von Zertifikaten ist ebenso ein denkbarer und möglicher Vorgang. Für die
Automation eines Prozesses ist eine genaue Angabe und Überprüfung der Informationen
notwendig. Auch muss die Möglichkeit gegeben werden auftretende Fehler kenntlich zu
machen und diese an eine entsprechende Stelle übermitteln zu können.
Skalierbarkeit
ITP soll sowohl die Kommunikation in einem streng hierarchischen Trustcenter ermöglichen
als auch in einem modularen Umfeld. Da eine hierarchische Topologie eine spezielle
Topologie eines allgemeinen modularen Modells ist gilt es, dieses zu erfüllen um damit
beide Möglichkeiten zu erfassen.
Eine modulare Topologie erlaubt es, dass Komponenten mehrfach vorhanden sind, sowie
eine nicht im Vorfeld festgelegte Verteilung der Komponenten zu haben. Ebenfalls ist die
Kommunikation zwischen allen Komponenten möglich. Hierbei handelt es sich um eine
Peer-2-Peer Topologie.
Durch diese Flexibilität ist es möglich ohne großen Aufwand die PKI auf eine spezielle Anforderung
anzupassen. Ein möglicher Aufbau einer PKI ist in Abbildung 6.1 dargestellt.
Mit einer flexiblen Struktur ist es Möglich einen Rollout von tausenden Karten zu realisieren
und für den laufenden Betrieb die Kosten zu senken. Diese Szenario ist nicht abwegig,
da im Zuge der Gesundheitskarte, des elektronischen Reisepasses oder dem digitalen Personalausweis
sich die Frage stellt, wie man mehrere Millionen Identitäten bestätigt, erfasst
und ihnen eine Chipkarte sowohl erstellt als auch zuordnet. Auf der anderen Seite sollte es
auch möglich sein, ein Trustcenter nach einer solchen massiven Last beim Rollout, zu verkleinern.
Dies bedeutet, dass man Komponenten abschaltet und gegebenenfalls herauslöst.
Diese Reduktion sollte auch vom Protokoll unterstützt sein.
Nachvollziehbarkeit
Die Protokollierung geschieht innerhalb der einzelnen Komponenten. Es muss seitens des
Protokolls ermöglicht werden und in den Nachrichten alle dazu notwendigen Daten zur
Verfügung zu stellen. Diese Daten sollten, soweit möglich, für den Menschen lesbar sein. In
einem Sicherheitsbereich gibt es Prozesse und Vorgänge die eine Protokollierung erfordern.
Dieses geht nur, wenn die Vorgänge innerhalb einer PKI für den Benutzer protokollierbar
und nachvollziehbar ablaufen.
Eine Forderung zur Nachvollziehbarkeit der Vorgänge findet sich auch im deutschen Signaturgesetz
Paragraph 10 Absatz 1 (E.2) wieder.
26

Sicherheit
Benutzer 1
Benutzer 2
Status Anfrage
RA 1 RA 2 RA . . .
CMA KA
Schlüsselerzeuger ID 1
Schlüsselerzeuger ID 2
Verzeichnisdienst Revokationsdienst
Abbildung 6.1.: Übersicht über verschiedene Module in der PKI
6.1. Designziele
Es ist nicht ausreichend, das Daten nur auf den Speicherplätzen geschützt werden. Die
Kommunikationswege sind gleich stark zu schützen, so dass hier keine Verletzung der
Sicherheitspolicy auftreten kann. Dies bedeutet, dass das Protokoll Signaturen und Verschlüsselung
unterstützen muss, um auf den Kommunikationsweg ebenfalls die Integrität
der PKI zu wahren. Problematisch hierbei ist eine gleichzeitigen Verschlüsselung und Signatur
von Daten [16]. Auch sollen die Bereiche die in eine Signatur einfließen so erkenntlich
sein, als das der Signierer genau sieht, was er unterzeichnen wird oder unterzeichnet
hat (”What you see, is what you sign”). Hierbei ist die Klartextdarstellung von XML-Daten
eine gute Ausgangsbasis.
Für eine sichere Identifikation der Teilnehmer sollte auch eine Unterstützung von Authentifikationsmechanismen
vorhanden sein. Auch die Delegation von Aufgaben sollte unterstützt
werden, da es im Vorfeld nicht unbedingt feststeht welche Komponente welche
Teilaufgabe wahrnimmt.
6.1.1. Intra Trustcenter Protocol Version 1.0
ITP in der Version 1.0 [28] war ein reiner Entwurf eines neuen Managementprotokolls,
welches die im Vorfeld gestellten Anforderungen erfüllen soll. Die Nachrichten wurden nur
durch XML-TAGs und Beispiele in XML spezifiziert. Die Syntax einer Nachricht gibt der
Quelltext in Anhang A.2 wieder.
Innerhalb der , die die gesamte Nachricht umhüllt, gibt es die Felder
für den Sender der Nachricht, markiert den Empfänger,
beinhaltet die Aufgabe und bietet eine Sicherung der gesamten Nachricht
durch eine Signatur. Die enthält zwei Attribute version, für die Versionsnummer
des Nachrichtenprotokolles, und mit id einen eindeutigen Identifikator der Nachricht.
Eine Nachricht kann mehrere Blöcke des Typs und besitzen.
Der Bereich teilt sich in zwei Blöcke auf. Den ersten Block bildet das Profil
mit , den zweiten eine oder mehrere über den Bereich gebildete
27

6. Intra Trustcenter Protocol
Signaturen. Die enthält eine Attribut namens id, dass eine eindeutige
Identifikation ermöglicht.
Die Eindeutigkeit soll auch in den Profilen gewahrt bleiben, so dass ein Profil auch eine
eigene id als Attribut hat. Unter den neun vorgesehen Elementen in einem Profil sind
zur Identifikation der Subjekte die TAGs , und vorgesehen.
Das Element ist für die Übermittlung eines Passwortes
vorhanden, hierbei ist kein weiterer Schutz des Passwortes gegeben. Mit dem TAG
ist es möglich ein Markierung zu setzen, die die Veröffentlichung eines
Zertifikats unterbinden soll. Für den Transport von drei Zertifikaten, welche selbst als binär
Codierung vorliegen, sind die Elemente , und
vorgesehen.
Einen Gesamtüberblick über alle definierten TAGs der Version 1.0 liefert die Tabelle C.1
im Anhang.
6.1.2. Intra Trustcenter Protocol Version 1.1
In [29] wurde ITP in der Version 1.1 veröffentlicht. Beispiel für eine solche Nachricht
findet sich in Anhang A.3. Im Folgenden werden nur die Änderungen gegenüber Version
1.0 vorgestellt.
Das TAG wurde zur Verdeutlichung des Inhaltes der Nachricht zu
umbenannt und das Attributversion hat nun den Wert ”1.1”. Dieid der Profile wurde
als eindeutiger Identifikator aufgegeben und als Identifikator für die Aufgaben benutzt.
Konkret wurde für die Aufgabe der Aktivierung eines Zertifikates die id="Activation"
benannt. Ein Übertragung von mehreren Zertifikaten trägt id="Multicert" als Attribut
im Element . Das Element wird um das Attribut
type="binary" erweitert, um hier verschlüsselte Passwörter abzulegen.
Die Elemente , und wurden
zu einem Element zusammengefasst. Damit auch weiterhin der
Versand von mehreren Zertifikaten in einer Nachricht möglich ist wurden jedem Element im
Bereich das Element zugeordnet. Die einzelnen Werte werden durch
das Attribut id innerhalb des Elementes differenziert. Ein Zertifikat kann somit
jedes TAG in diesem Abschnitt besitzen. Ein Zuordnung für die entsprechenden Zertifikate
erfolgt hierbei über den Identifikator oder über das KeyUsage-Feld innerhalb eines Zertifikats.
Jedes Zertifikat liegt als base64binary innerhalb eines Bereiches.
Die zwei Signaturbereiche bleiben unverändert. Auch ist keine Verschlüsselung innerhalb
der Nachrichten hinzugekommen.
Diese Version von ITP ist bereits prototypisch für Flexitrust implementiert worden und
kann dort eingesetzt werden.
Eine komplette TAG-Referenz gibt es im Anhang die Tabelle C.2.
28

6.2. Intra Trustcenter Protocol Version 1.2
6.2. Intra Trustcenter Protocol Version 1.2
In allen bisherigen Versionen von ITP bestand das Protokoll nur aus definierten TAGs und
XML-Dateien. Mit der Version 1.2 wird erstmalig eine Schemadefinition (B.1) eingeführt.
Anhand derer kann man die einzelnen ITP-Nachrichten auf ihre Korrektheit prüfen und
korrekt erstellen.
Probleme hierbei sind die Menge der klar zu definierenden TAGs. Ebenso eine Festlegung
der Attribute und eine Reihenfolge der TAGs in den Nachrichten. Zu Beginn dieses Kapitels
werden einige grundlegende Designentscheidungen für die neue Version von ITP angeführt.
Insgesamt bleibt jedoch die Grundstruktur erhalten, so dass weiterhin die Intelligenz in den
Anwendungen ist und die Nachrichten nur zum Transport von Informationen dienen. Auch
ist durch die generischen Nachrichten eine hohe Wiederverwendbarkeit des Protokolls für
andere Bereiche gegeben.
Zur Übersichtlichkeit des Abschnittes finden sich alle Quelltexte in Anhang A.
6.2.1. XML-Schema Definition
Beschreibung der ITP XML-Syntax erfolgt in einem XML-Schema. Eine Schemaerstellung
mit Document Type Definition (DTD) fällt durch die Verwendung von Namespaces weg.
DTD unterstützt keine Namespaces. XML-Schema hat durch seine eigene Darstellung in
XML den Vorteil, dass keine weitere Beschreibungssprache außer XML verwendet werden
muss. Auch eine Nutzung von XML-Werkzeugen zur automatischen Überprüfung und Verarbeitung
wird damit ermöglicht. Eine Zukunftssicherheit ergibt sich aus der Flexibilität
von XML-Schema und der Unterstützung für eigene selbst spezifizierte Datentypen.
Durch die Möglichkeit der automatischen Syntaxüberprüfung ist ein Fortschritt bezüglich
der Sicherheit in ITP erreicht worden. Das komplette Schema findet sich in Anhang B.1.
In diesem Abschnitt werden jeweils die entsprechenden Teile des Schema durch Tabellen
übersichtlicher dargestellt und die enthaltenen Elemente aufgezeigt.
Namensräume
Das Markup-Vokabular in XML-Dokumenten ist nicht eindeutig. Dadurch kann ein TAG
auch mehrfach in verschiedenen Kontexten verwendet werden. Dadurch ist die Eindeutigkeit
nicht mehr gegeben und es besteht die Möglichkeit einer Kollision. Um die Eindeutigkeit
der TAGs zu wahren, werden Namensräume (Namespaces) benutzt. Somit wird es
für die Verarbeitung immer möglich die zugeordneten TAGs und Attribute eindeutig zu
erfassen und auszuwerten.
Der für ITP gewählte Präfix des Namensraum ist itp. Innerhalb der Schemadefinition
wird noch ds für XML Digital Signature und xenc für XML Encryption verwendet. Das
Präfix xsd steht für XML Schema Definition. In dieser sind die Grundlegenden Datentypen
spezifiziert.
Mehr Informationen zu XML-Namespaces sind unter [9] zu bekommen.
29

6. Intra Trustcenter Protocol
Feste Reihenfolge
Eine festgelegte Reihenfolge der einzelnen TAGs sorgt für eine strukturierte Leseweise
der Nachricht. Da eine Forderung die Menschenlesbarkeit ist ergibt sich durch eine klare
Reihenfolge, gerade bei vielen optionalen Feldern, ein leichteres Auffinden der Felder und
damit eine vereinfachte Überprüfung. Im Zuge dieser Festlegung wurden auch die Profile
und die Elemente aufgegeben. Es ist nicht mehr nötig ein Profil zu
haben. Die dort getroffene Unterscheidung wird jetzt direkt mit der entsprechenden
vorgenommen. Die Notwendigkeit des Elementes ist auch nicht mehr
nötig, da innerhalb der einzelnen Elemente per Index eine Möglichkeit geschaffen wurde,
mehrere Elemente dieser Art auf einmal, ohne einen Verlust der Eindeutigkeit, zu erfassen.
6.2.2. Informationssicherheit
ITP Nachrichten können auch vertrauliche Informationen enthalten. Dabei kann es sich um
Passwörter oder private Schlüsselinformationen handeln. Um diese zu schützen wird auf
XML Digital Signature und XML Encryption zurückgegriffen. Hierbei können beliebige
kryptographische Algorithmen verwendet werden, da diese per Referenz in beide Verfahren
integriert werden.
Signaturen
Jede Nachricht die verschickt wird, ist digital signiert. Für die Übermittlung dieser Signatur
wird XML Digital Signature verwendet. Dieser Standard erfüllt alle notwendigen
Bedingungen um eine berechnete Signatur in eine Nachricht zu integrieren. Jede Nachricht
wird nur noch im Ganzen signiert, von der Signatur nur eines Teilbereichs wurde
Abstand genommen, da dies zusätzlichen Aufwand bedeutet. Die frühere reine Signatur
einer ist nicht sinnvoll, da wichtige Informationen aus dem Kopfteil fehlen.
Passwörter
Alle in ITP versendeten Passwörter sind vom Typ . Hierbei handelt
es sich um eine gekapselte Form von XML Digital Signature. Damit Passwörter innerhalb
der Nachricht eindeutig ihrem Aufgabenbereich zugeordnet werden können, ist ein Attribut
use=" " hinzugekommen. Mit diesem Attribut wird das gehashte Passwort folgenden
Aufgaben zugeordnet: activation, revocation, recovery und transport.
Vertrauliche Informationen
Sind private Schlüssel oder der private Teil eines Zertifikats zu übermitteln, so wird das
entsprechende Element mit Hilfe von XML Encryption verschlüsselt. ITP selbst bietet
keine Verschlüsselung an, sondern greift auf diesen bewährten und seit langem etablierten
Standard zurück.
30

6.2.3. Nachrichten
6.2. Intra Trustcenter Protocol Version 1.2
Eine ITP Nachricht ist in drei Bereiche aufgeteilt. Den Anfang und das
Ende jeder Nachricht bilden globale Teile. Zwischen diesen globalen und für alle Nachrichtenarten
gleichen Kopf- und Fussbereichen steht die Application. Mit der ITP Version 1.2
werden die in Tabelle 6.3 aufgelisteten Nachrichtenarten unterstützt. Im Folgenden wird
auf die einzelnen Bereiche eingegangen.
Globaler Kopfteil
Im Kopfteil einer jeden Nachricht wird mit einem Attribut Id ein eindeutiger Identifikator
zugeordnet. Dieser Identifikator muss jede Nachricht besitzen. Sie behält ihre Id solange
die Nachricht existiert. Damit ist eine Grundlage für eine sichere und gute Protokollierung
und somit Nachverfolgbarkeit der Nachricht im TC gewährleistet. Ein weiteres Attribut
mit der Bezeichnung Version dient der besseren Handhabung der einzelnen Nachrichten.
Der Wert dieses Attributs wurde im Schema auf den Standardwert "1.2" gesetzt.
Weiterhin gibt es drei Elemente die in jeder Nachricht enthalten sein müssen: ,
, . Die Information wer eine Nachricht abgeschickt hat und
an wen sie gehen soll sind ohne weiter Erklärung notwendig da es sich um einen Nachrichtenaustausch
handelt. Bei ITP 1.2 ist es möglich mehrere Empfänger einer Nachricht zu
haben. Somit ist senderseitig eine Reduzierung des Datenvolumens möglich, da die selbe
Information gleichzeitig an verschiedene Empfänger gehen kann. Die ist
wichtig um notfalls einen zeitlichen Verlauf von zueinandergehörenden Nachrichten darstellen
zu können. Ebenso kann sie für die genau Protokollierung der einzelnen Vorgänge
herangezogen werden. Es ist jedoch zu beachten, dass ein zentrale Zeit für alle beteiligten
System zur Verfügung steht.
In manchen Bereichen kann es vorkommen, dass der Verfasser einer Nachricht nicht der
Versender selbst ist, sondern es sich hierbei um eine andere Partei handeln kann. Damit
dieses deutlich in der Nachricht mit übermittelt werden kann, gibt es das optionale Element
.
Die drei Elemente , und sind in ihrer Struktur nicht
vorgeschrieben und somit ist eine freie Namensnennung (Domainname, Emailadresse oder
Distinguished Names (DN)) möglich. Eine detaillierte Übersicht über alle Elemente wird
in der Tabelle 6.1 gegeben.
Feld Typ Datentyp req Beschreibung
ID Attribute xsd:ID required Eindeutiger Identifikator
Version Attribute xsd:string optional Version des Protokolls
Sender Element xsd:string required Absender der Nachricht
Recipient Element xsd:string required Empfänger der Nachricht
CreationTime Element xsd:dateTime required Zeitpunkt der Erstellung
Creator Element xsd:string optional ”Verfasser” der Nachricht
Tabelle 6.1.: Felder des Kopfteils
31

6. Intra Trustcenter Protocol
Globaler Fussteil
Im Fussteil sind die Signaturen einer Nachricht enthalten. Diese sind vom Datentyp Signature,
welcher aus XML Digital Signature stammt. Die Signaturen einer Nachricht können
den Verlauf dieser Nachricht durch das System widerspiegeln, in dem immer die nächste
angehängt wird. Somit ergibt sich eine Historie der Signaturen.
Zwingend notwendig ist die erste Signatur, welche vom Absender der ursprünglichen Nachricht
stammt. Ist ein Creator angeben, so sollte auch dessen Signatur teil der Nachricht
werden. Der Überblick wird in Tabelle 6.2 gegeben.
Feld Typ Datentyp req Beschreibung
Signature Element ds:Signature required Signatur des Senders
Signature Element ds:Signature optional weitere Signaturen der Nachricht
Die Application
Tabelle 6.2.: Felder des Fussteiles
Den Hauptteil eine ITP Nachricht bildet die Application. Eine Application enthält die einzelnen
Aufgabe, die in dieser Nachricht übermittelt wird. Jede Application enthält genau
eine Aufgabe die übermittelt werden muss. Es ist auch möglich mehrere Application-Blöcke
in einer ITP Nachricht zu haben. Eine Unterstützung für die Delegation der Aufgaben gibt
es in der Weise, als das solche Blöcke direkt von einer Nachricht in eine neue Nachricht
kopiert oder bewegt werden können.
Die Kapselung der einzelnen Aufgaben in einzelne Blöcke ist sinnvoll, da somit bei einem
Datenaustausch zwischen den Komponenten mehrere verschiedene Aufgaben in einer
einzigen Nachricht übermittelt werden können. Ein Szenario hier für ergibt sich bei einer
Offline CA (Szenario 5.2.3). Hierbei kann für jede Anfrage eine eigene Application erstellt
werden und alle in einer großen Message auf einmal übermittelt werden.
Tabelle 6.3 bietet einen Überblick der in Version 1.2 vorgesehenen Nachrichten.
Die in ITP Version 1.0 und 1.1 vorhandene Signatur einer solchen Application ist nicht
mehr vorhanden, da sich dies durch eine Signatur der gesamten Nachricht ergibt und eine
unnötige Doppelsignierung damit entfällt. Sind Prozesse so kritisch, als das sie einzeln
signiert werden müssen, so sind diese auch in einzelnen Nachrichten zu versenden.
Zertifikatsanfrage - CertificateRequest
Diese Nachricht wird zur Anfrage nach einem Zertifikat genutzt. Es können gänzlich neue
Zertifikate erstellt werden, vorhanden Schlüssel zertifiziert werden oder Zertifikate verlängert
werden.
Für die gänzliche Neuausstellung eines Zertifikats ist nur das Pflichtfeld anzugeben.
Alle weiteren Informationen werden durch das Trustcenter ausgefüllt. Hierbei
könnte auf eine vorhandene Vorlage des Trustcenters zurückgegriffen werden. Die notwendigen
Passwörter, welche verwendet werden sind durch ein Hashverfahren geschützt und
32

6.2. Intra Trustcenter Protocol Version 1.2
Anfrage Beschreibung
CertificateRequest Anfrage für die Ausstellung oder Verlängerung eines Zertifikats
Activation Aktivierung eines erhaltenen Zertifikats
Revocation Meldung und Übermittlung von Revokationen
Recovery Anfrage auf die Wiederherstellung eines Zertifikats
CertificateTransport Übermittlung von einem oder mehreren Zertifikaten
KeyTransport Übermittlung von einem oder mehreren (öffentlichen und/oder privaten) Schlüsseln
Information Aktueller Status und weiter Informationen über ein oder mehrere Zertifikate
Notify Einfacher Nachrichtenaustausch zwischen den Knoten
Tabelle 6.3.: ITP Version 1.2 Nachrichtentypen
somit sind keine weiteren vertraulichen Informationen enthalten. Damit bietet die Signatur
am Ende der Nachricht den notwendigen Schutz, um eine Veränderung der Nachricht
erkennen zu können.
Für die reine Signatur muss der öffentliche Schlüssel mit übertragen werden. Hierbei wird
in der Application CertificateRequest mit Hilfe der auf den Schlüssel verwiesen.
Dieser kann entweder dem System schon vorliegen oder durch eine weitere Application vom
Typ KeyTransport (siehe weiter unten) innerhalb dieser Nachricht übermittelt werden. Das
Trustcenter kann dann den notwendigen Proof-of-Possession (PoP) Mechanismus über das
Aktivierungspasswort realisieren.
Muss ein Zertifikat verlängert werden, so wird in der Nachricht mit dem Element
auf den entsprechenden Schlüssel verwiesen. Dieser kann gegebenenfalls auch in der Application
KeyTransport direkt mitgeliefert werden. Ob hier eine Mechanismus nach PoP
notwendig ist, muss die Policy des entsprechenden Trustcenters selbst regeln. Technisch
notwendig ist dies nicht, da der Schlüssel bereits ausgeliefert wurde und in Verwendung ist.
Somit hat der Benutzer bereits einmal nachweisen müssen, dass er im Besitz des privaten
Schlüssels ist.
Wenn ein Trustcenter nach dem Signaturgesetz arbeitet, gibt es für die Ausstellung eines
Zertifikats Auflagen. Diese notwendigen Inhalte sind in SigG § 7 (E.1) festgelegt. ITP
selbst nimmt alle diese Daten als optionale Felder auf. Somit kann ITP auch signaturgesetzkonforme
Zertifikate verarbeiten.
Bei einer CertificateRequest-Nachricht gibt es nur das Element, dass verwendet
werden muss. In diesem Feld muss der Bezeichner für den zukünftigen Inhaber des Zertifikats
stehen. Dieser Bezeichner ist nicht weiter in seiner Art eingeschränkt und somit frei
wählbar und könnte ein DN sein. Alle weiteren Felder sind optional und können je nach
Gegebenheit verwendet werden. Die sonst zur Identifikation eines Zertifikats dienenden Felder
und sind optional, sie können bei einer Verlängerung der
Zertifikats herangezogen werden. Das Element nimmt den
alternativen Namen des Inhabers des Zertifikates auf. Hier wird oft auf eine Emailadresse
oder den Domainnamen zurückgegriffen. Mit den drei Feldern , und
ist es möglich bei der Erstellung Einfluss auf den Schlüssel und dessen
Verwendungszwecks zu nehmen. Eine Beispiel einer solchen Nachricht findet sich in A.4
und die Übersicht aller Elemente in Tabelle 6.4.
33

6. Intra Trustcenter Protocol
Feld Typ Datentyp req Beschreibung
Subject Element xsd:string required Identifikator des Zertifikats
SubjectAlternativeName Element xsd:string optional zum Beispiel eine Emailadresse
Password[Index] Element itp:PasswordType optional Passwörter
Issuer Element xsd:string optional Aussteller des Zertifikats oder
bei einer Verlängerung zur
Identifizierung des alten Zertifikats
SerialNumber Element xsd:string optional Seriennummer, bei einer Verlängerung
zur Identifizierung
des alten Zertifikats
KeyId[Index] Element xsd:string optional Für die gezielte Wahl eine mitgelieferten
oder bereits vorhanden
Schlüssels
KeyUsage[Index] Element itp:KeyUsageType optional Angelehnt an RFC 3280, Vorgaben
für die Verwendung des
Schlüssels
KeyAlgorithmen[Index] Element xsd:string optional Für die Vorgabe eines Algorithmus
Tabelle 6.4.: Felder der CertificateRequest-Nachricht
Aktivierungsnachrichten - Activation
Um die im Signaturgesetz (E.3) gestellten und im Abschnitt 5.1.4 gezeigten Anforderungen
zu erfüllen, muss innerhalb einer ITP-Nachricht ein eindeutiger Identifikator des Zertifikats
vorhanden sein. Ebenso ist eine optionale Meldung über den Status des Zertifikats sinnvoll.
Notwendige TAGs für diese Nachricht sind und . Diese zwei
Felder identifizieren ein Zertifikat innerhalb einer PKI eindeutig. Die gesamte Nachricht
sollte dann auch von einer Signatur des Eigentümers umschlossen sein. Ein Beispiel für eine
solche Nachricht gibt Quelltext A.6. In Tabelle 6.5 wird eine Übersicht über die Elemente
einer Aktivierungsnachricht gegeben.
Feld Typ Datentyp req Beschreibung
Issuer[Index] Element xsd:string required Aussteller des Zertifikats
SerialNumber[Index] Element xsd:string required Seriennummer
Password[Index] Element itp:PasswordType optional Aktivierungspasswort
PublicAvailable[Index] Element xsd:boolean optional Zertifikat soll öffentlich verfügbar
sein
Activate[Index] Element xsd:boolean optional Zertifikat soll aktiviert werden
CertHash[Index] Element xsd:base64binary optional Hashwert über das Zertifikat
(Kompatibilität zu CMP)
CertReqId[Index] Element xsd:string optional Identifikator für die Anfrage
(Kompatibilität zu CMP)
Tabelle 6.5.: Felder der Activation-Nachricht
Bei einer Aktivierung sollte jedoch auch die Möglichkeit der Überprüfung des Eigentümers
durch die CA erreicht werden. Hierzu wird das optionales TAG
34

6.2. Intra Trustcenter Protocol Version 1.2
hinzugefügt. Hier kann ein von der CA erstelltes Passwort in die Antwort einfließen. Dieses
Passwortfeld muss während des Transportes geschützt sein.
Um eine Ablehung des Zertifkates zu ermöglichen wird das optionale TAG
verwendet. Durch diesen Boolean-Wert kann dem Trustcenter mitgeteilt werden, dass der
Benutzer das Zertifikat aktiviert haben möchte oder eben nicht.
Eine weiterer Punkt ist das deutsche Signaturgesetz Paragraph 7 (E.1). Zu beachten ist
die Möglichkeit der Steuerung über die Publizierung des Zertifikats. Diese Forderung wird
mit dem optionalen TAG erfüllt. Hier kann eingestellt werden, ob ein
Zertifikat öffentlich publiziert werden soll oder nicht.
Die zwei Elemente und sind zur Kompatibilität mit CMP hinzugekommen.
In diesen wird ein Hashwert über das Zertifikat und der Anfrage Identifikator
abgelegt. Diese Werte direkt in diese Elemente erfasst werden.
Eine vollständige ITP-Aktivierungsnachricht findet sich im Quelltext A.5, dieser zeigt alle
Möglichkeiten von Parametern und Optionen.
Revokationsnachricht - Revocation
Um ein erstelltes und ausgeliefertes Zertifikat zurückzuziehen, muss dieses revoziert werden.
Hierfür bietet ITP einen Nachrichtentyp an, der die Information auf allen Ebenen
übermitteln kann. Dieser Vorgang ist vom verwendeten Revokationsmechanismus unabhängig.
Sowohl eine Revokationinformationsverwaltung mittels eines Certificate Revokation
List oder über Online Certificate Status Protocol wird unterstützt. Die Nachricht selbst
ist so generisch erzeugt, dass sie keinerlei Festlegung oder Beschränkung auf einen dieser
Mechanismen vorsieht.
Feld Typ Datentyp req Beschreibung
Issuer[index] Element xsd:string required Aussteller des Zertifikats
SerialNumber[Index] Element xsd:string required Seriennummer
Password[Index] Element itp:PasswordType optional Revokationspasswort
Reason[Index] Element xsd:string optional Grund der Revokation
Tabelle 6.6.: Felder der Revocation-Nachricht
Für eine Revokation ist eine eindeutige Identifizierung des Zertifikats notwendig. Dazu wird
der Aussteller und die Seriennummer des Zertifikats verwendet. Die innerhalb einer CA
eindeutige Seriennummer zusammen mit der Aussteller CA ist ein eindeutige Identifikator
eines Zertifikats. Werden andere Mechanismen verwendet so ist dieses Feld sinngemäß zu
verwenden. Weiterhin kann der Grund der Revokation mit angegeben werden. Ein Absicherung
dieses Vorganges erfolgt über das Revokationspasswort. Dieses Passwort, welches
bei der Erstellung der Zertifikats festgelegt wurde, muss vom Benutzer eingegeben werden
und wird von der CA überprüft. Ist es korrekt, so kann die Nachricht weitergeleitet werden
und die Revokation vollzogen werden.
Ein Beispiel für eine solche Nachricht finde sich in Anhang A.10 und einen kurzen Überblick
über die Elemente findet sich in Tabelle 6.6.
35

6. Intra Trustcenter Protocol
Wiederherstellungsnachricht - Recovery
Die Wiederherstellung eines Schlüssels ist ein kritischer Vorgang. Daher kann hier aus
sicherheitstechnischen Gründen das 4-Augen-Prinzip gefordert sein. Dies wird bei einer
ITP-Nachricht durch das Vorhanden sein von mindestens zwei gültigen Signaturen an
einer Recovery-Nachricht realisiert. Somit kann die Wiederherstellung eines Zertifikats
angestoßen werden. Ein Beispiel für eine solche Nachricht findet sich in Anhang A.9, die
Elemente sind in Tabelle 6.7 aufgeführt. Für die Wiederherstellung kann ein Passwort
vergeben worden sein, so dass dieses bei der Beauftragung durch das Element mit übermittelt werden kann. Für die eindeutige Identifizierung eines
Schlüssel ist das notwendige Element vorhanden.
Es ist auch die Wiederherstellung von mehreren Schlüsseln möglich, da über das Attribut
Index die eindeutige Zuordnung der Daten gewahrt bleibt.
Feld Typ Datentyp req Beschreibung
KeyId[index] Element xsd:string required Identifikator des Wiederherzustellenden
Schlüssels
Password[Index] Element itp:PasswordType optional Recoverpasswort
Tabelle 6.7.: Felder der Recovery-Nachricht
Zertifikatsübermittlung - CertificateTransport
Für einen Transport von Zertifikaten ist die Application CertificateTransport vorgesehen.
Die Elemente in dieser Nachricht teilen sich, wie man in Tabelle 6.8 sehen kann, in zwei
notwendige und zwei optionale Felder auf. Die notwendigen Felder und
dienen zur eindeutigen Identifizierung der transportierten Daten. In den
zwei optionalen Feldern und werden die eigentlichen
Daten enthalten. Das öffentliche Zertifikat muss nicht weiter verborgen werden und
kann somit in einem einfachen xsd:base64Binary Feld transportiert werden. Für den zum
Zertifikat passenden privaten Schlüssel ist ein verschlüsselter Bereich vorgesehen. Auch bei
dieser Nachricht ist es über einen Index möglich mehrer Zertifikate in einer Application
zuverlässig zu transportieren.
Feld Typ Datentyp req Beschreibung
Issuer[Index] Element xsd:string required Aussteller des Zertifikats
SerialNumber[Index] Element xsd:string required Seriennummer
PublicCertificate[Index] Element xsd:base64Binary optional Öffentliches Zertifikat
PrivateKey[Index] Element xenc:EncryptedType optional Privater Schlüssel
36
Tabelle 6.8.: Felder der CertificateTransport-Nachricht

Schlüsselübermittlung - KeyTransport
6.2. Intra Trustcenter Protocol Version 1.2
Für die Übertragung von reinen Schlüsseln wird die Application KeyTransport verwendet.
Der binärcodierte Schlüssel wird hierbei über seine eindeutige zugeordnet.
Für den öffentlichen Teil wird, wie man in Tabelle 6.9 schon erahnen kann, das Element
mit dem Datentyp xsd:base64Binary benutzt. Der zu schützende private
Schlüssel wird in einem verschlüsselten Feld übermittelt. Für die Übertragung
von mehr als einem Schlüsselpaar ist jedem Feld das Attribut Index zugewiesen um
somit den eindeutigen Identifikator des Schlüssels mit den binären Schlüsseldaten zuverlässig
zu verknüpfen. Ein Beispiel für eine solche Nachricht findet sich in A.8.
Feld Typ Datentyp req Beschreibung
KeyId[Index] Element xsd:string required Eindeutiger Schlüsselidentifikator
PublicKey[Index] Element xsd:base64Binary optional Öffentlicher Schlüssel
SecretKey[Index] Element xenc:EncryptedType optional Privater Schlüssel
Informationsnachricht - Information
Tabelle 6.9.: Felder der KeyTransport-Nachricht
Für die Übermittlung von Statusinformationen eines Zertifikates ist die Informationsnachricht
vorgesehen. Sie enthält, wie in Tabelle 6.10 gezeigt, neben den Elementen
und für die eindeutige Zuordnung die optionalen Elemente und
. Mit kann der aktuelle Status eine Zertifikats übermittelt werden.
ermöglicht einen weiteren Informationsaustausch. Über das Attribut Index ist
es bei dieser Nachricht auch möglich mehrere Zertifikate gleichzeitig zu verarbeiten.
Feld Typ Datentyp req Beschreibung
Issuer[index] Element xsd:string required Aussteller des Zertifikats
SerialNumber[Index] Element xsd:string required Seriennummer
Status[Index] Element xsd:string optional Aktueller Status über ein Zertifikat
KeyInfo[Index] Element ds:KeyInfoType optional Weitere Informationen
Allgemeine Nachricht - Notify
Tabelle 6.10.: Felder der Information-Nachricht
Die Notify-Nachricht ist für alle möglichen Informationsaustausche zwischen den Komponenten
vorgesehen. Ihr Inhalt ist, wie Tabelle 6.11 bereits aufgeschlüsselt, dreigeteilt.
Somit ist die Übertragung von reinem, und oder eine
Kombination dieser Daten möglich. Durch die Signatur, welche der Fussteil einer Nachricht
liefert, ist es möglich sicher Daten zwischen den Komponenten auszutauschen. Diese
Nachricht bildet somit einen universellen Container für alle sonstigen Nachrichten. Jedoch
muss beachtet werden, dass diese Nachricht keine spezifischen Informationen bezüglich ihrer
enthaltenen Daten liefern kann und somit eine Protokollierung nur schwer möglich ist.
37

6. Intra Trustcenter Protocol
Um einer Protokollierung entgegen zu kommen ist das Element ein notwendiges
Feld. Bei der Übertragung von reinen Binärdaten kann in diesem Element eine Hinweis
auf die enthaltenen Daten gegeben werden. Ein Zuordnung erfolgt hier über eine Attribut
namens Index, was die Übertragung von mehreren Sequenzen innerhalb eines Application
zuverlässig und weiterhin eindeutig ermöglicht.
Das Attribut Error vom Datentyp xsd:boolean ist für die Markierung eines Fehlernachricht
gedacht. Somit können diese zuverlässig und schnell erkannt werden. Die Fehlermeldung
selbst ist dann im Element enthalten und es ist möglich Binärdaten, die
zum Beheben des Fehler notwendig sein könnten mit zu übertragen. Über den Index ist
auch das Übermitteln von mehreren gleichzeitg auftretenden Fehlern möglich.
Der Bezeichner Notify ist bewusst für diese Nachricht gewählt, um die Unterordnung
dieser Nachricht gegenüber anderen klar darzustellen und die Häufigkeit der Verwendung
zu reduzieren. Diese Nachricht soll nicht als Ersatz für bereits vorhandene und spezifischer
Nachrichten in ITP dienen, ist aber der bereitgestellte Mechanismus für die Übermittlung
von Fehlermeldungen.
Feld Typ Datentyp req Beschreibung
Text[Index] Element xsd:string required Einfache Textinformationen
BinaryData[Index] Element xsd:base64Binary optional Binär Daten
SecretData[Index] Element xenc:EncryptedType optional Vertrauliche Daten
Error Attribut xsd:boolean optional / False Markierung für eine Fehlermeldung
Tabelle 6.11.: Felder der Notify-Nachricht
Die Notify-Nachricht wird wie im Szenario 5.2.3 beschrieben und bei der Erneuern des
Vertrauensankers eingesetzt. Da dieser Vorgang zu den kritischsten Vorgängen innerhalb
einer PKI gehört, findet in der Regel auch keine große Kommunikation innerhalb des
Trustcenters statt. Mit einer Notify-Nachricht besteht die Möglichkeit der CA das TC
über den Ablauf seines Zertifikats selbst zu informieren und mit einer weiteren Komponenten
zu informieren, die über eine Update des Vertrauensankers informiert sein müssen.
Eine Übermittlung der neuen Zertifikate, kann durch eine CertificateTransport-Nachricht
erfolgen. Hier können in einem Rutsch alle drei neuen Zertifikate sicher übermittelt werden.
Eine weitere Überprüfung der Daten erfolgt in den Komponenten selbst und somit
gibt es für das Managementprotokoll in diesem Punkt keine weitere Aufgaben.
6.2.4. Analyse
Die einzelnen Szenarien aus Kapitel 5 sind mit ITP 1.2 abgedeckt und können verarbeitet
werden. Die Designziele aus 6.1 werden erfüllt.
Eine Allgemeingültigkeit und Unabhängigkeit der Nachrichten ist durch generische Namen
und die Kapselung von einzelnen Aufgaben vorhanden. Das Design ist jedoch an dem
aktuell verwendeten PKI Konzept mit Zertifikaten nach X.509 angelehnt. Eine Skalierbarkeit
ergibt sich durch die Zusendung von Paketen an beliebige Komponenten. Dadurch
können Aufgaben einfach verteilt werden. In Kombination mit der Erweiterung um be-
38

6.2. Intra Trustcenter Protocol Version 1.2
liebigen Komponenten ergeben sich für die Skalierung weitere Möglichkeiten. Wird eine
neue Komponente in die PKI eingeführt, so muss sie nur den zuständigen Stellen bekannt
gemacht werden. Der Versand der Nachrichten bleibt weitestgehend unberührt. Die Forderung
nach Automatisierbarkeit und Nachvollziehbarkeit ist erfüllt. Durch das Schema
können Nachrichten konform erstellt werden und auf diese Überprüft werden. Die feste
Vorgabe von Elementen, die zur Identifizierung der Nachrichten und Aufgaben vorhanden
sind, ist für die Protokollierung optimal, da hier nur die entsprechenden Stellen betrachtet
beziehungsweise gespeichert werden müssen. Soweit es geht sind die Nachrichten im
Klartext formuliert und bieten damit einen direkten Einblick auf deren Inhalt. Die Verarbeitung
von Fehlermeldungen innerhalb von ITP ermöglicht es, dass der selbe Mechanismus
zum Speichern und Protokollieren der Prozesse verwendet werden kann um auch die
Fehlermeldungen zu verarbeiten.
Der größten Fortschritt wurde in der Sicherheit gemacht. So werden nur noch strukturierte
überprüfbare Daten versendet. Jegliche vertrauliche Information muss verschlüsselt versendet
werden. Verschlüsselte Bereiche gab es zuvor nicht. Auch auf die Signaturen wurden
eher marginal hingewiesen. Mit Version 1.2 müssen sie verwendet werden und nach den
Vorgaben vorhanden sein.
39

6. Intra Trustcenter Protocol
40

7. Fazit und Ausblick
7.1. Fazit zu Version 1.2
Mit dem Erreichen der Version 1.2 ist ITP eine großen Schritt in Richtung des produktiven
Einsatzes vorangekommen. Das eingeführte Schema ermöglicht es Nachrichten nach
festgelegten Regeln zu erstellen und zu verarbeitende Nachrichten auf Korrektheit zu überprüfen.
Die in Kapitel 5 vorgestellten Szenarien werden alle durch ITP 1.2 abgedeckt.
Mit der Schemadefinition in Version 1.2 wird eine Struktur vorgeben, die einzuhalten ist.
Die Gradwanderung zwischen Flexibilität, Generalität und Struktur galt es zu begehen.
Daher sind die Nachrichten so gestaltet worden, dass sie auf keine spezifische PKI festgelegt
sind. Auch ist das zu verarbeitende Zertifikat in seiner Art nicht festgelegt. Ein
unvermeidbarer Anlehnung an den aktuell vorherrschenden Standard X.509 ist jedoch zu
erkennen. Die Elemente in den Nachrichten wurden auch im Hinblick auf das deutsche
Signaturgesetz und die Signaturverordnung entwickelt. So das der Einsatz im Bereich der
qualifizierten Signaturen möglich ist.
Ein weiterer Fortschritt ist die Einführung der Möglichkeit Fehlermeldungen zwischen den
Komponenten zu versenden. Die Notify-Nachricht bietet auch die Möglichkeit notwendige
Informationen zur Analyse und Behebung mit zu senden. Es kann somit jede in der Anwendung
auftretende Fehlermeldungen inklusive etwaiger Daten zur Behebung übermittelt
werden.
Gegenüber den Vorgängerversionen werden vertrauliche Daten in verschlüsselter Form
übermittelt. Hierbei ist es unerheblich, ob es sich um Passwörter oder private Schlüssel
handelt. Mit der Verwendung von XML Digital Signature und XML Encryption in diesem
Bereich ist auf Standards zurückgegriffen worden, die bereits bekannt sind und sich etabliert
haben. Eine Neuentwicklung in diesem Bereich war nicht notwendig. Dies entlastet
die Entwickler und sorgt für eine höhere Kompatibilität zu anderen Anwendungen.
Das entwickelte Schema sorgt für eine Steigerung der Sicherheit und eine Vereinfachung
im Einsatz von ITP, somit kann dieses Protokoll auch Einzug in produktiven Bereichen
erhalten. Ein Umdenken im Bereich der Kapselung von Aktionen ist erforderlich, da zum
Beispiel in den Applications selbst keine Zertifikate mehr übermittelt werden, sondern
diese in nur noch in der Application CertificateTransport übertragen werden. Die kann in
der selben Nachricht erfolgen.
7.2. Ausblick auf Intra Trustcenter Protocol Version 2.0
Die in Version 1.2 entworfene XML-Schema-Definition müsste dahingehende ausgebaut
werden, dass weitere Nachrichten und Methoden die im Bereich eine PGP Infrastruktur
vorliegen integriert werden. Das Protokoll ist so entwickelt, dass es eine Peer-2-Peer Struk-
41

7. Fazit und Ausblick
tur unterstützt und in dieser verwendet werden kann. In diesem Bereich gibt es Probleme
die noch in den Nachrichten und der Struktur nicht erfasst sind. Es müsste Möglichkeiten
geben um Zeitsyncronität, globale Zustände und die Zuständigkeiten von Aufträgen zu
übermitteln und erfüllen.
Eine Verfeinerung der rudimentären Fehlermeldungen ist denkbar. Hier gibt es noch Potential
für eine Verbesserung in Richtung definierter Fehlercodes und Meldungen. Zu bedenken
ist die Forderung nach der Generalität. Die Meldungen dürfen nicht zu spezifisch werden
und es sollte auch nicht für jede Eventualität in jedem Modell ein Meldung existieren, da
dieses nur noch unübersichtlich wäre.
Weiterhin ist die Einführung von einem Attribut das kritische Nachrichten markiert denkbar.
Bei dieser Markierung muss jedoch der komplette Prozess beachtet werden. Falls an
einer Stelle in einem Prozessablauf ein Fehler in einer kritischen Nachricht auftritt so muss
der gesamte Prozess nochmals kontrolliert werden. Da diese Prozesse und der Prozessablauf
jedoch für jede PKI-Anwendung individuell ist, können Korrekturmechanismen auch
nur in der Anwendung selbst vorhanden sein. Eventuell ist es hier denkbar eine Prozessbeschreibung
in die ITP Nachrichten zu integrieren.
Als Ziel soll ITP beim World Wide Web Consortium (W3C) im Herbst 2007 zur Standardisierung
eingereicht werden.
42

A. ITP-Nachrichten Quelltexte
1
2 Registration
3 Certification
4
5
6
7 value
8
9
10 value
11
12
13
14
15
16
17
18
19
20
21
22
23
24
Quelltext A.1: Standardnachricht von ITP Version 1.0
1
2 [Cleartext | Sender of the Message]
3 [Cleartext | Recipient of the Message]
4
5
6
7 [Cleartext]
8
9
10 [Cleartext]
11
12
13 [Cleartext]
14
15
16 [binary | Certificate for encryption]
17
18
19 [binary | Certificate for signing]
20
43

A. ITP-Nachrichten Quelltexte
21
22 [binary | Certificate for ]
23
24
25 [Cleartext | Password for Revocation]
26
27
28 [true|false]
29
30
31
32 [XML digital Signature | Signature about the profile]
33
34 [possibility of more signatures]
35
36 [possibility of more applications]
37
38 [XML digital Signature | Signature about the message]
39
40 [possibility of more signatures]
41
Quelltext A.2: Syntax einer ITP-Nachricht Version 1.0
1
2 [Cleartext | Sender of the Message]
3 [Cleartext | Recipient of the Message]
4
5
6
7
8 [Cleartext]
9
10
11
12
13 [Cleartext]
14
15
16
17
18 [Cleartext]
19
20
21
22
23 [binary | Certificate for encryption]
24
25
26
27
28 [Cleartext | Password for Revocation]
29
30
31
32
44

33 [true|false]
34
35
36
37
38 [XML digital Signature | Signature about the profile]
39
40 [possibility of more signatures]
41
42 [possibility of more applications]
43
44 [XML digital Signature | Signature about the message]
45
46 [possibility of more signatures]
47
Quelltext A.3: Syntax einer ITP-Nachricht Version 1.1
1
7 Sender0
8 Recipient0
9 2006-05-04T18:13:51.0Z
10
11
12
13 CN=Jochen,OU=OrgUnitName,O=OrgName,C=DE
14
15
16 becker@cdc.informatik.tu-darmstadt.de
17
18
19 CN=MyCA,OU=OrgUnitName,O=OrgName,C=DE
20
21
22 1234
23
24
25 a123
26
27
28 RSA
29
30
31 digitalSignature
32
33
34
35
36
37
45

A. ITP-Nachrichten Quelltexte
38
39
40
41
42
43
44 ZGVmYXVsdA==
45
46
47 ZGVmYXVsdA==
48
49
50
51
Quelltext A.4: Standard CertificateRequest-Nachricht
1
7 Sender0
8 Recipient0
9 2006-05-04T18:13:51.0Z
10
11
12
13
14 CN=MyCA,OU=OrgUnitName,O=OrgName,C=DE
15
16
17 10245
18
19
20
21 60NvZvtdTB+7UnlLp/H24p7h4bs=
22
23
24
25 60NvZvtdTB+7UnlLp/H24p7h4bs=
26
27
28 true
29
30
31 true
32
33
34 ZGVmYXVsdA==
35
36
46

37 IDABX1
38
39
40
41
42
43
44
45
46
47
48
49
50 ZGVmYXVsdA==
51
52
53 ZGVmYXVsdA==
54
55
56
57
Quelltext A.5: Standard Activation-Nachricht
1
7 Sender0
8 Recipient0
9 2006-05-04T18:13:51.0Z
10
11
12
13
14 CN=MyCA,OU=OrgUnitName,O=OrgName,C=DE
15
16
17 10245
18
19
20
21 60NvZvtdTB+7UnlLp/H24p7h4bs=
22
23
24
25 60NvZvtdTB+7UnlLp/H24p7h4bs=
26
27
28 true
29
47

A. ITP-Nachrichten Quelltexte
30
31 true
32
33
34 ZGVmYXVsdA==
35
36
37 IDABX1
38
39
40
41
42
43
44
45
46
47
48
49
50 ZGVmYXVsdA==
51
52
53 ZGVmYXVsdA==
54
55
56
57
Quelltext A.6: Kürzeste Activation-Nachricht
1
6 Sender0
7 Recipient0
8 2006-05-04T18:13:51.0Z
9
10
11 CN=ABC
12 121331
13
14
15 256
16 9lWu3Q==
17
18
19
20 Jochen
21

22 Type="http://www.w3.org/2001/04/xmlenc#EncryptedKey"/>
23
24
26
27 qZk+NkcGgWq6PiVxeFDCbJzQ2J0=
28
29
30
31
32
33
34
35 Zm9v
36
37
38
39
40 cafebabe
41 cafebabe
42
43
44
45
46
47
48 cafebabe
49 cafebabe
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64 This XML document
tests the schema
65 for ambigous content.
66
67
68
69
70
71
49

A. ITP-Nachrichten Quelltexte
72
73
74
75
76
77 ZGVmYXVsdA==
78
79
80 ZGVmYXVsdA==
81
82
83
Quelltext A.7: Standard CertificateTransport-Nachricht
1
6 Sender0
7 Recipient0
8 2006-05-04T18:13:51.0Z
9
10
11 CN=ABC
12 121331
13
14
15 256
16 9lWu3Q==
17
18
19
20 Jochen
21
23
24
26
27 qZk+NkcGgWq6PiVxeFDCbJzQ2J0=
28
29
30
31
32
33
34
50

35 Zm9v
36
37
38
39
40 cafebabe
41 cafebabe
42
43
44
45
46
47
48 cafebabe
49 cafebabe
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64 This XML document
tests the schema
65 for ambigous content.
66
67
68
69
70
71
72
73
74
75
76
77 ZGVmYXVsdA==
78
79
80 ZGVmYXVsdA==
81
82
83
Quelltext A.8: Standard KeyTransport-Nachricht
51

A. ITP-Nachrichten Quelltexte
1
7 Sender
8 Recipient
9 2006-05-04T18:13:51.0Z
10
11
12
13 CN=MyCA,OU=OrgUnitName,O=OrgName,C=DE
14
15
16 0815
17
18
19
20
21
22
23
24
25
26
27
28
29 ZGVmYXVsdA==
30
31
32 ZGVmYXVsdA==
33
34
35
36
37
38
39
40
41
42
43 AhbcZUHBNBba
44
45
46 AhbcZUHBNBba
47
52

48
Quelltext A.9: Standard Recovery-Nachricht
1
7 Owner of all keys
8 Trust Center
9 2006-05-04T18:13:51.0Z
10
11
12 CN=MyCA1,OU=OrgUnitName,O=OrgName,C=DE
13 CN=MyCA2,OU=OrgUnitName,O=OrgName,C=DE
14 CN=MyCA2,OU=OrgUnitName,O=OrgName,C=DE
15 08151a
16 08152a
17 08152b
18
19
20
21
22 ZGVmYXVsdA==
23
24
25 Revoked
26 Compromissed
27 Root CA - compromissed
28
29
30
31
32
33
34
35
36
37
38
39 ZGVmYXVsdA==
40
41
42 ZGVmYXVsdA==
43
44 Owner of all Revoked Key
53

A. ITP-Nachrichten Quelltexte
45
46
47
54
Quelltext A.10: Standard Revocation-Nachricht

B. Intra Trustcenter Protocol Version 1.2
Schema
1
2
5
6
12
13
15
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
33
34
35
36
37
38
39
41
42
55

B. Intra Trustcenter Protocol Version 1.2 Schema
43
44
45
46
47
48
49
50
52
53
55
57
58
59
60
62
63
64
65 Standard Message Format
66
67
68
69
70
72
73
74
75
77
79
80
81
82
83
84
85
86
87
89
91
93
95
97

98 maxOccurs="unbounded">
99
100
101
102
104
105
106
107
108
110
111
112
113
115
116
117
118
119
121
122
123
124
126
127
128
129
130
131
132
133
134
135
136
138
139
140
141
143
144
145
146
147
149
150
151
152

B. Intra Trustcenter Protocol Version 1.2 Schema
153 type="xsd:nonNegativeInteger" use="required" />
154
155
156
157
158
160
161
162
163
165
166
167
168
169
171
172
173
174
176
177
178
179
180
182
183
184
185
187
188
189
190
191
193
194
195
196
198
199
200
201
202
204
205
206
207

208 type="xsd:nonNegativeInteger" use="required" />
209
210
211
212
213
214
215
216
217
218
220
221
222
223
225
226
227
228
229
231
232
233
234
236
237
238
239
240
242
243
244
245
247
248
249
250
251
253
254
255
256
258
259
260
261
262
59

B. Intra Trustcenter Protocol Version 1.2 Schema
263
264
265
266
267
269
270
271
272
274
275
276
277
278
280
281
282
283
285
286
287
288
289
290
291
292
293
294
296
297
298
299
301
302
303
304
305
307
308
309
310
312
313
314
315
316
60

318
319
320
321
323
324
325
326
327
328
329
330
331
332
334
335
336
337
339
340
341
342
343
345
346
347
348
350
351
352
353
354
356
357
358
359
361
362
363
364
365
367
368
369
370
372
61

B. Intra Trustcenter Protocol Version 1.2 Schema
373
374
375
376
377
378
379
380
381
383
384
385
386
388
389
390
391
392
394
395
396
397
399
400
401
402
403
405
406
407
408
410
411
412
413
414
416
417
418
419
421
422
423
424
425
426
427
62

428
429
430
432
433
434
435
437
438
439
440
441
443
444
445
446
448
449
450
451
452
454
455
456
457
459
460
461
462
463
464
466
467
468
469
470
471
472
473
475
476
477
478
479
480
481
482
63

B. Intra Trustcenter Protocol Version 1.2 Schema
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
64
Quelltext B.1: ITP 1.2 Schema

C. ITP-Tag Referenz
Dieser Abschnitt liefert eine TAG-Referenz für ITP in Versionen 1.0 und 1.1. Für Version
1.2 sei auf den Abschnitt 6.2 verwiesen. Innerhalb dieses Abschnittes werden die einzelnen
Elemente aufgeführt und in Abhängigkeit ihres Einsatzes erklärt. Ebenso kann man für
eine Referenz in die Schema-Definition in Anhang B schauen.
XML-Tag notwendig/optional
notwendig
notwendig
notwendig
optional mehrfach
optional mehrfach
optional
optional
optional
optional
optional
optional
optional
optional mehrfach
Tabelle C.1.: ITP Version 1.0 — XML-Tags im Überblick
65

C. ITP-Tag Referenz
66
XML-Tag notwendig/optional Vorgänger
notwendig
notwendig
notwendig
optional mehrfach
optional mehrfach
optional
optional
optional
optional
optional
optional
optional
optional
optional mehrfach
Tabelle C.2.: ITP Version 1.1 — XML-Tags im Überblick

D. Vergleich ITP mit CMP
Am Beispiel der Aktivierungsnachricht wird ein Vergleich zwischen CMP und ITP Version
1.2 vorgenommen. Die Aktivierungsnachricht wurde gewählt, da sie im Grunde eine recht
einfache Nachricht ist, sich jedoch beliebig verkomplizieren lässt.
Im Quelltext D.1 wird eine auf die wesentlichen Bestandteile gekürzte Aktivierungsnachricht
im ITP Format gezeigt. Der Quelltext D.2 gibt die Definition einer CMP Aktivierungsnachricht
wieder. Die Definition wurde an dieser Stelle gewählt, da sie übersichtlicher
ist die ASN.1 Codierung einer Nachricht. Die einzelnen Elemente sind ebenfalls auf die
Wesentlichen reduziert.
1
2 xsd:string
3 xsd:string
4 xsd:date
5
6
7
8 xsd:string
9
10
11 xsd:string
12
13
14 xsd:boolean
15
16
17 xsd:base64binary
18
19
20 xsd:integer
21
22
23
24
25 [Signatur]
26
27
Quelltext D.1: Aktivierungsnachricht von ITP
1 PKIMessage ::= SEQUENCE {
2 header PKIHeader ::= SEQUENCE {
3 pvno INTEGER,
4 sender GeneralName,
5 recipient GeneralName,
6 },
7 body CertConfirmContent ::= SEQUENCE OF {
67

D. Vergleich ITP mit CMP
8 CertStatus ::= SEQUENCE {
9 certHash OCTET STRING,
10 certReqId INTEGER,
11 statusInfo PKIStatusInfo OPTIONAL
12 },
13 },
14 protection [0] PKIProtection OPTIONAL ,
15 extraCerts [1] SEQUENCE SIZE (1..MAX) OF CMPCertificate OPTIONAL,
16 }
Quelltext D.2: Aktivierungsnachricht in CMP
Beide Nachrichten teilen sich in verschiedene Blöcke auf. Die ITP-Nachricht enthält den
Kopfteil mit Sender, Empfänger, Zeitpunkt und einen eindeutigen Identifikator der Nachricht.
Auf diesen Block folgt die Application mit dem Auftrag einer Activation. Zum
Schluss ist noch eine notwendige Signatur über die Nachricht angehängt. Innerhalb der
Activation wird das zu aktivierende Zertifikat eindeutig anhand des Aussteller und der
Seriennummer identifiziert. Für die Übermittlung von mehreren Zertifikaten in einer Activation-Nachricht
ist das Attribut Index vorhanden.
CMP Identifiziert im Kopfteil die Nachricht mit Hilfe einer Nummer (pvno) eindeutig.
Ebenso wird dort der Sender und Empfänger der Nachricht benannt. Daran angeschlossen
kommt im allgemeinen Nachrichtenbereich der CertConfirmContent-Block, der selbst nur
eine Sequenz von CertStatus-Blöcken ist. Innerhalb eines CertStatus-Blocks wird das
Zertifikat über den Hashwert (certHash) identifiziert. Mit statusInfo wird der Status
über das Zertifikat gesetzt.
In beiden Nachrichten ist es möglich die Aktivierung eines Zertifikates zu unterbinden. Bei
ITP wird das Element auf false gesetzt. Bei CMP übernimmt diese Aufgabe
das Element statusInfo, das auf den Wert status = rejection gesetzt wird.
Beide Nachrichten bieten eine Absicherung der Nachricht an. Bei ITP ist diese notwendig,
innerhalb von CMP ist die Signatur im PKIProtection-Bereich optional. CMP sieht im
optionalen Bereich noch die Übermittlung von beteiligten Zertifikaten vor, dies ist in ITP
mit einer weiteren Application in der Nachricht möglich.
Beide Nachrichten sind von ihrem Umfang bisher gleich und bieten eine Basis für weitere
Funktionalität. Die Verschachtelung von Information in einer CMP Nachricht wirkt sich
erheblich auf die Lesbarkeit aus. So ist es nicht durch eine schnelles Überprüfen in der
Nachricht möglich zu erkennen welche Zertifikate angefragt werden. Die Identifikation
eines Zertifikates durch den Hashwert dieses ist an dieser Stelle ungeschickt gewählt. Ein
Mensch hat bei diesen Aufgaben Probleme.
ITP bietet darüber hinaus, wie man in Abschnitt 6.2.3 sehen kann erheblich mehr direkt
zugängliche Funktionen. Alle Informationen sind auf einen Blick erkennbar und können somit
auch für eine Protokollierung schnell erfasst werden. Dies ergibt sich vor allem durch
die Verwendung von XML anstelle von ASN.1 als Codierungsformat. Diese Übersichtlichkeit
ist gerade bei eine semantischen Prüfung der Informationen notwendig, da der
Mensch in seinen Möglichkeiten der Informationswahrnehmung gegenüber dem Computer
im Nachteil ist.
Weitere sich auf alle CMP Nachrichten beziehende Probleme finden sich unter anderem in
”A PKI your mother can use” [22].
68

E. Gesetzestexte
Auszüge aus dem deutschen Signaturgesetz und der deutschen Signaturverordnung in der
aktuell gültigen Fassung von 2001.
E.1. Signaturgesetz § 7
(1) Ein qualifiziertes Zertifikat muss folgende Angaben enthalten und eine qualifizierte
elektronische Signatur tragen:
1. den Namen des Signaturschlüssel-Inhabers, der im Falle einer Verwechslungsmöglichkeit
mit einem Zusatz zu versehen ist, oder ein dem Signaturschlüssel-
Inhaber zugeordnetes unverwechselbares Pseudonym, das als solches kenntlich
sein muss,
2. den zugeordneten Signaturprüfschlüssel,
3. die Bezeichnung der Algorithmen, mit denen der Signaturprüfschlüssel des
Signaturschlüssel-Inhabers sowie der Signaturprüfschlüssel des Zertifizierungsdiensteanbieters
benutzt werden kann,
4. die laufende Nummer des Zertifikats,
5. Beginn und Ende der Gültigkeit des Zertifikats,
6. den Namen des Zertifizierungsdiensteanbieters und des Staates, in dem er
niedergelassen ist,
7. Angaben darüber, ob die Nutzung des Signaturschlüssels auf bestimmte
Anwendungen nach Art oder Umfang beschränkt ist,
8. Angaben, dass es sich um ein qualifiziertes Zertifikat handelt, und
9. nach Bedarf Attribute des Signaturschlüssel-Inhabers.
(2) Attribute können auch in ein gesondertes qualifiziertes Zertifikat (qualifiziertes
Attribut-Zertifikat) aufgenommen werden. Bei einem qualifizierten
Attribut-Zertifikat können die Angaben nach Absatz 1 durch eindeutige Referenzdaten
des qualifizierten Zertifikats, auf das sie Bezug nehmen, ersetzt
werden, soweit sie nicht für die Nutzung des qualifizierten Attribut-Zertifikats
benötigt werden.
E.2. Signaturgesetz § 10 Absatz 1
Der Zertifizierungsdiensteanbieter hat die Sicherheitsmaßnahmen zur Einhaltung
dieses Gesetzes und der Rechtsverordnung nach § 24 Nr. 1, 3 und 4 sowie
69

E. Gesetzestexte
die ausgestellten qualifizierten Zertifikate nach Maßgabe des Satzes 2 so zu dokumentieren,
dass die Daten und ihre Unverfälschtheit jederzeit nachprüfbar
sind. Die Dokumentation muss unverzüglich so erfolgen, dass sie nachträglich
nicht unbemerkt verändert werden kann. Dies gilt insbesondere für die Ausstellung
und Sperrung von qualifizierten Zertifikaten.
E.3. Signaturverordnung § 5 Absatz 2 Satz 2
Erst nachdem der Signaturschlüssel-Inhaber den Erhalt der sicheren Signaturerstellungseinheit
gegenüber dem Zertifizierungsdiensteanbieter bestätigt hat,
darf das zugehörige qualifizierte Zertifikat nach § 5 Absatz 1 Satz 2 und 3 des
Signaturgesetzes nachprüfbar und, soweit vereinbart, abrufbar gehalten werden.
E.4. Signaturverordnung § 7 Absatz 2
Der Zertifizierungsdiensteanbieter hat sich vor Sperrung auf geeignete Weise
von der Identität des zur Sperrung Berechtigten zu überzeugen. Die Sperrung
von qualifizierten Zertifikaten ist mit Angabe des Datums und der zu diesem
Zeitpunkt gültigen gesetzlichen Zeit im Zertifikatsverzeichnis nach § 4 eindeutig
kenntlich zu machen.
E.5. Signaturverordnung § 15 Absatz 2 Satz 2b)
70
Signaturanwendungskomponenten nach § 17 Absatz 2 des Signaturgesetzes
müssen gewährleisten, dass [...] bei der Prüfung einer qualifizierten elektronischen
Signatur [...] eindeutig erkennbar wird, ob die nachgeprüften qualifizierten
Zertifikate im jeweiligen Zertifikat-Verzeichnis zum angegebenen Zeitpunkt
vorhanden und nicht gesperrt waren.

Begriffe
4-Augen-Prinzip Für einen Vorgang werden mindestens 4-Augen im Sinne von mehreren
Personen benötigt. (Stichwort: Multi-person Control [15])
Benutzer Anwender einer Software, hier: Inhaber des Zertifikats
Distinguished Name (DN) Namensgebung nach [30], [46]
Hashwert Ein Wert der mit Hilfe eine Hashfunktion berechnet wird und als Repräsentant
für eine Menge Daten steht. Aus diesem Hashwert ist es nicht möglich auf die Daten
zuschließen.
Hashfunktion Eine Einwegfunktion, die einen Menge von Daten auf einen repräsentativen
Hashwert konstanter Länge abbildet. Vertreter einer Hashfunktion sind beispielsweise
MD5, SHA-1 und SHA-160.
ID - Identifier eindeutiger Identifikator für ein Objekt
Name Name für eine Komponente. Hier bei kann es sich beispielsweise um einen symbolischen
Namen, einen Distinguished Name oder eine Internetprotokolladresse handeln.
PoP - Proof-of-Possession Der Nachweis, dass der Empfänger eines Zertifikats im Besitz
des dazugehörigen privaten Schlüssels ist.
Revokationspasswort Ein Passwort das den Eigentümer eines Zertifikats so schützt, dass
Dritte nicht sein Zertifikat revozieren können. Der Eigentümer weißt den Besitz dieses
Passworts bei einer Revokation nach.
Transportpasswort Ein Passwort das als symmetrisches Geheimnis für die Verschlüsselung
des Zertifikats genutzt wird. Nur der Sender und der Empfänger kennen dieses
Passwort. Damit ist der im Zertifikat enthaltene private Schlüssel auf den Transportwegen
zum Benutzer geschützt.
71

Begriffe
72

Literaturverzeichnis
[1] ASN.1 encoding rules: XML Encoding Rules.
http://www.itu.int/rec/T-REC-X.693/en (letzter Zugriff 18.07.2007), December
2001
[2] Abstract Syntax Notation One (ASN.1): Specification of basic notation.
http://www.itu.int/rec/T-REC-X.680/en (letzter Zugriff 18.07.2007), July
2002
[3] ASN.1 encoding rules: Specification of Basic Encoding Rules (BER), Canonical
Encoding Rules (CER) and Distinguished Encoding Rules (DER).
http://www.itu.int/rec/T-REC-X.690/en (letzter Zugriff 18.07.2007), July 2002
[4] XML Encryption Syntax and Processing. http://www.w3.org/TR/xmlenc-core/
(letzter Zugriff 18.07.2007), December 2002
[5] XML-Signature Syntax and Processing. http://www.w3.org/TR/xmldsig-core/
(letzter Zugriff 18.07.2007), Februray 2002
[6] Scalable Certificate Validation and Simplified PKI Management. 2003 . – EP Patent
1,371,171
[7] ASN.1 encoding rules: Mapping W3C XML schema definitions into ASN.1.
http://www.itu.int/rec/T-REC-X.694/en (letzter Zugriff 18.07.2007), January
2004
[8] Information technology - Abstract Syntax Notation One (ASN.1): Specification of
basic notation. http://www.iso.org/iso/en/
CatalogueDetailPage.CatalogueDetail?CSNUMBER=35684 (letzter Zugriff
18.07.2007), June 2006
[9] Namespaces in XML 1.0. http://www.w3.org/TR/REC-xml-names/ (letzter Zugriff
18.07.2007), August 2006
[10] Adams, C. ; Farell, S.: Internet X.509 Public Key Infrastructure Certificate Management
Protocols. In: IETF Request For Comments 2510 (1999), March
[11] Adams, C. ; Farell, S. ; Kause, T. ; Mononen, T.: Internet X.509 Public Key
Infrastructure Certificate Management Protocol (CMP). In: IETF Request For Comments
4210 (2005), September
[12] Bray, T. ; Paoli, J. ; Sperberg-McQueen, C.M. ; Maler, E.: Extensible Markup
Language (XML). http://www.w3.org/XML/ (letzter Zugriff 18.07.2007),
73

Literaturverzeichnis
[13] Callas, J. ; Donnerhacke, L. ; Finney, H. ; Thayer, R.: OpenPGP Message
Format. In: IETF Request For Comments 2440 (1998), November
[14] Camphausen, I. ; Petersen, H. ; Stark, C.: Root CA Zertifikatswechsel Secorvo
White Paper. (2002), September
[15] Chokhani, S. ; Ford, W. ; Sabett, R. ; Merrill, C. ; Wu, S.: Internet X.509
Public Key Infrastructure - Certificate Policy and Certification Practices Framework.
In: IETF Request For Comments 3647 (2003), November
[16] Davis, D.: Defective Sign & Encrypt in S/MIME, PKCS# 7, MOSS, PEM, PGP,
and XML. In: Proc. 2001 USENIX Technical Conference (2001), S. 65–78
[17] Dubuisson, Olivier: ASN.1 - Communication between Heterogeneous Systems. Morgan
Kaufmann, 2000
[18] Dusse, S. ; Hoffman, P. ; Ramsdell, B. ; Weinstein, J.: S/MIME Version 2
Certificate Handling. In: IETF Request For Comments 2312 (1998), March
[19] Eckert, C.: IT-Sicherheit, Konzepte - Verfahren - Protokolle, Kapitel 9.1.3. 3.
Oldenbourg Wissenschaftsverlag GmbH, 2004
[20] Eckstein, R. ; Casabianca, M.: XML Pocket Reference. Second Edition. O’Reilly,
2001 (ISBN:0596001339)
[21] Group, XML Schema W.: XML Schema. http://www.w3.org/2001/XMLSchema
(letzter Zugriff 18.07.2007), October 2004
[22] Gutmann, P.: Plug-and-Play PKI: A PKI your Mother Can Use. In: Proceedings of
the 12th USENIX Security Symposium, 2003, S. 45–58
[23] Hallam-Baker, Phillip ; Mysore, Shivaram H.: XML Key Management Specification
Version 2.0 (XKMS 2.0). http://www.w3.org/TR/2005/REC-xkms2-20050628/
(letzter Zugriff 18.07.2007), 06 2005
[24] Housley, R.: Cryptographic Message Syntax. In: IETF Request For Comments 2630
(1999), June
[25] Housley, R. ; Polk, W. ; Ford, W. ; Solo, D.: Internet X.509 Public Key Infrastructure
Certificate and Certificate Revocation List Profile. In: IETF Request For
Comments 3280 (2002), April
[26] ITU: The Directory: Public-key and attribute certificate frameworks / International
Telecommunication Union - TELECOMMUNICATION STANDARDIZATION
SECTOR. 2005. – Forschungsbericht
[27] Karatsiolis, V. ; Lippert, M. ; Wiesmaier, A.: Using LDAP Directories for Management
of PKI Processes. In: Proceedings of Public Key Infrastructure: First European
PKI Workshop: Research and Applications, EuroPKI 2004 Bd. 3093, 2004, S. 126–134
74

Literaturverzeichnis
[28] Karatsiolis, V. ; Lippert, M. ; Wiesmaier, A. ; Pitaev, A. ; Ruppert, M. ;
Buchmann, J.: Towards a Flexible Intra-Trustcenter Management Protocol. In: The
Third International Workshop for Applied PKI, IWAP 2004, 2004
[29] Karatsiolis, Vangelis: Flexible Certificate Management in Public Key Infrastructures.
2007
[30] Kille, S.: A String Representation of Distinguished Names. In: IETF Request For
Comments 1779 (1995), March. http://www.ietf.org/rfc/rfc1779.txt
[31] Kunz, T. (Hrsg.) ; Okunick, S. (Hrsg.) ; Viebeg, U. (Hrsg.): Long-term security
for signed documents: services, protocols, and data structures. 2006
[32] Larmouth, J.: ASN.1 Complete. Open Systems Solutions, 1999
[33] Laue, Ralf ; Huss, Sorin A.: Perfomanter Krypto-CoProzessor für unterschiedliche
Verfahren. In: Stamer, Heiko (Hrsg.): 5. Krypto-Tag - Workshop über Kryptographie.
Universität Kassel, 2006 (Mathematische Schriften Kassel 06), S. 3. – (in German)
[34] McLaughlin, Brett: Java & XML. Second Edition. O’Reilly, 2001 (ISBN: 0-596-
00197-5)
[35] Myers, M. ; Adams, C. ; Solo, D. ; Kemp, D.: Internet X.509 Certificate Request
Message Format. In: IETF Request For Comments 2511 (1999), March.
http://www.ietf.org/rfc/rfc2511.txt
[36] Myers, M. ; Ankney, R. ; Malpani, A. ; Galperin, S. ; Adams, C.: X.509 Internet
Public Key Infrastructure Online Certificate Status Protocol. In: IETF Request For
Comments 2560 (1999), June. http://www.ietf.org/rfc/rfc2560.txt
[37] Myers, M. ; Liu, X. ; Schaad, J. ; Weinstein, J.: Certificate Management
Messages over CMS. In: IETF Request For Comments 2797 (2000), April.
http://www.ietf.org/rfc/rfc2797.txt
[38] Park, Namje ; Moon, Kiyoung ; Sohn, Sungwon: Certificate validation service
using XKMS for computational grid. In: XMLSEC ’03: Proceedings of the 2003 ACM
workshop on XML security. New York, NY, USA : ACM Press, 2003. – ISBN 1–
58113–777–X, S. 112–120
[39] RSA, Laboratories: PKCS#7 v1.5: Cryptographic Message Syntax Standard.
http://www.rsasecurity.com/rsalabs/pkcs/ (letzter Zugriff 18.07.2007), November
1993
[40] RSA, Laboratories: PKCS#12 v1.0: Personal Information Exchange Syntax Standard.
http://www.rsasecurity.com/rsalabs/node.asp?id=2138 (letzter Zugriff
18.07.2007), June 1999
[41] RSA, Laboratories: PKCS#10 v1.7: Certification Request Syntax Standard.
http://www.rsasecurity.com/rsalabs/pkcs/ (letzter Zugriff 18.07.2007), May
2000
75

Literaturverzeichnis
[42] Schaad, J.: Internet X.509 Public Key Infrastructure Certificate Request Message
Format (CRMF). In: IETF Request For Comments 4211 (2005), September.
http://www.ietf.org/rfc/rfc4211.txt
[43] Scheibelhofer, Karl: What You See Is What You Sign - Trustworthy Display of
XML Documents for Signing and Verification. In: Proceedings of the IFIP TC6/TC11
International Conference on Communications and Multimedia Security Issues of the
New Century. Deventer, The Netherlands, The Netherlands : Kluwer, B.V., 2001. –
ISBN 0–7923–7365–0, S. 35
[44] Sun Microsystems, Inc.: JavaTM Cryptography Extension (JCE) Reference
Guide for the Java (TM) 2 Platform Standard Edition Development Kit (JDK) 5.0.
http://java.sun.com/j2se/1.5.0/docs/guide/security/jce/JCERefGuide.html
(letzter Zugriff 18.07.2007), 01 2004
[45] Technische Universität Darmstadt, Theoretische Informatik Kryptographie
und C.: FlexiTRUST - A flexible and secure Truscenter application.
http://www.cdc.informatik.tu-darmstadt.de/research/pki.html (letzter Zugriff
18.07.2007),
[46] Wahl, M. ; Kille, S. ; Howes, T.: Lightweight Directory Access Protocol (v3): UTF-
8 String Representation of Distinguished Names. In: IETF Request For Comments
2253 (1997), December
[47] Wiesmaier, A. ; Lippert, M. ; Karatsiolis, V.: The Key Authority – Secure
Key Management in Hierarchical Public Key Infrastructures. In: Proceedings of the
International Conference on Security and Management, SAM ’04, 2004, S. 89–93
76