是否有理由在XAdES上使用CAdES进行高级电子签名？

Question

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

互联网上有更多开放的库和实施案例以及XAdES的例子，但我不相信这就是人们决定使用XAdES而不是CAdES的原因。

是因为XAdES是面向XML的，软件开发人员喜欢与XML相关的任何东西吗？是否有任何情况下CAdES是直接使用XAdES的最佳选择？

供参考：

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

Answer 1

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

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

性能将是CAdES受到青睐的另一个论点。 CAdES的消息摘要计算通常直接在输入数据的原始字节上完成，在XML文档上计算的XML签名涉及很多开销，例如评估XPath表达式，XSLT转换，Base64 en- / decode和Canonicalization，可能还有几个Transform元素。

如果要构建存档系统以对存储大量签名的签名进行长期验证，则CAdES是首选格式，因为它与文本XAdES格式相比具有紧凑性。

Answer 2

XadES上的CAdES：

• 实施的选项较少
• （方式）更容易验证
• 处理任何类型的数据，包括XML
• 使用ASiC更容易
• Windows API构建起来更强大
• 无需复杂的规范化
• 可以与S / MIME一起使用
• 允许多个签名
• 用于PAdES
• 更快

XadES超过CAdES：

• 未加密的应用程序仍可以读取签名的XML文件
• 可以一次签名多个元素
• 您不需要ASN.1编译器

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

此外，这些形式不仅仅是带有时间戳的旧形式，还有很多附加组件。参见https://www.w3.org/TR/XAdES/和https://www.secureblackbox.com/kb/articles/8-CAdES.rst。

我也已经在Windows的C ++中实现了它们，请检查here和here和here以获取完整的工具集。