CMS AuthEnvelopedData 類型是否提供消息認證？
我正在查看 S/MIME 消息規範 (RFC 8551) 以了解它提供的安全服務。本文件的第 2.4.4 節描述AuthEnvelopedData內容類型（使用同名的 CMS 類型）說：
此內容類型用於將數據機密性和消息完整性應用於消息。 此內容類型不提供身份驗證或不可否認性。
Authenticated-Enveloped-Data CMS 內容類型根據 RFC 5083 使用經過身份驗證的加密算法（例如 AES-CCM 或 AES-GCM）。
經認證的加密算法通常提供數據的機密性、真實性和完整性。那麼為什麼 S/MIME 規範聲明AuthEnvelopedData類型不提供身份驗證？
認證（和不可否認性）是相對於來源的。
像 GCM 和 CCM 這樣的“經過身份驗證”的加密是一種有限的身份驗證形式，可確保成功解密的數據來自進行加密的實體，並且在傳輸過程中沒有被修改（篡改），但它本身並不能告訴您加密者是誰是，只是他們有鑰匙。它使用的環境可能會增加這一點；作為一個常見的例子，TLS（總是在 1.3 中，現在通常在 1.2 中）可以使用 AEAD 算法和只有連接的兩個端點知道的 nonce 密鑰來加密會話數據（至少有一個例外是 IV-aka-nonce部分只有端點知道）；因此，如果一個端點接收到正確解密的數據，並且知道它沒有發送該數據，則數據必須來自另一個端點並且未被篡改。
S/MIME 和 CMS 消息可以以無限數量的步驟與任何人傳輸，儘管簽名消息只能由具有相關私鑰的實體創建（並且應該只有一個，因為不應共享私鑰）和類似封裝的消息（具有通常使用的 RecipientInfo 類型）只能使用只有一個實體應該擁有的私鑰“打開”（解密）。AuthEnveloped 變體，使用 AEAD 加密，保證密文沒有被篡改——不像傳統加密，沒有外部簽名或其他完整性措施，有時可以以一種導致未檢測到的攻擊者期望的明文更改的方式完成——但是它沒有說明誰數據來自。世界上任何擁有您的（公共）證書的人都可以向您創建有效的 AuthEnveloped 消息。由於您不知道發件人是誰，因此拒絕是沒有意義的——沒有被拒絕的責任斷言。