RFC 2807 (rfc2807) - Page 2 of 9

XML Signature Requirements

RFC 2807               XML Signature Requirements              July 2000


   This document lists the design principles, scope, and 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. Design Principles and Scope

   1. The specification must describe how to sign digital content, and
      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
      of a signature manifest. (In this document we use the term
      manifest to mean a collection of references to the objects being
      signed. The specifications may use the terms manifest, package or
      other terms differently from this document while still meeting
      this requirement.) The manifest must support references to Web
      resources, the hash of the resource content (or its canonicalized
      form), and (optionally) the resource content type. [Brown,
      List(Solo)] Web resources are defined as any digital content that
      can be addressed using the syntax of XLink locator [XLink]).
   3. The meaning of a signature is simple:  The XML Signature syntax
      associates the content of resources listed in a manifest with a
      key via a strong one-way transformation.
      1. The XML Signature syntax must be extensible such that it can
         support arbitrary application/trust semantics and assertion
         capabilities -- that can also be signed.
         [Charter(Requirement1&4), List(Bugbee, Solo)]
      2. 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)] At the Chairs' discretion and in order
         to test the extensibility of the syntax, the WG may produce
         non-critical-path proposals defining common semantics (e.g.,
         manifest, package, timestamps, endorsement, etc.) relevant to
         signed assertions about Web resources in a schema definition
         [XML, RDF] or link type definition [XLink].
      Comment: A more formal definition of a signed resource is below.
      The notation is "definition(inputs):constraints" where definition
      evaluates as true for the given inputs and specified constraints.
      signed-resource(URI-of-resource, content, key, signature): (there
      was some protocol message at a specific time such that "GET(URI-
      of-resource) = content") AND (sign-doc(content, key, sig))



Reagle                       Informational