34

| DFN Mitteilungen Ausgabe 85 | November 2013 | SICHERHEIT

Konzept und Nutzen von Certificate Policy und Certification Practice Statement Zertifizierungsstellen, die Zertifikate für E-Mail-Signatur oder -Verschlüsselung oder für die Authentifizierung von Web-Servern oder Nutzern ausgeben, werden als Trusted Third Party bezeichnet. Dieser Begriff kann auf mehrere Arten interpretiert werden: Entweder als eine Stelle, deren Vertrauenswürdigkeit bewiesen ist. Oder aber als eine Stelle, die durch ein formales Axiom für bedingungslos vertrauenswürdig erklärt werden muss, damit das Sicherheitssystem funktioniert. Insbesondere mit der letzten Interpretation haben es Zertifizierungsstellen durch schwerwiegende Sicherheitsvorfälle in den Jahren 2011 und 2012 sogar bis in die Mainstream-Presse gebracht: „Schludrige Schlüsselmeister gefährden das Web“ [1]. In diesem Beitrag wird dargestellt, welche Rolle Certificate Policy (CP) und Certification Practice Statement (CPS) bei der Bewertung der Vertrauenswürdigkeit von Zertifizierungsstellen haben. Text: Jürgen Brauckmann (DFN-CERT GmbH), Dr. Ralf Gröper (DFN-Verein) Dieser Artikel ist bereits erschienen in „Datenschutz und Datensicherheit“, Ausgabe 08/2013.

Foto: © Francesca Schellhaas - Photocase

SICHERHEIT | DFN Mitteilungen Ausgabe 85 |

1 Einleitung X.509-Zertifikate binden Namen an kryptographische Schlüssel und diese Bindung wird dabei durch den Zertifikatherausgeber, die Zertifizierungsstelle (Certificate Authority, CA), mit einer eigenen Signatur bestätigt. Die Kombination aus Namen, kryptographischem Schlüssel und Signatur bildet schließlich das Zertifikat. Bevor der technische Vorgang der Zertifikaterstellung stattfindet, muss eine Zertifizierungsstelle organisatorische und technische Prozesse durchlaufen, um die Gültigkeit und Korrektheit von Namen und die Bindung an die kryptographischen Schlüssel zu verifizieren. Die Komplexität dieser organisatorischen Prozesse ist der Grund, warum so manches internes Zertifizierungsstellenprojekt zwar bis zu einer passenden OpenSSL-Installation und -Konfiguration kommt, aber dann an den weiteren Schritten scheitert. Ob einer Zertifizierungsstelle vertraut werden kann, hängt aber entscheidend von diesen organisatorischen und technischen Prozessen ab. Daraus ergibt sich die Fragestellung: Wie kann eine Zertifizierungsstelle genügend Informationen über ihre Prozesse an die Öffentlichkeit transportieren, um das entsprechende Vertrauen herzustellen?

2 Zweck Eine Antwort auf diese Frage ist: Durch die Veröffentlichung einer Zertifizierungsrichtlinie und/oder einer Erklärung zum Zertifizierungsbetrieb, in denen sich jedermann über die Prozesse und Sicherheitsmaßnahmen einer Zertifizierungsstelle informieren kann. Eine Zertifizierungsrichtlinie (Certificate Policy, CP) beschreibt das Sicherheitsniveau der in einer Zertifizierungshierarchie ausgegebenen Zertifikate in einem öffentlichen Dokument. Eine CP soll die Frage beantworten, ob ein vorliegendes Zertifikat für einen bestimmten Einsatzzweck geeignet ist. Hierzu werden Anforderungen dokumentiert, die für alle ausgestellten Zertifikate eingehalten werden. Eine CP kann unabhängig von einer konkreten CA erstellt werden und somit beispielsweise die Anforderungen einer speziellen Nutzergruppe festhalten. Eine CA, die Zertifikate für diese Nutzergruppe erstellen will, muss dann deren CP einhalten. Im Unterschied dazu enthält die Erklärung zum Zertifizierungsbetrieb (Certification Practice Statement, CPS) konkrete Aussagen über den Betrieb einer bestimmten Zertifizierungsstelle. Es werden alle Aspekte des Lebenszyklus eines Zertifikats inklusive Erneuerung und Sperrung beschrieben, und die Maßnahmen der CA im Bereich Infrastruktur, Organisation und personelle Sicherheitsmaßnahmen offengelegt.

35

