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

Question

我还没有找到任何理由来解释为什么有人更喜欢实现面向CAdES的电子签名软件解决方案而不是面向XAdES的解决方案。

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

这是因为XAdES是面向XML的，软件开发人员喜欢任何与XML相关的东西吗？有什么情况下CAdES是XAdES上最好的选择吗？

供参考：

• CAdES是CMS/PKCS#7的高级形式(支持时间戳)
• XAdES是XML-DSig的高级形式(支持时间戳)。

Answer 1

CAdES的一个优点是它通常导致较少的互操作性问题，因为XML标准允许许多选项，包括XSLT、XPointer框架、XPointer等等。如果只处理严格的DER编码签名(一旦需要处理BER编码，图片就会发生变化)，那么CAdES就不会那么苛刻了。

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

性能将是支持CAdES的另一个论点。CAdES的消息摘要计算通常直接在输入数据的原始字节上进行，在XML文档上计算的XML签名涉及许多开销，如XPath表达式的计算、XSLT转换、Base64 en/解码和规范化，以及潜在的几个转换元素。

如果您正在构建一个用于长期验证签名的归档系统，其中存储了大量签名，CAdES是首选格式，因为它与文本XAdES格式相比具有简洁性。

Answer 2

CAdES优于XAdES：

• 减去要实施的备选方案
• (方式)更容易核实
• 可以处理任何类型的数据，包括XML。
• 对ASiC来说更容易
• Windows更健壮地构建它。
• 不需要复杂的规范化
• 可与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++ for Windows中实现了它们，检查这里和这里以获得完整的工具集。