1. Einführung

HTTP definiert keine Mittel zum Schutz der Datenintegrität von Inhalten oder Repräsentationen. Wenn HTTP-Nachrichten zwischen Endpunkten übertragen werden, können Funktionen oder Eigenschaften unterer Schichten wie TCP-Prüfsummen oder TLS-Datensätze [TLS] einen gewissen Integritätsschutz bieten. Die transportorientierte Integrität bietet jedoch einen begrenzten Nutzen, da sie für die Anwendungsschicht undurchsichtig ist und nur den Umfang einer einzelnen Verbindung abdeckt. HTTP-Nachrichten reisen oft über eine Kette separater Verbindungen. Zwischen den Verbindungen besteht die Möglichkeit einer Datenbeschädigung. Ein HTTP-Integritätsmechanismus kann Endpunkten oder Anwendungen, die HTTP verwenden, die Mittel bieten, Datenbeschädigungen zu erkennen und eine Entscheidung darüber zu treffen, wie darauf reagiert werden soll. Ein Beispielanwendungsfall ist die Unterstützung der Fehlererkennung und -diagnose über Systemgrenzen hinweg.

Dieses Dokument definiert zwei Digest-Integritätsmechanismen für HTTP. Erstens die Inhaltsintegrität, die auf den übermittelten Inhalt wirkt (Abschnitt 6.4 von [HTTP]). Zweitens die Repräsentationsdatenintegrität, die auf Repräsentationsdaten wirkt (Abschnitt 8.1 von [HTTP]). Dies unterstützt fortgeschrittene Anwendungsfälle, wie z. B. die Validierung der Integrität einer Ressource, die aus Teilen rekonstruiert wurde, die über mehrere Anfragen oder Verbindungen abgerufen wurden.

Dieses Dokument macht [RFC3230] und damit die Digest- und Want-Digest-HTTP-Felder obsolet; siehe Abschnitt 1.3.

1.1. Dokumentstruktur

Dieses Dokument ist wie folgt aufgebaut:

• Neue Definitionen für Anfrage- und Antwort-Header- und Trailer-Felder.

  • Abschnitt 2 (Content-Digest),
  • Abschnitt 3 (Repr-Digest) und
  • Abschnitt 4 (Want-Content-Digest und Want-Repr-Digest).

• Überlegungen speziell zur Integrität von Repräsentationsdaten.

  • Abschnitt 3.1 (Zustandsändernde Anfragen),
  • Abschnitt 3.2 (Content-Location),
  • Anhang A enthält ausgearbeitete Beispiele für Repräsentationsdaten im Nachrichtenaustausch und
  • Die Anhänge B und C enthalten ausgearbeitete Beispiele für Repr-Digest- und Want-Repr-Digest-Felder im Nachrichtenaustausch.

• Abschnitt 5 stellt Überlegungen zu Hash-Algorithmen vor und definiert Registrierungsverfahren für zukünftige Einträge.

1.2. Konzeptübersicht

Die in diesem Dokument definierten HTTP-Felder können für die HTTP-Integrität verwendet werden. Sender wählen einen Hashing-Algorithmus und berechnen einen Digest aus einer Eingabe, die sich auf die HTTP-Nachricht bezieht. Der Algorithmusbezeichner und der Digest werden in einem HTTP-Feld übertragen. Empfänger können den Digest zu Integritätszwecken validieren. Hashing-Algorithmen werden im Register "Hash Algorithms for HTTP Digest Fields" registriert (siehe Abschnitt 7.2).

Die Auswahl der Daten, für die Digests berechnet werden, hängt vom Anwendungsfall der HTTP-Nachrichten ab. Dieses Dokument bietet unterschiedliche Felder für HTTP-Repräsentationsdaten und HTTP-Inhalt.

Es gibt Anwendungsfälle, in denen ein einfacher Digest der HTTP-Inhaltsbytes erforderlich ist. Das Content-Digest-Anfrage- und Antwort-Header- und Trailer-Feld ist definiert, um Digests von Inhalten zu unterstützen (Abschnitt 6.4 von [HTTP]); siehe Abschnitt 2.

Für fortgeschrittenere Anwendungsfälle ist das Repr-Digest-Anfrage- und Antwort-Header- und Trailer-Feld (Abschnitt 3) definiert. Es enthält einen Digest-Wert, der durch Anwenden eines Hashing-Algorithmus auf ausgewählte Repräsentationsdaten (Abschnitt 8.1 von [HTTP]) berechnet wurde. Die Basis von Repr-Digest auf der ausgewählten Repräsentation macht es einfach, es auf Anwendungsfälle anzuwenden, in denen der Nachrichteninhalt eine Art von Manipulation erfordert, um als Repräsentation der Ressource betrachtet zu werden, oder der Inhalt eine teilweise Repräsentation einer Ressource übermittelt, wie z. B. Bereichsanfragen (siehe Abschnitt 14 von [HTTP]).

Content-Digest und Repr-Digest unterstützen die Agilität von Hashing-Algorithmen. Die Want-Content-Digest- und Want-Repr-Digest-Felder ermöglichen es Endpunkten, Interesse an Content-Digest bzw. Repr-Digest zu bekunden und Algorithmuspräferenzen für beide auszudrücken.

