4. Identifikatoren in HTTP

Uniform Resource Identifiers (URIs) [URI] werden durchgehend in HTTP als Mittel zur Identifizierung von Ressourcen (Abschnitt 3.1) verwendet.

4.1. URI-Referenzen

URI-Referenzen werden verwendet, um Anfragen zu adressieren, Weiterleitungen anzuzeigen und Beziehungen zu definieren.

Die Definitionen von "URI-reference", "absolute-URI", "relative-part", "authority", "port", "host", "path-abempty", "segment" und "query" werden aus der generischen URI-Syntax übernommen. Eine "absolute-path"-Regel wird für Protokollelemente definiert, die eine nicht-leere Pfadkomponente enthalten können. (Diese Regel unterscheidet sich geringfügig von der path-abempty-Regel von RFC 3986, die einen leeren Pfad zulässt, und der path-absolute-Regel, die keine Pfade zulässt, die mit "//" beginnen.) Eine "partial-URI"-Regel wird für Protokollelemente definiert, die einen relativen URI, aber keine Fragment-Komponente enthalten können.

URI-reference = <URI-reference, see [URI], Section 4.1>
absolute-URI  = <absolute-URI, see [URI], Section 4.3>
relative-part = <relative-part, see [URI], Section 4.2>
authority     = <authority, see [URI], Section 3.2>
uri-host      = <host, see [URI], Section 3.2.2>
port          = <port, see [URI], Section 3.2.3>
path-abempty  = <path-abempty, see [URI], Section 3.3>
segment       = <segment, see [URI], Section 3.3>
query         = <query, see [URI], Section 3.4>

absolute-path = 1*( "/" segment )
partial-URI   = relative-part [ "?" query ]

Jedes Protokollelement in HTTP, das eine URI-Referenz zulässt, gibt in seiner ABNF-Produktion an, ob das Element jede Form von Referenz (URI-reference), nur einen URI in absoluter Form (absolute-URI), nur die Pfad- und optionalen Abfragekomponenten (partial-URI) oder eine Kombination der oben genannten zulässt. Sofern nicht anders angegeben, werden URI-Referenzen relativ zum Ziel-URI (Abschnitt 7.1) analysiert.

Es wird EMPFOHLEN (RECOMMENDED), dass alle Sender und Empfänger mindestens URIs mit Längen von 8000 Oktetten in Protokollelementen unterstützen. Beachten Sie, dass dies bedeutet, dass einige Strukturen und On-Wire-Darstellungen (z. B. die Anforderungszeile in HTTP/1.1) in einigen Fällen notwendigerweise größer sein werden.

4.2. HTTP-bezogene URI-Schemata

Die IANA pflegt das Register der URI-Schemata [BCP35] unter https://www.iana.org/assignments/uri-schemes/. Obwohl Anfragen auf jedes URI-Schema abzielen können, sind die folgenden Schemata inhärent für HTTP-Server:

URI-Schema	Beschreibung	Abschnitt
http	Hypertext Transfer Protocol	4.2.1
https	Hypertext Transfer Protocol Secure	4.2.2

Tabelle 2

Beachten Sie, dass das Vorhandensein eines "http"- oder "https"-URI nicht impliziert, dass immer ein HTTP-Server am identifizierten Ursprung auf Verbindungen wartet. Jeder kann einen URI erstellen, unabhängig davon, ob ein Server existiert und ob dieser Server derzeit diesen Identifikator einer Ressource zuordnet. Die delegierte Natur registrierter Namen und IP-Adressen schafft einen föderierten Namensraum, unabhängig davon, ob ein HTTP-Server vorhanden ist.

4.2.1. http-URI-Schema

Das "http"-URI-Schema wird hiermit definiert zur Erstellung von Identifikatoren innerhalb des hierarchischen Namensraums, der von einem potenziellen HTTP-Ursprungsserver verwaltet wird, der auf TCP-Verbindungen ([TCP]) an einem bestimmten Port wartet.