In der Praxis ist es schwierig, CP und CPS klar voneinander abzugrenzen, da die meisten Aspekte aus dem CPS gleichzeitig für die CP relevant sind. Daher veröffentlichen viele Zertifizierungsstellen kombinierte Dokumente, die beide Aspekte enthalten. CP und CPS beschreiben zudem immer nur den Soll-Zustand der Zertifizierungshierarchie. Ob dieser Soll-Zustand auch wirklich erreicht wird, muss durch ein internes oder besser noch externes Audit nachgewiesen werden.

3 Entwicklung des Konzepts Die Konzepte zu CP/CPS sind im Kern in den Jahren 1993 bis 2003 entstanden und gewachsen. Hierfür findet man auch in der DuD Belege, siehe z.B. den Beitrag „Eine ‚PGP-Policy‘ für Unternehmen“ von Dirk Fox aus dem Jahre 1998 [2], in dem auf zwei Seiten die Grundzüge von technischen und organisatorischen Maßnahmen für den Einsatz von PGP zum Schutz der E-Mail-Kommunikation in kleineren Unternehmen dargelegt werden. 3.1 X.509 Der „Urstandard“ für Zertifikate, X.509v1 von 1987 [3] enthält noch keine konkreten Aussagen zur Vertrauenswürdigkeit der Zertifizierungsstelle. Es wird lediglich eine „security policy“ erwähnt, die vom Nutzer eines Security Service vorab selbst definiert werden muss und die keinen konkreten Bezug zu Zertifizierungsstellen hat. X.509v2 von 1993 [4] kennt ebenfalls nur die allgemeine „security policy“. Erst in X.509v3 von 1997 [5] wird dann die „certifi­ cate policy“ definiert: „A named set of rules that indicates the applicability of a certificate to a particular community and/or class of application with common security requirements“ Konkrete Vorgaben über die Gestaltung einer Certificate Policy werden aber nicht gemacht. 3.2 PEM In RFC 1422 zu „Privacy Enhancement for Internet Electronic Mail“ [6] aus dem Jahre 1993 gibt es bereits das Konzept einer CP. Allerdings wird noch von einem weltweiten Netzwerk verbundener CAs unter einer oberen Aufsicht durch eine Internet Policy Registration Authority (IPRA) mit einer Zwischenschicht aus Policy Certificate Authorities (PCA) ausgegangen. Eine PCA hätte danach eine Rahmenrichtlinie als RFC veröffentlichen und sich durch die IPRA selbst zertifizieren lassen sollen. Dieses Konzept hat sich bekanntermaßen nicht durchgesetzt. 3.3 American Bar Association 1996 veröffentlichte die American Bar Association, eine Vereinigung von Rechtsanwälten und Jurastudenten, die „Digital Signature Guidelines“ [7]. Als Teil der Erläuterungen zu allgemeinen

36

| DFN Mitteilungen Ausgabe 85 | November 2013 | SICHERHEIT

rechtlichen und technischen Prinzipien von digitalen Signaturen werden allgemeine Richtlinien für den Betrieb von Zertifizierungsstellen aufgestellt und der Begriff der „Erklärung zum Zertifizierungsbetrieb“ definiert. Dabei wird festgelegt, welche Informationen eine Zertifizierungsstelle veröffentlichen muss. 3.4 PKIX Die IETF Working Group PKIX arbeitete ab dem Frühjahr 1997 an einer Standardgliederung für eine CP/CPS. Zielgruppe von PKIX sind Zertifizierungsstellen, die in der offenen Nutzergruppe des öffentlichen Internet agieren und anerkannt werden wollen. Die Standardgliederung soll ermöglichen, dass das Sicherheitsniveau von Zertifizierungsstellen leichter verglichen werden kann. Das Ergebnis wurde 1999 als RFC 2527 veröffentlicht [8]. Santosh Chokhani (CygnaCom) und Warwick Ford (Verisign) sind die Hauptautoren, die Inhalte wurden also maßgeblich von Mitarbeitern von CAs geprägt. Ab 2001 wurde die Weiterentwicklung in Angriff genommen. Das Ergebnis der Überarbeitung kam 2003 als RFC 3647 [9] mit einem mehr als doppelt so großen Umfang wie sein Vorgänger heraus. 3.5 ANSI, Webtrust, ESI In den Jahren 2000 bis 2002 wurden vier Standards zur Evaluation von Zertifizierungsstellen verabschiedet: • ANSI X9.79 „PKI Practices and Policy Framework“ [10] • AICPA/CICA „WebTrust™ Program for Certification Authorities” [11] • ETSI ESI TS 101 456 v1.1.1 [12] • ETSI ESI TS 102 042 v1.1.1 [13] Diesen Evaluierungsstandards ist gemeinsam, dass sie die Offenlegung von Informationen über die Prozesse und Verfahrensweise einer Zertifizierungsstelle verlangen, dabei aber keine konkrete Form vorschreiben. Als Hilfsmittel wird aber z.B. in den ETSI-Standards die Kapitelstruktur von RFC 2527 und später RFC 3647 referenziert. Als Ergänzung zu CP/CPS beschreiben die ETSI Standards ein „PKI Disclosure Statement“ (PDS). Das PDS soll dem Nutzer die wichtigsten Eigenschaften der Zertifizierungsstelle kurz und knapp erläutern. Leider hat sich dieses Format nicht etabliert. Nur sehr wenige Zertifizierungsstellen bieten ein PDS an.

