Zusammenfassung

  • draft-ietf-opsawg-yang-provenance-07 bindet kanonisierten YANG-Inhalt an einen COSE-Schlüssel; die Zuordnung des kid zum richtigen öffentlichen Schlüssel und zu einer verlässlichen Quelle bleibt eine lokale Deployment-Entscheidung.
  • Ein belastbarer Nachweis trennt mathematische Gültigkeit, Schlüsselzweck, Verwaltungsdomäne, Gegenzeichnungen, Verarbeitungslücken, Aktualität, Entscheidungsbefugnis, Ausführung und beobachtete Wirkung.

Der Verifier meldete eine gültige Signatur. Der kid ließ sich auflösen, die Zertifikatskette war formal korrekt und die kanonisierten Bytes passten.

Nur gehörte der Schlüssel zur Testorganisation eines früheren Dienstleisters. Eine Aliasregel im lokalen Verzeichnis hatte ihn der produktiven Controller-Domäne zugeordnet.

Die Mathematik beantwortete die gestellte Frage. Die Organisation hatte die falsche Frage konfiguriert.

Revision 07 von Applying COSE Signatures for YANG Data Provenance erschien am 6. Juli 2026 und läuft am 7. Januar 2027 ab. Sie ist ein aktiver OPSAWG Working-Group Internet-Draft mit Standards-Track-Ziel im Kopf. Sie ist weder RFC noch abgeschlossene IANA-Zuweisung, Interoperabilitätsnachweis, Deployment-Studie oder Sicherheitszertifizierung. Der Datatracker zeigte am 25. August 2026 vier YANG-Fehler und keine Warnung. Referenzimplementierung und Hackathon-Demonstrationen belegen nur den angegebenen Prototypumfang.

Die Signatur hat einen präzisen Geltungsbereich

Der Entwurf verwendet COSE_Sign1 mit nil payload. Der ausgewählte YANG-Inhalt wird nach der für seine Serialisierung geltenden Kanonisierung als external data signiert. CBOR nutzt length-first deterministic encoding, JSON JCS und XML Exclusive XML Canonicalization 1.0.

Algorithmus, kid und Serialisierungsmethode werden geschützt. Ein positives Ergebnis bedeutet, dass genau diese kanonisierten Bytes vom zugeordneten privaten Schlüssel signiert und danach nicht verändert wurden.

Es bedeutet nicht, dass benachbarte Nodes eingeschlossen waren, ein Schema richtig interpretiert oder eine spätere Konvertierung semantisch identisch ist. Der Receipt muss Scope, Schema, Serialisierung, Kanonisierung, Hash, Algorithmus, kid, aufgelösten Schlüssel, Trust-Policy und Zeitpunkt festhalten.

kid ist ein Verweis, kein selbstbeweisender Name

Der Entwurf lässt die Auslegung des kid und seine Bindung an einen Public Key ausdrücklich beim Verifier. Zertifikate, PKI oder sichere Out-of-band-Verteilung können die Zuordnung tragen. Sie bleiben jedoch Governance-Infrastruktur außerhalb des Signaturformats.

Die Organisation muss deshalb beantworten, welche Domain der Schlüssel vertreten darf, für welchen Zweck er ausgestellt wurde, wer seine Rotation verantwortet und welcher Revocation-Zustand galt. Ein technisch gültiger Schlüssel aus dem falschen Tenant oder einer abgelaufenen Betreiberbeziehung ist keine akzeptable Quelle.

Bei Kompromittierung kann ein Angreifer gültige Signaturen erzeugen. Auch ein legitimer Inhaber kann falsche oder bösartige Daten signieren. Herkunftsauthentisierung beweist Schlüsselbesitz, nicht Wahrheit oder redliche Absicht.

Gegenzeichnungen verbreitern nicht den Inhalt

Weitere Akteure dürfen vollständige COSE-Countersignatures nach RFC 9338 hinzufügen. Die Primary Signature und ihr kanonisierter Input bleiben unverändert; zusätzliche Signer binden sich an dasselbe Objekt.

