3. Meldung von Expect-CT-Fehlern

Wenn der UA versucht, sich mit einem bekannten Expect-CT-Host zu verbinden, und die Verbindung nicht CT-qualifiziert ist, SOLLTE der UA Expect-CT-Fehler an den report-uri melden, falls vorhanden, in den Expect-CT-Metadaten des bekannten Expect-CT-Hosts.

Wenn der UA ein Expect-CT-Antwortheaderfeld über eine Verbindung empfängt, die nicht CT-qualifiziert ist, falls der UA noch keinen Expect-CT-Bericht für diese Verbindung gesendet hat, dann SOLLTE der UA Expect-CT-Fehler an den konfigurierten report-uri melden, falls vorhanden.

3.1. Generierung eines Verletzungsberichts

Um ein Verletzungsberichtsobjekt zu generieren, konstruiert der UA ein JSON [RFC8259]-Objekt mit den folgenden Schlüsseln und Werten:

"date-time" - Der Wert für diesen Schlüssel gibt die UTC-Zeit an, zu der der UA den CT-Konformitätsfehler beobachtet hat. Der Wert ist eine Zeichenkette, die gemäß Abschnitt 5.6 von [RFC3339], „Internet Date/Time Format", formatiert ist.

"hostname" - Der Wert ist der Hostname, an den der UA die ursprüngliche Anfrage gestellt hat, die die CT-Konformitätsprüfung nicht bestanden hat. Der Wert wird als Zeichenkette bereitgestellt.

"port" - Der Wert ist der Port, an den der UA die ursprüngliche Anfrage gestellt hat, die die CT-Konformitätsprüfung nicht bestanden hat. Der Wert wird als Ganzzahl bereitgestellt.

"scheme" - (optional) Der Wert ist das Schema, mit dem der UA die ursprüngliche Anfrage gestellt hat, die die CT-Konformitätsprüfung nicht bestanden hat. Der Wert wird als Zeichenkette bereitgestellt. Dieser Schlüssel ist optional und wird als „https" angenommen, wenn er nicht vorhanden ist.

"effective-expiration-date" - Der Wert gibt das effektive Ablaufdatum (siehe Abschnitt 2.3.2.2) für den Expect-CT-Host an, der die CT-Konformitätsprüfung nicht bestanden hat, in UTC. Der Wert wird als Zeichenkette bereitgestellt, die gemäß Abschnitt 5.6 von [RFC3339], „Internet Date/Time Format", formatiert ist.

"served-certificate-chain" - Der Wert ist die Zertifikatskette, wie sie vom Expect-CT-Host während der TLS-Sitzungseinrichtung bereitgestellt wurde. Der Wert wird als Array von Zeichenketten bereitgestellt, die in der Reihenfolge erscheinen MÜSSEN, in der die Zertifikate bereitgestellt wurden; jede Zeichenkette im Array ist die Privacy-Enhanced Mail (PEM)-Darstellung jedes X.509-Zertifikats, wie in [RFC7468] beschrieben.

"validated-certificate-chain" - Der Wert ist die Zertifikatskette, wie sie vom UA während der Zertifikatsketten-Validierung konstruiert wurde. Der Wert wird als Array von Zeichenketten bereitgestellt.

"scts" - Der Wert repräsentiert die SCTs (falls vorhanden), die der UA für den Expect-CT-Host empfangen hat, und deren Validierungsstatus. Der Wert wird als Array von JSON-Objekten bereitgestellt. Jedes JSON-Objekt im Array hat die folgenden Schlüssel:

• Einen "version"-Schlüssel mit einem Ganzzahlwert. Der UA MUSS diesen Wert auf 1 setzen, wenn der SCT im in Abschnitt 3.2 von [RFC6962] definierten Format ist, oder auf 2, wenn er im in Abschnitt 4.5 von [RFC9162] definierten Format ist.

• Den "status"-Schlüssel mit einem Zeichenkettenwert, den der UA auf einen der folgenden Werte setzen MUSS: „unknown" (was anzeigt, dass der UA den öffentlichen Schlüssel des Logs, von dem der SCT ausgegeben wurde, nicht hat oder ihm nicht vertraut); „valid" (was anzeigt, dass der UA den SCT erfolgreich validiert hat, wie in Abschnitt 5.2 von [RFC6962] oder Abschnitt 8.1.3 von [RFC9162] beschrieben); oder „invalid" (was anzeigt, dass die SCT-Validierung aufgrund einer falschen Signatur oder eines ungültigen Zeitstempels fehlgeschlagen ist).

