Punkte sammeln Cacert-Mitglieder, um in den Genuss bestätigter Zertifikate zu kommen. Damit ließen sich Server per SSL/TLS prima absichern, wäre nur das Rootzertifikat den Browsern bekannt. Doch statt sich mit Nachdruck darum zu kümmern, jagt mancher im Projekt vornehmlich seinen Punkten nach.
Sicherheit scheint eine teure Angelegenheit zu sein. Wer etwa seine Webserver mit SSL oder TLS absichern möchte, benötigt dazu Zertifikate, die einige Dienstleister gegen gutes Geld verkaufen (siehe Kasten “Aufbau und Nutzen digitaler Zertifikate”). Da diese meist für einen einzigen DNS-Namen ausgestellt sind, kostet jede neue URL abermals Geld. Außerdem haben diese Bestätigungen eine begrenzte Lebensdauer und sind regelmäßig zu aktualisieren.
|
Aufbau und Nutzen digitaler |
|---|
|
Die Protokollschichten SSL oder TLS sichern – oft vom Benutzer unbemerkt – Onlineverbindungen wie zwischen Browser und Bankinstitut ab. Für die meisten ist allenfalls die URL-Dienstekennung »https« oder das Schlüsselsymbol in der Browser-Adresszeile ein Indiz für die Sicherung. Damit alles klappt, sind zwei Voraussetzungen nötig: starke Verschlüsselungstechnik und abgesicherter Austausch von Schlüsseln. Erstere findet sich heute in fast jedem Browser. Die meisten heute verwendeten Cipher sind so stark, dass sie durchaus auch in sensiblen Bereichen zum Einsatz kommen. SSL und der Nachfolger TLS enthalten außerdem Mechanismen, die neue Verfahren nahtlos und vom Anwender weitgehend unbemerkt integrieren, sollte sich ein älterer Cipher als zu schwach erweisen. Bleibt die Frage, wie zwei Partner in einem nicht vertrauenswürdigen Netz vertrauliche Nachrichten austauschen, insbesondere den Sitzungsschlüssel, der den Datenverkehr wirksam schützt. Hier kommen die Zertifikate ins Spiel, die meist dem X.509v3-Standard entsprechen [2]. Das sind Datenstrukturen, die zwei wesentliche Inhalte besitzen: Den öffentlichen Teil eines asymmetrischen Schlüsselpaars und Angaben dazu, zu welchem Inhaber er gehört, Identität genannt. Im Fall eines Webservers könnte das sein DNS-Name, im Fall einer Person könnten das ihre E-Mail-Adresse oder ihr Name sein. Klare Abläufe sind Grundlage für VertrauenEssenziell ist die zweifelsfreie und nicht fälschbare Verbindung aus beiden genannten Angaben. Das bestätigt eine digitale Signatur unter dem Zertifikat. Die Güte einer solchen Public Key Infrastruktur, oft PKI genannt, ergibt sich daher nicht nur aus der eingesetzten Technik, sondern auch daraus, wie vertrauenwürdig die Beteiligten handeln. Insbesondere der Aussteller der digitalen Signaturen, die so genannte Certificate Authority (CA), sollte eine hinreichende Seriosität ausstrahlen. Unternehmen wie Verisign oder Thawte zum Beispiel betreiben kommerziell ausgerichtete CAs und verlangen Geld dafür, dass sie Zertifikate nur dann signieren, wenn der angegebene Inhaber authentisch ist. Zusätzlich sorgen alle CAs dafür, wirksame Maßnahmen vorzuhalten, um solche Antragsteller zurückzuweisen, die sich mit einer fremden Identität melden. Eine Bezahlung fällt somit nicht in erster Linie für das faktische Erzeugen der Signatur und damit für das Zertifikat an sich an, sondern vielmehr für das Vorhalten der dafür notwendigen Prozesse und Abläufe. |
Zertifikate an sich lassen sich jedoch günstig herstellen: Bereits wenige Open-SSL-Kommandos erzeugen sie. Aufwändig ist hingegen die Infrastruktur, diese Arbeiten transparent und sicher auszuführen. Im Jahr 2002 war eine Gruppe Freiwilliger der Ansicht, dass ein Projekt diese Arbeiten erbringen könnte, und gründete 2003 in Australien die ehrenamtlich arbeitende Körperschaft “Cacert Incorporated”. Unter ihrem Dach stellt seitdem das Projekt über seine Website interessierten Anwendern die für eine asymmetrische Kryptographie notwendigen Schlüsselpaare ebenso wie die für eine Verifizierung der Schlüssel nutzbaren Public-Key-Zertifikate kostenlos zur Verfügung.
Hierarchische Community
Das Cacert-Projekt unterscheidet Teilnehmer hierarchisch zwischen einfachen Community-Mitgliedern, Assurern, Super-Assurern, Associated Members und dem Cacert-Board. Einfache Mitglieder treten Cacert auf der Website bei, indem sie ein Formular ausfüllen und ihre E-Mail-Adresse übermitteln [1]. Anschließend verschickt Cacert eine Verifizierungsnachricht an diese Adresse, die der Nutzer seinerseits durch Aufruf eines in der E-Mail enthaltenen Links bestätigt. Fortan darf sich das neuen Mitglied ein einfaches Zertifikat (unassured) ausstellen lassen.
Da die Authentifikation über E-Mail gemeinhin als nur mäßig vertrauenswürdig gilt, haben die auf eine E-Mail-Adresse ausgestellten Zertifikate nur eine Gültigkeit von sechs Monaten, um Missbrauch einzuschränken. Weist sich der Antragsteller jedoch gegenüber Cacert persönlich aus, enthält das Zertifikat den Personennamen und die Gültigkeit beträgt 24 Monate.
Die Gültigkeitsdauern von sowohl Server- als auch Clientzertifikaten hängen daher von der Identitätsprüfung ab, bei der sich das Mitglied und spätere Inhaber gegenüber dem Projekt mit einem offiziellen Dokument ausweist. Das ist die Kernaufgabe, der sich Cacert stellt.
Mitmachen erwünscht
Die verlässliche Verifikation von Individuen ist die aufwändigste Leistung einer Certificate Authority. Cacert löst das Problem dadurch, dass es seine Mitglieder dazu einlädt, das Projekt aktiv durch Teilnahme am Assurance-Programm zu unterstützen. Ist die Identität eines Mitglieds persönlich verifiziert und hat es eine Prüfung abgelegt und bestanden, erhält es den Status eines Assurers. Die nehmen als offizielle Vertreter an Veranstaltungen teil und bestätigen die Identität weiterer Mitglieder. Damit bilden sie das Web of Trust des Cacert-Projekts.
Neben den Assurern benennt die Cacert-Website auch Super-Assurer. Ihr Alleinstellungsmerkmal gegenüber Assurern bleibt jedoch unklar. In der Theorie zeichnen sich Super-Assurer durch mehr Erfahrung sowie Einsatz für das Projekt aus und übernehmen aufgrund ihrer Qualitäten besondere Aufgaben. Mitglieder mit Super-Assurer-Status treten bei Veranstaltungen in der Praxis jedoch nicht in allen Ländern auf.
Um als Associated Member beizutreten, stellen User einen Antrag auf Mitgliedschaft bei Cacert Inc. und zahlen einen Jahresbeitrag von 10 US-Dollar. Dafür können sie auch in den Vorstand (Board) gewählt werden. Der zeichnet für die Ausrichtung der Organisation verantwortlich. Die auf der Website veröffentlichte Statistik wies Mitte September 2010 insgesamt 181764 erfolgreich registrierte Nutzer sowie 3860 Assurer aus [3].
Die nach der einfachen E-Mail-Verifikation vergebenen Clientzertifikate weisen den Antragsteller selbst aus oder genauer gesagt seine E-Mail-Adresse. Ein Webserver lässt sich damit noch nicht schützen. Cacert unterscheidet nämlich Client-, Server- und Codezertifikate. Ein Clientzertifikat verifiziert E-Mail-Absender und ermöglicht es, Nachrichten mit dem asymmetrischen Schlüsselpaar und zum Beispiel Open PGP oder Kgpg verschlüsselt zu übertragen oder zu signieren.
Ausweise für alle
Cacert erzeugt Schlüsselpaare für seine Mitglieder selbst und überträgt sie anschließend ebenfalls verschlüsselt an den Anwender. Benutzt der beispielsweise Mozillas Firefox, so installiert sich das Zertifikat anschließend dort automatisch (siehe Abbildung 1).