http-URI = "http" "://" authority path-abempty [ "?" query ]

Der Ursprungsserver für einen "http"-URI wird durch die Authority-Komponente identifiziert, die einen Host-Identifikator ([URI], Abschnitt 3.2.2) und eine optionale Portnummer ([URI], Abschnitt 3.2.3) enthält. Wenn die Port-Unterkomponente leer oder nicht angegeben ist, ist TCP-Port 80 (der reservierte Port für WWW-Dienste) der Standardport. Der Ursprung bestimmt, wer das Recht hat, autoritativ auf Anfragen zu antworten, die auf die identifizierte Ressource abzielen, wie in Abschnitt 4.3.2 definiert.

Ein Sender DARF NICHT (MUST NOT) einen "http"-URI mit einem leeren Host-Identifikator erzeugen. Ein Empfänger, der eine solche URI-Referenz verarbeitet, MUSS sie als ungültig ablehnen.

Die hierarchische Pfadkomponente und die optionale Abfragekomponente identifizieren die Zielressource innerhalb des Namensraums dieses Ursprungsservers.

4.2.2. https-URI-Schema

Das "https"-URI-Schema wird hiermit definiert zur Erstellung von Identifikatoren innerhalb des hierarchischen Namensraums, der von einem potenziellen Ursprungsserver verwaltet wird, der auf TCP-Verbindungen an einem bestimmten Port wartet und in der Lage ist, eine TLS-Verbindung ([TLS13]) herzustellen, die für die HTTP-Kommunikation gesichert wurde. In diesem Kontext bedeutet "gesichert" (secured) spezifisch, dass der Server als handelnd im Namen der identifizierten Autorität authentifiziert wurde und dass alle HTTP-Kommunikation mit diesem Server Vertraulichkeits- und Integritätsschutz hat, der sowohl für Client als auch Server akzeptabel ist.

https-URI = "https" "://" authority path-abempty [ "?" query ]

Der Ursprungsserver für einen "https"-URI wird durch die Authority-Komponente identifiziert, die einen Host-Identifikator ([URI], Abschnitt 3.2.2) und eine optionale Portnummer ([URI], Abschnitt 3.2.3) enthält. Wenn die Port-Unterkomponente leer oder nicht angegeben ist, ist TCP-Port 443 (der reservierte Port für HTTP über TLS) der Standardport. Der Ursprung bestimmt, wer das Recht hat, autoritativ auf Anfragen zu antworten, die auf die identifizierte Ressource abzielen, wie in Abschnitt 4.3.3 definiert.

Ein Sender DARF NICHT (MUST NOT) einen "https"-URI mit einem leeren Host-Identifikator erzeugen. Ein Empfänger, der eine solche URI-Referenz verarbeitet, MUSS sie als ungültig ablehnen.

Die hierarchische Pfadkomponente und die optionale Abfragekomponente identifizieren die Zielressource innerhalb des Namensraums dieses Ursprungsservers.

Ein Client MUSS sicherstellen, dass seine HTTP-Anfragen für eine "https"-Ressource gesichert sind, bevor sie kommuniziert werden, und dass er nur gesicherte Antworten auf diese Anfragen akzeptiert. Beachten Sie, dass die Definition dessen, welche kryptografischen Mechanismen für Client und Server akzeptabel sind, normalerweise ausgehandelt wird und sich im Laufe der Zeit ändern kann.

Ressourcen, die über das "https"-Schema verfügbar gemacht werden, haben keine gemeinsame Identität mit dem "http"-Schema. Sie sind unterschiedliche Ursprünge mit separaten Namensräumen. Erweiterungen von HTTP, die als auf alle Ursprünge mit demselben Host anwendbar definiert sind, wie das Cookie-Protokoll [COOKIE], erlauben jedoch, dass von einem Dienst gesetzte Informationen die Kommunikation mit anderen Diensten innerhalb einer übereinstimmenden Gruppe von Host-Domänen beeinflussen. Solche Erweiterungen sollten mit großer Sorgfalt entworfen werden, um zu verhindern, dass Informationen, die aus einer gesicherten Verbindung gewonnen wurden, versehentlich in einem ungesicherten Kontext ausgetauscht werden.

