全体像（何の話？）
-
テーマは「S/MIMEを使ったメール暗号化と送信者検証」。問題は“委託先とのメール”に限定され、設計・運用の要所を読解する構成です。
既存のメール・ファイル受け渡し運用
-
R社の自社ドメインは r-sha.co.jp。普段はF社の「ファイル交換サービス」を推奨。委託先側の社内ルールで外部サービス禁止の場合は、設計ドキュメントを“パスワード付きZIP”にして“ML宛にメール送付”、さらに“パスワードは平文メールでML宛に送る”という、典型的に危ない手順になっている。
-
MLはG社サービス。MLアドレスのドメインはG社保有、ローカル部は「プロジェクト名_相手社名」の規則。例：b-project_s-sha。
-
MLに送ると登録メンバ全員に同報。登録メンバ管理は各プロジェクト管理者の役割。
R社の情報システム（図1・表1・表2の要点）
-
ネットワークはPC-LAN／内部システムLAN／DMZに分割。DMZには“外部メールサーバ”と“プロキシ”。内部側には“内部メールサーバ”“ディレクトリサーバ”“ファイルサーバ”。
-
内部メールサーバ
-
SMTPで外部メールサーバと転送、R社ドメイン宛はメールボックス格納、PCはPOP3で受信、SMTPで送信。
-
-
ディレクトリサーバ
-
X.500系ディレクトリ（TCP 389）に“aというプロトコル”でアクセス。内部サーバ認証にも利用。→ここが設問1(1)の伏線。
-
-
外部メールサーバ（DMZ）
-
インターネット/内部メールサーバとSMTPで中継。SMTP over TLSにも対応。
-
-
PCのWebブラウザは、HTTPSサーバ証明書の失効確認に“RFC 6960のb”を使う設定。→設問1(2)の伏線。
要望（要件）
-
要件は2本柱：
①「送信者→受信者まで、メールが“通しで暗号化”されていること」
②「委託先とのメールが“なりすまされていない”と確認できること」
“TLSだけじゃダメ”の理由（下線①の趣旨）
-
Hさんは「メール通信を暗号化（＝SMTP over TLSなど）すれば両方満たせる？」と考えたが、E主任は否定。
-
ポイント：
-
TLSは“通信路”を暗号化・サーバ真正性を確認できるが、メールサーバ上（保管時）の暗号化は担保しない＝要件①を満たせない。
-
送信者の“From詐称”はTLSでは検出できない＝要件②を満たせない（送信元サーバの真正性は確認できても、送信者アドレスの詐称は別問題）。本文も「委託先のメールアドレスを使うようななりすましは検出できない」と明示。
-
S/MIME案（“エンドツーエンド暗号化”＋“署名で送信者検証”）
-
R社CAでS/MIME用鍵ペア・クライアント証明書を発行し、失効情報サーバを用意、クライアント側で失効確認、将来の読めなくなるリスクに備え“必要メールは復号してファイルサーバ保存”という運用案を作成。
-
ここでの“将来読めなくなる”は「秘密鍵を失った/削除した等で復号できない」事態を想定（設問2(3)の伏線）。
-
現実の課題（ア）（イ）（ウ）と解決
-
（ア）委託先では“プライベートCAのルート証明書をPCに入れることが禁止”の場合がある。するとR社従業員が送ったS/MIMEの“d（＝署名）”を“e（＝検証）”できない。解決：商用CA発行のS/MIME証明書に切替え。すると“失効情報サーバの導入も不要”。
-
（イ）委託先に証明書をどう渡す？——S/MIMEで“署名付きメール”を送れば、受信者は“送信者の証明書を同時に受け取り”、かつ“なりすましでない”ことを確認できる（便利なのでメールで送る方針に）。
-
（ウ）ML宛メールは“各受信者の公開鍵で個別暗号化”が必要だが、MLでは受信者が複数・入替ありで難しい。G社に「MLで復号→各メンバ向けに再暗号化して配信」という案を打診したが“非対応”。よって“暗号化メールはMLを使わず、委託先担当者の証明書で暗号化し、個別アドレスへ送信”に決めた。
結果
-
事前説明・内諾・試行を経て、S/MIME利用を開始。
用語のミニ解説（本文の“穴埋め”に対応）
-
LDAP：X.500系ディレクトリへTCP 389でアクセスするプロトコル。本文“a”の伏線。
-
OCSP：RFC 6960で定義のオンライン失効確認。本文“b”の伏線（ブラウザ設定）。
-
SMTP over TLS：メール配送の通信路暗号化（ただしサーバ保管時の暗号化ではない）。
-
S/MIME：メール本文/添付の暗号化・電子署名で“エンドツーエンド暗号化”と“送信者の真正性”を実現。本文の中心テーマ。
-
ML（メーリングリスト）：1アドレス宛に送ると登録メンバ全員へ同報する仕組み。
設問で問われるポイント（拾いどころ）
-
設問1
-
(1) a＝LDAP（表1の“X.500 / TCP389 / ディレクトリアクセス”から導出）。
-
(2) b＝OCSP（RFC6960による失効確認）。
-
-
設問2
-
(1) 「通信暗号化だけではサーバ上で平文になる」趣旨（“メールサーバ上では暗号化されていない”）。本文のTLSだけでは要件①・②を満たせない流れより。
-
(2) c＝メールサーバ（“送信元のメールサーバの真正性確認”の流れ）。
-
(3) 「秘密鍵を意図せず削除した場合に復号不能」。
-
-
設問3（穴埋めの意味づけ）
-
d＝ディジタル署名（署名付きメールを送る話）／e＝検証（受信側の確認）／f＝MLの登録メンバ／g＝ML（ML暗号化案の文脈）。
-
