是否有任何理由使用 CAdES 而不是 XAdES 进行高级电子签名？答案

【问题标题】：Is there any reason to use CAdES over XAdES for advanced electronic signatures?是否有任何理由使用 CAdES 而不是 XAdES 进行高级电子签名？
【发布时间】：2011-09-17 22:08:18
【问题描述】：

我无法找到任何理由说明为什么有人更愿意实施面向 CAdES 的电子签名软件解决方案而不是面向 XAdES 的电子签名软件解决方案。

互联网上有很多 XAdES 的开放库和实施案例和示例，但我仍然认为这不是人们决定使用 XAdES 而不是 CAdES 的原因。

是因为 XAdES 是面向 XML 的，而软件开发人员往往喜欢任何与 XML 相关的东西吗？在任何情况下，CAdES 是完全优于 XAdES 的最佳选择吗？

供参考：

CAdES 是高级形式的 CMS/PKCS#7（支持时间戳）
XAdES 是高级形式的 XML-DSig（支持时间戳）

【问题讨论】：

标签： xml content-management-system pkcs#7 xml-signature electronic-signature

【解决方案1】：

CAdES 的一个优点是它通常导致较少的互操作性问题，因为 XML-DSig 标准允许许多选项，包括 XSLT、XPointer 框架、XML 规范化等等。如果只处理严格 DER 编码的签名，CAdES 的要求会更低（一旦需要处理 BER 编码，图片就会改变）。

在需要在大数据块上生成“附加”签名的情况下，CAdES 的性能优于 XAdES（您希望结果是包含原始数据和签名的单个数据块）。附加的 CAdES 签名（原始输入数据存储在 CMS 结构的 EncapContentInfo 元素中）的等效项是 Enveloping Signature。如果您需要生成这种签名，那么如果您的 XAdES 实现是基于 DOM 的（我所知道的是），那么在处理大量输入数据时您很可能会遇到问题 - 您的机器最终会用完内存。

性能将是另一个偏爱 CAdES 的论据。 CAdES 的消息摘要计算通常直接在输入数据的原始字节上完成，在 XML 文档上计算的 XML 签名涉及很多开销，例如 XPath 表达式的评估、XSLT 转换、Base64 编码/解码和规范化，可能还有几个 Transform 元素。

如果您正在构建用于长期验证签名的存档系统，其中存储了大量签名，则 CAdES 是首选格式，因为它与文本 XAdES 格式相比更紧凑。

【讨论】：

感谢您的精彩回答！我们将针对您提到的不同场景进行更多调查。

【解决方案2】：

CAdES 优于 XAdES：

实现的选项更少
（方式）更容易验证
适用于任何类型的数据，包括 XML
ASiC 更容易
Windows API 构建起来更加健壮
无需复杂的规范化
可与 S/MIME 一起使用
允许多个签名
在 PAdES 中使用
更快

XAdES 优于 CAdES：

签名的 XML 文件仍然可以被不知道加密的应用程序读取
一次可以对多个元素进行签名
您不需要 ASN.1 编译器

我会使用 XAdES 的唯一原因是第一个，个人意见。但是，不知情的应用程序可能会修改文件，导致签名无效。此外，使用 *AdES 类型意味着您希望与欧盟法规兼容，这通常意味着使用 PAdES 签名的 PDF 文档。当您只想签署电子邮件时，CAdES 并不是很有用，因为大多数 S/MIME 客户端都没有对其进行验证。 AdES 的东西是欧洲法律，所以没有多少美国应用程序知道它。

此外，这些表单不仅仅是带有时间戳的旧表单，还有很多插件。请参阅https://www.w3.org/TR/XAdES/ 和https://www.secureblackbox.com/kb/articles/8-CAdES.rst。

我还在 C++ 中为 Windows 实现了它们，请查看 here 和 here 以获取我的完整工具集。

【讨论】：