在本次独家 developerworks 采访中，xml 数字签名（xml digital signature）先行者 donald eastlake 通过阐明许多有关如何使用该技术的问题来回答有关这一主题的 larry loeb 近期文章。
　　作者的注释：在关于 xml 数字签名的近期文章中，我对它们的实用性和有效性产生了疑问。因为这个提案刚被推荐通过常规使用，所以我确定这是再次核对这个主题的时候了。这次，我与 donald eastlake 进行了交谈，他是 xml 数字签名（xmldsig）rfc 的编辑，也是应该知道有关该主题的人，因为自 90 年代以来他就一直参与了 xml 规范的工作。他还为 ietf 做了多得无法列出的工作。除了在文法上稍做改动之外，基本上未对他的回答做过编辑。向他提出的问题用粗体显示。　　

  　在 xml 数字签名工作组中有许多代表着不同观点的对象群体。一些是“表单（forms）”人，他们的目的是获得把签名插入到文档的能力，即无需更改根元素就由该签名签署了所有或部分文档（除了签名本身）。其他一些是面向协议的人，例如他们想要使用 xml 签名以相对简短而不是极其冗长的用 xml 编码的协议消息的形式来签署特定元素。还有一些人想要构造分离的 xml 签名，这些签名认证了并可能还断言了某些或许根本不是 xml 格式，但很可能是例如二进制可执行文件的远程数据的一些特性。　　

　　为了使这些对象群体都满意，xmldsig 构成得非常灵活。因为这些对象群体中的一些人把他们的观点视为唯一观点而忽略了其他人的观点，诸如您在以上引用的 rfc 上的短语那样的赘述也会包含在需求和规范中，以明确说明将涉及到所有基本方面。　　

　　rfc 还指出此规范对于解决所有应用程序的“安全-信任”问题还不够充分，因此需要额外要求。对于真正安全的 xml 的额外需要您有何预想？　　

　　什么是“真正安全的 xml”？在未定义您试图获得什么样的安全特性以及威胁模型类型的情况下，这个短语毫无意义。xmldisg 提供了一个构件。它是用于将数据密码绑定到密钥的一种灵活机制。　　

　　满足一些特殊应用程序的安全性要求可能意味着指定要使用的特别算法、允许的密钥信息的类型、绑定到签名的语义标记、密钥生成和分发的安全性、包括 tempest 考虑的执行环境的安全性、涉及到的人员的背景检查级别、包括如何响应对安全性的损害的管理程序、解决争论的合法地点的选择，等等、等等、等等。　　

　　为了认证一本匿名政治小册子（例如，什么也没），您需要做的不同于为了认证本地网络内会议室预订而做的（它不是为了全球因特网上多方国际基金划拨系统上操作几百万美元交易的认证）。您出版发行所需的机密性（例如，无）不是普通用户点击踪迹所需的机密性，不是获取有关至今还未宣布的大公司合并信息所需的机密性，并且也不是当您正在为紧急战争订单而分发认证材料时想要的安全性（拥有了该安全性，在理论上您就能发射核导弹）。在不知道您想要的安全性策略以及您想要防御的威胁等情况下，您也就没有可以使用的魔术公式或仙尘（pixie dust）使某些信息“安全”。前面主要评论了数字签名或认证代码的常规特性，并且事实上这与它们是否是 xml、s/mime 还是其它什么形式无关。　　

　　对于为 xml 消息传送而添加（或除去）数字签名，您是如何看的？　　

　　xmldsig 用密码使数据与密钥关联，而且可以提供认证和／或完整性。由于您明确请求消息传送，因此通过 x 方添加的 xml 数字签名后从 x 方发送到 y 方的 xml 消息就能被 y 方认证为来自 x 方并且是完好无损的。这里假设 x 方使用的密钥只为 x 方和其它信任方（如果有的话）所拥有；这只应用于该签名所涉及的消息的数据元素；并且这里假设 y 方信任表示 x 方签署所用的密钥，并且信任和已经实现了所用的密码算法。　　

　　为了采用较少面向消息的观点而更多面向文档的观点，x 可以是 xml 对象／文档的发送方。然后，由 x 添加的签名可以认证并确保那个被发送到无数接收方的文档完整性而不管被签署对象可能已被嵌入到其它 xml 和／或转发的多个跳跃点之类的对象。　　

　　数据传送的目标是要确保消息完整性（也就是，“完好无损”）。现在，xmldsig 能确保以某些供应商告知用户的方式做到“不可抵赖性”（暂时忽略那术语的合法定义）吗？　　

　　是的。为了做到这一点，您必须选择象 rsa 那样的非对称签名算法，使发送方用其私钥签署，使那些想要验证签名的人能够知道并信任相应的公钥（可能将它放入以接收方信任的认证中心签署的签名的 keyinfo 部分发送的证书中）。如果那些都是事实，那么您就拥有了由它们签名的签发者通常所指的不可抵赖性。　　

