行业新闻与博客

1 月，行业领导者采用了新的 S/MIME 基本要求，旨在提高全球范围内公开信任的电子邮件签名证书的颁发和管理方式的一致性。以下是您需要了解的重点……

异常安全报告称，十分之九 (92%) 的调查受访者表示，他们在过去一年中经历过一次或多次与电子邮件相关的安全事件。其中许多问题，包括网络钓鱼商业电子邮件泄露 (BEC) 攻击，通常可以通过教育和安全措施来预防。

• 提供网络意识培训，
• 要求员工对所有出站电子邮件进行数字签名，并使用 S/MIME 数字证书对包含敏感数据的电子邮件进行加密。

这些电子邮件签名证书是使数据签名和加密成为可能的小型数据文件。但多年来，在管理这些证书的颁发和管理方式方面，该行业有点像狂野西部。现在，随着行业管理机构之一 CA/ 浏览器 (CA/B) 论坛签署了一套名为基准要求 (BR) 的新标准，以提供有关 S/MIME 证书的指导，情况正在发生变化。

我们始终保持警惕，让您了解行业内的重大变化。在深入探讨这些新基准要求的更多技术细节之前，本文将首先介绍需要了解的信息。

让我们讨论一下。

发生了什么：行业领导者采用新的全球 S/MIME 证书标准

2023 年 1 月 1 日，CA/B 论坛通过了一项投票，该投票构成了针对公开信任的电子邮件安全证书的第一个基线要求（版本 1.0.0）的基础。这些要求是颁发和管理公众信任的电子邮件签名证书或所谓的 S/MIME 证书的基础。

这些标准经过精心设计，不会破坏现有部署。

什么是 S/MIME？

如果您想知道，S/MIME 或代表安全多用途 Internet 邮件扩展的内容是一种广泛使用的增强电子邮件安全性的技术协议。特别是，它用于使用 S/MIME 证书和非对称加密技术传输数字签名和加密的电子邮件（这意味着有一对公私对数学相关的密钥加密和解密数据）。

S/MIME 证书是数字证书（即小数据文件），组织和个人可以将其安装到他们的设备上以声明他们经过验证的数字身份。正确安装后，它们用于对所有出站电子邮件进行数字签名。如果发件人和收件人都使用电子邮件签名证书，则它们也可用于发送加密邮件。发件人使用收件人的公共证书加密邮件，收件人使用他们的私钥解密邮件。

我们不会得到比这更多的技术。如果您想了解有关 S/MIME 的更多信息，请查看我们关于该主题的另一篇文章。

这些基本要求何时生效

CA/B 论坛投票最初由该论坛于 2022 年 11 月 1 日批准。但是，与其他全行业协作流程一样，新标准的推出并非一蹴而就。这需要时间才能在全球范围内被整个行业采用。这就是 S/MIME BR 将于 2023 年 9 月 1 日生效的原因。

S/MIME 基本要求的快速解释

S/MIME 基线要求是旨在确保正确颁发这些数字证书并满足既定行业安全标准的标准。这份 84 页的文档是由一个专门的 S/MIME 证书工作组编写的，该工作组由 50 个证书颁发机构 (CA)、技术公司、Web 浏览器和其他相关方组成。

这些要求旨在为如何颁发和管理这些证书设定最低标准。他们还旨在向公众信任的 CA（或其指定的注册机构）提供有关其证书实践声明 (CPS) 中应包含哪些内容的信息。

为什么要费心做这一切？这是为了向电子邮件收件人提供“合理保证”，即 S/MIME 证书中标识的主题（即电子邮件发件人）实际上可以控制他们发送邮件的域或邮箱。这一切都归结为使用经过验证的数字身份来建立数字信任。

这些基本要求适用于谁

S/MIME BR 适用于公开信任的 CA，如 DigiCert 或 Sectigo，以及使用这些证书在其网络之外发送电子邮件的组织。如果您的组织颁发或请求包含以下两项的 S/MIME 证书，那么您就是这些标准的目标受众：

• id-kp-emailProtection (OID: 1.3.6.1.5.5.7.3.4)的扩展密钥使用 (EKU)
• RFC822Name的主题备用名称 (SubjectAlt) 字段信息或id-on-SmtpUTF8Mailbox类型的 otherName 条目

以下是 SAN 字段信息在电子邮件签名证书中的外观的快速示例：

如果您运行内部私有 CA，并在其中颁发严格供内部使用的 S/MIME 证书，那么您可能会很高兴知道这些基线要求不适用于您。它们仅适用于面向公众的公钥基础设施 (PKI) 和在外部使用这些证书的组织。

为什么这很重要？默认情况下，任何操作系统或邮件客户端都不会信任内部 S/MIME 证书；您必须手动将您的私人 CA 添加到您的操作系统或邮件客户端的信任库中，以便将它们识别为有效和可信的。另一方面，对于由公开信任的 CA 颁发的 S/MIME 证书，默认情况下它们将受到信任，因为这些证书链接回的根 CA 已经在信任库中。  

为什么需要这些新的行业标准

