Aspekte der Cross-Zertifizierung

Von Volker Hammer und Holger Petersen, Secorvo Security Consulting

Gegenwärtig werden Public-Key-Infrastrukturen in Insellösungen (einzelnen Domains) aufgebaut und in ersten produktiven Anwendungen eingesetzt. Es ist aber absehbar, dass der Aufwand zur Zertifizierung und Zertifikatverwaltung zu hoch ist, um immer alle möglichen Teilnehmer und Partner einer Domain innerhalb dieser Domain selbst zu zertifizieren. Vielmehr versprechen Verknüpfungen der "Inseln" mithilfe von Cross-Zertifikaten erhebliche Synergieeffekte und dementsprechend einen höheren Business-Value für die PKI-Anwendungen. Vor einer Cross-Zertifizierung ist jedoch die Frage zu beantworten, ob das Vertrauen, das mit Cross-Zertifikaten ausgesprochen wird, auch domainübergreifend gerechtfertigt ist. Dieser Beitrag betrachtet die genannten Aspekte aus der Perspektive digitaler Signaturen. Eine Übertragung für andere Nutzungszwecke von PKI, zum Beispiel für Verschlüsselung, ist allerdings ohne wesentliche Änderungen möglich.

Best Papers Award

Der vorliegende Beitrag zu Aspekten der Crosszertifizierung errang auf dem 7. Deutschen IT-Sicherheitskongress des BSI den zweiten Platz der Best Paper Awards (vgl. BSI-Forum 2001/3, S. 30). Die ausgezeichneten Beiträge sind Im Tagungsband erschienen und werden im BSI-Forum nachgedruckt.

1 Einleitung

Cross-Zertifikate werden im Standard X.509 definiert und in PKIX sowie einigen Internet Drafts angesprochen [1, 2, 12]. Zum besseren Verständnis werden zunächst die Eigenschaften von Cross-Zertifikaten und ihre Verwendungsmöglichkeiten dargestellt.

1.1 Cross-Zertifikate und andere Zertifikat-Typen

Durch die Ausstellung von Zertifikaten entstehen mehrere Relationen zwischen den Ausstellern und Inhabern der Zertifikate. Zum Verständnis von Cross-Zertifikaten sind vor allem zwei dieser Relationen relevant:

• Die Zertifizierungsinstanz-Relation: "Issuer zertifiziert Subject". Die in der Menge der Zertifikate enthaltenen Paare (issuer dn, subject dn) bestimmen einen Graphen. In klassischen Zertifizierungshierarchien bildet dieser einen Baum. Dieser Relation liegt in der Regel die Vorstellung der rechtlich-organisatorischen Zuständigkeiten zugrunde.
• Die Zertifizierungsrelation: "Schlüssel X wird zum Prüfen des Zertifikats Y" benötigt. Im entsprechenden Graphen wird erkennbar, ob eine Zertifizierungsinstanz mit wechselnden Schlüsseln Zertifikate für ein Schlüsselpaar eines nachgeordneten Inhaber ausstellt.

Cross-Zertifikate beeinflussen die Struktur beider Graphen. Öffentliche Schlüssel können – wie der Name sagt – als öffentliche Informationen verwendet werden. Sie können daher in mehr als einem Zertifikat bestätigt werden. Ist dies der Fall, kann allgemein von Mehrfachzertifikaten für einen öffentlichen Schlüssel gesprochen werden [3, 4]. Beispiele für Mehrfachzertifikate sind:

• Verlängerungszertifikate: Es unterscheiden sich nur Gültigkeitszeitraum, Seriennummer und Signatur.
• Austauschzertifikate: issuer dn, subject dn und bestätigter öffentlicher Schlüssel sind gleich, aber alle anderen Attributwerte können sich ändern.
• Cross-Zertifikate: Ein öffentlicher Schlüssel wird bereits durch eine Zertifizierungsinstanz bestätigt (primäre Zertifizierungsrelation). Zu diesem öffentlichen Schlüssel stellt eine Zertifizierungsinstanz mit anderem issuer dn als das der primären Zertifizierungsinstanz ein weiteres Zertifikat, ein Cross-Zertifikat, aus (diese Definition ist enger als in X.509). Der Sonderfall, dass die primäre Zertifizierungsinstanz ihren Namen wechselt und daraufhin neu zertifiziert, wird eingeschlossen.

Während mit Verlängerungszertifikaten und Austauschzertifikaten eine bestehende Baumstruktur der Zertifizierungsinstanz-Relation erhalten bleibt, entstehen mit Cross-Zertifikaten beliebige Graphen für diese Relation. Cross-Zertifikate liegen nach dieser Definition vor, wenn mehr als ein issuer dn einen subject dn zertifiziert.

Cross-Zertifikate (auch Mehrfachzertifikate im Allgemeinen) können vom Schlüsselinhaber nicht verhindert werden, da der öffentliche Schlüssel jedem zugänglich ist und deshalb von jedem ein Zertifikat ausgestellt werden kann, das diesen Schlüssel enthält.