Abbildung 1: Firefox installiert das generierte Zertifikat automatisch und teilt dies in einem Hinweisfenster mit. Anwender finden es unter »Bearbeiten | Einstellungen | Verschlüsselung | Zertifikate anzeigen« wieder.
Der Export des im Browser eingebundenen Zertifikats in eine Datei und der anschließende Import in ein E-Mail-Programm erlaubt es dem Anwender, das Schlüsselpaar zum Signieren und Verschlüsseln zu verwenden: Unter »Bearbeiten | Einstellungen | Verschlüsselung | Zertifikate anzeigen« markiert er das Zertifikat und wählt »Sichern …« (siehe Abbildung 2). Nach der Vergabe eines Dateinamens liegt das von Cacert generierte Schlüsselpaar in der Export-Datei vor [5]. Der Anwender sollte diese im PKCS#12-Format [6] vorliegende Datei besonders sorgfältig schützen, da sie auch den privaten Schlüssel enthält (siehe Abbildung 3).

Abbildung 2: Nach Eingabe eines Dateinamens erzeugt ein Klick auf »Sichern« eine PKCS#12-Datei zum Exportieren, die neben dem öffentlichen auch den privaten Schlüssel des Zertifikats enthält. Sie bedarf besonderen Schutzes.

Abbildung 3: Ein Passwort schützt das Schlüsselpaar in der Export-Datei. Der Anwender importiert bei Bedarf ihren Inhalt in sein E-Mail-Programm und nutzt die erzeugten privaten Schlüssel zum Dekodieren von Nachrichten an ihn.
Gegen das Abhören während der Übertragung eines den privaten Schlüssel enthaltenden Zertifikats schützt sich der Nutzer, indem er zunächst ein Schlüsselpaar auf dem eigenen System erzeugt. Danach lädt er beim folgenden Certificate Signing Request (CSR) nur den öffentlichen Schlüssel zur Generierung des Zertifikats auf den Cacert-Server hoch.
Server mit Identität
Wollen Administratoren Webanwendungen schützen, greifen sie auf Cacerts Serverzertifikate zurück. Das Projekt vergibt sie sowohl für die Host- als auch für Wildcard-Nutzung, um damit Web- oder IMAP-Server fit für SSL und TLS zu machen. Dieses Einsatzszenario ist vermutlich für Anwender der nützlichste Dienst von Cacert. Website-Betreiber profitieren von der erhöhten Sicherheit bei Internetverbindungen, drückt die Verschlüsselung von Kundendaten doch notwendige Professionalität aus.
Auch hier bedürfen die bestätigten Zertifikate einer persönlichen Identifikation des Antragstellers (siehe Abbildung 4). Sie enthalten daher neben dem Domainnamen des Servers auch den vollen Namen des Inhabers. Zur Identifikation legt das Mitglied am einfachsten den Personalausweis persönlich einem Assurer auf einer der weltweit stattfindenden Cacert-Veranstaltungen vor. Schneller geht die Bestätigung, wenn er mehrere Identitätsnachweise vorlegt. Durch die Bestätigung verlängert sich die Gültigkeit beider Zertifikatsarten auf 24 Monate.

