要約

  • RFC 1505は、メール本文の各部分について、行数と順序付きの変換語を任意のEncodingヘッダーで記述した。構文どおりに復号できることは、送信者の認証や次の動作の許可とは別だった。
  • LZJU90の元バイト数とCRCは破損や誤復号を検出する手掛かりになったが、誰が送ったか、復元物が安全か、実行してよいかは証明しなかった。
  • SHAR、所有者、ACL、平文パスワード、アプリケーション名を受け取れても、命令の実行や権限の割り当ては受信側の管理領域が決める必要があった。

二つの一致が証明した範囲

RFC 1505のEncodingヘッダーには、本文のある部分が何行で構成されるかを十進数で書けた。一方、LZJU90という方式は、復元後の元バイト数とCRCを末尾に持っていた。受信側は、まず符号化されたテキストの行を数え、次に圧縮を解き、最後にバイト数とCRCを確かめられた。

この二つの一致は価値がある。途中で行が落ちた、ゲートウェイで文字が変わった、誤った変換を適用した、といった問題を切り分けられる。単に「開けた」と報告するより、どの段階で何を検証したかが明確になる。

ただし、対象も単位も異なる。ヘッダーの数値は符号化済み本文の行を数え、LZJU90の末尾は復号後のバイト数とCRCを扱う。どちらも一致したという事実を一つの緑色ランプにまとめれば、伝送の完全性が送信者の信頼性に見え、さらに実行許可にまで見えてしまう。

CRCは秘密鍵を使った署名ではない。送信者を認証せず、ACLの妥当性を保証せず、復元された命令が安全だとも言わない。証明できるのは、定義された計算について受信結果が付随値と対応したという狭い事実である。

ヘッダーは変換の順路を示した

RFC 822は、空行を境にメールをヘッダーと本文へ分けていた。RFC 1505は、その枠組みを大きく崩さず、本文の複数部分とその表現を一つの任意ヘッダーで説明しようとした。本文中の各所に新しい制御構造を置けば、古いメール閲覧ソフトにその文字列がそのまま見えてしまうからだった。

各サブフィールドは、本文に現れる順で一つの部分に対応した。そこには行数と、一つ以上のキーワードを並べられた。部分間の区切りはCRLFだけからなる空行で、前後どちらの行数にも含めない。最後の部分、または一つしかない部分では、行数を省略できた。

変換が入れ子になれば、語順が処理順になる。デコーダーは左から右へ読み、エンコーダーは実際に施した変換と逆順に語を並べる。たとえばuuencode LZW tarは、三つの機能が使えるという一覧ではなく、元の内容へ戻るための特定の道筋を表した。

括弧内のコメントは閲覧ソフトへ渡してもよいが、内容の解釈に使ってはならなかった。同じヘッダーの中でも、説明用の文字と機械が従う語を分離していたのである。

ここで得られるのは表現の地図だ。地図を正しく読めたことと、その終点で見つかったものを作動させる権限は一致しない。

SHARを理解しても、シェルを起動してはならない

その境界を最もはっきり示すのがSHARだった。SHARはシェルアーカイブを表し、ファイルを再構成する命令を含み得た。RFC 1505はこの形式を扱ったが、利用を推奨しなかった。受信者が望まない命令が入る可能性があるため、デコーダーは復号したシェル文を自動実行してはならないと警告した。将来、受信機向けの命令を含む型が追加された場合にも同じ警告が及んだ。

この一文は、処理を少なくとも六つの証拠へ分ける。キーワードを認識したこと、符号化を解いたこと、命令を表示したこと、権限ある人または方針が実行を承認したこと、実際にプロセスを起動したこと、そして結果として何が変わったかである。

行数とCRCが合うのは第二段階までの強い手掛かりになり得る。しかし第四段階を埋めない。復元された命令が元どおりであるほど、それを無断で実行した場合の効果も忠実に再現されるかもしれない。伝送の正確さは、安全性の代用品ではない。

RFC 1505は、SHARを使った具体的な攻撃事件を記録していない。特定製品が警告を守ったとも証明しない。ここで確認できるのは仕様上の設計判断である。複雑な本文を自動的に復号する提案そのものが、復号と実行の間に受信側の判断を必要としていた。

ファイル属性は別の管理領域から来た

FS方式は、ディレクトリ、エントリー、ファイル、セグメント、データを階層的に表現した。Unix、DOS、VMS、Primos、Macintoshなど、異なるファイル体系をまたぐことを想定し、表示名、コメント、型、作成・変更・アクセス時刻、所有者、グループ、ACL、パスワード、ブロック長、レコード長、関連アプリケーションまで運べた。

多くの属性を保存できることは、同じ意味で適用できることを保証しない。送信元のユーザー番号が受信先では別人を指すことがある。グループ名が存在しないことも、同じ名前で権限の異なるグループがあることもある。関連アプリケーションの名前が別のプログラムへ解決されれば、単純な復元が新しい動作を生む。

ACLは、追加、削除、一覧、保護変更、読み取り、利用、書き込み、実行、全権限などを文字で表した。$OWNER、$GROUP、$SYSTEM、$RESTという予約された役割もあった。これらは異なる保護モデルを記述する共通語彙であり、世界共通のアカウントではない。

