要約

  • RFC 9787 は、リモートの Drafts に平文の未完成メッセージを残すこと自体を漏えいリスクとして扱う。MUA は一定の例外を除き下書きを暗号化すべきであり、その暗号化対象は著者自身の証明書、または著者だけが保持する同等の鍵に限定される。
  • 下書きには著者の通常の署名鍵を使ってはならない。RFC が問題にするのは、未完成の文章に否認困難な署名を付けることで、漏えい後に「著者がすでにコミットしていた」と主張される余地を生むことだ。これは普遍的な法的効果の断定ではなく、署名が持つ証拠的意味についての設計上の警告である。
  • 複数端末の継続性が難所になる。二台目の MUA が同じ下書きを再開するには、同じメールボックスだけでなく復号可能な秘密鍵への安全なアクセスも必要になる。RFC 9787 はこの共有を未解決の相互運用問題として残している。
  • 受信者向け暗号化は実際に送信するときまで行わない。保存中のオブジェクトを著者だけが読める状態から、最終受信者が読める送信オブジェクトへ変える瞬間こそ、技術上の権限境界である。

自動保存は小さな「送信」ではない

RFC 9787 の 9.5 節は、多くの Mail User Agent、つまり MUA が、まだ送っていないメッセージを Drafts フォルダへ保存すると説明する。問題はそのフォルダがどこにあるかだ。IMAP メールボックスのように利用者自身の端末外に置かれていれば、完成時に暗号化する予定だったとしても、途中の平文がリモートサービス側に露出する経路ができる。

この指摘の重要なところは、「最終的に暗号メールになる文書だけを下書き暗号化すればよい」としていないことにある。作成途中には最終判断がまだ確定していない場合がある。送信直前に暗号化を選ぶこともできる。そこで RFC 9787 は、完成版が平文で送信されると MUA が明示的に知っている場合、または Drafts を潜在的な攻撃者が読めないと分かっている場合を除き、すべての下書きを暗号化することを SHOULD としている。

ここで「下書き」は単なる完成メールの若い版ではない。まだ公開範囲が確定していないオブジェクトである。保存は継続作業のために必要だが、保存したこと自体から、第三者へ内容を開示する権限までは生じない。

暗号化しても、予定受信者には渡さない

RFC 9787 はさらに強い境界を置く。保護された下書きは、著者自身の証明書、または著者だけが保持する同等の秘密鍵にのみ暗号化されなければならない。予定受信者を暗号化対象に含めてはいけない。

この違いは一見細かいが、メールの権限モデルを変える。受信者の公開鍵で暗号化されたオブジェクトを保存すれば、技術的にはその受信者が復号できる可能性を作る。まだ推敲中で、宛先さえ変更され得る文章に、その権限を先渡しする理由はない。RFC は、実際に送信するときに初めて受信者向け暗号化を行うという順序を採る。

したがって、下書き暗号化の目的は「未来の受信メールを早めに作ること」ではない。リモート保存という利便性を維持しながら、未完成の内容を著者の管理範囲に残すことにある。

二台目の端末で、暗号化は鍵配布問題になる

冒頭の仮想例に戻る。一台目の MUA が著者専用に暗号化して下書きを保存した。二台目の MUA は同じメールボックスからそのオブジェクトを取得できる。しかし、それだけでは文章を再開できない。二台目にも復号できる秘密鍵が必要になる。

RFC 9787 はこの点を明示しており、Appendix A.4.1では、複数の MUA 間で利用者自身の証明書と秘密鍵を効率的かつ安全に共有するための詳細な指針を将来課題としている。安全な鍵伝送や維持管理を含め、現在の文書の範囲外だ。Appendix A.4.2は、スマートカードや USB トークンなどの可搬型秘密鍵という別の方向も挙げるが、その運用方法を標準化してはいない。

ここで運用上の問題は「暗号化できるか」から「同じ変化中のオブジェクトを、許可された複数クライアントだけが継続して扱えるか」に移る。端末 A が版を保存し、端末 B が復号して編集し、さらに A が古い版から編集を再開した場合、最後に何が送信対象になったのかを理解するには、暗号方式だけでなく版管理とクライアント間の状態整合が必要になる。

S/MIME 4.0 の仕様である RFC 8551と、OpenPGP を定義する RFC 9580は暗号保護の技術的基盤を提供する。しかし、それらが存在することは、端末横断で使われる下書き専用鍵が広く運用されていることの証拠ではない。RFC 9787 自身が複数 MUA 間の鍵共有を将来課題としていることと、この点を混同すべきではない。

通常署名鍵を使わない理由

下書きに対するもう一つの境界は署名だ。RFC 9787 は、適合する MUA が著者の通常の署名鍵で下書きを署名することを MUST NOT とする。

理由は機密性とは異なる。暗号化は「誰が読めるか」を制御する。署名は「誰がこの内容に結び付けられるか」を強くする。RFC は、未完成文に否認困難な署名を付けたまま信用できない Drafts 保存先へ流出した場合、保存先の運営者が、著者はその内容にすでにコミットしていたと主張できる危険を説明している。

