要約

  • RFC 9997は二つの巨大な私用範囲を設け、条件を満たすPEN保有者が10万個単位のSIDブロックを計算できるようにした。小さいPENには1万個単位の別ブロックもある。解消するのは割当の往復であり、成果物の認証ではない。
  • 同RFCは、SIDに特定のPENが含まれても出所を示さないと警告する。RFC 9595も、誤った整数とスキーマ項目の対応が意味を変えるため、.sidファイルを権威ある場所から入手するよう求めている。
  • Daniel Kadeは、登録簿、範囲計算、公式配布元、モジュールとSIDファイルのダイジェスト、割当履歴、完全性検証、YANG Libraryの実装状況、採否を八つの面として結ぶ最小限の出所バインディング記録を提案する。

計算できることと、信用できることの距離

ある管理システムに、新しいYANGモジュールとSIDファイルが届く。含まれる整数を調べると、名乗られた企業のPENから導く範囲にすべて入っている。CBORの試験データも問題なく復号され、見慣れたノード名が現れる。導入担当者にとっては、十分に整った荷物に見える。

しかし、範囲の計算法は公開されている。第三者も同じPENから同じ開始位置を求め、その内側に数字を並べられる。モジュール名、名前空間、改訂日も似せられる。ファイル同士を一貫させれば、復号試験さえ通るだろう。算術上の整合性は、公開権限を一度も検査していない。

RFC 9997は2026年7月、IETF標準化過程のProposed Standardとして公開された。Private Enterprise Numberを使い、私用のYANG Schema Item iDentifier範囲を導く方法を定める。社内、実験、独自用途のモデルごとに中央割当を求めれば生じる手間を、衝突を避けながら減らすための仕組みだ。

YANG SIDは、YANGのモジュール、識別子、ノードなどを63ビットの符号なし整数へ対応付ける。RFC 9254のYANG-CBORでは、長い名前やパスの代わりに小さな整数を送れるため、制約のある環境で効く。ただし、送受信側が同じ対応表を持つことが前提になる。

一意性が守るのは、慎重に割り当てる二者が偶然同じ番号を別用途に使う事故である。一意な番号それ自体は、配布者を認証しない。正規の棚番号が付いた箱でも、誰が中身を入れたかは別に確かめなければならない。

二つの巨大範囲が申請を計算に変える

IANA YANG SID登録簿には、RFC 9997が設けた二範囲がPrivateとして載っている。3,000,000,000から3,999,999,999までと、300,000,000,000から399,999,999,999までである。ここでのPrivateは割当方針を意味し、秘密性を意味しない。

1,000,000未満のPENは、大きい方の範囲から10万SIDのブロックを決定的に導ける。100,000未満のPENなら、小さい方の範囲にも1万SIDのブロックを持てる。PENを基に開始点を計算するため、ブロックごとにIANAと追加調整する必要がない。

中央は全体の境界と企業番号を管理し、数式が各保有者の区画を切り分け、保有者が私用割当を管理する。異なるPENから同じ区画が出ないようにした、役割分担の良い設計である。

例示用PENの扱いにも一貫性がある。RFC 5612は32473を文書用に予約している。RFC 9997もそこから導く二つのSIDブロックを文書用として予約した。実在企業の空間を借りずに、読者は正確な計算例を再現できる。

この取得方法は、RFC自身が低い敷居とゼロインタラクションを特徴として挙げる。迅速に試せるから価値がある。だからこそ、後から強い本人確認だったかのように扱ってはならない。反復審査を省くための制度は、反復審査の代用品にはならない。

範囲の管理者とファイルの発行者は同じ証拠ではない

RFC 9997は、導出した範囲の管理を該当PENの保有者へ委ねる。これは誰がその区画内を割り当てる権限を持つかという話だ。手元のファイルが、その権限者の認めた経路から届いたかどうかまでは、番号だけで分からない。

セキュリティ考察は明快である。SIDに特定PENが現れても、それは出所の指標ではない。SIDや基礎となるYANGモデルがPEN保有者に由来する保証にもならない。範囲から企業名を連想する人間の癖を、仕様が先回りして否定している。

IANA Private Enterprise Numbers登録簿が示すのは番号の登録であって、商標権の審査、ソフトウェア署名証明書、特定リポジトリの現在の管理権ではない。YANG SID登録簿は範囲方針を示すが、その中で使われる全私用モデルの目録ではない。

実際の供給には別の対象が並ぶ。公式と認められた配布場所、YANGモジュールの名前・名前空間・改訂・実体、対応する.sidファイル、転送時の完全性、実装が有効にしたスキーマである。PENが正しくても、このどこかが誤っていることはあり得る。

RFC 9595が権威あるSIDファイルを求めるのは、対応表が意味そのものを左右するからだ。不正な.sidを取り込めば、受け取った整数を別の設定項目や状態として解釈しかねない。管理システムでは、SIDファイルにもYANGモジュールと同等に権威ある入手元が必要になる。

