RFC 8551: S/MIME 4.0 メッセージ仕様

Standards Track Content Security Published March 2026

ELI5: [S/MIME 3.2](5751)は、メールを良いロックの付いた金庫に入れるようなものです。S/MIME 4.0はそのロックを最新のものに置き換え、内容を秘密にするだけでなく、誰かが金庫自体に改ざんを試みたかどうかも検出します。暗号化アルゴリズムを現在のベストプラクティスにアップグレードします。AES-CBCではなくAES-GCM、RSAと並んで楕円曲線、最低限としてのSHA-256。同じ概念、より強力な数学。

これが存在する理由

S/MIME 3.2（RFC 5751、2010年発行）はその時代には堅牢でしたが、暗号化は進化し続けています：

CBCモードは認証がない。 AES-CBC（S/MIME 3.2のデフォルト）はデータを暗号化しますが、改ざんを検出しません。攻撃者は平文に予測可能な変更をもたらす方法で暗号文を変更できます。AES-GCMは認証付き暗号化を提供します — すべての変更が検出されます。
RSA鍵サイズは増え続ける。 RSA-2048は今日の最小値と見なされ、RSA-4096が一般的です。楕円曲線暗号（ECDSA、ECDH）は同等のセキュリティを提供しながらはるかに小さい鍵を使用するため、メッセージサイズと計算時間が削減されます。
SHA-1は破られた。 S/MIME 3.2は後方互換性のためにSHA-1を署名に許可していました。S/MIME 4.0は署名にSHA-1を完全に廃止します。
ヘッダー保護。 S/MIME 3.2はメッセージ本体のみを署名/暗号化しました。S/MIME 4.0は暗号化されたエンベロープ内のヘッダー（Subject、Fromなど）を保護するメカニズムを追加します。

仕組み

MIME構造とCMSラッピングはS/MIME 3.2と同じままです。変更は送受信者間でネゴシエートされるアルゴリズムと機能にあります。

3.2から4.0への変更点

機能	S/MIME 3.2（RFC 5751）	S/MIME 4.0（RFC 8551）
コンテンツ暗号化	AES-128-CBC（MUST）	AES-128-GCM（MUST）
署名用ダイジェスト	SHA-256（MUST）	SHA-256（MUST）
署名アルゴリズム	RSA（MUST）	P-256付きECDSA（MUST）、RSA（MUST）
鍵転送	RSA（MUST）	P-256付きECDH（MUST）、RSA-OAEP（SHOULD）
署名用SHA-1	許可（後方互換性）	廃止
3DES暗号化	許可（後方互換性）	廃止
ヘッダー保護	対応なし	メカニズム定義
EdDSA（Ed25519）	未定義	関連RFCで参照

認証付き暗号化（AES-GCM）

最も重要な変更はAES-CBCからAES-GCMへの移行であり、必須のコンテンツ暗号化アルゴリズムです：

AES-CBCはブロックを独立して暗号化します。暗号文のビットを反転させる攻撃者は、復号化された平文に予測可能な変更を引き起こします。個別の整合性チェックがなければ、受信者は改ざんを検出しないかもしれません。
AES-GCM（ガロア/カウンターモード）は暗号化と組み込み認証タグを組み合わせます。暗号文への変更は復号化を完全に失敗させます。これは認証付き暗号化です — 機密性と整合性を単一操作で得られます。

楕円曲線暗号

S/MIME 4.0はECDSA（署名用）とECDH（鍵合意用）をRSAと並行して実装を必須にします：

アルゴリズム	曲線	同等のRSA強度	鍵サイズ
ECDSA / ECDH	P-256（secp256r1）	RSA-3072	256ビット
ECDSA / ECDH	P-384（secp384r1）	RSA-7680	384ビット
ECDSA / ECDH	P-521（secp521r1）	RSA-15360	521ビット

EC鍵は同等のセキュリティレベルでRSA鍵よりも劇的に小さいです。電子メールではこれは署名が小さく、暗号化された鍵転送ブロックが小さいことを意味するため、メッセージサイズが削減されます。

ヘッダー保護

S/MIME 4.0は電子メールヘッダー（Subject、From、To、Date）の保護されたコピーを署名付きまたは暗号化されたMIME本体内に含める方法を定義します。外側のヘッダーはルーティングと表示のために可視のままですが、内側の保護されたコピーにより受信者は転送中にヘッダーが変更されていないことを確認できます：