Das ist hilfreich für Custody oder Bestätigung. Es signiert aber keine neu berechnete Aggregation. Wer Felder normalisiert, Werte verwirft oder eine Empfehlung erzeugt, schafft einen neuen Claim. Dafür braucht es einen Input/Output-Receipt mit beiden Hashes, Codeversion und Parametern sowie eine neue Signatur.

Der Verifier darf Primary, eine Teilmenge oder alle Gegenzeichnungen gemäß lokaler Policy prüfen. Das sichtbare Ergebnis muss nennen, welche Signer vorgeschrieben, geprüft, fehlgeschlagen oder ausgenommen waren. Ein allgemeines „verified“ verschleiert sonst den eigentlichen Assurance-Vertrag.

Eine fehlende Unterschrift erzeugt keinen Kryptofehler

Der Entwurf räumt ein, dass eine Herkunftsspur nur so vollständig ist wie die vorhandenen Signaturen. Das Verfahren garantiert ihre Kontinuität nicht und erkennt nicht allein, dass eine Zwischenstelle nie signiert hat.

Erforderlich ist ein erwarteter Workflow-Graph. Er definiert Gerät, Broker, Aggregator, Analyse, Freigabe und Controller sowie die Inputs und Outputs, die jede Stufe verbinden muss. Erst der Vergleich zwischen Soll- und Ist-Signern macht eine Lücke sichtbar.

Kryptografie stärkt vorhandene Belege. Sie erfindet weder den fehlenden Akteur noch dessen Mandat.

Ein alter Claim bleibt unverändert

Freshness ist nicht eingebaut. Zuvor gültige Daten können erneut abgespielt werden, wenn Timestamp, Nonce, Request-ID oder ein gleichwertiger Kontext nicht gebunden sind.

Für die Annahme sind maximale Lebensdauer, Policy-Epoche, Zeitquelle, Revocation und Einmalverbrauch relevant. Ein gestern autorisierter Desired State kann heute intakt und zugleich unzulässig sein.

Schema-Validierung ergänzt Struktur, nicht Sachrichtigkeit. Ein YANG-konformer Messwert kann falsch sein. Eine AI/ML-Auswertung über authentischen Input ist ein neuer Claim und braucht Modellversion, Features, Output-Hash, Unsicherheit und Freigabe.

Herkunft ist nicht Änderungsbefugnis

Der Schlüssel, der Telemetrie signiert, sollte keine implizite Produktionsänderung auslösen dürfen. Entscheidungsbefugnis gehört zu einem aktuellen Principal: Betreiber, Service Owner, Change Board oder ausdrücklich delegierte Automation Policy.

Damit folgt die operative Logik der Heng-Lu-Notizen: Technischer Nachweis kann eine Behauptung disziplinieren, aber keine Vollmacht für Abwesende erzeugen. Wer Kontinuität, Kundenpflichten und Verlust trägt, muss die Autorisierung kontrollieren.

Auch nach der Freigabe fehlen Ausführung und Wirkung. Ein Controller kann bestätigen, ein Gerät kann ablehnen, nur ein Teil der Flotte kann wechseln oder die Konfiguration kann ohne erwartete Forwarding-Wirkung erscheinen.

Vier Enclosing Methods sind Transport, kein Urteil

Der Entwurf beschreibt Provenance Leaf, YANG-Push-Erweiterung, Metadata für Instance Data und Annotation. So kann der Nachweis gespeicherte oder vermittelte Daten begleiten, wenn ein geschützter Live-Transport nicht mehr genügt.

Die vollständige operative Kette bleibt länger: signierte Quelle, jede Transformation, Analyse, aktuelle Autorisierung, Controller-Akzeptanz, Device Readback und unabhängige Servicebeobachtung. Jede Koordinate hat einen eigenen Verantwortlichen.

Die belastbare Aussage lautet deshalb: Diese kanonisierten Bytes wurden von dem Schlüssel signiert, den diese lokale Policy diesem kid zuordnete, und danach nicht verändert. Ob die Zuordnung richtig, der Inhalt aktuell, die Handlung erlaubt und die Wirkung real war, muss separat bewiesen werden.

Quellen