1.2 Verwendungsmöglichkeiten für Cross-Zertifikate

Cross-Zertifikate haben zwei vorrangige Verwendungszwecke: Verknüpfung von Zertifizierungshierarchien und Verkürzungen von Zertifikatketten. Der geläufigste Zweck ist die Verknüpfung von Zertifizierungshierarchien, insbesondere auf der Ebene der Wurzel-Zertifizierungsinstanzen. Die beiden Root-CAs können sich gegenseitig Zertifikate ausstellen. Dieser Fall wird im Weiteren auch als Verknüpfung von Domänen bezeichnet.

Nach der obigen Definition liegt aber auch ein (einseitiges) Cross-Zertifikat vor, wenn nur eine Root die Wurzel-Zertifizierungsinstanz einer anderen Zertifizierungshierarchie bestätigt, wenn diese bereits über ein Selbstzertifikat verfügt.

Schließlich können sich auch nachgeordnete Zertifizierungsinstanzen unterschiedlicher Domänen cross-zertifizieren. Mit Cross-Zertifikaten können sowohl innerhalb einer Zertifizierungshierarchie als auch zwischen Zertifizierungshierarchien zusätzliche "Wege" erzeugt werden. Die entstehenden "Querverbindungen" können zu kürzeren Zertifikatketten für Signaturprüfungen führen [1, Kap. 18.2.1].

2 Aufbau, Erzeugung und Bereitstellung von Cross-Zertifikaten

Cross-Zertifikate sind nach X.509 "Standard"-Zertifikate. Sie können allerdings bestimmte Extensions enthalten, um ihre Verwendung zu steuern:

• policyMappings: als SEQUENCE OF {issuerDomainPolicy, subjectDomainPolicy}. Semantik: Der Issuer des Cross-Zertifikat erklärt, dass die issuerDomainPolicy äquivalent zur subjectDomainPolicy ist.
• policyConstraints: steuern, ob und ab welcher Position in der zu prüfenden Zertifikatkette Policies ausgewiesen sein müssen (Attribut requireExplicitPolicy) und ob die Policies direkt bekannt sein müssen oder ob eine Referenz über policyMapping ausreichend ist (Attribut inhibitPolicyMapping). Mit inhibitAnyPolicy kann außerdem der Wert "anyPolicy" für Policy Identifier unterbunden werden.
• nameConstraints: kann zur Einschränkung der Namen verwendet werden, die von der zertifizierten CA verwendet werden dürfen (im Sinne von Cross-Zertifikaten: für die das Cross-Zertifikat Gültigkeit hat).

Weitere Attribute können für den Einsatz von Cross-Zertifikaten hilfreich sein, zum Beispiel pathLenConstraints. Im allgemeinen Fall kann aber nicht davon ausgegangen werden, dass ein Cross-Zertifikat von einem "normalen Hierarchie-Zertifikat" unterschieden werden kann. Die genannten Attribute können auch in normalen Zertifikaten enthalten sein oder in Cross-Zertifikaten fehlen.

Da nach der hier verwendeten Terminologie Cross-Zertifikate nur für bereits existierende Schlüsselpaare ausgestellt werden, kommen für die Erzeugung nur Lösungen in Frage, die auf einer Übertragung des öffentlichen Schlüssels an die CA beruhen. Es können beispielsweise Zertifikat-Management-Protokolle nach PKIX (CMP, CMC) oder PKCS#10 / PKCS#7 verwendet werden.

Cross-Zertifikate können über Directories bereitgestellt oder direkt in Nachrichten mit versandt werden. Im Directory ist in Einträgen von Zertifizierungsinstanzen (jetzt Object Class pkiCA, [1, Kap. 11.1.2]) ein Attributtyp crossCertificatePair vorgesehen. Dieser kann Vorwärts- und ein Rückwärts-Cross-Zertifikat (von bzw. für eine cross-zertifizierte Zertifizierungsinstanz) enthalten. Im Directory können daher beide CA-Einträge jeweils beide Zertifikate enthalten.

3 Aspekte beim Ausstellen von Cross-Zertifikaten

Die Informationen in Zertifikaten sind insbesondere unter dem Blickwinkel des Sicherheitsniveaus zu betrachten, unter dem die Zertifizierungshierarchie betrieben wird. Dabei können in einer Zertifizierungshierarchie durchaus unterschiedliche Sicherheitsklassen definiert sein, die durch Policy-Angaben unterschieden werden. Die Menge der Sicherheitsklassen einer Zertifizierungshierarchie und die Regeln für ihre Verwendung wird im Folgenden als Domain-Policy bezeichnet.

An dieser Stelle wird angenommen, dass für zwei Zertifizierungs(teil-)hierarchien, für die eine Cross-Zertifizierung geplant ist, jeweils eine Domain-Policy definiert ist. Außerdem wird angenommen, dass die Teilnehmer einer Zertifizierungshierarchie (Zertifikatinhaber und Empfänger von Zertifikaten) über Clients verfügen, die die jeweilige Domain-Policy beherrschen.