-- S/MIME暗号化本体内 --
Content-Type: message/rfc822

Subject: 機密四半期結果
From: cfo@example.com
To: board@example.com
Date: Wed, 12 Mar 2025 09:00:00 -0400

（暗号化本体コンテンツ...）

受信者のクライアントは内側のヘッダーと外側のヘッダーを比較し、異なる場合にアラートを表示します。

主要な技術詳細

RSA-OAEPとRSA PKCS#1 v1.5

S/MIME 3.2は鍵転送にRSA PKCS#1 v1.5を使用しました。このパディングスキームはBleichenbacher型攻撃に対して脆弱です。S/MIME 4.0はRSA-OAEP（最適非対称暗号化パディング）を推奨します。これは選択平文攻撃に対して証明可能に安全です。送信者はS/MIME機能を介して受信者がサポートを示すときにRSA-OAEPを使用すべきです（SHOULD）。

S/MIME機能属性

メッセージに署名するとき、送信者はサポートするアルゴリズムを列挙するSMIMECapabilities属性を含めます。受信者はこれを使用して相互にサポートされる最強のアルゴリズムを暗号化された返信に対して選択します。S/MIME 4.0は推奨される機能の順序付けを更新します：

AES-256-GCM
AES-128-GCM
AES-256-CBC（後方互換性のため）
AES-128-CBC（後方互換性のため）

後方互換性

S/MIME 4.0エージェントはS/MIME 3.2メッセージを受け取り処理できなければなりません。送信するときは、受信者の機能がサポートを示すときはS/MIME 4.0アルゴリズム（AES-GCM、ECDSA）を使用し、そうでない場合は3.2アルゴリズムにフォールバックすべきです。SMIMECapabilities属性がこのネゴシエーションを駆動します。

一般的な間違い

AES-GCMが利用可能なときにAES-CBCを使用する。 受信者がS/MIME 4.0をサポートしている場合、常にAES-GCMを優先します。整合性チェックなしのCBCはパディングオラクル攻撃に対して脆弱です。
RSA-OAEPを無視する。 鍵転送に引き続きRSAを使用する場合、OAEPパディングを使用します。PKCS#1 v1.5には既知の弱点があり、レガシー受信者との後方互換性にのみ使用すべきです。
S/MIME機能をアドバタイズしない。 署名付きメッセージがSMIMECapabilities属性を省略する場合、受信者は暗号化されたメールで返信するときに最低公約数を想定します。
ヘッダー保護を軽視する。 S/MIME 4.0はヘッダー保護を定義しますが、多くのクライアントはまだそれを実装していません。保護されたSubjectラインに依存する場合、受信者のクライアントが実際に内部ヘッダーをチェックすることを確認します。
EC証明書サポートが普遍的であると想定する。 S/MIME 4.0はECDSA/ECDHサポートを必須にしますが、多くの展開されたクライアント（特に古いOutlookバージョン）はRSAのみをサポートします。相互運用性が重要な場合は二重証明書を発行します。
引き続きSHA-1で署名する。 SHA-1はS/MIME 4.0で廃止されています。モダンクライアントはSHA-1署名を拒否するか、警告を表示します。最低でもSHA-256を使用します。

配信可能性への影響

S/MIME 3.2と同じ考慮事項。 S/MIME暗号化はメッセージコンテンツを中間サーバーとスパムフィルターに対して不透明にします。これは受信ゲートウェイがポリシーコンプライアンスのためにコンテンツを検査できない場合、配信の問題を引き起こす可能性があります。
ECでより小さい署名。 楕円曲線署名はRSA-2048署名のおよそ1/10のサイズです。大量署名メールでは、これは帯域幅とメッセージサイズを有意に削減します。
エンタープライズゲートウェイ互換性。 多くの企業メールゲートウェイはコンプライアンススキャンのために周辺でS/MIMEを復号化し、受信者のために再暗号化します。S/MIME 4.0アルゴリズムを展開する場合、ゲートウェイがそれらをサポートすることを確認します。
規制上の利点。 GDPR、HIPAA、または財務規制の対象となる組織は、認証されていない暗号化（AES-CBC）ではなく、認証付き暗号化（AES-GCM）を必要とするかもしれません。S/MIME 4.0コンプライアンスは規制対象の事業体とのビジネス遂行の要件になる可能性があります。