Zusammenfassung

  • draft-reddy-wimse-aggregate-signatures-01 verbindet eine signierte Digest-Kette mit einer Aggregatsignatur: Die Digest-Kette zeigt Inhaltsänderungen; das Aggregat erschwert auch das unbemerkte Entfernen eines Signierers, der den Body unverändert weitergab.
  • Nur der aggregierte Signaturwert bleibt annähernd konstant. Workload Identity Tokens, Signature-Input-Einträge, frühere Pfad- und Query-Werte sowie Kontinuitätsdigests wachsen pro Hop.
  • Erfolgreiche Prüfung belegt die dargestellten Signierer und die ihnen zugeschriebenen Änderungen. Sie belegt weder eine vollständige Soll-Kette noch Berechtigung, fachliche Richtigkeit, Ausführung oder Geschäftserfolg.

Zwei Schutzwirkungen, die nicht verwechselt werden dürfen

Eine dynamische Delegation ist keine einzelne, unverändert weitergereichte HTTP-Nachricht. Ein Agent formuliert einen Auftrag. Ein Orchestrator macht daraus einen konkreten Aufruf. Ein Werkzeug ergänzt Parameter. Ein Gateway ändert den Zielpfad, obwohl der Body gleich bleibt. Am Ende besitzt der Empfänger nur die letzte Darstellung.

Revision 01 von Authenticated Provenance for WIMSE Delegation Chains will frühere Darstellungen verifizierbar machen. Das Dokument erschien am 28. September 2026 als aktiver individueller Internet-Draft. Es ist kein RFC, kein WIMSE-Arbeitsgruppendokument, kein IETF-Konsens, kein Implementierungsbericht und kein Nachweis realer Einführung. Die beabsichtigte Einstufung Standards Track ändert an diesem gegenwärtigen Status nichts.

Der Entwurf beginnt mit Hop-zu-Hop-Kontinuität. Jeder signierende Workload trägt in wimse-req-digest den Digest des empfangenen Bodys und in Content-Digest den Digest des gesendeten Bodys. Der Initiator verwendet für den Eingang den reservierten Wert origin. Ein späterer Prüfer vergleicht den signierten Ausgang eines Dienstes mit dem signierten Eingang seines Nachfolgers.

Hat H2 den Body geändert, reißt die Kette, wenn jemand H2 entfernt. Der Ausgang von H1 passt dann nicht mehr zum Eingang von H3. Der Beleg weist die Veränderung H2 zu, weil H2 beide Seiten signiert hat. Er sagt nicht, ob die Veränderung zulässig, korrekt oder erwünscht war. Ein irrtümlicher oder missbräuchlicher Dienst kann eine in sich konsistente Veränderung signieren.

Diese Digests schützen außerdem nicht die gesamte HTTP-Semantik. Methode, Pfad, Query, ausgewählte Header und Digest werden über die Signaturbasis des jeweiligen Hops gebunden. Ohne diese Basis wäre ein lückenloser Body-Digest nur ein Teilbeleg.

Die zweite Schutzwirkung entsteht durch Signature-Aggregate. Jeder Hop signiert seine eigene Basis. Statt sämtliche einzelnen Signaturwerte zu transportieren, werden sie in einen laufenden Aggregatwert eingebracht. Der Empfänger prüft ihn gegen eine geordnete Liste aus öffentlicher Schlüssel und rekonstruierter Nachricht für jeden Signierer.

Damit wird ein anderer Angriff sichtbar. Gibt H2 den Body unverändert weiter, zeigen die benachbarten Digests sowohl mit als auch ohne H2 dieselbe Kontinuität. Einzelne, getrennt übertragene Signaturen ließen sich zusammen mit dem H2-Eintrag entfernen. Aus einem Aggregat lässt sich H2s Beitrag nicht einfach herauslösen. Wird H2 aus der vorgelegten Signiererliste gestrichen, schlägt die Gesamtprüfung fehl.

Doch auch dieses Ergebnis ist begrenzt. Ein Vermittler, der nie signiert hat, wird durch die Aggregation nicht nachträglich sichtbar. Ein vorgeschriebener Prüfdienst, den die Route vollständig umging, hinterlässt keine negative Signatur. Ob bestimmte Rollen zwingend teilnehmen mussten, kommt aus externer Richtlinie, nicht aus dem mathematisch gültigen Aggregat.

Die Signatur ist nicht ihr eigener Prüfkontext

Der Größenabschnitt des Entwurfs sagt ausdrücklich: Der Aggregatwert bleibt ungefähr so groß wie eine Signatur, die übrigen Felder nicht. Signature-Input, Workload-Identity-Tokens und Digests wachsen mit der Kettenlänge.

Für jeden Hop benötigt der Prüfer mindestens ein eindeutiges Label, die Liste der abgedeckten Komponenten, Zeit- und Nonce-Parameter, Tag und Audience, den WIT, Eingangs- und Ausgangsdigest, den früheren Pfad und die frühere Query sowie die Ordnung, in der Nachbarbelege zusammengehören.

Workload-Identity-Tokens ist ein Structured-Fields-Dictionary, dessen Mitglieder anhand der Signaturlabel unterschieden werden. Jeder Hop bewahrt die bisherigen Mitglieder, validiert den Präfix, fügt sein Token unter einem neuen Label hinzu und deckt das eigene Mitglied mit seiner Signatur ab. Entfernen oder Ersetzen eines früheren WIT verändert einen signierten Wert.