3.1 Notwendigkeit von Cross-Zertifikaten

Alternativ zum Einsatz von Cross-Zertifikaten mit Angaben zum Policy Mapping könnten übergeordnete Roots für bestimmte Sicherheitsklassen gebildet werden. Dies entspricht dem PEM-Modell von Policy-CAs. Möglicherweise ist dies der pragmatischere und anwenderfreundlichere Ansatz. Als weitere Alternative kann der Anwender in seiner Prüffunktion mehrere unabhängige Wurzelzertifikate als Sicherungsanker aufnehmen.

Die Wahl zwischen diesen drei Verknüpfungsmöglichkeiten von Zertifizierungshierarchien oder ihre geschickte Kombination unterliegt vielen Einflussfaktoren. Dazu gehören Kosten- und Nutzengesichtspunkte, "politische" Fragen (z. B. Branding), Sicherheitsaspekte, Anforderungen an und technische Realisierbarkeit von Gültigkeitsmodellen und schließlich die Beherrschbarkeit für die Teilnehmer. So können Teilnehmer beim Akzeptieren unabhängiger Root-Zertifikate die akzeptierte Zertifikatmenge nach Hierarchien kontrollieren. Der Preis dafür ist allerdings, dass sie Wurzelzertifikate manuell prüfen und das jeweilige Certification Practice Statement (CPS) selbst bewerten müssen. Im Falle von Cross-Zertifikaten übernimmt dies ihre Root für sie. Ob dadurch allerdings das Verständnis der entstehenden Zertifizierungsgraphen für die Teilnehmer und ihr Vertrauen in die PKI erhöht wird, muss sich erst zeigen.

3.2 Interdomain-Vertrauen

Eine der technischen Umsetzung vorgelagerte Fragestellung ist, inwieweit die Teilnehmer Interdomain-Cross-Zertifikaten vertrauen müssen. Schließlich könnte der Teilnehmer zum Zeitpunkt seines Eintritts in eine PKI annehmen, dass er sich mit der Anerkennung des Wurzelzertifikats "seiner" PKI auch nur in deren Domain bewegt und Zertifikate anderer Domains ausgeschlossen sind. Grundsätzlich können hier zwei Positionen bezogen werden:

• Nach der einen Position delegiert der Teilnehmer Vertrauen weitgehend: Da der Teilnehmer einer bestimmten Vertrauens-Domäne beitritt und die Policy der Wurzel-Zertifizierungsinstanz anerkennt, muss er auch akzeptieren, dass die Zertifizierungsinstanzen Interdomain-Cross-Zertifikate ausstellen, wenn sie sich an die Policy halten und hinreichende Policy-Äquivalenz zwischen den Domains sicherstellen.
• Nach der zweiten Position will der Teilnehmer die Vertrauensgewährung selbst kontrollieren. In diesem Fall würde er die Cross-Zertifizierung nicht unbesehen akzeptieren, sondern unter den Vorbehalt einer expliziten Anerkennung der anderen Domain stellen, sich gegebenenfalls sogar eine Entscheidung für einzelne Teilnehmerzertifikate vorbehalten.

Da eine explizite Kennzeichnung von Cross-Zertifikaten nach dem Standard nicht vorgesehen ist, müsste zur Unterstützung des zweiten Falles ein spezifische Regelung innerhalb der Teilnehmer-Domain festgelegt werden. Diese wäre bei der Zertifizierung von den Zertifizierungsinstanzen zu beachten und müsste von den Clients der Teilnehmer unterstützt werden. Es könnte allerdings auf Standard-Extensions zurückgegriffen werden.

3.3 Gleichheit von Certificate Policies

In einem Zertifikat können über sogenannte Policy-OIDs Informationen zum Sicherheitsniveau oder Hinweise zur Eignung ausgedrückt werden (Certificate Policies). Certificate Policies adressieren dazu eine Fülle von Parametern und informieren über Zusicherungen, Begrenzungen und Servicequalitäten für das ausgestellte Zertifikat.

Für das Erbringen der zugesicherten Eigenschaften besteht in vielen Fällen eine Reihe von Alternativen. Die in einer PKI ausgewählten Varianten werden zum Beispiel in einem CPS beschrieben. Aus praktischen Gründen abstrahieren Certificate Policies jedoch von vielen Details eines Certification Practice Statement. Doch die CPS zweier Domains können sich auch in ihrem Detaillierungsgrad unterscheiden. Außerdem zeigt sich, dass es in jeder PKI eine Menge Trust Level geben kann, die gegebenenfalls erst im Laufe der Zeit durch graduelle Veränderungen entstehen.

Abb. 2: Bereits Standard-Parameter von Policies weisen häufig Unterschiede auf.