4 Gliederung nach RFC 3647 Inzwischen verwenden die meisten Zertifizierungsstellen die in RFC 3647 definierte Standardgliederung für ihre CP/CPS, auch wenn man ab und zu noch Dokumente nach RFC 2527 oder sogar mit ganz anderen Strukturen findet. Der vielleicht wichtigste As-

pekt dabei: Es darf kein Kapitel oder Unterkapitel der Standardgliederung ausgelassen werden, selbst wenn die Zertifizierungsstelle über die betreffenden Punkte keine Informationen geben möchte. Solche nicht ausgefüllten Kapitel müssen mit dem expliziten Hinweis „Keine Angaben.“ gefüllt werden, da nur so die Vergleichbarkeit von verschiedenen CP/CPS erreicht werden kann. Die von RFC 3647 definierte Gliederung unterscheidet nicht zwischen CP und CPS. Für beide Dokumenttypen soll dieselbe Struktur verwendet werden, wobei der Inhalt jeweils an die unterschiedliche Zielsetzung angepasst sein soll: Vereinfacht kann gesagt werden, dass in der CP das „Was“ und in der CPS das „Wie“ stehen soll. Kapitel 1 eines zu RFC 3647 kompatiblen Dokuments enthält eine Identifikation des Dokuments (möglichst in Form eines Object Identifiers, die auch in den ausgestellten Zertifikaten enthalten sein kann), die Definition der Teilnehmer der PKI, mögliche Verwendungsarten der ausgestellten Zertifikate und Informationen über die Verwaltung des Dokumentes. Kapitel 2 enthält Aussagen zu öffentlich zugänglichen Informationen über die PKI, wie z.B. die Adressen von Sperrlisten, OCSPServer oder Verzeichnisdiensten. In Kapitel 3 findet sich der interessanteste Teil des Dokumentes. Es trägt den Titel „Identification and Authentication“, und beantwortet die folgenden Fragen: • Wie werden die Daten, die in das Zertifikat aufgenommen werden, verifiziert? • Welche Namen werden überhaupt in ein Zertifikat auf­- genommen? • Wie werden Zertifikat- und Sperranträge authentifiziert? Kapitel 4 befasst sich mit allen Aspekten des Lebenszyklus der Zertifikate in der PKI: • Wie werden Anträge gestellt? • Wie werden die Anträge dann weiterbearbeitet? • Wie werden Zertifikaterneuerungen und Sperrungen durchgeführt? • Was für einen Zertifikat-Status-Service gibt es? • Gibt es in der PKI Schlüsselhinterlegung und -wiederherstellung? • Welche Verantwortlichkeiten haben Zertifikatinhaber und weitere Parteien im Umgang mit den Schlüsseln und Zertifikaten? Dieser letzte Punkt erlegt dem Zertifikatinhaber und weiteren Parteien Verpflichtungen auf. Alle anderen Aussagen eines RFC

SICHERHEIT | DFN Mitteilungen Ausgabe 85 |

37

