要約
- RFC 1036はモデレートされたニュースグループへの投稿に
Approved:を必須とし、モデレーターが自分のメールアドレスを加えるよう定めた。 - それは記事を通すための信号であり、暗号学的な資格情報ではない。後の歴史的草案は、申告された承認を認証できなかったと明記した。
判断を記事と一緒に運ぶ
Usenetでは、中央の一台が最終稿を受け取り、全体を代表して承認するわけではなかった。記事はニュースグループごとに選択的に交換するサイトを渡り、それぞれに複製が保存された。モデレーションの規則をその経路で機能させるには、記事にソフトウェアが読める状態表示が必要だった。通常の配送に進めるのか、それともまだ審査に回すのかを区別するためである。
1987年12月に公開されたRFC 1036は、その表示に Approved という短い名前を付けた。一般には任意のヘッダー一覧に置かれているが、モデレートグループ宛ての記事では必須となる。モデレーターが付け、自分のメールアドレスを内容にすることが望ましいとされた。アドレスは実際の連絡先となり、ソフトウェアにも認識できた。一方、受信側がそのアドレスと正規のモデレーターを照合する署名や鍵、信頼できる名簿は規定されていない。
ここには二つの事柄がある。人が判断したという前提と、その判断があったと記事が宣言していることだ。ヘッダーは審査そのものを示さず、何を基準にしたかも、誰が判断したかも証明しない。Approved は状態を示し、アドレスは連絡先を示す。どちらも認証された承認の受領証ではなかった。
同じ表示がグループ制御メッセージにも付いた
RFC 1036の例は具体的だ。1986年10月1日付の読者数報告が news.lists と news.groups にクロスポストされ、モデレーターのアドレスを示す Approved フィールド を含んでいる。Xref は seismo ホスト上のローカル記事番号も記す。これはアドレス形式の承認表示が通常の記事とともに流通した例だが、利用頻度や各サイトの検証方法までは示していない。
さらに大きな影響を持つ場面でも同じヘッダーが使われた。RFC 1036はグループ作成を依頼する newgroup 制御メッセージを定義し、モデレート対象として作る指定も認めた。ヘッダーに Approved がなければ、そのメッセージを無視するようサイトに求めている。グループを全ホストから削除する rmgroup も同じ条件を持つ。文書はネットワーク全体に及ぶ削除のため慎重さを促した。ここでもフィールドは、承認済みだという主張を通常の指示と区別するが、権限そのものは認証しない。
この再利用は、分散型プロトコルの緊張を示す。決定をどのサイトからも読めるようにはできるが、決定の出所を自動的に検証できるとは限らない。各サイトはフィールドの有無を調べられる。しかし、その値だけでは、メールボックスが正式なモデレーターや管理者のものだと証明できない。標準は共通の確認点を用意し、信頼は各地の運用関係に委ねた。
後の草案は信頼の欠落を言葉にした
「Son of 1036」の時系列には注意がいる。RFC 1849は2010年3月、歴史文書として公開された。著者によれば、元の草案は1990年代初めに広く流通し、ニュースソフト実装者にとって事実上の参照になった。文書自身も、歴史的背景を保存するもので、現在の実装指針ではないと説明する。
この文書はソフトウェアの役割を明確に分けた。投稿エージェントはローカル利用者の投稿を整え、適合性を確認し、配送へ渡す。リレーは他のリレーから完成した記事を受け取り、複製を転送する。モデレートグループで Approved がない記事は、読者の投稿として投稿エージェントからモデレーターへ送られる。リレーがそれをモデレーター宛てメールに変えてはならず、未承認記事として破棄するべきだ。同じプログラムが両方の機能を持つことはあっても、責任は別である。
その歴史文書は限界を直接記す。Approved に書かれた承認が実際に与えられたか確かめる認証方法はなく、正規の承認者一覧を最新の状態に保つ仕組みもなかった。暗号学的認証は有望な拡張として挙げられたが、多くのニュースシステムが鍵サーバーへリアルタイム接続できないため簡単ではないとも指摘された。これは設計上の欠落を示す記録であり、具体的な偽造事件や全サイトの受け入れを証明するものではない。
後のRFC 5537は注入経路を形式化した。未承認記事は Newsgroups にある最初のモデレート対象グループのモデレーターへ、通常はメールで転送する。承認と注入を通常のリレー処理から切り分ける。後年の標準は役割分担を明示するが、1980年代の全てのシステムが同じだったとまでは言えない。
このヘッダーが可能にしたこと、残したこと
Approved: は暗号学的証明を持たないからといって無意味ではなかった。離れた場所のニュースソフトに共通の処理条件を与え、モデレーターへの現実的な連絡先も運んだ。編集上の判断を分散した出版網で共有できた。しかし、その可搬性はフィールドを支える信頼関係の境界で止まる。
ネットワークは承認の申告を運べるが、文字列だけでその背後の権限を判断できない。人による審査、アドレス管理、ローカル方針、ソフトウェア処理は別の要素として残った。標準は判断を書き留める場所を作ったが、誰が判断したかを普遍的に証明する仕組みは作らなかった。
出典
会員向け解説
プロフィールの詳細
適切な会員レベルでログインすると、解説全文と出典メモをご覧いただけます。
Strategic Circle 限定
Strategic Circle
すべての読者に公開されています。参加してログインすると プロフィール解説 を閲覧できます。
Strategic Circle に参加Leadership Alliance 会員限定
Leadership Alliance
対象となる IP 資産の所有者・管理者向けです。ログインすると Leadership Alliance の解説を閲覧できます。
Leadership Alliance に参加
