要約

  • RFC 1421 は PEM の処理を利用者側の端点に置き、途中の SMTP 中継には暗号機能を要求しなかった。保護対象は封入された本文であり、配送中に付け加えられる外側のフィールドや経路全体ではない。
  • MIC-CLEAR は MIC-ONLY と同じ認証・完全性サービスを選びながら、転送時の書き換えから本文を守る印字可能符号化を省いた。PEM を持たない受信者も文章を読めたが、署名は検証できなかった。
  • MIC は ASCII と CRLF から成る正規形に対して計算された。改行変換や転送用エスケープでも不一致は起こり得るため、検証失敗、変化の原因、セキュリティ事象という三つの判断を一つにしてはならない。

初期の安全な電子メールが直面した難問は、強い暗号を選ぶことだけではなかった。すでに動いている配送網のうち、どこまでなら何も知らないままでもよいのか。その線を引くほうが、普及を左右した。

1993年のメールは単一のプログラムではない。利用者の端末で作られ、複数の Message Transfer Agent に引き渡され、ときには異種ネットワークのゲートウェイを通った。各ホストは文字や行末を同じように保存するとは限らない。転送者は元の本文を別のメッセージ内に包むこともあった。この全員に新しい保護形式の理解を求めれば、最初の利用者は永遠に待たされる。

RFC 1421 は Privacy Enhanced Mail の処理を User Agent か、それより上の層に限定した。送信側で本文を変換してから通常のメールとして渡し、受信側で配達後に逆変換と検証を行う。途中の SMTP サーバーは PEM を理解しなくてよい。経路上の組織すべてが同時に設備更新することを、導入条件から外したのである。

ただし、その選択は保護範囲を狭く保った。二つの PEM 処理点の間で中継が追加・変換するフィールドには、プライバシー拡張が及ばない。外側の宛先、配送経路、追跡フィールドまでが、内側の MIC に近いというだけで認証されるわけではない。

一通のメールには、少なくとも配送、外側の表示、封入オブジェクト、検証、人間の行動という別々の履歴がある。ひとつの「安全」表示に畳み込めば、どの履歴が確かで、どれが未知なのかを失う。

中継を変えないという導入戦略

RFC 1421 の現実主義は、メールサーバーへ安全機能を組み込むより、端点の能力を増やすことにあった。通常の無保護メールを技術的に禁止しようともしていない。信頼できる利用者エージェントが普遍的に存在する、という前提も置かなかった。

その結果、中継運用者は既存の手順を維持できた。導入する組織は自分の端点だけで試せた。一方、送信者には新しい仕事が残った。受信者が選択した符号化や暗号化を元に戻せるか、事前に知る必要がある。鍵管理と処理方式の合意も、SMTP の配送受付とは別に用意しなければならない。

アドレスが存在し、RCPT TO が受理されたとしても、そこから PEM 能力は証明できない。ある配送ノードが次の責任を引き受けたことと、最終端点が復号・検証できることは異なる関係だからだ。

仕様が対象外としたものも境界を示す。アクセス制御、通信量から分かる流れの秘匿、宛先一覧の正確性、経路制御、受領の保証や否認防止、確認応答との対応付け、重複検出、再送攻撃の防止は解決しない。本文の完全性から、それらの事実を推測してはいけない。

画面上の文章ではなく、正規化したバイトを署名する

PEM の処理は各ホストのローカル形式から始まる。RFC 1421 はそれを inter-SMTP 表現にならった共通形へ直した。文字は ASCII、行末は CRLF である。SMTP の透明性処理で行頭のピリオドに施す変換は、この正規対象には含めなかった。

Message Integrity Check はそのバイト列から作られる。秘匿を選んだ場合の暗号化も同じ表現を出発点とする。一般形は Encode(Encrypt(Canonicalize(Local_Form))) と示され、メッセージ種別に不要な処理を外す。受信側は対応する処理を逆順で行い、最後にローカル形式へ戻す。

この順序は異なる計算機を結んだが、同時に証明対象を厳密にした。MIC が認証するのは「人に同じ意味に見える段落」ではない。規定の手順で再構成されたバイトである。表示が同じでも行末が違えば不一致になり得るし、見かけに変化があっても正しく外側の処理を外せば同じ対象へ戻れる。

