要約

  • RFC 3983 では IRIS プロファイルが受理され BEEP チャネルが作られると ready になったが、それは広告された型のメッセージを交換できるという能力であり、身元や権限の判定ではなかった。
  • サーバー認証は型ごとの方式、基本 TLS 方式、または明示的な「認証なし」を選べた。暗号化、利用者認証、検索の認可、参照先への信頼は別々に確認する必要があった。

TLS が証明書を暗号学的に正しいと判定した。その次に、クライアントは証明書の名前が本当に要求した authority と一致するかを調べる。前者が成功しても後者は失敗し得る。RFC 3983 が二つを別の段階にしたのは、証明書の真正性と相手先の同一性が同じ命題ではないからである。

RFC Editor のステータス、エラッタ、Datatracker の履歴は、2005年1月の Standards Track 文書としての状態を記録する。仕様は Internet Registry Information Service を Blocks Extensible Exchange Protocol、BEEP に写像した。この記録から配備数や現在の可用性を読むことはできない。

BEEP を選んだ理由は、フレーミング、認証、接続管理、交渉を備えた既存の仕組みと実装用ツールを再利用できることだった。IRIS 専用の簡素なトランスポートでも、結局は同種の機能を作る必要がある。HTTP は Web アプリケーションとの混同や TLS 利用のばらつきを招き、直接 TCP は異なるパラメーターのサーバーを参照で渡り歩くための交渉能力が足りない、と文書は判断した。これは設計理由であり、性能実測ではない。

BEEP プロファイル URI は IRIS スキーマ版とレジストリ型 URN を組み合わせた。チャネル作成時には複数の profile を提示でき、型ごとに使う版を交渉できた。プロファイルが受理されチャネルが作られると、チャネルは IRIS メッセージ交換の準備ができたとみなされた。サーバーは広告したすべてのレジストリ型のクエリを、その IRIS チャネルで扱わなければならない。

しかし「扱う」は「データを与える」ではない。既定のパターンでは、クライアントが有効な IRIS XML を BEEP MSG で送り、サーバーが RPY で IRIS XML を返す。BEEP レベルの障害には ERR を使う。型は別の BEEP 互換パターンを定義できるが、lookupEntity には既定方式を用意する。IRIS 中核とそのステータスは、未対応や権限拒否などレジストリ層の結果を別に持つ。ready は会話の入口で、結論ではない。

サーバー身元には追加の規約が必要だった。BEEP の TLS tuning profile を用いる場合、レジストリ型は独自のサーバー認証方式を定めることが望ましい。なければ基本方式を使う。クライアントは IRIS URI で求めた authority を BEEP serverName に入れる。サーバーはその authority を含む X.509 証明書を提示する。TLS の手順で証明書を検証した後、クライアントは dNSName、指定された subjectDN の順に authority 名を照合する。

型を定義する文書には、メッセージ・パターンとサーバー認証方式の明記が必須だった。認証方式については独自方式、基本方式、サーバー認証を一切使わないという宣言のいずれかを選べる。したがって、正しく交渉されたプロファイルと ready なチャネルがあっても、サーバー認証が行われたとは限らない。

利用者認証はさらに独立していた。RFC 3983 は、セッション暗号化なしに利用者を認証する SASL DIGEST-MD5 と OTP を挙げる。一方、TLS の暗号化だけの利用と、クライアント証明書によって利用者認証も加える利用を区別する。匿名アクセスは認証 tuning profile を使わない場合と SASL ANONYMOUS を使う場合がある。暗号化、サーバー認証、利用者認証、データ認可は一列の進捗段階ではなかった。

この分解は BEEP の構造に由来する。RFC 3080とステータス、エラッタ、Datatrackerは profile、channel、message、tuning を定めた。RFC 3081とそのステータスは BEEP を TCP に載せた。tuning で一つの安全属性を変えても、他の属性が自動的に成立するわけではない。

当時の周辺文書も境界を示す。RFC 2246とステータスは TLS 1.0 を、RFC 2222とステータスは参照された SASL を定義した。RFC 2817とステータス、RFC 2818とステータスは RFC 3983 が論じた HTTP/TLS の方式を記録する。機構の存在は、個々のセッションでの適用証拠ではない。

参照は認証情報の扱いを難しくした。IRIS では別サーバーへの移動が通常の動作だった。RFC 3983 は、信頼できない参照先へ認証情報を渡さないよう求め、SASL PLAIN を使わないことを勧め、TCP セッションを暗号化する前の PLAIN を禁止した。暗号化は途中で秘密が読まれるのを防ぐが、受取人を信頼できる相手に変えるものではない。

後の RFC 4992とステータス記録は XPC over TCP を追加し、IRIS 中核を更新した。これはトランスポートを交換できた事実を示すが、採用や移行の理由までは示さない。

現在の IANA URI Schemes レジストリには iris.beep が、IANA BEEP Parameters レジストリにはプロファイルと tuning の名前空間が残る。登録は、稼働チャネル、証明書照合、利用者身元、認可結果の証明ではない。

RFC 3983 の歴史的な価値は、ready を小さな事実のままにしたことにある。メッセージ交換の準備完了を、接続先への信頼やデータ取得権へ膨らませなかった。運用側がそれらを一つの状態に畳み込めば、障害時に必要な証拠を自ら捨てることになる。

Sources