要約

  • RFC 9519 は複数の SSH パラメータ範囲を IETF Review から Expert Review に変更し、Standards Action と Private Use の境界は維持した。
  • IANA の割当てが確定するのは名前または値であり、製品への実装、二者間の交渉、運用上の有効化、現在の安全性ではない。
  • 申請と専門家判断の記録を、コミット、リリース、交渉ログ、相互運用、配備、廃止の記録から分離して追跡すべきである。

新しい SSH の値が IANA 表に載った日を「採用日」と呼ぶと、証拠の時計を早く回しすぎる。そこで確定したのは、世界で再利用できる名前と参照先である。実装者がコードを書いた日、二つの製品が同じ意味で交渉できた日、運用者が本番で有効にした日は、いずれも別の日付を持つ。

RFC 9519 が短縮した工程

RFC 9519 は RFC 4250、RFC 4716、RFC 4819、RFC 8308 に定められた複数の SSH 登録方針を更新した。通常の範囲は IETF Review から Expert Review に移る。一方、Standards Action が必要な限定範囲と Private Use の領域は残る。

この差は単なる厳格さの段階ではない。IETF Review は通常、IETF の合意を通った IETF-stream RFC を要求する。Expert Review は、指定専門家が公開文書と個別レジストリの基準を用いて割当てを判断する。RFC 8126 は、専門家の任命・交代、利益相反時の回避、追加知見の導入、拒否理由の説明、異議申立てという責任経路を示している。

現在の IANA SSH Parameters には、Expert Review の対象、担当専門家、申請先、RFC 9519 への参照が明記される。メッセージ番号など Standards Action の範囲も同じ表に残る。したがって表は値の一覧であると同時に、変更の決定権を可視化したものでもある。

交渉は登録表を読んで成立するのではない

RFC 4253 のアルゴリズム交渉では、クライアントとサーバーが提示する順序付きリストの共通項から選択が行われる。登録済みの名前が片方の実装に存在しなければ選ばれない。双方が提示しても、同じ処理を実装したか、ローカルポリシーが許可するか、障害時の振る舞いが安全かは別途検証が必要だ。

RFC 8308 が鍵交換後の拡張通知を設けたのも、相手が何をサポートすると主張するかを実通信で知る必要があるためである。その主張の後には、テストベクトル、異なるコードベース間の相互運用、設定初期値、本番テレメトリが続く。RFC 9142 は、登録済み方式が後に非推奨となり得ることを示す。診断のため名称を残すことと、採用を推奨することは同義ではない。

専門家審査にも実装にも、それぞれ領収書が要る

審査側では、対象レジストリと範囲、申請者、識別子、変更管理者、根拠文書、提出時刻、公開議論、担当専門家、利益相反と回避、質問、修正、判断理由、承認時刻、IANA 反映時刻を残す。実装側では、コミット、リリース、役割、テスト、交渉キャプチャ、フォールバック、既定設定、ポリシー制御、相互運用相手、有効化、障害、保守者、廃止計画を残す。

この二つを混ぜると、登録を認証のように宣伝する側にも、配備証拠がないという理由で割当て制度を無価値とみなす側にも都合がよい。審査制度は衝突回避、一貫した基準、判断の説明可能性で評価する。機能はコードと運用結果で評価する。それが最小の混同防止策である。

時間軸にも注意が要る。申請書は予定する意味を説明でき、専門家はその説明が登録に十分かを判断できる。しかし最初の実装が全ての役割を支えるとは限らない。クライアントだけの対応、実験フラグの背後にある機能、異なる失敗時既定値は、同じ登録名の下で並存し得る。「実装あり」を採用の証拠にするには、対象役割、版、既定状態、試験相手、保守方針まで結び付けなければならない。

審査の健全性も承認件数だけでは測れない。公開リストの外で修正が続けば重要な論点が見えず、承認から IANA 反映まで長ければ割当て済みという認識と公開状態がずれる。却下や撤回は失敗ではなく、曖昧な意味を恒久的な名前に固定しなかった成果かもしれない。総申請数、待ち時間、修正、回避、撤回、却下、実際の更新を同じ分母で示す必要がある。

どの範囲に割り当てるかも証拠の一部である。隣接する範囲が Expert Review になっても、Standards Action として残された希少または敏感な値の門が軽くなるわけではない。Private Use は閉じた環境での試行に便利だが、別組織が同じ値に異なる意味を与え得る。長く使った私的値が自動的に公共の優先権を得ることもない。申請記録には、対象範囲、適用方針の理由、代替拡張方式の有無を明記すべきだ。

変更管理者も永続性を左右する。最初の申請者が離れ、参照文書や実装が保守されなくなっても、登録名は外部依存として残る。誰が意味を説明し、状態変更を通知し、参照先を更新できるかが不明なら、恒久的な識別子が一時的な約束を固定してしまう。連絡先と文書の定期確認は再審査ではなく、登録項目を解釈可能に保つ保守である。

検証可能な一次資料として、RFC Editor は情報ページ、テキスト、XML、正誤情報検索を公開し、Datatracker はRFC の履歴と最終ドラフトを保持する。これらは方針決定を再構成できるが、後続実装の代わりにはならない。

分析上の手掛かりは、running code の優位、最小初期仕様と自発的採用、現実の層と象徴的権力を論じた三つの文章にある。制度を否定するためではなく、制度上の事実が運用上の事実を代行しないよう境界を引くために使える。