要約

  • 2001 年の Experimental RFC 3183 は、組織境界の MTA やゲートウェイが利用者に代わって S/MIME を処理する設計を示した。正しいドメイン署名があっても、送信者個人の証明書署名がなければ、外部の受信者が表示できるのは原則としてドメイン名だった。
  • 送信者署名、ドメイン署名、審査署名、追加属性署名、ドメイン復号は別々の行為である。入れ子と変換順序を失えば、「署名済み」という表示だけでは責任主体を復元できない。

RFC 3183 の対象は、デスクトップの利用者だけではなかった。メール転送エージェント、ガード、ファイアウォール、プロトコル変換ゲートウェイが、組織またはセキュリティドメインのために S/MIME オブジェクトを生成・処理する。端末に PKI がない、内部形式が異なる、証明書基盤が相互運用できない、保存装置がメールを書き換える、境界で検査と監査が必要だ、といった事情が背景にあった。

文書はエンドツーエンド方式とドメイン方式の優劣を決着させていない。代わりに、誰が何を証明するかを型に分けた。

送信者署名は送信者と内容を結ぶ。ドメイン署名は利用者の代理で作られる署名である。ドメイン署名者は、内側の送信者署名、または認証済みリンクなど S/MIME 外部の手段で送信者を先に認証し、依存する署名も検証しなければならない。失敗した場合はドメイン署名を生成してはならない。

それでも、内部で個人を認証した事実と、外部で個人名を表示できる事実は同じではない。送信者署名が残っていれば、その証明書名を受信者が確認できる。残っていなければ、RFC 3183 が受信者に許す推定は送信元ドメインまでである。境界の内側で個人が正しく特定されていても、外側に届いた検証可能な発言者はドメインであり得る。

したがって、内容を作った主体、内部で認証された主体、放出を決めた主体、外部で観測された署名者を分けなければならない。これらは連鎖していても同一ではない。

審査署名は、審査者が転送を承認したことを表す。ガードはその署名を通過条件にできる。しかし審査者は著者にならず、その署名は送信者を認証しない。内容の真実性、法的妥当性、配送、受領も証明しない。証明されるのは、特定の権限者が特定の方針下で先へ送ることを承認したという行為である。

追加属性署名は SignerInfo の属性をメッセージに結び付ける。検証により、どの属性権限者がどのデータをどの内容に結び付けたかは分かる。属性が指す外部事実の真偽や鮮度、後続判断への適格性までは自動的に確定しない。

これらの意味を機械が区別するため、RFC は署名済み属性 SignatureType を定義した。Verified Erratum 3757 は本文から抜けていた属性 OID、id-aa-signatureType の 1.2.840.113549.1.9.2.28 を補った。実装上重要な修正だが、証明範囲は変えない。識別子が直っても、審査承認が著者証明に変わるわけではない。

暗号化では、ドメイン機密権限者が利用者やドメインのために暗号化・復号できた。この仕組みは運用上の障害を解く一方、鍵と平文の保管場所を変える。ドメイン鍵の侵害は多数の利用者へ及び得る。受信側 DCA が復号すれば、その先には平文が存在する。DCA 自体が侵害され、端末が独立検証できる署名もなければ、DCA の「検証成功」という報告だけで完全性は保証できない。

メーリングリストと入れ子処理では、装置が検証、復号、層の除去、属性の保存、新たなドメイン署名、再暗号化を順に行う場合がある。リスト展開履歴を別の SignedData 層で残すこともある。だから必要なのは抽象的な「署名あり」ではなく、対象バイト、内容型、署名種別、証明書、変換時点の記録である。

当時の S/MIME、CMS、Enhanced Security Services が容器を提供し、後続 RFC が CMS、S/MIME、PKIX の基準を更新した。それは RFC 3183 の普及を証明せず、Experimental という地位も変えない。IANA の割当は識別子の存在を示すだけで、利用実績ではない。

歴史的な教訓は、入れ子を責任の時間軸として保存することにある。送信者が作成し、ドメインが認証して放出し、審査者が転送を許可し、属性権限者が属性を結び、機密権限者が暗号を解き、受信者が結果を見る。各動詞の主語を残して初めて、境界を越えた後にも説明責任が残る。