Zusammenfassung

  • HTTPbis hat eine Call for Adoption zu draft-hardt-httpbis-signature-key-08 eröffnet. Der öffentliche Draft-State bezeichnet eine laufende Konsultation, in der noch kein Konsens über Annahme erreicht ist.
  • Die vorgeschlagenen Header können die Beschaffung eines Verifikationsschlüssels strukturieren. Sie bestimmen nicht, welchen Schlüssel eine Anwendung für welche Handlung als ausreichende Berechtigung anerkennt.

Der Draft nennt fünf HTTP-Felder und acht anfängliche Wege zu Verifikationsmaterial: pseudonyme Inline-Schlüssel, thumbprint-gebundene Delegation, JWKS-URI, direktes JWKS, JWT-Varianten, selbst ausgestellte JWTs, X.509-Ketten und gecachte Assertions. Diese Vielfalt ist ein technischer Gegenstand, kein Katalog von Vollmachten. Ein Verfahren kann einen öffentlichen Schlüssel erreichbar machen, ohne zu bestimmen, welchem Principal ein Ressourceninhaber vertraut.

Die Aufrufnachricht fragt die einschlägige Liste, ob dieser Text Arbeit der httpbis WG werden soll, und setzt den 7. September 2026 als Ende der Rückmeldungen. Datatracker erklärt den Zustand Call For Adoption By WG Issued präzise: Der Aufruf läuft, die Gruppe hat noch keinen Konsens zur Annahme erreicht. Eine spätere Chair-Feststellung, ein WG-Dokument, Reviews, ein IESG-Schritt oder ein RFC sind jeweils eigene Zustände. Sie dürfen nicht aus der bloßen Existenz einer Frist hergeleitet werden.

Der Draft behält auch sachlich Raum für lokale Entscheidungen. Vorab konfigurierte Schlüssel und Out-of-Band-Austausch liegen außerhalb von Signature-Key. Für solche Signaturen ist der Header nicht erforderlich; ein Verifier darf den Schlüssel auf anwendungsspezifische Weise beziehen. Die Spezifikation behauptet damit nicht, die alleinige Quelle jeder Vertrauensentscheidung zu sein. Ein Deployment kann den Header nutzen, zusätzliche Bindungen verlangen oder einen anderen Schlüsselweg wählen.

Gerade diese Freiheit unterscheidet Verifikation von Autorisierung. Eine gültige Signatur kann belegen, dass eine Nachricht mit der zu einem bestimmten öffentlichen Material passenden privaten Schlüssel erzeugt wurde. Sie zeigt nicht, ob der Inhaber ein zugelassenes Konto, ein Dienstprozess, ein delegierter Agent oder ein unberechtigter Dritter ist. Sie legt weder Betrag noch Scope noch Laufzeit fest und ersetzt keine Regel über Widerruf, Ausnahme oder Protokollierung.

Ein Endpunkt, der eine Zahlung freigibt, eine Produktionskonfiguration ändert oder vertrauliche Daten ausliefert, braucht deshalb einen zweiten Nachweis. Er muss den Policy-Eigentümer, die akzeptierten Signiererklassen, Credential-Quelle, Identity Binding, Delegation, Zweck, Grenzen, Ablehnung und Audit Trail benennen können. Der erste Nachweis ist der Weg zur kryptografischen Prüfung. Der zweite ist der Weg zur erlaubten Wirkung. Ein Header kann den ersten verbessern; er kann den zweiten nicht in Besitz nehmen.

Das HTTPbis-Charter gibt dieser Trennung einen Mandatsrahmen. Die aktive Gruppe pflegt das Kernprotokoll HTTP und generische Erweiterungen. Sie kann eine allgemein verwendbare Schnittstelle weiterentwickeln. Sie ist kein Gremium für die Kontopolitik einer Bank, die Einwilligungslogik eines Gesundheitsdienstes oder die Zugriffsrechte eines Unternehmens. Der Standardsprozess schafft eine gemeinsame technische Sprache, nicht eine übertragene Verfügungsgewalt über fremde Ressourcen.

Damit ist der Draft keineswegs belanglos. Die Wahl eines Schemas kann Netzwerkzugriffe, Privacy, Caching, Substitution, Algorithmusverhandlung und Implementierungsaufwand verändern. Ein öffentlicher Adoption Call kann diese Fragen sichtbar machen. Er kann helfen, technische Einwände vor einer möglichen Annahme zu ordnen. Doch auch ein gut gestaltetes generisches Verfahren ersetzt nicht die lokale Risikoprüfung, die bestimmt, ob eine korrekt verifizierte Anfrage überhaupt gewollt ist.

Die Formulierung „standardbasiertes Vertrauen“ wird nur dann ehrlich, wenn sie zwei Protokolle nennt. Das Protokollregister enthält Draft-Version, Call, späteren Konsens und technische Regeln. Das Anwendungsregister enthält Policy-Eigentümer, zulässige Schlüsselformen und Signierer, Bindung an Identität oder Konto, Delegation, Scope, Limits, Logs und Widerruf. Eine Anwendung kann das erste Register referenzieren. Sie kann es nicht als Beleg für die fehlenden Felder des zweiten verwenden.

Auch Mailinglistenpartizipation ändert diesen Befund nicht. Antworten können technische Erfahrung und gewichtige Einwände liefern. Sie werden nicht zur Mandatserteilung durch nicht anwesende Ressourceninhaber. Selbst eine spätere WG-Annahme wäre eine Entscheidung über ein generisches HTTP-Arbeitspaket und keine Zustimmung zu einer konkreten Transaktion. Der gegenwärtige Nachweis reicht daher für eine enge Aussage: HTTPbis prüft ein Key-Discovery-Design; es hat weder eine universelle Vertrauensordnung noch eine reale Anwendungshandlung beschlossen.

Quellen