要約

  • 9月27日付のSUIT更新管理案第16版は、まだIETFのInternet-Draftであり、RFCとして発行されたものではない。
  • 追加機能の実装とマニフェストへの採用はいずれも任意だ。受信側が対応するかどうかは導入環境固有の情報で、帯域外で確認してもよいと新しい本文は述べる。
  • 第15版にあった、作成者が配布前に受信側の対応表明を確認するという一律の規定は削られた。ただし、未知の命令を成功扱いしてよいという変更ではない。

現場では、同じ製品群として管理される装置でも、起動用ソフトウエアや更新処理系の世代が違う。配布システムがマニフェストの署名を検証した時点で分かるのは、そのデータの出所と完全性だ。電池残量の条件や特定の待機命令を、対象装置が解釈できるかどうかは別の調査を要する。

今回のUpdate Management Extensions for SUIT Manifestsは、更新の優先度、バージョン確認、ローカルな許可、イベントまでの待機などを扱う追加の項目と命令を定義する草案だ。第16版はそれらを実装することも、マニフェストに含めることも任意とした上で、受信側の対応状況に関する知識は導入環境に依存し、帯域外で確立できると記す。Datatracker上の状態はIESG評価後のAD Followupで、標準の成立や製品普及を示すものではない。

注目すべき差は、前版が書いていた作成者への指示だ。第15版は、必要な拡張に受信側が対応すると表明していることを配布前に作成者が確かめるよう求めていた。第16版ではその一律の文言がなくなった。運用プロファイル、管理画面、試験結果などで確認する道は残るが、新版が共通の能力交換方式を新設したわけではない。削除の理由を推測して特定の審査判断に結び付けることもできない。

反対方向の誤解にも注意したい。SUITの基礎マニフェスト案は、未対応の命令やパラメータに遭遇した場合を、マニフェストを除外し得る理由として挙げる。更新管理案の新命令も引き続き実装任意である。したがって、配布前確認についての文が変わったことから、未知の命令を無視して処理済みにできるとは言えない。実際の扱いは、基礎仕様、適用するプロファイル、装置の挙動で確かめるべきだ。

導入上の注意事項には、さらに地域的な、というより装置群ごとの事情が並ぶ。権限識別子とローカルアクセス制御の対応、電池情報の測定源、優先度に結び付くポリシー、待機に使う時刻や他装置の情報などである。草案は管理インターフェースに、対応拡張と待機・失敗の理由を示すよう勧めるが、SHOULDという勧告が全機種での実装を証明するわけではない。

問われるのは、署名者のインストール権限そのものではなく、配布対象の装置群が必要な追加命令を理解できるという判断を誰が裏付けるかだ。「配信キューに入った」と「実行可能である」の間には、個別に検証しなければならない境界がある。

出典