1. Einführung

Dieses Dokument definiert ein neues HTTP-Headerfeld ([RFC9110], Abschnitt 6.3), das es UAs ermöglicht, Web-Hosts zu identifizieren, die das Vorhandensein von signierten Zertifikatstimestempeln (SCTs) [RFC9162] in nachfolgenden Transport Layer Security (TLS) [RFC8446]-Verbindungen erwarten.

Web-Hosts, die das Expect-CT-Headerfeld bereitst ellen, werden vom UA als "bekannte Expect-CT-Hosts" notiert. Der UA bewertet jede Verbindung zu einem bekannten Expect-CT-Host auf Konformität mit der Certificate Transparency (CT)-Richtlinie des UA. Wenn die Verbindung gegen die CT-Richtlinie verstößt, sendet der UA einen Bericht an eine vom Expect-CT-Host konfigurierte URI und/oder lässt die Verbindung fehlschlagen, abhängig von der Konfiguration, die der Expect-CT-Host gewählt hat.

Bei Fehlkonfiguration kann Expect-CT unerwünschte Verbindungsausfälle verursachen. Web-Host-Betreibern wird geraten, Expect-CT mit Vorsichtsmaßnahmen bereitzustellen, indem sie die Berichtsfunktion verwenden und das Zeitintervall schrittweise erhöhen, während dessen der UA den Host als bekannten Expect-CT-Host betrachtet.

Expect-CT ist ein Trust-on-First-Use (TOFU)-Mechanismus. Wenn ein UA zum ersten Mal eine Verbindung zu einem Host herstellt, fehlen ihm die notwendigen Informationen, um SCTs für die Verbindung zu verlangen. Dennoch bietet Expect-CT Wert, indem es 1) UAs ermöglicht, die Verwendung nicht protokollierter Zertifikate nach der ersten Kommunikation zu erkennen, und 2) Web-Hosts sicher sein können, dass UAs nur öffentlich überprüfbaren Zertifikaten vertrauen.

Expect-CT ähnelt HTTP Strict Transport Security (HSTS) [RFC6797] und HTTP Public Key Pinning (HPKP) [RFC7469]. HSTS ermöglicht es Websites, sich als nur über sichere Verbindungen zugänglich zu erklären, und HPKP ermöglicht es Websites, ihre kryptographischen Identitäten zu deklarieren. Ähnlich ermöglicht Expect-CT Websites, sich als nur über CT-richtlinienkonforme Verbindungen zugänglich zu deklarieren.

Diese Expect-CT-Spezifikation ist kompatibel mit [RFC6962] und [RFC9162], aber nicht notwendigerweise mit zukünftigen Versionen von Certificate Transparency.

1.1. Anforderungssprache

Die Schlüsselwörter "MUSS", "DARF NICHT", "ERFORDERLICH", "SOLL", "SOLL NICHT", "SOLLTE", "SOLLTE NICHT", "EMPFOHLEN", "NICHT EMPFOHLEN", "KANN" und "OPTIONAL" in diesem Dokument sind wie in BCP 14 [RFC2119] [RFC8174] beschrieben zu interpretieren, wenn und nur wenn sie in Großbuchstaben erscheinen, wie hier gezeigt.

1.2. Terminologie

"Certificate Transparency Policy (Zertifikatstransparenz-Richtlinie)"

Eine vom UA definierte Richtlinie bezüglich der Anzahl, Quellen und Zustellmechanismen von signierten Zertifikatstimestempeln, die mit TLS-Verbindungen verknüpft sind.

"Certificate Transparency Qualified (Zertifikatstransparenz-qualifiziert)"

Beschreibt eine TLS-Verbindung, für die der UA festgestellt hat, dass eine ausreichende Menge und Qualität von signierten Zertifikatstimestempeln bereitgestellt wurde.

"CT Qualified (CT-qualifiziert)"

Eine Abkürzung für "Certificate Transparency Qualified".

"CT Policy (CT-Richtlinie)"

Eine Abkürzung für "Certificate Transparency Policy".

"Effective Expect-CT Date (Effektives Expect-CT-Datum)"

Der Zeitpunkt, zu dem ein UA ein gültiges Expect-CT-Headerfeld für einen bestimmten Host beobachtet hat.

"Expect-CT Host (Expect-CT-Host)"

Ein konformer Host, der die HTTP-Serveraspekte von Expect-CT implementiert.

"Known Expect-CT Host (Bekannter Expect-CT-Host)"

Ein Expect-CT-Host, den der UA als solchen notiert hat. Siehe Abschnitt 2.3.2.1 für Details.

"User Agent (UA, Benutzeragent)"

Für die Zwecke dieser Spezifikation ist ein UA eine HTTP-Client-Anwendung, die typischerweise aktiv von einem Benutzer manipuliert wird [RFC9110].

"Unknown Expect-CT Host (Unbekannter Expect-CT-Host)"

Ein Expect-CT-Host, den der UA nicht notiert hat.