$SYSTEMを受信側の管理者へ割り当てるのか、無視するのか、隔離用の主体へ置き換えるのか。それぞれ結果が違う。原文をそのままコピーする処理であっても、ローカルな対応付けを選んだ時点で権限判断を行っている。

時刻にも変換損失があった。送信元の精度が受信先より高ければ、余分な精度を無視するようRFC 1505は述べた。受信値、表現可能な値、実際に保存した値を分けなければ、「属性を保存した」という表示の裏で情報が消える。

平文パスワードは責任の所在を露出させた

FSのpassword属性は、要素へのアクセス用パスワードを平文で伝えられた。RFC 1505は、保護対象の内容自体が同じ符号化の後ろに続くため、平文で書くことが必ずしも追加の情報漏えいにはならないと考えた。

しかし、その文字列を受信側で本当にパスワードとして設定する安全性は、デコーダーを制御するアプリケーション領域の責任だと明記した。ACLや他の保護属性も同じである。

受信した値がpasswordと名付けられていることは、ローカルな秘密として採用する理由にならない。既存の保護を上書きする許可でも、二つの利用者が同一人物だという証明でもない。保存するなら、元の値、適用先、変換規則、承認者、結果を別々に残す必要がある。

完全な複製という言葉にも注意が要る。意味の違う環境へ保護機構をそのまま移すことは、忠実な復元ではなく、新しい権限の付与になり得る。

Signatureは普通の署名欄でもあった

RFC 1505のSignatureは、メールやUsenet記事の末尾に置かれる通常の署名領域を意味した。送信者名や好みの言葉など、自動付加されるテキストを含み得た。Text Signatureは暗号検証の結果ではなく、表示上の部分の種類だった。

PEM、PEM-Clear、PGPは別のキーワードとして扱われ、暗号化、完全性検査、鍵ブロック、分離署名など、それぞれの内部形式を持った。それでも、外側の語だけで検証は完了しない。どのバイトが対象か、計算が成功したか、鍵はどこから来たか、名乗られた人物を受信側が信頼するかを確認する必要がある。

PGPの後ろに入れ子の型を置くと、内容がテキストかEDI取引かを通信観察者に推測させる場合がある、と文書は注意した。暗号化が成功しても、文脈情報がすべて消えるわけではない。

通常の結び文、暗号オブジェクト、数学的な検証、信頼された人物という四つの状態を「署名済み」の一語で表せば、インターフェースが証拠の段差を消してしまう。

登録語は安全認定ではなかった

X-で始まらないキーワードはIANAへ登録し、X-は実装固有の用途に残すという仕組みもあった。登録は、共有できる名称と説明への経路をつくる。別々の方式が同じ語を奪い合う危険を減らす。

しかし登録は、特定のデコーダーがその語を実装している証明ではない。正しく実装している、安全に使える、既定で有効にすべきだという認定でもない。登録語を知っている受信機が、対応機能を持たないことも、方針により無効化することも、内容だけ隔離して提示することもできる。

語彙を調整する機関と、ローカルな機能を有効にする管理者を同一視すれば、名前の登録が遠隔から能力を起動する仕組みに変わる。RFC 1505の構造から読み取るべきなのは、その二者を結ぶことではなく分けることである。

MIMEと並んでいた実験

RFC 1505は1993年8月にExperimentalとして公開され、RFC 1154を廃止した。インターネット標準を定めた文書ではない。IESGの注記は、同じ領域に標準化過程の技術がすでに存在するとし、RFC 1341のMIMEを示した。

両者は、複雑なメール本文を扱う同時代の異なる設計として比較できる。RFC 1505はトップレベルのヘッダーに順序付きの説明を集めた。MIMEは各部分へ明示的なヘッダーを置き、境界文字列で分けた。MIME側にも能動的な内容や資源消費への警告があった。

後のRFC 2045は、RFC 1521、RFC 1522、RFC 1590を経たMIMEの系譜を改訂した。だからといって、RFC 1505がMIMEの前身だった、MIMEがRFC 1505を正式に廃止した、と結論することはできない。仕様の細かさだけから普及率や製品実装も推定できない。

残るのは勝敗表より有用な歴史である。メールが単純な文字列を越え、アーカイブ、属性、暗号表現、命令まで運ぼうとしたとき、伝送の検査とローカルな支配権は同じものにならなかった。

史料が示すこと、示さないこと

一次資料は、ヘッダーの構文、行数、順序付きキーワード、FS属性、SHARへの警告、LZJU90の検査、Experimentalという位置付け、MIMEに関するIESG注記を裏付ける。これらから、表現、完全性、認証、許可、効果を分ける設計上の教訓を引き出せる。

一方、全キーワードを実装した特定製品、運用上の普及、悪意あるSHAR事件、ACLを安全に移せた事例は示されていない。CRCが送信者を認証したとも、Signatureが暗号署名だったとも、IANA登録が実行を許可したとも言えない。

実験文書に詳細な構文があることは、稼働するコードが広く存在した証拠ではない。受信側で何が起きたかを主張するには、仕様ではなく、実装、方針、承認、実行結果の記録が必要になる。

参照資料