Technisch wird in X.509 spezifiziert, wie in (Cross-)Zertifikaten zu definieren ist, dass bestimmte Certificate Policies äquivalent seien (policyMapping, [1, Kap. 18.2.1.]). Für das Policy-Mapping in Cross-Zertifikaten ergeben sich zwei Problembereiche:

• Selbst bei sehr einfachen und klaren Modellen wird es vermutlich keine zwei exakt gleichen Certificate Policies in unterschiedlichen Domänen geben. Damit stellt sich die Frage, ob Policy-Mapping überhaupt verwendet werden kann oder den Anwender unter Umständen in trügerischer Sicherheit wiegt.
• Selbst wenn für Certificate Policies die gleichen Aussagen getroffen werden, stellt sich die Frage, ob sie als äquivalent anzusehen sind, wenn sich die dahinter liegenden CPS unterscheiden.

Für den praktischen Einsatz von Policy-Mapping werden deshalb Regeln benötigt. Sie müssen bestimmen, welche Parameter in welchen Toleranzen übereinstimmen müssen, damit

• Policy Mapping überhaupt beim Zertifizieren genutzt werden kann und
• die Mapping-Aussage(n) in verschiedenen Anwendungen von Prüfenden sinnvoll verwendet werden kann.

Für eine Interdomain-Cross-Zertifizierung wird es deshalb regelmäßig erforderlich sein, einen umfangreicheren Zertifizierungsprozess aufzusetzen. In dessen Verlauf sind eine Vielzahl von Prüfungen und Abstimmungen vorzunehmen [8]. Dadurch ist die hinreichende Äquivalenz von Policy-Elementen sicherzustellen, zum Beispiel der Identifikation und Authentifikation von Schlüsselinhabern, der zulässigen Schlüsselträger, den geforderten Schlüssellängen, der maximalen Gültigkeitsdauer von Zertifikaten, des Verfahrens der Auslieferung von Schlüsselträger und PIN, der Sicherungsmaßnahmen für die CAs, RAs oder anderen Stellen, der Abläufe und Zusicherungen bei Störfällen und für Sperrungen, und Haftungsfragen. Wird eine hinreichende Äquivalenz der Eigenschaften erreicht, sind die Mapping-Regeln für Policy-OIDs festzulegen und in die Cross-Zertifikate aufzunehmen.

Da Certification Practice Statements im Allgemeinen nicht statisch sind, stellt sich außerdem die Frage, welche Konsequenzen sich bei Veränderungen von CPS, Certificate Policies und Domain Policies für das Cross-Zertifikat ergeben. Es ist daher zu erwarten, dass die Verbindung zwischen unterschiedlichen Domains kontinuierlich beobachtet und gepflegt werden muss.

Mit der X.509-Konstruktion wird immer die gesamte Policy auf eine andere Policy abgebildet. Eine Alternative bestünde darin, einzelne Policy-Elemente mit einem Wert anzugeben. In der Prüffunktion könnte dann eine differenzierte Bewertung der einzelnen Elemente vorgenommen werden. Ob dies zu einem einfacheren Vergleich von Policies unterschiedlicher Zertifizierungsinstanz führt, hängt sehr von der Zahl der als relevant erachteten Parameter ab. Im Prinzip können alle Aspekte angesprochen werden, beispielsweise im Detaillierungsgrad von RFC 2527 [5]. In X.509 wird eine solche parameterbasierte Variante bisher nicht unterstützt. Ein Vorschlag für XML findet sich in [6].

3.4 Transitive Cross-Zertifizierung

Spezielle Probleme treten auf, wenn in einer Zertifikatkette mehrere Cross-Zertifikate enthalten sind. Durch Crosszertifikate können

• mehrere Zertifizierungshierarchien miteinander verknüpft werden. Hier stellt sich die Frage, wie die entsprechenden Mapping-Regeln vom Client berücksichtigt werden sollen. Muss die cross-zertifizierende CA grundsätzlich mit inhibitPolicyMapping festlegen, dass nach dem von ihr ausgestellten Cross-Zertifikat keine weitere Mapping-Regeln mehr akzeptiert werden dürfen?
• Zertifizierungshierarchien "rückverknüpft" sein, wenn eine nachgeordnete CA einer cross-zertifizierten Zertifizierungshierarchie wiederum ein Cross-Zertifikat für die erste Zertifizierungshierarchie ausstellt (zum Beispiel Pfad 11a, 6, 7, 16a in Abb. 1). Hier fragt sich, ob solche "Rückverknüpfungen" bei der Prüfung einer Zertifikatkette verwendet werden dürfen?

Abb. 1: Graph einer Zertifizierungsinstanz-Relation. Cross-Zertifikate haben Kantennummern ≥1 (die Kantennummern werden in den weiteren Beispielen verwendet).

Die Begrenzung der Pfadlänge über die basicConstraints hilft nur bedingt in einfachen Fällen. nameConstraints oder inhibitPolicyMapping nutzen nur etwas, wenn die anderen Zertifizierungshierarchien andere Namensräume oder andere Policy-OIDs verwenden.

