<Expiration>04/02</Expiration>
</CreditCard>
</PaymentInfo>
可能还有必要加密文档中的所有信息，清单 4 演示了这点。
清单 4. 隐藏了全部内容的加密文档
<?xml version='1.0'?>
<EncryptedData xmlns='http://www.w3.org/2001/04/xmlenc#'
Type='http://www.isi.edu/in-notes/iana/assignments/media-types/text/xml'>
<CipherData><CipherValue>A23B45C56</CipherValue></CipherData>
</EncryptedData>
CipherData 可以封装，也可以引用原始加密数据。在第一种情况下，CipherValue 元素的内容显示原始数据，而在第二种情况，使用 CipherReference 元素，这包括了一个指向加密数据位置的 URI。
规范的 XML
对应用了密码散列算法的消息进行最轻微的更改也会产生不同的值。这为消息完整性方面提供了信任，并适于通常用法，但是也引入了进一步的复杂性 — 两个 XML 文档虽然在逻辑上相等，但可能在确切文本比较中不同。象行定界符、空标记、在属性中使用十六进制而不是名称以及在特定情况下存在注释或注释变体这样的事情都可以成为文档的逻辑结构不受影响而实际彼此不同的实例。规范的 XML 规范描述了一种生成文档的物理表示（也成为范式）的方法，该范式解释允许的变体，以便如果两个文档具有同一范式，则认为两个文档在给定应用程序上下文中是逻辑相等的。
对于加密、特别是数字签名来说，这尤为重要，因为很明显，逻辑上相同的文本变体不应该表示文档的完整性及其发送方的认证是可疑的。用不同工具（譬如，解析器）生成不同文本（并因而生成不同消息摘要）进行处理时也可能发生这样的事。因此，在生成签名和验证计算期间，应该在范式上进行消息摘要。如果摘要匹配，这将确定：即使文本形式可能不同，它们在其上计算的范式也匹配。
如果您对本文有任何疑问或者建议，请到讨论区发表您的意见:
>>
论坛入口 <<
上一篇：启用 XML 安全性(1) 下一篇：启用 XML 安全性(3)
【文章评论】
【收藏本文】
【推荐好友】
【打印本文】
【我要投稿】 【论坛讨论】
