idnits 2.17.1 draft-ietf-xmldsig-requirements-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? == There is 1 instance of lines with non-ascii characters in the document. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack an Authors' Addresses Section. ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 19 instances of too long lines in the document, the longest one being 1 character in excess of 72. ** There are 2 instances of lines with control characters in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (December 23, 1999) is 8862 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Missing reference section? 'Charter' on line 255 looks like a reference -- Missing reference section? 'WS' on line 69 looks like a reference -- Missing reference section? 'Brown' on line 234 looks like a reference -- Missing reference section? 'XML' on line 115 looks like a reference -- Missing reference section? 'Reagle' on line 240 looks like a reference -- Missing reference section? 'DOMHASH' on line 167 looks like a reference -- Missing reference section? 'C14N' on line 167 looks like a reference -- Missing reference section? 'XML-namespaces' on line 171 looks like a reference -- Missing reference section? 'Xlink' on line 174 looks like a reference -- Missing reference section? 'XPointer' on line 179 looks like a reference -- Missing reference section? 'WebData' on line 185 looks like a reference -- Missing reference section? 'RDF' on line 195 looks like a reference -- Missing reference section? 'Berners-Lee' on line 206 looks like a reference -- Missing reference section? 'WS-summary' on line 221 looks like a reference Summary: 9 errors (**), 0 flaws (~~), 2 warnings (==), 16 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 XML Digital Signatures Working Group J. Reagle, 2 INTERNET-DRAFT W3C/MIT 3 draft-ietf-xmldsig-requirements-00.txt 4 Expires December 23, 1999 6 XML-Signature Requirements 8 Copyright Notice 10 Copyright (c) 1999 The Internet Society & W3C (MIT, INRIA, Keio), All 11 Rights Reserved. 13 IETF Status of this Memo 15 This document is an Internet-Draft and is in full conformance with all 16 provisions of Section 10 of RFC2026. 18 Internet-Drafts are working documents of the Internet Engineering Task 19 Force (IETF), its areas, and its working groups. Note that other 20 groups may also distribute working documents as Internet-Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet- Drafts as reference 25 material or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 This document is a production of the joint IETF/W3C XML Signature 34 Working Group. 36 http://www.w3.org/Signature 38 The latest version of this draft series may be found at: 40 http://www.w3.org/TR/1999/xmldsig-requirements 42 XML-Signature Requirements 43 W3C Working Draft 1999-June-23 45 This version: 46 http://www.w3.org/TR/1999/xmldsig-requirements-990623 {ASCII} 47 http://www.ietf.org/internet-drafts/draft-ietf-xmldsig-requirem 48 ents-00.txt 50 Latest version: 51 http://www.w3.org/TR/1999/xmldsig-requirements 53 Previous version: 55 http://www.w3.org/Signatures/Drafts/xml-dsig-requirements-99060 56 1 58 Editor(s): 59 Joseph Reagle Jr. 61 Copyright � 1999 The Internet Society & W3C (MIT, INRIA, Keio), All 62 Rights Reserved. W3C liability, trademark, document use and software 63 licensing rules apply. 65 W3C Status of this Document 67 This is the first Public Working Draft of the IETF/W3C XML-Digital 68 Signature Working Group Requirements document. Its content is based 69 on the Charter [Charter], XML-Signature Workshop [WS], Brown's IETF 70 draft [Brown] and mailing list discussion. This draft will be 71 published prior to the June 25 IETF deadline for consideration at the 72 IETF in Oslo as an IETF-draft and W3C Working Draft. The first draft 73 of a Working Group consensus version should be produced by July. 75 This document does not necessarily represent the working group's 76 consensus on a finished document; it also includes contrary positions 77 (or alternative wordings) in order to elicit review and discussion. 78 Positions which are potentially in conflict are specified as a list of 79 lettered points. For example: 80 1 Extensibility 81 a. Position 82 b. Alternative/Contrary Position 84 Please send comments to the editor and cc: the list 85 . Publication as a Working Draft does not 86 imply endorsement by the W3C membership. This is a draft document and 87 may be updated, replaced or obsoleted by other documents at any time. 88 It is inappropriate to cite W3C Drafts as other than "work in 89 progress".A list of current W3C working drafts can be found at 90 http://www.w3.org/TR. Publication as a Working Draft does not imply 91 endorsement by the W3C membership. 93 Abstract 95 This document lists the design principles, scope, and requirements for 96 the XML Digital Signature specification. It includes requirements as 97 they relate to the signature syntax, data model, format, cryptographic 98 porcessing, and external requirements and coordination. 100 Table of Contents 102 1 Introduction 103 2 Design Principles and Scope 104 3 Requirements 105 1 Signature Data Model and Syntax 106 2 Format 107 3 Cryptography 108 4 Processing 109 5 Coordination 110 4 References 111 _________________________________________________________________ 113 1 Introduction 115 The XML 1.0 Recommendation [XML] describes the syntax of a class of 116 data objects called XML documents. The mission of this working group 117 is to develop an XML compliant syntax used for representing signatures 118 on Web resources and portions of protocol messages (anything that can 119 be referenced by a URI) and procedures for computing and verifying 120 such signatures. Signatures will provide data integrity, 121 authentication, and/or non-repudiatability 123 2 Design Principles and Scope 125 1 The XML-Signature specification will describe how to a digitally 126 sign a Web resource in general, and an XML document in particular. 127 [Charter] The specification will not specify methods of providing 128 confidentiality though the Working Group may report on the 129 feasibility of such work in a future or rechartered activity. 130 [List(Bugbee)] 131 2 The meaning of the signature is very simple: The XML signature 132 syntax associates the cryptographic signature value with Web 133 resources using XML markup. 134 1 The WG is not chartered to specify trust semantics, but 135 syntax and processing rules necessary for communicating 136 signature validity (authenticity, integrity and 137 non-repudiation). [Charter(Requirement1)] 138 2 The XML signature syntax must be highly extensible such that 139 it can support arbitrary application/trust semantics and 140 assertion capabilities -- that can also be signed. For 141 example, potential trust applications include sophisticated 142 timestamps, endorsement, and threshold signature schemes. At 143 the Chairs' discretion and in order to test the extensibility 144 the syntax, the WG may produce non-standard-track proposals 145 defining common semantics relevant to signed assertions about 146 Web resources and their relationships in a schema definition 147 (XML/RDF) or link type definition (XLink). 148 [Charter(Requirement1&4), List(Bugbee, Solo)] 149 3 Validity and Identity 150 A. Only enough information necessary to check the validity 151 of the cryptographic signature need be provided. 152 [Reagle] 153 B. Each signature shall be associated with information to 154 identify the signer and/or the cryptographic information 155 required to validate the signature. [List(Solo)] 156 3 An XML-Signature can apply to a part or totality of an XML 157 document. [Charter, Brown] 158 4 More than one signature may exist over any resource.[Charter, 159 Brown] 160 5 A key use of XML Signatures will be detached Web signatures. In 161 conjunction with XML facilities (including packaging) signatures 162 may be embedded within or encapsulate XML or encoded content. 163 [Charter] 164 6 The Signature syntax specification will not specify methods of 165 serialization or canonicalization. XML content is normalized by 166 specifying an appropriate content C14N (canonicalization) 167 algorithm [DOMHASH, C14N]; applications are expected to normalize 168 application specific semantics prior to handing data to a 169 XML-Signature application. [Charter] 170 7 An XML-Signature application must be able to use and understand 171 1 XML-namespaces [XML-namespaces] within its own signature 172 syntax. Applications may optionally choose C14N algorithms 173 which do or do not process namespaces within XML content. 174 2 XLink [Xlink]. Applications will use XLink locators within 175 the signature manifest to reference signed resources. 176 Signature applications will not embed or expand XLink 177 references in the signed content, though applications may 178 optionally choose C14N algorithms which provide this feature. 179 3 XML-Pointers [XPointer]. Applications will reference/select 180 parts of XML documents using XML-Pointer within an XLink 181 locator. [Reagle, WS-list(1)] 182 8 Implementation/Design Philosophy 183 A. XML Signatures will be developed as part of the broader Web 184 design philosophy of decentralization, URIs, Web data 185 [WebData], modularity/layering/extensibility, and assertions 186 as statements about statements. [Reagle] 187 B. The ability to leverage existing cryptographic provider (and 188 infrastructure) primitives is desirable. [List(Solo)] 190 3 Requirements 192 Signature Data Model and Syntax 194 1 The XML-Signature data structures will be predicated on an RDF 195 data model [RDF] but need not use the RDF serialization syntax. 196 [Charter] 197 2 XML-Signatures can be applied to any Web resource -- including 198 non-XML content. XML-Signature referents are identified with XML 199 locators (URIs or fragments) within the manifest that refer to 200 external or internal resources (i.e., network accessible or within 201 the same XML document/package). [Berners-Lee, Reagle, Brown, 202 List(Vincent)] 203 1 Entries may include explicit content type information. 204 [List(Solo)] 205 3 XML-Signatures are first class objects themselves and consequently 206 can be referenced and signed. [Berners-Lee, Reagle] 207 4 Algorithm Identification 208 A. Whenever possible, any resource or algorithm identifier is a 209 first class object, and addressable by a URI. [Beners-Lee, 210 Reagle] 211 B. Ability to specify algorithms independently and to reference 212 the algorithms linked to standard algorithm specifications 213 (e.g. OIDs) [List(Solo)] 214 5 XML-Signatures must be able to apply to the original version of an 215 included/encoded resource. [WS-list (Brown/Himes)] 217 Format 219 1 An XML-Signature is XML. [Charter] 220 2 An XML document of a certain type must still be recognizable as 221 its original type when signed. [WS-summary] 222 3 XML-Signature will provide a mechanism that facilitates the 223 production of composite documents -- by addition or deletion -- 224 while preserving the signature characteristics (integrity, 225 authentication, and non-repudiatability) of the consituent parts. 226 [Charter, Brown, List(Bugbee)] 227 4 ?Packaging? 229 Cryptography 231 1 The solution shall provide indifferently for digital signature and 232 message authentication codes, considering symmetric and asymmetric 233 authentication schemes as well as dynamic negotiation of keying 234 material. [Brown] 236 Processing 238 1 In the event of redundant attributes within the XML Signature 239 syntax and relevant cryptographic blobs, XML Signature 240 applications prefer the XML Signature semantics. [Reagle] 242 Coordination 244 The XML Signature specification should meet the requirements of the 245 following applications: 246 1 Internet Open Trading Protocol v2.0 [Charter] 247 2 Financial Services Mark Up Language v2.0 [Charter] 249 To ensure the above requirements are adequately addressed, the XML 250 Signature specification must be reviewed by a designated member of the 251 following communities: 252 1 XML Syntax Working Group [Charter] 253 2 XML Linking Working Group [Charter] 254 3 XML Schema Working Group [Charter] 255 4 Metadata Coordination Group [Charter] 256 5 ?W3C Internationalization Interest Group? 258 4 References 260 Berners-Lee 261 Axioms of Web Architecture: URIs. 262 http://www.w3.org/DesignIssues/Axioms.html 264 Brown-XML-DSig 265 Internet Draft. Digital Signatures for XML 266 http://search.ietf.org/internet-drafts/draft-brown-xml-dsig-00. 267 txt 269 C14N 270 XML Canonicalization Requirements. 271 http://www.w3.org/TR/NOTE-xml-canonical-req 273 Charter 274 XML-DSig Charter. 275 http://www.w3.org/1999/05/XML-DSig-charter-990521.html 277 DOMHASH 278 Internet Draft. Digest Values for DOM (DOMHASH) 279 http://search.ietf.org/internet-drafts/draft-hiroshi-dom-hash-0 280 1txt 282 Infoset-Req 283 XML Information Set Requirements Note. 284 http://www.w3.org/TR/NOTE-xml-infoset-req 286 IOTP-DSig 287 Internet Draft. Digital Signatures for the Internet Open 288 Trading Protocol 289 http://www.ietf.org/internet-drafts/draft-ietf-trade-iotp-v1.0- 290 dsig-00.txt 292 Namespaces 293 Namespaces in XML Recommendation. 294 http://www.w3.org/TR/REC-xml-names 296 Signature List 297 http://lists.w3.org/Archives/Public/w3c-ietf-xmldsig/ 299 WS (list, summary) 300 XML-DSig '99: The W3C Signed XML Workshop 301 http://www.w3.org/DSig/signed-XML99/ 302 http://www.w3.org/DSig/signed-XML99/summary.html 304 XLink 305 XML Linking Language 306 http://www.w3.org/TR/WD-xlink 308 XML 309 Extensible Markup Language (XML) Recommendation. 310 http://www.w3.org/TR/REC-xml 312 XML-namespaces 313 Namespaces in XML 314 http://www.w3.org/TR/REC-xml-names/ 316 XPointer 317 XML Pointer Language (XPointer) 318 http://www.w3.org/TR/WD-xptr 320 WebData 321 Web Architecture: Describing and Exchanging Data. 322 http://www.w3.org/1999/04/WebData