draft-ietf-xmldsig-requirements-02.txt   rfc2807.txt 
XML Digital Signatures Working Group J. Reagle,
INTERNET-DRAFT W3C/MIT
draft-ietf-xmldsig-requirements-02.txt
Expires April 14, 1999
XML-Signature Requirements
Copyright Notice
Copyright (c) 1999 The Internet Society & W3C (MIT, INRIA, Keio), All
Rights Reserved.
IETF Status of this Memo Network Working Group J. Reagle
Request for Comments: 2807 W3C/MIT
This document is an Internet-Draft and is in full conformance with all Category: Informational July 2000
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
Force (IETF), its areas, and its working groups. Note that other
groups may also distribute working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet- Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at XML Signature Requirements
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at Status of this Memo
http://www.ietf.org/shadow.html.
W3C Status of this document This memo provides information for the Internet community. It does
not specify an Internet standard of any kind. Distribution of this
memo is unlimited.
This Working Draft of XML Signature Requirements is a very stable Copyright Notice
result of this Working Draft having been advanced through W3C Last
Call. Relatively small changes have been made to clarify the stated
requirements during that period. This document will now be advanced as
an IETF Informational RFC.
Please send comments to the editor <reagle@w3.org> and cc: the list Copyright (c) 2000 The Internet Society & W3C (MIT, INRIA, Keio), All
<w3c-ietf-xmldsig@w3.org>. Publication as a Working Draft does not Rights Reserved.
imply endorsement by the W3C membership. This is a draft document and
may be updated, replaced or obsoleted by other documents at any time.
It is inappropriate to cite W3C Drafts as other than "work in
progress". A list of current W3C working drafts can be found at
http://www.w3.org/TR
Abstract Abstract
This document lists the design principles, scope, and requirements for This document lists the design principles, scope, and requirements
the XML Digital Signature specification. It includes requirements as for the XML Digital Signature specification. It includes requirements
they relate to the signature syntax, data model, format, cryptographic as they relate to the signature syntax, data model, format,
processing, and external requirements and coordination. cryptographic processing, and external requirements and coordination.
Table of Contents Table of Contents
1. Introduction 1. Introduction .............................................. 1
2. Design Principles and Scope 2. Design Principles and Scope ............................... 2
3. Requirements 3. Requirements .............................................. 4
3.1 Signature Data Model and Syntax 3.1. Signature Data Model and Syntax .................... 4
3.2 Format 3.2. Format ............................................. 5
3.3 Cryptography and Processing 3.3. Cryptography and Processing ........................ 5
3.4 Coordination 3.4 Coordination ........................................ 5
4. References 4. Security Considerations ................................... 6
5. References ................................................ 6
6. Acknowledgements .......................................... 8
7. Author's Address .......................................... 8
8. Full Copyright Statement .................................. 9
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
content and procedures for computing and verifying such signatures. digital content and procedures for computing and verifying such
Signatures will provide data integrity, authentication, and/or signatures. Signatures will provide data integrity, authentication,
non-repudiatability. and/or non-repudiability.
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
are designated as "must," those things that are optional are required 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
syntax and processing rules necessary for communicating and processing rules necessary for communicating signature
signature validity (authenticity, integrity and validity (authenticity, integrity and non-repudiation).
non-repudiation). [Charter(Requirement1)] At the Chairs' [Charter(Requirement1)] At the Chairs' discretion and in order
discretion and in order to test the extensibility of the to test the extensibility of the syntax, the WG may produce
syntax, the WG may produce non-critical-path proposals non-critical-path proposals defining common semantics (e.g.,
defining common semantics (e.g., manifest, package, manifest, package, timestamps, endorsement, etc.) relevant to
timestamps, endorsement, etc.) relevant to signed assertions signed assertions about Web resources in a schema definition
about Web resources in a schema definition [XML, RDF] or link [XML, RDF] or link type definition [XLink].
type definition [XLink]. Comment: A more formal definition of a signed resource is below.
Comment: A more formal definition of a signed resource is below. The notation is "definition(inputs):constraints" where definition
The notation is "definition(inputs):constraints" where definition evaluates as true for the given inputs and specified constraints.
evaluates as true for the given inputs and specified constraints. signed-resource(URI-of-resource, content, key, signature): (there
signed-resource(URI-of-resource, content, key, signature): (there was some protocol message at a specific time such that "GET(URI-
was some protocol message at a specific time such that of-resource) = content") AND (sign-doc(content, key, sig))
"GET(URI-of-resource) = content") AND (sign-doc(content, key, sign-doc(content, key, signature): signature is the value of a
sig)) strong one-way transformation over content and key that yields
sign-doc(content, key, signature): signature is the value of a content integrity/validity and/or key non-repudiability
strong one-way transformation over content and key that yields 4. The specification must not specify methods of confidentiality
content integrity/validity and/or key non-repudiability though the Working Group may report on the feasibility of such
4. The specification must not specify methods of confidentiality work in a future or rechartered activity. [List(Bugbee)]
though the Working Group may report on the feasibility of such 5. The specification must only require the provision of key
work in a future or rechartered activity. [List(Bugbee)] information essential to checking the validity of the
5. The specification must only require the provision of key cryptographic signature. For instance, identity and key recovery
information essential to checking the validity of the information might be of interest to particular applications, but
cryptographic signature. For instance, identity and key recovery they are not within the class of required information defined in
information might be of interest to particular applications, but this specification. [List(Reagle)]
they are not within the class of required information defined in 6. The specification must define or reference at least one method of
this specification. [List(Reagle)] canonicalizing and hashing the signature syntax (i.e., the
6. The specification must define or reference at least one method of manifest and signature blocks). [Oslo] The specification must not
canonicalizing and hashing the signature syntax (i.e., the specify methods of canonicalizing resource content [Charter],
manifest and signature blocks). [Oslo] The specification must not though it may specify security requirements over such methods.
specify methods of canonicalizing resource content [Charter], [Oslo] Such content is normalized by specifying an appropriate
though it may specify security requirements over such methods. content C14N (canonicalization) algorithm [DOMHASH, XML-C14N].
[Oslo] Such content is normalized by specifying an appropriate Applications are expected to normalize application specific
content C14N (canonicalization) algorithm [DOMHASH, XML-C14N]. semantics prior to handing data to a XML Signature application or
Applications are expected to normalize application specific specify the necessary transformations for this process within the
semantics prior to handing data to a XML-signature application or signature. [Charter]
specify the necessary transformations for this process within the 7. XML Signature applications must be conformant with the
signature. [Charter] specifications as follows:
7. XML-signature applications must be conformant with the 1. XML-namespaces [XML-namespaces] within its own signature
specifications as follows: syntax. Applications may choose C14N algorithms which do or do
1. XML-namespaces [XML-namespaces] within its own signature not process namespaces within XML content. For instance, some
syntax. Applications may choose C14N algorithms which do or C14N algorithms may opt to remove all namespace declarations,
do not process namespaces within XML content. For instance, others may rewrite namespace declarations to provide for
some C14N algorithms may opt to remove all namespace context independent declarations within every element.
declarations, others may rewrite namespace declarations to 2. XLink [Xlink] within its own signature syntax. For any resource
provide for context independent declarations within every identification beyond simple URIs (without fragment IDs) or
element. fragmentIDs, applications must use XLink locators to reference
2. XLink [Xlink] within its own signature syntax. For any signed resources. Signature applications must not embed or
resource identification beyond simple URIs (without fragment expand XLink references in signed content, though applications
IDs) or fragmentIDs, applications must use XLink locators to may choose C14N algorithms which provide this feature.
reference signed resources. Signature applications must not 3. XML-Pointers [XPointer] within its own signature syntax. If
embed or expand XLink references in signed content, though applications reference/select parts of XML documents, they must
applications may choose C14N algorithms which provide this use XML-Pointer within an XLink locator. [WS-list(1)]
feature. The WG may specify security requirements that constrain the
3. XML-Pointers [XPointer] within its own signature syntax. If operation of these dependencies to ensure consistent and secure
applications reference/select parts of XML documents, they signature generation and operation. [Oslo]
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)]
3 Requirements 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)]
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
Comment: A related requirement under consideration is requiring under consideration is requiring the specification to support the
the specification to support the ability to indicate those ability to indicate those portions of a document one signs via
portions of a document one signs via exclusion of those portions exclusion of those portions one does not wish to sign. This
one does not wish to sign. This feature allows one to create feature allows one to create signatures that have document closure
signatures that have document closure [List(Boyer(1)], retain [List(Boyer(1)], retain ancestor information, and retain element
ancestor information, and retain element order of non-continuous order of non-continuous regions that must be signed. We are
regions that must be signed. We are considering implementing this considering implementing this requirement via (1) a special
requirement via (1) a special <dsig:exclude> element, (2) an <dsig:exclude> element, (2) an exclude list accompanying the
exclude list accompanying the resource locator, or (3) the resource locator, or (3) the XML-Fragment or XPointer
XML-Fragment or XPointer specifications -- or a requested change specifications -- or a requested change to those specifications if
to those specifications if the functionality is not available. See the functionality is not available. See List(Boyer(1,2)) for
List(Boyer(1,2)) for further discussion of this issue. 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, transformations, 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-repudiability) 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]
2. The specification must specify at least one mandatory to implement 2. The specification must specify at least one mandatory to implement
signature canonicalization, content canonicalization, hash, and signature canonicalization, content canonicalization, hash, and
signature algorithm. signature algorithm.
3. In the event of redundant attributes within the XML Signature 3. In the event of redundant attributes within the XML Signature
syntax and relevant cryptographic blobs, XML Signature syntax and relevant cryptographic blobs, XML Signature
applications prefer the XML Signature semantics. applications prefer the XML Signature semantics. Comment: Another
Comment: Another possibility is that an error should be generated, possibility is that an error should be generated, however it isn't
however it isn't where a conflict will be flagged between the where a conflict will be flagged between the various function and
various function and application layers regardless. application layers regardless.
4. The signature design and specification text must not permit 4. The signature design and specification text must not permit
implementers to erroneously build weak implementations susceptible implementers to erroneously build weak implementations susceptible
to common security weaknesses (such as as downgrade or algorithm to common security weaknesses (such as as downgrade or algorithm
substitution attacks). substitution attacks).
3.4 Coordination 3.4 Coordination
1. The XML Signature specification should meet the requirements of 1. The XML Signature specification should meet the requirements of
the following applications: the following applications:
1. Internet Open Trading Protocol v1.0 [IOTP] 1. Internet Open Trading Protocol v1.0 [IOTP]
2. Financial Services Mark Up Language v2.0 [Charter] 2. Financial Services Mark Up Language v2.0 [Charter]
3. At least one forms application [XFA, XFDL] 3. At least one forms application [XFA, XFDL]
2. To ensure that all requirements within this document are
adequately addressed, the XML Signature specification must be 2. To ensure that all requirements within this document are
reviewed by a designated member of the following communities: adequately addressed, the XML Signature specification must be
reviewed by a designated member of the following communities:
1. XML Syntax Working Group: canonicalization dependencies. 1. XML Syntax Working Group: canonicalization dependencies.
[Charter] [Charter]
2. XML Linking Working Group: signature referants. [Charter] 2. XML Linking Working Group: signature referents. [Charter]
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
AC Review This document lists XML Digital Signature requirements as they relate
Misha Wolf. "The Charter should include the I18N WG in the to the signature syntax, data model, format, cryptographic
section on 'Coordination with Other Groups.'" processing, and external requirements and coordination. In that
http://lists.w3.org/Archives/Team/xml-dsig-review/1999May/0007. context much of this document is about security.
html
Berners-Lee 5. References
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 AC Review Misha Wolf. "The Charter should include the I18N WG
Internet Draft. Digital Signatures for XML in the section on `Coordination with Other
http://search.ietf.org/internet-drafts/draft-ietf-xmldsig-signa Groups'", http://lists.w3.org/Archives/Team/xml-
ture-00.txt dsig-review/1999May/0007.html
Charter Berners-Lee Axioms of Web Architecture: URIs.
XML Signature (xmldsig) Charter. http://www.w3.org/DesignIssues/Axioms.html Web
http://www.w3.org/1999/05/XML-DSig-charter-990521.html Architecture from 50,000 feet
http://www.w3.org/DesignIssues/Architecture.html
DOMHASH Brown-XML-DSig Work in Progress. Digital Signatures for XML
Internet Draft. Digest Values for DOM (DOMHASH) http://www.w3.org/Signature/Drafts/xmldsig-
http://search.ietf.org/internet-drafts/draft-hiroshi-dom-hash-0 signature-990618.html
1.txt
FSML Charter XML Signature (xmldsig) Charter.
FSML 1.5 Reference Specification http://www.w3.org/1999/05/XML-DSig-charter-
http://www.echeck.org/library/ref/fsml-v1500a.pdf 990521.html
Infoset-Req DOMHASH Maruyama, H., Tamura, K. and N. Uramoto, "Digest
XML Information Set Requirements Note. Values for DOM (DOMHASH)", RFC 2803, April 2000.
http://www.w3.org/TR/1999/NOTE-xml-infoset-req-19990218.html
IOTP FSML FSML 1.5 Reference Specification
Internet Open Trading Protocol v1.0 http://www.echeck.org/library/ref/fsml-v1500a.pdf
http://www.ietf.org/internet-drafts/draft-ietf-trade-iotp-v1.0-
protocol-04.txt
IOTP-DSig Infoset-Req XML Information Set Requirements Note.
Internet Draft. Digital Signatures for the Internet Open http://www.w3.org/TR/1999/NOTE-xml-infoset-req-
Trading Protocol 19990218.html
http://www.ietf.org/internet-drafts/draft-ietf-trade-iotp-v1.0-
dsig-00.txt
Oslo IOTP Burdett, D., "Internet Open Trading Protocol - IOTP
Minutes of the XML Signature WG Sessions at IETF face-to-face Version 1.0", RFC 2801, April 2000.
meeting in Oslo.
RDF IOTP-DSig Davidson, K. and Y. Kawatsura, "Digital Signatures
RDF Schema for the v1.0 Internet Open Trading Protocol
http://www.w3.org/TR/1999/PR-rdf-schema-19990303 (IOTP)", RFC 2802, April 2000.
RDF Model and Syntax
http://www.w3.org/TR/1999/REC-rdf-syntax-19990222
Signature WG List Oslo Minutes of the XML Signature WG Sessions at IETF
http://lists.w3.org/Archives/Public/w3c-ietf-xmldsig/ face-to-face meeting in Oslo.
URI RDF RDF Schema
Uniform Resource Identifiers (URI): Generic Syntax http://www.w3.org/TR/1999/PR-rdf-schema-19990303
http://www.ietf.org/rfc/rfc2396.txt RDF Model and Syntax
http://www.w3.org/TR/1999/REC-rdf-syntax-19990222
WS (list, summary) Signature WG List http://lists.w3.org/Archives/Public/w3c-ietf-
XML-DSig '99: The W3C Signed XML Workshop xmldsig/
http://www.w3.org/DSig/signed-XML99/
http://www.w3.org/DSig/signed-XML99/summary.html
XLink URI Berners-Lee, T., Fielding, R. and L. Masinter,
XML Linking Language "Uniform Resource Identifiers (URI): Generic
http://www.w3.org/1999/07/WD-xlink-19990726 Syntax", RFC 2396, August 1998.
http://www.ietf.org/rfc/rfc2396.txt
XML WS
Extensible Markup Language (XML) Recommendation. (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
http://www.w3.org/TR/1998/REC-xml-19980210 XLink XML
Linking Language http://www.w3.org/1999/07/WD-xlink-19990726
XML-C14N XML Extensible Markup Language (XML) Recommendation.
XML Canonicalization Requirements. http://www.w3.org/TR/1998/REC-xml-19980210
http://www.w3.org/TR/1999/NOTE-xml-canonical-req-19990605
XFA XML-C14N XML Canonicalization Requirements.
XML Forms Architecture (XFA) http://www.w3.org/TR/1999/NOTE-xml-canonical-req-
http://www.w3.org/Submission/1999/05/ 19990605
XFDL XFA XML Forms Architecture (XFA)
Extensible Forms Description Language (XFDL) 4.0 http://www.w3.org/Submission/1999/05/
http://www.w3.org/Submission/1998/16/
XML-Fragment XFDL Extensible Forms Description Language (XFDL) 4.0
XML-Fragment Interchange http://www.w3.org/Submission/1998/16/
http://www.w3.org/1999/06/WD-xml-fragment-19990630.html
XML-namespaces XML-Fragment XML-Fragment Interchange
Namespaces in XML http://www.w3.org/1999/06/WD-xml-fragment-
http://www.w3.org/TR/1999/REC-xml-names-19990114 19990630.html
XML-schema XML-namespaces Namespaces in XML
XML Schema Part 1: Structures http://www.w3.org/TR/1999/REC-xml-names-19990114
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-schema XML Schema Part 1: Structures
XML Pointer Language (XPointer) http://www.w3.org/1999/05/06-xmlschema-1/
http://www.w3.org/1999/07/WD-xptr-19990709 XML Schema Part 2: Datatypes
http://www.w3.org/1999/05/06-xmlschema-2/
WebData XPointer XML Pointer Language (XPointer)
Web Architecture: Describing and Exchanging Data. http://www.w3.org/1999/07/WD-xptr-19990709
http://www.w3.org/1999/04/WebData
WebData Web Architecture: Describing and Exchanging Data.
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
EMail: reagle@w3.org
URL: http://www.w3.org/People/Reagle
8. Full Copyright Statement
Copyright (c) 2000 The Internet Society & W3C (MIT, INRIA, Keio), 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.
Acknowledgement
Funding for the RFC Editor function is currently provided by the
Internet Society.
 End of changes. 49 change blocks. 
335 lines changed or deleted 279 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/