4 Konsequenzen für das Gültigkeitsmodell

Da die bisher genannten Attribute in Zertifikatketten mit Cross-Zertifikaten auftreten können, müssen sie von Prüffunktionen beherrscht werden. Im Folgenden werden Aspekte angesprochen, die über normale Gültigkeitsprüfungen hinausgehen. Dabei müssen zwei spezielle Aufgaben gelöst werden: Zum einen ist die zur Prüfung zu verwendende Zertifikatkette zu bestimmen. Dies kann aus der Sicht des Signierenden wie auch des Prüfenden erfolgen. Zum zweiten muss der "Policy-Wert" des Prüfergebnisses festgestellt werden.

Da beim Vorliegen von Cross-Zertifikaten mehrere Zertifikate den gleichen öffentlichen Schlüssel bestätigen, können unterschiedliche Zertifikatketten geprüft werden. Will Tln1 in Abb. 1 ausgehend von Root A das Zertifikat von Tln2 prüfen, kann er unterschiedlichen Pfaden folgen (vgl. Abb. 3). In einem allgemeinen Zertifizierungsgraphen sind mehrere Wege zwischen einer Wurzel und einem Teilnehmerzertifikat möglich. Der Austausch von Zertifikaten in einer Zertifikatkette kann allerdings zu unterschiedlichen Prüfergebnissen führen. Daher müssen Regeln definiert sein, nach denen die "richtige" Zertifikatkette ausgewählt wird. Die Entscheidung hierüber kann dem Signierenden wie auch dem Prüfenden obliegen.

Abb. 3: Ausschnitt des Zertifizierungsgraphen aus Abb. 1 für die Prüfung von Tln2 durch Tln1 – Ausgehend von Root A sind z. B. der Pfad 11a, 6, 7, 9, der Pfad 15, 7, 9, oder der Pfad 2, 17, 16b, 9 geeignet.

4.1 Bestimmen der Zertifikatkette durch den Signierenden

Soll sichergestellt werden, dass alle Prüfenden zum gleichen Ergebnis kommen, wie dies beispielsweise im Kontext des SigG gefordert ist, kann in jedem digital signierten Dokument ein Verweis auf das Zertifikat angegeben werden, das zum Prüfen zu verwenden ist. Dies kann erreicht werden, indem der Signierende zum digital signierten Dokument ein Attribut wie authorityKeyIdentifier nach [1, Kap. 8.2.2.1] mit den Angaben für Subject und Serialnumber des Zertifikats der ausstellenden Zertifizierungsinstanz hinzufügt. Die Prüffunktion würde dann genau die durch die Referenzen identifizierten Zertifikate für die Prüfung heranziehen. Für Anwendungen, die einen hohen Beweiswert erbringen sollen, ist dieses Variante dringend zu empfehlen.

Wenn Zertifikate beim Prüfprozess nicht ausgetauscht werden dürfen, stellt sich allerdings das Problem, welche Zertifikate der Signierende einschließen muss, um die durch Cross-Zertifikate möglichen alternativen Zertifikatketten auch für den Prüfenden zuzulassen. Nach der Schnittstellenspezifikation des BSI (SigI, [7]) wird in jedem digital signierten Dokument, auch in Zertifikaten, jeweils auf das zum Prüfen zu verwendende Zertifikat verwiesen.

In diesem Fall bilden die Verweise auf das jeweils übergeordnete Zertifikat wiederum eine eigene Relation, die Zertifikat-Relation. Betrachtet man den Graphen in Abb. 3, hat der Tln2 nur ein Zertifikat (9). Nach den Regeln von SigI muss die Zertifizierungsinstanz im Teilnehmerzertifikat auf eines ihrer eigenen Zertifikate verweisen. Wenn nur das jeweils übergeordnete Zertifikat referenziert wird, definiert also die Zertifizierungsinstanz H1, welche der Zertifikatketten weiter zu verfolgen ist. Beschränkt sich jede Zertifizierungsinstanz auf die Angabe eines übergeordneten Zertifikats, entsteht mit der Zertifikat-Relation wieder ein baumartiger Graph (vgl. Abb. 4). Die Pfade in diesem Graphen sind für die Prüffunktion eindeutig, wenn sie den Verweisen folgt, die in den Zertifikaten enthalten sind. Allerdings wird der für die Prüfung zulässige Pfad durch die Zertifizierungsinstanzen bestimmt. Aus der Sicht des Teilnehmers wird die Festlegung des Pfades mit der Ausstellung seines Zertifikats getroffen.

