要約

  • RFC 1805は、ファイルの内容ハッシュと日付を信頼する第三者の署名付き証明書に収め、元の置き場所から独立して照合する方式を示した。
  • 作者の本人確認手段はプロトコルで固定せず、証明書に記載する。BellcoreのBetsiでは電話案内で番号を調べ、折り返し電話で登録内容を確かめた。

ファイルは複製されるたびに住所を変えられる。しかし「誰が作ったか」という問いはコピー操作だけでは片付かない。Aviel Rubinが1995年6月のRFC 1805で描いたのは、作者、利用者、信頼する第三者による確認の仕組みだった。ファイルが不確かな配布先を経由しても、内容と日付を別の証明書で確かめる。ここまではいかにもネットワークらしい。ところがBellcoreの実装例Betsiで作者の身元を確かめる場面には、電話案内と折り返し電話が出てくる。

この一見古風な手順には理由がある。Rubinは検証プログラムそのものが攻撃される危険から話を始めた。改変されたファイルを、同じく改変された検証器が「無事」と判定しても安心できない。そこで提案はASCIIメッセージと広く使われる署名方式を土台に置き、利用者が自分で検証器を作るか、信頼できるものを独立に入手できるようにした。一つの配布業者のソフトウェアに最終判断を預ける設計ではなかった。

手順は作者登録、作者確認、ファイル認証、配布、受領側の完全性確認という五段階。作者確認だけは方法を定義し切らず、どの方法を使ったか後の証明書で明示する。署名は鍵とメッセージを結び付けるが、その鍵と実在の作者を結び付ける作業は別に必要だからだ。RFCに記されたBetsiでは、作者の都市で電話案内を利用して番号を得て、そこへ電話をかけ、登録内容や公開鍵を確認した。これは米国内で動いた実装例の方法であり、方式全体を電話専用にする規則ではない。

登録済みの作者はファイルの暗号学的ハッシュを計算し、署名した認証依頼を第三者へ送る。第三者は依頼を確認し、ハッシュ、使用した関数、日付、作者名、本人確認方法を入れた証明書に署名する。依頼に書くファイルの場所は任意項目だった。これが題名の「場所に依存しない」という意味を支える。保証の対象は特定のFTPディレクトリではなく、手元のバイト列と証明書の関係である。作者はファイルと証明書を一緒に、信頼していない経路からでも配れる。

受け取った側は、まず第三者の公開鍵を複数の独立した手掛かりから確かめる。その鍵で証明書の署名を検証し、記載された作者確認方法を受け入れるか判断する。さらに実際のファイルをハッシュ化して証明書の値と比較し、必要なら日付も確認する。最後に、その第三者が公開する現在の完全な署名付き失効リストを調べる。封印だけ見て失効を忘れるなら、期限切れの通行証を額装して使うようなものだ。

一連の照合が支えるのは、ある条件の下で受け取ったバイトが証明されたバイトと一致し、指定された時点の存在が示されるという判断だ。実行する価値や安全性まで自動採点する証明書ではない。電話はこの設計の弱点を笑うための小道具ではなく、持ち運べる内容の証拠と、場所に根を持つ本人確認の接点を見せている。