XML Digital Signatures Working Group J. Reagle, INTERNET-DRAFT W3C/MIT draft-ietf-xmldsig-requirements-00.txt Expires December 23, 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 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 http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This document is a production of the joint IETF/W3C XML Signature Working Group. http://www.w3.org/Signature The latest version of this draft series may be found at: http://www.w3.org/TR/1999/xmldsig-requirements Reagle [Page 1]
Internet Draft XML-Signature Requirements June 1999 XML-Signature Requirements W3C Working Draft 1999-June-23 This version: http://www.w3.org/TR/1999/xmldsig-requirements-990623 {ASCII} http://www.ietf.org/internet-drafts/draft-ietf-xmldsig-requirem ents-00.txt Latest version: http://www.w3.org/TR/1999/xmldsig-requirements Previous version: http://www.w3.org/Signatures/Drafts/xml-dsig-requirements-99060 1 Editor(s): 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 this Document This is the first Public Working Draft of the IETF/W3C XML-Digital Signature Working Group Requirements document. Its content is based on the Charter [Charter], XML-Signature Workshop [WS], Brown's IETF draft [Brown] and mailing list discussion. This draft will be published prior to the June 25 IETF deadline for consideration at the IETF in Oslo as an IETF-draft and W3C Working Draft. The first draft of a Working Group consensus version should be produced by July. This document does not necessarily represent the working group's consensus on a finished document; it also includes contrary positions (or alternative wordings) in order to elicit review and discussion. Positions which are potentially in conflict are specified as a list of lettered points. For example: 1 Extensibility a. Position b. Alternative/Contrary Position 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. Reagle [Page 1]
Internet Draft XML-Signature Requirements June 1999 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 porcessing, and external requirements and coordination. Table of Contents 1 Introduction 2 Design Principles and Scope 3 Requirements 1 Signature Data Model and Syntax 2 Format 3 Cryptography 4 Processing 5 Coordination 4 References _________________________________________________________________ 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 XML compliant syntax used for representing signatures on Web resources and portions of protocol messages (anything that can be referenced by a URI) and procedures for computing and verifying such signatures. Signatures will provide data integrity, authentication, and/or non-repudiatability 2 Design Principles and Scope 1 The XML-Signature specification will describe how to a digitally sign a Web resource in general, and an XML document in particular. [Charter] The specification will not specify methods of providing confidentiality though the Working Group may report on the feasibility of such work in a future or rechartered activity. [List(Bugbee)] 2 The meaning of the signature is very simple: The XML signature syntax associates the cryptographic signature value with Web 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 The 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 trust applications include sophisticated timestamps, endorsement, and threshold signature schemes. At the Chairs' discretion and in order to test the extensibility the syntax, the WG may produce non-standard-track proposals defining common semantics relevant to signed assertions about Reagle [Page 1]
Internet Draft XML-Signature Requirements June 1999 Web resources and their relationships in a schema definition (XML/RDF) or link type definition (XLink). [Charter(Requirement1&4), List(Bugbee, Solo)] 3 Validity and Identity A. Only enough information necessary to check the validity of the cryptographic signature need be provided. [Reagle] B. Each signature shall be associated with information to identify the signer and/or the cryptographic information required to validate the signature. [List(Solo)] 3 An XML-Signature can apply to a part or totality of an XML document. [Charter, Brown] 4 More than one signature may exist over any resource.[Charter, Brown] 5 A key use 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. [Charter] 6 The Signature syntax specification will not specify methods of serialization or canonicalization. XML content is normalized by specifying an appropriate content C14N (canonicalization) algorithm [DOMHASH, C14N]; applications are expected to normalize application specific semantics prior to handing data to a XML-Signature application. [Charter] 7 An XML-Signature application must be able to use and understand 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 XLink [Xlink]. Applications will use XLink locators within the signature manifest to reference signed resources. Signature applications will not embed or expand XLink references in the signed content, though applications may optionally choose C14N algorithms which provide this feature. 3 XML-Pointers [XPointer]. Applications will reference/select parts of XML documents using XML-Pointer within an XLink locator. [Reagle, WS-list(1)] 8 Implementation/Design Philosophy A. XML Signatures will be developed as part of the broader Web design philosophy of decentralization, URIs, Web data [WebData], modularity/layering/extensibility, and assertions as statements about statements. [Reagle] B. The ability to leverage existing cryptographic provider (and infrastructure) primitives is desirable. [List(Solo)] 3 Requirements Signature Data Model and Syntax 1 The XML-Signature data structures will be predicated on an RDF data model [RDF] but need not use the RDF serialization syntax. [Charter] 2 XML-Signatures can be applied to any Web resource -- including non-XML content. XML-Signature referents are identified with XML Reagle [Page 1]
Internet Draft XML-Signature Requirements June 1999 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, List(Vincent)] 1 Entries may include explicit content type information. [List(Solo)] 3 XML-Signatures are first class objects themselves and consequently can be referenced and signed. [Berners-Lee, Reagle] 4 Algorithm Identification A. Whenever possible, any resource or algorithm identifier is a first class object, and addressable by a URI. [Beners-Lee, Reagle] B. Ability to specify algorithms independently and to reference the algorithms linked to standard algorithm specifications (e.g. OIDs) [List(Solo)] 5 XML-Signatures must be able to apply to the original version of an included/encoded resource. [WS-list (Brown/Himes)] Format 1 An XML-Signature is XML. [Charter] 2 An XML document of a certain type must still be recognizable as its original type when signed. [WS-summary] 3 XML-Signature will 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? Cryptography 1 The solution shall provide indifferently for digital signature and message authentication codes, considering symmetric and asymmetric authentication schemes as well as dynamic negotiation of keying material. [Brown] Processing 1 In the event of redundant attributes within the XML Signature syntax and relevant cryptographic blobs, XML Signature applications prefer the XML Signature semantics. [Reagle] Coordination The XML Signature specification should meet the requirements of the following applications: 1 Internet Open Trading Protocol v2.0 [Charter] 2 Financial Services Mark Up Language v2.0 [Charter] Reagle [Page 1]
Internet Draft XML-Signature Requirements June 1999 To ensure the above requirements are adequately addressed, the XML Signature specification must be reviewed by a designated member of the following communities: 1 XML Syntax Working Group [Charter] 2 XML Linking Working Group [Charter] 3 XML Schema Working Group [Charter] 4 Metadata Coordination Group [Charter] 5 ?W3C Internationalization Interest Group? 4 References Berners-Lee Axioms of Web Architecture: URIs. http://www.w3.org/DesignIssues/Axioms.html Brown-XML-DSig Internet Draft. Digital Signatures for XML http://search.ietf.org/internet-drafts/draft-brown-xml-dsig-00. txt C14N XML Canonicalization Requirements. http://www.w3.org/TR/NOTE-xml-canonical-req Charter XML-DSig Charter. http://www.w3.org/1999/05/XML-DSig-charter-990521.html DOMHASH Internet Draft. Digest Values for DOM (DOMHASH) http://search.ietf.org/internet-drafts/draft-hiroshi-dom-hash-0 1txt Infoset-Req XML Information Set Requirements Note. http://www.w3.org/TR/NOTE-xml-infoset-req IOTP-DSig Internet Draft. Digital Signatures for the Internet Open Trading Protocol http://www.ietf.org/internet-drafts/draft-ietf-trade-iotp-v1.0- dsig-00.txt Namespaces Namespaces in XML Recommendation. http://www.w3.org/TR/REC-xml-names Signature List http://lists.w3.org/Archives/Public/w3c-ietf-xmldsig/ Reagle [Page 1]
Internet Draft XML-Signature Requirements June 1999 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/TR/WD-xlink XML Extensible Markup Language (XML) Recommendation. http://www.w3.org/TR/REC-xml XML-namespaces Namespaces in XML http://www.w3.org/TR/REC-xml-names/ XPointer XML Pointer Language (XPointer) http://www.w3.org/TR/WD-xptr WebData Web Architecture: Describing and Exchanging Data. http://www.w3.org/1999/04/WebData
