< draft-ietf-xmldsig-requirements-02.txt		draft-ietf-xmldsig-requirements-03.txt >
	XML Digital Signatures Working Group J. Reagle,		XML Digital Signatures Working Group J. Reagle,
	INTERNET-DRAFT W3C/MIT		INTERNET-DRAFT W3C/MIT
	draft-ietf-xmldsig-requirements-02.txt		draft-ietf-xmldsig-requirements-03.txt
	Expires April 14, 1999		Expires August 01, 2000
	XML-Signature Requirements		XML Signature Requirements
	Copyright Notice		Copyright Notice
	Copyright (c) 1999 The Internet Society & W3C (MIT, INRIA, Keio), All		Copyright (c) 2000 The Internet Society & W3C (MIT, INRIA, Keio), All
	Rights Reserved.		Rights Reserved.
	IETF Status of this Memo		IETF Status of this Memo
	This document is an Internet-Draft and is in full conformance with all		This document is an Internet-Draft and is in full conformance with
	provisions of Section 10 of RFC2026.		all provisions of Section 10 of RFC2026.
	This document is a production of the joint IETF/W3C XML Signature
	Working Group.
	http://www.w3.org/Signature
	The comparable html draft of this version may be found at
	http://www.w3.org/TR/1999/WD-xmldsig-requirements-19991014
	The latest version of this draft series may be found at:
	http://www.w3.org/TR/xmldsig-requirements
	Internet-Drafts are working documents of the Internet Engineering Task		Internet-Drafts are working documents of the Internet Engineering Task
	Force (IETF), its areas, and its working groups. Note that other		Force (IETF), its areas, and its working groups. Note that other
	groups may also distribute working documents as Internet-Drafts.		groups may also distribute working documents as Internet-Drafts.
	Internet-Drafts are draft documents valid for a maximum of six months		Internet-Drafts are draft documents valid for a maximum of six months
	and may be updated, replaced, or obsoleted by other documents at any		and may be updated, replaced, or obsoleted by other documents at any
	time. It is inappropriate to use Internet- Drafts as reference		time. It is inappropriate to use Internet- Drafts as reference
	material or to cite them other than as "work in progress."		material or to cite them other than as "work in progress."
	The list of current Internet-Drafts can be accessed at		The list of current Internet-Drafts can be accessed at
	http://www.ietf.org/ietf/1id-abstracts.txt		http://www.ietf.org/ietf/1id-abstracts.txt
	The list of Internet-Draft Shadow Directories can be accessed at		The list of Internet-Draft Shadow Directories can be accessed at
	http://www.ietf.org/shadow.html.		http://www.ietf.org/shadow.html.
	W3C Status of this document		W3C Status of this document
			This document is a production of the joint IETF/W3C XML Signature
			Working Group.
			http://www.w3.org/Signature
			The comparable html draft of this version may be found at
			http://www.w3.org/TR/2000/xmldsig-requirements-20000104/
			The latest version of this document series may be found at:
			http://www.w3.org/TR/xmldsig-core
	This Working Draft of XML Signature Requirements is a very stable		This Working Draft of XML Signature Requirements is a very stable
	result of this Working Draft having been advanced through W3C Last		result of this Working Draft that has been advanced through W3C Last
	Call. Relatively small changes have been made to clarify the stated		Call and has been published as an IETF Informational RFC. The only
	requirements during that period. This document will now be advanced as		changes from the previous version were those necessary to comply with
	an IETF Informational RFC.		RFC Editor publication requirements, including the addition of a
			security considerations section.
	Please send comments to the editor <reagle@w3.org> and cc: the list		Please send comments to the editor <reagle@w3.org> and cc: the list
	<w3c-ietf-xmldsig@w3.org>. Publication as a Working Draft does not		<w3c-ietf-xmldsig@w3.org>. Publication as a Working Draft does not
	imply endorsement by the W3C membership. This is a draft document and		imply endorsement by the W3C membership. This is a draft document and
	may be updated, replaced or obsoleted by other documents at any time.		may be updated, replaced or obsoleted by other documents at any time.
	It is inappropriate to cite W3C Drafts as other than "work in		It is inappropriate to cite W3C Drafts as other than "work in
	progress". A list of current W3C working drafts can be found at		progress". A list of current W3C working drafts can be found at
	http://www.w3.org/TR		http://www.w3.org/TR
			Patent disclosures relevant to this specification may be found on the
			WG's patent disclosure page.
	Abstract		Abstract
	This document lists the design principles, scope, and requirements for		This document lists the design principles, scope, and requirements for
	the XML Digital Signature specification. It includes requirements as		the XML Digital Signature specification. It includes requirements as
	they relate to the signature syntax, data model, format, cryptographic		they relate to the signature syntax, data model, format, cryptographic
	processing, and external requirements and coordination.		processing, and external requirements and coordination.
	Table of Contents		Table of Contents
	1. Introduction		1. Introduction
	2. Design Principles and Scope		2. Design Principles and Scope
	3. Requirements		3. Requirements
	3.1 Signature Data Model and Syntax		3.1. Signature Data Model and Syntax
	3.2 Format		3.2. Format
	3.3 Cryptography and Processing		3.3. Cryptography and Processing
	3.4 Coordination		3.4 Coordination
	4. References		4. Security Considerations
			5. References
			6. Acknowledgements
			7. Author's Address
			8. Full Copyright Statements
	1 Introduction		1. Introduction
	The XML 1.0 Recommendation [XML] describes the syntax of a class of		The XML 1.0 Recommendation [XML] describes the syntax of a class of
	data objects called XML documents. The mission of this working group		data objects called XML documents. The mission of this working group
	is to develop a XML syntax used for representing signatures on digital		is to develop a XML syntax used for representing signatures on digital
	content and procedures for computing and verifying such signatures.		content and procedures for computing and verifying such signatures.
	Signatures will provide data integrity, authentication, and/or		Signatures will provide data integrity, authentication, and/or
	non-repudiatability.		non-repudiatability.
	This document lists the design principles, scope, and requirements		This document lists the design principles, scope, and requirements
	over three things: (1) the scope of work available to the WG, (2) the		over three things: (1) the scope of work available to the WG, (2) the
	XML signature specification, and (3) applications that implement the		XML signature specification, and (3) applications that implement the
	specification. It includes requirements as they relate to the		specification. It includes requirements as they relate to the
	signature syntax, data model, format, cryptographic processing, and		signature syntax, data model, format, cryptographic processing, and
	external requirements and coordination. Those things that are required		external requirements and coordination. Those things that are required
	are designated as "must," those things that are optional are		are designated as "must," those things that are optional are
	designated by "may," those things that are optional but recommended		designated by "may," those things that are optional but recommended
	are designated as "should."		are designated as "should."
	2 Design Principles and Scope		2. Design Principles and Scope
	1. The specification must describe how to sign digital content, and		1. The specification must describe how to sign digital content, and
	XML content in particular. The XML syntax used to represent a		XML content in particular. The XML syntax used to represent a
	signature (over any content) is described as an XML-signature.		signature (over any content) is described as an XML Signature.
	[Charter]		[Charter]
	2. XML-signatures are generated from a hash over the canonical form		2. XML Signatures are generated from a hash over the canonical form
	of a signature manifest. (In this document we use the term		of a signature manifest. (In this document we use the term
	manifest to mean a collection of references to the objects being		manifest to mean a collection of references to the objects being
	signed. The specifications may use the terms manifest, package or		signed. The specifications may use the terms manifest, package or
	other terms differently from this document while still meeting		other terms differently from this document while still meeting
	this requirement.) The manifest must support references to Web		this requirement.) The manifest must support references to Web
	resources, the hash of the resource content (or its canonicalized		resources, the hash of the resource content (or its canonicalized
	form), and (optionally) the resource content type. [Brown,		form), and (optionally) the resource content type. [Brown,
	List(Solo)] Web resources are defined as any digital content that		List(Solo)] Web resources are defined as any digital content that
	can be addressed using the syntax of XLink locator [XLink]).		can be addressed using the syntax of XLink locator [XLink]).
	3. The meaning of a signature is simple: The XML-signature syntax		3. The meaning of a signature is simple: The XML Signature syntax
	associates the content of resources listed in a manifest with a		associates the content of resources listed in a manifest with a
	key via a strong one-way transformation.		key via a strong one-way transformation.
	1. The XML-signature syntax must be extensible such that it can		1. The XML Signature syntax must be extensible such that it can
	support arbitrary application/trust semantics and assertion		support arbitrary application/trust semantics and assertion
	capabilities -- that can also be signed.		capabilities -- that can also be signed.
	[Charter(Requirement1&4), List(Bugbee, Solo)]		[Charter(Requirement1&4), List(Bugbee, Solo)]
	2. The WG is not chartered to specify trust semantics, but		2. The WG is not chartered to specify trust semantics, but
	syntax and processing rules necessary for communicating		syntax and processing rules necessary for communicating
	signature validity (authenticity, integrity and		signature validity (authenticity, integrity and
	non-repudiation). [Charter(Requirement1)] At the Chairs'		non-repudiation). [Charter(Requirement1)] At the Chairs'
	discretion and in order to test the extensibility of the		discretion and in order to test the extensibility of the
	syntax, the WG may produce non-critical-path proposals		syntax, the WG may produce non-critical-path proposals
	defining common semantics (e.g., manifest, package,		defining common semantics (e.g., manifest, package,
	skipping to change at page 3, line 53 ¶		skipping to change at page 4, line 10 ¶
	they are not within the class of required information defined in		they are not within the class of required information defined in
	this specification. [List(Reagle)]		this specification. [List(Reagle)]
	6. The specification must define or reference at least one method of		6. The specification must define or reference at least one method of
	canonicalizing and hashing the signature syntax (i.e., the		canonicalizing and hashing the signature syntax (i.e., the
	manifest and signature blocks). [Oslo] The specification must not		manifest and signature blocks). [Oslo] The specification must not
	specify methods of canonicalizing resource content [Charter],		specify methods of canonicalizing resource content [Charter],
	though it may specify security requirements over such methods.		though it may specify security requirements over such methods.
	[Oslo] Such content is normalized by specifying an appropriate		[Oslo] Such content is normalized by specifying an appropriate
	content C14N (canonicalization) algorithm [DOMHASH, XML-C14N].		content C14N (canonicalization) algorithm [DOMHASH, XML-C14N].
	Applications are expected to normalize application specific		Applications are expected to normalize application specific
	semantics prior to handing data to a XML-signature application or		semantics prior to handing data to a XML Signature application or
	specify the necessary transformations for this process within the		specify the necessary transformations for this process within the
	signature. [Charter]		signature. [Charter]
	7. XML-signature applications must be conformant with the		7. XML Signature applications must be conformant with the
	specifications as follows:		specifications as follows:
	1. XML-namespaces [XML-namespaces] within its own signature		1. XML-namespaces [XML-namespaces] within its own signature
	syntax. Applications may choose C14N algorithms which do or		syntax. Applications may choose C14N algorithms which do or
	do not process namespaces within XML content. For instance,		do not process namespaces within XML content. For instance,
	some C14N algorithms may opt to remove all namespace		some C14N algorithms may opt to remove all namespace
	declarations, others may rewrite namespace declarations to		declarations, others may rewrite namespace declarations to
	provide for context independent declarations within every		provide for context independent declarations within every
	element.		element.
	2. XLink [Xlink] within its own signature syntax. For any		2. XLink [Xlink] within its own signature syntax. For any
	resource identification beyond simple URIs (without fragment		resource identification beyond simple URIs (without fragment
	skipping to change at page 4, line 25 ¶		skipping to change at page 4, line 35 ¶
	reference signed resources. Signature applications must not		reference signed resources. Signature applications must not
	embed or expand XLink references in signed content, though		embed or expand XLink references in signed content, though
	applications may choose C14N algorithms which provide this		applications may choose C14N algorithms which provide this
	feature.		feature.
	3. XML-Pointers [XPointer] within its own signature syntax. If		3. XML-Pointers [XPointer] within its own signature syntax. If
	applications reference/select parts of XML documents, they		applications reference/select parts of XML documents, they
	must use XML-Pointer within an XLink locator. [WS-list(1)]		must use XML-Pointer within an XLink locator. [WS-list(1)]
	The WG may specify security requirements that constrain the		The WG may specify security requirements that constrain the
	operation of these dependencies to ensure consistent and secure		operation of these dependencies to ensure consistent and secure
	signature generation and operation. [Oslo]		signature generation and operation. [Oslo]
	8. XML-signatures must be developed as part of the broader Web design		8. XML Signatures must be developed as part of the broader Web design
	philosophy of decentralization, URIs, Web data,		philosophy of decentralization, URIs, Web data,
	modularity/layering/extensibility, and assertions as statements		modularity/layering/extensibility, and assertions as statements
	about statements. [Berners-Lee, WebData] In this context, existing		about statements. [Berners-Lee, WebData] In this context, existing
	cryptographic provider (and infrastructure) primitives should be		cryptographic provider (and infrastructure) primitives should be
	taken advantage of. [List(Solo)]		taken advantage of. [List(Solo)]
	3 Requirements		3. Requirements
	3.1 Signature Data Model and Syntax		3.1 Signature Data Model and Syntax
	1. XML-signature data structures must be based on the RDF data model		1. XML Signature data structures must be based on the RDF data model
	[RDF] but need not use the RDF serialization syntax. [Charter]		[RDF] but need not use the RDF serialization syntax. [Charter]
	2. XML-signatures apply to any resource addressable by a locator --		2. XML Signatures apply to any resource addressable by a locator --
	including non-XML content. XML-signature referents are identified		including non-XML content. XML Signature referents are identified
	with XML locators (URIs or fragments) within the manifest that		with XML locators (URIs or fragments) within the manifest that
	refer to external or internal resources (i.e., network accessible		refer to external or internal resources (i.e., network accessible
	or within the same XML document/package). [Berners-Lee, Brown,		or within the same XML document/package). [Berners-Lee, Brown,
	List(Vincent), WS, XFDL]		List(Vincent), WS, XFDL]
	3. XML-signatures must be able to apply to a part or totality of a		3. XML Signatures must be able to apply to a part or totality of a
	XML document. [Charter, Brown]		XML document. [Charter, Brown]
	Comment: A related requirement under consideration is requiring		Comment: A related requirement under consideration is requiring
	the specification to support the ability to indicate those		the specification to support the ability to indicate those
	portions of a document one signs via exclusion of those portions		portions of a document one signs via exclusion of those portions
	one does not wish to sign. This feature allows one to create		one does not wish to sign. This feature allows one to create
	signatures that have document closure [List(Boyer(1)], retain		signatures that have document closure [List(Boyer(1)], retain
	ancestor information, and retain element order of non-continuous		ancestor information, and retain element order of non-continuous
	regions that must be signed. We are considering implementing this		regions that must be signed. We are considering implementing this
	requirement via (1) a special <dsig:exclude> element, (2) an		requirement via (1) a special <dsig:exclude> element, (2) an
	exclude list accompanying the resource locator, or (3) the		exclude list accompanying the resource locator, or (3) the
	XML-Fragment or XPointer specifications -- or a requested change		XML-Fragment or XPointer specifications -- or a requested change
	to those specifications if the functionality is not available. See		to those specifications if the functionality is not available. See
	List(Boyer(1,2)) for further discussion of this issue.		List(Boyer(1,2)) for further discussion of this issue.
	4. Multiple XML-signatures must be able to exist over the static		4. Multiple XML Signatures must be able to exist over the static
	content of a Web resource given varied keys, content		content of a Web resource given varied keys, content
	transormations, and algorithm specifications (signature, hash,		transormations, and algorithm specifications (signature, hash,
	canonicalization, etc.). [Charter, Brown]		canonicalization, etc.). [Charter, Brown]
	5. XML-signatures are first class objects themselves and consequently		5. XML Signatures are first class objects themselves and consequently
	must be able to be referenced and signed. [Berners-Lee]		must be able to be referenced and signed. [Berners-Lee]
	6. The specification must permit the use of varied digital signature		6. The specification must permit the use of varied digital signature
	and message authentication codes, such as symmetric and asymmetric		and message authentication codes, such as symmetric and asymmetric
	authentication schemes as well as dynamic agreement of keying		authentication schemes as well as dynamic agreement of keying
	material. [Brown] Resource or algorithm identifier are a first		material. [Brown] Resource or algorithm identifier are a first
	class objects, and must be addressable by a URI. [Berners-Lee]		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		7. XML Signatures must be able to apply to the original version of an
	included/encoded resource. [WS-list (Brown/Himes)]		included/encoded resource. [WS-list (Brown/Himes)]
	3.2 Format		3.2 Format
	1. An XML-signature must be an XML element (as defined by production		1. An XML Signature must be an XML element (as defined by production
	39 of the XML1.0 specification. [XML])		39 of the XML1.0 specification. [XML])
	2. When XML signatures are placed within a document the operation		2. When XML signatures are placed within a document the operation
	must preserve (1) the document's root element tag as root and (2)		must preserve (1) the document's root element tag as root and (2)
	the root's descendancy tree except for the addition of signature		the root's descendancy tree except for the addition of signature
	element(s) in places permitted by the document's content model.		element(s) in places permitted by the document's content model.
	For example, an XML form, when signed, should still be		For example, an XML form, when signed, should still be
	recognizable as a XML form to its application after it has been		recognizable as a XML form to its application after it has been
	signed. [WS-summary]		signed. [WS-summary]
	3. XML-signature must provide a mechanism that facilitates the		3. XML Signature must provide a mechanism that facilitates the
	production of composite documents -- by addition or deletion --		production of composite documents -- by addition or deletion --
	while preserving the signature characteristics (integrity,		while preserving the signature characteristics (integrity,
	authentication, and non-repudiatability) of the consituent parts.		authentication, and non-repudiatability) of the consituent parts.
	[Charter, Brown, List(Bugbee)]		[Charter, Brown, List(Bugbee)]
	4. An important use of XML-signatures will be detached Web		4. An important use of XML Signatures will be detached Web
	signatures. However, signatures may be embedded within or		signatures. However, signatures may be embedded within or
	encapsulate XML or encoded content. [Charter] This WG must specify		encapsulate XML or encoded content. [Charter] This WG must specify
	a simple method of packaging and encapsulation if no W3C		a simple method of packaging and encapsulation if no W3C
	Recommendation is available.		Recommendation is available.
	3.3 Cryptography and Processing		3.3 Cryptography and Processing
	1. The specification must permit arbitrary cryptographic signature		1. The specification must permit arbitrary cryptographic signature
	and message authentication algorithms, symmetric and asymmetric		and message authentication algorithms, symmetric and asymmetric
	authentication schemes, and key agreement methods. [Brown]		authentication schemes, and key agreement methods. [Brown]
	skipping to change at page 6, line 30 ¶		skipping to change at page 6, line 40 ¶
	3. XML Schema Working Group: signature schema design. [Charter]		3. XML Schema Working Group: signature schema design. [Charter]
	4. Metadata Coordination Group: data model design. [Charter]		4. Metadata Coordination Group: data model design. [Charter]
	5. W3C Internationalization Interest Group: [AC Review]		5. W3C Internationalization Interest Group: [AC Review]
	6. XML Package Working Group: signed content in/over packages.		6. XML Package Working Group: signed content in/over packages.
	7. XML Fragment Working Group: signing portions of XML content.		7. XML Fragment Working Group: signing portions of XML content.
	Comment: Members of the WG are very interested in signing and		Comment: Members of the WG are very interested in signing and
	processing XML fragments and packaged components. Boyer asserts		processing XML fragments and packaged components. Boyer asserts
	that [XML-fragment] does not "identify non-contiguous portions of		that [XML-fragment] does not "identify non-contiguous portions of
	a document in such a way that the relative positions of the		a document in such a way that the relative positions of the
	connected components is preserved." Packaging is a capability		connected components is preserved." Packaging is a capability
	critical to XML-Signature applications, but it is clearly		critical to XML Signature applications, but it is clearly
	dependent on clear trust/semantic definitions, package application		dependent on clear trust/semantic definitions, package application
	requirements, and even cache-like application requirements. It is		requirements, and even cache-like application requirements. It is
	not clear how this work will be addressed.		not clear how this work will be addressed.
	4 References		4. Security Considerations
			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.
			5. References
	AC Review		AC Review
	Misha Wolf. "The Charter should include the I18N WG in the		Misha Wolf. "The Charter should include the I18N WG in the
	section on 'Coordination with Other Groups.'"		section on 'Coordination with Other Groups.'"
	http://lists.w3.org/Archives/Team/xml-dsig-review/1999May/0007.		http://lists.w3.org/Archives/Team/xml-dsig-review/1999May/0007.
	html		html
	Berners-Lee		Berners-Lee
	Axioms of Web Architecture: URIs.		Axioms of Web Architecture: URIs.
	http://www.w3.org/DesignIssues/Axioms.html		http://www.w3.org/DesignIssues/Axioms.html
	Web Architecture from 50,000 feet		Web Architecture from 50,000 feet
	http://www.w3.org/DesignIssues/Architecture.html		http://www.w3.org/DesignIssues/Architecture.html
	Brown-XML-DSig		Brown-XML-DSig
	Internet Draft. Digital Signatures for XML		Internet Draft. Digital Signatures for XML
	http://search.ietf.org/internet-drafts/draft-ietf-xmldsig-signa		http://www.w3.org/Signature/Drafts/xmldsig-signature-
	ture-00.txt		990618.html
	Charter		Charter
	XML Signature (xmldsig) Charter.		XML Signature (xmldsig) Charter.
	http://www.w3.org/1999/05/XML-DSig-charter-990521.html		http://www.w3.org/1999/05/XML-DSig-charter-990521.html
	DOMHASH		DOMHASH
	Internet Draft. Digest Values for DOM (DOMHASH)		Internet Draft. Digest Values for DOM (DOMHASH)
	http://search.ietf.org/internet-drafts/draft-hiroshi-dom-hash-0		http://www.ietf.org/internet-drafts/draft-ietf-trade-
	1.txt		hiroshi-dom-hash-03.txt
	FSML		FSML
	FSML 1.5 Reference Specification		FSML 1.5 Reference Specification
	http://www.echeck.org/library/ref/fsml-v1500a.pdf		http://www.echeck.org/library/ref/fsml-v1500a.pdf
	Infoset-Req		Infoset-Req
	XML Information Set Requirements Note.		XML Information Set Requirements Note.
	http://www.w3.org/TR/1999/NOTE-xml-infoset-req-19990218.html		http://www.w3.org/TR/1999/NOTE-xml-infoset-req-19990218.html
	IOTP		IOTP
	Internet Open Trading Protocol v1.0		Internet Open Trading Protocol v1.0
	http://www.ietf.org/internet-drafts/draft-ietf-trade-iotp-v1.0-		http://www.ietf.org/internet-drafts/draft-ietf-trade-iotp-v1.0-
	protocol-04.txt		protocol-07.txt
	IOTP-DSig		IOTP-DSig
	Internet Draft. Digital Signatures for the Internet Open		Internet Draft. Digital Signatures for the Internet Open
	Trading Protocol		Trading Protocol
	http://www.ietf.org/internet-drafts/draft-ietf-trade-iotp-v1.0-		http://www.ietf.org/internet-drafts/draft-ietf-trade-iotp-v1.0-
	dsig-00.txt		dsig-05.txt
	Oslo		Oslo
	Minutes of the XML Signature WG Sessions at IETF face-to-face		Minutes of the XML Signature WG Sessions at IETF face-to-face
	meeting in Oslo.		meeting in Oslo.
	RDF		RDF
	RDF Schema		RDF Schema
	http://www.w3.org/TR/1999/PR-rdf-schema-19990303		http://www.w3.org/TR/1999/PR-rdf-schema-19990303
	RDF Model and Syntax		RDF Model and Syntax
	http://www.w3.org/TR/1999/REC-rdf-syntax-19990222		http://www.w3.org/TR/1999/REC-rdf-syntax-19990222
	skipping to change at line 411 ¶		skipping to change at page 9, line 4 ¶
	XML Schema Part 2: Datatypes		XML Schema Part 2: Datatypes
	http://www.w3.org/1999/05/06-xmlschema-2/		http://www.w3.org/1999/05/06-xmlschema-2/
	XPointer		XPointer
	XML Pointer Language (XPointer)		XML Pointer Language (XPointer)
	http://www.w3.org/1999/07/WD-xptr-19990709		http://www.w3.org/1999/07/WD-xptr-19990709
	WebData		WebData
	Web Architecture: Describing and Exchanging Data.		Web Architecture: Describing and Exchanging Data.
	http://www.w3.org/1999/04/WebData		http://www.w3.org/1999/04/WebData
			6. Acknowledgements
			This document was produced as a collaborative work item of the XML
			Signature (xmldsig) Working Group.
			7. Author's Address
			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
			Phone: 1.617.258.7621
			E-Mail: reagle@w3.org
			URL: http://www.w3.org/People/Reagle
			8. Full Copyright Statements
			The terms of use of this document is governed by either the IETF
			or W3C terms. The reader must comply with either the complete
			IETF or W3C terms but need not comply with both.
			IETF
			Copyright (C) The Internet Society (date). All Rights Reserved.
			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.
			W3C http://www.w3.org/Consortium/Legal/copyright-documents-19990405
			Copyright ¨ 1995-1999 World Wide Web Consortium, (Massachusetts
			Institute of Technology, Institut National de Recherche en
			Informatique et en Automatique, Keio University). All Rights Reserved.
			http://www.w3.org/Consortium/Legal/
			Public documents on the W3C site are provided by the copyright holders
			under the following license. The software or Document Type Definitions
			(DTDs) associated with W3C specifications are governed by the Software
			Notice. By using and/or copying this document, or the W3C document
			from which this statement is linked, you (the licensee) agree that you
			have read, understood, and will comply with the following terms and
			conditions:
			Permission to use, copy, and distribute the contents of this document,
			or the W3C document from which this statement is linked, in any medium
			for any purpose and without fee or royalty is hereby granted, provided
			that you include the following on ALL copies of the document, or
			portions thereof, that you use:
			1. A link or URL to the original W3C document.
			2. The pre-existing copyright notice of the original author, if it
			doesn't exist, a notice of the form: "Copyright ¨ World Wide Web
			Consortium, (Massachusetts Institute of Technology, Institut
			National de Recherche en Informatique et en Automatique, Keio
			University). All Rights Reserved.
			http://www.w3.org/Consortium/Legal/" (Hypertext is preferred, but
			a textual representation is permitted.)
			3. If it exists, the STATUS of the W3C document.
			When space permits, inclusion of the full text of this NOTICE should
			be provided. We request that authorship attribution be provided in any
			software, documents, or other items or products that you create
			pursuant to the implementation of the contents of this document, or
			any portion thereof.
			No right to create modifications or derivatives of W3C documents is
			granted pursuant to this license. However, subsequent to additional
			requirements documented in the Copyright FAQ, modifications or
			derivatives are sometimes granted by the W3C to individuals complying
			with those terms.
			THIS DOCUMENT IS PROVIDED "AS IS," AND COPYRIGHT HOLDERS MAKE NO
			REPRESENTATIONS OR WARRANTIES, EXPRESS OR IMPLIED, INCLUDING, BUT NOT
			LIMITED TO, WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR
			PURPOSE, NON-INFRINGEMENT, OR TITLE; THAT THE CONTENTS OF THE DOCUMENT
			ARE SUITABLE FOR ANY PURPOSE; NOR THAT THE IMPLEMENTATION OF SUCH
			CONTENTS WILL NOT INFRINGE ANY THIRD PARTY PATENTS, COPYRIGHTS,
			TRADEMARKS OR OTHER RIGHTS.
			COPYRIGHT HOLDERS WILL NOT BE LIABLE FOR ANY DIRECT, INDIRECT, SPECIAL
			OR CONSEQUENTIAL DAMAGES ARISING OUT OF ANY USE OF THE DOCUMENT OR THE
			PERFORMANCE OR IMPLEMENTATION OF THE CONTENTS THEREOF.
			The name and trademarks of copyright holders may NOT be used in
			advertising or publicity pertaining to this document or its contents
			without specific, written prior permission. Title to copyright in this
			document will at all times remain with copyright holders.
End of changes. 35 change blocks.
	56 lines changed or deleted		70 lines changed or added
This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/