2. Server- und Client-Verhalten

2.1. Syntax des Antwortheaderfelds

Das Expect-CT-Antwortheaderfeld ist ein neues Feld, das in dieser Spezifikation definiert wird. Es wird von einem Server verwendet, um anzuzeigen, dass UAs Verbindungen zum Host, der das Headerfeld ausgibt, auf CT-Konformität bewerten sollten (Abschnitt 2.4).

Expect-CT           = 1#expect-ct-directive
expect-ct-directive = directive-name [ "=" directive-value ]
directive-name      = token
directive-value     = token / quoted-string

Die in dieser Spezifikation definierten Direktiven werden unten beschrieben. Die allgemeinen Anforderungen für Direktiven sind:

1. Die Reihenfolge des Auftretens von Direktiven ist nicht bedeutsam.
2. Eine gegebene Direktive DARF NICHT mehr als einmal in einem gegebenen Headerfeld erscheinen.
3. Direktivnamen sind nicht groß-/kleinschreibungssensitiv.
4. UAs MÜSSEN jedes Headerfeld ignorieren, das Direktiven oder andere Headerfeld-Wertdaten enthält, die nicht der in dieser Spezifikation definierten Syntax entsprechen.
5. Wenn ein Headerfeld Direktive(n) enthält, die der UA nicht erkennt, MUSS der UA diese Direktiven ignorieren.

2.1.1. Die report-uri-Direktive

Die OPTIONALE report-uri-Direktive gibt den URI an, an den der UA Expect-CT-Fehler melden SOLLTE (Abschnitt 2.4).

2.1.2. Die enforce-Direktive

