要約

  • IESGは2026年9月3日、IoT向けTLS/DTLS 1.3プロファイルをProposed Standardとして承認した。長期間使う端末のアンカー変更を扱うが、規格適合は各端末での変更完了を保証しない。
  • 配信の管理記録とは別に、承認、永続書き込み、有効化、選択された証明書チェーン、旧権限の最終利用、ロールバック境界、アプリケーション受領までを端末ごとに結ぶ必要がある。

IESGの告知は draft-ietf-uta-tls13-iot-profile-25 の承認を伝えた。Datatrackerでは第25版が「Approved-announcement sent」となっており、確認時点では最終RFC番号はまだ付いていない。承認された本文はTLS/DTLS 1.2向けのRFC 7925を補完し、X.509証明書と暗号スイートの要件を更新する。

重要なのは新しい暗号の一覧よりも、端末と組織の時間軸が異なることだ。橋梁センサーや計量器は、CAの交代、メーカー買収、サービス移管、アルゴリズム変更より長く残る。生涯固定のアンカーは、こうした移行とインシデント対応を難しくすると本文は明記している。

トラストアンカーは、検証をどこから始めてよいかという端末側の決定である。TLSのCertificateメッセージにルートが含まれていても、その到着だけで信用してはならない。本文が推奨する基線は、ハンドシェイク外でアンカーを用意し、送信チェーンからルートを省くことだ。

配信画面と端末の現実を分離する

新しいアンカーは安全なファームウェア更新で配れる。RFC 9019のSUITアーキテクチャは、作者、配布者、端末、信頼関係を区別する。しかし配信成功の後にも、署名検証、永続書き込み、有効化、再起動、ストアの再読込、新アンカーを実際に使う接続が残る。

各段階は別の主体と失敗条件を持つ。サーバーが更新を渡した事実はフラッシュの状態を証明しない。端末が保存した事実も、サービスが古い互換チェーンを出し続ける限り、新アンカーの利用を証明しない。

ファームウェアでアンカーを配る範囲にも境界がある。エンドエンティティ証明書や下位CA証明書まで自動的に更新するわけではない。RFC 7030のESTは登録やCA証明書取得の仕組みを提供するが、各製品の実装と成功は別途確認が要る。

同じ「TLS」でも保管責任は三通り

プロファイルはX.509、Raw Public Key、外部PSKを扱い、全IoTに一方式を強制しない。

X.509ではアンカー、下位CA、エンドエンティティを分けて追う。RFC 7250のRPKは交換する証明書構造を減らせるが、鍵と期待する相手の同一性を自動では結び付けない。保護された対応表が別に必要であり、自己署名X.509証明書をRPKと呼び替えることもできない。

外部PSKでは秘密の生成と配布が中心になる。RFC 9257はエントロピー、識別、配備上の危険を整理し、RFC 9258はTLS 1.3のKDFとハッシュ文脈に結び付けるインポーターを定める。それでも生成者、共有範囲、ローテーション、利用可能サービスは運用台帳の項目だ。

橋が残る限り、旧権限も残り得る

CA移行中、サーバーはcertificate_authorities拡張を参照して、相手が対応すると示すCAのチェーンを選べる。RFC 9810のnewWithOldとoldWithNewも世代間を橋渡しする。しかし、どちらも端末への新アンカーの帯域外導入を代替しない。

古いチェーンとの互換性を残せば、更新していない端末も接続できるため稼働率は高い。だが、退役させるはずのCAの認証能力も残る。終了条件のない橋は移行策ではなく恒久的な権限になる。

一方、遠隔端末が新アンカーを書き込む前に旧経路を切れば、復旧用更新を認証する唯一の道を失う。必要なのは一斉の期日ではなく、各コホートがどの経路を最後に使い、どこまで戻せるかを示す証拠である。

バイト削減後の依存先を見る

既定要件のおよそ18KBの処理バッファが重い場合、RFC 8449のRecord Size Limitで受信可能な最大レコードを知らせられる。ただし、その値は総RAM、フラッシュ、消費電力、証明書検証時間の測定ではない。

RFC 9846のTLS 1.3セッション再開は証明書認証の反復を減らすが、チケット数、寿命、再利用はサーバー状態、プライバシー、リプレイ制御に影響する。CoAPやMQTT側に安全な規定がない限り、このIoTプロファイルだけで0-RTTを有効にはできない。

証明書圧縮、キャッシュ情報、証明書URLも通信量を減らす一方、キャッシュや取得サービス、固定識別子への依存を増やし得る。「軽量化」は権限面の単純化とは限らない。

端末別の信頼世代台帳

台帳にはハードウェア、ファームウェア、セキュアブートの世代、更新ルート、資格情報方式、受容アンカーのフィンガープリント、用途、検証方針を置く。移行ごとに承認済みパッケージ、配達、検証、永続化、有効化、再起動、再読込を別々に記録する。

さらにサービスが出したものと端末が選んだものを記す。エンドエンティティ証明書、下位経路、アンカー世代、ネゴシエートしたプロトコル、観測時刻である。アプリケーションの受領は独立した証拠にする。TLS接続は一つの経路で相手を認証したことしか示さず、命令の承認、確定、物理的実行までは示さない。

Lu Hengの現実レイヤー論に従えば、規格承認は象徴、ストアは構成状態、検証は実行、継続性は結果であり、相互に代用できない。Running-Code Primacyは製品表より観測された端末状態を優先する。最小初期仕様と将来判断の局所化は、相互運用を保ちながら単一のCA設計を押し付けない理由を与える。

出典