draft-ietf-xmldsig-requirements-01.txt   draft-ietf-xmldsig-requirements-02.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-01.txt draft-ietf-xmldsig-requirements-02.txt
Expires March 20, 1999 Expires April 14, 1999
XML-Signature Requirements XML-Signature Requirements
Copyright Notice Copyright Notice
Copyright (c) 1999 The Internet Society & W3C (MIT, INRIA, Keio), All Copyright (c) 1999 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
provisions of Section 10 of RFC2026.
This document is a production of the joint IETF/W3C XML Signature This document is a production of the joint IETF/W3C XML Signature
Working Group. Working Group.
http://www.w3.org/Signature http://www.w3.org/Signature
The latest version of this draft series may be found at: The comparable html draft of this version may be found at
http://www.w3.org/TR/1999/xml-dsig-requirements http://www.w3.org/TR/1999/WD-xmldsig-requirements-19991014
This document is an Internet-Draft and is in full conformance with all The latest version of this draft series may be found at:
provisions of Section 10 of RFC2026.
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 is a Last Call XML Signature Requirements public Working Draft. This Working Draft of XML Signature Requirements is a very stable
This report is not expected to be advanced to Recommendation. Instead, result of this Working Draft having been advanced through W3C Last
this Last Call designation is (1) a representation of WG consensus, Call. Relatively small changes have been made to clarify the stated
(2) an invitation for comments that will affect the future course of requirements during that period. This document will now be advanced as
the technical specification, and (3) an opportunity to identify and an IETF Informational RFC.
obtain commitments regarding WG dependencies. This document will be
referred to at least the W3C XML Plenary Interest Group and W3C Chairs
Working Group. Last Call period ends when dependencies between WGs
have been acknowledged and the Signature Chairs have procured
commitments of review. This is expected to take six weeks from the
date of publication.
This document attempts to capture the Working Group's consensus though
it contains points which are still uncertain or not well
specified. Issues which are still being actively discussed during the
publication of this document are of class="discuss" and rendered in
navy by style sheet compliant applications.
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
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. 1. Introduction 1. Introduction
2. 2. Design Principles and Scope 2. Design Principles and Scope
3. 3. Requirements 3. Requirements
3.1 1. Signature Data Model and Syntax 3.1 Signature Data Model and Syntax
3.2 2. Format 3.2 Format
3.3 3. Cryptography and Processing 3.3 Cryptography and Processing
3.4 4. Coordination 3.4 Coordination
4. 4. References 4. References
1 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 2. Design Principles and Scope 2 Design Principles and Scope
1. The specification must describe how to a sign digital content, and 1. The specification must describe how to sign digital content, and
XML content in particular. [Charter] XML content in particular. The XML syntax used to represent a
signature (over any content) is described as an XML-signature.
[Charter]
2. XML-signatures are generated from a hash over the canonical form 2. XML-signatures are generated from a hash over the canonical form
of a signature manifest. The manifest must support references to of a signature manifest. (In this document we use the term
Web resources, the hash of the resource content (or its manifest to mean a collection of references to the objects being
canonicalized form), and (optionally) the resource content type. signed. The specifications may use the terms manifest, package or
[Brown, List(Solo)] Web resources are defined as any digital other terms differently from this document while still meeting
content content that can be addressed using the syntax of XLink this requirement.) The manifest must support references to Web
locator [XLink]). resources, the hash of the resource content (or its canonicalized
Comment: Scenarios are being explored which examine the ability to form), and (optionally) the resource content type. [Brown,
sign without requiring a manifest whereas the scope of the signed List(Solo)] Web resources are defined as any digital content that
content is designated by the relative placement of signature can be addressed using the syntax of XLink locator [XLink]).
elements in the XML stream/tree. For instance:
<html> .....</body><dsig xmlns="http://..." referent=""><html>.
or
<html><title>pricelist</title>...<dsig xmlns="http://..."> ...
</dsig></html>
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-standard-track proposals syntax, the WG may produce non-critical-path proposals
defining common semantics (e.g., package, timestamps, defining common semantics (e.g., manifest, package,
endorsement, etc.) relevant to signed assertions about Web timestamps, endorsement, etc.) relevant to signed assertions
resources in a schema definition [XML, RDF] or link type about Web resources in a schema definition [XML, RDF] or link
definition [XLink]. type definition [XLink].
Comment: A more formal definition of a signed resource is the Comment: A more formal definition of a signed resource is below.
following evaluates as true "definition(inputs):constraints" where The notation is "definition(inputs):constraints" where definition
R is a resource., I is a resource identifier (URI), and C is evaluates as true for the given inputs and specified constraints.
content (sequence-of-octects). signed-resource(URI-of-resource, content, key, signature): (there
signed-resource(I, C, key, sig): there was some request R such was some protocol message at a specific time such that
that GET(R) = C and address(R) = I and sign-doc(C, key, sig) "GET(URI-of-resource) = content") AND (sign-doc(content, key,
sign-doc(C, key, sig): sig is the value of a strong one-way sig))
function over content and key that yields C integrity/validity and sign-doc(content, key, signature): signature is the value of a
K non-repudiability strong one-way transformation over content and key that yields
content integrity/validity and/or key non-repudiability
4. The specification must not specify methods of confidentiality 4. The specification must not specify methods of confidentiality
though the Working Group may report on the feasibility of such though the Working Group may report on the feasibility of such
work in a future or rechartered activity. [List(Bugbee)] work in a future or rechartered activity. [List(Bugbee)]
5. The specification must only require the provision of key 5. The specification must only require the provision of key
information essential to checking the validity of the information essential to checking the validity of the
cryptographic signature. For instance, identity and key recovery cryptographic signature. For instance, identity and key recovery
information might be of interest to particular applications, but information might be of interest to particular applications, but
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. semantics prior to handing data to a XML-signature application or
[Charter] specify the necessary transformations for this process within the
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 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. Applications 2. XLink [Xlink] within its own signature syntax. For any
must use XLink locators within the signature manifest to resource identification beyond simple URIs (without fragment
reference resources. Signature applications must not embed or IDs) or fragmentIDs, applications must use XLink locators to
expand XLink references in signed content, though reference signed resources. Signature applications must not
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 3. Requirements 3 Requirements
3.1 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, retain ancestor signatures that have document closure [List(Boyer(1)], retain
information, and retain element order of non-continuous regions ancestor information, and retain element order of non-continuous
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) a request exclude list accompanying the resource locator, or (3) the
to change the XML-Fragment or XPointer specifications to yield XML-Fragment or XPointer specifications -- or a requested change
this functionality. See List(Boyer(1,2)) for further discussion of to those specifications if the functionality is not available. See
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. [Beners-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 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. An XML document of a certain type must still be recognizable as 2. When XML signatures are placed within a document the operation
its original type when signed. For example, an XML form, when must preserve (1) the document's root element tag as root and (2)
signed, should still be recognizable as a XML form to its the root's descendancy tree except for the addition of signature
application after it has been signed. [WS-summary] element(s) in places permitted by the document's content model.
For example, an XML form, when signed, should still be
recognizable as a XML form to its application after it has been
signed. [WS-summary]
3. XML-signature must provide a mechanism that facilitates the 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. A key use of XML-signatures will be detached Web signatures. 4. An important use of XML-signatures will be detached Web
However, signatures may be embedded within or encapsulate XML or signatures. However, signatures may be embedded within or
encoded content. [Charter] This WG must specify a simple method of encapsulate XML or encoded content. [Charter] This WG must specify
packaging and encapsulation if no W3C Recommendation is available. a simple method of packaging and encapsulation if no W3C
Recommendation is available.
3.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 possibility is that an error should be generated, Comment: Another possibility is that an error should be generated,
however it isn't where a conflict will be flagged between the however it isn't where a conflict will be flagged between the
various function and application layers regardless. various function and application layers regardless.
4. The signature design and specification text must not permit
implementers to erroneously build weak implementations susceptible
to common security weaknesses (such as as downgrade or algorithm
substitution attacks).
3.4 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 2. To ensure that all requirements within this document are
adequately addressed, the XML Signature specification must be adequately addressed, the XML Signature specification must be
reviewed by a designated member of the following communities: reviewed by a designated member of the following communities:
1. XML Syntax Working Group: canonicalization dependencies. 1. XML Syntax Working Group: canonicalization dependencies.
skipping to change at page 6, line 35 skipping to change at page 6, line 35
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 4. References 4 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
skipping to change at page 7, line 19 skipping to change at page 7, line 19
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
draft-ietf-trade-iotp-v1.0-protocol-04.txt http://www.ietf.org/internet-drafts/draft-ietf-trade-iotp-v1.0-
protocol-04.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-00.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.
 End of changes. 28 change blocks. 
93 lines changed or deleted 94 lines changed or added

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