要約

  • HP-Outerは、作成側が暗号エンベロープの外へ意図的に置いたヘッダー名と値を、暗号ペイロード内の保護された証跡として残す。
  • 受信したMIME暗号レイヤーが実際の保護状態を決め、hpは作成者の意図を示すにすぎない。意図から機密性を水増ししてはならない。
  • 内側と外側のFrom、署名とアドレスの結合、配送側の認証、画面表示、返信先は別々の判断であり、一つの鍵マークに統合できない。

メール一覧には、送信者、日時、件名が並ぶ。暗号化された本文を開く前から見えるこの画面は、ヘッダー保護にとって厳しい試験場だ。件名が [...] なら安心してよいのか。外側の件名が途中で削除されただけなら、受信時の見た目は同じになる。

RFC 9788は、最終状態だけを比較して過去を推測する設計を退ける。作成ソフトが外側に何を出したかを、改ざんから守られた形で内側に残す。暗号化アイコンを強くするのではなく、主張を小さくし、出所を付ける。

暗号状態はMIMEの配置から読む

RFC 9787では、S/MIMEとPGP/MIMEを暗号レイヤーの木として扱う。署名レイヤーは完全性と真正性を、暗号化レイヤーは機密性を与えるが、具体的な性質は方式による。レイヤーの順序も意味を持つ。署名してから暗号化した構造と、暗号化してから署名した構造は同じではない。

最外側のMIME型から連続する暗号レイヤーが暗号エンベロープで、その内側にある最初の非暗号部分が暗号ペイロードになる。通常のMIME部分で連続性が切れれば、その奥の署名や暗号文はメール全体の状態を代表できない。

これは画面の色より先に保存すべき受信事実だ。圧縮がCMS容器に入っていても、それだけで暗号レイヤーにはならない。同様に、本文が復号できても、外側にある全ヘッダーが秘密だったとは限らない。

従来の暗号メールは本文を守りながら、件名や見かけ上の送信者を外に残すことが多かった。RFC 8551の旧方式は、完全なmessage/rfc822を暗号エンベロープで包んだが、旧来のMUAで表示や安全処理の問題が生じた。RFC 9788は、中間のラッパーを使わず、作成時に把握しているヘッダーを暗号ペイロードへ直接複製する。

暗号化メールの非構造ヘッダーは、外側に同じ値を残す、別の値に隠す、外側から消す、という三つの扱いを受ける。内側に暗号化コピーがあるだけでは、そのどれだったか分からない。

HP-Outerが記録する一回の判断

HP-Outerは暗号ペイロードのヘッダー部に置かれる。作成側が外側に意図して公開した非構造ヘッダーごとに、フィールド名と外側の値を複製する。

外側のSubjectを[...]へ置き換えたなら、その文字列が記録される。Dateをそのまま残したなら、明文の日時が記録される。保護されたフィールドに対応するHP-Outerが一つもなければ、作成側はメールシステムへ投入した時点で、そのフィールドを外側に出していないと表明している。

この証跡は作成行為に強いが、配送経路全体には弱い。中継が後からフィールドを追加、削除、変更しても、HP-Outerはその出来事を観測しない。配送先、受信者鍵ID、Received、メールボックス内の順序から、隠したはずの情報を推測できる場合もある。

それでも証跡は決定的な誤認を防ぐ。作成側がCcを外に出し、攻撃者が途中で外側Ccだけを消したとする。最終的な内外差だけを見るMUAは「Ccは最初から暗号化されていた」と誤判定する。保護されたHP-Outerが一致すれば、作成者が公開した事実は消えない。

表示上の評価では、そのCcを機密だったと呼べない。一方、返信処理では、値を再び平文へ漏らさないよう保守的に扱える。歴史の説明と将来の防御は別の判断である。

HCPは送られるラベルではない

ヘッダー機密性ポリシーHCPは、非構造ヘッダーの名前と入力値から、同じ値、隠した値、外側削除を示すnullのいずれかを返す関数だ。