RFC 822 はフィールドと任意の ASCII 行本文としてメッセージ形式を定め、RFC 821 は SMTP の DATA と透明性規則を定めていた。PEM は広く実装済みの行指向モデルを利用したのであって、正規化途中の表現そのものを観測済み SMTP 取引だと扱ったわけではない。

三つの形式、三つの互換性

ENCRYPTED は認証と完全性に加えて機密性を提供する。正規本文を暗号化し、異なるメール環境を通せる制限された印字可能文字へ表す。

MIC-ONLY は本文を秘密にはしないが、そのまま平文で見せる形式でもない。正規本文を印字可能符号へ変えるため、メール転送系がしがちな変換が署名対象へ届きにくい。受信者は PEM 実装で復元し、MIC を検証してから読む。

MIC-CLEAR は MIC-ONLY と同じ認証・完全性の処理を持ちながら、この印字可能符号化だけを省いた。ここに互換性上の魅力があった。PEM ソフトウェアのない相手でも、本文の意味には到達できる。しかし署名の妥当性には到達できない。

読めることと確かめられることは、同じ段階ではない。前者は見える表現が成立すればよい。後者には制御フィールド、適切な鍵、正しい正規化、そして一致する MIC が要る。

人間にとって、この差は時間差にもなる。命令、依頼、警告は表示された瞬間から行動を促す。検証が終わっていなくても文章は説得力を持つ。互換性のために先に読ませるなら、未検証という状態も同じ強さで見せなければならない。

不一致は観測結果であり、原因名ではない

MIC-ONLY の符号化は Message Transfer System 内の書き換えから署名対象を守る役割を持った。MIC-CLEAR はそれを省く。そのため、途中で本文が変わらなかった場合、あるいは変化を特定して検証前に戻せる場合に限って、MIC を正しく照合できる。

典型は改行である。SMTP は CRLF を使うが、受信ホストが PEM 処理へ渡す前に自分の行末へ変えるかもしれない。検証者は配達済み本文を再正規化し、inter-SMTP 表現を復元して比較用 MIC を計算する必要がある。

転送による封入には別の可逆変換がある。RFC 1421 は RFC 934 の境界方式を採用した。MIC-CLEAR の行頭がハイフンで、外側の境界と誤認され得るなら、転送層は を前置する。MIC はその追加より前の本文で計算済みである。したがって検証前に、追加した外層自身がエスケープを除かなければならない。

MIC の不一致は差が残ったことを示す。しかし、悪意による改ざんと、受信側が認識できなかった無害な変換を区別しない。RFC 1421 が MIC-CLEAR の失敗は必ずしもセキュリティ上の事象を意味しないと述べたのは、このためだ。

利用者への表示も二値判定では足りない。失敗を報告するときは、どの PEM 形式だったかを示すべきだとした。また、構文上は正しいが MIC が失敗したメールを、そのまま信頼済みとして表示してはならない。真正性と完全性への警告を出し、利用者が明示的に続行を選ぶ。失敗を消すのでも、原因不明を攻撃と断定するのでもない。

境界の外側は、署名の外側のまま

PEM の制御フィールドは外側メール本文の中に封入ヘッダーとして置かれる。境界外に保護されない注記を置くことも、複数の保護オブジェクトを含めることも、転送を入れ子にすることもできた。画面で近く見える文字が、署名範囲へ自動的に入ることはない。

有効な MIC も、外側の差出人表示、宛先一覧、通過経路、受領、本人の閲覧を証明しない。それは正規化された本文、MIC、鍵処理の間に成立する証拠である。人の権限、同意、返信、実行は別の記録を要する。

RFC 1423 はアルゴリズム、モード、識別子を処理文法とは別の文書に分けた。交換可能な暗号面とメッセージ処理の骨格を分離する考え方だった。RFC 1421 と RFC 1423 は現在どちらも Historic である。この構造上の教訓は読めるが、1993年のアルゴリズム群を現代の安全策として勧めるものではない。

MIC-CLEAR が残した歴史は、古い配送網でも摩擦なく安全になれたという成功談ではない。中継を変えず、本文を誰にでも読ませるという二つの利点と引き換えに、署名対象から表示までの変換履歴を検証者が背負う。その交換条件を明文化したことに価値がある。