Zusammenfassung

  • Die Fassung -01 vom 28. September ist ein aktiver individueller Internet-Draft, weder ein RFC noch ein nachweislich von der WIMSE-Arbeitsgruppe übernommener Standard.
  • Eingangs- und Ausgangs-Digests können die Entfernung einer Station offenlegen, die eine Nachricht verändert hat. Bei einer unveränderten Weiterleitung bleiben die benachbarten Digests möglicherweise stimmig.
  • Eine vorgeschlagene aggregierte Signatur soll auch die Beteiligung dieses Durchleiters absichern; Berechtigung, genaue Reihenfolge mehrerer unveränderter Stationen und Ausführungserfolg sind getrennte Prüfungen.

Der unscheinbare Fall ist ein Dienst, der eine Anfrage lediglich annimmt, unterschreibt und unverändert weitergibt. In einer Kette aus drei Arbeitslasten könnte man seine einzelne Signatur später aus einer Liste streichen. Der Ausgangs-Digest der ersten Station passt weiterhin zum Eingangs-Digest der dritten. Wer nur die Inhaltsfolge betrachtet, übersieht den fehlenden Akteur. Genau diesen Unterschied zwischen Inhalts- und Beteiligungsnachweis macht Anhang A des neuen Entwurfs mit drei Stationen sichtbar.

Die überarbeitete Vorlage heißt Authenticated Provenance for WIMSE Delegation Chains. Der IETF Datatracker bezeichnet -01 als aktiven individuellen Internet-Draft, ohne RFC-Stream und mit dem IESG-Status I-D Exists. Er warnt ausdrücklich, dass eine solche Einreichung keine Billigung durch die IETF bedeutet. Das Aggregationskonzept stand bereits in der Fassung -00 vom 8. September. -01 arbeitet die unterschiedlichen Beweisziele deutlicher heraus und behandelt Pfad, Abfrage sowie Antworten ausführlicher; es ist keine erstmalige Erfindung aggregierter Signaturen.

Der bestehende WIMSE-Entwurf für HTTP-Nachrichtensignaturen authentifiziert eine Arbeitslast gegenüber dem unmittelbaren Empfänger. Er liefert dem Endempfänger damit noch keine prüfbare Liste aller Dienste auf einem längeren Delegationsweg. Die individuelle Ergänzung lässt jede signierende Station die Digests des empfangenen und versandten Bodys sowie Werte für Pfad und Query dokumentieren. Entfernt man eine Station, die den Body geändert hat, passen die verbliebenen Ein- und Ausgänge nicht mehr zusammen. Der Prüfer kann eine Änderung einer Station zuordnen; ob deren neuer Inhalt stimmt oder die Änderung erlaubt war, folgt daraus nicht.

Für eine Station ohne Inhaltsänderung reicht diese Verbindung nicht aus. Vorgeschlagen wird deshalb Signature-Aggregate: Jede Signatur geht in einen laufenden gemeinsamen Wert ein, während die Einzelwerte nicht separat übertragen werden. Der Prüfer testet den Gesamtwert gegen die vorgelegten Unterzeichner und Nachrichten. Unter den kryptografischen Annahmen des Textes soll das Entfernen eines signierenden, unverändert weiterleitenden Dienstes die Verifikation scheitern lassen. Das ist eine Sicherheitsbehauptung eines Entwurfs, keine Messung an einer veröffentlichten Implementierung.

Auch die Kosten sind konkreter als die Formel „eine Signatur“. Der aggregierte Wert bleibt annähernd so groß wie eine Signatur, doch Identitätsnachweise, Signatur-Eingaben und Digests wachsen weiter mit der Kette. Alle Stationen brauchen ein gemeinsames aggregationsfähiges Schema. Laut Vorlage lässt sich ML-DSA nicht aggregieren; bei Rückfall auf einzelne Signaturen entfällt der Schutz gegen das Entfernen eines unveränderten Durchleiters. Ein fehlerhafter Beitrag lässt die Gesamtprüfung scheitern, ohne den Verursacher sofort zu benennen.

Die Nachrichtenlinie authentifiziert für sich genommen nicht die Reihenfolge aufeinanderfolgender unveränderter Stationen. Die vorgeschlagenen HTTP-Feldnamen sind IANA-Registrierungsanträge, keine bereits registrierten Schnittstellen.

Die entscheidende Zuständigkeitsgrenze setzt der Entwurf selbst: Autorisierung liegt außerhalb seines Umfangs. Eine gültige Beteiligungssignatur beweist weder die Berechtigung zum Zugriff auf die Aufgabe noch, dass eine Anwendung die Handlung angenommen hat. Diese Tatsachen müssen dort geprüft werden, wo eine Entscheidung wirksam wird.

Quellen