summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc2807.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc2807.txt')
-rw-r--r--doc/rfc/rfc2807.txt507
1 files changed, 507 insertions, 0 deletions
diff --git a/doc/rfc/rfc2807.txt b/doc/rfc/rfc2807.txt
new file mode 100644
index 0000000..695e5c3
--- /dev/null
+++ b/doc/rfc/rfc2807.txt
@@ -0,0 +1,507 @@
+
+
+
+
+
+
+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
+
+ 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 feet
+ http://www.w3.org/DesignIssues/Architecture.html
+
+ Brown-XML-DSig Work in Progress. Digital Signatures for XML
+ http://www.w3.org/Signature/Drafts/xmldsig-
+ signature-990618.html
+
+ Charter XML Signature (xmldsig) Charter.
+ http://www.w3.org/1999/05/XML-DSig-charter-
+ 990521.html
+
+
+
+
+Reagle 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 Specification
+ http://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 Schema
+ http://www.w3.org/TR/1999/PR-rdf-schema-19990303
+ RDF Model and Syntax
+ http://www.w3.org/TR/1999/REC-rdf-syntax-19990222
+
+ Signature WG List http://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 Workshop
+ http://www.w3.org/DSig/signed-XML99/
+ http://www.w3.org/DSig/signed-XML99/summary.html
+
+ XLink XML
+ Linking Language http://www.w3.org/1999/07/WD-xlink-19990726
+
+ XML Extensible Markup Language (XML) Recommendation.
+ http://www.w3.org/TR/1998/REC-xml-19980210
+
+
+
+
+
+
+
+
+Reagle 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.0
+ http://www.w3.org/Submission/1998/16/
+
+ XML-Fragment XML-Fragment Interchange
+ http://www.w3.org/1999/06/WD-xml-fragment-
+ 19990630.html
+
+ XML-namespaces Namespaces in XML
+ http://www.w3.org/TR/1999/REC-xml-names-19990114
+
+ XML-schema XML Schema Part 1: Structures
+ http://www.w3.org/1999/05/06-xmlschema-1/
+ XML Schema Part 2: Datatypes
+ http://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/WebData
+
+6. 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/Reagle
+
+
+
+
+
+Reagle Informational [Page 8]
+
+RFC 2807 XML Signature Requirements July 2000
+
+
+8. 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]
+