Zusammenfassung

  • Want-Content-Digest und Want-Repr-Digest ordnen Algorithmuspräferenzen. Sie begründen keine bindende Aushandlung: Die Gegenseite darf den Wunsch ignorieren, einen anderen Algorithmus wählen oder das Digest-Feld weglassen.
  • Eine belastbare Integritätsakte trennt vier Zustände: gesendeter Wunsch, tatsächlich empfangener Nachweis, vom Feld erfasstes HTTP-Objekt sowie lokale Berechnung und Entscheidung.
  • Ein Digest erkennt Abweichungen in klar abgegrenzten Bytes. Er authentifiziert keinen Absender, erteilt keine Berechtigung, schafft keine Vertraulichkeit und schützt nicht automatisch die übrigen HTTP-Metadaten.

Eine Rangfolge ist noch keine Vereinbarung

Wer in einer Konfiguration SHA-512 mit der höchsten Gewichtung versieht, hat zunächst nur die eigene Erwartung ausgedrückt. RFC9530 definiert die Sprache dafür; eine stillschweigende Zusage der Gegenseite definiert es nicht.

Beide Want-*-Felder sind Wörterbücher nach Structured Fields. Der Schlüssel benennt den Algorithmus, eine ganze Zahl die relative Präferenz. 1 ist die niedrigste, 10 die höchste Präferenz, 0 bedeutet nicht akzeptabel. Want-Content-Digest gilt dem Nachrichteninhalt, Want-Repr-Digest der ausgewählten Repräsentation.

Die Zahl ist weder kryptografische Güteklasse noch Prüfergebnis. Auch ein Gewicht von 10 bindet den Empfänger nicht. Er kann das Feld unbeachtet lassen, einen nicht genannten Algorithmus liefern oder weder Content-Digest noch Repr-Digest senden. Allein daraus entsteht laut RFC9530 kein Protokollfehler.

Eine Anwendung darf strengere Bedingungen setzen. Sie kann einen aktiven Algorithmus verlangen, Fehlen als Fehler behandeln oder einen bestimmten Status zurückgeben. Diese Wirkung muss sie jedoch als eigenen Vertrag festlegen. Anhang C führt mehrere mögliche Reaktionen vor: einen weniger bevorzugten Algorithmus, ausschließlich nicht unterstützte Wünsche oder eine anwendungsspezifische 4xx-/5xx-Antwort. Einen universellen Fehlercode schreibt der Standard nicht vor.

Auch die Nachrichtenrichtung zählt. Sendet ein Server Want-Content-Digest in einer Antwort, beschreibt er damit seinen Wunsch für künftige Requests. Das Feld enthält keinen Digest der laufenden Antwort. Ein Logeintrag mit dem Wort „Digest“ ist daher noch kein eingegangener Integritätsnachweis.

Vier Belege statt eines Schalters

Der erste Beleg hält die Präferenz fest: Feldname, Mitglieder und Reihenfolge. Der zweite beschreibt die Beobachtung: welches Nachweisfeld eintraf, welche Mitglieder es trug und ob es als Header oder Trailer ankam. Der dritte benennt den Umfang: Nachrichteninhalt oder ausgewählte Repräsentation. Der vierte enthält die lokale Handlung: akzeptierter Algorithmus, berechnete Bytes, Übereinstimmung und Geschäftsentscheidung.

Mit dieser Trennung wird aus „SHA-512 bevorzugt“ nicht „SHA-512 geliefert“. Aus einem vorhandenen sha-256 wird nicht automatisch „vom Client geprüft“. Und ein grünes Ergebnis bleibt unvollständig, solange Feld und Bezugsobjekt fehlen.

Ein Fallback kann sachgerecht sein. Ebenso kann ein Dienst ohne Digest fortfahren. Dann sollten „weniger bevorzugte Alternative akzeptiert“ oder „Fehlen nach lokaler Regel akzeptiert“ im Datensatz stehen. Wer beides als allgemeinen Prüferfolg speichert, macht eine Kompatibilitätsentscheidung unsichtbar und überhöht später die zugesagte Sicherheit.

Content und Repräsentation bezeichnen verschiedene Prüfobjekte

RFC3230 hinterließ mit dem instance digest begriffliche Unschärfe. RFC9530 teilt das Thema auf. Content-Digest umfasst den tatsächlichen Inhalt einer konkreten HTTP-Nachricht. Repr-Digest umfasst die vollständige ausgewählte Repräsentation im Sinne der HTTP-Semantik.

Bei Teilübertragungen fällt der Unterschied besonders auf, er besteht aber auch bei Aushandlung und Codierung. Ein Resource kann mehrere Repräsentationen haben. Content-Type und Content-Encoding beeinflussen die Bytefolge und ihre Deutung. Eine bequem erreichbare Datei im Speicher ist deshalb nicht automatisch das vom Feld bezeichnete Objekt.

