XML Digital Signatures Working Group               J. Reagle,
INTERNET-DRAFT                                     W3C/MIT
Expires December 23, March 20, 1999

                         XML-Signature Requirements

Copyright Notice

   Copyright (c) 1999 The Internet Society & W3C (MIT, INRIA, Keio), All
   Rights Reserved.

IETF Status of this Memo

   This document is a production of the joint IETF/W3C XML Signature
   Working Group.


   The latest version of this draft series may be found at:


   This document is an Internet-Draft and is in full conformance with all
   provisions of Section 10 of RFC2026.

   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

   The list of Internet-Draft Shadow Directories can be accessed at


W3C Status of this document

   This is a production of the joint IETF/W3C Last Call XML Signature
   Working Group.


   The latest version of this draft series may be found at:


XML-Signature Requirements
W3C public Working Draft 1999-June-23 Draft.
   This version:
          http://www.w3.org/TR/1999/xmldsig-requirements-990623 {ASCII}

   Latest version:

   Previous version:


          Joseph Reagle Jr. <reagle@w3.org>

   Copyright  1999 The Internet Society & W3C (MIT, INRIA, Keio), All
   Rights Reserved. W3C liability, trademark, document use and software
   licensing rules apply.

W3C Status of report is not expected to be advanced to Recommendation. Instead,
   this Document

   This Last Call designation is the first Public Working Draft (1) a representation of WG consensus,
   (2) an invitation for comments that will affect the IETF/W3C XML-Digital
   Signature Working Group Requirements document.  Its content is based
   on future course of
   the Charter [Charter], XML-Signature Workshop [WS], Brown's IETF
   draft [Brown] technical specification, and mailing list discussion. (3) an opportunity to identify and
   obtain commitments regarding WG dependencies. This draft document will be
   published prior
   referred to the June 25 IETF deadline for consideration at least the
   IETF in Oslo as an IETF-draft W3C XML Plenary Interest Group and W3C Chairs
   Working Draft. The first draft Group. Last Call period ends when  dependencies between WGs
   have been acknowledged and the Signature Chairs have procured
   commitments of a Working Group consensus version should be produced by July. review. This is expected to take six weeks from the
   date of publication.

   This document does not necessarily represent attempts to capture the working group's Working Group's consensus on a finished document; though
   it also includes contrary positions
   (or alternative wordings) in order to elicit review and discussion.
   Positions contains points which are potentially in conflict still uncertain or not well
   specified. Issues which are specified as a list still being actively discussed during the
   publication of
   lettered points. For example:
    1 Extensibility
         a. Position
         b. Alternative/Contrary Position 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
   <w3c-ietf-xmldsig@w3.org>. Publication as a Working Draft does not
   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. Publication as a Working Draft does not imply
   endorsement by the W3C membership.


   This document lists the design principles, scope, and requirements for
   the XML Digital Signature specification. It includes requirements as
   they relate to the signature syntax, data model, format, cryptographic
   processing, and external requirements and coordination.

Table of Contents


     1. 1. Introduction
     2. 2. Design Principles and Scope
     3. 3. Requirements
          3.1 1. Signature Data Model and Syntax
          3.2 2. Format
          3.3 3. Cryptography
         4 and Processing
          3.4 4. Coordination
     4. 4. References

1 1. Introduction

   The XML 1.0 Recommendation [XML] describes the syntax of a class of
   data objects called XML documents. The mission of this working group
   is to develop an a XML compliant syntax used for representing signatures on Web resources and portions of protocol messages (anything that can
   be referenced by a URI) digital
   content and procedures for computing and verifying such signatures.
   Signatures will provide data integrity, authentication, and/or non-repudiatability

2 Design Principles

   This document lists the design principles, scope, and Scope

    1 The XML-Signature specification will describe requirements
   over three things: (1) the scope of work available to the WG, (2)  the
   XML signature specification, and (3) applications that implement the
   specification. It includes requirements as they relate to the
   signature syntax, data model, format, cryptographic processing, and
   external requirements and coordination. Those things that are required
   are designated as "must," those things that are optional are
   designated by "may," those things that are optional but recommended
   are designated as "should."