4.2.3. http(s)-Normalisierung und -Vergleich

URIs mit einem "http"- oder "https"-Schema werden gemäß den in Abschnitt 6 von [URI] definierten Methoden normalisiert und verglichen, unter Verwendung der oben für jedes Schema beschriebenen Standardwerte.

HTTP erfordert nicht die Verwendung einer bestimmten Methode zur Bestimmung der Äquivalenz. Beispielsweise könnte ein Cache-Schlüssel als einfache Zeichenkette verglichen werden, nach syntaxbasierter Normalisierung oder nach schemabasierter Normalisierung.

Die schemabasierte Normalisierung (Abschnitt 6.2.3 von [URI]) von "http"- und "https"-URIs umfasst die folgenden zusätzlichen Regeln:

• Wenn der Port dem Standardport für ein Schema entspricht, ist die Normalform, die Port-Unterkomponente wegzulassen.

• Wenn nicht als Ziel einer OPTIONS-Anfrage verwendet, ist eine leere Pfadkomponente äquivalent zu einem absoluten Pfad von "/", daher ist die Normalform, stattdessen einen Pfad von "/" bereitzustellen.

• Das Schema und der Host sind nicht case-sensitiv und werden normalerweise in Kleinbuchstaben bereitgestellt; alle anderen Komponenten werden case-sensitiv verglichen.

• Zeichen außerhalb des "reserved"-Sets sind äquivalent zu ihren prozentkodierte Oktetten: die Normalform ist, sie nicht zu kodieren (siehe Abschnitte 2.1 und 2.2 von [URI]).

Beispielsweise sind die folgenden drei URIs äquivalent:

http://example.com:80/~smith/home.html
http://EXAMPLE.com/%7Esmith/home.html
http://EXAMPLE.com:/%7esmith/home.html

Zwei HTTP-URIs, die nach Normalisierung (mit jeder Methode) äquivalent sind, können als dieselbe Ressource identifizierend angenommen werden, und jede HTTP-Komponente KANN Normalisierung durchführen. Daher SOLLTEN (SHOULD NOT) unterschiedliche Ressourcen NICHT durch HTTP-URIs identifiziert werden, die nach Normalisierung äquivalent sind (mit einer in Abschnitt 6.2 von [URI] definierten Methode).

4.2.4. Veraltung von userinfo in http(s)-URIs

Die generische URI-Syntax für Authority enthält auch eine userinfo-Unterkomponente ([URI], Abschnitt 3.2.1) zum Einschließen von Benutzerauthentifizierungsinformationen im URI. In dieser Unterkomponente ist die Verwendung des Formats "user:password" veraltet.

Einige Implementierungen verwenden die userinfo-Komponente für die interne Konfiguration von Authentifizierungsinformationen, wie z. B. in Befehlsaufrufoptionen, Konfigurationsdateien oder Lesezeichenlisten, auch wenn eine solche Verwendung eine Benutzerkennung oder ein Passwort offenlegen könnte.

Ein Sender DARF NICHT (MUST NOT) die userinfo-Unterkomponente (und ihr "@"-Trennzeichen) erzeugen, wenn eine "http"- oder "https"-URI-Referenz innerhalb einer Nachricht als Ziel-URI oder Feldwert erzeugt wird.

Bevor eine "http"- oder "https"-URI-Referenz verwendet wird, die von einer nicht vertrauenswürdigen Quelle empfangen wurde, SOLLTE (SHOULD) ein Empfänger userinfo analysieren und sein Vorhandensein als Fehler behandeln; es wird wahrscheinlich verwendet, um die Autorität zum Zweck von Phishing-Angriffen zu verschleiern.

