要約

  • RFC 2015 は RFC 1847 の multipart/signed を採用し、読める MIME 部分と分離署名を分けながら、第一部分の MIME コンテンツヘッダーも署名対象に含めた。
  • 7 ビット化、CRLF、Quoted-Printable や Base64、行頭の From 、末尾空白は表示上の細部ではなく、検証入力を一致させる条件だった。
  • 検証が示すのはバイト列・署名・鍵の関係であり、本人性、権限、意図、配送、閲覧、結果を単独で証明するものではない。

初期の application/pgp 方式には構造上の不便があった。署名本文を取り出すだけでも PGP 固有の構造を解析しなければならない場合があったからだ。RFC 1847 はセキュリティ方式に依存しない二部構成を定め、RFC 2015 は第一部に署名対象、第二部に application/pgp-signature を置いた。PGP を検証できない MIME 実装でも、内容の位置は理解できるようになった。

しかし、第一部が読めることは、途中で変更してよいことを意味しない。テキストなら、文字表現を決め、改行を CRLF に正規化し、Content-Transfer-Encoding を適用し、コンテンツヘッダーを加えてから、そのヘッダーと符号化済みデータを署名する。ヘッダーを含めるのは、Content-Type や符号化ラベルの変更によって同じデータの解釈が変わるのを防ぐためだった。

7 ビット SMTP との境界では、この順序が実務上の制御になる。次のホップが 8 ビットに対応しなければ、ゲートウェイは Quoted-Printable や Base64 に変換できた。配送には有益でも、署名後ならハッシュ入力の置換である。したがって署名対象は、出発前から転送に耐える 7 ビット表現でなければならなかった。

RFC 2015 の例は、行頭の From と末尾空白をわざわざ保護する。旧来のメールボックス処理は From の前に > を加えることがあり、別のゲートウェイは空白を削ることがあった。RFC 3156 は後に CRLF の復元、空白処理、最終行の境界をさらに明確にした。見た目が同じでも、署名された記録が同じとは限らない。

暗号化だけのオブジェクトは 8 ビットを保持できた。受信者が不透明な OpenPGP データを復号して内部オブジェクトを得るからである。分離署名では、受信者がすでに可読な第一部を持ち、送信者と同じ表現を再ハッシュする。署名後に暗号化する場合も、内側の署名対象には同じ規律が必要だった。

RFC 2480 は、非 MIME 環境へ渡すゲートウェイに二つの能力を求めた。保護オブジェクトを変更せずトンネルするか、署名が壊れると承知して内容を展開するかである。展開時には署名を消さず、検証可能性を失ったという警告を残す。ゲートウェイによる代理検証や再署名は、新しい鍵管理と信頼終点を生むため、既定で有効にすべきではなかった。

有効な署名は、検証器が特定の MIME エンティティを再構築し、特定の公開鍵で署名を確認したことを示す。鍵が誰を表すかは別の信頼判断である。文章の執筆者、組織上の権限、配送、表示、時刻、取引結果までは導けない。失敗も攻撃者を特定しない。悪意ある変更、善意の変換、改行差、保存破損、誤った鍵のいずれでも起こり得る。

RFC 2015 の長期的な教訓は、暗号計算より先にある。ネットワークが「これ以上は直さない」と約束する表現を、まず定義しなければならない。

情報源