3647-konformen Dokumentes betreffen üblicherweise die Zertifizierungs- oder Registrierungsstelle. Wussten Sie, dass Sie vor dem Bezug eines Zertifikats tunlichst in Kapitel 4.5 der zugehörigen CP/CPS nachschauen sollten, wie Sie mit dem Zertifikat und dem dazugehörigen privaten Schlüssel umgehen dürfen? Aber nicht nur dem Zertifikatinhaber werden an dieser Stelle Verpflichtungen auferlegt: Auch Zertifikatprüfer, also Personen, die ein Zertifikat im Rahmen von z.B. S/MIME oder SSL präsentiert bekommen, können in diesem Kapitel dazu verpflichtet werden, eine Gültigkeitsprüfung mittels Sperrlisten oder OCSP vorzunehmen. Kapitel 5, „Management, Operational and Physical Controls“, beschreibt die nicht technischen Sicherheitsmaßnahmen der Zertifizierungsstelle: Rollenmodelle, physische Rechenzentrumssicherheit, Audit- und Logprozeduren, Trainingsanforderungen usw.

dass zur CPS noch mehr als 20 weitere Anhang-Dokumente gehören, die in unterschiedlichen Situationen Geltung haben. Im Dokument werden Sicherheitsanforderungen für 42 verschiedene Zertifikattypen und -produkte (z.B. Essential SSL, Elite SSL, PlatinumSSL, Comodo Premium SSL usw.) beschrieben.

Kapitel 6 widmet sich den technischen Sicherheitsmaßnahmen:

Die Richtlinien folgen einer eigenen Struktur und befassen sich ausführlich mit den organisatorischen Aspekten der Zertifizierung von Zertifizierungsstellen. Es handelt sich also eher um Dokumente einer „Policy Certification Authority“ im Geiste von RFC 1422 aus dem PEM-Umfeld.

• Erzeugung und Installation der CA-Schlüssel • Schutz des privaten Schlüssels der CA durch Hardware Security Module • Gibt es Schlüssel-Backups, z.B. von Nutzerschlüsseln, oder werden Schlüssel an weitere Parteien offengelegt? • Vorgaben für Passwortlängen, Schlüsselgrößen, Krypto-Algorithmen • Netzwerk- und Systemsicherheitsmaßnahmen Kapitel 7 beschreibt die konkrete Ausgestaltung von Zertifikaten, Sperrlisten und evtl. der OCSP-Dienste: Welche Felder werden belegt, welche Zertifikaterweiterungen werden unterstützt, werden Object Identifier zur Markierung von Zertifikaten verwendet? Kapitel 8 legt dar, wie die Zertifizierungsstelle die Konformität ihres Betriebs zu ihren eigenen Richtlinien sicherstellt. Kapitel 9 enthält schließlich Aussagen über die rechtlichen Rahmenbedingungen des Betriebs, Regelungen zum Datenschutz und Haftungserklärungen.

5.2 DFN Der DFN-Verein stellt seit 1996 für seine Anwender PKI-Dienstleistungen zur Verfügung. 1997 wurde ein Satz von Richtlinien unter dem Namen Low-Level Policy und Medium-Level Policy veröffentlicht, die mit jeweils ca. 20 Seiten die Ausgabe von X.509- und PGP-Zertifikaten an Personen regelten [15, 16]. 1999 kam dann die „World Wide Web Policy“ für die Zertifizierung von Servern hinzu [17].

Ab 2005 erfolgte dann eine Umstellung der Zertifizierungs- wie auch der Dokumentenstruktur. Die aktuelle DFN-PKI (unter Verantwortung der Autoren dieses Artikels) umfasst fünf verschiedene Sicherheitsniveaus (darunter z.B. Spezial-Zertifikate für das Grid-Computing), die in vier verschiedenen CPs von jeweils 40 bis 50 Seiten beschrieben werden [18]. Zu drei der vier CPs gibt es eine ergänzende CPS von 10 bis 25 Seiten, ein Sicherheitsniveau wird in einem kombinierten CP/CPS beschrieben. Die Dokumente sind nach RFC 3647 strukturiert. 5.3 Symantec Symantec (früher Verisign) veröffentlicht für seine Zertifikat-Produkte eine CP von fast 90 Seiten und eine CPS von mehr als 150 Seiten [19, 20]. Ältere Versionen sind nicht direkt abrufbar, können aber per E-Mail angefordert werden.

RFC 3647 ist ein langes und sperriges Dokument, und so verwundert es nicht, dass einige Zertifizierungsstellen eine individuelle Umsetzung gewählt haben. Im Folgenden werden Beispiele aus der Praxis vorgestellt, wobei der Fokus auf Zertifizierungsstellen liegt, deren CA-Zertifikate im Webbrowser verankert sind. 5.1 Comodo

