← RFC Reference

RFC 5751: S/MIME 3.2 メッセージ仕様

これが存在する理由

トランスポート層セキュリティ（TLS、STARTTLS）はホップ間のメールを保護しますが、制限があります：

• サーバー運用者はあなたのメールを読むことができます。TLSは各サーバーで終了します。送信サーバー、受信サーバー、および仲介者はプレーンテキストコンテンツを見ることができます。
• 送信元の保証がありません。DKIMはドメインがメッセージを処理したことを証明しますが、どの人がそれを作成したかは証明しません。
• 配信後の改ざん検出がありません。メッセージがサーバーに保存されると、メッセージが変更された場合、DKIM署名が壊れる可能性があります。S/MIME署名はコンテンツ自体を保護します。

S/MIMEはエンドツーエンド暗号化（受信者だけが復号できる）とデジタル署名（受信者は送信者の身元とコンテンツが改ざんされていないことを確認できる）を提供します。HTTPS保護と同じPKIからのX.509証明書を使用します。

仕組み

2つの操作

S/MIMEは標準のMIMEメッセージをCMS（暗号メッセージ構文）を使用して暗号エンベロープでラップします：

署名のみ、暗号化のみ、または署名してから暗号化することができます（最も一般的な組み合わせ）。

メッセージに署名する

送信者は秘密鍵を使用してメッセージコンテンツ上にデジタル署名を作成します。2つの形式が存在します：

• クリア署名（multipart/signed）：元のメッセージは任意のクライアントで読むことができます。署名は別のMIMEパートです。非S/MIMEクライアントはメッセージを通常表示し、署名を無視します。
• 不透明署名（application/pkcs7-mime）：メッセージと署名が一緒にバンドルされています。S/MIME対応クライアントのみがコンテンツを抽出できます。

-- クリア署名メッセージ構造 --
Content-Type: multipart/signed;
  protocol="application/pkcs7-signature";
  micalg=sha-256; boundary="----sig"

------sig
Content-Type: text/plain

これが元のメッセージコンテンツです。
任意のメールクライアントで読むことができます。

------sig
Content-Type: application/pkcs7-signature
Content-Transfer-Encoding: base64

MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBgl...
（base64エンコードされたCMS SignedData）
------sig--

メッセージを暗号化する

送信者は受信者の公開鍵（X.509証明書から）を使用して暗号化します。対応する受信者の秘密鍵のみが復号できます：

-- 暗号化されたメッセージ構造 --
Content-Type: application/pkcs7-mime;
  smime-type=enveloped-data;
  name=smime.p7m
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename=smime.p7m

MIAGCSqGSIb3DQEHA6CAMIA...
（base64エンコードされたCMS EnvelopedData）

実際には、S/MIMEはハイブリッド暗号化を使用します：ランダム対称鍵（例：AES-128-CBC）がメッセージを暗号化し、受信者のRSA/EC公開鍵がその対称鍵を暗号化します。

主要な技術詳細

証明書要件

S/MIMEは認証局（CA）によって発行されたX.509証明書に依存します。証明書は以下を含む必要があります：

• サブジェクト代替名（SAN）またはサブジェクトフィールド内の送信者のメールアドレス。
• emailProtection拡張キー使用法（EKU）。
• 受信者のクライアントが信頼するCAによって発行されていること。

これはS/MIME導入の最大の実際的障壁です：すべての送信者が証明書を必要とし、すべての受信者が署名を検証したり暗号化された返信を送信するために送信者の公開証明書を必要とします。

アルゴリズム要件（S/MIME 3.2）

SHA-1および3DESは後方互換性のためにまだ参照されていますが、弱いと見なされています。S/MIME 4.0はこれらの要件を大幅に更新します。

証明書検出

暗号化の場合、送信者は受信者の証明書が必要です。一般的な検出方法：

• 以前の通信：受信者が送信したサインメッセージから証明書を抽出します。
• LDAPディレクトリ：多くの組織はLDAPディレクトリに証明書を公開しています。
• DNS（SMIMEA/DANE）：RFC 8162はSMIMEAレコードを介したDNSベースの証明書検出を定義しています。
• キーサーバーまたはゲートウェイ：エンタープライズS/MIMEゲートウェイは証明書を一元管理します。

一般的な間違い

• S/MIMEとTLSを混同します。TLSはサーバー間の接続を保護します。S/MIMEはメッセージコンテンツをエンドツーエンドで保護します。異なる問題を解決し、一緒に使用する必要があります。
• 署名にSHA-1を使用しています。SHA-1は衝突耐性に関して暗号的に破損しています。常にSHA-256以上を使用してください。
• 署名なしで暗号化しています。暗号化されたが署名されていないメッセージは送信者の身元については何も証明しません。認証された暗号化のため、常に暗号化する前に署名してください。
• 証明書配布を忘れています。受信者の公開証明書がなければ、誰かに暗号化されたメールを送信することはできません。S/MIME導入前に証明書交換を計画してください。
• 自己署名証明書を使用しています。受信者のクライアントは信頼警告を表示します。相互運用性のために、認識されたCAからの証明書を使用してください。
• 混在した受信者を処理していません。一部の受信者がS/MIME証明書を持っており、他は持っていない場合、メッセージを2回送信する必要があります：証明書を持つ人には暗号化、持たない人にはプレーンです。
• 不透明署名でDKIMを壊しています。不透明署名メッセージはMIMEボディを再構成し、DKIMボディハッシュを無効にする可能性があります。クリア署名メッセージはDKIM互換性をより安全にしています。

配信可能性への影響

• S/MIME署名は信頼を向上させることができます。一部のエンタープライズメールゲートウェイはS/MIME署名を検証し、署名されたメッセージをより優遇します。Microsoft Outlookは有効なS/MIME署名に対して信頼リボンを目立つように表示します。
• 暗号化されたコンテンツはスパムフィルターに対して不透明です。スパムフィルターは暗号化されたメッセージボディを検査できません。一部のフィルターは暗号化されたメッセージを疑いで扱い、他は通します。バルクメールの場合、S/MIME暗号化は通常実用的ではありません。
• SPF/DKIM/DMARCの代替ではありません。S/MIMEはユーザーレベルで動作します。SPF、DKIM、およびDMARCはドメインレベルで動作します。両方のレイヤーは異なる目的を果たします。S/MIMEは個人の身元を証明します。DKIMはドメイン認可を証明します。
• エンタープライズコンプライアンス。規制対象業界（金融、医療、政府）は多くの場合S/MIMEを要求します。トランザクションメールでのS/MIME署名のサポートは、コンプライアンスに敏感な受信者の差別化要因になることができます。

Related RFCs