邮件内容级签名加密（S/MIME）怎么和国密算法结合？

传输层加密只在链路上有效。邮件经过发送方 MTA、中转节点、接收方网关、邮箱存储，在每一个节点上都会以明文形态落地一次。内容级签名与加密作用于邮件本体，覆盖中转与静态存储全过程。

两者解决的是不同威胁：传输层防的是链路窃听与降级；内容层防的是中间节点泄露、存储泄露，以及提供发件人不可否认。

判定条件：凡是合规上要求「抗抵赖」或「端到端保密」的邮件业务，传输层加密不足以满足，必须上内容层。

RFC 5652 Cryptographic Message Syntax (CMS) 定义了签名数据（SignedData）与封装加密数据（EnvelopedData）的通用语法，RFC 8551 S/MIME Version 4.0 Message Specification 规定了它们在邮件 MIME 结构中的承载方式。国密化的替换点非常明确：

• 摘要算法标识：SignedData 中的 digestAlgorithm 使用 SM3。
• 签名算法标识：signatureAlgorithm 使用 SM2 签名。
• 内容加密算法：EnvelopedData 中的 contentEncryptionAlgorithm 使用 SM4，需明确工作模式。
• 密钥封装：recipientInfo 中使用 SM2 对内容加密密钥做加密。

要点：MIME 外层结构与封装方式不变，变的只是算法标识。这意味着不支持国密的接收方仍能识别出「这是一封加密/签名邮件」，只是无法验签或解密——而不是把邮件解析成乱码。

证书需符合 RFC 5280 Internet X.509 Public Key Infrastructure Certificate and CRL Profile 的基本结构，证书的获取与处理规则见 RFC 8550 S/MIME Version 4.0 Certificate Handling。国密场景下需要注意：

• 一人两证：签名证书私钥由本人独占（保证不可否认）；加密证书密钥对由密钥管理机构产生并托管（保证可恢复）。
• 密钥用途扩展必须正确：签名证书不应带密钥加密用途，反之亦然。配错会导致部分客户端拒绝使用。
• 邮件地址绑定：证书中的邮件地址须与实际发件地址一致，否则接收方校验会失败。

这是内容级加密部署中最现实的问题：邮件正文与附件加密后，边界侧的反病毒、反钓鱼、内容合规检查全部失效。而等保的区域边界要求恶意代码与垃圾邮件防范必须存在。

三种可选安排及其判定：

1. 检查点前移到客户端：在加密前、解密后于终端侧检查。适用于终端可控的场景。
2. 设立受控解密检查点：在边界处以托管的加密私钥解密、检查、再重新加密。该点位本身成为高价值目标，必须严格管控并纳入审计。
3. 按业务范围限定使用：仅对特定敏感业务启用端到端加密，其余流量保持可检查。多数组织的现实选择。

不可接受的做法是「先上加密，检查的事以后再说」——这会同时造成安全缺口与合规不符合项。

加密邮件同样要满足归档与可取证要求。若加密私钥仅存在于个人终端，人员离职或设备损坏后历史邮件将永久不可读——这在合规上是不可接受的。

可操作安排：加密密钥对由密钥管理设施托管并备份；归档系统持有解密能力但解密操作必须走审批并全程审计；签名密钥不托管，以维持不可否认性。「加密密钥托管、签名密钥不托管」是兼顾合规与抗抵赖的标准分界。

1. 先只签名不加密：全员部署签名，接收方可验真，风险极低，且立刻带来反钓鱼收益。
2. 再对内部特定群组启用加密：两端可控，便于验证密钥管理与归档流程。
3. 最后扩展到外部往来：需先与对端交换证书并确认算法支持情况。

算法标识与证书规范的现行要求，请以国家密码管理局与密标委发布的文件为准。