4.2.5. http(s)-Referenzen mit Fragment-Identifikatoren

Fragment-Identifikatoren ermöglichen die indirekte Identifizierung einer sekundären Ressource, unabhängig vom URI-Schema, wie in Abschnitt 3.5 von [URI] definiert. Einige Protokollelemente, die auf einen URI verweisen, erlauben die Einbeziehung eines Fragments, während andere dies nicht tun. Sie werden durch die Verwendung der ABNF-Regel für Elemente unterschieden, bei denen Fragment erlaubt ist; andernfalls wird eine spezifische Regel verwendet, die Fragmente ausschließt.

Hinweis: Die Fragment-Identifikator-Komponente ist nicht Teil der Schema-Definition für ein URI-Schema (siehe Abschnitt 4.3 von [URI]) und erscheint daher nicht in den ABNF-Definitionen für die "http"- und "https"-URI-Schemata oben.

4.3. Autoritativer Zugriff

Autoritativer Zugriff bezieht sich auf das Dereferenzieren eines gegebenen Identifikators zum Zweck des Zugriffs auf die identifizierte Ressource auf eine Weise, die der Client als autoritativ (vom Ressourcenbesitzer kontrolliert) ansieht. Der Prozess zur Bestimmung, ob Zugriff gewährt wird, wird durch das URI-Schema definiert und verwendet häufig Daten innerhalb der URI-Komponenten, wie z. B. die Authority-Komponente bei Verwendung der generischen Syntax. Der autoritative Zugriff ist jedoch nicht auf den identifizierten Mechanismus beschränkt.

Abschnitt 4.3.1 definiert das Konzept eines Ursprungs als Hilfe für solche Verwendungen, und die nachfolgenden Unterabschnitte erklären, wie festgestellt wird, dass ein Peer die Autorität hat, einen Ursprung zu repräsentieren.

Siehe Abschnitt 17.1 für Sicherheitsüberlegungen im Zusammenhang mit der Herstellung von Autorität.

4.3.1. URI-Ursprung

Der "Ursprung" (origin) für einen gegebenen URI ist das Tripel aus Schema, Host und Port nach Normalisierung des Schemas und Hosts in Kleinbuchstaben und Normalisierung des Ports zur Entfernung aller führenden Nullen. Wenn der Port im URI weggelassen wird, wird der Standardport für dieses Schema verwendet. Beispielsweise hätte der URI

https://Example.Com/happy.js

den Ursprung

{ "https", "example.com", "443" }

was auch als normalisiertes URI-Präfix mit immer vorhandenem Port beschrieben werden kann:

https://example.com:443

Jeder Ursprung definiert seinen eigenen Namensraum und kontrolliert, wie Identifikatoren innerhalb dieses Namensraums Ressourcen zugeordnet werden. Wiederum bestimmt, wie der Ursprung im Laufe der Zeit konsistent auf gültige Anfragen antwortet, die Semantik, die Benutzer mit einem URI assoziieren werden, und die Nützlichkeit dieser Semantik ist es, was diese Mechanismen letztendlich in eine Ressource umwandelt, auf die Benutzer in Zukunft verweisen und zugreifen werden.

Zwei Ursprünge sind unterschiedlich, wenn sie sich in Schema, Host oder Port unterscheiden. Selbst wenn verifiziert werden kann, dass dieselbe Entität zwei unterschiedliche Ursprünge kontrolliert, sind die beiden Namensräume unter diesen Ursprüngen unterschiedlich, es sei denn, sie werden explizit von einem für diesen Ursprung autoritativen Server aliasiert.

Der Ursprung wird auch in HTML und verwandten Web-Protokollen verwendet, die über den Rahmen dieses Dokuments hinausgehen, wie in [RFC6454] beschrieben.

4.3.2. http-Ursprünge

