XML数字签名标准（XML Digital SignatureStandard）确立了XML在非安全网络（如因特网）上有效的自签方法。这项工作不需要一个已建立的PKI，而可能需要使用可信的XML服务器进行认证。因此，每家企业不得不估计外购这一日益关键的商业功能的潜在安全性风险。

　　简介

　　XML签名有一个W3C候选方案，它看上去非常象最终方案，但这项工作仍处于进展中，并在本文写作时还未正式提升到“草稿标准（Draft Standard）”阶段。“因特网工程工作组（Internet Engineering Task Force (IETF)）”称它为RFC 3075。据这个候选方案的作者列表上的作者（包括W3、MIT和Microsoft的人员）判断，因特网行业显然正在严肃地考虑这一问题。

　　概述

　　依照RFC，设计的XML签名带有多个目标，可提供“对任何数据类型的完整性、消息认证、和／或签名者认证服务， 无论是在包括该签名的XML内部还是在别处。”（我加粗了后半句话是因为如果采用并实现候选方案，它对于因特网的工作方式将有重大意义。稍后将详细说明。）这些目标自然雄心勃勃，并且如果放在上下文中考虑，涉及面也很广泛。这些签名及其相关过程有一个终极目标，通过使用XML，为Web提供基于服务器的缺省基本安全性服务。

　　然而，作者们只理解其工作的一部分。候选方案包含这样一段：“XML签名……没有规范地指定如何将密钥与个人或社会团体相关联，也没有指定正在引用并签名的数据的含意。 因此，虽然这个规范是安全XML应用程序的重要组成部分，但它本身不足以处理所有应用程序安全性／信任事宜，特别在有关将已签名的XML（或其它数据格式）用作人与人之间通信和协议的基础方面。这种应用程序必须指定附加密钥、算法、处理和再现需要。”简而言之，作者们正在告诫人们，不要将这项工作视作技术上的万能药；必须在其它安全性措施中使用它。这一点很明智，但回避了XML幕后是什么这个实质问题。

　　在规范中没有涉及的内容

　　这里还有一个隐含的假设，作一些检验就会发现这相当明显。XML既基于Web又基于服务器。与Java的“无需带宽，装入servlet”方法相反，它是一种瘦客户机方法。因此，XML签名将使用Web（通过XML中的URL）来找出编码或解码事物的方法。 可以从语法上确切地指定它如何使用Web（随后的技术讨论中将进行演示），但这种讨论忽略了要使用什么URL的实质问题。即，如果签名需要因特网资源来完成其操作，那么谁将提供这些资源呢？如果这种签名成为消息和事务认证所广泛使用的“信号灯”，则XML代码中所指向的任何一个URL都可以成为认证服务的实际标准。

　　但不仅如此。真正的认证服务的使用最有可能出现在Web购物中；而不是出现在象安全电子邮件这类应用中。贸易商想要知道他从客户那里接收到的订单是否有效，所以将坚持某种形式的可接受认证。这种问题首先由使用安全网络进行操作的“电子数据交换（Electronic Data Interchange(EDI)）”系统解决。在不可靠的因特网上，先前解决过的相同的操作问题仍然存在。XML签名过程打算以清扫方式处理这一问题，但这种清扫是问题的一部分。这种少有人知的候选方案将方法种子引入其中，使一些公司垄断因特网认证服务。

　　让我假定一种情况。设想某一商业现货供应（Commercial Off The Shelf(COTS)）软件公司决定成为认证服务，所有事情必须先通过这个认证服务才能完成。再进一步假定这家COTS的专用操作系统可以在大多数研究中的已部署系统上找到。然后，COTS供应商生产出其OS的Xtra专用版，它包含了将XML签名（和仅XML签名）用于安全性的客户机。所有XML代码都指向该供应商的服务器以提供信息，这有点象非公用的PKI基础结构。这种客户机广泛用于认证，因为这种OS被广泛使用，所以很容易将它设置为缺省值。另外，上述的制造商将它作为缺省安全性机制嵌入其流行的“免费”浏览器。

　　再加些点缀，假设每次这种客户机将供应商的服务器用于认证时，供应商就开始向某人（可能是贸易商，也可能间接地是客户）收取费用。瞧!垄断和收入同流合污了。

