rfc2807.txt

著名的RFC文档,其中有一些文档是已经翻译成中文的的.

Network Working Group                                           J. Reagle
Request for Comments: 2807                                        W3C/MIT
Category: Informational                                         July 2000


                       XML Signature Requirements

Status of this Memo

   This memo provides information for the Internet community.  It does
   not specify an Internet standard of any kind.  Distribution of this
   memo is unlimited.

Copyright Notice

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

Abstract

   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. Introduction .............................................. 1
   2. Design Principles and Scope ............................... 2
   3. Requirements .............................................. 4
        3.1. Signature Data Model and Syntax .................... 4
        3.2. Format ............................................. 5
        3.3. Cryptography and Processing ........................ 5
        3.4 Coordination ........................................ 5
   4. Security Considerations ................................... 6
   5. References ................................................ 6
   6. Acknowledgements .......................................... 8
   7. Author's Address .......................................... 8
   8. Full Copyright Statement .................................. 9

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 a XML syntax used for representing signatures on
   digital content and procedures for computing and verifying such
   signatures.  Signatures will provide data integrity, authentication,
   and/or non-repudiability.



Reagle                       Informational                      [Page 1]

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                      [Page 2]

RFC 2807               XML Signature Requirements              July 2000


      sign-doc(content, key, signature): signature is the value of a
      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
      though the 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 checking the validity of the
      cryptographic signature. For instance, identity and key recovery
      information might be of interest to particular applications, but
      they are not within the class of required information defined in
      this specification. [List(Reagle)]
   6. The specification must define or reference at least one method of
      canonicalizing and hashing the signature syntax (i.e., the
      manifest and signature blocks). [Oslo] The specification must not
      specify methods of 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, XML-C14N].
      Applications are expected to normalize application specific
      semantics prior to handing data to a XML Signature application or
      specify the necessary transformations for this process within the
      signature.  [Charter]
   7. XML Signature applications must be conformant with the
      specifications as follows:
      1. XML-namespaces [XML-namespaces] within its own signature
         syntax. Applications may choose C14N algorithms which do or do
         not process namespaces within XML content. For instance, some
         C14N algorithms may opt to remove all namespace declarations,
         others may rewrite namespace declarations to provide for
         context independent declarations within every element.
      2. XLink [Xlink] within its own signature syntax. For any resource
         identification beyond simple URIs (without fragment IDs) or
         fragmentIDs, applications must use XLink locators to reference
         signed resources. Signature applications must not embed or
         expand XLink references in signed content, though applications
         may choose C14N algorithms which provide this feature.
      3. XML-Pointers [XPointer] within its own signature syntax. If
         applications reference/select parts of XML documents, they 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]








Reagle                       Informational                      [Page 3]

RFC 2807               XML Signature Requirements              July 2000


   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

   1. XML Signature data structures must be based on the RDF data model
      [RDF] but need not use the RDF serialization syntax. [Charter]
   2. XML Signatures apply to any resource addressable by a locator --
      including non-XML content. 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, Brown,
      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
      [List(Boyer(1)], 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) the XML-Fragment or XPointer
      specifications -- or a requested change to those specifications if
      the functionality is not available. See List(Boyer(1,2)) for
      further discussion of this issue.
   4. Multiple XML Signatures must be able to exist over the static
      content of a Web resource given varied keys, content
      transformations, 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]
   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 are a first
      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
      included/encoded resource. [WS-list (Brown/Himes)]





Reagle                       Informational                      [Page 4]

RFC 2807               XML Signature Requirements              July 2000


3.2 Format

   1. An XML Signature must be an XML element (as defined by production
      39 of the XML1.0 specification. [XML])
   2. When XML signatures are placed within a document the operation
      must preserve (1) the document's root element tag as root and (2)
      the root's descendancy tree except for the addition of signature
      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
      production of composite documents -- by addition or deletion --
      while preserving the signature characteristics (integrity,
      authentication, and non-repudiability) of the consituent parts.
      [Charter, Brown, List(Bugbee)]
   4. An important 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 Cryptography and Processing