Movatterモバイル変換

Network Working Group                                           J. ReagleRequest for Comments: 2807                                        W3C/MITCategory: Informational                                         July 2000XML Signature RequirementsStatus 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 Contents1. Introduction ..............................................12. Design Principles and Scope ...............................23. Requirements ..............................................43.1. Signature Data Model and Syntax ....................43.2. Format .............................................53.3. Cryptography and Processing ........................53.4 Coordination ........................................54. Security Considerations ...................................65. References ................................................66. Acknowledgements ..........................................87. Author's Address ..........................................88. Full Copyright Statement ..................................91. 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. Requirements3.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 20003.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   1. The specification must permit arbitrary cryptographic signature      and message authentication algorithms, symmetric and asymmetric      authentication 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.  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.   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 Coordination   1. The XML Signature specification should meet the requirements of      the following applications:         1. Internet Open Trading Protocol v1.0 [IOTP]         2. Financial Services Mark Up Language v2.0 [Charter]         3. At least one forms application [XFA, XFDL]Reagle                       Informational                      [Page 5]

RFC 2807               XML Signature Requirements              July 2000   2. To ensure 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: canonicalization dependencies.            [Charter]         2. XML Linking Working Group: signature referents. [Charter]         3. XML Schema Working Group: signature schema design. [Charter]         4. Metadata Coordination Group: data model design. [Charter]         5. W3C Internationalization Interest 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. Security Considerations   This document lists XML Digital Signature requirements as they relate   to the signature syntax, data model, format, cryptographic   processing, and external requirements and coordination. In that   context much of this document is about security.5. References   AC Review         Misha Wolf. "The Charter should include the I18N WG                     in the section on `Coordination with Other                     Groups'",http://lists.w3.org/Archives/Team/xml-dsig-review/1999May/0007.html   Berners-Lee       Axioms of Web Architecture: URIs.http://www.w3.org/DesignIssues/Axioms.html Web                     Architecture from 50,000 feethttp://www.w3.org/DesignIssues/Architecture.html   Brown-XML-DSig    Work in Progress. Digital Signatures for XMLhttp://www.w3.org/Signature/Drafts/xmldsig-signature-990618.html   Charter           XML Signature (xmldsig) Charter.http://www.w3.org/1999/05/XML-DSig-charter-990521.htmlReagle                       Informational                      [Page 6]

RFC 2807               XML Signature Requirements              July 2000   DOMHASH           Maruyama, H., Tamura, K. and N. Uramoto, "Digest                     Values for DOM (DOMHASH)",RFC 2803, April 2000.   FSML              FSML 1.5 Reference Specificationhttp://www.echeck.org/library/ref/fsml-v1500a.pdf   Infoset-Req       XML Information Set Requirements Note.http://www.w3.org/TR/1999/NOTE-xml-infoset-req-19990218.html   IOTP              Burdett, D., "Internet Open Trading Protocol - IOTP                     Version 1.0",RFC 2801, April 2000.   IOTP-DSig         Davidson, K. and Y. Kawatsura, "Digital Signatures                     for the v1.0 Internet Open Trading Protocol                     (IOTP)",RFC 2802, April 2000.   Oslo              Minutes of the XML Signature WG Sessions at  IETF                     face-to-face meeting in Oslo.   RDF               RDF Schemahttp://www.w3.org/TR/1999/PR-rdf-schema-19990303                     RDF Model and Syntaxhttp://www.w3.org/TR/1999/REC-rdf-syntax-19990222   Signature WG Listhttp://lists.w3.org/Archives/Public/w3c-ietf-xmldsig/   URI               Berners-Lee, T., Fielding, R. and L. Masinter,                     "Uniform Resource Identifiers (URI): Generic                     Syntax",RFC 2396, August 1998.http://www.ietf.org/rfc/rfc2396.txt   WS   (list, summary)   XML-DSig '99: The W3C Signed XML Workshophttp://www.w3.org/DSig/signed-XML99/http://www.w3.org/DSig/signed-XML99/summary.html   XLink XML   Linking Languagehttp://www.w3.org/1999/07/WD-xlink-19990726   XML               Extensible Markup Language (XML) Recommendation.http://www.w3.org/TR/1998/REC-xml-19980210Reagle                       Informational                      [Page 7]

RFC 2807               XML Signature Requirements              July 2000   XML-C14N          XML Canonicalization Requirements.http://www.w3.org/TR/1999/NOTE-xml-canonical-req-19990605   XFA               XML Forms Architecture (XFA)http://www.w3.org/Submission/1999/05/   XFDL              Extensible Forms Description Language (XFDL) 4.0http://www.w3.org/Submission/1998/16/   XML-Fragment      XML-Fragment Interchangehttp://www.w3.org/1999/06/WD-xml-fragment-19990630.html   XML-namespaces    Namespaces in XMLhttp://www.w3.org/TR/1999/REC-xml-names-19990114   XML-schema        XML Schema Part 1: Structureshttp://www.w3.org/1999/05/06-xmlschema-1/XML Schema Part 2: Datatypeshttp://www.w3.org/1999/05/06-xmlschema-2/   XPointer          XML Pointer Language (XPointer)http://www.w3.org/1999/07/WD-xptr-19990709   WebData           Web Architecture: Describing and Exchanging Data.http://www.w3.org/1999/04/WebData6. 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/ReagleReagle                       Informational                      [Page 8]

RFC 2807               XML Signature Requirements              July 20008.  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.Reagle                       Informational                      [Page 9]