Es fällt auf, dass beide Dokumente sehr große Überschneidungen aufweisen und beispielsweise das Kapitel 3 „Identification and Authentication“ fast identisch ist. Ein weiteres sehr interessantes Merkmal findet sich in den Anhängen zur CPS: Hier wurden relevante externe Standards wie die „Baseline Requirements for the Issuance and Management of Publicly-Trusted Certificates“ des CA Browser Forums [21] oder aber die „Guidelines for the Issuance and Management of Extended Validation (EV) Certificates“ [22] direkt wörtlich in das Dokument eingebunden.

Comodo veröffentlicht ein CPS [14]. Die älteste abrufbare Version ist von 2005, und umfasst knapp 50 Seiten. Das aktuelle Dokument hat mehr als 90 Seiten und ist in einer eigenen, nicht RFC 3647-konformen Struktur verfasst. Besonders auffällig ist,

5.4 TC TrustCenter TC TrustCenter veröffentlicht eine CP und eine CPS inklusive aller historischen Versionen [23, 24]. Im Jahr 1999 wurde die erste, nach einer eigenen Struktur aufgebaute CP mit ca. 20 Seiten Um-

5 Dokumente in der Praxis

38

| DFN Mitteilungen Ausgabe 85 | November 2013 | SICHERHEIT

fang veröffentlicht. Das Dokument beschreibt ausschließlich die Abläufe der Identifizierung und Authentifizierung, was Kapitel 3 in einem RFC 3657-Dokument entspricht. Dieses Dokument ist in überarbeiteter Form auch heute noch in Gebrauch. Es wird in der englischen Version „Certificate Policy Definitions“ genannt. Ab 2001 veröffentlichte TC TrustCenter zusätzlich ein nach RFC 2527 und später RFC 3647 gegliedertes CPS, das im Laufe der Jahre von ca. 40 auf aktuell über 70 Seiten gewachsen ist. Das Kapitel 3 dieses Dokuments ist recht ausführlich gehalten, verweist aber zusätzlich weiterhin auf die CP. Beide Dokumente definieren fünf Zertifikatklassen mit unterschiedlichen Anforderungen an die Verifikation von Daten in den ausgestellten Zertifikaten.

6 Nützlichkeit Nach diesen Beispielen aus der Praxis stellt sich jetzt die Frage, welchen Nutzen die Veröffentlichung von CP oder CPS hat. Dass eine CA als Trusted Third Party dokumentieren muss, wie sie das in sie gesetzte Vertrauen rechtfertigt, liegt auf der Hand. Aber welchen Beitrag leisten hierzu CP und CPS? Im Prinzip ist alles ganz einfach: Der Nutzer eines Zertifikats liest die dazugehörigen Dokumente und weiß sofort, wie es um die Vertrauenswürdigkeit einer CA und deren Zertifikate bestellt ist. Wie man allerdings an den Praxis-Beispielen erkennen kann, scheitert dieser Ansatz schon am Umfang einer gewöhnlichen CP oder CPS. Man muss bei 90 Seiten Dokumentation vorab recht genau

wissen, an welchen Stellen die kritischen Punkte stehen, die zur Beurteilung der Vertrauenswürdigkeit wichtig sind. Die Verteilung wichtiger Inhalte auf zig Anhänge erschwert dies zusätzlich. Und noch ein weiteres Zahlenspiel: In Mozilla-Produkten sind aktuell 62 verschiedene Organisationen mit 158 Root-CA-Zertifikaten enthalten [25]. Man müsste sich also durch mindestens 6.000, vermutlich aber eher 10.000 Seiten Dokumentation arbeiten, um einen vollständigen Überblick über die Arbeitsweise und Vertrauenswürdigkeit dieser CAs zu bekommen. Daher muss ein CP/CPS als ein Dokument begriffen werden, das nicht den Zertifikatnutzern, sondern Fachleuten dient . Die CP/ CPS ist der Mittelpunkt der gesamten Dokumentationslage und Startpunkt zur Beurteilung einer Zertifizierungsstelle. Es dient als zentraler Ankerpunkt für Dokumente, die in alle Richtungen zielen: • Zertifikatinhaber benötigen eine Zusammenfassung ihrer Rechte und Pflichten, die in „Subscriber Obligations“oder „Subject Information“-Papieren beschrieben werden. • Mitarbeiter der Zertifizierungsstelle benötigen für interne Zwecke weitere Dokumente wie z.B. ein Sicherheits­konzept, ein Betriebshandbuch und Administrationsdokumentation. • Softwarehersteller, die die CA in ihre Produkte vorinstallieren wollen, verlangen Prüfberichte und weitere Erklärungen zur Konformität mit eigenen Vorgaben. • Auditoren sehen CP/CPS ebenfalls nur als erste Ansatzpunkte, die durch weitere interne und externe Dokumente, Checklisten und Vorgaben ergänzt werden müssen.

