xml – 有没有理由在XAdES上使用CAdES进行高级电子签名？
发布时间：2020-12-16 23:02:36 所属栏目：百科 来源：网络整理
导读：我无法找到任何理由为什么有人愿意在面向XAdES的应用中实施面向CAdES的电子签名软件解决方案. 互联网上有更多开放的库和实施案例以及XAdES的例子,但我不相信这就是为什么人们决定在CAdES上使用XAdES的原因. 是因为XAdES是面向XML的,软件开发人员喜欢与XML相
|
我无法找到任何理由为什么有人愿意在面向XAdES的应用中实施面向CAdES的电子签名软件解决方案.
互联网上有更多开放的库和实施案例以及XAdES的例子,但我不相信这就是为什么人们决定在CAdES上使用XAdES的原因. 是因为XAdES是面向XML的,软件开发人员喜欢与XML相关的任何东西吗？是否有任何情况下CAdES完全是使用XAdES的最佳选择？ 谢谢！ 以供参考： > CAdES是高级形式的CMS / PKCS#7(支持时间戳) 解决方法
CAdES的一个优点是它通常会导致较少的互操作性问题,主要是因为XML-DSig标准允许很多选项,XSLT,XPointer Framework和各种形式的XML规范化等等.如果您只需要处理严格的DER编码签名(虽然您需要处理BER编码时图片会发生变化),CAdES的要求会更低.
CAdES相对于XAdES的另一个优点是,您需要在大型数据块上生成“附加”签名,即??您希望结果是包含原始数据和签名的单个数据块.附加的CAdES签名(即原始输入数据存储在CMS结构的EncapContentInfo元素中)的等价物是Enveloping Signature.如果您需要生成这种签名,则很可能会遇到问题当处理大型输入数据时,如果您的XAdES实现是基于DOM的(我知道的那些) – 您的机器最终会耗尽内存. 性能将是CAdES受到青睐的另一个论点.虽然CAdES的消息摘要计算通常直接在输入数据的原始字节上完成,但在XML文档上计算的XML签名涉及一些开销,例如评估XPath表达式,XSLT转换,Base64 en- / decode和Canonicalization. …理论上甚至不止一次应该有几个变形元素. 如果您正在构建一个存档系统,用于需要存储大量签名的签名的长期验证,CAdES也将是首选格式,因为它与文本XAdES格式相比具有紧凑性. （编辑：李大同） 【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容! |