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

Question

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

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

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

谢谢!

以供参考:

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

Answer 1

CAdES的一个优点是它通常会导致较少的互操作性问题,主要是因为XML-DSig标准允许很多选项,XSLT,XPointer Framework和各种形式的XML规范化等等.如果您只需要处理严格的DER编码签名(虽然您需要处理BER编码时图片会发生变化),CAdES的要求会更低.

CAdES相对于XAdES的另一个优点是,您需要在大型数据块上生成"附加"签名,即​​您希望结果是包含原始数据和签名的单个数据块.附加的CAdES签名的等价物(即原始输入数据存储在CMS结构的EncapContentInfo元素中)是包络签名.如果您需要生成这种签名,那么在处理大型输入数据时,如果您的XAdES实现基于DOM(我知道的那些),您很可能会遇到问题 - 您的机器最终会耗尽记忆

性能将是CAdES受到青睐的另一个论点.虽然CAdES的消息摘要计算通常直接在输入数据的原始字节上完成,但在XML文档上计算的XML签名涉及一些开销,例如评估XPath表达式,XSLT转换,Base64 en-/decode和Canonicalization. ...理论上甚至不止一次应该有几个变形元素.

如果您正在构建一个存档系统,用于需要存储大量签名的签名的长期验证,CAdES也将是首选格式,因为它与文本XAdES格式相比具有紧凑性.

Answer 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。

我还在 Windows 上用 C++ 实现了它们，请在此处和此处查看我的完整工具集。