　　对于大多数目的，您还必须添加一个指出签名“含义”的语义标记（例如，契约协议、证明、对其它签名的反签名、原作者等）。　　部分问题可能在于：为了避免烦琐的措词，xmldsig 使用术语“签名”不仅为了包含上面描述的人们通常理解的“签名”的含义，而且还为了包含对称密钥认证代码或基于生物识别技术的认证或其它任何事物。尽管如此，使用对称密钥认证代码，任何能验证认证代码的人都能伪造一个代码，所以它可能被拒绝，但您可能想要使用这个代码，因为它更加有效。　　

　　如果您只尝试根据机器 a 到机器 b 在因特网上通信完整性来获取信任，并且您控制着这两台机器，那么在向另一方发送消息然后在接收方检查并获取一个认证代码之前，使每台机器添加一个这样的代码的做法也是合理的。[也就是说，在数据流中使用 mac 有时会是认证的一个更常用的方法 — ed.]。这就以相当低的计算的开销代价给您带来防止篡改的管道安全（但不适用于窃听，除非您还添加了加密）。　　

　　确实如此。xmldsig 允许 — 真的，鼓励 — 多种认证方法。我假设当您前面提到“为了使这些 [ 不同 — ed. ] 对象群体都满意xmldsig 构成得非常灵活”时，这个特性是那个灵活性的一部分。并且可以由 uri 元素指向特定方法，是吗？　　

　　是的。一些灵活性来自指定加密算法的能力并且工作组选择了使用 uri 作为算法的名称。但是通过使一些元素和属性变为可选，通过接受各种密钥信息等，在您能使用 uri 的其它地方也可以提供灵活性。xmldsig 是具有各种用途的工具箱。　　

　　但是重要的是请注意：在大多数真实世界的系统中，特别验证程序可能对于它们将接受这么多选项中的什么选项有非常严格的策略。如果某人正在您本地公司的那个密钥的认证中心上寻找带有至少 1024 位长的公钥模数的 rsa 公钥签名和一个当前有效的证书，那么您可能不会考虑指定另一种算法或密钥信息类型的 xmldsig 来认证为您的目的所签署的东西，即使它对于某些其它验证程序是可能接受的。　　

　　您认为真实世界中的 xml 数字签名有什么用途？您认为它们最大的用途在那里？　　

　　我相信将会有非常广泛的用途，但特别突出的两个领域可能是：文档和消息。虽然有时候这两个领域会相互混合，但是文档趋向于保存得更长，并且其上的签名趋向于表示对所有或部分文档的人类批准，虽然它们可能还有自动附加的签名时间戳记。消息趋向于是瞬时的，并且通常会自动添加和除去认证。当然，就我在这里使用的单词而言，在其内容中，消息可以包含一个或更多文档。
　　文档很可能使用公钥技术，而根据应用程序的不同，消息可以使用公钥或对称秘钥技术。文档很可能是象抵押契据或法院文件那样“重要”的东西。但是如果 xml 数字签名广泛用于消息，那么消息就可达几个数量级那样之多。　　对于将在真实世界应用程序中非常有用的 xml 数字签名所需要的最小安全性上部构造，您是如何看的？　　它事实上取决于应用程序。签发者和验证程序总是需要密钥资料，所以最小的所谓“上部构造”是签发者和验证员用密钥资料进行手工配置。虽然我确信这在某些例子中将会这样做，但对于大多数的应用程序而言，您可以使用证书系统或密钥分发中心作为密钥中的信任源。　　

　　参考资料
　　◇在 xml signatures: behind the curtain 中，larry loeb 对 xml 数字签名的实用性和有效性表示怀疑。
　　◇w3c 的 xml 签名工作组页面是有关该主题更多信息的极佳参考资料，它包括 xml-signature syntax and processing recommendation。
　　◇donald eastlake 是数字签名工作组的主席，其宪章解释了他们希望实现的东西。
　　◇oasis 组织的 robin cook 汇编了这篇有关在数字签名上所做工作的概要（带有日期）。
　　◇verisign 的密钥管理系统使用了 xml 签名作为信任基础。在这里获得可下载的 java 客户机 sdk。
　　◇当然，您可以在 developerworks 安全性主题中找到许多安全性的文章，并且我们的 xml 专区对于使用这种语言的开发人员来说总是一个极佳的参考资料。
　　◇alphaworks 上可用的 xml security suite 为 xml 文档（如数字签名、加密和访问控制等）提供了安全性功能部件。
　　◇ibm 安全性服务能帮助您确定您的风险所在，然后设计一个安全性程序来解决它们。