-
Technisches Gebiet
-
Diese Erfindung betrifft das Gebiet der Public Key Infrastruktur (PKI) und insbesondere Verfahren zur Transformation digitaler Zertifikate in einen vertrauenswürdigen Zertifizierungspfad zum Zweck der Interoperabilität solcher PKIen.
-
Stand der Technik
-
Asymmetrische Kryptosysteme basieren darauf, dass Daten mit einem Chiffrierschlüssel verschlüsselt und mit einem dazu inversen Dechiffrierschlüssel wieder entschlüsselt werden können. Der Chiffrierschlüssel kann veröffentlicht werden, während der Dechiffrierschlüssel vom Eigentümer geheim gehalten wird. Ein System zur Verwaltung solcher Schlüssel wird als Public Key Infrastruktur (PKI) bezeichnet. Für PKI existieren zahlreiche Standards und Verfahren, vgl. „B. Schneier; Applied Cryptography 2nd ed.; Wiley & Sons; 1996”.
-
Der X.509 Standard „ITU-T X.509, Directory Information technology – Open Systems Interconnection – The Directory: Public-key and attribute certificate frameworks, 2005” beschreibt insbesondere die Struktur von digitalen Zertifikaten. Ein digitales Zertifikat ordnet den öffentlichen Schlüssel eines Public Key Kryptosystems einem Teilnehmer zu und wird von einer vertrauenswürdigen Zertifizierungsstelle, Certification Authority (CA) digital signiert. Digitale Zertifikate werden zur Verschlüsselung und digitalen Signierung von Daten sowie zur Authentisierung von Teilnehmern und Systemen verwendet. Teilnehmerzertifikate können effizient über Verzeichnisdienste zur Verfügung gestellt werden.
-
Die PKIX Arbeitsgruppe der IETF hat eine Reihe von Standards verabschiedet, welche die Realisierung von PKIen im Internet auf der Basis von X.509 ermöglichen. Insbesondere wird in RFC 5280 „Internet X.509 Public Key Infrastructure – Certificate and Certificate Revocation List (CRL) Profile, IETF 2008” beschrieben, wie der Aufbau und die Nutzung digitaler Zertifikate erfolgen soll.
-
Die in RFC 5652 spezifizierte „Crytographic Message Syntax, IETF 2009”, auch als PKCS#7 Format bekannt, beschreibt die Struktur von signierten und verschlüsselten Daten. CMS ist Basis für viele kryptographische Anwendungen, beispielsweise verschlüsselte oder signierte E-Mails mittels Secure Multipurpose Internet Mail Extensions (S/MIME) gemäß RFC 3851 oder verschlüsselte oder signierte Dokumente mittels Portable Document Format (PDF) gemäß ISO 32000. Viele Produkte wie Microsoft® Outlook®, Lotus Notes®, Adobe® Acrobat® oder Open Source Werkzeuge wie Mozilla® Thunderbird® verwenden diesen Standard.
-
In CMS wird der Inhaltstyp Enveloped Data spezifiziert, der aus den verschlüsselten Inhaltsdaten sowie den für einen oder mehrere Empfänger verschlüsselten Datenverschlüsselungsschlüsseln besteht. Bei Nutzung einer PKI wird der Datenverschlüsselungsschlüssel mit dem öffentlichen Schlüssel des jeweiligen Empfängers verschlüsselt. Der Empfänger entschlüsselt mit Hilfe seines privaten Schlüssels zunächst den Datenverschlüsselungsschlüssel und hiermit anschließend die Inhaltsdaten. Die Angaben über das verwendete Schlüsselverteilungsverfahren sowie den vom Urheber verwendeten öffentlichen Schlüssel sind in der Struktur RecipientInfo und dort im Typ KeyTransRecipientInfo in dem Element RecipientIdentifier ::= CHOICE {issuerAndSerialNumber IssuerAndSerialNumber, subjectKeyIdentifier [0] SubjectKeyIdentifier} gespeichert. Welcher Wert verwendet wird, ist abhängig von der CMS-Version. Hiermit wird ein eindeutiger Bezug auf das vom Urheber verwendete Empfängerzertifikat entweder auf den Distinguished Name (DN) der ausstellenden CA und die Zertifikatsseriennummer oder den Subject Key Identifier hergestellt.
-
Der Urheber muss der ausstellenden Zertifizierungsstelle eines digitalen Zertifikats vertrauen, bevor der darin enthaltene öffentliche Schlüssel verwendet werden kann. Ursprünglich wurde in X.509 und RFC 1422 „Certificate-Based Key Management, IETF 1993” ein streng hierarchisches Modell vorgeschlagen, in dem das Vertrauen in eine ausstellende Zertifizierungsstelle (Issuing CA) durch übergeordnete Zertifizierungsstellen (Intermediate CA) und eine Kette von Zertifikaten bis hin zu einer Wurzel-Zertifizierungsstelle (Root CA) realisiert wird. Dieser globalen Wurzel-Zertifizierungsstelle sollten alle Teilnehmer vertrauen.
-
In der Realität wurden inzwischen viele PKIen in Unternehmen, Behörden und akademischen Einrichtungen etabliert. Jede dieser PKIen hat üblicherweise eine eigene Root CA. Das Vertrauen in alle Teilnehmerzertifikate innerhalb einer PKI wird durch die Konfiguration des Root-Zertifikats in den vorhandenen Computersystemen erreicht.
-
Um das Vertrauen in Zertifikate aus einer anderen PKI herzustellen, gibt es verschiedene Ansätze, die in RFC 4158 „Internet X.509 Public Key Infrastructure: Certification Path Building, IETF 2005” beschrieben sind. Mit Kreuzzertifikaten können CAs sich gegenseitig anerkennen. Hierbei signiert CA1 ein Zertifikat, das den öffentlichen Schlüssel von CA2 enthält und umgekehrt. Solche Kreuzzertifikate werden beispielsweise in
US Patent 6738900 B1 verwendet. In Zertifikatsvertrauenslisten, wie sie beispielsweise in ETSI TS 102 231 „Provision of harmonized Trust Service Provider status information, 2005” spezifiziert sind, können die vertrauten Root-CAs konfiguriert werden. So genannte Bridge CAs können als gemeinsamer Vertrauensanker dienen. In
US 2003/0130947 A1 wird ein Verfahren zur Ermittlung von Vertrauenspfaden beschrieben, basierend auf einer Menge von vorhandenen Vertrauensbeziehungen. In
US 2004/0144840 A1 wird eine Methode und ein System zur Registrierung und Verifikation von Smart Card Zertifikaten beschrieben für Benutzer, die sich zwischen PKI Domänen bewegen und die Smart Card zur Authentisierung und zum Zugang zu einem externen Terminal verwenden. Hierzu wird in der externen Domäne durch eine externe CA ein neues Zertifikat für ein neu erzeugtes Schlüsselpaar ausgestellt und zusammen mit dem privaten und dem öffentlichen Schlüssel auf die Smart Card geschrieben.
-
In RFC 4158 wird beschrieben, wie ein Zertifizierungspfad von einem Teilnehmerzertifikat hin zu einem Vertrauensanker oder in umgekehrter Richtung geprüft werden kann. Insbesondere kann ein Zertifizierungspfad durch Übereinstimmung von Schlüsselidentifikatoren (Key-IDs) oder Distinguished Names in den Zertifikaten von ausstellenden CAs und den von diesen ausgestellten Zertifikaten ermittelt werden. Enthält das End-Entity-Zertifikat (EE-Zertifikat) einen AuthorityKeyIdentifier (AKI) (siehe RFC 5280), kann die Zertifikatskette anhand des AKI gebildet werden. Der AKI besteht entweder aus dem SubjectKeyIdentifier (SKI) (vgl. RFC 5280) des ausstellenden CA Zertifikats oder aus dem Issuer-DN und der Seriennummer des ausstellenden CA Zertifikats. Um die Zertifikatskette zu bilden, sucht die Applikation im lokalen Speicher nach einem Zertifikat, das den Angaben im AKI aus dem EE-Zertifikat entspricht. Das gleiche Vorgehen wird dann für das gefundene CA Zertifikat verwendet, bis die Applikation an einem Vertrauensanker, z. B. einem Stammzertifizierungsstellenzertifikat angekommen ist. Ein Stammzertifizierungsstellenzertifikat ist selbstsigniert, verweist somit auf sich selbst und muss in der Applikation als vertrauenswürdig deklariert werden. Kann ein Zertifikat bei der Zertifikatskettenbildung nicht gefunden werden, wird der Authority Information Access (AIA) aus dem Zertifikat ausgewertet. Anhand des AIA kann das gesuchte CA-Zertifikat heruntergeladen werden (beispielsweise über LDAP oder http). Als weitere Methode beschreibt RFC 4158 die Kettenbildung mittels DN. So überprüft die Applikation, ob der Issuer-DN des EE-Zertifikats mit dem Subject-DN im CA-Zertifikat übereinstimmt. Ist dies der Fall, wird die Kettenbildung mit diesem CA-Zertifikat fortgesetzt, bis ein Vertrauensanker (z. B. Stammzertifizierungsstellenzertifikat) gefunden wird. Auch in diesen Fall muss das Stammzertifizierungsstellenzertifikat als vertrauenswürdig deklariert werden.
-
Eine kryptographische Anwendung muss alle Zertifikate des Zertifizierungspfads bis hin zu einem Vertrauensanker überprüfen, bevor der öffentliche Schlüssel des Empfängerzertifikats zur Verschlüsselung genutzt wird. Dazu gehört auch eine Sperrprüfung mittels Sperrlisten (CRL) oder Online-Verfahren wie OCSP. Dies geschieht bei Microsoft
® Outlook
® beispielsweise dadurch, dass die Zertifikatskette vom Teilnehmerzertifikat des Mail-Empfängers bis hin zu einer Root-CA geprüft wird, die aktuell im Windows Zertifikatsspeicher als vertrauenswürdig konfiguriert sein muss.
US Patent 7143165 B2 beschreibt ein Verfahren zur Aktualisierung von solchen Root-Zertifikaten im Windows
® Root Certificate Store.
-
Beschreibung des Problems
-
Wenn die Absenderin Alice einer PKI1 eine Nachricht an den Empfänger Bob in der PKI2 senden möchte, benötigt sie dessen Teilnehmerzertifikat und muss diesem vertrauen.
-
Für die Beschaffung des Teilnehmerzertifikats aus einer externen PKI eignen sich so genannte Zertifikats-Broker, die in ”Öffentliche Zertifikatsverzeichnisse für Public Keys, DuD 7, GWV Fachverlage 2009” beschrieben sind. Die Client-Anwendung von Alice kann automatisch über LDAP gemäß „RFC 2251, Lightweight Directory Access Protocol (v3), IETF 1997” eine Suchanfrage für das Zertifikat von Bob an den Zertifikats-Broker stellen. Dieser ermittelt das für Bob's Zertifikat zuständige Zertifikatsverzeichnis (Repository), leitet die Anfrage dorthin weiter und sendet das empfangene Zertifikat an Alice's Client zurück.
-
Sofern Alice's Client einen vertrauenswürdigen und gültigen Zertifizierungspfad für das erhaltene Zertifikat von Bob ermitteln kann, wird anschließend die Nachricht an Bob mit dessen öffentlichem Schlüssel verschlüsselt. Sofern kein Zertifizierungspfad vorhanden ist oder Sperrprüfungen nicht durchgeführt werden können, wird die Client-Anwendung die Verschlüsselung ablehnen und eine entsprechende Warnung hervorrufen.
-
In der Praxis großer PKIen hat es sich gezeigt, dass die Verwaltung von PKI-übergreifendem Vertrauen auf jedem einzelnen Computersystem (Client-Rechner) äußerst aufwändig ist. Insbesondere ist die ständige Aktualisierung von Vertrauenslisten auf allen Benutzer-Computern eine technische und organisatorische Herausforderung. Das zuvor aufgeführte Verfahren zur automatischen Aktualisierung kann für Einzelanwender akzeptabel sein, jedoch nicht für Unternehmen mit einer einzuhaltenden Security- und Trust-Policy. Auch die Nutzung von Kreuzzertifikaten ist problematisch, da die Bildung von Zertifizierungspfaden hierbei äußerst komplex ist und von den heutigen Softwareprodukten oft nur unzureichend unterstützt wird. Die Vereinbarung von Kreuzzertifikaten auf Root-CA-Ebene ist ferner oft organisatorisch und rechtlich äußerst aufwändig zu erreichen.
-
Ein Verfahren zur Delegation der Zertifikatskettenbildung und -prüfung vom Client-Rechner an einen zentralen Dienst ist in RFC 5055 „Server-Based Certificate Validation Protocol (SCVP), IETF 2007” beschrieben. Die Nutzung dieses Dienstes bedingt aber spezielle Software am Client-Rechner, die dieses SCVP Protokoll unterstützt. Es gibt hierfür wenige Implementierungen und eine Verbreitung dieses Verfahrens ist nicht abzusehen. Beispielsweise müsste dazu unter Microsoft® Windows® ein neuer Revocation Provider integriert werden, der sich grundlegend anders verhält als das bislang über die Crypto-API verwendete Standardverfahren.
-
Die Konsequenz ist, dass viele E-Mails, die technisch betrachtet verschlüsselt übertragen werden könnten, in der Praxis unverschlüsselt gesendet werden, da kein gültiger Zertifizierungspfad in der Client-Anwendung ermittelt werden kann. Zur Lösung dieses Problems wird ein Verfahren benötigt, das nahtlos an vorhandene IT-Systeme ohne Änderung der vorhandenen Betriebssysteme oder Anwendungsprogramme angebunden werden kann und mit welchem das PKI-übergreifende Vertrauen für eine PKI effizient verwaltet werden kann. Das Verfahren soll den Teilnehmern und Computersystemen der PKI Zertifikate für Empfänger in anderen PKIen bereitstellen, für die die einzelnen Computersysteme einen vertrauenswürdigen Zertifizierungspfad ermitteln können. Hiermit sollen Nachrichten an beliebige Empfänger einer anderen PKI verschlüsselt werden können, so dass der Empfänger den verwendeten öffentlichen Schlüssel identifizieren und die Nachricht entschlüsseln kann.
-
Beschreibung der Erfindung
-
Die Aufgabe der hier vorliegenden Erfindung ist es, für den Urheber einer Nachricht aus einer PKI das erforderliche Vertrauen in Verschlüsselungszertifikate für Empfänger in anderen PKIen herzustellen, welche beispielsweise über einen Verzeichnisdienst gefunden werden. Das hier beschriebene technische Verfahren kann in die Kommunikation zwischen der verschlüsselnden Anwendung (Client) und einem Zertifikats-Repository geschaltet werden und stellt der Clientanwendung geeignete Zertifikate für die öffentlichen Schlüssel der Empfänger bereit, denen ohne weitere Einstellungen vertraut wird. Diese Zertifikate können dann von der Clientanwendung zur Verschlüsselung von Nachrichten oder Dokumenten verwendet werden, die der Empfänger entschlüsseln kann. Das technische Verfahren wird im Folgenden beschrieben.
-
Das Verfahren erfordert keine technischen Änderungen am Client und keine Änderungen an existierenden Standards wie X.509, LDAP (RFC 2251), CMS (RFC 3852), S/MIME (RFC 3851) oder PDF (ISO 32000). Lediglich das Vertrauen in eine vordefinierte Zertifizierungsstelle innerhalb der eigenen PKI muss direkt oder indirekt über eine Zertifizierungshierarchie vorhanden sein. Das Verfahren kann technisch direkt in einen Verzeichnisdienst integriert werden oder es kann durch Vorschalten eines zusätzlichen Systems zwischen Client und Server realisiert werden.
-
zeigt eine Übersicht über die Funktionsweise sowie die Vertrauensbeziehungen des Verfahrens. Eine verschlüsselnde Anwendung (Client1) 1 in der PKI1 benötigt den öffentlichen Schlüssel für den Empfänger mit dem Client2 2 in PKI2. In der PKI2 wurde hierfür durch die Zertifizierungsinstanz CA2 mit dem Ausstellerzertifikat ZCA2 4 ein Zertifikat Z2 5 ausgestellt 6, das einen Bezug zum Ausstellerzertifikat enthält 7. Dieses Zertifikat wird einem Zertifikatstransformationsdienst (ZTD) 8, beispielsweise über einen Verzeichnisdienst zugeführt 9. Nach Überprüfung der Gültigkeit wird vom ZTD eine Zertifikatsanforderung 10 für den enthaltenen öffentlichen Schlüssel zusammen mit weiteren Attributen erzeugt und an die Zertifizierungsinstanz CM1 11 mit dem Ausstellerzertifikat ZCA1 12 gesendet und von dieser ein Zertifikat Z2t 13 ausgestellt 14, das einen Verweis auf das Ausstellerzertifikat ZCA1 enthält 15. Der ZTD empfängt das Zertifikat Z2t 16 und sendet es dann an Client1 17. Der Client1 verschlüsselt 18 die Nachricht M 19, und fügt dabei eine Referenz auf den zur Verschlüsselung verwendeten öffentlichen Schlüssel in Z2 hinzu 20. Der Client2 empfängt die Nachricht M 21 und kann aufgrund der Referenz 20 den zum öffentlichen Schlüssel in Z2 gehörenden privaten Schlüssel ermitteln 22 und die Nachricht M entschlüsseln. In diesem Verfahren ist lediglich das Vertrauen von Client1 zu CA1 23 und von Client2 zu CA2 24 erforderlich. Der ZTD vertraut CA1 25 und CA2 26 und stellt somit für alle Clients in der PKI1 Vertrauen mit CA2 her. Alle Vertrauensbeziehungen können entweder direkt oder indirekt über eine Vertrauenskettenbildung mit mehreren Zwischenzertifikaten und einem Vertrauensanker hergestellt sein. Somit kann der öffentliche Schlüssel aus Zertifikat Z2 am Client1 verwendet werden, ohne dass ein direktes Vertrauen zu CA2 am Client1 eingestellt werden muss.
-
Die gefundenen Empfängerzertifikate können vor der Transformation gemäß RFC 5280 und RFC 4158 auf Gültigkeit geprüft werden. Welche Empfängerzertifikate vom ZTD transformiert werden, kann konfiguriert werden. So kann festgelegt werden, dass nur Zertifikate von bestimmten Zertifizierungsstellen transformiert werden, denen vertraut wird. Die Konfiguration der vertrauten Zertifizierungsstellen kann über standardisierte Formate wie beispielsweise ETSI Trusted Service List erfolgen.
-
Die in dargestellten Komponenten Client1 1 und Client2 2 können verfügbare Programme zur E-Mailverschlüsselung oder Dokumentverschlüsselung sein. Ebenso können die Komponenten CA1 11 und CA2 3 gängige Programme für Zertifizierungsinstanzen sein. Der Zertifikatstransformationsdienst ist eine neue Komponente, die dafür zuständig ist, Zertifikatsanforderungen an CA1 zu stellen, die geeignet sind, um Zertifikate Z2t zu erzeugen, die folgende Anforderungen erfüllen:
- 1. Der Subject Distinguished Name (DN) des Empfängers sowie dessen öffentlicher Schlüssel müssen für die Nutzung zur Verschlüsselung enthalten sein.
- 2. Für die eindeutige Ermittlung des Empfängerzertifikats durch Client2 muss die Nachricht M entweder den Issuer Distinguished Name (DN) der ausstellenden CA2 und die Zertifikatsseriennummer von Z2 oder den Subject Key Identifier von Z2 enthalten. Diese Angaben müssen also in Z2t enthalten sein. Ein Beispiel einer verschlüsselten Nachricht an 3 Empfänger ist in dargestellt. Für jedes Zertifikat der Teilnehmer werden Issuer DN und Seriennummer des Zertifikats in die Nachricht eingefügt.
- 3. Für die Bildung einer Vertrauenskette mittels der CA1 durch Client1 muss in Z2t eine Referenz auf ZCA1 enthalten sein. Dies kann gemäß RFC 5280 entweder durch die Erweiterung AuthorityKeyIdentifier (AKI) oder den Namen des Ausstellers (Issuer DN oder RDN) erfolgen. Der AKI besteht dabei entweder aus dem SubjectKeyIdentifier (SKI) des ausstellenden CA Zertifikats ZCA1 oder aus dem Issuer DN und der Seriennummer des ausstellenden CA Zertifikats ZCA1.
- 4. Alle weiteren Attribute, die gemäß RFC 5280 zwingend vorgeschrieben sind, müssen ebenfalls enthalten sein. Hierzu gehören die Version sowie die Gültigkeit des Zertifikats. Das transformierte Zertifikat Z2t darf dabei nicht länger gültig sein als das ursprüngliche Zertifikat Z2.
-
Optional können auch weitere benötigte Zertifikatserweiterungen aus Z2 in das transformierte Zertifikat Z2t übernommen werden. Dies ist vor allem dann notwendig, wenn eine KeyUsageExtension in Z2 vorhanden ist, welche die Schlüsselverwendung des Zertifikats einschränkt oder ein SubjectAlternativeName (SAN) im Empfängerzertifikat vorhanden ist, der dem Zertifikat z. B. eine E-Mail-Adresse zuordnet.
-
Die notwendigen Informationen zur Zertifikatserstellung von Z2t werden in einer Zertifikatsanforderung R2t vom ZTD an CA1 übergeben. RFC 4211 „Certificate Request Message Format (CRMF), 2005” beschreibt das standardisierte Format der Zertifikatsanforderung. Eine Zertifikatsanforderung besteht aus einer ID, einem Zertifikatsmuster (Template) sowie Steuerinformationen (Controls). Die Attribute des Zertifikatsmusters werden wie folgt belegt: version, serialNumber, signingAlg, issuerUID und subjectUID werden wie im RFC gefordert nicht gesetzt. Das Feld issuer wird mit dem Namen der externen Zertifizierungsstelle CA2 belegt. validity kann belegt werden, in diesem Fall muss notBefore die aktuelle Zeit und notAfter maximal den Wert der Gültigkeit aus Z2 tragen. subject wird mit dem Subject Distinguished Name (DN) des Empfängers und publicKey mit dessen öffentlichem Schlüssel aus Z2 belegt. Das Feld extensions wird mit den optional benötigten Zertifikatserweiterungen aus Z2 belegt. Das Steuerelement OldCertId dient laut RFC 4211 dazu, ein Zertifikat zu spezifizieren, das durch die aktuelle Zertifikatsanforderung aktualisiert werden soll. Es wird hier verwendet, indem issuer mit dem Issuer DN aus Z2 und serialNumber mit der Seriennummer aus Z2 belegt wird. Damit können alle gemäß [0022] zur Transformation benötigten Informationen an CA1 in der Zertifikatsanforderung R2t im CRMF Format übergeben werden. Alternativ kann in einer technischen Realisierung die Zertifikatsanforderung auch in anderen Formaten, beispielsweise in einer XML-Struktur, codiert und übermittelt werden, sofern die Implementierung der Schnittstellen der Zertifizierungsstelle CA1 dies zulässt.
-
Die Zertifikatsanforderung R2t kann mit dem privaten Schlüssel des ZTD signiert und anhand des zugehörigen Zertifikats von der Zertifizierungsstelle CA1 vor der Bearbeitung der Zertifikatsanfrage geprüft werden.
-
Die Zertifizierungsstelle CA1 erstellt das transformierte Zertifikat Z2t. Dazu werden die in der Zertifikatsanforderung R2t übergebenen unter [0022] aufgeführten Attributwerte in Z2t aufgenommen. Zusätzlich können weitere Attribute wie beispielsweise Verweise auf Ausstellerinformationen (AIA) oder Sperrinformationen in die transformierten Zertifikate hinzugefügt werden. Werden CRL Distribution Points verwendet, muss die entsprechende Zertifizierungsstelle CA1 Sperrlisten veröffentlichen und entsprechende CRL Distribution Points in die transformierten Zertifikate einfügen. Das Bereitstellen von Sperrinformationen ist dann notwendig, wenn die Sperrprüfung der Clientanwendung nicht deaktiviert werden kann. Das erstellte Zertifikat Z2t wird von der Zertifizierungsstelle CA1 mit dem zu ZCA1 gehörigen privaten Schlüssel signiert und an den ZTD gesendet. Von dort wird das Zertifikat an den Client1 übermittelt.
-
Der Client1 führt eine Zertifikatskettenprüfung durch. Sofern die Prüfung anhand des AKI aus Z2t erfolgt, kann die Zertifikatskette bis hin zum Vertrauensanker ZRt1 gültig geprüft werden, vgl. Schema A) in .
-
Ausführungsbeispiel 1 in zeigt. den detaillierten Ablauf für eine Applikation welche die Zertifikatskette anhand des AKI generiert. Ein Client übergibt eine Suchanfrage nach einem Zertifikat an einen Zertifikats-Broker 1. Der Zertifikats-Broker leitet die Anfrage an den Verzeichnisdienst weiter 2. Der Verzeichnisdienst sucht in einer Datenbank, die sich z. B. auf der lokalen Festplatte des Rechners befindet nach einem entsprechenden Eintrag. Als Ergebnis wird das gefundene Zertifikat Z2 an den Zertifikats-Broker zurückgegeben 3. Der Zertifikats-Broker leitet das gefundene Zertifikat an den ZTD weiter 4. Der ZTD überprüft die Zertifikatskette des Zertifikats, wobei Root-CA2 als vertrauenswürdig gilt 4. Dabei wird jedes Zertifikat der Kette an eine Validierungskomponente übergeben 5. Die Komponente überprüft z. B. anhand von CRL oder OCSP die Gültigkeit des Zertifikats. Ist das Zertifikat gültig, wird eine Zertifikatsanforderung R2t für das transformierte Zertifikat erzeugt und an die Zertifizierungsstelle CA1 übergeben 6. CA1 erstellt mit diesen Informationen ein neues Zertifikat Z2t gemäß [0022] und übergibt das signierte Zertifikat dem ZTD 7. Der Zertifikatstransformationsdienst übergibt das Zertifikat dem Zertifikats-Broker 8, der das Zertifikat an den anfragenden Client weiterleitet 9. Der Client kann nun eine vertrauenswürdige Zertifikatskette bis zur Root-CA1 aufbauen, da diese das Zertifikat von CA1 ausgestellt hat. Anschließend kann das Zertifikat zur Verschlüsselung durch den Client z. B. mit S/MIME verwendet werden.
-
Wird die Kettenbildung bei Client1 mittels Issuer DN durchgeführt, muss das neue Zertifikat von einer Zertifizierungsstelle CA1* signiert werden, die ein Zertifikat ZCA1-2 besitzt, das als Subject DN den Issuer DN CA2 aus dem Empfängerzertifikat Z2 enthält. Schema B) beschreibt diesen Ansatz.
-
Für die Realisierung einer solchen Zertifizierungsstelle CA1* gibt es verschiedene Möglichkeiten. In einer Variante wird für jede in einem empfangenen Empfängerzertifikat Zi enthaltene Issuer CAi jeweils eine Instanz CA1-i (i = 1...n; n = Anzahl der externen Issuer CAs) mit eigenem Schlüsselpaar und dem entsprechenden Zertifikat ZCA1-i erzeugt. In einer anderen Variante wird lediglich eine Instanz der Zertifizierungsstelle CA1* eingesetzt für deren öffentlichen Schlüssel mehrere Zertifikate ZCA1-i existieren. Die Zertifikate ZCA1-i werden von einer Wurzel- oder Zwischenzertifizierungsstelle CA0 ausgestellt, für die am Client1 ein Vertrauenspfad existiert. Die Gültigkeit der Zertifikate ZCA1-i darf dabei nicht länger als die ursprüngliche Gültigkeit des Zertifikats ZCAi der externen Zertifizierungsstelle CAi sein. Der Client1 muss für die Kettenprüfung Zugriff auf die Zertifikate ZCA1-i haben. Dies kann dadurch erreicht werden, dass alle Zertifikate ZCA1-i auf einem Server bereitgestellt werden, der über HTTP oder LDAP erreichbar ist und jedes transformierte Zertifikat Zit einen AIA-Verweis auf diesen Speicherort erhält.
-
Ausführungsbeispiel 2 in zeigt die Schritte für eine Applikation, welche Zertifikatsketten anhand des Issuer DN im Empfängerzertifikat bildet. Ein Client übergibt eine Suchanfrage nach einem Zertifikat an einen Zertifikats-Broker 1. Der Zertifikats-Broker leitet die Anfrage an den Verzeichnisdienst weiter 2. Der Verzeichnisdienst sucht in einer Datenbank, die sich z. B. auf der lokalen Festplatte des Rechners befindet nach einem entsprechenden Eintrag. Als Ergebnis wird das gefundene Zertifikat Z2 an den Broker zurückgegeben 3. Der Zertifikats-Broker sendet dieses Zertifikat an den Zertifikatstransformationsdienst (ZTD) 4. Der ZTD überprüft das Zertifikat (führt eine Zertifikatskettenprüfung durch) und extrahiert aus dem Zertifikat die notwendigen Informationen wie Public Key, Subject DN, Issuer DN, Seriennummer, SubjectKeyIdentifier und SubjectAlternativeName. Diese Informationen werden in eine Zertifikatsanforderung R2t übernommen und an Zertifizierungsstelle CA1* weitergeleitet 5. CA1* basiert auf dem in [0030] beschriebenen Verfahren und verwendet dasselbe Schlüsselpaar für mehrere Ausstellerzertifikate. Zertifizierungsstelle CA1* überprüft nach Erhalt von R2t, ob bereits ein Ausstellerzertifikat existiert, welches als Subject DN den Issuer DN aus der Zertifikatsanforderung R2t besitzt. Ist dies nicht der Fall, wird ein neues Ausstellerzertifikat von CA0 beantragt. Dazu wird die Zertifikatsanforderung R1-2 erstellt und Zertifizierungsstelle CA0 übergeben 6. Zertifizierungsstelle CA0 erstellt mit Hilfe der Zertifikatsanforderung R1-2 das neue Ausstellerzertifikat ZCA1-2 und übergibt es Zertifizierungsstelle CA1* 7. Zertifizierungsstelle CA1* veröffentlicht das Ausstellerzertifikat ZCA1-2 auf einem öffentlich zugänglichen Server (z. B. Webserver oder Verzeichnisdienst) 8, damit das Ausstellerzertifikat über einen AIA im transformierten Zertifikat Z2t referenziert werden kann. Anschließend erzeugt ZCA1* mit den Informationen aus der Zertifikatsanforderung R2t sowie dem AIA das transformierte Zertifikat Z2t und übergibt es dem ZTD 9. Der ZTD leitet das Zertifikat an den Zertifikats-Broker weiter 10. Der Zertifikats-Broker liefert das transformierte Zertifikat Z2t dem anfragenden Client zurück 11. Der Client verifiziert das Zertifikat Z2t und erstellt eine Zertifikatskette. Hierzu wird das Zertifikat ZCA1-2 benötigt, welches mittels Informationen aus dem AIA in Z2t gefunden wird 12. Das Zertifikat ZCA1* wird dem Client vom Server zurückgegeben 13 und der Client kann eine vollständige Kette bis zu einer vertrauenswürdigen Zertifizierungsstelle bilden, da die entsprechende Root-CA1 als vertrauenswürdig eingestuft ist. Anschließend kann das Zertifikat z. B. für S/MIME verwendet werden.