WebTrust ETSI TS 102 042 CA/Browserforum Baseline Requirements

RFC3647

CP/CPS

Subject Information Subscriber Obligations

Risikoanalyse

Sicherheitskonzept Betriebshandbuch ........................... Abb. 1: CP/CPS als Ankerpunkt der Dokumentation

SICHERHEIT | DFN Mitteilungen Ausgabe 85 |

Derjenige, der im Internet auf ein Zertifikat stößt, muss sich normalerweise ganz darauf verlassen, dass die CA vorab überprüft wurden, da er nur schwerlich für jedes Zertifikat die dazugehörige CP oder CPS studieren kann. Als Zertifikatnutzer vertraut man dabei den Fachleuten der verwendeten Software, sei es der Webbrowser, das Betriebssystem oder spezielle Anwendungen für qualifizierte Signaturen nach dem Signaturgesetz. Jeder große Betriebssystem- und Browserhersteller hat ein eigenes „Root-Programm“, in dem eine Root CA zunächst geprüft wird, bevor sie in der Software vorinstalliert wird. Die CP/CPS wird dabei immer mit geprüft und ist unabdingbarer Bestandteil des Prozesses. Aber auch andere Organisationen setzen einen Mechanismus um, bei dem die Prüfung von CP/CPS gekapselt wird und an zentraler Stelle für eine Vielzahl von Nutzern erfolgt. Beispiele sind die TeleTrusT European Bridge CA [26] oder die European Grid PMA zusammen mit der International Grid Trust Federation [27]. Die TeleTrust European Bridge CA nutzt eine eigene CP (konform zu RFC 3647), die alle teilnehmenden CAs einhalten müssen, während die European Grid PMA mit sogenannten „Authentication Profiles“ arbeitet, gegen die die Konformität der CP/CPS von CAs geprüft werden.

7 Defizite Wie sich in den Praxisbeispielen schon angedeutet hat, ist der Nutzen von CP/CPS durchaus kritisch zu bewerten. Die von CAs veröffentlichten Dokumente sind bisweilen sehr schwer zu lesen, da entweder irrelevante Allgemeinplätze beschrieben werden oder aber die Detailtiefe so groß ist, das jeder Überblick verloren geht. Dies ist aber nicht nur Schuld der CAs, die sich zu wenig Mühe bei der Gestaltung ihrer Dokumente geben: Gerade an im Webbrowser vorinstallierte CAs werden (zu Recht) ständig neue externe Anforderungen gestellt, die umgesetzt und in CP/ CPS dokumentiert werden müssen. Mozilla, Microsoft und Co. haben in ihren jeweiligen RootProgrammen unterschiedliche Anforderungen, die sich darüber hinaus noch mehr oder weniger häufig ändern. Hinzu kommen weitere Anforderungen aus Standards, die CAs einhalten müssen oder wollen, beispielsweise Webtrust, ETSI oder die Baseline Requirements des CA/Browserforums. Die Einhaltung dieser Standards wird üblicherweise regelmäßig von externen Auditoren überprüft. Je nach Prüfer kann hierbei durchaus jedes Jahr eine neue Verfeinerung von CP/CPS notwendig werden. Das Ergebnis sind die in den Beispielen vorgestellten komplizierten Strukturen von über die Zeit gewachsenen

39

