< draft-eastlake-xmldsig-uri-08.txt		draft-eastlake-xmldsig-uri-09.txt >
	INTERNET-DRAFT Donald E. Eastlake 3rd		INTERNET-DRAFT Donald E. Eastlake 3rd
	Motorola Laboratories		Motorola Laboratories
	Expires: December 2004 July 2004		Expires: March 2005 September 2004
	Additional XML Security URIs		Additional XML Security URIs
	---------- --- -------- ----		---------- --- -------- ----
	<draft-eastlake-xmldsig-uri-08.txt>		<draft-eastlake-xmldsig-uri-09.txt>
	Donald E. Eastlake 3rd		Donald E. Eastlake 3rd
	Status of This Document		Status of This Document
	By submitting this Internet-Draft, I certify that any applicable		By submitting this Internet-Draft, I certify that any applicable
	patent or other IPR claims of which I am aware have been disclosed,		patent or other IPR claims of which I am aware have been disclosed,
	and any of which I become aware will be disclosed, in accordance with		or will be disclosed, and any of which I become aware will be
	RFC 3668.		disclosed, in accordance with RFC 3668.
	Distribution of this document is unlimited. Comments should be sent		Distribution of this document is unlimited. Comments should be sent
	to the author. This document is an Internet-Draft and is in full		to the author. Internet-Drafts are working documents of the Internet
	conformance with all provisions of Section 10 of RFC 2026.		Engineering Task Force (IETF), its areas, and its working groups.
	Internet-Drafts are working documents of the Internet Engineering		Note that other groups may also distribute working documents as
	Task Force (IETF), its areas, and its working groups. Note that		Internet-Drafts.
	other 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 a "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. The list of Internet-		http://www.ietf.org/1id-abstracts.html
	Draft Shadow Directories can be accessed at
	http://www.ietf.org/shadow.html.		The list of Internet-Draft Shadow Directories can be accessed at
			http://www.ietf.org/shadow.html
			Copyright (C) 2004 The Internet Society. All Right Reserved.
	Abstract		Abstract
	A number of URIs intended for use with XML Digital Signatures,		A number of URIs intended for use with XML Digital Signatures,
	Encryption, and Canonnicalization are defined. These URIs identify		Encryption, and Canonnicalization are defined. These URIs identify
	algorithms and types of keying information.		algorithms and types of keying information.
	Acknowledgements		Acknowledgements
	Glenn Adams, Merlin Hughs, Gregor Karlinger, Brian LaMachia, Shiho		Glenn Adams, Merlin Hughs, Gregor Karlinger, Brian LaMachia, Shiho
	skipping to change at page 2, line 53 ¶		skipping to change at page 2, line 53 ¶
	3.1 PKCS #7 Bag of Certificates and CRLs..................13		3.1 PKCS #7 Bag of Certificates and CRLs..................13
	3.2 Additional RetrievalMethod Type Values................14		3.2 Additional RetrievalMethod Type Values................14
	4. IANA Considerations....................................15		4. IANA Considerations....................................15
	5. Security Considerations................................15		5. Security Considerations................................15
	6. Copyright and Disclaimer...............................15		6. Copyright and Disclaimer...............................15
	Normative References......................................16		Normative References......................................16
	Informative References....................................17		Informative References....................................17
	Author's Address..........................................19		Author‚ÇÖs Address..........................................19
	Expiration and File Name..................................19		Expiration and File Name..................................19
	INTERNET-DRAFT Additional XML Security URIs		INTERNET-DRAFT Additional XML Security URIs
	1. Introduction		1. Introduction
	XML Digital Signatures, Canonicalization, and Encryption have been		XML Digital Signatures, Canonicalization, and Encryption have been
	standardized by the W3C and by the joint IETF/W3C XMLDSIG working		standardized by the W3C and by the joint IETF/W3C XMLDSIG working
	group [W3C]. All of these are now W3C Recommendations and IETF		group [W3C]. All of these are now W3C Recommendations and IETF
	Informational or Standards Track documents. They are available as		Informational or Standards Track documents. They are available as
	skipping to change at page 4, line 15 ¶		skipping to change at page 4, line 15 ¶
	INTERNET-DRAFT Additional XML Security URIs		INTERNET-DRAFT Additional XML Security URIs
	2. Algorithms		2. Algorithms
	The URI [RFC 2396] being dropped from the standard due to the		The URI [RFC 2396] being dropped from the standard due to the
	transition from Proposed Standard to Draft Standard is included in		transition from Proposed Standard to Draft Standard is included in
	Section 2.4 below with its original		Section 2.4 below with its original
	http://www.w3.org/2000/09/xmldsig#		http://www.w3.org/2000/09/xmldsig#
	prefix so as to avoid changing the XMLDSIG standard's namespace.		prefix so as to avoid changing the XMLDSIG standard‚ÇÖs namespace.
	Additional algorithms are given URIs that start with		Additional algorithms are given URIs that start with
	http://www.w3.org/2001/04/xmldsig-more#		http://www.w3.org/2001/04/xmldsig-more#
	An "xmldsig-more" URI does not imply any official W3C status for		An "xmldsig-more" URI does not imply any official W3C status for
	these algorithms or identifiers nor does it imply that they are only		these algorithms or identifiers nor does it imply that they are only
	useful in digital signatures. Currently, dereferencing such URIs may		useful in digital signatures. Currently, dereferencing such URIs may
	or may not produce a temporary placeholder document. Permission to		or may not produce a temporary placeholder document. Permission to
	use these this URI prefix has been given by the W3C.		use these this URI prefix has been given by the W3C.
	skipping to change at page 5, line 7 ¶		skipping to change at page 5, line 7 ¶
	element shall be the base64 [RFC 2045] encoding of this bit string		element shall be the base64 [RFC 2045] encoding of this bit string
	viewed as a 16-octet octet stream.		viewed as a 16-octet octet stream.
	2.1.2 SHA-224		2.1.2 SHA-224
	Identifier:		Identifier:
	http://www.w3.org/2001/04/xmldsig-more#sha224		http://www.w3.org/2001/04/xmldsig-more#sha224
	INTERNET-DRAFT Additional XML Security URIs		INTERNET-DRAFT Additional XML Security URIs
	The SHA-224 algorithm [RFC sha224] takes no explicit parameters. An		The SHA-224 algorithm [FIPS 180-2change, RFC 3874] takes no explicit
	example of a SHA-224 DigestAlgorithm element is:		parameters. An example of a SHA-224 DigestAlgorithm element is:
	<DigestAlgorithm		<DigestAlgorithm
	Algorithm="http://www.w3.org/2001/04/xmldsig-more#sha224" />		Algorithm="http://www.w3.org/2001/04/xmldsig-more#sha224" />
	A SHA-224 digest is a 224 bit string. The content of the DigestValue		A SHA-224 digest is a 224 bit string. The content of the DigestValue
	element shall be the base64 [RFC2045] encoding of this string viewed		element shall be the base64 [RFC2045] encoding of this string viewed
	as a 28-octet stream. Because it takes roughly the same amount of		as a 28-octet stream. Because it takes roughly the same amount of
	effort to compute a SHA-224 message digest as a SHA-256 digest and		effort to compute a SHA-224 message digest as a SHA-256 digest and
	terseness is usually not a criteria in XML application, consideration		terseness is usually not a criteria in XML application, consideration
	should be given to the use of SHA-256 as an alternative.		should be given to the use of SHA-256 as an alternative.
	skipping to change at page 6, line 51 ¶		skipping to change at page 6, line 51 ¶
	of MD5 in HMAC.		of MD5 in HMAC.
	2.2.2 HMAC SHA Variations		2.2.2 HMAC SHA Variations
	Identifiers:		Identifiers:
	http://www.w3.org/2001/04/xmldsig-more#hmac-sha224		http://www.w3.org/2001/04/xmldsig-more#hmac-sha224
	http://www.w3.org/2001/04/xmldsig-more#hmac-sha256		http://www.w3.org/2001/04/xmldsig-more#hmac-sha256
	http://www.w3.org/2001/04/xmldsig-more#hmac-sha384		http://www.w3.org/2001/04/xmldsig-more#hmac-sha384
	http://www.w3.org/2001/04/xmldsig-more#hmac-sha512		http://www.w3.org/2001/04/xmldsig-more#hmac-sha512
	SHA-224, SHA-256, SHA-384, and SHA-512 [FIPS 180-2, RFC sha224] can		SHA-224, SHA-256, SHA-384, and SHA-512 [FIPS 180-2, FIPS 180-2change,
	also be used in HMAC as described in section 2.2.1 above for HMAC-		RFC 3874] can also be used in HMAC as described in section 2.2.1
	MD5.		above for HMAC-MD5.
	INTERNET-DRAFT Additional XML Security URIs		INTERNET-DRAFT Additional XML Security URIs
	2.2.3 HMAC-RIPEMD160		2.2.3 HMAC-RIPEMD160
	Identifier:		Identifier:
	http://www.w3.org/2001/04/xmldsig-more#hmac-ripemd160		http://www.w3.org/2001/04/xmldsig-more#hmac-ripemd160
	RIPEMD-160 [RIPEMD-160] can also be used in HMAC as described in		RIPEMD-160 [RIPEMD-160] can also be used in HMAC as described in
	section 2.2.1 above for HMAC-MD5.		section 2.2.1 above for HMAC-MD5.
	skipping to change at page 7, line 50 ¶		skipping to change at page 7, line 50 ¶
	the hash function, but the availability of an ASN.1 parser and		the hash function, but the availability of an ASN.1 parser and
	recognition of OIDs is not required of a signature verifier. The		recognition of OIDs is not required of a signature verifier. The
	PKCS#1 v1.5 representation appears as:		PKCS#1 v1.5 representation appears as:
	CRYPT (PAD (ASN.1 (OID, DIGEST (data))))		CRYPT (PAD (ASN.1 (OID, DIGEST (data))))
	Note that the padded ASN.1 will be of the following form:		Note that the padded ASN.1 will be of the following form:
	01 | FF* | 00 | prefix | hash		01 | FF* | 00 | prefix | hash
	where "|" is concatenation, "01", "FF", and "00" are fixed octets of		Vertical bar ("|") represents concatenation. "01", "FF", and "00" are
	the corresponding hexadecimal value, "hash" is the MD5 digest of the		fixed octets of the corresponding hexadecimal value and the asterisk
	data, and "prefix" is the ASN.1 BER MD5 algorithm designator prefix		("*") after "FF" indicates repetition. "hash" is the MD5 digest of
	INTERNET-DRAFT Additional XML Security URIs		INTERNET-DRAFT Additional XML Security URIs
			the data. "prefix" is the ASN.1 BER MD5 algorithm designator prefix
	required in PKCS #1 [RFC 2437], that is,		required in PKCS #1 [RFC 2437], that is,
	hex 30 20 30 0c 06 08 2a 86 48 86 f7 0d 02 05 05 00 04 10		hex 30 20 30 0c 06 08 2a 86 48 86 f7 0d 02 05 05 00 04 10
	This prefix is included to make it easier to use standard		This prefix is included to make it easier to use standard
	cryptographic libraries. The FF octet MUST be repeated the maximum		cryptographic libraries. The FF octet MUST be repeated enough times
	number of times such that the value of the quantity being CRYPTed is		that the value of the quantity being CRYPTed is exactly one octet
	one octet shorter than the RSA modulus.		shorter than the RSA modulus.
	Due to increases in computer processor power and advances in		Due to increases in computer processor power and advances in
	cryptography, use of RSA-MD5 is NOT RECOMMENDED.		cryptography, use of RSA-MD5 is NOT RECOMMENDED.
	2.3.2 RSA-SHA256		2.3.2 RSA-SHA256
	Identifier:		Identifier:
	http://www.w3.org/2001/04/xmldsig-more#rsa-sha256		http://www.w3.org/2001/04/xmldsig-more#rsa-sha256
	This implies the PKCS#1 v1.5 padding algorithm [RFC 2437] as		This implies the PKCS#1 v1.5 padding algorithm [RFC 2437] as
	skipping to change at page 8, line 45 ¶		skipping to change at page 8, line 46 ¶
	This implies the PKCS#1 v1.5 padding algorithm [RFC 2437] as		This implies the PKCS#1 v1.5 padding algorithm [RFC 2437] as
	described in section 2.3.1 but with the ASN.1 BER SHA-384 algorithm		described in section 2.3.1 but with the ASN.1 BER SHA-384 algorithm
	designator prefix. An example of use is		designator prefix. An example of use is
	<SignatureMethod		<SignatureMethod
	Algorithm="http://www.w3.org/2001/04/xmldsig-more#rsa-sha384"		Algorithm="http://www.w3.org/2001/04/xmldsig-more#rsa-sha384"
	/>		/>
	Because it takes about the same effort to calculate a SHA-384 message		Because it takes about the same effort to calculate a SHA-384 message
	digest as it does a SHA-512 message digest, it is suggested that		digest as it does a SHA-512 message digest, it is suggested that RSA-
	RSA-SHA512 be used in preference to RSA-SHA384 where possible.		SHA512 be used in preference to RSA-SHA384 where possible.
	INTERNET-DRAFT Additional XML Security URIs		INTERNET-DRAFT Additional XML Security URIs
	2.3.4 RSA-SHA512		2.3.4 RSA-SHA512
	Identifier:		Identifier:
	http://www.w3.org/2001/04/xmldsig-more#rsa-sha512		http://www.w3.org/2001/04/xmldsig-more#rsa-sha512
	This implies the PKCS#1 v1.5 padding algorithm [RFC 2437] as		This implies the PKCS#1 v1.5 padding algorithm [RFC 2437] as
	described in section 2.3.1 but with the ASN.1 BER SHA-512 algorithm		described in section 2.3.1 but with the ASN.1 BER SHA-512 algorithm
	skipping to change at page 10, line 33 ¶		skipping to change at page 10, line 33 ¶
	2.4 Minimal Canonicalization		2.4 Minimal Canonicalization
	Thus far two independent interoperable implementations of Minimal		Thus far two independent interoperable implementations of Minimal
	Canonicalization have not been announced. Therefore, when XML		Canonicalization have not been announced. Therefore, when XML
	Digital Signature was advanced from Proposed Standard [RFC 3075] to		Digital Signature was advanced from Proposed Standard [RFC 3075] to
	Draft Standard [RFC 3275], Minimal Canonicalization was dropped from		Draft Standard [RFC 3275], Minimal Canonicalization was dropped from
	the standard track documents. However, there is still interest and		the standard track documents. However, there is still interest and
	indicates of possible future use for Minimal Canonicalization. For		indicates of possible future use for Minimal Canonicalization. For
	its definition, see [RFC 3075], Section 6.5.1.		its definition, see [RFC 3075], Section 6.5.1.
	For reference, it's identifier remains:		For reference, it‚ÇÖs identifier remains:
	http://www.w3.org/2000/09/xmldsig#minimal		http://www.w3.org/2000/09/xmldsig#minimal
	2.5 Transform Algorithms		2.5 Transform Algorithms
	Note that all CanonicalizationMethod algorithms can also be used as		Note that all CanonicalizationMethod algorithms can also be used as
	Transform algorithms.		Transform algorithms.
	2.5.1 XPointer		2.5.1 XPointer
	Identifier:		Identifier:
	skipping to change at page 11, line 40 ¶		skipping to change at page 11, line 40 ¶
	This subsection gives identifiers and information for several		This subsection gives identifiers and information for several
	EncryptionMethod Algorithms.		EncryptionMethod Algorithms.
	2.6.1 ARCFOUR Encryption Algorithm		2.6.1 ARCFOUR Encryption Algorithm
	Identifier:		Identifier:
	http://www.w3.org/2001/04/xmldsig-more#arcfour		http://www.w3.org/2001/04/xmldsig-more#arcfour
	ARCFOUR is a fast, simple stream encryption algorithm that is		ARCFOUR is a fast, simple stream encryption algorithm that is
	compatible with RSA Security's RC4 algorithm. An example		compatible with RSA Security‚ÇÖs RC4 algorithm. An example
	EncryptionMethod element using ARCFOUR is		EncryptionMethod element using ARCFOUR is
	<EncryptionMethod		<EncryptionMethod
	Algorithm="http://www.w3.org/2001/04/xmldsig-more#arcfour">		Algorithm="http://www.w3.org/2001/04/xmldsig-more#arcfour">
	<KeySize>40<KeySize>		<KeySize>40<KeySize>
	</EncryptionMethod>		</EncryptionMethod>
	Note that Arcfour makes use of the generic KeySize parameter		Note that Arcfour makes use of the generic KeySize parameter
	specified and defined in [XMLENC].		specified and defined in [XMLENC].
	skipping to change at page 15, line 29 ¶		skipping to change at page 15, line 29 ¶
	5. Security Considerations		5. Security Considerations
	Due to computer speed and cryptographic advances, the use of MD5 as a		Due to computer speed and cryptographic advances, the use of MD5 as a
	DigestMethod or in the RSA-MD5 SignatureMethod is NOT RECOMMENDED.		DigestMethod or in the RSA-MD5 SignatureMethod is NOT RECOMMENDED.
	The cryptographic advances concerned do not effect the security of		The cryptographic advances concerned do not effect the security of
	HMAC-MD5; however, there is little reason not to go for one of the		HMAC-MD5; however, there is little reason not to go for one of the
	SHA series of algorithms.		SHA series of algorithms.
	6. Copyright and Disclaimer		6. Copyright and Disclaimer
	Copyright (C) The Internet Society 2004. This document is subject to		Copyright (C) 2004 The Internet Society. This document is subject to
	the rights, licenses and restrictions contained in BCP 78, and except		the rights, licenses and restrictions contained in BCP 78 and except
	as set forth therein, the authors retain all their rights.		as set forth therein, the authors retain all their rights.
	This document and the information contained herein are provided on an		This document and the information contained herein are provided on an
	"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS		"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
	OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET		OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
	ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,		ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
	INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE		INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
	INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED		INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
	WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.		WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
	skipping to change at page 16, line 27 ¶		skipping to change at page 16, line 27 ¶
	Karlinger, T. Kobayashi, Y. Want, January 2004. draft-blake-wilson-		Karlinger, T. Kobayashi, Y. Want, January 2004. draft-blake-wilson-
	xmldsig-ecdsa-*.txt		xmldsig-ecdsa-*.txt
	[FIPS 180-1] - "Secure Hash Standard", (SHA-1) US Federal Information		[FIPS 180-1] - "Secure Hash Standard", (SHA-1) US Federal Information
	Processing Standard, 17 April 1995.		Processing Standard, 17 April 1995.
	[FIPS 180-2] - "Secure Hash Standard", (SHA-1/256/384/512) US Federal		[FIPS 180-2] - "Secure Hash Standard", (SHA-1/256/384/512) US Federal
	Information Processing Standard, Draft, not yet issued.		Information Processing Standard, Draft, not yet issued.
	[FIPS 180-2change] - "FIPS 180-2, Secure Hash Standard Change Notice		[FIPS 180-2change] - "FIPS 180-2, Secure Hash Standard Change Notice
	1", proposes adding SHA-224 to [FIPS 180-2].		1", adds SHA-224 to [FIPS 180-2].
	[FIPS 186-2] - "Digital Signature Standard", National Institute of		[FIPS 186-2] - "Digital Signature Standard", National Institute of
	Standards and Technology, 2000.		Standards and Technology, 2000.
	[IEEE P1363a] - "Standard Specifications for Public Key Cryptography:		[IEEE P1363a] - "Standard Specifications for Public Key Cryptography:
	Additional Techniques", October 2002.		Additional Techniques", October 2002.
	[ISO/IEC 18033-2] - "Information technology -- Security techniques --		[ISO/IEC 18033-2] - "Information technology -- Security techniques --
	Encryption algorithms -- Part 3: Asymmetric ciphers", CD, October		Encryption algorithms -- Part 3: Asymmetric ciphers", CD, October
	2002.		2002.
	skipping to change at page 17, line 24 ¶		skipping to change at page 17, line 24 ¶
	[RFC 3275] - "XML-Signature Syntax and Processing", D. Eastlake, J.		[RFC 3275] - "XML-Signature Syntax and Processing", D. Eastlake, J.
	Reagle, D. Solo, March 2002.		Reagle, D. Solo, March 2002.
	[RFC 3394] - "Advanced Encryption Standard (AES) Key Wrap Algorithm",		[RFC 3394] - "Advanced Encryption Standard (AES) Key Wrap Algorithm",
	J. Schaad, R. Housley, September 2002.		J. Schaad, R. Housley, September 2002.
	[RFC 3713] - "A Description of the Camellia Encryption Algorithm", M.		[RFC 3713] - "A Description of the Camellia Encryption Algorithm", M.
	Matsui, J. Nakajima, S. Moriai, April 2004.		Matsui, J. Nakajima, S. Moriai, April 2004.
	[RFC sha224] - "A 224-bit One-way Hash Function: SHA-224", R.		[RFC 3874] - "A 224-bit One-way Hash Function: SHA-224", R. Housley,
	Housley, December 2003, draft-ietf-pkix-sha224-*.txt.		September 2004.
	[RIPEMD-160] - ISO/IEC 10118-3:1998, "Information Technology -		[RIPEMD-160] - ISO/IEC 10118-3:1998, "Information Technology -
	Security techniques - Hash-functions - Part3: Dedicated hash-		Security techniques - Hash-functions - Part3: Dedicated hash-
	functions", ISO, 1998.		functions", ISO, 1998.
	[X9.62] - X9.62-200X, "Public Key Cryptography for the Financial		[X9.62] - X9.62-200X, "Public Key Cryptography for the Financial
	Services Industry: The Elliptic Curve Digital Signature Algorithm		Services Industry: The Elliptic Curve Digital Signature Algorithm
	(ECDSA)", Accredited Standards Committee X9, American National		(ECDSA)", Accredited Standards Committee X9, American National
	Standards Institute.		Standards Institute.
	skipping to change at page 18, line 7 ¶		skipping to change at page 18, line 7 ¶
	<http://www.w3.org/TR/2001/REC-xml-c14n-20010315>.		<http://www.w3.org/TR/2001/REC-xml-c14n-20010315>.
	[EXCANON] - "Exclusive XML Canonicalization Version 1.0", D.		[EXCANON] - "Exclusive XML Canonicalization Version 1.0", D.
	Eastlake, J. Reagle, 18 July 2002. <http://www.w3.org/TR/REC-xml-		Eastlake, J. Reagle, 18 July 2002. <http://www.w3.org/TR/REC-xml-
	enc-c14n-20020718/>.		enc-c14n-20020718/>.
	[RFC 3076] - "Canonical XML Version 1.0", J. Boyer, March 2001.		[RFC 3076] - "Canonical XML Version 1.0", J. Boyer, March 2001.
	INTERNET-DRAFT Additional XML Security URIs		INTERNET-DRAFT Additional XML Security URIs
	[RFC 3092] - "Etymology of 'Foo'", D. Eastlake 3rd, C. Manros, E.		[RFC 3092] - "Etymology of ‚ÇÖFoo‚ÇÖ", D. Eastlake 3rd, C. Manros, E.
	Raymond, 1 April 2001.		Raymond, 1 April 2001.
	[RFC 3741] - "Exclusive XML Canonicalization Version 1.0", J. Boyer,		[RFC 3741] - "Exclusive XML Canonicalization Version 1.0", J. Boyer,
	D. Eastlake 3rd, J. Reagle, March 2004.		D. Eastlake 3rd, J. Reagle, March 2004.
	INTERNET-DRAFT Additional XML Security URIs		INTERNET-DRAFT Additional XML Security URIs
	Author's Address		Author‚ÇÖs Address
	Donald E. Eastlake 3rd		Donald E. Eastlake 3rd
	Motorola Laboratories		Motorola Laboratories
	155 Beaver Street		155 Beaver Street
	Milford, MA 01757 USA		Milford, MA 01757 USA
	Telephone: +1-508-786-7554 (w)		Telephone: +1-508-786-7554 (w)
	+1-508-634-2066 (h)		+1-508-634-2066 (h)
	EMail: Donald.Eastlake@motorola.com		EMail: Donald.Eastlake@motorola.com
	Expiration and File Name		Expiration and File Name
	This draft expires in December 2004.		This draft expires in March 2005.
	Its file name is draft-eastlake-xmldsig-uri-08.txt		Its file name is draft-eastlake-xmldsig-uri-09.txt
End of changes. 25 change blocks.
	40 lines changed or deleted		42 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/