Zusammenfassung

  • abc, "abc", #616263#, 3:abc und |YWJj| können dieselben drei Oktette bezeichnen; nur die kanonische Darstellung liefert die eindeutigen Signaturbytes.
  • Ein Anzeigehinweis kann mit signiert sein, ohne Typ, Vertrauen oder Berechtigung zu beweisen.
  • Belastbare Evidenz trennt Eingabe, Parserprofil, kanonische Ausgabe, Signatur, Interpretation, Richtlinienentscheidung und beobachtete Wirkung.

Sichtbare Zeichen sind nicht die Signaturgrenze

Ein Terminal zeigt abc, eine Datei "abc", ein Trace #616263#, eine Nachricht 3:abc und ein Werkzeug |YWJj|. RFC 9804 zeigt, dass alle fünf Formen dieselben drei Oktette ergeben können. Ein Bild davon sagt nicht, welche Bytes beim Signieren vorlagen.

Eine S-Expression ist eine Oktettfolge oder eine endliche Liste. Die Spezifikation unterscheidet vier Umgebungen: fortgeschrittene Darstellung für Menschen und Diagnose, Basis-Transport für empfindliche Kanäle, eindeutige kanonische Darstellung für Signaturen und eine implementierungsinterne Speicherform.

Kanonische Strings bestehen aus dezimaler Bytelänge, Doppelpunkt und unveränderten Bytes. Listen enthalten keinen optionalen Satz. Die gesamte kanonische Folge kann als Base64 in geschweiften Klammern reisen. Diese Hülle ändert den Transport, nicht die Bedeutung; nach dem Dekodieren müssen exakt dieselben kanonischen Bytes entstehen.

Die fortgeschrittene Form erlaubt Token, Anführungszeichen, Hexadezimal, Base64, Längen und Leerraum. Ihre Unterstützung ist optional. Eine Anwendung sollte sie nur aufgrund ihres Profils oder festgestellter Fähigkeit annehmen. „Parse erfolgreich“ ohne Version, freigegebene Formen, Tiefen- und Längenlimits sowie Anwendungsregeln ist nicht reproduzierbar.

Ein signierter Hinweis bleibt ein Hinweis

Ein Anzeigehinweis sagt der Anwendung, wie sie Daten darstellen soll, und hat laut RFC 9804 keine andere Funktion. Ist er vorhanden, gehört er zur kanonischen Darstellung und kann signiert werden. Das belegt seine Aufnahme, nicht die Wahrheit eines Typs, die Sicherheit des Handlers oder eine Erlaubnis.

Ohne Hinweis gilt ein lokaler Standard; allgemein ist das application/octet-stream. Zwei Programme dürfen identische Oktette verschieden anzeigen. Auch Gleichheit ist eine Profilfrage. Der RFC empfiehlt Gleichheit von Hinweis und Daten, lässt aber etwa das Ignorieren des Hinweises zu. Diese Regel samt Version gehört in den Nachweis.

Grammatik ist nur das erste Tor. RFC 9804 erlaubt, fortgeschrittene Formen, Hinweise, leere Strings oder Listen zu verbieten und Ressourcenlimits zu setzen. RFC 2693 verengt SPKI konkret: keine leeren Listen und ein Typstring an erster Stelle.

Die Evidenzkette beginnt mit empfangenen Bytes und Rahmung. Sie nennt Parser, Grammatik, Profil und Grenzen und hält das abstrakte Objekt fest. Danach werden kanonische Bytes neu ausgegeben und gehasht. Die Signaturprüfung bindet diesen Hash an Schlüssel und Zertifikatspfad; eine Anzeige ersetzt ihn nicht.

Erst danach entsteht Bedeutung. RFC 2692 überlässt dem Autor des Anwendungscodes die Semantik einer SPKI-Autorisierung. RFC 2693 beschreibt vertrauenswürdige Tupel und Reduktion, doch die Anwendung entscheidet. Handler, Richtlinienversion, Subjekt, Aktion, Ressource und Ergebnis müssen erfasst werden. Die tatsächliche Ausführung braucht eine eigene Beobachtung.

Empfang, Zulassung, Parsing, Kanonisierung, Signatur, Interpretation, Autorisierung und Wirkung bilden eine Kette. Bei Parserabweichung vergleicht man Eingabe und kanonischen Hash. Bei gleicher Signatur und anderer Wirkung untersucht man Handler und Policy. RFC 9804 ermöglicht Byte-Einigung, überträgt aber keine spätere Autorität.

Quellen