Obwohl HTTP unabhängig vom Transportprotokoll ist, ist das "http"-Schema (Abschnitt 4.2.1) spezifisch für die Zuordnung von Autorität zu jedem, der den Ursprungsserver kontrolliert, der auf TCP-Verbindungen auf dem angegebenen Port des in der Authority-Komponente identifizierten Hosts wartet. Dies ist ein sehr schwacher Sinn von Autorität, da es sowohl von clientspezifischen Namensauflösungsmechanismen als auch von Kommunikation abhängt, die möglicherweise nicht vor einem On-Path-Angreifer gesichert ist. Dennoch ist es ein ausreichendes Minimum zum Binden von "http"-Identifikatoren an einen Ursprungsserver für eine konsistente Auflösung innerhalb einer vertrauenswürdigen Umgebung.

Wenn der Host-Identifikator als IP-Adresse bereitgestellt wird, ist der Ursprungsserver der Listener (falls vorhanden) auf dem angegebenen TCP-Port an dieser IP-Adresse. Wenn der Host ein registrierter Name ist, ist der registrierte Name ein indirekter Identifikator zur Verwendung mit einem Namensauflösungsdienst, wie z. B. DNS, um eine Adresse für einen geeigneten Ursprungsserver zu finden.

Wenn ein "http"-URI in einem Kontext verwendet wird, der Zugriff auf die angegebene Ressource erfordert, KANN ein Client versuchen, den Zugriff herzustellen, indem er den Host-Identifikator in eine IP-Adresse auflöst, eine TCP-Verbindung zu dieser Adresse auf dem angegebenen Port herstellt und über diese Verbindung eine HTTP-Anforderungsnachricht sendet, die ein Anforderungsziel enthält, das mit dem Ziel-URI des Clients übereinstimmt (Abschnitt 7.1).

Wenn der Server auf eine solche Anfrage mit einer nicht-vorläufigen HTTP-Antwortnachricht antwortet, wie in Abschnitt 15 beschrieben, wird diese Antwort als autoritative Antwort auf die Anfrage des Clients betrachtet.

Beachten Sie jedoch, dass das Obige nicht das einzige Mittel zum Erhalt einer autoritativen Antwort ist, noch impliziert es, dass eine autoritative Antwort immer erforderlich ist (siehe [CACHING]). Beispielsweise ermöglicht das Alt-Svc-Header-Feld [ALTSVC] einem Ursprungsserver, andere Dienste zu identifizieren, die ebenfalls für diesen Ursprung autoritativ sind. Der Zugriff auf "http"-identifizierte Ressourcen kann auch durch Protokolle außerhalb des Rahmens dieses Dokuments bereitgestellt werden.

4.3.3. https-Ursprünge

Das "https"-Schema (Abschnitt 4.2.2) ordnet Autorität basierend auf der Fähigkeit eines Servers zu, einen privaten Schlüssel zu verwenden, der einem Zertifikat entspricht, das der Client für den identifizierten Ursprungsserver als vertrauenswürdig ansieht. Ein Client wird sich typischerweise auf eine Vertrauenskette verlassen, die von einem vorab arrangierten oder konfigurierten Vertrauensanker übertragen wird, um ein Zertifikat als vertrauenswürdig anzusehen (Abschnitt 4.3.4).

In HTTP/1.1 und früher würde ein Client einem Server nur dann Autorität zuschreiben, wenn er über eine erfolgreich hergestellte und gesicherte Verbindung kommuniziert, die speziell mit dem Host des URI-Ursprungs hergestellt wird. Verbindungsaufbau und Zertifikatsverifizierung wurden als Nachweis der Autorität verwendet.