Abbildung 4: Je nach Status dürfen Cacert-Mitglieder unterschiedliche Zertifikate ausgeben. Mitglieder benötigen 50 Punkte, um bestätigte Client- oder Serverzertifikate zu erhalten. Ab 100 Punkte dürfen sie eine Prüfung zum Assurer ablegen. Die bestätigten Zertifikate gelten in der Regel 24 Monate.
Codezertifikate, die dritte Kategorie, zur Signierung von Programmcode enthalten immer den vollen Namen des Inhabers und setzen in jedem Fall eine persönliche Identifikation voraus. Mit Codezertifikaten können Entwickler das Ausführen von bestimmtem Programmcode bei fehlendem oder falschem Zertifikat unterbinden. Ihre Gültigkeitsdauer beträgt durchgehend zwölf Monate.
Nur persönlicher Nachweis
Die ehemals angebotene Identitätsprüfung mit Hilfe von Trusted Third Parties (TTP), also durch vertrauenswürdige Drittparteien wie Notare, Richter, Anwälte, Bankbedienstete oder vereidigte Bilanzprüfer, steht zurzeit nicht mehr zur Verfügung. Ein Identitätsnachweis auf dem Postweg gegenüber Cacert ist somit für Anwender unmöglich. Mitglieder müssen bei einer der Cacert-Veranstaltungen persönlich vorbeischauen.
Der Anwender haftet bei allen drei Zertifikatstypen für den Missbrauch seines jeweiligen Zertifikats der Cacert Inc. gegenüber mit einem Betrag von derzeit 1000 US-Dollar für aufgetretene Missbrauchsfälle. Sollten unberechtigte Dritte mit gestohlenen Zertifikaten Straftaten begehen, könnte theoretisch auch der Inhaber des Rootzertifikats zur Rechenschaft gezogen werden.
Die vorstehende Regelung gibt Cacert die Möglichkeit, ihrerseits die Zertifikatsinhaber auf Schadensersatz zu verklagen. In Deutschland wäre dies wohl auf Fälle begrenzt, die ein Inhaber durch eine grobe Fahrlässigkeit herbeiführt.
Falls die Cacert Inc. selbst in Rechenschaft gezogen wird, müsste sie ihre Ansprüche gegen den Zertifikatsinhaber über Landesgrenzen hinweg durchsetzen. Das erscheint jedoch unwahrscheinlich. Auch ist es fraglich, inwieweit die nach australischem Recht getroffene Regelung in Deutschland nach internationalem Recht gültig und durchzusetzen ist.
Anhaltendes Interesse
Das Projekt veröffentlicht Statistiken zu verteilten Zertifikaten. Die Angaben auf der Website erscheinen auf den ersten Blick positiv: Bis Mitte September 2010 gab Cacert insgesamt 627184 Zertifikate aus (siehe Tabelle 1), in den zwölf Monaten davor waren es 85907. Zum Stichtag besitzen jedoch nur noch 83985 der jemals ausgegebenen Zertifikate Gültigkeit (siehe Tabelle 2). In anderen Worten: Inhaber von Zertifikaten verlängern diese nur in 13,7 Prozent der Fälle. Cacert-Mitglieder räumen ein, dass die Zertifikatsverwaltung verbesserungsfähig ist, und verweisen auf die Vielzahl an Anwendungen bei Nutzern.
|
Tabelle 1: |
|||
|---|---|---|---|
|
Jahr |
Neue Nutzer |
Neue Assurer |
Neue Zertifikate |
|
2010 |
19768 |
624 |
58803 |
|
2009 |
29846 |
1390 |
103432 |
|
2008 |
29172 |
1463 |
116908 |
|
2007 |
26809 |
1974 |
107481 |
|
2006 |
31828 |
2864 |
110014 |
|
2005 |
28114 |
3367 |
88870 |
|
2004 |
13306 |
855 |
35417 |
|
2003 |
2760 |
75 |
3994 |
|
2002 |
161 |
147 |
|
|
Tabelle 2: Fakten |
|
|---|---|
|
Kennzahl |
Anzahl |
|
verifizierte Nutzer |
181764 |
|
verifizierte E-Mail-Adressen |
233573 |
|
verifizierte Domains |
121307 |
|
ausgegebene Zertifikate |
627184 |
|
gültige Zertifikate |
83985 |
|
von Assurern durchgeführte |
128297 |
|
Nutzer mit 1 bis 49 Punkten |
5569 |
|
Nutzer mit 50 bis 99 Punkten |
4380 |
|
Assurer-Kandidaten |
10036 |
|
Assurer mit Prüfung |
3860 |
|
vergebene Punkte |
2134390 |
Trotz dieser Hürden probieren viele von ihnen das kostenlose Zertifikatswesen von Cacert jedes Jahr aufs Neue aus (Abbildung 5). Doch die Nichterneuerung vieler Zertifikate weist auf zwei Probleme hin: Zum einen probieren die Anwender die Zertifikate aus, schätzen den Nutzen auf Dauer aber gering ein und kehren dem Projekt den Rücken. Zum anderen erzeugen sich Teilnehmer lieber neue Zertifikate, als alte zu verlängern, weil das Verlängern als komplex gilt.