Die OPTIONALE enforce-Direktive ist eine wertlose Direktive, die, wenn vorhanden (d.h., sie ist „behauptet"), dem UA signalisiert, dass die Einhaltung der CT-Richtlinie erzwungen werden sollte (statt nur zu berichten) und dass der UA zukünftige Verbindungen ablehnen sollte, die gegen seine CT-Richtlinie verstoßen.

2.1.3. Die max-age-Direktive

Die max-age-Direktive gibt die Anzahl der Sekunden nach dem Empfang des Expect-CT-Headerfelds an, während derer der UA den Host, von dem die Nachricht empfangen wurde, als bekannten Expect-CT-Host betrachten SOLLTE.

max-age-value = delta-seconds
delta-seconds = 1*DIGIT

2.2. Host-Verarbeitungsmodell

Dieser Abschnitt beschreibt das Verarbeitungsmodell, das Expect-CT-Hosts implementieren.

2.2.1. HTTP-over-Secure-Transport-Anforderungstyp

Ein Expect-CT-Host schließt ein Expect-CT-Headerfeld in seiner Antwort ein. Das Headerfeld MUSS die in Abschnitt 2.1 spezifizierte Grammatik erfüllen.

2.2.2. HTTP-Anforderungstyp

Expect-CT-Hosts SOLLTEN NICHT das Expect-CT-Headerfeld in HTTP-Antworten einschließen, die über einen nicht sicheren Transport übermittelt werden.

2.3. Benutzeragent-Verarbeitungsmodell

Das UA-Verarbeitungsmodell beruht auf dem Parsing von Domainnamen. Beachten Sie, dass internationalisierte Domainnamen vom UA gemäß dem Schema in Abschnitt 10 von [RFC6797] kanonisiert werden SOLLEN.

Der UA speichert bekannte Expect-CT-Hosts und ihre zugehörigen Expect-CT-Direktiven. Diese Daten werden kollektiv als „Expect-CT-Metadaten" eines Hosts bezeichnet.

2.3.1. Fehlende oder fehlerhafte Expect-CT-Headerfelder

Wenn eine HTTP-Antwort kein Expect-CT-Headerfeld enthält, das der in Abschnitt 2.1 spezifizierten Grammatik entspricht, dann DARF der UA keine Expect-CT-Metadaten aktualisieren.

2.3.2. Expect-CT-Headerfeld-Verarbeitung

Wenn der UA eine HTTP-Antwort über einen sicheren Transport empfängt, die ein Expect-CT-Headerfeld enthält, das der in Abschnitt 2.1 spezifizierten Grammatik entspricht, MUSS der UA die Verbindung, auf der das Headerfeld empfangen wurde, auf Konformität mit der CT-Richtlinie des UA bewerten und dann das Expect-CT-Headerfeld wie folgt verarbeiten.

Wenn die Verbindung nicht der CT-Richtlinie des UA entspricht (d.h., die Verbindung ist nicht CT-qualifiziert), dann DARF der UA keine Expect-CT-Metadaten aktualisieren. Wenn das Headerfeld eine report-uri-Direktive enthält, SOLLTE der UA einen Bericht an den angegebenen report-uri senden (Abschnitt 2.3.3).

Wenn die Verbindung der CT-Richtlinie des UA entspricht (d.h., die Verbindung ist CT-qualifiziert), dann MUSS der UA entweder:

• Den Host als bekannten Expect-CT-Host notieren, falls er noch nicht so notiert ist (siehe Abschnitt 2.3.2.1) oder
• Die zwischengespeicherten Informationen des UA für den bekannten Expect-CT-Host aktualisieren, wenn die enforce-, max-age- oder report-uri-Headerfeld-Wert-Direktiven Informationen übermitteln, die sich von denen unterscheiden, die bereits vom UA gewartet werden.

2.3.2.1. Notieren von Expect-CT

Beim Empfang des Expect-CT-Antwortheaderfelds über eine fehlerfreie TLS-Verbindung (mit X.509-Zertifikatsketten-Validierung wie in [RFC5280] beschrieben sowie der in Abschnitt 2.4 dieses Dokuments beschriebenen Validierung) MUSS der UA den Host als bekannten Expect-CT-Host notieren und den Domainnamen des Hosts und seine zugehörigen Expect-CT-Direktiven in einem nicht-flüchtigen Speicher speichern.

2.3.2.2. Speichermodell

Wenn die Teilzeichenfolge, die der Host-Produktion aus dem Request-URI entspricht (der Nachricht, auf die der Host geantwortet hat), nicht genau mit dem Domainnamen eines vorhandenen bekannten Expect-CT-Hosts übereinstimmt, gemäß dem Matching-Verfahren für eine kongruente Übereinstimmung, das in Abschnitt 8.2 von [RFC6797] spezifiziert ist, dann MUSS der UA diesen Host zum Cache bekannter Expect-CT-Hosts hinzufügen. Der UA cached:

• den Domainnamen des Expect-CT-Hosts.
• ob die enforce-Direktive vorhanden ist.
• das effektive Ablaufdatum, das das effektive Expect-CT-Datum plus dem Wert der max-age-Direktive ist.
• den Wert der report-uri-Direktive, falls vorhanden.

2.3.3. Berichterstattung

Wenn der UA über einen sicheren Transport eine HTTP-Antwort empfängt, die ein Expect-CT-Headerfeld mit einer report-uri-Direktive enthält, und die Verbindung nicht der CT-Richtlinie des UA entspricht (d.h., die Verbindung ist nicht CT-qualifiziert), und der UA noch keinen Expect-CT-Bericht für diese Verbindung gesendet hat, dann SOLLTE der UA einen Bericht an den angegebenen report-uri senden, wie in Abschnitt 3 spezifiziert.

2.4. Bewertung von Expect-CT-Verbindungen auf CT-Konformität

Wenn ein UA eine TLS-Verbindung einrichtet, bestimmt der UA, ob der Host ein bekannter Expect-CT-Host ist, gemäß seinem Cache bekannter Expect-CT-Hosts. Ein Expect-CT-Host ist „abgelaufen", wenn das effektive Ablaufdatum auf ein Datum in der Vergangenheit verweist. Der UA MUSS alle abgelaufenen Expect-CT-Hosts in seinem Cache ignorieren und solche Hosts nicht als bekannte Expect-CT-Hosts behandeln.

Wenn ein UA sich mit einem bekannten Expect-CT-Host über eine TLS-Verbindung verbindet, falls die TLS-Verbindung keine Fehler hat, dann wird der UA eine zusätzliche Korrektheitsprüfung anwenden: Konformität mit einer CT-Richtlinie. Ein UA sollte die Konformität mit seiner CT-Richtlinie bewerten, wann immer er sich mit einem bekannten Expect-CT-Host verbindet.

Wenn eine Verbindung zu einem bekannten Expect-CT-Host gegen die CT-Richtlinie des UA verstößt (d.h., die Verbindung ist nicht CT-qualifiziert), und wenn die Expect-CT-Metadaten des bekannten Expect-CT-Hosts eine enforce-Konfiguration anzeigen, MUSS der UA den CT-Konformitätsfehler als Fehler behandeln.

Wenn eine Verbindung zu einem bekannten Expect-CT-Host gegen die CT-Richtlinie des UA verstößt, und wenn die Expect-CT-Metadaten des bekannten Expect-CT-Hosts einen report-uri enthalten, SOLLTE der UA einen Expect-CT-Bericht an diesen report-uri senden (Abschnitt 3).

2.4.1. Überspringen von CT-Konformitätsprüfungen

Es ist akzeptabel für einen UA, CT-Konformitätsprüfungen für einige Hosts gemäß lokaler Richtlinien zu überspringen. Zum Beispiel KANN ein UA CT-Konformitätsprüfungen für Hosts deaktivieren, deren validierte Zertifikatskette an einem benutzerdefinierten Vertrauensanker endet und nicht an einem in den UA (oder die zugrunde liegende Plattform) integrierten Vertrauensanker.

Wenn der UA die CT-Konformität nicht bewertet, z.B., weil der Benutzer sich entschieden hat, sie zu deaktivieren, oder weil eine präsentierte Zertifikatskette bis zu einem benutzerdefinierten Vertrauensanker verkettet ist, SOLLTEN UAs keine Expect-CT-Berichte senden.