8. User Agent Processing Model (Benutzeragenten-Verarbeitungsmodell)

Dieser Abschnitt beschreibt das HTTP Strict Transport Security-Verarbeitungsmodell der UAs. Das Modell hat mehrere Aspekte, die von den folgenden Unterabschnitten aufgezählt werden.

Dieses Verarbeitungsmodell geht davon aus, dass der UA IDNA2008 [RFC5890] oder möglicherweise IDNA2003 [RFC3490] implementiert, wie in Abschnitt 13 ("Internationalized Domain Names for Applications (IDNA): Dependency and Migration") diskutiert. Es geht auch davon aus, dass alle Domainnamen, die im Kontext dieser Spezifikation operieren, IDNA-kanonisiert wurden, bevor sie wie in Abschnitt 10 ("Domain Name IDNA-Canonicalization") beschrieben verarbeitet wurden.

HINWEIS: Die Referenz auf [RFC3490] ist aufgrund ihrer anhaltenden Relevanz für die tatsächliche Bereitstellung in absehbarer Zukunft.

Die obigen Annahmen implizieren auch, dass dieses Verarbeitungsmodell speziell davon ausgeht, dass vor der in diesem Abschnitt spezifizierten Verarbeitung eine angemessene IDNA- und Unicode-Validierung sowie Zeichenlistentests an Domainnamen im Rahmen des IDNA-Kanonisierungsprozesses der Domainnamen durchgeführt wurden. Siehe die IDNA-spezifischen Sicherheitsüberlegungen in Abschnitt 14.10 ("Internationalized Domain Names") für die Begründung und weitere Details.

8.1. Strict-Transport-Security Response Header Field Processing (Verarbeitung des Strict-Transport-Security-Antwort-Header-Felds)

Wenn eine über einen sicheren Transport empfangene HTTP-Antwort ein STS-Header-Feld enthält, das der in Abschnitt 6.1 ("Strict-Transport-Security HTTP Response Header Field") spezifizierten Syntax entspricht, und es keine Fehler oder Warnungen des zugrunde liegenden sicheren Transports gibt (siehe Abschnitt 8.4), muss (MUST) der UA:

• Den Host als bekannten HSTS-Host notieren, falls er noch nicht notiert wurde (siehe Abschnitt 8.1.1 ("Noting an HSTS Host - Storage Model")),

oder

• Die zwischengespeicherten Informationen des UA für den bekannten HSTS-Host aktualisieren, wenn eine oder beide der in den max-age- und includeSubDomains-Header-Feld-Wert-Tokens übermittelten Informationen von den Informationen abweichen, die der UA bereits pflegt.

  Der max-age-Wert ist im Wesentlichen ein "Time-to-Live"-Wert relativ zum Zeitpunkt des Empfangs des STS-Header-Felds.

  Wenn der Wert des max-age-Header-Feld-Wert-Tokens Null ist, muss (MUST) der UA seine zwischengespeicherten HSTS-Richtlinieninformationen (einschließlich der includeSubDomains-Direktive, falls behauptet) löschen, wenn der HSTS-Host bekannt ist, oder der UA darf nicht (MUST NOT) diesen HSTS-Host notieren, wenn er noch nicht bekannt ist.

  Wenn der UA mehrere STS-Header-Felder in einer HTTP-Antwortnachricht über einen sicheren Transport empfängt, muss (MUST) der UA nur das erste solche Header-Feld verarbeiten.

Andernfalls:

• Wenn eine HTTP-Antwort über unsicheren Transport empfangen wird, muss (MUST) der UA jedes vorhandene STS-Header-Feld ignorieren.

• Der UA muss (MUST) jedes STS-Header-Feld ignorieren, das nicht der in Abschnitt 6.1 ("Strict-Transport-Security HTTP Response Header Field") spezifizierten Syntax entspricht.

8.1.1. Noting an HSTS Host - Storage Model (Notieren eines HSTS-Hosts - Speichermodell)

Wenn die Teilzeichenfolge, die der Host-Produktion im Request-URI (der Nachricht, auf die der Host antwortet) entspricht, syntaktisch der IP-literal- oder IPv4address-Produktion in Abschnitt 3.2.2 von [RFC3986] entspricht, darf (MUST NOT) der UA diesen Host nicht als bekannten HSTS-Host notieren.

