Zusammenfassung

  • Die auf den 27. September datierte Revision 16 der SUIT-Erweiterungen ist weiterhin ein aktiver IETF-Internet-Draft, keine veröffentlichte RFC.
  • Die Implementierung und Verwendung der Erweiterungen sind optional. Ob ein Empfänger sie unterstützt, muss laut neuer Fassung für die jeweilige Bereitstellung bekannt sein; die Information kann außerhalb des Protokollaustauschs gewonnen werden.
  • Revision 15 verlangte noch ausdrücklich eine Unterstützungsmeldung vor dem Versand abhängiger Manifeste. Die Streichung dieser allgemeinen Pflicht bedeutet nicht, dass unbekannte Befehle als ausgeführt gelten dürfen.

Der Zeitpunkt der entscheidenden Prüfung liegt vor dem Rollout. Wird ein signiertes Manifest an mehrere Hardwaregenerationen adressiert, belegt die Signatur weder deren Softwarestand noch den Befehlssatz ihrer Manifestverarbeitung. Ein Gerät kann den Absender anerkennen und dennoch die optionale Wartebedingung, Batterieprüfung oder Versionsoperation nicht implementiert haben. Ein Verteiler, der beides unter „Update angenommen“ zusammenfasst, verliert eine wichtige Unterscheidung.

Update Management Extensions for SUIT Manifests beschreibt zusätzliche Metadaten, Parameter und Befehle für diese und weitere Abläufe. Revision 16 hält fest, dass die Erweiterungen weder verpflichtend zu implementieren noch verpflichtend in Manifesten zu verwenden sind. Neu ist die Aussage, das Wissen über die Unterstützung eines Empfängers sei bereitstellungsspezifisch und könne außerhalb des direkten Austauschs hergestellt werden. Der Datatracker führt das Dokument nach der IESG-Bewertung weiterhin unter AD Followup. Sein angestrebter Status als Proposed Standard ist noch keine erteilte Anerkennung als RFC.

Die vorherige Fassung setzte anders an: Der Manifestautor sollte vor dem Versand sicherstellen, dass die angepeilten Empfänger die benötigten Erweiterungen ankündigen. Revision 16 ersetzt diesen allgemeinen Satz durch die lokale Zuordnung. Das lässt Raum für ein Einsatzprofil, eine Verwaltungsschnittstelle oder einen Testnachweis. Es ist aber weder ein neues universelles Aushandlungsverfahren noch eine Aussage, dass ein bestimmtes Verfahren überall vorhanden ist. Aus dem Textvergleich lässt sich auch kein Motiv der Autoren sicher ableiten.

Besonders sorgfältig muss der Umgang mit nicht unterstützten Befehlen gelesen werden. Der grundlegende SUIT-Manifestentwurf nennt unbekannte Befehle und Parameter unter den möglichen Gründen, ein Manifest auszuschließen. Die neu beschriebenen Managementbefehle bleiben optional. Dass eine Pflicht des Autors wegfällt, erlaubt daher nicht den Schluss, ein Empfänger dürfe eine unbekannte Anweisung stillschweigend überspringen und Erfolg melden. Maßgeblich sind die Grundregeln, das Einsatzprofil und die beobachtete Implementierung.

Abschnitt 6 macht deutlich, wie viel vor Ort entschieden werden muss: Rechte und Identitäten auf lokale Zugangskontrolle abbilden, Herkunft und Genauigkeit der Batteriewerte kennen, Prioritäten politisch festlegen und Ereignisquellen für Wartebedingungen definieren. Verwaltungsschnittstellen sollen unterstützte Erweiterungen sowie Warte- und Fehlergründe anzeigen. Dieses SHOULD ist eine Empfehlung, kein Beleg über tatsächlich vorhandene Gerätefunktionen.

Es geht nicht erneut um die Frage, ob ein Signierer das Installieren autorisieren darf. Der neue, engere Prüfpunkt lautet: Wer kann für genau diese Zielkohorte nachweisen, dass sie den erforderlichen optionalen Befehl versteht? Ein Warteschlangeneintrag und eine gültige Signatur beantworten ihn nicht.

Quellen