需要这些准则是因为证书颁发机构、注册机构 (RAS) 和公司颁发、部署或管理证书的方式存在重大差异。还记得我们之前提到的狂野西部吗？令人担忧的是，这些不同的（即不一致的）实践和流程可能会导致安全风险和问题。

在发布任何类型的公开可信数字证书时，一致性是关键——SSL /TLS 证书、代码签名证书、文档签名证书等。

为了更多地讨论这个问题，我们联系了 DigiCert 全球治理、风险和合规高级经理 Stephen Davidson ，他是 S/MIME 证书工作组 (SMCWG) 的主席，看看他有什么说：

“虽然 S/MIME 的‘技术管道’在定义协议的一组 RFC 中得到了很好的定义，但从来没有一套行业范围的最低要求来管理证书颁发机构验证证书持有者身份的方式，或者他们控制电子邮件地址，以及布置 S/MIME 中使用的证书配置文件。” 

戴维森将新建立的 S/MIME BR 描述为证书颁发者和证书消费者之间的协作成果。目标？设置护栏，使电子邮件用户相信，通用做法正在按照整个行业的既定标准正确实施。企业、WebTrust 和 ETSI 审计社区以及政府 PKI 专家等重要用户组针对这些要求提供了额外的反馈。

但这一切真的值得吗？这就是目标。

“我们已经看到 CA/ 浏览器论坛的 EV 指南和 TLS 基线要求在提高 webPKI 的合规性和一致性方面取得的成功，并且相信新的 S/MIME 基线要求将同样改善安全消息传递生态系统。”

基本要求涵盖的内容

好吧，现在是时候看看引擎盖下了。这些要求涵盖与电子邮件签名证书相关的各种主题和主题，包括：

• 适当和不适当的证书使用
• 主题身份验证以确保主题真正控制与证书关联的电子邮件域或邮箱
• CA 和 / 或 RA 的主题身份验证要求和流程，以确保主题的身份是真实的（即，验证 Casey Crane 确实是 Casey Crane，我不是冒名顶替者发送消息）
• 颁发 CA 和证书主体的操作实践和安全控制
• 审计和合规相关的注意事项

同样，第一个版本是一个 84 页的文档；正如您所想象的那样，在整个 BR 中还有许多其他具体的谈话要点，我们没有时间在这里讨论。如果您想了解更多细节，请务必查看 CA/B 论坛的 S/MIME 基本要求网页上的新标准文档。

BR 确定四种类型的 S/MIME 证书

当我们谈论不同类型的电子邮件签名证书时，我们通常会从验证的角度（个人验证、组织验证和扩展验证）讨论它们。新的 BR 采取了不同的方法，扩展了列表并根据证书配置文件进行了一些不同的分解。

在第 1.2 节“文档名称和标识”中，BR 根据证书主题定义了这四种类型的证书配置文件：

这些证书类型中的每一种都被进一步定义为三个生成配置文件之一：

1. 遗产。此配置文件仅适用于现有的 S/MIME 证书以提供灵活性，并将在未来的 S/MIME BR 版本中弃用。这一代密钥对使用期限最长为 1185 天（约 3.25年）。S/MIME 工作组讨论了最终为遗留配置文件发布特定计划弃用日期的目标，但这是必须在未来版本的基线要求中解决的问题。
2. 多用途。顾名思义，它的用途广泛，因为它具有额外的扩展密钥使用 (EKU) 选项并且可以允许交叉使用。例如，它也可以用于文档签名目的，而不是严格意义上的电子邮件签名证书。它的最长有效期为 825 天，即 2.25 年多一点。
3. 严格的。顾名思义，这一代是最严格的，并作为 S/MIME 证书的长期目标配置文件，仅支持id-kp-emailProtection以及其他限制。此配置文件类型的最长有效期为 825 天。

基线要求是否适用于所有这些类别？完全正确。当然，基准要求还涵盖了许多其他主题……请务必查看我们在文章开头链接到的 BR 文档，以了解有关标准其他方面的更多信息。

创建新的全球行业标准并不容易（但必须有人去做）

可以想象，创建如此有影响力的标准并非没有挑战，但戴维森说，领导该倡议的小组齐心协力使其发挥作用：

“ S/MIME 证书工作组 (SMCWG) 面临的一个挑战是量化 S/MIME 世界中的现有实践，它的实现比 TLS 中看到的更加多样化，企业 RA 向公司员工颁发证书的主导地位，以及跨电子邮件 / 身份验证和文档签名的多用途证书的广泛使用。SMCWG 的任务是避免不必要地破坏合理的遗留实践；我们相信 S/MIME BR 成功地将 S/MIME 发布纳入可审计的框架，并提供了随着时间的推移朝着更明确的“严格”政策和实践迈进的路线图。”

但是创建行业标准并不是一劳永逸的事情。S/MIME 证书工作组刚刚发布了 S/MIME 基线要求的第一版，但将来会有新版本来解决更多的想法和问题。但这包括哪些类型的考虑因素？

“SMCWG 正在探索有助于扩展 S/MIME 安全性的新想法，包括验证电子邮件域控制的新方法，以及将证书颁发机构授权 (CAA) 等想法扩展到 S/MIME。”

最后的想法是

我们希望您发现本文内容对您有用。