Zusammenfassung

  • Die Update-Management-Erweiterungen in draft-ietf-suit-update-management-16 sind optional; ob ein Recipient sie unterstützt, ist eine deployment-spezifische und gegebenenfalls extern gewonnene Tatsache.
  • Lesbare Versionsangaben sind nicht vertrauenswürdige Anzeigeinformationen. Maschinenentscheidung, Autorisierung, Warten, Installation, Aktivierung und laufender Zustand brauchen getrennte Nachweise.

Ein kleiner Diff mit großer Wirkung

Revision 15 enthielt eine klare Kette. Traf ein Recipient auf einen nicht implementierten Befehl oder Parameter, musste er das Manifest ablehnen. Verließ sich ein Manifest Author auf die neuen Funktionen, musste er sicherstellen, dass die Zielgeräte ihre Unterstützung angekündigt hatten.

Revision 16 ersetzt diese Passage durch zwei Sätze: Die Erweiterungen bleiben optional, und das Wissen über die Unterstützung ist deployment-spezifisch und kann out of band etabliert werden. Daraus folgt keine Aussage über ein tatsächlich eingesetztes Produkt. Es folgt aber eine neue Beweisfrage: Welcher externe Datensatz rechtfertigte die Annahme, dass dieses konkrete Gerät den Befehl ausführen kann?

Eine Lieferantenmatrix, ein Build-Flag oder eine Beschaffungsunterlage kann diese Rolle übernehmen. Doch jede Quelle hat Grenzen. Die Baureihe kann fähig sein, während ein älterer Bootloader die Erweiterung nicht kennt. Eine Funktion kann kompiliert, aber deaktiviert sein. Ein Capability-Nachweis braucht deshalb Herausgeber, Zielmenge, Implementationsstand, Prüfmethode und Zeit.

Das Deployment Profile füllt die vom Standard offengelassenen Zuordnungen. Es ist kein neues Objekt auf dem Draht, sondern eine Spezifikation oder Konfiguration. Seine Unsichtbarkeit im Protokoll mindert seine Macht nicht. Wer es aus dem Ausführungsprotokoll entfernt, entfernt die Erklärung für lokale Unterschiede.

Die Signatur schützt die Anweisung, nicht die Implementierung

Ein korrekt verifiziertes Manifest belegt Herkunft und Integrität innerhalb seines Modells. Es belegt nicht, dass der Recipient eine optionale Operation enthält. Diese Unterscheidung ist gerade bei unbeaufsichtigten Geräten wichtig, weil Update-Autor, Verteilung, Policy, Audit und Gerät nicht dieselbe Instanz sind.

Ein belastbarer Lauf verknüpft daher das Manifest mit einem versionierten Capability-Eintrag und dem Deployment Profile. Die Verknüpfung muss auch nach einer späteren Geräteaktualisierung erhalten bleiben. Sonst wird die heutige Fähigkeit rückwirkend zur Erklärung eines gestrigen Verhaltens.

Out of band darf nicht „ohne Provenienz“ bedeuten. Es bezeichnet einen anderen Pfad. Dieser Pfad braucht mindestens so viel Sorgfalt wie die signierte Anweisung, weil er darüber entscheidet, ob sie überhaupt ausführbar ist.

Lesbarer Text besitzt keine Maschinenautorität

suit-set-version ist für deterministische Vergleiche gedacht, wenn die Version verlustfrei im eingeschränkten Schema darstellbar ist. suit-parameter-version liefert Vergleichsoperator und Komponentenversion. Build-Metadaten werden bei der SemVer-Rangfolge ignoriert und gehören nicht in diese Maschinenrepräsentation.

suit-text-current-version und suit-text-version-required erklären die Lage für Menschen. Ein Text wie >=1.2.5,<2 sieht ausführbar aus, ist es aber nicht. Der Manifest Processor darf ihn nicht interpretieren. Bei Widerspruch sind die maschinenlesbaren Felder maßgeblich.

Der Security-Abschnitt behandelt Freitext als untrusted input. Weder Auswertung noch eingebettetes Markup noch eine Überschreibung der strukturierten Entscheidung sind zulässig. Auch UI- und Log-Injection müssen verhindert werden.