In HTTP/2 und HTTP/3 wird ein Client einem Server Autorität zuschreiben, wenn er über eine erfolgreich hergestellte und gesicherte Verbindung kommuniziert, wenn der Host des URI-Ursprungs mit einem der im Serverzertifikat vorhandenen Hosts übereinstimmt und der Client glaubt, dass er eine Verbindung zu diesem Host für diesen URI öffnen könnte. Tatsächlich wird der Client eine DNS-Abfrage durchführen, um zu überprüfen, ob der Host des Ursprungs dieselbe Server-IP-Adresse enthält wie die hergestellte Verbindung. Ein Ursprungsserver kann diese Einschränkung entfernen, indem er einen äquivalenten ORIGIN-Frame [RFC8336] sendet.

Die Host- und Port-Werte des Anforderungsziels werden bei jeder HTTP-Anfrage übergeben, identifizieren den Ursprung und unterscheiden ihn von anderen Namensräumen, die möglicherweise vom selben Server kontrolliert werden (Abschnitt 7.2). Es liegt in der Verantwortung des Ursprungs sicherzustellen, dass alle Dienste, die mit Kontrolle über seinen Zertifikatsprivatschlüssel bereitgestellt werden, gleichermaßen für die Verwaltung des entsprechenden "https"-Namensraums verantwortlich sind oder zumindest bereit sind, Anfragen abzulehnen, die fehlgeleitet zu sein scheinen (Abschnitt 7.4).

Ein Ursprungsserver möchte möglicherweise keine Anfragen für bestimmte Ziel-URIs verarbeiten, selbst wenn er für sie autoritativ ist. Beispielsweise ist bei einem Host, der unterschiedliche Dienste auf verschiedenen Ports ausführt (z. B. 443 versus 8000), die Überprüfung des Ziel-URI auf dem Ursprungsserver erforderlich (selbst nachdem die Verbindung gesichert wurde), da ein Netzwerkangreifer veranlassen könnte, dass Verbindungen für einen Port an einem anderen Port empfangen werden. Das Versäumnis, den Ziel-URI zu überprüfen, könnte es einem solchen Angreifer ermöglichen, die Antwort auf einen Ziel-URI (z. B. "https://example.com/foo") durch eine scheinbar autoritative Antwort von einem anderen Port (z. B. "https://example.com:8000/foo") zu ersetzen.

Beachten Sie, dass das "https"-Schema nicht auf TCP und die verbundene Portnummer zur Zuordnung von Autorität angewiesen ist, da beide außerhalb der gesicherten Kommunikation liegen und daher nicht als definitiv vertrauenswürdig angesehen werden können. Daher kann die HTTP-Kommunikation über jeden gesicherten Kanal erfolgen, wie in Abschnitt 4.2.2 definiert, einschließlich Protokollen, die TCP nicht verwenden.

Wenn ein "https"-URI in einem Kontext verwendet wird, der Zugriff auf die angegebene Ressource erfordert, KANN ein Client versuchen, den Zugriff herzustellen, indem er den Host-Identifikator in eine IP-Adresse auflöst, eine TCP-Verbindung zu dieser Adresse auf dem angegebenen Port herstellt, die Verbindung End-to-End sichert, indem er erfolgreich TLS über TCP mit Vertraulichkeits- und Integritätsschutz initiiert, und über diese Verbindung eine HTTP-Anforderungsnachricht sendet, die ein Anforderungsziel enthält, das mit dem Ziel-URI des Clients übereinstimmt (Abschnitt 7.1).

Wenn der Server auf eine solche Anfrage mit einer nicht-vorläufigen HTTP-Antwortnachricht antwortet, wie in Abschnitt 15 beschrieben, wird diese Antwort als autoritative Antwort auf die Anfrage des Clients betrachtet.

Beachten Sie jedoch, dass das Obige nicht das einzige Mittel zum Erhalt einer autoritativen Antwort ist, noch impliziert es, dass eine autoritative Antwort immer erforderlich ist (siehe [CACHING]).

4.3.4. https-Zertifikatsverifizierung