Abbildung 5: Obwohl sich seit 2005 konstant neue Mitglieder anmelden (blau), stagniert die Zahl aktiven Zertifikate (gelb). Nutzer schätzen zwar das kostenlose Angebot, haben aber Probleme mit den komplexen Regeln zur Verlängerung.
Bei wenigen inklusive
Sicherheitsbewusste Anwender schrecken vor Websites zurück, die mit einer Nachfrage Zustimmung zu einem neuen Zertifikat oder gar eine händische Installation von Rootzertifikaten oder das manuelle Prüfen von Zertifikat-Fingerprints fordern. Kommen die Rootzertifikate in den Anwendungen bereits mit der Installation des Betriebssystems oder des Browsers, erhöht sich die Akzeptanz.
Gängige Browsermodelle oder Desktop-Oberflächen enthalten bereits viele gültige Rootzertifikate der kommerziellen CAs. Anwender sollten sich bewusst sein, dass sie damit eine wichtige Sicherheitsaufgabe an die Anbieter ihrer Software delegieren, und sich über die Kriterien informieren, nach denen das geschieht. Leider sind diese oft wenig transparent. Das Rootzertifikat von Cacert fehlt jedoch bislang in den bekannten Browsern oder Distributionen (siehe Abbildung 6). Eine Ausnahme stellt Knoppix dar. Bei Debian enthält das per Apt nachinstallierbare Paket »ca-certificates« unter anderem das Cacert-Rootzertifikat.

