トランスポートTLSとS/MIMEさまざまな問題を解決します。 TLS 、隣接するシステム間の接続を保護します。 S/MIMEメッセージのコンテンツに署名または暗号化できるため、メッセージとともに保護が適用されます。それが本当にエンドツーエンドであるかどうかは、電子メール クライアントにセキュリティ アイコンが表示されるかどうかだけではなく、鍵がどこに保管され、どこで署名や復号化が行われるかによって決まります。
コントロールを選択する前にパスを描画します
参考文献: RFC 3207 §1, RFC 8551 §1.
アリスのクライアントから彼女の送信サービス、次に送信ゲートウェイ、受信者のMXサービス、ボブのメールボックスとクライアントへのメッセージを使用します。各ネットワーク ホップは独自のTLS接続とポリシーを持つことができます。ドメイン間SMTP TLS接続が成功しても、それだけでは送信、内部リレー、メールボックス アクセス、ストレージ暗号化については何もわかりません。
TLSを終了する各サーバーでは、個別に暗号化されない限り、通常のメッセージ コンテンツを処理できます。したがって、フィルター、ゲートウェイ、侵害されたエンドポイントは機密境界の一部のままになります。 MTA-STS およびSMTP DANE 該当するルートのトランスポート認証と適用を改善します。どちらもホップバイホップTLSメッセージ暗号化に変換しません。 RFC 8461セクション 2.
署名と暗号化を区別する
参考文献: RFC 8551 §3.3, RFC 8551 §3.4, RFC 8551 §3.5, RFC 8551 §3.7, RFC 8551 §4.
S/MIME signed content provides integrity and signer-authentication evidence according to certificate trust and validation.署名だけではメッセージは隠蔽されません。 S/MIME enveloped content encrypts protected material for recipients whose keys can decrypt it; encryption alone is not equivalent to a verified author signature. RFC 8551 §3.4 で説明されているように、認証されたエンベロープ コンテンツは、発信元を証明することなく機密性とデータの整合性をさらに提供できます。 Do not equate that protection with a verified author signature.ワークフローでは、署名と暗号化を組み合わせることができます。 RFC 8551セクション 2 および 3.
Keys and certificate identities need lifecycle management.誰が秘密鍵にアクセスできるか、受信者が証明書を取得する方法、期限切れまたは紛失した鍵がアーカイブされたメールへのアクセスにどのような影響を与えるか、およびどの回復プロセスが許可されているかを確認します。これらは運用設計の問題であり、秘密キーを広範囲に配布したり、ドメイン認証チェックが証明書の検証に代わると仮定したりする理由ではありません。
同じメッセージの脅威を比較する
参考文献: RFC 8551 §3.1, RFC 8551 §6.
適切に暗号化されたSMTPホップを受動的に観察するために、 TLSそのホップ上の送信バイトを保護します。 For a gateway administrator reading mail after TLS termination, hop encryption provides no content-confidentiality barrier. Client-side S/MIME encryption may protect the encrypted body from that gateway if it does not hold a decryption key. The word may matters because some deployments intentionally decrypt at gateways.
For alteration after transport, a valid S/MIME signature can expose changes to the signed content; the fact an earlier TLS connection succeeded cannot. For a compromised recipient client that has the decryption key, neither TLS nor S/MIME encryption prevents the client from accessing plaintext.可視のルーティング メタデータと外部ヘッダーについては、完全な隠蔽を約束するものではありません。適用範囲はメッセージのパッケージ化と実装によって異なります。
非公開レビューの証拠には、これらの境界を説明する明示的な経路と脅威のマトリックスが含まれています。 It is a design model, not a cryptographic interoperability test.地元の TLSA パッケージ内の他の場所の証明書フィクスチャはS/MIME署名または復号化の動作を確立しません。
コントロールと受け入れ証拠を一緒に選択する
参考文献: RFC 8551 §4, RFC 8551 §6.
TLSの適用が必要なホップ、署名または暗号化が必要なコンテンツ、および復号化が許可される場所を指定します。制御された環境で、代表的なクライアント、添付ファイル、転送、およびアーカイブへのアクセスをテストします。ワークフローが特定のルート全体で署名や機密性を保持していると主張する前に、肯定的な検証と否定的なコンテンツ変更ケースの両方を保持してください。
保つ フィッシング ビジネスプロセスクレームは分離されています。特にアカウント侵害後は、認証された送信者または署名されたメッセージに、誤ったまたは不正な支払い要求が含まれる可能性があります。結果として生じるアクションについては、独立した検証が引き続き必要です。このガイドでは、 S/MIMEメッセージの署名、暗号化、配信、または復号化は行われていません。その証拠は検査可能な制御と脅威のマトリックスであり、クライアントの相互運用性は明示的に保留中の受け入れタスクのままです。