2 2. Design Principles and Scope

    1. The specification must describe how to a digitally sign a Web resource in general, digital content, and an
       XML document content in particular. [Charter]
    2. XML-signatures are generated from a hash over the canonical form
       of a signature manifest. The specification will not specify methods manifest must support references to
       Web resources, the hash of providing
       confidentiality though the Working Group may report on resource content (or its
       canonicalized form), and (optionally) the
       feasibility resource content type.
       [Brown, List(Solo)] Web resources are defined as any digital
       content content that can be addressed using the syntax of such work in XLink
       locator [XLink]).
       Comment: Scenarios are being explored which examine the ability to
       sign without requiring a future manifest whereas the scope of the signed
       content is designated by the relative placement of signature
       elements in the XML stream/tree. For instance:
       <html> .....</body><dsig xmlns="http://..." referent=""><html>.
       or rechartered activity.
       <html><title>pricelist</title>...<dsig xmlns="http://..."> ...
    3. The meaning of the a signature is very simple:  The XML signature XML-signature syntax
       associates the cryptographic signature value with Web content of resources using XML markup.
         1 The WG is not chartered to specify trust semantics, but
            syntax and processing rules necessary for communicating
            signature validity (authenticity, integrity and
            non-repudiation).  [Charter(Requirement1)]
         2 listed in a manifest with a
       key via a strong one-way transformation.
         1. The XML signature XML-signature syntax must be highly extensible such that it can
            support arbitrary application/trust semantics and assertion
            capabilities -- that can also be signed. For
            example, potential
            [Charter(Requirement1&4), List(Bugbee, Solo)]
         2. The WG is not chartered to specify trust applications include sophisticated
            timestamps, endorsement, semantics, but
            syntax and threshold processing rules necessary for communicating
            signature schemes. validity (authenticity, integrity and
            non-repudiation).  [Charter(Requirement1)] At the Chairs'
            discretion and in order to test the extensibility of the
            syntax, the WG may produce non-standard-track proposals
            defining common semantics (e.g., package, timestamps,
            endorsement, etc.) relevant to signed assertions about Web
            resources and their relationships in a schema definition
            (XML/RDF) [XML, RDF] or link type
            definition (XLink).
            [Charter(Requirement1&4), List(Bugbee, Solo)]
         3 Validity [XLink].
       Comment: A more formal definition of a signed resource is the
       following evaluates as true "definition(inputs):constraints" where
       R is a resource., I is a resource identifier (URI), and Identity
              A. Only enough information necessary to check C is
       content (sequence-of-octects).
       signed-resource(I, C, key, sig): there was some request R such
       that GET(R) = C and address(R) = I and sign-doc(C, key, sig)
       sign-doc(C, key, sig): sig is the validity value of a strong one-way
       function over content and key that yields C integrity/validity and
       K non-repudiability
    4. The specification must not specify methods of confidentiality
       though the cryptographic signature need be provided.
              B. Each signature shall be associated with Working Group may report on the feasibility of such
       work in a future or rechartered activity. [List(Bugbee)]
    5. The specification must only require the provision of key
       information essential to
                 identify checking the signer and/or validity of the
       cryptographic signature. For instance, identity and key recovery
                 required might be of interest to validate particular applications, but
       they are not within the signature.   [List(Solo)]
    3 An XML-Signature can apply to a part or totality class of an XML
       document.  [Charter, Brown]
    4 More than required information defined in
       this specification. [List(Reagle)]
    6. The specification must define or reference at least one signature may exist over any resource.[Charter,
    5 A key use method of XML Signatures will be detached Web signatures. In
       conjunction with XML facilities (including packaging) signatures
       may be embedded within or encapsulate XML or encoded content.
    6 The Signature
       canonicalizing and hashing the signature syntax (i.e., the
       manifest and signature blocks). [Oslo] The specification will must not
       specify methods of
       serialization or canonicalization. XML canonicalizing resource content [Charter],
       though it may specify security requirements over such methods.
       [Oslo] Such content is normalized by specifying an appropriate
       content C14N (canonicalization) algorithm [DOMHASH, C14N]; applications XML-C14N].
       Applications are expected to normalize application specific
       semantics prior to handing data to a
       XML-Signature XML-signature application.
    7 An XML-Signature application
    7. XML-signature applications must be able to use and understand
         1 conformant with the
       specifications as follows:
         1. XML-namespaces [XML-namespaces] within its own signature
            syntax. Applications may optionally choose C14N algorithms which do or
            do not process namespaces within XML content.
         2 For instance,
            some C14N algorithms may opt remove all namespace
            declarations, others may rewrite namespace declarations to
            provide for context independent declarations within every
         2. XLink [Xlink]. [Xlink] within its own signature syntax. Applications will
            must use XLink locators within the signature manifest to
            reference signed resources. Signature applications will must not embed or
            expand XLink references in the signed content, though
            applications may
            optionally choose C14N algorithms which provide this
         3. XML-Pointers [XPointer]. Applications will [XPointer] within its own signature syntax. If
            applications reference/select parts of XML documents using documents, they
            must use XML-Pointer within an XLink locator. [Reagle, WS-list(1)]
    8 Implementation/Design Philosophy
         A. XML Signatures will [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
            [WebData], data,
       modularity/layering/extensibility, and assertions as statements
       about statements. [Reagle]
         B. The ability to leverage [Berners-Lee, WebData] In this context, existing
       cryptographic provider (and infrastructure) primitives is desirable. should be
       taken advantage of. [List(Solo)]

3 3. Requirements

3.1 1. Signature Data Model and Syntax

    1 The XML-Signature

    1. XML-signature data structures will must be predicated based on an the RDF data model
       [RDF] but need not use the RDF serialization syntax. [Charter]
    2 XML-Signatures can be applied
    2. XML-signatures apply to any Web resource addressable by a locator --
       including non-XML content. XML-Signature XML-signature referents are identified
       with XML locators (URIs or fragments) within the manifest that
       refer to external or internal resources (i.e., network accessible
       or within the same XML document/package). [Berners-Lee, Reagle, Brown,
         1 Entries may include explicit
       List(Vincent), WS, XFDL]
    3. XML-signatures must be able to apply to a part or totality of a
       XML document.  [Charter, Brown]
       Comment: A related requirement under consideration is requiring
       the specification to support the ability to indicate those
       portions of a document one signs via exclusion of those portions
       one does not wish to sign. This feature allows one to create
       signatures that have document closure, retain ancestor
       information, and retain element order of non-continuous regions
       that must be signed. We are considering implementing this
       requirement via (1) a special <dsig:exclude> element, (2) an
       exclude list accompanying the resource locator, or (3) a request
       to change the XML-Fragment or XPointer specifications to yield
       this functionality. See List(Boyer(1,2)) for further discussion of
       this issue.
    4. Multiple XML-signatures must be able to exist over the static
       content type information.
    3 XML-Signatures of a Web resource given varied keys, content
       transormations, and algorithm specifications (signature, hash,
       canonicalization, etc.). [Charter, Brown]
    5. XML-signatures are first class objects themselves and consequently
       must be able to be referenced and signed. [Berners-Lee, Reagle]
    4 Algorithm Identification
         A. Whenever possible, any resource [Berners-Lee]
    6. The specification must permit the use of varied digital signature
       and message authentication codes, such as symmetric and asymmetric
       authentication schemes as well as dynamic agreement of keying
       material. [Brown] Resource or algorithm identifier is are a first
       class object, and addressable by a URI. [Beners-Lee,
         B. Ability to specify algorithms independently and to reference
            the algorithms linked to standard algorithm specifications
            (e.g. OIDs) [List(Solo)]
    5 XML-Signatures objects, and must be addressable by a URI. [Beners-Lee]
    7. XML-signatures must be able to apply to the original version of an
       included/encoded resource. [WS-list (Brown/Himes)]

3.2 2. Format


    1. An XML-Signature is XML. [Charter]
    2 XML-signature must be an XML element (as defined by production
       39 of the XML1.0 specification. [XML])
    2. An XML document of a certain type must still be recognizable as
       its original type when signed. 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 will
    3. XML-signature must provide a mechanism that facilitates the
       production of composite documents -- by addition or deletion --
       while preserving the signature characteristics (integrity,
       authentication, and non-repudiatability) of the consituent parts.
       [Charter, Brown, List(Bugbee)]
    4 ?Packaging?
    4. A key use of XML-signatures will be detached Web signatures.
       However, signatures may be embedded within or encapsulate XML or
       encoded content. [Charter] This WG must specify a simple method of
       packaging and encapsulation if no W3C Recommendation is available.

3.3 3. Cryptography

    1 and Processing

    1. The solution shall provide indifferently for digital specification must permit arbitrary cryptographic signature
       and message authentication codes, considering algorithms, symmetric and asymmetric
       authentication schemes as well as dynamic negotiation of keying
       material. schemes, and key agreement methods. [Brown]


    2. The specification must specify at least one mandatory to implement
       signature canonicalization, content canonicalization, hash, and
       signature algorithm.
    3. In the event of redundant attributes within the XML Signature
       syntax and relevant cryptographic blobs, XML Signature
       applications prefer the XML Signature semantics. [Reagle]
       Comment: Another possibility is that an error should be generated,
       however it isn't where a conflict will be flagged between the
       various function and application layers regardless.

3.4 4. Coordination

    1. The XML Signature specification should meet the requirements of
       the following applications:
         1. Internet Open Trading Protocol v2.0 [Charter]
    2 v1.0 [IOTP]
         2. Financial Services Mark Up Language v2.0 [Charter]
         3. At least one forms application [XFA, XFDL]
    2. To ensure the above that all requirements within this document are
       adequately addressed, the XML Signature specification must be
       reviewed by a designated member of the following communities:
         1. XML Syntax Working Group Group: canonicalization dependencies.
         2. XML Linking Working Group Group: signature referants. [Charter]
         3. XML Schema Working Group Group: signature schema design. [Charter]
         4. Metadata Coordination Group Group: data model design. [Charter]
    5 ?W3C
         5. W3C Internationalization Interest Group? Group:  [AC Review]
         6. XML Package Working Group: signed content in/over packages.
         7. XML Fragment Working Group: signing portions of XML content.
       Comment: Members of the WG are very interested in signing and
       processing XML fragments and packaged components. Boyer asserts
       that [XML-fragment] does not "identify non-contiguous portions of
       a document in such a way that the relative positions of the
       connected components is preserved." Packaging is a capability
       critical to XML-Signature applications, but it is clearly
       dependent on clear trust/semantic definitions, package application
       requirements, and even cache-like application requirements. It is
       not clear how this work will be addressed.

4 4. References

   AC Review
          Misha Wolf. "The Charter should include the I18N WG in the
          section on 'Coordination with Other Groups.'"

          Axioms of Web Architecture: URIs.
          Web Architecture from 50,000 feet

          Internet Draft. Digital Signatures for XML

          XML Canonicalization Requirements.

          XML Signature (xmldsig) Charter.
          Internet Draft. Digest Values for DOM (DOMHASH)

          FSML 1.5 Reference Specification

          XML Information Set Requirements Note.

          Internet Open Trading Protocol v1.0

          Internet Draft. Digital Signatures for the Internet Open
          Trading Protocol

          Namespaces in

          Minutes of the XML Recommendation.
          http://www.w3.org/TR/REC-xml-names Signature WG Sessions at  IETF face-to-face
          meeting in Oslo.

          RDF Schema
          RDF Model and Syntax

   Signature WG List

          Uniform Resource Identifiers (URI): Generic Syntax

   WS (list, summary)
          XML-DSig '99: The W3C Signed XML Workshop

          XML Linking Language

          Extensible Markup Language (XML) Recommendation.
          XML Canonicalization Requirements.

          XML Forms Architecture (XFA)

          Extensible Forms Description Language (XFDL) 4.0

          XML-Fragment Interchange

          Namespaces in XML

          XML Schema Part 1: Structures
          XML Schema Part 2: Datatypes

          XML Pointer Language (XPointer)

          Web Architecture: Describing and Exchanging Data.