Der WIT liefert über sub die beanspruchte Workload-Identität und über cnf.jwk den öffentlichen Schlüssel. Das Mitführen eines Tokens ist aber kein Vertrauensurteil. Aussteller, Gültigkeit, Audience, Schlüsselbindung, Vertrauensdomäne und Algorithmuspolitik müssen weiterhin geprüft werden. Verarbeitung vor abgeschlossener Tokenprüfung würde eine kryptografische Zutat mit einer Zulassungsentscheidung verwechseln.

Auch Pfad und Query müssen konserviert werden. Der letzte Request enthält möglicherweise /commit?mode=fast, während H1 /plan?region=eu signierte. Revision 01 legt pro Hop wimse-req-path und wimse-req-query in signierten Parametern ab. Der Prüfer rekonstruiert damit die jeweilige ältere Signaturbasis, anstatt die letzte URI rückwirkend auf alle Hops anzuwenden.

Für den Ausgangsdigest eines Hops wird der signierte Eingangsdigest des Nachfolgers verwendet. Beim letzten Hop liefert die finale Nachricht den Content-Digest. Methode und Content-Type nimmt die Rekonstruktion aus der letzten Nachricht, weil der Entwurf ihre Änderung entlang der Kette verbietet. Eine Änderung lässt frühere Basen scheitern.

Die Beweisform ist deshalb S + Σ(Wᵢ + Iᵢ + Dᵢ + Rᵢ): ein Aggregat S, dazu je Hop Token, Signaturinput, Digestmaterial und Rekonstruktionswerte. Das ist Daniel Kades Erklärungsmodell, kein Benchmark. Reale Bytes hängen von Tokenlänge, Labels, URI, Algorithmus, Structured-Field-Serialisierung und Headerkompression ab.

Gültig oder ungültig ist noch keine Diagnose

Eine Aggregatsignatur liefert ein Kollektivurteil. Passt jeder Beitrag zur vorgelegten Schlüssel-Nachrichten-Liste, ist die Prüfung erfolgreich. Ein einziger falscher Beitrag macht das Aggregat ungültig. Aus diesem einen Wert erfährt der Prüfer nicht, welcher Hop die Ursache war.

Das schafft einen Verfügbarkeitshebel. Ein abgelaufener WIT, verlorener Query-Wert, beschädigter Digest oder nicht zugelassener Schlüssel kann die gesamte Kette sperren. Die Annahmeprüfung darf deshalb nicht mit der Fehlerlokalisierung gleichgesetzt werden. Für Letztere können geschützte Hop-Protokolle, gespeicherte Präfixprüfungen, lokale Validierungsbelege oder kontrollierte Wiederholung nötig sein. Revision 01 definiert kein allgemeines Blame-Protokoll.

Der Algorithmus ist eine weitere Richtliniengrenze. Alle Hops eines Aggregats brauchen ein kompatibles aggregierbares Verfahren. Der Entwurf nennt BLS Message Augmentation als derzeit mögliche Instanziierung; der WIT-Algorithmusbezeichner bleibt einer gesonderten Spezifikation vorbehalten. BLS ist nicht postquantenfest. Selbst eine mathematisch gültige BLS-Prüfung ersetzt weder Allowlist noch Vertrauensdomänen- und Downgrade-Regel.

Fehlt ein geeignetes Aggregatverfahren, kann die Kette Einzelsignaturen verwenden. Dann bleibt die Entfernung eines verändernden Hops über Digestdiskontinuität erkennbar. Die besondere Nichtentfernbarkeit eines unverändert weiterleitenden Signierers geht verloren. Ein Betriebsbeleg muss festhalten, welcher Modus tatsächlich galt.

Rückweg, Commit und beobachtete Wirkung

Antworten können die Kette in umgekehrter Richtung schützen. Der Antwortursprung setzt wimse-resp-digest="origin"; weitere Hops erfassen empfangene und weitergegebene Darstellungen und aggregieren ihre Signaturen. Ohne signierten Rückweg kann diese Konstruktion eine veränderte oder verworfene Antwort nicht zuverlässig erkennen.

Ein verifizierter Rückweg beweist dennoch keinen Commit. Er bindet eine Aussage und ihre Weitergabe an Workloads. Ob eine Transaktion dauerhaft gespeichert, Geld bewegt, Zugriff gewährt oder ein Produktionszustand geändert wurde, benötigt einen Anwendungsbeleg und möglichst unabhängige Beobachtung.

Damit bleiben fünf Belegarten getrennt: Teilnehmeridentität, Transformation, Aggregatprüfung, Richtlinienentscheidung und Ergebnis. Die ersten drei können authentifizierte Provenienz liefern. Sie erteilen nicht selbst die Befugnis und ersetzen nicht die letzten beiden.

Quellen

Die Quellen wurden am 30. September 2026 in der Zeitzone Asia/Shanghai eingefroren. Sie enthalten keine gemessene Mehrlast, interoperable Implementierung, reale Attacke, Produktionsersparnis, Konformitätsbewertung oder beobachteten Schaden. Diese Analyse behauptet weder einen bösartigen benannten Workload noch eine bereits bewährte Einsatzpraxis.