Alternativ könnte der Signierende nicht nur das Teilnehmerzertifikat, sondern den gesamten Pfad (oder mehrere alternative Pfade) über entsprechende Verweisungen im digital signierten Dokument festlegen. In diesem Fall würden die Zertifikatketten, die zum Prüfen zu verwenden sind, erst zum Signaturzeitpunkt festgelegt. Sie würden außerdem vollständig vom Signierenden definiert. Dadurch entsteht für ihn einerseits eine größere Flexibilität, aber möglicherweise auch eine höhere Komplexität in der Anwendung von digitalen Signaturen.

4.2 Bestimmen der Zertifikatkette durch den Prüfenden

Für diese Variante nehmen wir an, dass dem prüfenden Teilnehmer eine Menge von Zertifikaten zur Verfügung steht. Die Zertifikate einer ausgewählten Teilmenge genießen als Wurzelzertifikate direktes Vertrauen. Der Prüfende muss nun eine oder mehrere Zertifikatketten bestimmen, die er zum Prüfen eines digital signierten Dokuments verwenden will. Dazu kann er versuchen, den allgemeinen Zertifizierungsgraphen zu reduzieren [11]. Welche Bedingungen dazu während des Traversierens des entstehenden Graphen herangezogen werden, hängt von den jeweils unterstützten Zertifikat-Attributen und dem Anwendungszweck ab.

• Zunächst werden die Zertifikate bestimmt, die in der transitiven Hülle der Wurzelzertifikate liegen. Außerdem werden alle abgelaufenen Zertifikate, alle Zertifikate mit dem Status revoked oder suspended und solche, zu denen keine Statusinformation verfügbar ist, aus der Menge zulässiger Zertifikate entfernt.
• Es werden nur Zertifikate akzeptiert, die folgenden Bedingungen genügen: Das Zertifikat zum ausstellenden Schlüssel ist ein Zertifikat für die Zertifizierung (keyUsage = keyCertSign oder basicConstraints.cA = true) und die pathLenConstraint aller in der Kette enthaltenen Zertifikate wird eingehalten.
• In allgemeinen Zertifizierungsgraphen können Zyklen auftreten. Taucht ein Zertifikat in einer Kette zum zweiten Mal auf, kann die Traversierung für diese Kette abgebrochen werden. Alternativ kann durch Längenbegrenzungen sichergestellt werden, dass die Traversierung terminiert. Gegebenenfalls liefert auch die Bedingung, dass ein nachgeordnetes Zertifikat nach dem notBefore des Zertifikats zum bestätigenden Schlüssel ausgestellt sein muss, ein Abbruchkritierium.
• Es könnten Zertifikatketten entweder nur mit lokal akzeptierten (bereits bekannten) Policies oder oberhalb einer geforderten Mindest-Policy oder ohne Policy-Mapping ausgewählt werden.
• Sofern nach Anwendung der bisherigen Kriterien noch alternative Zertifikatketten für die Prüfung eines digital signierten Dokuments geeignet sind, kann zum Beispiel durch Entscheidung des Prüfenden oder automatisch eine der folgenden Ketten gewählt werden: Entweder die mit der minimale Länge, der maximalen Policy, die ohne Policy Mapping oder die mit den "günstigsten" Naming-Constraints.

Die Ergebnisse einer Analyse können teilweise wiederverwendet und kontinuierlich fortgeschrieben werden. Dadurch sollte sich der Aufwand für die Auswahl von Zertifikatketten in vertretbarem Rahmen halten.

4.3 Feststellen der Pfad-Policies

Die eigentliche Prüfung setzt auf der oder den ausgewählten Zertifikatketten auf. Im Rahmen der Prüfung einer Zertifikatkette wird eine Gesamt-Policy für die Kette bestimmt. Durch alternative Zertifikatketten können sich unterschiedliche Gesamt-Policies ergeben. Für das Gültigkeitsmodell muss daher entschieden werden,

• ob alternative Gesamt-Policies zu bestimmen sind,
• welche der alternativen Gesamt-Policies für das Prüfergebnis berücksichtigt wird, also beispielsweise die minimale oder die maximale, oder
• ob so lange geprüft wird, bis eine Zertifikatkette gefunden wird, die eine der initial geforderten (Mindest-)Policies erreicht.

  Im Gültigkeitsmodell muss außerdem geprüft werden, auf welchem Niveau Mapping-Regeln angegeben werden. Beispielsweise muss erkannt werden, wenn eine CA mit einer "niedrigen" Policy ein weiteres CA-Zertifikat ausstellt, in dem ein Mapping auf ein höheres Sicherheitsniveau festgelegt wird.

Policy-Mapping und policyConstraints sind insofern dynamisch, dass sie mit Sperrungen oder ausgelaufenen Zertifikaten nicht mehr als Regeln gelten. Prüffunktionen dürfen diese Regeln daher nicht dauerhaft speichern, sondern müssen sich in Abhängigkeit von der jeweils verwendeten Zertifikatkette über ihre Anwendbarkeit vergewissern.

5 Implikationen für Sperrungen

