1. Informal Introduction (Informelle Einführung)
1. Informal Introduction (Informelle Einführung)
Certificate Transparency (Zertifikatstransparenz) soll das Problem fälschlich ausgestellter Zertifikate mildern, indem öffentlich prüfbare, nur anhängende (append-only) und als nicht vertrauenswürdig behandelte Logs (Protokolle) aller ausgestellten Zertifikate bereitgestellt werden. Die Logs sind öffentlich prüfbar, sodass jeder die Korrektheit jedes Logs verifizieren und beobachten kann, wann neue Zertifikate hinzugefügt werden. Die Logs verhindern falsch ausgestellte Zertifikate nicht selbst, stellen aber sicher, dass interessierte Parteien (insbesondere die in Zertifikaten genannten) solche Fehlausstellung erkennen können. Dies ist ein allgemeiner Mechanismus; in diesem Dokument wird jedoch nur seine Verwendung für öffentliche TLS-Serverzertifikate beschrieben, die von öffentlichen Certificate Authorities (Zertifizierungsstellen, CAs) ausgestellt werden.
Jedes Log besteht aus Zertifikatsketten, die von jedem eingereicht werden können. Es wird erwartet, dass öffentliche CAs alle neu ausgestellten Zertifikate an ein oder mehrere Logs melden; ebenso wird erwartet, dass Zertifikatsinhaber ihre eigenen Ketten einreichen. Um zu verhindern, dass Logs mit Spam unbrauchbar werden, ist ERFORDERLICH, dass jede Kette in einem bekannten Stammzertifikat der CA verwurzelt ist. Wird eine Kette an ein Log übermittelt, wird ein signierter Zeitstempel zurückgegeben, der später als Nachweis gegenüber Clients dienen kann, dass die Kette eingereicht wurde. TLS-Clients können daher verlangen, dass alle gesehenen Zertifikate geloggt wurden.
Wer sich um Fehlausstellung sorgt, kann die Logs überwachen, sie regelmäßig nach allen neuen Einträgen fragen und so prüfen, ob für von ihnen verantwortliche Domänen Zertifikate ausgestellt wurden, die sie nicht erwartet haben. Was mit diesen Informationen geschieht, insbesondere wenn eine Fehlausstellung festgestellt wird, liegt außerhalb des Geltungsbereichs dieses Dokuments; grob gesprochen können bestehende geschäftliche Mechanismen zur Behandlung falsch ausgestellter Zertifikate genutzt werden. Natürlich kann jeder, der möchte, die Logs überwachen und, wenn er der Meinung ist, ein Zertifikat sei fälschlich ausgestellt, nach eigenem Ermessen handeln.
Ebenso können diejenigen, die signierte Zeitstempel eines bestimmten Logs gesehen haben, später einen Inclusion Proof (Einschlussnachweis) von diesem Log verlangen. Kann das Log diesen nicht liefern (oder fehlt das entsprechende Zertifikat in den Kopien der Monitore), ist das ein Indiz für fehlerhaften Log-Betrieb. Die Prüfoperation ist asynchron, damit TLS-Verbindungen trotz Netzproblemen und Firewall-Besonderheiten ohne Verzögerung fortgesetzt werden können.
Die Append-Only-Eigenschaft (nur-anhängbar) jedes Logs wird technisch mit Merkle Trees (Merkle-Bäumen) erreicht, mit denen gezeigt werden kann, dass eine bestimmte Version des Logs eine Obermenge einer bestimmten früheren Version ist. Merkle-Bäume vermeiden zudem blindes Vertrauen in Logs: Versucht ein Log, verschiedenen Personen unterschiedliche Ansichten zu zeigen, lässt sich dies effizient durch Vergleich von Tree Roots (Baumwurzeln) und Consistency Proofs (Konsistenzbeweisen) erkennen. Ebenso lassen sich andere Fehlverhalten eines Logs (z. B. signierte Zeitstempel für Zertifikate ausstellen, die es dann nicht loggt) effizient nachweisen und der Öffentlichkeit belegen.