Dokumenten, die sich dem normalen Leser komplett ent­ziehen. Ein weiteres Problem: Die eigentlich vorgesehene einfache Vergleichbarkeit zwischen verschiedenen CAs ist kaum gegeben, da zum einen die Abgrenzung zwischen CP und CPS uneinheitlich gehandhabt wird und zum anderen die Standardgliederung aus RFC 3647 nicht immer konsequent übernommen wird. Des Weiteren ist eine CP oder CPS vollkommen ungeeignet, um Zertifikatinhaber oder -nutzer verbindlich zu einem bestimmten Verhalten zu verpflichten (z.B. Sorgsamkeitspflichten im Umgang mit dem privaten Schlüssel, wie sie oft in Kapitel 4.5 eines RFC 3647-kompatiblen Dokumentes zu finden sind). Hierfür müssen weitere, kürzere Dokumente wie ein „Subscriber Agreement“ oder eine „Subject Information“ genutzt werden, die als Ergänzung zur CP/CPS genau die Aspekte aufgreifen, die für die jeweilige Zielgruppe wirklich relevant sind. Und wenn es um Verpflichtungen zur Prüfung der Zertifikat-Gültigkeit per Sperrliste oder OCSP geht, nützen noch so viele Dokumente nichts: Selbst wenn ein Nutzer weiß, dass er die Gültigkeit eines Zertifikats prüfen soll, so ist er doch darauf angewiesen, dass die verwendete Software diese Aufgabe für ihn erledigt. Hier gibt es viele Probleme: In Mozilla Firefox/Thunderbird sind die Mechanismen für Sperrlisten seit Jahren fehlerhaft, und auch wenn seit einiger Zeit OCSP recht gut unterstützt wird, so wird doch in den Default-Einstellungen bei Nichterreichbarkeit eines OCSP-Servers kein Fehler erzeugt, sondern das Zertifikat einfach als gültig akzeptiert. Noch ärger ist es bei Google Chrome: Anfang 2012 deaktivierte Google die übliche Unterstützung für Sperrlisten und OCSP in den Default-Einstellungen von Chrome und nutzt stattdessen eine stark eingeschränkte Untermenge an Sperrinformationen („CRLSet“), die nach Vorauswahl durch Google per Update-Mechanismus zu den Clients gelangt [28]. Nach etwas mehr als einem Jahr sind in Chromes CRLSet ca. 24.500 Zertifikate als gesperrt markiert, was nur ein ganz kleiner Bruchteil der weltweit von Zertifizierungsstellen gesperrten Zertifikate ist. Es bleibt noch darauf aufmerksam zu machen, dass es sehr einfach ist, eine CP/CPS zu verfassen, das zwar einen beträchtlichen Umfang an Papier oder Festplattenplatz verbraucht, aber keinerlei verwertbare Aussage enthält. Hierzu ein kleines Suchspiel: Wo steckt der Fehler in folgender Formulierung? „Zur Speicherung des privaten Schlüssels der CA kann ein nach FIPS 140-1 Level 3 zertifiziertes Hardware Security Modul verwendet werden.“ Auflösung: Das unscheinbare Wort „kann“ vernichtet jede Verbindlichkeit der Spezifikation. Eine solche CP/CPS könnte zwar den stolzen Titel „Entspricht RFC 3647“ tragen, wäre aber ziemlich nutzlos.

40

| DFN Mitteilungen Ausgabe 85 | November 2013 | SICHERHEIT

8 Fazit Zertifizierungsrichtlinien und Erklärungen zum Zertifizierungsbetrieb sind wichtige öffentliche Dokumente, die für einen Überblick über das allgemeine Sicherheitsniveau der beschriebenen PKI unabdingbar sind und ein gewisses Maß an Transparenz schaffen. Für Fachleute mit genügend Zeit zum Studium der Dokumente ergibt sich ein an einer Stelle gebündelter guter Einblick in die Arbeit einer Zertifizierungsstelle. Allerdings sind die Dokumente oft sehr unhandlich. Beschreibt eine Zertifizierungsstelle dann auch noch mehrere Zertifikattypen in einem Dokument, wird es schnell unlesbar, und man bekommt den Eindruck, dass es doch nicht so sehr um Transparenz, sondern mehr um die formale Erfüllung von externen Vorgaben geht. Es wäre wünschenswert, wenn Zertifizierungsstellen mehr auf die Lesbarkeit ihrer Dokumente und Beschreibungen achten würden. Klar verständliche Informationen für Zertifikatinhaber oder kurze und prägnante Policy Disclosure Statements wären gut geeignet, um mehr Vertrauen in die Arbeitsweise aufzubauen. Allerdings können in CP/CPS nicht alle Aspekte der Sicherheit von Zertifikaten so geregelt werden, dass sich in der Praxis alle Beteiligten daran halten (können). Wenn z.B. große SoftwareHersteller keine vollständige Unterstützung von Sperrmechanismen bieten, lässt sich außerhalb eines gesetzlich reglementierten Bereichs eine Verpflichtung von Nutzern zur Prüfung der Gültigkeit von Zertifikaten durch die Zertifizierungsstelle in der Praxis nicht durchsetzen. Trotzdem sind CP/CPS als Ausgangspunkt für die Dokumentationslage einer Zertifizierungsstelle und als zentrale Sammlung der verbindlichen Verpflichtungen aller beteiligten Rollen unersetzlich. M