Um eine gesicherte Verbindung zum Dereferenzieren eines URI herzustellen, MUSS ein Client verifizieren, dass die Identität des Dienstes eine akzeptable Übereinstimmung für den Ursprungsserver des URI ist. Die Zertifikatsverifizierung wird verwendet, um Server-Impersonation durch einen On-Path-Angreifer oder durch einen Angreifer, der die Namensauflösung kontrolliert, zu verhindern. Dieser Prozess erfordert, dass der Client mit einer Reihe von Vertrauensankern konfiguriert ist.

Typischerweise MUSS ein Client den in Abschnitt 6 von [RFC6125] definierten Validierungsprozess verwenden, um die Dienstidentität zu verifizieren. Der Client MUSS eine Referenzidentität aus dem Host des Dienstes konstruieren: wenn der Host eine literale IP-Adresse ist (Abschnitt 4.3.5), dann ist die Referenzidentität eine IP-ID, andernfalls ist der Host ein Name und die Referenzidentität ist eine DNS-ID.

Ein Client DARF NICHT (MUST NOT) eine Referenzidentität vom Typ CN-ID verwenden. Wie in Abschnitt 6.2.1 von [RFC6125] erwähnt, könnte eine Referenzidentität vom Typ CN-ID von älteren Clients verwendet werden.

Ein Client könnte speziell konfiguriert sein, um alternative Formen der Server-Identitätsverifizierung zu akzeptieren. Beispielsweise könnte ein Client eine Verbindung zu einem Server herstellen, dessen Adresse und Hostname dynamisch sind, und erwarten, dass der Dienst ein bestimmtes Zertifikat präsentiert (oder eines, das einer extern definierten Referenzidentität entspricht), anstatt eines, das mit dem Ursprung des Ziel-URI übereinstimmt.

In besonderen Fällen kann es angemessen sein, dass ein Client die Identität des Servers einfach ignoriert, aber es muss verstanden werden, dass dies eine Verbindung für aktive Angriffe offen lässt.

Wenn das Zertifikat für den Ursprung des Ziel-URI nicht gültig ist, MUSS ein User-Agent entweder eine Bestätigung vom Benutzer einholen (siehe Abschnitt 3.5), bevor er fortfährt, oder die Verbindung mit einem Bad-Certificate-Fehler beenden. Automatisierte Clients MÜSSEN den Fehler in einem geeigneten Audit-Log protokollieren, falls verfügbar, und SOLLTEN (SHOULD) die Verbindung mit einem Bad-Certificate-Fehler beenden. Automatisierte Clients KÖNNEN (MAY) eine Konfigurationseinstellung bereitstellen, die diese Überprüfung deaktiviert, MÜSSEN aber eine Einstellung bereitstellen, die sie aktiviert.

4.3.5. IP-ID-Referenzidentität

Ein Server, der durch ein IP-Adressen-Literal im "host"-Feld eines "https"-URI identifiziert wird, hat eine Referenzidentität vom Typ IP-ID. Eine IP-Version-4-Adresse verwendet die "IPv4address"-ABNF-Regel, und eine IP-Version-6-Adresse verwendet die "IP-literal"-Produktion mit der "IPv6address"-Option; siehe Abschnitt 3.2.2 von [URI]. Die Referenzidentität für eine IP-ID enthält die dekodierten Bytes der IP-Adresse.

Eine IP-Version-4-Adresse besteht aus 4 Oktetten, und eine IP-Version-6-Adresse besteht aus 16 Oktetten. Die Verwendung einer IP-ID ist für keine andere IP-Version definiert. Eine iPAddress-Auswahl in der subjectAltName-Erweiterung eines Zertifikats enthält nicht explizit eine IP-Version, sondern verlässt sich stattdessen auf die Länge der Adresse, um Versionen zu unterscheiden; siehe Abschnitt 4.2.1.6 von [RFC5280].

Eine Referenzidentität vom Typ IP-ID stimmt überein, wenn die Adresse mit einem iPAddress-Wert der subjectAltName-Erweiterung des Zertifikats identisch ist.