Andernfalls, wenn die Teilzeichenfolge nicht kongruent mit dem Domainnamen eines bekannten HSTS-Hosts gemäß dem in Abschnitt 8.2 ("Known HSTS Host Domain Name Matching") spezifizierten Matching-Prozess übereinstimmt, muss (MUST) der UA diesen Host als bekannten HSTS-Host notieren, den Domainnamen des HSTS-Hosts zwischenspeichern und damit die Ablaufzeit dieser Informationen notieren, wie durch den gegebenen max-age-Wert effektiv festgelegt, sowie ob die includeSubDomains-Direktive behauptet wird. Siehe auch Abschnitt 11.2 ("HSTS Policy Expiration Time Considerations").

Der UA darf nicht (MUST NOT) die Ablaufzeit oder die includeSubDomains-Direktive eines bekannten HSTS-Hosts ändern, der mit der übergeordneten Domain übereinstimmt.

Wenn der Cache-Eintrag eines bekannten HSTS-Hosts ein Ablaufdatum in der Vergangenheit hat, ist dieser bekannte HSTS-Host "abgelaufen (expired)". Wenn zu irgendeinem Zeitpunkt abgelaufene bekannte HSTS-Hosts im Cache vorhanden sind, muss (MUST) der UA alle abgelaufenen bekannten HSTS-Hosts aus seinem Cache entfernen.

8.2. Known HSTS Host Domain Name Matching (Bekannter HSTS-Host-Domainname-Abgleich)

Ein gegebener Domainname kann auf eine oder beide der folgenden Weisen mit dem Domainnamen eines bekannten HSTS-Hosts übereinstimmen: kongruente Übereinstimmung (congruent match) oder Superdomain-Übereinstimmung (superdomain match). Oder es gibt möglicherweise keine Übereinstimmung.

Die folgenden Schritte bestimmen, ob es eine Übereinstimmung gibt und wenn ja, auf welche Weise:

Vergleichen Sie unter Verwendung eines ASCII-Fall-insensitiven Vergleichs, beginnend mit dem rechtesten Label und von rechts nach links fortfahrend, Label für Label (wobei nur Labels verglichen werden) den gegebenen Domainnamen mit dem Domainnamen jedes nicht abgelaufenen bekannten HSTS-Hosts des UA. Siehe auch Abschnitt 2.3.2.4 von [RFC5890].

• Superdomain-Übereinstimmung (Superdomain Match)

  Wenn eine Label-für-Label-Übereinstimmung zwischen dem gesamten Domainnamen des bekannten HSTS-Hosts und dem rechten Teil des gegebenen Domainnamens gefunden wird, ist der Domainname dieses bekannten HSTS-Hosts eine Superdomain-Übereinstimmung des gegebenen Domainnamens. Es kann mehrere Superdomain-Übereinstimmungen für einen gegebenen Domainnamen geben.

• Kongruente Übereinstimmung (Congruent Match)

  Wenn eine Label-für-Label-Übereinstimmung zwischen dem Domainnamen des bekannten HSTS-Hosts und dem gegebenen Domainnamen gefunden wird -- d. h. es gibt keine weiteren Labels zu vergleichen -- dann stimmt der gegebene Domainname kongruent mit diesem bekannten HSTS-Host überein.

8.3. URI Loading and Port Mapping (URI-Laden und Port-Zuordnung)

Beim Laden eines URI, wenn die HSTS-Richtlinie wie in Abschnitt 5.4 beschrieben gilt, muss (MUST) sich der UA wie folgt verhalten:

• Wenn der URI keine Port-Komponente hat oder wenn die Port-Komponente dem standardmäßigen unsicheren Port 80 entspricht, weisen Sie dem URI den standardmäßigen sicheren Transport-Port 443 als Port-Komponente des effektiven Anforderungs-URI zu.

• Ändern Sie die Schema-Komponente des URI in "https".

• Darf nicht (MUST NOT) eine unsichere Verbindung herstellen.

• Kann (MAY) versuchen, eine sichere Verbindung zum konstruierten effektiven Anforderungs-URI herzustellen.

8.4. Errors in Secure Transport Establishment (Fehler bei der Einrichtung des sicheren Transports)

Wenn beim Versuch, eine sichere Verbindung zu einem bekannten HSTS-Host herzustellen, ein Fehler auftritt, darf (MUST NOT) der UA die Verbindung nicht fortsetzen und darf (MUST NOT) eine Meldung anzeigen, die den Benutzer vor dem Fehler warnt. Der UA darf nicht (MUST NOT) dem Benutzer erlauben, trotz des Fehlers fortzufahren.

Diese Fehler umfassen (sind aber nicht beschränkt auf):

• Abgelaufenes Zertifikat
• Selbstsigniertes Zertifikat
• Nicht vertrauenswürdige Zertifikatskette
• Hostname-Nichtübereinstimmung
• TLS/SSL-Protokollfehler