Literatur [1] Spiegel Online, „Schludrige Schlüsselmeister gefährden das Web“, http://www.spiegel.de/netzwelt/netzpolitik/internetsicherheitschludrige-schluesselmeister-gefaehrden-das-web-a-786481.html [2] DuD 22 (1998) 9, Dirk Fox, Eine ‚PGP-Policy‘ für Unternehmen [3] ITU-T Recommendation X.509 (11/1988) – THE DIRECTORY – AUTHENTICATION FRAMEWORK [4] ITU-T Recommendation X.509 (11/1993) – THE DIRECTORY – AUTHENTICATION FRAMEWORK [5] ITU-T Recommendation X.509 (08/1997) – THE DIRECTORY – AUTHENTICATION FRAMEWORK [6] IETF, RFC1422, S. Kent, Privacy Enhancement for Internet Electronic Mail: Part II: Certificate-Based Key Management, Februar 1993, http://www.ietf.org/rfc/rfc1422.txt [7] American Bar Association, Digital Signature Guidelines, August 1996 [8] IETF, RFC 2527, S. Chokhani, W. Ford, Internet X.509 Public Key Infrastructure, Certificate Policy and Certification Practices, März 1999, Framework, http://www.ietf.org/rfc/rfc2527.txt [9] IETF, RFC 3647, S. Chokhani, W. Ford, R. Sabett, C. Merrill, S. Wu, Internet X.509 Public Key Infrastructure Certificate Policy and Certification Practices Framework, November 2003, http://www.ietf.org/rfc/ rfc3647.txt [10] ANSI, X9.79 PKI Practices and Policy Framework for the Financial Services Industry, 2001 [11] AICPA/CICA, WebTrust™ Program for Certification Authorities Ver­ sion 1.0, August 25, 2000 [12] ETSI ESI TS 101 456 v1.1.1, Electronic Signatures and Infrastructures (ESI): Policy requirements for certification authorities issuing qualified certificates, Dezember 2000 [13] ETSI ESI TS 102 042 v1.1.1, Electronic Signatures and Infrastructures (ESI): Policy requirements for certification authorities issuing public key certificates, April 2002 [14] Comodo Certification Practice Statement v. 4.0, October 2012, http://www.comodo.com/about/comodoagreements.php [15] DFN-Verein, Zertifizierungsrichtlinien für die DFN-PCA, MediumLevel Policy, Version 1.0, April 1997 [16] DFN-Verein, Zertifizierungsrichtlinien für die DN-PCA, Low-Level Policy, Version 1.0, April 1997 [17] DFN-Verein, Zertifizierungsrichtlinien für die DFN-PCA, Die World Wide Web Policy, Version 1.0, April 1999 [18] DFN-Verein, Policies der DFN-PKI, http://www.pki.dfn.de/policies [19] Symantec Trust Network (STN) Certificate Policy Version 2.8.11, Februar 2013, http://www.verisign.com/repository/index.html [20] Symantec Trust Network (STN) Certification Practices Statement Version 3.8.12, Februar 2013, http://www.verisign.com/repository/ index.html [21] CA/Browser Forum, Baseline Requirements for the Issuance and Man­agement of Publicly-Trusted Certificates, Version 1.1, September 2012, https://www.cabforum.org [22] CA/Browser Forum, Guidelines for the Issuance and Management of Extended Validation (EV) Certificates, Version 1.4, Mai 2012, https:// www.cabforum.org [23] TC TrustCenter, Zertifizierungsrichtlinien, Januar 2010, http://www. trustcenter.de/about/repository.htm [24] TC TrustCenter GmbH, Certification Practice Statement Version 1.9.3, Januar 2010, http://www.trustcenter.de/about/repository.htm [25] Mozilla CA Certificate Store, http://www.mozilla.org/projects/security/certs [26] TeleTrusT European Bridge CA, https://www.ebca.de [27] The European Policy Management Authority for Grid Authentication in e-Science, http://www.eugridpma.org [28] Revocation checking and Chrome‘s CRL, Februar 2012) http://www. imperialviolet.org/2012/02/05/crlsets.html