Konzept und Nutzen von Certificate Policy und Certification Practice

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