範囲確認が答えるのは「この番号をPEN保有者が割り当て得るか」である。出所確認が答えるのは「この対応付けを本当に権限者が発行したか」である。前者は登録簿と数式で済む。後者には配布元の委任、実体の同一性、完全性検証が要る。

見つける仕組みは、信頼の根を自動では作らない

RFC 9997は、PEN由来SIDから認証済みモジュールへ世界共通で解決する探索基盤を定めていない。秘匿を目的としない場合は、YANGモデルとSIDファイルを公開リポジトリに置くこと、実装でYANG Libraryを提供すること、またはその両方を勧める。

公開は発見性を高める。だが、検索で上位に出た場所が公式とは限らない。どの場所を保有者が認めたか、管理権をどう確認したか、承認された改訂とダイジェストは何か、移転や侵害の際に旧経路をどう無効にするかが必要だ。

RFC 8525のYANG Libraryは、稼働サーバーの宣言状態を詳しく表せる。モジュール、改訂、名前空間、機能、偏差、スキーマ、データストアを列挙する。サーバー固有のcontent-idは情報が変われば変更される一方、同じ情報が別サーバーや別時点で同じ値になる義務はない。

従ってcontent-idは、そのサーバーでスキーマ状況が変わったことを検出する手掛かりであり、世界共通の内容ハッシュではない。ある時点の実装宣言は示せても、モジュールの最初の発行者や、ダウンロード経路の完全性を過去へさかのぼって認証しない。

必要なのは一個の万能印ではなく、連続する確認だ。登録簿は範囲を示す。権限記録は公式配布元を示す。ダイジェストは確認したバイト列を固定する。署名などは発行と実体を結ぶ。YANG Libraryは展開先を示す。採否記録は、運用者が何を根拠に依存したかを示す。

安定したSIDにも、廃止後の責任がある

RFC 9595はSID対応をunstable、stable、obsoleteの状態で扱う。開発中の不安定な割当は変わり得る。安定後は継続性が重くなる。廃止された値は記録に残し、別のスキーマ項目へ再利用しない。

これは、古い整数が新しい意味で復活するのを防ぐ重要な規律だ。しかし履歴を失えば、規律も観測できない。最新のSIDファイルだけでは、過去のデータが参照した安定版を説明できないことがある。逆に、公式な旧版でも現在のサーバーには適さない。

つまり真正性と適合時点は別々に保存しなければならない。公式配布だから現在も有効とは限らず、最新版を名乗るから公式とも限らない。ダイジェスト、状態、時刻、対象用途を一つの採用判断に結び付ける必要がある。

整数へ圧縮された意味は、表示上の手掛かりが少ない。長いスキーマ名なら人が違和感を持つ場面でも、数値の誤対応は双方の機械が同じ表を共有する限り静かに通る。構文的成功を意味的正しさと取り違えやすい。

八面の出所バインディング記録

解決策として、機器設定、私有モデル本文、通信内容を中央へ集める必要はない。守るべきなのは、判断に必要な最小の結合関係である。Daniel Kadeは八面からなる、改ざん検出可能な出所バインディング記録を提案する。

第一面は、判定に使ったIANA登録簿のスナップショットまたは版。第二面はPEN、適用条件、範囲の計算結果。この二つは番号上の所属だけを証明し、出所とは明示的に切り離す。

第三面は、公式と認めたリポジトリまたは配布ルートと、その認定根拠。第四面はモジュール名、名前空間、改訂、暗号学的ダイジェスト。第五面は.sidファイルのダイジェスト、割当状態、安定化や廃止の履歴である。

第六面には、署名または完全性検証の方式、照合した信頼済み主体、時刻、結果を残す。第七面は、サーバー範囲、モジュール集合、機能、偏差、スキーマ、データストア、content-idを含むYANG Library観測。第八面は、受入れ、拒否、置換、廃止の結果と理由、責任者、適用範囲だ。

八面を分けることで、IANAがリポジトリまで保証したことにも、サーバーの自己申告が過去の供給元を証明したことにもならない。復号成功から発行権を逆算することも防げる。不明な面は不明なまま示し、後の調査対象にできる。

これはDaniel Kadeの編集上の提案であり、RFC 9997、RFC 9595、RFC 8525の規定項目ではない。設定ペイロード、認証情報、私有モデル本文、機器の秘密、無関係な行動は保存しない。目的は、便利な割当の近道を、見えない認証の近道へ変えないことである。

BTW Mediaが存在する理由の要点は、期待する物語より観測可能な現実を優先することにある。観測できるのは範囲、バイト列、検証結果、展開状態、判断である。「その企業が作った」という物語には、それ専用の証拠が要る。

出典