　　现在，在诚心诚意地使用了这些安全性服务后，贸易商可能会发现这些服务实际上并没有解决根本问题 ― 即信用卡公司的“退费（chargebacks）”。这些退费问题 ― 人们承认他们与贸易商有协议或合同，但他们声称贸易商没有按承诺执行部分或所有方面（象没有交货、订单被取消或其它一些原因） ― 是信用卡发行者商业模型的一部分，并且超出了XML签名规范的作用范围。确实，在美国，Fair Credit Billing Act（15 U.S.C. 1666-1666j）保护客户与发行银行就帐单的正确性（包括商品／服务的数量、总金额、时间和交付／接收）进行争论的权利。不能通过合同否认这些权利。

　　我将总结上一部分。

　　因此，即使有合适的象XML签名这样的方案正在使用，它们可能也不会解决它们应该解决的现实世界的问题。假定可能有贪婪的公司不负责任地胡乱建立因特网垄断业务，那么使用这种技术可以结束这种令人不满的局面。这并不意味着开发者在相当长的时间里一定要使用这种模式以提供兼容性；但也不要认为它只是一个有魔力的咒语。除最大型公司以外的那些公司可能开发独特的认证服务，使用它们可能需要对XML代码稍做改写。真正的问题可能是对制造商提供的XML签名代码的绝对接受。所以，让我们看一下技术规范，同时也要注意理解随着服务的发展可能需要哪些更改。

　　烦人的部分

　　注意，在随后的示例中，可以用您想到的一些专利软件供应商的URL代替W3C地址。这样看上去更现实。下面的讨论很大程度上借鉴了候选规范，因为它们与供应商无关。

　　XML签名的第一个有用的特性是，它可应用于任何类型的数字内容（有时称为数据对象），包括XML。一个XML签名可应用于一个或多个资源的内容。对在签名的同一个XML文档内的数据执行封装式签名，所以对于签名元素本身以外的数据还有一个分离签名。更具体地讲，当前的XML签名规范定义一种XML签名元素类型和一个XML签名应用程序；每一个的一致性要求在文档中分别用模式定义和散文方式指定。

　　签名元素

　　看一下签名元素。首先编摘数据对象摘要（“摘要”是变长数据对象的定长表示，并且使用一个类似SHA-1的算法创建），产生的值（和其它信息）被放在一个元素中。然后，对该元素进行编摘并使用密码签名。签名元素的结构如下（其中，“?”表示0或1次出现，“+”表示1次或多次出现，“*”表示0或多次出现）：

　　清单1
 <Signature>
     <SignedInfo>
       (CanonicalizationMethod)
       (SignatureMethod)
       (<Reference (URI=)? >
         (Transforms)?
         (DigestMethod)
         (DigestValue)
       </Reference>)+
     </SignedInfo>
     (SignatureValue)
    (KeyInfo)?
    (Object)*
   </Signature>
 
　　要仔细考虑的示例

　　考虑一个带一些真实数据的简单示例。以下是XML规范中HTML4内容的分离签名。先给出XML，随后提供每个分别列出的代码行的注释。在讨论中还假设您已经对专用／公用密钥密码术方法有一些经验并且熟悉概念。如果不是这样，可以仔细阅读developerWorks上出色的介绍性文章。

　　清单2
 [s01] <Signature Id=”MyFirstSignature” />
   [s05]   <Reference URI=”http://www.w3.org/TR/2000/REC-xhtml1-20000126/”>
   [s06]     <Transforms>
   [s07]       <Transform Algorithm=
            “http://www.w3.org/TR/2001/REC-xml-c14n-20010315″/>
   [s08]     </Transforms>
   [s09]     <DigestMethod Algorithm=”http://www.w3.org/2000/09/xmldsig#sha1″/>
   [s10]     <DigestValue>j6lwx3rvEPO0vKtMup4NbeVu8nk=</DigestValue>
   [s11]   </Reference>
   [s12]   </SignedInfo>
   [s13]   <SignatureValue>MC0CFFrVLtRlk=…</SignatureValue>
   [s14]   <KeyInfo>
   [s15a]    <KeyValue>
   [s15b]      <DSAKeyValue>
   [s15c]        <p>…</p><Q>…</Q><G>…</G><Y>…</Y>
   [s15d]      </DSAKeyValue>
   [s15e]    </KeyValue>
   [s16]   </KeyInfo>
   [s17] </Signature>
 
　　[s02-12]必需的SignedInfo元素是实际签名的信息。SignedInfo的核心验证由两个必要过程组成：对SignedInfo的签名验证和SignedInfo内部每个Reference摘要的验证。计算SignatureValue所使用的算法也包括在已签名的信息中，而SignatureValue元素在SignedInfo之外。

