要約

  • RFC 9787 のサマリーに参加するのは、Crypto Payload を外側から連続して包む署名・暗号化層だけである。
  • 入れ子の署名、孤立した暗号化断片、転送メッセージは局所的に有効でも、外側のメッセージへ状態を継承させない。
  • 返信、添付、長期保存では新しい証拠と権限が必要になる。MUA は以前の表示を新しい行為の許可として扱ってはならない。

サマリーは画面ではなく構造に属する

RFC 9787 は、Crypto Payload の周囲に連続する暗号化・署名層を cryptographic envelope と呼ぶ。MUA はその層の結果を一つに集約する。MIME ツリーの別の場所にある暗号層は errant、つまり当該エンベロープ外であり、最上位のサマリーに寄与しない。

RFC 3156 の OpenPGP/MIME、RFC 8551 の S/MIME、RFC 2045 の MIME 基盤は、処理対象の構造を与える。しかし表示上の近さは暗号学的な包含を生まない。内側の署名が検証できても、外側の説明文や隣の添付まで署名された証拠にはならない。

メーリングリストの例は明快だ。送信者が署名したメッセージをリストが包み、フッターを加える。元の署名は内側の内容について有効なままでも、購読者が受信したメッセージにとっては errant である。最上位サマリーは保護なしになる。MUA は内側の結果を別表示できるが、「受信メールが署名済み」と統合してはならない。

復号できても、周囲へ貼り込めない

孤立した暗号化部分は閲覧のため復号できる。ただし RFC 9787 は、平文を独立した MIME サブツリーとして扱い、攻撃者が制御し得る周囲の HTML へ接合しないよう求める。全体を暗号化済みと表示することもできない。

この分離には EFAIL の研究 とマルチパート・オラクル研究が示す背景がある。復号成功は鍵と暗号文の関係を示すだけで、安全なレンダリングや再配布を許可しない。RFC 9580 形式のインライン OpenPGP も、MIME エンベロープ外ならメッセージ署名の根拠にはならず、復号平文を返信に自動引用してはならない。

転送と返信は別の判断である

RFC 5322 や RFC 6532 に基づく転送オブジェクトは、独自のエンベロープを持ち得る。その状態は外側から独立している。二つのサマリーを示すなら、どちらがどのオブジェクトに属するかを偽装できない UI で明示する必要がある。

返信は新しいメッセージを作る行為だ。元メッセージの全体サマリーが暗号化なら、返信も暗号化するか、元文の引用を外す。全受信者について期限内の暗号化用証明書が得られなければ、利用者が明示的に選ばない限り引用を除く。返信攻撃の研究は、引用が単なる編集機能ではない理由を補強する。

孤立暗号文を閲覧のため復号できても、その平文は返信へ入れない。「読める」と「新しい宛先へ送れる」は別の権限である。

添付と有効期限にも独自の証拠がある

RFC 9787 では添付を一つの Crypto Payload 内に置く。添付ごとに別エンベロープを与えると、全体の完全性なしに削除、置換、並べ替えができ、単一表示では混在状態を表せない。保護を主張するには、画面上のクリップではなく解析した MIME ツリーで payload への所属を確認する。

証明書が後に期限切れになっても、必要な秘密鍵を保有していれば過去の暗号文は復号できるべきだ、と RFC 9787 は述べる。有効期限はローテーションや鍵破棄の判断材料であり、古い暗号文を遡って変更しない。送信者向け完全コピー、別版、平文、セッション鍵の保存は、それぞれ再現性、漏えい面、バックアップ、他 MUA での利用可能性を変える。

RFC 9788 のヘッダー保護は隣接領域であり、ここでは展開しない。RFC Editor 情報、Datatracker、errata 検索は文書状態と確認時点で該当 errata がなかったことを示すが、製品実装を証明しない。