推奨のhcp_baselineは控えめで、外側Subjectを[...]にし、CommentsとKeywordsを消し、その他を通す。hcp_shyはさらにFrom、To、Ccの表示名を外し、DateをUTCへそろえる。可読なメタデータは減るが、正しい構文解析が必要で、配送や表示への影響も増えるため、既定の推奨ではない。

ポリシー名そのものは通信路に出ない。受信側が見られるのは、HP-Outerに現れた個々の判断だ。IANAレジストリは実装可能な記述と推奨状態を保つが、特定製品の実装、利用者設定、個別メールでの採用を証明しない。

共通層が担うのは、フィールド構文、再現可能な処理、登録の条件まででよい。To、Cc、References、In-Reply-Toまで隠す方針は環境によって有効だが、配送、検索、スレッド、メーリングリストを壊す可能性がある。より厚い秘密化は、ローカルな実行証拠とともに採用すべきだ。

hpは予定表であって実績表ではない

保護されたContent-Typeのhpパラメータは、作成者の意図を示す。cipherは暗号化を伴うヘッダー保護を試みたことを、clearは署名のみの構成を示す。

受信側は実際の暗号レイヤーを見なければならない。暗号化レイヤーがないのにhp=cipherと書かれたメールは、署名のみである。意図を機密性へ昇格させてはならない。

逆に、中継者が元は署名だけだったメールを暗号層で包むこともできる。受信した暗号層は存在するが、元の作成者が作ったとは限らない。その不一致があるとき、HP-Outerがないことから「作成時に全ヘッダーを隠した」と推定するのは危険だ。

監査にはMIME木と順序、hp、すべてのHP-Outer、実際の外側ヘッダー、解析結果を分けて残す必要がある。encrypted=trueだけでは再検証できない。

表示するアドレスと返信するアドレス

外側Fromは配送系が評価できる。内側Fromは端末間の署名で保護できる。RFC 9788は両者のaddr-specが異なる状態を不一致と定義する。

内側にあるだけでは送信者認証にならない。署名が有効で、その証明書が保護されたメールアドレスへ正しく結び付いている必要がある。不一致と結合不成立が同時に起きたら、MUAはフィッシングに近い警告を出し、二つの値を示すべきだ。

配送側の認証に依存する表示では、実際の外側Fromを慎重な退避値として使う。悪意ある作成者が、有名人のアドレスを暗号部分に書いただけで真正な送信者として表示されるのを防ぐためだ。

しかし返信先は保護されたヘッダーだけから作る。改変可能な外側Fromが返信先を支配すれば、中間者が機密な会話を自分へ誘導できる。

同じ画面に異なる規則があるのは欠陥ではない。表示はなりすましを避け、返信は経路改変による漏えいを避ける。表示名はさらに別物で、メールアドレスのような大域的一意性も、証明書との結合も当然には持たない。

誰に対する秘密か

内外に同じフィールドがあれば、配送者には秘密でない。外から消しても、復号する全受信者には見える。受信者鍵、SMTPエンベロープ、Received、時刻や格納位置から関係を推測できる。

User-Agentや規則的なMessage-IDは、受信者へ端末情報を漏らし得る。Bccを誤った受信者向けペイロードに入れれば、暗号はその設計ミスを正確に届ける。メーリングリストが後から加えたフィールドも、暗号本文の隣にあるだけで端末間保証を得ない。

返信や転送では、復号した件名、参照、引用を平文へ移す危険がある。RFC 9788の成果は万能な秘密ではない。どのフィールドを、どの観測者から、いつ守ったかを検証可能にすることである。

出典

  1. RFC 9788 — Header Protection for Cryptographically Protected Email
  2. RFC 9787 — Guidance on End-to-End Email Security
  3. RFC 8551 — S/MIME 4.0 Message Specification
  4. RFC 5322 — Internet Message Format
  5. RFC 3156 — MIME Security with OpenPGP
  6. RFC 7489 — Domain-based Message Authentication, Reporting, and Conformance
  7. IANA — Mail Header Confidentiality Policies
  8. IANA — Message Headers
  9. Heng Lu — 稼働コード優先
  10. Heng Lu — 最小初期仕様とローカルな将来判断
  11. Heng Lu — 現実の層と象徴権力