Abbildung 6: Warnhinweise auf fehlende Zertifikate erschrecken normale Internetnutzer. Das Rootzertifikat der Cacert-CA ist den meisten Browsern standardmäßig nicht bekannt und sorgt dann für Irritationen bei Anwendern.
Das Fehlen des Cacert-Rootzertifikats in vielen Browsern begründet sich bei näherer Betrachtung nicht alleine als eine Frage des Geldes, das Browserhersteller für ihre eigene Prüfung des Rootzertifikats der CA in Rechnung stellen. Vielmehr spielen sicherheitskritische Faktoren wie die Schlüsselgenerierung, -vorhaltung und -übertragung bei den Browserentwicklern und Distributoren eine ganz zentrale Rolle. Deshalb erwarten viele, dass eine CA mit einem Audit aus eigener Initiative ihre Maßnahmen zur Qualitätssicherung darlegt.
Dürftige Dringlichkeit
Wer die Arbeit des Projekts seit seiner Gründung betrachtet, fragt sich bisweilen, wieso es auf diesen Aspekt so wenig Wert zu legen scheint. Stattdessen befassten sich die meisten Aktivitäten der vergangenen Jahre mit internen Organisationsfragen und dem Ausstellen nur untereinander akzeptierter Zertifikate. Schauen sich interessierte Nutzer auf den Projekt-Webseiten um, finden sie kaum oder erst nach längerem Suchen Informationen zu den technischen Aspekten.
Angaben etwa zur Zertifikatseinbindung und -vorhaltung beziehungsweise der Übertragung, internen Speicherung und Nutzung der privaten Schlüssel sind vergleichsweise schwer zu finden – problematisch für eine CA [4]. Demgegenüber befassen sich viele Dokumente und Einzelseiten mit dem Themenkomplex der “Organisation der Organisation” und Cacerts Punktesystem.
Die Projektdokumentation unternimmt viele Anstrengungen, die Glaubwürdigkeit von Cacert zu stärken. Andere CAs verankern diese, indem sie ein strenges hierarchisches System etablieren: Ein Rootzertifikat bildet die Basis sämtlicher von ihr ausgehenden Zertifikate. Eine solche CA führt in der Regel alle dafür notwendigen Identitätsprüfungen selbst durch. Dann stellt ein einzelnes gefälschtes Zertifikat auch nicht die Glaubwürdigkeit der ganzen CA in Frage.
Cacert hingegen verbindet durch seine Organisation den zum Beispiel von Open PGP her bekannten Web-of-Trust-Ansatz mit der strengen hierarchischen Gliederung einer Certificate Authority: Auf der einen Seite gibt sich Cacert aufeinander aufbauende Regeln, die einzuhaltende Verfahrensschritte und zu beteiligende Instanzen definieren. Auf der anderen Seite identifizieren sich die Zertifikatsinhaber nicht direkt gegenüber Cacert, sondern gegenüber Assurern, die das Cacert-Web-of-Trust ausbilden.
Hybrides Vertrauensmodell
Diese Crossover-Verifizierung stellt die Identität der Instanzen untereinander fest und nicht die einer übergeordneten Stelle, die ihrerseits Engpass oder Angriffspunkt sein kann. Welches Modell Vertrauen besser abbildet, ist Gegenstand vieler Diskussionen, jeder Anwender muss dies letztlich für sich selbst entscheiden.
Cacert versucht die Glaubwürdigkeit seiner ausgegebenen Zertifikate durch ein ausgeklügeltes Punktesystem zu untermauern. Mitglieder sammeln durch die Bestätigung ihrer persönlichen Identität Punkte. Die wiederum ermöglichen es den Mitgliedern, länger gültige Zertifikate zu erhalten oder die Assurer-Prüfung abzulegen. Unbestätigte einfache Zertifikate besitzen die geringste Glaubwürdigkeit, was sich in einer geringen Gültigkeitsdauer und im Fehlen des Inhabernamens niederschlägt.
Punkte als Qualitätsmaß
Ab einer bestimmten Punktzahl darf ein Mitglied seine einfachen Zertifikate in bestätigte umwandeln. Die Punkte dazu sammelt es beispielsweise auf Cacert-Veranstaltungen, indem ein Assurer persönlich seine Identität bestätigt. 50 Punkte erlauben es dem einfachen Mitglied, bestätigte Zertifikate zu erlangen. Eine vergleichbare Regelung betrifft Serverzertifikate, mit denen Mitglieder ihre Web- oder IMAP-Server sichern können. Die genannte Punktzahl setzt Cacert auch für Codezertifikate voraus.
Durch Identitätsprüfungen gesammelte 100 Punkte ermöglichen es einem Mitglied, sich zur Assurer-Prüfung anzumelden. Je mehr Punkte ein Assurer besitzt, desto mehr erhalten ihrerseits die von ihm identitätsgeprüften einfachen Mitglieder. Er vergibt so zwischen 10 und 35 Punkte an Mitglieder, die sich durch ihn ihre Identität bestätigen lassen.
Die Höhe der zu vergebenden Assurer-Punkte drückt bei diesem Modell das Maß der Vertrauenswürdigkeit eines Assurers aus. Sie bewerten also, wie viele hoffentlich kompetente Assurer ein Mitglied getroffen hat. Als Maß für die Vertrauenswürdigkeit der zertifizierten Person selbst taugt er jedoch wenig.
Die maximal erreichbare Punktzahl hat das Cacert-Board in seinen Regularien auf 200 festgelegt. Höchstens 150 davon sammelt das Mitglied durch Identitätsnachweise von Assurern. Nach bestandener Prüfung erhalten die Assurer für jede getätigte Identitätsprüfung eines einfachen Mitglieds ihrerseits zwei Punkte (siehe Abbildung 4). Ab diesem Zeitpunkt haben die Punkte also eine andere Bedeutung: Sie symbolisieren nun die Produktivität des Assurers für das Projekt. Spätestens dies hat mit einem Maß für Vertrauenswürdigkeit nur noch wenig zu tun. Jeder Super-Assurer verfügt auf seinem Punktekonto über die maximale Anzahl von 200 Punkten.
Das Punktesystem präsentiert sich auf den ersten Blick als von vielen Audits geforderte Qualitätssicherungsmaßnahme, dennoch fallen bei näherer Betrachtung einige Ungereimtheiten auf: Die Punkte suggerieren, dass Mitglieder mit einer hohen Punktzahl über umfangreiches Wissen bezüglich Zertifikatsstrukturen besitzen und sich längerfristig im Projekt engagiert haben.
Dem steht die Erkenntnis gegenüber, dass selbst ein neues Mitglied 100 oder gar 150 Punkte leicht an einem Nachmittag auf einer Konferenz sammelt. Drei oder vier Bekannte reichen aus, und das einfache Mitglied legt nach thematischer Vorbereitung bereits die Assurer-Prüfung ab. Die restlichen notwendigen 50 Punkte bis zum Status des Super-Assurers sammeln die Assurer ziemlich leicht, indem sie zum Beispiel ihre Kommilitonen oder ihre ganze Sportriege nach und nach assuren. Hinzu kommt, dass das Board die nicht für alle Zeiten festgeschriebenen Punkteregeln bei Gefallen aufheben oder ändern kann.
Hatz nach dem Highscore
Die Forderung nach einer bestimmten Punktezahl ist somit keine ernsthafte Hürde gegen das Vortäuschen von versprochener Eigenschaften. Sie ist auch kein Garant für fachliche Kompetenz oder Engagement. Als Entscheidungs- oder Qualitätskriterium, das Rootzertifikat in eine Anwendung zu implementieren, taugen Punkte nicht.
Eine regelrechte Jagd der Mitglieder nach hohen Punktezahlen fördert zudem nicht den verantwortungsvollen Umgang mit sicherheitsrelevanten Daten oder Zertifikaten. Von dem Wunsch nach hohen Punktezahlen und ihrer Bedeutsamkeit für den Einzelnen getreu dem Motto “Mehr Punkte sind besser” profitiert im Zweifel eine auch beim Cacert-Projekt nicht auszuschließende Vetternwirtschaft. Ob somit Punkte eine gute Grundlage für die Ausbildung eines Web of Trust darstellen, bleibt zweifelhaft.
Ehrenhafte Motive
Die Ziele von Cacert sind ehrenhaft: kostenlose Zertifikate für Authentifikation und Verschlüsselung einer interessierten Öffentlichkeit in Form eines Projekts bereitstellen. Die Entscheidung, ein Web of Trust für die Modellierung von Vertrauen heranzuziehen, erscheint zwar durchaus folgerichtig, ist aber diskussionswürdig. Doch offenbar dreht sich das Projekt im Wesentlichen nur noch um sich selbst, befasst sich mit einer wenig transparenten Eigenorganisation und hechelt Punkte-Rekorden hinterher.
Für Anwender wichtige Fragen wie die Voraussetzungen für das Einbetten des Rootzertifikats in Browser wie Firefox & Co. haben offenbar eine niedrigere Priorität. Alleine am Geld für ein Audit kann es kaum liegen, denn das Thema dümpelt schon seit mehreren Jahren vor sich hin. Auch die technische Umsetzung ist noch verbesserungswürdig. Dass Cacert private Schlüssel eingebettet überträgt, bewerten manche Anwender kritisch. Denn die lassen sich auch selbst generieren. Nur der Public Key ist beim Signieren notwendig.
Cacert steckt in einer Zwickmühle: Das Vertrauen in die eingesetzte Technik und die Transparenz der Abläufe sind unabdingbar für eine CA. Andererseits muss das Projekt irgendwann auch einmal Ergebnisse zeigen. Gelingt es in Zukunft, das Verfahren zur Anwendung der Zertifikate und der in ihnen enthaltenen Schlüssel zu vereinfachen, die Nutzer insgesamt mehr zu binden und das Rootzertifikat in Browsern standardmäßig zu hinterlegen, dann nähert sich Cacert seinem Ziel bedeutend schneller – kostenlose Zertifikate für jedermann zur Verfügung zu stellen und den Anwendern eine wirkliche Alternative zu den etablierten kommerziellen Anbietern zu bieten.
|
Infos |
|---|
|
[1] Cacert:[http://www.cacert.org/index.php?id=1] [2] Spezifikation X.509v3: [http://www.itu.int/rec/T-REC-X.509-200508-I] [3] Statistiken zum Cacert-Projekt:[http://www.cacert.org/stats.php] [4] Projekt-Wiki: [http://wiki.cacert.org] [5] Zertifikatserstellung: [http://ivamp.de/cert/CACert_Zertifikatserstellung_Mail.pdf] [6] Public-Key Cryptography Standards (PKCS): [http://rsa.com/rsalabs/node.asp?id=2124] |
|
Der Autor |
|---|
|
Kay Königsmann arbeitete seit 1999 zunächst als Datenbank- und Java-Dozent, später im Projektmanagement. Seine Schwerpunkte sind Debian sowie IT-Security. Er ist Autor zahlreicher Fernlehrgänge für die Erwachsenenweiterbildung. |