　　[s03]CanonicalizationMethod标识了一种算法，这种算法被用来规范化SignedInfo元素，然后该元素作为签名操作的一部分被编摘。规范化（Canonicalization）是一种方法，过程使用该方法处理可包含在同一数据元素内部的不同数据流，例如，可以包含两种不同方法来表示文本。规范化是解释原始数据以使空格显示为空格而不显示为ASCII码的方法。

　　[s04]SignatureMethod是用于将已规范化的SignedInfo转换成SignatureValue的算法。这是编摘算法、密钥从属算法和可能的其它算法的组合。为算法名签名以抵抗攻击，该攻击是基于替换成效率更低的算法。要提高应用程序的互操作性，候选方案指定一组需要实现的签名算法，虽然它们的使用任凭签名创建者处理。

　　[s05-11]每个Reference元素都包括摘要方法和对已标识数据对象计算得出的摘要值。它还可能包括产生对摘要操作的输入的转换。数据对象的签名是通过计算其摘要值并对该值的签名进行的。稍后通过引用和签名验证来检查该签名，这些验证将重新创建摘要值并确保它与该数据对象中的内容匹配。

　　[s05]Reference的这个可选URI属性标识要签名的数据对象。在一个Signature中，至多可以对一个Reference省略该属性。（为了确保明确地匹配引用和对象，要强加这个限制。）

　　[s05-08]该标识与transforms一起是签名者提供的描述，其内容有关它们如何获得已编摘形式的已签名数据对象（即，已编摘的内容）。验证者还可能以另一种方法获得已编摘的内容，只要摘要验证这种方法。

　　[s06-08]Transforms是一种可选的处理步骤排序列表，在编摘资源内容之前，对它应用这些步骤。这是解密所需遵循的轨迹。Transforms可以包括如规范化、编码／解码（包括压缩／扩张）、XSLT和XPath等操作。XPath转换有些复杂，因为它们允许签名者派生出省略一部分源文档的XML文档，并将XML树限制为它原来的那样。因此，未包含部分可以更改，而不影响签名有效性。如果不存在Transforms元素，则直接编摘资源内容。应该记住，即使在候选方案中指定了基本缺省设置，还是允许用户指定的转换。

　　[s09-10]DigestMethod是在应用Transforms（如果已经指定它）之后对数据应用以产生DigestValue的算法。DigestValue的签名是将资源内容与签名者密钥绑定的机制。

　　[s14-16]KeyInfo表示用于验证签名的密钥。标识机制可以包括证书、密钥名称和密钥协议算法。KeyInfo是可选的有两个原因。首先，签名者可能不希望向所有文档处理方披露任何密钥信息。为什么总要告诉人家？其次，该信息在应用程序上下文中可能是已知的，并且不需要明确表示。由于KeyInfo在SignedInfo之外，所以如果签名者希望将密钥信息与签名绑定，那么Reference可以容易地将KeyInfo作为签名的一部分标识并将其包括在内。

　　精练的总结

　　XML是作者Donald Knuth的格言“所有计算机问题都可以通过其它途径解决。”的代码化表示。整个XML语法被设计成利用基于Web的重定向服务。虽然可以接受向可信伙伴外包关键商业服务，但在缺省情况下，最好不要将外包作为未来几年中电子商务的重要组成部分。

　　另外，还必须强调对于安全性分析而言，理解XML所使用的上下文（实际正在签名的数据）与代码本身的实际签名同样重要。任何转向其他Web服务商业模型的无意或无知缺省使用，都可能因其使一个组织开放和不安全而终止 – 更不用说潜在的昂贵开销了。知道您在Web上究竟去向何方（以及是谁让您去那里！）目前来说似乎是一门很理智的操作课程。

　　关于作者

　　Larry Loeb为上个世纪主要的计算机杂志“dead tree”写了很多文章，另外，他还是BYTE杂志的顾问编辑和发起WebWeek的资深编辑。作为BIX上的Macintosh Exchange和VARBusiness Exchange的编辑，他从uucp用“bang”寻址的时代（相对!decvax而存在的世界）就开始上网了。他还写了一本关于安全性电子交易因特网协议的书。他的第一台Mac有128K内存。他第一台1130有4K，和他的第一台1401一样。可以通过larryloeb@prodigy.net给他发邮件。