Damit reicht es nicht, den Text sicher anzuzeigen. Eine Oberfläche darf aus „benötigte Version“ nicht stillschweigend „Kompatibilität bestätigt“ machen. Ein Vergleichsnachweis benennt das Maschinenfeld, die beobachtete Komponente, die Quelle ihres Versionswerts, das Ergebnis und den Zeitpunkt.

Priorität ist ein Parameter für den Entscheider

Kleinere Zahlen bedeuten höhere Update-Priorität. Welche Aktion ein Wert auslöst, bestimmt die lokale Policy. Die Autorisierungsbedingung übergibt die Priorität an eine Anwendung und scheitert, wenn diese nicht zustimmt.

Eine kritische Kennzeichnung beseitigt also nicht die lokale Autorität. Automatische Freigaben sind möglich, aber sie gehören als versionierte Deployment-Regel in die Akte. Gespeichert werden müssen Rohwert, Policy-Version, Entscheider, Ergebnis und Zeit.

So bleibt erkennbar, ob der Autor Dringlichkeit ausdrückte oder der Betreiber Installation erlaubte. Beides kann gleichzeitig wahr sein, ist aber nicht dieselbe Aussage.

Warten braucht eine Ursache und eine Fortsetzungsregel

Der Wait-Befehl kann von Autorisierung, externer Energie, Netzwerk, einer anderen Geräteversion, Zeit oder Wochentag abhängen. Alle angegebenen Ereignisse müssen eintreten. Die konkrete Warteform ist jedoch implementierungsabhängig: Blockieren, Suspendieren, Polling oder Abbruch mit späterem Neustart.

Lokale Zeit funktioniert nur mit Zeitzone und Sommerzeitregeln. Ein Verweis auf ein anderes Gerät funktioniert nur, wenn das Profil Namensraum, Eindeutigkeit, Versionsquelle und Kodierung definiert. Fehlen diese Angaben, ist das Ereignis unsupported.

Management-Oberflächen sollten daher sowohl die unterstützten Erweiterungen als auch den Grund für Warten oder Fehler zeigen. Die Policy sollte bestimmen, ob ein Wait einen Reboot überlebt, wie er abgebrochen wird und ob ein Timeout gilt.

Der Sammelstatus „pending“ verschleiert Nichtunterstützung, fehlende Zuordnung, legitimes Warten, ausgebliebene Fortsetzung und einen späteren Fehler. Ein operativer Nachweis enthält Zustand, offenes Ereignis, Signalquelle, letzte Bewertung, Persistenz und nächsten erlaubten Übergang.

CoSWID ist Inventarinformation, keine Laufzeitmessung

suit-coswid kann SBOM-, Inventar- und Attestierungsfälle unterstützen. Als severable element kann es entfernt werden, ohne die Manifest-Signatur zu brechen. Seine Anwesenheit verpflichtet nicht jeden Recipient zu vollständiger Verarbeitung.

CoSWID beschreibt, welche Software erwartet wird. Es beweist weder Installation noch Aktivierung noch laufende Ausführung. Dafür sind spätere Nachweise über Fetch, Write, Install, Reboot und gemessene Komponente erforderlich.

Die Information ist zugleich sensibel: genaue Komponenten und Versionen helfen auch Angreifern. Zugriff und Entfernung des Metadatenelements gehören deshalb in die Kontrollkette.

Der vollständige Update-Nachweis

Eine nachvollziehbare Akte trennt Dokumentstatus, signiertes Manifest, Zielgerät, Capability-Provenienz, Deployment Profile, Maschinenwerte, lokale Signalquellen, Bedingungsergebnisse, Wait- oder Fehlergrund, Installationsartefakt, Aktivierung und beobachteten Laufzustand.

Zum Recherchezeitpunkt zeigte Datatracker für Revision 16 „Approved-announcement sent“. Das Dokument war dennoch ein Internet-Draft; die IANA-Aktion lief. Institutionelle Freigabe, finale RFC-Veröffentlichung, registrierte Kennung, Implementation und Betriebserfolg bleiben getrennte Ereignisse.

Die Signatur ist nicht zu schwach. Sie wird nur dann missbraucht, wenn sie für Tatsachen bürgen soll, die außerhalb ihres Umfangs liegen. Gute Update-Governance bewahrt diese Grenzen.

Quellen