Network Working Group J. Reagle
Request for Comments: 2807 W3C/MIT
Category: Informational July 2000
Network Working Group J. Reagle
Request for Comments: 2807 W3C/MIT
Category: Informational July 2000
XML Signature Requirements
XML签名要求
Status of this Memo
本备忘录的状况
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
本备忘录为互联网社区提供信息。它没有规定任何类型的互联网标准。本备忘录的分发不受限制。
Copyright Notice
版权公告
Copyright (c) 2000 The Internet Society & W3C (MIT, INRIA, Keio), All Rights Reserved.
版权所有（c）2000互联网协会和W3C（MIT、INRIA、Keio），保留所有权利。
Abstract
摘要
This document lists the design principles, scope, and requirements for the XML Digital Signature specification. It includes requirements as they relate to the signature syntax, data model, format, cryptographic processing, and external requirements and coordination.
本文档列出了XML数字签名规范的设计原则、范围和要求。它包括与签名语法、数据模型、格式、加密处理以及外部需求和协调相关的需求。
Table of Contents
目录
1. Introduction .............................................. 1
2. Design Principles and Scope ............................... 2
3. Requirements .............................................. 4
3.1. Signature Data Model and Syntax .................... 4
3.2. Format ............................................. 5
3.3. Cryptography and Processing ........................ 5
3.4 Coordination ........................................ 5
4. Security Considerations ................................... 6
5. References ................................................ 6
6. Acknowledgements .......................................... 8
7. Author's Address .......................................... 8
8. Full Copyright Statement .................................. 9
1. Introduction .............................................. 1
2. Design Principles and Scope ............................... 2
3. Requirements .............................................. 4
3.1. Signature Data Model and Syntax .................... 4
3.2. Format ............................................. 5
3.3. Cryptography and Processing ........................ 5
3.4 Coordination ........................................ 5
4. Security Considerations ................................... 6
5. References ................................................ 6
6. Acknowledgements .......................................... 8
7. Author's Address .......................................... 8
8. Full Copyright Statement .................................. 9
The XML 1.0 Recommendation [XML] describes the syntax of a class of data objects called XML documents. The mission of this working group is to develop a XML syntax used for representing signatures on digital content and procedures for computing and verifying such signatures. Signatures will provide data integrity, authentication, and/or non-repudiability.
XML 1.0建议[XML]描述了一类称为XML文档的数据对象的语法。该工作组的任务是开发一种XML语法，用于表示数字内容上的签名，以及计算和验证此类签名的过程。签名将提供数据完整性、身份验证和/或不可否认性。
This document lists the design principles, scope, and requirements over three things: (1) the scope of work available to the WG, (2) the XML signature specification, and (3) applications that implement the specification. It includes requirements as they relate to the signature syntax, data model, format, cryptographic processing, and external requirements and coordination. Those things that are required are designated as "must", those things that are optional are designated by "may", those things that are optional but recommended are designated as "should".
本文档列出了三方面的设计原则、范围和要求：（1）工作组可用的工作范围，（2）XML签名规范，以及（3）实现该规范的应用程序。它包括与签名语法、数据模型、格式、加密处理以及外部需求和协调相关的需求。那些需要的东西被指定为“必须”，那些可选的东西被指定为“可以”，那些可选但推荐的东西被指定为“应该”。
1. The specification must describe how to sign digital content, and XML content in particular. The XML syntax used to represent a signature (over any content) is described as an XML Signature. [Charter] 2. XML Signatures are generated from a hash over the canonical form of a signature manifest. (In this document we use the term manifest to mean a collection of references to the objects being signed. The specifications may use the terms manifest, package or other terms differently from this document while still meeting this requirement.) The manifest must support references to Web resources, the hash of the resource content (or its canonicalized form), and (optionally) the resource content type. [Brown, List(Solo)] Web resources are defined as any digital content that can be addressed using the syntax of XLink locator [XLink]). 3. The meaning of a signature is simple: The XML Signature syntax associates the content of resources listed in a manifest with a key via a strong one-way transformation. 1. The XML Signature syntax must be extensible such that it can support arbitrary application/trust semantics and assertion capabilities -- that can also be signed. [Charter(Requirement1&4), List(Bugbee, Solo)] 2. The WG is not chartered to specify trust semantics, but syntax and processing rules necessary for communicating signature validity (authenticity, integrity and non-repudiation). [Charter(Requirement1)] At the Chairs' discretion and in order to test the extensibility of the syntax, the WG may produce non-critical-path proposals defining common semantics (e.g., manifest, package, timestamps, endorsement, etc.) relevant to signed assertions about Web resources in a schema definition [XML, RDF] or link type definition [XLink]. Comment: A more formal definition of a signed resource is below. The notation is "definition(inputs):constraints" where definition evaluates as true for the given inputs and specified constraints. signed-resource(URI-of-resource, content, key, signature): (there was some protocol message at a specific time such that "GET(URI-of-resource) = content") AND (sign-doc(content, key, sig))
1. 规范必须描述如何签署数字内容，特别是XML内容。用于表示签名（在任何内容上）的XML语法被描述为XML签名。[宪章]2。XML签名是从签名清单的规范形式上的散列生成的。（在本文档中，我们使用术语manifest表示对正在签名的对象的引用集合。规范可能使用术语manifest、package或其他与本文档不同的术语，同时仍满足此要求。）清单必须支持对Web资源的引用，即资源内容的哈希（或其规范化形式）和（可选）资源内容类型。[Brown，List（Solo）]Web资源定义为可以使用XLink定位器[XLink]语法寻址的任何数字内容。3.签名的含义很简单：XML签名语法通过强大的单向转换将清单中列出的资源的内容与密钥相关联。1.XML签名语法必须是可扩展的，以便它能够支持任意的应用程序/信任语义和断言功能——也可以进行签名。[章程（要求1和4），清单（Bugbee，Solo）]2。工作组没有被授权指定信任语义，而是指定传递签名有效性（真实性、完整性和不可否认性）所需的语法和处理规则。[Charter（Requirement1）]由主席自行决定，为了测试语法的可扩展性，工作组可能会提出非关键路径建议，定义与模式定义[XML，RDF]或链接类型定义[XLink]中有关Web资源的签名断言相关的通用语义（例如，清单、包、时间戳、背书等）. 注释：下面是签名资源的更正式的定义。符号是“定义（输入）：约束”，其中定义对给定输入和指定约束的计算结果为真。已签名资源（资源的URI、内容、密钥、签名）：（在特定时间有一些协议消息，例如“GET（资源的URI）=内容”）和（签名文档（内容、密钥、sig））
sign-doc(content, key, signature): signature is the value of a
strong one-way transformation over content and key that yields
content integrity/validity and/or key non-repudiability
4. The specification must not specify methods of confidentiality
though the Working Group may report on the feasibility of such
work in a future or rechartered activity. [List(Bugbee)]
5. The specification must only require the provision of key
information essential to checking the validity of the
cryptographic signature. For instance, identity and key recovery
information might be of interest to particular applications, but
they are not within the class of required information defined in
this specification. [List(Reagle)]
6. The specification must define or reference at least one method of
canonicalizing and hashing the signature syntax (i.e., the
manifest and signature blocks). [Oslo] The specification must not
specify methods of canonicalizing resource content [Charter],
though it may specify security requirements over such methods.
[Oslo] Such content is normalized by specifying an appropriate
content C14N (canonicalization) algorithm [DOMHASH, XML-C14N].
Applications are expected to normalize application specific
semantics prior to handing data to a XML Signature application or
specify the necessary transformations for this process within the
signature. [Charter]
7. XML Signature applications must be conformant with the
specifications as follows:
1. XML-namespaces [XML-namespaces] within its own signature
syntax. Applications may choose C14N algorithms which do or do
not process namespaces within XML content. For instance, some
C14N algorithms may opt to remove all namespace declarations,
others may rewrite namespace declarations to provide for
context independent declarations within every element.
2. XLink [Xlink] within its own signature syntax. For any resource
identification beyond simple URIs (without fragment IDs) or
fragmentIDs, applications must use XLink locators to reference
signed resources. Signature applications must not embed or
expand XLink references in signed content, though applications
may choose C14N algorithms which provide this feature.
3. XML-Pointers [XPointer] within its own signature syntax. If
applications reference/select parts of XML documents, they must
use XML-Pointer within an XLink locator. [WS-list(1)]
The WG may specify security requirements that constrain the
operation of these dependencies to ensure consistent and secure
signature generation and operation. [Oslo]
sign-doc(content, key, signature): signature is the value of a
strong one-way transformation over content and key that yields
content integrity/validity and/or key non-repudiability
4. The specification must not specify methods of confidentiality
though the Working Group may report on the feasibility of such
work in a future or rechartered activity. [List(Bugbee)]
5. The specification must only require the provision of key
information essential to checking the validity of the
cryptographic signature. For instance, identity and key recovery
information might be of interest to particular applications, but
they are not within the class of required information defined in
this specification. [List(Reagle)]
6. The specification must define or reference at least one method of
canonicalizing and hashing the signature syntax (i.e., the
manifest and signature blocks). [Oslo] The specification must not
specify methods of canonicalizing resource content [Charter],
though it may specify security requirements over such methods.
[Oslo] Such content is normalized by specifying an appropriate
content C14N (canonicalization) algorithm [DOMHASH, XML-C14N].
Applications are expected to normalize application specific
semantics prior to handing data to a XML Signature application or
specify the necessary transformations for this process within the
signature. [Charter]
7. XML Signature applications must be conformant with the
specifications as follows:
1. XML-namespaces [XML-namespaces] within its own signature
syntax. Applications may choose C14N algorithms which do or do
not process namespaces within XML content. For instance, some
C14N algorithms may opt to remove all namespace declarations,
others may rewrite namespace declarations to provide for
context independent declarations within every element.
2. XLink [Xlink] within its own signature syntax. For any resource
identification beyond simple URIs (without fragment IDs) or
fragmentIDs, applications must use XLink locators to reference
signed resources. Signature applications must not embed or
expand XLink references in signed content, though applications
may choose C14N algorithms which provide this feature.
3. XML-Pointers [XPointer] within its own signature syntax. If
applications reference/select parts of XML documents, they must
use XML-Pointer within an XLink locator. [WS-list(1)]
The WG may specify security requirements that constrain the
operation of these dependencies to ensure consistent and secure
signature generation and operation. [Oslo]
8. XML Signatures must be developed as part of the broader Web design philosophy of decentralization, URIs, Web data, modularity/layering/extensibility, and assertions as statements about statements. [Berners-Lee, WebData] In this context, existing cryptographic provider (and infrastructure) primitives should be taken advantage of. [List(Solo)]
8. XML签名必须作为分散、URI、Web数据、模块化/分层/可扩展性以及作为语句声明的断言等更广泛的Web设计理念的一部分进行开发。[Berners Lee，WebData]在这种情况下，应该利用现有的加密提供程序（和基础设施）原语。[名单（单独）]
1. XML Signature data structures must be based on the RDF data model [RDF] but need not use the RDF serialization syntax. [Charter] 2. XML Signatures apply to any resource addressable by a locator -- including non-XML content. XML Signature referents are identified with XML locators (URIs or fragments) within the manifest that refer to external or internal resources (i.e., network accessible or within the same XML document/package). [Berners-Lee, Brown, List(Vincent), WS, XFDL] 3. XML Signatures must be able to apply to a part or totality of a XML document. [Charter, Brown] Comment: A related requirement under consideration is requiring the specification to support the ability to indicate those portions of a document one signs via exclusion of those portions one does not wish to sign. This feature allows one to create signatures that have document closure [List(Boyer(1)], retain ancestor information, and retain element order of non-continuous regions that must be signed. We are considering implementing this requirement via (1) a special <dsig:exclude> element, (2) an exclude list accompanying the resource locator, or (3) the XML-Fragment or XPointer specifications -- or a requested change to those specifications if the functionality is not available. See List(Boyer(1,2)) for further discussion of this issue. 4. Multiple XML Signatures must be able to exist over the static content of a Web resource given varied keys, content transformations, and algorithm specifications (signature, hash, canonicalization, etc.). [Charter, Brown] 5. XML Signatures are first class objects themselves and consequently must be able to be referenced and signed. [Berners-Lee] 6. The specification must permit the use of varied digital signature and message authentication codes, such as symmetric and asymmetric authentication schemes as well as dynamic agreement of keying material. [Brown] Resource or algorithm identifier are a first class objects, and must be addressable by a URI. [Berners-Lee] 7. XML Signatures must be able to apply to the original version of an included/encoded resource. [WS-list (Brown/Himes)]
1. XML签名数据结构必须基于RDF数据模型[RDF]，但不需要使用RDF序列化语法。[宪章]2。XML签名适用于定位器可寻址的任何资源——包括非XML内容。XML签名引用由清单中引用外部或内部资源的XML定位器（URI或片段）标识（即，网络可访问或在同一XML文档/包中）。[Berners Lee，Brown，List（Vincent），WS，XFDL]3。XML签名必须能够应用于XML文档的一部分或全部。[Charter，Brown]评论：正在考虑的一项相关要求是，规范要求能够通过排除不希望签署的部分，来表明文件中已签署的部分。此功能允许创建具有文档结束[列表（Boyer（1）]的签名，保留祖先信息，并保留必须签名的非连续区域的元素顺序。我们正在考虑通过（1）一个特殊的<dsig:exclude>元素，（2）资源定位器附带的排除列表，或（3）实现此要求XML片段或XPointer规范——如果功能不可用，则请求对这些规范进行更改。请参阅列表（Boyer（1,2））对于这个问题的进一步讨论。4.给定不同的密钥、内容转换和算法规范（签名、哈希、规范化等），多个XML签名必须能够存在于Web资源的静态内容上。[Charter，Brown]5.XML签名本身是第一类对象，因此必须能够被引用和签名。[Berners-Lee]6.该规范必须允许使用各种数字签名和消息身份验证代码，例如对称和非对称身份验证方案以及密钥材料的动态协议。[Brown]资源或算法标识符是第一类对象，必须可通过URI寻址。[Berners Lee]7.XML签名必须能够应用于包含/编码资源的原始版本。[WS-list（Brown/Himes）]
1. An XML Signature must be an XML element (as defined by production 39 of the XML1.0 specification. [XML]) 2. When XML signatures are placed within a document the operation must preserve (1) the document's root element tag as root and (2) the root's descendancy tree except for the addition of signature element(s) in places permitted by the document's content model. For example, an XML form, when signed, should still be recognizable as a XML form to its application after it has been signed. [WS-summary] 3. XML Signature must provide a mechanism that facilitates the production of composite documents -- by addition or deletion -- while preserving the signature characteristics (integrity, authentication, and non-repudiability) of the consituent parts. [Charter, Brown, List(Bugbee)] 4. An important use of XML Signatures will be detached Web signatures. However, signatures may be embedded within or encapsulate XML or encoded content. [Charter] This WG must specify a simple method of packaging and encapsulation if no W3C Recommendation is available.
1. XML签名必须是XML元素（如XML1.0规范[XML]2的产品39所定义）。在文档中放置XML签名时，操作必须保留（1）文档的根元素标记为root，以及（2）根元素的后代树，但在文档内容模型允许的位置添加签名元素除外。例如，一个XML表单在签名后，在其应用程序中仍然可以识别为XML表单。[WS-summary]3。XML签名必须提供一种机制，通过添加或删除促进复合文档的生成，同时保留一致部分的签名特征（完整性、身份验证和不可否认性）。[Charter，Brown，List（Bugbee）]4。XML签名的一个重要用途是分离的Web签名。然而，签名可以嵌入或封装XML或编码内容。[章程]如果没有W3C建议，本工作组必须指定一种简单的包装和封装方法。
1. The specification must permit arbitrary cryptographic signature and message authentication algorithms, symmetric and asymmetric authentication schemes, and key agreement methods. [Brown] 2. The specification must specify at least one mandatory to implement signature canonicalization, content canonicalization, hash, and signature algorithm. 3. In the event of redundant attributes within the XML Signature syntax and relevant cryptographic blobs, XML Signature applications prefer the XML Signature semantics. Comment: Another possibility is that an error should be generated, however it isn't where a conflict will be flagged between the various function and application layers regardless. 4. The signature design and specification text must not permit implementers to erroneously build weak implementations susceptible to common security weaknesses (such as as downgrade or algorithm substitution attacks).
1. 该规范必须允许任意加密签名和消息认证算法、对称和非对称认证方案以及密钥协商方法。[布朗]2。规范必须至少指定一个强制项来实现签名规范化、内容规范化、哈希和签名算法。3.在XML签名语法和相关加密blob中存在冗余属性的情况下，XML签名应用程序更喜欢XML签名语义。注释：另一种可能性是应该生成错误，但不管在哪里，不同功能层和应用层之间都不会标记冲突。4.签名设计和规范文本不得允许实现者错误地构建易受常见安全弱点（如降级或算法替换攻击）影响的弱实现。
1. The XML Signature specification should meet the requirements of the following applications: 1. Internet Open Trading Protocol v1.0 [IOTP] 2. Financial Services Mark Up Language v2.0 [Charter] 3. At least one forms application [XFA, XFDL]
1. XML签名规范应满足以下应用程序的要求：1。互联网开放交易协议v1.0[IOTP]2。金融服务加价语言v2.0[宪章]3。至少一个表单应用程序[XFA，XFDL]
2. To ensure that all requirements within this document are adequately addressed, the XML Signature specification must be reviewed by a designated member of the following communities: 1. XML Syntax Working Group: canonicalization dependencies. [Charter] 2. XML Linking Working Group: signature referents. [Charter] 3. XML Schema Working Group: signature schema design. [Charter] 4. Metadata Coordination Group: data model design. [Charter] 5. W3C Internationalization Interest Group: [AC Review] 6. XML Package Working Group: signed content in/over packages. 7. XML Fragment Working Group: signing portions of XML content. Comment: Members of the WG are very interested in signing and processing XML fragments and packaged components. Boyer asserts that [XML-fragment] does not "identify non-contiguous portions of a document in such a way that the relative positions of the connected components is preserved". Packaging is a capability critical to XML Signature applications, but it is clearly dependent on clear trust/semantic definitions, package application requirements, and even cache-like application requirements. It is not clear how this work will be addressed.
2. 为确保充分满足本文档中的所有要求，XML签名规范必须由以下社区的指定成员审查：1。XML语法工作组：规范化依赖项。[宪章]2。XML链接工作组：签名引用。[宪章]3。XML模式工作组：签名模式设计。[宪章]4。元数据协调组：数据模型设计。[宪章]5。W3C国际化利益集团：[AC Review]6。XML包工作组：包内/包外的已签名内容。7.XML片段工作组：对XML内容的部分进行签名。注释：工作组成员对签名和处理XML片段和打包组件非常感兴趣。Boyer断言，[XML片段]不会“以保留连接组件的相对位置的方式标识文档的非连续部分”。打包是XML签名应用程序的关键功能，但它显然依赖于清晰的信任/语义定义、打包应用程序需求，甚至类似缓存的应用程序需求。目前尚不清楚如何处理这项工作。
This document lists XML Digital Signature requirements as they relate to the signature syntax, data model, format, cryptographic processing, and external requirements and coordination. In that context much of this document is about security.
本文档列出了与签名语法、数据模型、格式、加密处理以及外部要求和协调相关的XML数字签名要求。在这种情况下，本文件的大部分内容都与安全有关。
AC Review Misha Wolf. "The Charter should include the I18N WG
in the section on `Coordination with Other
Groups'", http://lists.w3.org/Archives/Team/xml-
dsig-review/1999May/0007.html
AC Review Misha Wolf. "The Charter should include the I18N WG
in the section on `Coordination with Other
Groups'", http://lists.w3.org/Archives/Team/xml-
dsig-review/1999May/0007.html
Berners-Lee Axioms of Web Architecture: URIs.
http://www.w3.org/DesignIssues/Axioms.html Web
Architecture from 50,000 feet
http://www.w3.org/DesignIssues/Architecture.html
Berners-Lee Axioms of Web Architecture: URIs.
http://www.w3.org/DesignIssues/Axioms.html Web
Architecture from 50,000 feet
http://www.w3.org/DesignIssues/Architecture.html
Brown-XML-DSig Work in Progress. Digital Signatures for XML
http://www.w3.org/Signature/Drafts/xmldsig-
signature-990618.html
Brown-XML-DSig Work in Progress. Digital Signatures for XML
http://www.w3.org/Signature/Drafts/xmldsig-
signature-990618.html
Charter XML Signature (xmldsig) Charter.
http://www.w3.org/1999/05/XML-DSig-charter-
990521.html
Charter XML Signature (xmldsig) Charter.
http://www.w3.org/1999/05/XML-DSig-charter-
990521.html
DOMHASH Maruyama, H., Tamura, K. and N. Uramoto, "Digest Values for DOM (DOMHASH)", RFC 2803, April 2000.
DOMHASH Maruyama，H.，Tamura，K.和N.Uramoto，“DOM的摘要值（DOMHASH）”，RFC 2803，2000年4月。
FSML FSML 1.5 Reference Specification
http://www.echeck.org/library/ref/fsml-v1500a.pdf
FSML FSML 1.5 Reference Specification
http://www.echeck.org/library/ref/fsml-v1500a.pdf
Infoset-Req XML Information Set Requirements Note.
http://www.w3.org/TR/1999/NOTE-xml-infoset-req-
19990218.html
Infoset-Req XML Information Set Requirements Note.
http://www.w3.org/TR/1999/NOTE-xml-infoset-req-
19990218.html
IOTP Burdett, D., "Internet Open Trading Protocol - IOTP Version 1.0", RFC 2801, April 2000.
IOTP Burdett，D.，“互联网开放交易协议-IOTP 1.0版”，RFC 2801，2000年4月。
IOTP-DSig Davidson, K. and Y. Kawatsura, "Digital Signatures for the v1.0 Internet Open Trading Protocol (IOTP)", RFC 2802, April 2000.
IOTP DSig Davidson，K.和Y.Kawatsura，“v1.0互联网开放交易协议（IOTP）的数字签名”，RFC 2802，2000年4月。
Oslo Minutes of the XML Signature WG Sessions at IETF face-to-face meeting in Oslo.
在奥斯陆举行的IETF面对面会议上XML签名工作组会议的奥斯陆会议记录。
RDF RDF Schema
http://www.w3.org/TR/1999/PR-rdf-schema-19990303
RDF Model and Syntax
http://www.w3.org/TR/1999/REC-rdf-syntax-19990222
RDF RDF Schema
http://www.w3.org/TR/1999/PR-rdf-schema-19990303
RDF Model and Syntax
http://www.w3.org/TR/1999/REC-rdf-syntax-19990222
Signature WG List http://lists.w3.org/Archives/Public/w3c-ietf-
xmldsig/
Signature WG List http://lists.w3.org/Archives/Public/w3c-ietf-
xmldsig/
URI Berners-Lee, T., Fielding, R. and L. Masinter,
"Uniform Resource Identifiers (URI): Generic
Syntax", RFC 2396, August 1998.
http://www.ietf.org/rfc/rfc2396.txt
URI Berners-Lee, T., Fielding, R. and L. Masinter,
"Uniform Resource Identifiers (URI): Generic
Syntax", RFC 2396, August 1998.
http://www.ietf.org/rfc/rfc2396.txt
WS
(list, summary) XML-DSig '99: The W3C Signed XML Workshop
http://www.w3.org/DSig/signed-XML99/
http://www.w3.org/DSig/signed-XML99/summary.html
WS
(list, summary) XML-DSig '99: The W3C Signed XML Workshop
http://www.w3.org/DSig/signed-XML99/
http://www.w3.org/DSig/signed-XML99/summary.html
XLink XML
Linking Language http://www.w3.org/1999/07/WD-xlink-19990726
XLink XML
Linking Language http://www.w3.org/1999/07/WD-xlink-19990726
XML Extensible Markup Language (XML) Recommendation.
http://www.w3.org/TR/1998/REC-xml-19980210
XML Extensible Markup Language (XML) Recommendation.
http://www.w3.org/TR/1998/REC-xml-19980210
XML-C14N XML Canonicalization Requirements.
http://www.w3.org/TR/1999/NOTE-xml-canonical-req-
19990605
XML-C14N XML Canonicalization Requirements.
http://www.w3.org/TR/1999/NOTE-xml-canonical-req-
19990605
XFA XML Forms Architecture (XFA)
http://www.w3.org/Submission/1999/05/
XFA XML Forms Architecture (XFA)
http://www.w3.org/Submission/1999/05/
XFDL Extensible Forms Description Language (XFDL) 4.0
http://www.w3.org/Submission/1998/16/
XFDL Extensible Forms Description Language (XFDL) 4.0
http://www.w3.org/Submission/1998/16/
XML-Fragment XML-Fragment Interchange
http://www.w3.org/1999/06/WD-xml-fragment-
19990630.html
XML-Fragment XML-Fragment Interchange
http://www.w3.org/1999/06/WD-xml-fragment-
19990630.html
XML-namespaces Namespaces in XML
http://www.w3.org/TR/1999/REC-xml-names-19990114
XML-namespaces Namespaces in XML
http://www.w3.org/TR/1999/REC-xml-names-19990114
XML-schema XML Schema Part 1: Structures
http://www.w3.org/1999/05/06-xmlschema-1/
XML Schema Part 2: Datatypes
http://www.w3.org/1999/05/06-xmlschema-2/
XML-schema XML Schema Part 1: Structures
http://www.w3.org/1999/05/06-xmlschema-1/
XML Schema Part 2: Datatypes
http://www.w3.org/1999/05/06-xmlschema-2/
XPointer XML Pointer Language (XPointer)
http://www.w3.org/1999/07/WD-xptr-19990709
XPointer XML Pointer Language (XPointer)
http://www.w3.org/1999/07/WD-xptr-19990709
WebData Web Architecture: Describing and Exchanging Data.
http://www.w3.org/1999/04/WebData
WebData Web Architecture: Describing and Exchanging Data.
http://www.w3.org/1999/04/WebData
This document was produced as a collaborative work item of the XML Signature (xmldsig) Working Group.
本文件是作为XML签名（xmldsig）工作组的一个协作工作项目编写的。
Joseph M. Reagle Jr., W3C XML Signature Co-Chiar Massachusetts Institute of Technology Laboratory for Computer Science W3C, NE43-350 545 Technology Square Cambridge, MA 02139
Joseph M.Reagle Jr.，W3C XML签名公司中国麻省理工学院计算机科学实验室W3C，NE43-350 545技术广场剑桥，马萨诸塞州02139
Phone: 1.617.258.7621
EMail: reagle@w3.org
URL: http://www.w3.org/People/Reagle
Phone: 1.617.258.7621
EMail: reagle@w3.org
URL: http://www.w3.org/People/Reagle
Copyright (c) 2000 The Internet Society & W3C (MIT, INRIA, Keio), All Rights Reserved.
版权所有（c）2000互联网协会和W3C（MIT、INRIA、Keio），保留所有权利。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
本文件及其译本可复制并提供给他人，对其进行评论或解释或协助其实施的衍生作品可全部或部分编制、复制、出版和分发，不受任何限制，前提是上述版权声明和本段包含在所有此类副本和衍生作品中。但是，不得以任何方式修改本文件本身，例如删除版权通知或对互联网协会或其他互联网组织的引用，除非出于制定互联网标准的需要，在这种情况下，必须遵循互联网标准过程中定义的版权程序，或根据需要将其翻译成英语以外的其他语言。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上述授予的有限许可是永久性的，互联网协会或其继承人或受让人不会撤销。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
本文件和其中包含的信息是按“原样”提供的，互联网协会和互联网工程任务组否认所有明示或暗示的保证，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
Acknowledgement
确认
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC编辑功能的资金目前由互联网协会提供。