PKCS#7是 RSA Labs 的旧标准，后来作为“信息 RFC”发布。然后，产生了一个新版本，作为“互联网标准”，即获得 IETF 主管部门的批准印章；为此发明了一个新名称：CMS。随后定义了较新的版本：RFC 3369、RFC 3852、RFC 5652。您可以考虑将 CMS 和 PKCS#7 都指定为相同的标准，该标准有多个版本。

CMS (PKCS#7) 是一种用于对任意二进制消息（可能很大）应用加密、签名和/或完整性检查的格式。它可以嵌套。它是一些协议的基础，例如时间戳。它也经常（ab）用作 X.509 证书的容器：该SignedData类型包括一组签名的字段（并且该组可以为空），以及存储任意 X.509 证书的字段，这些证书被认为是对处理对象的人来说是“潜在有用的”。

CMS 名义上是向后兼容的：在各个地方都有版本字段，并且理解某个版本的 CMS 的库应该能够处理来自旧版本的消息；此外，这样的库还应该生成与其他版本兼容的消息，只要考虑到消息内容是可行的。有关示例，请参见第 5.1 节：“版本”字段设置为最小值，考虑到结构中的其他内容，这仍然有意义。

S/MIME是一种用于处理“安全电子邮件”的协议。S/MIME使用CMS 作为加密部分；S/MIME 通过 CMS 添加的内容如下：

• 将 CMS 对象（二进制）编码成可以在电子邮件（基于文本）中毫发无损地传播的规则。这些规则建立在MIME之上，因此基本上是带有一些标头的 Base64。

• 带有“分离签名”的已签名但未加密电子邮件的规范化规则。当一封电子邮件刚刚签名，而收件人可能不知道 S/MIME 时，将签名作为不包含电子邮件数据本身的 CMSSignedData对象发送会很方便；签名作为附件加入到电子邮件中。然后，重要的是要准确定义电子邮件内容如何编码为字节序列以进行签名验证（单个错误编码的位将意味着验证失败）。

• 实际 CMS 对象的限制和使用实践：允许嵌套多少，可能出现什么类型......

• 一些额外的属性，以便发送者可以在他的签名消息中发布它支持的加密算法和类似的元数据。

在某种程度上，我们可以将 S/MIME 视为 CMS 和电子邮件之间的粘合剂。

OpenSSL是一个实现一些协议的库，包括一些版本的 PKCS#7 和 CMS 和 S/MIME。该库还带有命令行工具，这些工具作为命令行界面公开了该库的一些功能。这些工具将不支持库未实现的任何内容（至少可以说相反会令人惊讶），但反之则不然：库可能实现命令行工具无法轻松访问的功能，或根本没有访问权限。

一般来说，命令行工具不是很“严肃”。它们对于一些手动操作或一些脚本很方便，但对于健壮的应用程序，您应该直接使用该库（它是一个 C 库，但许多编程语言都存在绑定）。

命令行工具包括子命令pkcs7和. 令人困惑的是，该命令旨在用于 S/MIME，并支持 S/MIME，结果证明只能作为副产品用作“通用”CMS 支持工具。OpenSSL 开发人员创建新命令是为了支持最新版本的 S/MIME（和 CMS），因为他们认为在不破坏接口兼容性的情况下无法更新命令：如果参数为该命令已针对较新的 S/MIME 版本进行了调整。所以他们只是创建了一个新命令，名为.cmssmimecmscmssmimeopenssl smimecms

从理论上讲，您应该使用openssl cms与 S/MIME 相关的所有内容；但是由于该命令可以访问“新”版本的 S/MIME 和 CMS 的 OpenSSL 支持代码，因此它必然允许您生成完全有效但使用旧的 S/MIME 实现可能不具备的功能的 S/MIME 消息支持。手册页对此进行了简要描述。需要对其他 S/MIME 实现（例如 Thunderbird、Outlook...）进行广泛的测试，以准确了解您可以使用 S/MIME 做什么，而不会让其他人无法阅读您的电子邮件。

OpenSSL 的smime应用程序支持使用 PKCS#7 CMS 的旧 S/MIME 格式，我猜（部分基于standards.txtOpenSSL 的分发）这是S/MIME Version 3。较新版本的cms应用程序支持 S/MIME v3.1 格式的消息，它使用较新的 CMS 规范，因此它仍然是 S/MIME。该pkcs7应用程序仅处理PKCS#7 v1.5 数据，不处理任何较新的 CMS 版本。

我认为命名不太清楚，人们可能会合理地期望该cms应用程序的行为类似于该pkcs#7应用程序。

S/MIME 版本 3.1 规范在RFC 3851中。当前版本的 S/MIME v3.2 在RFC 5751中定义，其中对其进行了描述：

S/MIME 提供了一种一致的方式来发送和接收安全的 MIME 数据。

“PKCS#7 Cryptographic Message Syntax”涉及加密数据的格式（签名、摘要、加密）。“CMS”是当前形式的名称。CMS 规范 (RFC 5652) 的这一部分详细介绍了对先前版本（包括PKCS#7 v1.5 ）的更改。CMS 将自己描述为

CMS 描述了用于数据保护的封装语法。它支持数字签名和加密。语法允许多重封装；一个封装信封可以嵌套在另一个内。

CMS 相对于 PKCS#7 v1.5 的重要变化之一是 CMS 与特定加密算法或密钥管理方案的联系较少（互操作性要求除外），因此它更具可扩展性（例如，参见RFC 3370）。

独立cms应用程序出现在 openssl-1.0.0 中（CHANGES无论如何）。据我了解，CMS数据结构的各个部分都有自己独立的版本细节，没有简单的“1.0”版本控制系统，RFC编号可能是识别实例的最佳方式。再次，相信standards.txtOpenSSL 的 CMS 支持似乎是RFC336实例。

如果您需要创建最兼容的 S/MIME 消息，该smime应用程序可能是最适合使用的应用程序。如果您想创建或处理较新的版本，cms则更好（可能还有更好的机会成功使用更新/更强的加密和摘要算法cms）。RFC 还提到跨版本的 S/MIME 签名不兼容，以及 CMS 和 PKCS#7 之间的不兼容。