Content-Digest und Repr-Digest werden gemeinsam als "Integritätsfelder" (Integrity fields) bezeichnet. Want-Content-Digest und Want-Repr-Digest werden gemeinsam als "Integritätspräferenzfelder" (Integrity preference fields) bezeichnet.

Integritätsfelder sind an die Content-Encoding- und Content-Type-Header-Felder gebunden. Daher kann eine bestimmte Ressource mehrere unterschiedliche Digest-Werte haben, wenn sie mit HTTP übertragen wird.

Integritätsfelder gelten für HTTP-Nachrichteninhalt oder HTTP-Repräsentationen. Sie gelten nicht für HTTP-Nachrichten oder -Felder. Sie können jedoch mit anderen Mechanismen kombiniert werden, die Metadaten schützen, wie z. B. digitale Signaturen, um die Phasen eines HTTP-Austauschs ganz oder teilweise zu schützen. Beispielsweise könnten HTTP Message Signatures [SIGNATURES] verwendet werden, um Integritätsfelder zu signieren und so eine Abdeckung für HTTP-Inhalt oder Repräsentationsdaten bereitzustellen.

Diese Spezifikation definiert keine Mittel für Authentifizierung, Autorisierung oder Datenschutz.

1.3. Obsoletierung von RFC 3230

[RFC3230] definierte die Digest- und Want-Digest-HTTP-Felder für die HTTP-Integrität. Es prägte auch die Begriffe "Instanz" (instance) und "Instanzmanipulation" (instance manipulation), um Konzepte wie ausgewählte Repräsentationsdaten (Abschnitt 8.1 von [HTTP]) zu erklären, die heute universeller als HTTP-Semantik definiert und implementiert sind.

Die Erfahrung hat gezeigt, dass Implementierungen von [RFC3230] die Bedeutung von "Instanz" inkonsistent interpretiert haben, was zu Interoperabilitätsproblemen führte. Das häufigste Problem bezieht sich auf den Fehler, den Digest unter Verwendung (dessen, was wir heute als) Nachrichteninhalt zu berechnen, anstatt (dessen, was wir heute als) Repräsentationsdaten zu verwenden, wie es ursprünglich beabsichtigt war. Interessanterweise hat die Zeit auch gezeigt, dass ein Digest des Nachrichteninhalts für einige Anwendungsfälle vorteilhaft sein kann, sodass es schwierig ist festzustellen, ob die Nichtkonformität mit [RFC3230] beabsichtigt oder unbeabsichtigt ist.

Um potenzielle Inkonsistenzen und Mehrdeutigkeiten zwischen Implementierungen von Digest und Want-Digest anzugehen, macht dieses Dokument [RFC3230] obsolet. Die in diesem Dokument definierten Integritätsfelder (Abschnitte 2 und 3) und Integritätspräferenzfelder (Abschnitt 4) sind besser auf die aktuelle HTTP-Semantik abgestimmt und haben Namen, die die beabsichtigten Verwendungen klarer artikulieren.

1.4. Notationelle Konventionen

Die Schlüsselwörter "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY" und "OPTIONAL" in diesem Dokument sind so zu interpretieren, wie in BCP 14 [RFC2119] [RFC8174] beschrieben, wenn und nur wenn sie in Großbuchstaben erscheinen, wie hier gezeigt.

Dieses Dokument verwendet die in [RFC5234] definierte und durch [RFC7405] aktualisierte Augmented BNF. Dies umfasst die Regeln CR (Wagenrücklauf), LF (Zeilenvorschub) und CRLF (CR LF).

Dieses Dokument verwendet die folgende Terminologie aus Abschnitt 3 von [STRUCTURED-FIELDS], um Syntax und Parsing zu spezifizieren: Boolean, Byte Sequence, Dictionary, Integer und List.

Die Definitionen "Repräsentation" (representation), "ausgewählte Repräsentation" (selected representation), "Repräsentationsdaten" (representation data), "Repräsentationsmetadaten" (representation metadata), "User Agent" und "Inhalt" (content) in diesem Dokument sind so zu interpretieren, wie in [HTTP] beschrieben.

Dieses Dokument verwendet die in [FOLDING] beschriebenen Zeilenumbruchstrategien.

Namen von Hashing-Algorithmen respektieren die in ihrem Definitionsdokument verwendete Groß-/Kleinschreibung (z. B. SHA-1, CRC32c).

HTTP-Nachrichten geben Hashing-Algorithmen unter Verwendung eines Algorithmus-Schlüssels (Algorithm Key) (Algorithmen) an. Wo das Dokument im Text auf einen Algorithmus-Schlüssel verweist, wird er in Anführungszeichen gesetzt (z. B. "sha", "crc32c").

Der Begriff "Prüfsumme" (checksum) beschreibt die Ausgabe der Anwendung eines Algorithmus auf eine Folge von Bytes, während "Digest" nur in Bezug auf den in den Feldern enthaltenen Wert verwendet wird.

"Integritätsfelder" (Integrity fields) ist der Sammelbegriff für Content-Digest und Repr-Digest.

"Integritätspräferenzfelder" (Integrity preference fields) ist der Sammelbegriff für Want-Repr-Digest und Want-Content-Digest.