Zustandsändernde Methoden verlangen dieselbe Genauigkeit. Ein PATCH-Request kann ein Patch-Dokument als Repräsentation tragen; die Antwort kann sich auf die ausgewählte Repräsentation des veränderten Resource beziehen. Content-Location und Location lassen sich dabei nicht als austauschbare Identitätsangaben verwenden.

Ein internes Feld namens „payload checksum“ verliert diese Information. Erforderlich sind Feldtyp, einschlägige Repräsentationsmetadaten, Behandlung der Content-Codierung und Verarbeitungsstufe der erfassten Bytes. Sonst können zwei Systeme korrekt über unterschiedliches Material rechnen und dennoch denselben Nachweis zu besitzen glauben.

Verstanden heißt nicht akzeptiert

Im aktuellen IANA-Register sind SHA-512 und SHA-256 als Active geführt. MD5, SHA, UNIX-Summenvarianten, Adler-32 und CRC32C zählen zu Deprecated. RFC9530 lässt veraltete Algorithmen für einige nicht adversariale Fälle zufälliger Beschädigung zu, verbietet sie jedoch bei einem Angreifer oder im Zusammenhang mit digitalen Signaturen.

Der Registerstatus ersetzt keine Risikoregel. Ein Empfänger darf einzelne oder alle Mitglieder ignorieren und die Zahl der Algorithmen und Berechnungen begrenzen. Das hat auch betriebliche Gründe: Mehrere Digests über große Inhalte verbrauchen Rechenzeit und Speicherbandbreite. Ein Peer sollte diese Arbeit nicht unbegrenzt bestimmen können.

Implementierungen brauchen deshalb getrennte Listen für technisch verstandene und politisch akzeptierte Algorithmen. Enthält eine Nachricht einen starken und einen veralteten Wert, darf nicht ein Baustein den erstbesten prüfen, während ein anderer die Einhaltung der höchsten Präferenz annimmt. Algorithmusagilität verhindert Downgrade oder Substitution nicht von selbst.

Die Aufzeichnung nennt den tatsächlich gewählten Algorithmus, das Feld, das Objekt und das Ergebnis. Die Anwendung entscheidet, ob eine akzeptable Übereinstimmung genügt, wie widersprüchliche Mitglieder behandelt werden und was bei ausschließlich unbekannten oder verbotenen Werten geschieht. Das Register koordiniert Namen; die Annahmeregel trägt die Folgen.

Ein später Trailer kann keine frühere Entscheidung absichern

Digest-Felder dürfen als Header oder Trailer erscheinen. Für einen streamenden Sender ist der Trailer praktisch, weil der Wert erst am Ende feststeht. Zwischenstellen können ihn jedoch verlieren, und die Anwendung kann den Inhalt bereits verarbeitet haben.

Wurde eine Zustandsänderung bestätigt, eine Datei freigegeben oder ein Datenstrom weitergereicht, bevor der Trailer geprüft war, lässt sich die frühere Handlung nicht nachträglich als integritätsbedingt darstellen. Eine späte Prüfung bleibt für Audit und Fehlererkennung nützlich. Sie ändert aber nicht die Reihenfolge. Ein verlorener Trailer bedeutet fehlenden Nachweis.

Auch Speicherung verlängert die Aussage nicht automatisch. Eine Übereinstimmung gilt für die erfassten Bytes am Prüfpunkt. Dauerhafte Unverändertheit setzt die Aufbewahrung des vollständigen Objekts und eine erneute Berechnung voraus. Verarbeitungsstufe und logischer Zeitpunkt gehören daher in den Nachweis.

Der Digest bindet nicht die ganze HTTP-Nachricht

RFC9530 hält den Zweck eng. Methode, Ziel-URI, Statuscode und weitere Metadaten sind nicht automatisch geschützt. Das Feld weist keine Identität nach, autorisiert keine Operation und verschlüsselt nichts.

RFC9421 erlaubt, einen Digest und relevante Repräsentationsmetadaten in eine HTTP Message Signature aufzunehmen. Sie müssen ausdrücklich Teil der Signaturbasis sein. Räumliche Nähe in derselben Nachricht schafft keine Bindung. Schlüssel-, Zeit- und Replay-Regeln bleiben eigenständige Aufgaben.

Eine Abweichung zeigt, dass berechnete Bytes und übermittelter Wert nicht zusammenpassen. Sie benennt weder den Verursacher noch dessen Absicht oder Berechtigung. Gerade diese Grenze erlaubt, Byteintegrität mit Transport, Identität, Autorisierung, Signatur und Speicherprüfung passend zum Bedrohungsmodell zu kombinieren.

Quellen und Beweisgrenze

Die Betriebsszenarien sind hypothetisch. Der Beitrag behauptet weder gemessene Verbreitung, Vorfälle, Angriffshäufigkeit oder Rechenkosten noch einen universell sicheren Grenzwert.