Cross-Zertifikate können, wie andere Zertifikate auch, gesperrt werden. Die Seriennummer des gesperrten Cross-Zertifikats ist dann in CRLs wie auch in ARLs aufzunehmen, bis die Gültigkeit des Cross-Zertifikats ausgelaufen ist. Diese Möglichkeit ist ein wesentlicher Vorteil gegenüber der direkten Anerkennung der Root (oder einer CA) einer anderen Domain durch den Teilnehmer. Im letzteren Fall muss er nämlich nicht nur die Informationen seiner primären Domain, sondern auch die der anderen daraufhin verfolgen, ob ein Störfall für den Root-Schlüssel vorliegt und dieser zurückgerufen wurde. Im Falle von Cross-Zertifikaten sollte diese Beobachtung eine Leistung der primären Domain sein, die gegebenenfalls zu einem Rückruf des Cross-Zertifikats führt. Aus der Sicht des Teilnehmers wird die Situation dann vom Client automatisch behandelt. Wie bereits erwähnt, müssen unter anderem wegen der Möglichkeit des Rückrufs die Zertifikatkette und ihre Policy während der Gültigkeitsprüfung jeweils neu bestimmt oder zumindest überprüft werden. Durch Cross-Zertifikate müssen darüber hinaus weitere Situationen berücksichtigt werden.

In strikten Baum-Hierarchien ist es möglich, durch die Sperrung eines übergeordneten Zertifikats die gesamte Teilhierarchie implizit mitzusperren. Dies ist insbesondere als Reaktion auf Schlüsselkompromittierung eines Zertifizierungsinstanz-Schlüssels sinnvoll. Mit Cross-Zertifikaten existieren jedoch mehrere Zertifikate für ein Schlüsselpaar. Daraus ergeben sich im Falle einer Sperrung Probleme:

• Teilnehmer oder zur Sperrung berechtigte Stellen müssen entscheiden, ob sie das Schlüsselpaar für alle Anwendungen sperren oder ob sie lediglich ein einzelnes Zertifikat sperren lassen wollen, beispielsweise weil sie eine Bankverbindung aufgegeben haben. Im ersten Fall muss ihre Zertifikatverwaltung (oder ein Service Provider) eine Übersicht über die existierenden Zertifikate zu einem Schlüssel haben.
• Für Zertifikate von Zertifizierungsinstanzen kann es je nach Struktur des Zertifizierungsgraphen Umwege um gesperrte Knoten herum geben. Soll ein Teilgraph eines Zertifizierungsgraphen gesperrt werden, beispielsweise weil in einer Zertifizierungsinstanz (ZI) schwerwiegende Unregelmäßigkeiten aufgetreten sind (sei in der ZI "G1" "compromised"), müsste der Graph bezüglich des Sperrziels analysiert werden. Dazu ist es entweder erforderlich, dass einer geeigneten Stelle die Informationen über alle Zertifizierungsrelationen zur Verfügung stehen und sie die notwendigen Sperrungen veranlasst. Alternativ könnten alle Zertifizierungsinstanzen des Graphen geeignet informiert werden und ihrerseits die Zertifikate sperren, die sie für Zertifizierungsinstanz G1 ausgestellt haben.
• Für die Sperrung von Zertifizierungsinstanz-Zertifikaten werden ferner Regeln benötigt, wie weit die Sperrung transitiv weitergegeben werden muss, also welche der ZI "G1" im Graphen nachgeordneten Zertifikate ebenfalls zu sperren sind. Zum Beispiel könnte es bei Schwachstellen in der Schlüsselgenerierung notwendig sein, auch alle weiteren Zertifikate für die von ZI "G1" erzeugten Schüssel zu sperren, während im Fall von Schlüsseln die von einer nachgeordneten Zertifizierungsinstanz oder den Teilnehmern selbst erzeugt wurden, nur die von ZI "G1" ausgestellten Zertifikate, nicht aber Mehrfachzertifikate anderer Zertifizierungsinstanzen zu sperren wären.

Varianten, die entsprechende Aufgaben im Rahmen der Gültigkeitsprüfung auf den Prüfenden verlagern, dürften die Effizienz von PKI-Anwendungen erheblich verringern und die Teilnehmer überfordern. Eine weitere wichtige Rahmenbedingung soll an dieser Stelle nicht unerwähnt bleiben: Die Sperrlisten der cross-zertifizierten Domain müssen auch den Teilnehmern der jeweils anderen Domains zugänglich gemacht werden. Dazu sind zum Beispiel geeignete Zugriffsrechte auf Directories einzurichten oder die notwendigen Replikationsmechanismen aufzusetzen.

6 Praxisbeispiele

Aus der Perspektive der Zertifizierung und Bereitstellung sollten Cross-Zertifikaten keine Hürden mehr entgegenstehen. Für Prüffunktionen kann sich die Situation etwas anders darstellen, wenn der Zugriff auf Cross-Zertifikate über das oben genannte Attribut und die Verarbeitung der notwendigen Extensions noch nicht unterstützt wird.