• Den "source"-Schlüssel mit einem Zeichenkettenwert, der angibt, von wo der UA den SCT erhalten hat. Der UA MUSS den Wert auf einen der folgenden setzen: „tls-extension", „ocsp" oder „embedded".

• Den "serialized_sct"-Schlüssel mit einem Zeichenkettenwert. Wenn der Wert des „version"-Schlüssels 1 ist, MUSS der UA diesen Wert auf die base64-kodierte [RFC4648] serialisierte SignedCertificateTimestamp-Struktur aus Abschnitt 3.2 von [RFC6962] setzen. Wenn der Wert des „version"-Schlüssels 2 ist, MUSS der UA diesen Wert auf die base64-kodierte [RFC4648] serialisierte TransItem-Struktur setzen.

"failure-mode" - Der Wert gibt an, ob der Expect-CT-Bericht durch eine Expect-CT-Richtlinie im Enforce- oder Report-Only-Modus ausgelöst wurde. Der Wert wird als Zeichenkette bereitgestellt. Der UA MUSS diesen Wert auf „enforce" setzen, wenn die Expect-CT-Metadaten eine Enforce-Konfiguration anzeigen, und ansonsten auf „report-only".

"test-report" - (optional) Der Wert wird auf true gesetzt, wenn der Bericht von einem Test-Client gesendet wird, um zu überprüfen, dass sich der Berichtsserver korrekt verhält. Der Wert wird als boolescher Wert bereitgestellt und MUSS auf true gesetzt werden, wenn der Bericht dazu dient, das Verhalten des Servers zu testen und verworfen werden kann.

3.2. Senden eines Verletzungsberichts

Der UA SOLLTE Expect-CT-Fehler für bekannte Expect-CT-Hosts melden: das heißt, wenn eine Verbindung zu einem bekannten Expect-CT-Host nicht der CT-Richtlinie des UA entspricht und die Expect-CT-Metadaten des Hosts einen report-uri enthalten.

Zusätzlich SOLLTE der UA Expect-CT-Fehler für Hosts melden, für die er keine gespeicherten Expect-CT-Metadaten hat.

Die Schritte zum Melden eines Expect-CT-Fehlers sind wie folgt:

1. Ein JSON-Objekt-Berichtsobjekt mit dem einzelnen Schlüssel „expect-ct-report" vorbereiten, dessen Wert das Ergebnis der Generierung eines Verletzungsberichtsobjekts ist, wie in Abschnitt 3.1 beschrieben.

2. Sei Berichtskörper die JSON-Stringifizierung des Berichtsobjekts.

3. Sei report-uri der Wert der report-uri-Direktive im Expect-CT-Headerfeld.

4. Eine HTTP-POST-Anfrage an report-uri mit einem Content-Type-Headerfeld von application/expect-ct-report+json und einem Entity-Body, der aus dem Berichtskörper besteht, senden.

Der UA KANN andere Operationen als Teil des Sendens der HTTP-POST-Anfrage durchführen, wie das Senden eines Cross-Origin Resource Sharing (CORS)-Preflights als Teil von [FETCH].

3.3. Empfang eines Verletzungsberichts

Beim Empfang eines Expect-CT-Verletzungsberichts MUSS der Berichtsserver mit einem 2xx (Successful) Statuscode antworten, wenn er den Anfragekörper als gültiges JSON parsen kann, der Bericht dem in Abschnitt 3.1 beschriebenen Format entspricht und er das Schema, den Hostnamen und den Port in den Feldern „scheme", „hostname" und „port" des Berichts erkennt. Wenn der Berichtskörper nicht geparst werden kann oder nicht dem in Abschnitt 3.1 beschriebenen Format entspricht, oder der Berichtsserver nicht erwartet, Berichte für das Schema, den Hostnamen oder den Port im Bericht zu empfangen, dann MUSS der Berichtsserver mit einem 400 Bad Request Statuscode antworten.

Wie in Abschnitt 3.2 beschrieben, können zukünftige Versionen dieser Spezifikation neue Berichtsformate definieren, die mit einem anderen Top-Level-Schlüssel gesendet werden. Wenn der Berichtsserver das Berichtsformat nicht erkennt, MUSS der Berichtsserver mit einem 501 Not Implemented Statuscode antworten.

Wenn der „test-report"-Schlüssel des Berichts auf true gesetzt ist, KANN der Server den Bericht ohne weitere Verarbeitung verwerfen, MUSS aber dennoch einen 2xx (Successful) Statuscode zurückgeben. Wenn der „test-report"-Schlüssel fehlt oder auf false gesetzt ist, SOLLTE der Server den Bericht zur Verarbeitung und Analyse durch den Eigentümer des Expect-CT-Hosts speichern.