これは「暗号署名があれば、あらゆる法域で法的承諾が成立する」という話ではない。RFC が扱うのは、著者がまだ確定していない文章に、通常なら完成した意思表示と関連付けられ得る暗号学的証拠を早すぎる段階で付けないという設計判断である。

複数 MUA 間の暗号学的調整のために下書きへ署名が必要なら、RFC は通常署名鍵とは別の鍵を使う方向を示唆する。しかし、その鍵の配布、識別、失効や相互運用の仕組みを定義してはいない。この「示唆されている」と「運用可能な標準が存在する」の差は残る。

Drafts という名前だけでは境界は守れない

メール保存プロトコルには以前から下書きを示す状態がある。IMAP4rev2 の RFC 9051では \Draft が、まだ作成を完了していないメッセージを示すシステムフラグとして定義される。RFC 6154には、下書き用メールボックスを示す special-use 属性 \Drafts がある。

JMAP Mail の RFC 8621は $draft を定義する。送信例では、保存済みの下書きを送信し、成功時に $draft を外し、Drafts のメールボックスから Sent 側へ移す状態遷移が示されている。

これらは重要な保存・状態機構だが、RFC 9787 が問題にするコミットメント境界そのものではない。Draft という状態が付いているだけでは、そのオブジェクトが著者だけに暗号化されているか、通常署名鍵が使われていないか、予定受信者に復号権限が与えられていないかまでは分からない。

言い換えれば、メールボックスの状態と暗号上の権限は別軸である。送信操作は両者を同時に変化させ得るからこそ、どの版が、どの MUA によって、どの受信者集合へ提出されたのかが運用上の核心になる。

編集提案：「下書き意図の保管レシート」

ここで BTW の編集提案として、「下書き意図の保管レシート」を考えたい。これは RFC 9787 の要件ではなく、標準として定義されたデータ形式でもない。複数 MUA が同じ暗号化下書きを扱う環境で、後から権限変化を説明するための最小限の補助証拠という位置付けである。

レシートが結び付けるべきなのは本文ではなく遷移だ。下書きオブジェクトまたは版を示す内部参照、保存先のクラス、著者専用だった暗号化範囲と鍵クラス、復号と更新に成功したクライアント、送信前の最終書込みまたはマージ状態を記録する。さらに、その下書きに通常署名鍵を使わなかったという確認を残す。ただしこれは「端末に通常署名鍵が存在しなかった」という意味ではない。必要なのは存在証明ではなく、その下書きに対する不使用の記録である。

同じレシートは、送信前には受信者向け暗号化が存在しなかったことを示し、実送信が起きた時点でイベント、開始クライアント、時刻、最終受信者集合のダイジェスト、提出オブジェクトのハッシュを結び付ける。送信後に下書きを消去したか tombstone 化したか、その記録の責任者は誰か、どの条件で見直しまたは失効扱いにするかまでを残せれば、保存状態と送信状態の境界を説明しやすくなる。

これは汎用ログを増やす提案ではない。本文、件名、無制限の受信者一覧、秘密鍵、認証情報、一般的な行動ログをレシートへ複製してはならない。証拠を作るために下書きそのものの新たな漏えい面を作れば目的が逆転する。

通常のハッシュも匿名化装置ではない。候補値の空間が小さければ列挙でき、同じ値が複数の記録に現れれば相関にも使われ得る。最終受信者集合のような値を残す必要がある場合、環境によっては鍵付きの表現やアクセス制御された証拠領域の方が適切になる。目的を下書きから送信への権限遷移の検証に限定し、保持期間も短くするべきだ。

重要なのは、レシートがメッセージの代替物ではないことである。それは「何を書いたか」ではなく、「その時点で誰が読める状態だったか」「どのクライアントが最後の版を扱ったか」「いつ送信という権限変更が起きたか」を狭く記録する。

調査から分かることと、まだ分からないこと

RFC 9787は 2025 年 8 月公開の Informational RFC であり、Internet Standards Track の仕様ではない。要求語を含む実装指針ではあるが、文書の存在だけから市場全体の実装状況を推定してはいけない。

2026 年 9 月 21 日の調査時点で、RFC Editor の errata 検索には RFC 9787 に一致する errata は確認されなかった。一方、本稿の調査で確認できた資料からは、RFC 9787 の普及率、主要ベンダーの適合率、下書き平文漏えいの実測頻度、下書き署名の具体的な法的効果、標準化済みの下書き専用鍵交換を裏付ける審査済みデータは確認できない。

従って、ここで確実に言えるのは仕様上の境界である。保存中の下書きをリモート保存先から守ること。暗号化対象を著者側に閉じること。通常署名鍵によるコミットメントの先取りを避けること。そして、受信者へのアクセス権を実送信まで与えないことだ。その先の展開度や実効性は、実装と運用を別途観測しなければ分からない。

出典