Beispiele für produktiv eingesetzte Cross-Zertifikate konnten die Autoren derzeit nur wenige finden. Cross-Zertifizierung auf der Basis von PGP wurden von einigen Zertifizierungsinstanzen durchgeführt, zum Beispiel der DFN-PCA, der c't-CA und TC Trustcenter. In der Literatur wird häufig auch unter dem Stichwort "Cross-Zertifikat" die Verknüpfung von Root-Schlüsseln einer Zertifizierungshierarchie diskutiert (Abb. 1 Kante 13). Praktisch angewendet wird dieses Modell in der PKI nach SigG von der Regulierungsbehörde für Telekommunikation und Post. Dabei wechseln sogar die Namen der Wurzel-Zertifizierungsinstanzen, obwohl der Betreiber gleich bleibt. Die Sphinx-PCA beabsichtigt, Cross-Zertifikate anzubieten. Inwieweit andere Akteure, zum Beispiel die Initiative der Deutschen Bank mit Telesec, Cross-Zertifikate einsetzten werden, muss sich im Laufe der Zeit zeigen.

In Kanada haben verschiedene Behörden ihre Public-Key-Infrastrukturen mit der Government of Canada PKI cross-zertifiziert, unter anderem Health Canada, die Royal Canadian Mounted Police, das Department of Foreign Affairs and International Trade sowie Public Works [8]. Für zwei weitere PKI wird der Prozess der Cross-Zertifizierung gegenwärtig durchgeführt. Dies sind Industry Canada und Canada Customs and Revenue Agency.

7 Ausblick

Dem Thema Cross-Zertifizierung wurde bisher nur unzureichend Beachtung geschenkt. Cross-Zertifikate bieten die Möglichkeit, unabhängige Zertifizierungshierarchien zu verknüpfen, Pfade in Zertifizierungshierarchien zu optimieren, Wurzelzertifikate einer Root zu verketten und gegebenenfalls in Störfällen Handlungsoptionen zu Schadensbegrenzung zu erschließen. Bezüglich der Verknüpfung unabhängiger Zertifizierungshierarchien konkurriert der Ansatz mit übergeordneten Roots, die eine einheitliche Policy durchsetzen, sowie dem Ansatz der individuellen Anerkennung unabhängiger Wurzel-Zertifizierungsinstanzen.

Der Teilnehmer kann Interdomain-Cross-Zertifikate nur unter bestimmten Bedingungen erkennen. Daraus ergeben sich zwei Konsequenzen: Zum einen sollten Zertifizierungsinstanzen prüfen, ob sie geeignete Kennzeichnungen vornehmen. Zum anderen sollten Client-Implementierungen die Auswertung der relevanten Attribute unterstützen und dem Teilnehmer die Möglichkeit geben, den Domain-Wechsel zu erkennen oder zu unterbinden, wenn er dies möchte. Denkbar wäre beispielsweise auch, dafür in Cross-Zertifikaten eine private Extension zur Markierung der Domain-Grenze einzusetzen. Dieses Attribut muss dann allerdings auch von den Clients unterstützt werden.

Wenn eine Zertifizierungsinstanz ein Interdomain-Cross-Zertifikat ausstellt, kann sie darin (über ihre Policy oder das CPS) Zusicherungen und Verpflichtungen für die Teilnehmer der cross-zertifizierten Domain ausdrücken, selbst wenn die Teilnehmer nicht zugestimmt haben. Vertrauen andere Teilnehmer auf diese Zusicherungen, könnten sie mit ihren Erwartungen leerlaufen. Für solche Fälle muss sichergestellt sein, dass der Aussteller des Cross-Zertifikats die Verantwortung trägt. Zu klären wäre daher, ob das bestehende Haftungsrecht und die Regelungen im novellierten SigG dieses Problem hinreichend abdecken.

Die bisher nur geringe Nutzung von Cross-Zertifikaten ist nicht zuletzt auch dadurch begründet, dass noch eine Reihe von organisatorischen, rechtlichen und technischen Problemen zu lösen sind. Cross-Zertifizierung wird jedoch in naher Zukunft an Bedeutung gewinnen, sobald PKI-Insellösungen domainweit eingeführt sind, nicht zuletzt weil dadurch auch der Business-Value der bereits etablierten Lösungen steigt. Bis dahin müssen die in diesem Beitrag angesprochenen Aspekte der Cross-Zertifizierung jedoch noch weiter untersucht und für ein gemeinsames Verständnis für die Problematik unter Policy-Verantwortlichen, Entwicklern von PKI-Komponenten und Teilnehmern gesorgt werden. Dieses gemeinsame Verständnis ist Voraussetzung für begründete Cross-Zertifizierung und damit mittelbar notwendig, damit das gewünschte hohe Vertrauen in PKI-Leistungen erreicht oder erhalten werden kann.

© SecuMedia-Verlags-GmbH, D-55205 Ingelheim,
KES 5/2001, Seite 52

Zurück zum Inhalt