要約

  • Phでは、格納されているフィールド、存在を発見できるフィールド、検索に使えるフィールド、既定で返るフィールドは同じ集合ではなかった。
  • TurnやLocalPubなどの属性は、本人の選択、接続元の分類、運用者の権限、変更経路を独立に扱った。
  • 空の応答が証明するのは、そのセッションがその時点で値を受け取らなかったことだけであり、非存在ではない。

自宅電話番号の先頭にアスタリスクを一つ置く。それだけで、一般利用者から番号が見えなくなる。だがデータは削除されない。本人と特権運用者には引き続き見える。

この仕組みは、1998年9月のRFC 2378が記述したCCSO Nameserver、通称Phにある。Phは、人物や物に関する小さな情報を多数のエントリとして保持し、TCPポート105上の簡潔なコマンドで検索するサービスだった。見かけはネットワーク対応の電話帳である。しかし、歴史的に興味深いのは、各フィールドに付けられた記述子のほうだ。

フィールド記述子には名前、最大長、説明文と複数の性質が入る。Publicは閲覧主体を、Lookupは選択条件への利用可否を定めた。Indexedは索引対象を示し、クエリには少なくとも一つの索引フィールドが必要だった。Defaultは返却項目を指定しない場合の出力を、Alwaysは強制出力を決めた。Changeは本人による変更、Uniqueは重複拒否、NoMetaはワイルドカード禁止、Encryptは送信時の扱いを担った。

これは公開度を一本の物差しに並べたものではない。閲覧できても検索キーにはできない。検索に使えても既定の応答には現れない。本人が読めても本人には書き換えられない。各属性は別の問いへの答えだった。

アスタリスクは表示上のゴミではない

Turn属性が付いたフィールドでは、本人が内容の先頭に*を付けると、本人とHeros以外への表示を止められた。HerosはPhにおける特権運用者である。RFCの例ではhome_phoneにLookup Public Change Turnが並ぶ。通常は公開され、検索でき、本人が更新できるが、本人自身が公開を止める余地も残されていた。

したがって移行処理がアスタリスクを「不要文字」として先に除去すれば、データ整形ではなく権利変更になる。また、通常の応答に番号がなかったとしても、保存領域から消えたとは限らない。

ForcePubは逆向きの作用を持つ。エントリ全体のsuppressフィールドの内容にかかわらず、対象フィールドを閲覧・検索可能にした。レコード単位の抑制とフィールド単位の公開は、単純な上下関係ではなかった。

この設計が示すのは、値、記述子、レコード状態、観察者という複数の入力から可視性が決まるという事実である。応答だけを保存し、その決定過程を捨てれば、後から意味を再現できない。

外部からは列そのものが消える

LocalPubは、ローカルと判定されたドメインまたはアドレス空間内の利用者にはフィールドを公開し、外部では完全に不可視にした。値を隠すだけではない。外部セッションのfieldsコマンドには記述子が現れず、クエリ条件にもreturn句にも指定できなかった。

つまり内側と外側では、検索前からスキーマが違う。外部利用者は、存在を知らされていない列について質問することさえできない。

セッションのexternalオプションもLocalPubを不可視にした。ただしRFCは「ローカル」を世界共通の暗号学的事実として定義していない。サーバ環境が分類し、プロトコルがその結果を適用する。接続元アドレス、ホスト名、組織所属、認可は、それぞれ別の証拠である。

Phがローカルだったのは別の意味でもある。サーバ間の自動参照は想定されず、別のnameserver一覧を提示してクライアントに追加照会させるにとどまった。一台のサーバで見つからないことは、全体に存在しないことを示さない。

ネットワークから変更不能でも、不変ではない

Sacredフィールドはネットワーク経由で変更できない一方、サーバ上の端末、ファイル、パイプからは変更できた。守られているのは値の永続性ではなく、変更経路である。

Herosの権限にも幅があった。完全なHeroは全フィールドを閲覧・変更できるが、ACLによって別エントリの一フィールドだけを扱う権限も委任できた。「管理者が実行した」という記録だけでは、権限範囲を説明できない。

セキュリティ節も同じ慎重さを持つ。Phは平文パスワードや弱いメール方式からKerberos、GSS-APIまで複数の認証を扱った。相互認証がなければサーバの身元を証明できず、そのサーバが情報集合について権威を持つことも証明できない。別途通信路を保護しなければ、トラフィックは観測・改変され得た。

利用者認証、サーバ認証、通信路保護、フィールド認可、データ権威性は別の領収書である。一つを得ても、残りを自動的に得たことにはならない。

allは「見えるもの全部」だった

return allが返すのは、そのセッションから閲覧可能な全フィールドであり、保存された全フィールドではない。索引済みであることは公開を意味せず、公開であることは変更権を意味しない。

応答の根拠を残すなら、保存レコード、フィールド記述子、抑制マーカー、ローカル判定、セッションID、認証方式、HeroとACLの範囲、検索条件、返却指定、接続先、通信路状態、観測時刻を分離して記録する必要がある。

RFC 2378は弱い認証も記述し、通信暗号を自力で交渉しない。現代の完成形ではない。それでも、ディレクトリが観察者ごとに構成されることを隠さなかった。「見えない」を「ない」に昇格させない姿勢は、現在のAPIにも必要である。