idnits 2.17.1 draft-ietf-xmldsig-requirements-01.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? == 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 an Introduction section. ** 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. ** There are 30 instances of too long lines in the document, the longest one being 1 character in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 51 has weird spacing: '...ds when depen...' -- 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 (March 20, 1999) is 9166 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? 'XML' on line 242 looks like a reference -- Missing reference section? 'Charter' on line 286 looks like a reference -- Missing reference section? 'XLink' on line 142 looks like a reference -- Missing reference section? 'RDF' on line 204 looks like a reference -- Missing reference section? 'Oslo' on line 191 looks like a reference -- Missing reference section? 'DOMHASH' on line 167 looks like a reference -- Missing reference section? 'XML-C14N' on line 167 looks like a reference -- Missing reference section? 'XML-namespaces' on line 173 looks like a reference -- Missing reference section? 'Xlink' on line 180 looks like a reference -- Missing reference section? 'XPointer' on line 186 looks like a reference -- Missing reference section? 'Berners-Lee' on line 230 looks like a reference -- Missing reference section? 'WebData' on line 195 looks like a reference -- Missing reference section? 'Brown' on line 261 looks like a reference -- Missing reference section? 'Beners-Lee' on line 235 looks like a reference -- Missing reference section? 'WS-summary' on line 246 looks like a reference -- Missing reference section? 'IOTP' on line 276 looks like a reference -- Missing reference section? 'XFA' on line 278 looks like a reference -- Missing reference section? 'XFDL' on line 278 looks like a reference -- Missing reference section? 'XML-fragment' on line 292 looks like a reference Summary: 8 errors (**), 0 flaws (~~), 2 warnings (==), 21 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-01.txt 4 Expires March 20, 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 a production of the joint IETF/W3C XML Signature 16 Working Group. 18 http://www.w3.org/Signature 20 The latest version of this draft series may be found at: 22 http://www.w3.org/TR/1999/xml-dsig-requirements 24 This document is an Internet-Draft and is in full conformance with all 25 provisions of Section 10 of RFC2026. 27 Internet-Drafts are working documents of the Internet Engineering Task 28 Force (IETF), its areas, and its working groups. Note that other 29 groups may also distribute working documents as Internet-Drafts. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet- Drafts as reference 34 material or to cite them other than as "work in progress." 36 The list of current Internet-Drafts can be accessed at 37 http://www.ietf.org/ietf/1id-abstracts.txt 39 The list of Internet-Draft Shadow Directories can be accessed at 40 http://www.ietf.org/shadow.html. 42 W3C Status of this document 44 This is a Last Call XML Signature Requirements public Working Draft. 45 This report is not expected to be advanced to Recommendation. Instead, 46 this Last Call designation is (1) a representation of WG consensus, 47 (2) an invitation for comments that will affect the future course of 48 the technical specification, and (3) an opportunity to identify and 49 obtain commitments regarding WG dependencies. This document will be 50 referred to at least the W3C XML Plenary Interest Group and W3C Chairs 51 Working Group. Last Call period ends when dependencies between WGs 52 have been acknowledged and the Signature Chairs have procured 53 commitments of review. This is expected to take six weeks from the 54 date of publication. 56 This document attempts to capture the Working Group's consensus though 57 it contains points which are still uncertain or not well 58 specified. Issues which are still being actively discussed during the 59 publication of this document are of class="discuss" and rendered in 60 navy by style sheet compliant applications. 62 Please send comments to the editor and cc: the list 63 . Publication as a Working Draft does not 64 imply endorsement by the W3C membership. This is a draft document and 65 may be updated, replaced or obsoleted by other documents at any time. 66 It is inappropriate to cite W3C Drafts as other than "work in 67 progress". A list of current W3C working drafts can be found at 68 http://www.w3.org/TR 70 Abstract 72 This document lists the design principles, scope, and requirements for 73 the XML Digital Signature specification. It includes requirements as 74 they relate to the signature syntax, data model, format, cryptographic 75 processing, and external requirements and coordination. 77 Table of Contents 79 1. 1. Introduction 80 2. 2. Design Principles and Scope 81 3. 3. Requirements 82 3.1 1. Signature Data Model and Syntax 83 3.2 2. Format 84 3.3 3. Cryptography and Processing 85 3.4 4. Coordination 86 4. 4. References 88 1 1. Introduction 90 The XML 1.0 Recommendation [XML] describes the syntax of a class of 91 data objects called XML documents. The mission of this working group 92 is to develop a XML syntax used for representing signatures on digital 93 content and procedures for computing and verifying such signatures. 94 Signatures will provide data integrity, authentication, and/or 95 non-repudiatability. 97 This document lists the design principles, scope, and requirements 98 over three things: (1) the scope of work available to the WG, (2) the 99 XML signature specification, and (3) applications that implement the 100 specification. It includes requirements as they relate to the 101 signature syntax, data model, format, cryptographic processing, and 102 external requirements and coordination. Those things that are required 103 are designated as "must," those things that are optional are 104 designated by "may," those things that are optional but recommended 105 are designated as "should." 107 2 2. Design Principles and Scope 109 1. The specification must describe how to a sign digital content, and 110 XML content in particular. [Charter] 111 2. XML-signatures are generated from a hash over the canonical form 112 of a signature manifest. The manifest must support references to 113 Web resources, the hash of the resource content (or its 114 canonicalized form), and (optionally) the resource content type. 115 [Brown, List(Solo)] Web resources are defined as any digital 116 content content that can be addressed using the syntax of XLink 117 locator [XLink]). 118 Comment: Scenarios are being explored which examine the ability to 119 sign without requiring a manifest whereas the scope of the signed 120 content is designated by the relative placement of signature 121 elements in the XML stream/tree. For instance: 122 ...... 123 or 124 pricelist... ... 125 126 3. The meaning of a signature is simple: The XML-signature syntax 127 associates the content of resources listed in a manifest with a 128 key via a strong one-way transformation. 129 1. The XML-signature syntax must be extensible such that it can 130 support arbitrary application/trust semantics and assertion 131 capabilities -- that can also be signed. 132 [Charter(Requirement1&4), List(Bugbee, Solo)] 133 2. The WG is not chartered to specify trust semantics, but 134 syntax and processing rules necessary for communicating 135 signature validity (authenticity, integrity and 136 non-repudiation). [Charter(Requirement1)] At the Chairs' 137 discretion and in order to test the extensibility of the 138 syntax, the WG may produce non-standard-track proposals 139 defining common semantics (e.g., package, timestamps, 140 endorsement, etc.) relevant to signed assertions about Web 141 resources in a schema definition [XML, RDF] or link type 142 definition [XLink]. 143 Comment: A more formal definition of a signed resource is the 144 following evaluates as true "definition(inputs):constraints" where 145 R is a resource., I is a resource identifier (URI), and C is 146 content (sequence-of-octects). 147 signed-resource(I, C, key, sig): there was some request R such 148 that GET(R) = C and address(R) = I and sign-doc(C, key, sig) 149 sign-doc(C, key, sig): sig is the value of a strong one-way 150 function over content and key that yields C integrity/validity and 151 K non-repudiability 152 4. The specification must not specify methods of confidentiality 153 though the Working Group may report on the feasibility of such 154 work in a future or rechartered activity. [List(Bugbee)] 155 5. The specification must only require the provision of key 156 information essential to checking the validity of the 157 cryptographic signature. For instance, identity and key recovery 158 information might be of interest to particular applications, but 159 they are not within the class of required information defined in 160 this specification. [List(Reagle)] 161 6. The specification must define or reference at least one method of 162 canonicalizing and hashing the signature syntax (i.e., the 163 manifest and signature blocks). [Oslo] The specification must not 164 specify methods of canonicalizing resource content [Charter], 165 though it may specify security requirements over such methods. 166 [Oslo] Such content is normalized by specifying an appropriate 167 content C14N (canonicalization) algorithm [DOMHASH, XML-C14N]. 168 Applications are expected to normalize application specific 169 semantics prior to handing data to a XML-signature application. 170 [Charter] 171 7. XML-signature applications must be conformant with the 172 specifications as follows: 173 1. XML-namespaces [XML-namespaces] within its own signature 174 syntax. Applications may choose C14N algorithms which do or 175 do not process namespaces within XML content. For instance, 176 some C14N algorithms may opt remove all namespace 177 declarations, others may rewrite namespace declarations to 178 provide for context independent declarations within every 179 element. 180 2. XLink [Xlink] within its own signature syntax. Applications 181 must use XLink locators within the signature manifest to 182 reference resources. Signature applications must not embed or 183 expand XLink references in signed content, though 184 applications may choose C14N algorithms which provide this 185 feature. 186 3. XML-Pointers [XPointer] within its own signature syntax. If 187 applications reference/select parts of XML documents, they 188 must use XML-Pointer within an XLink locator. [WS-list(1)] 189 The WG may specify security requirements that constrain the 190 operation of these dependencies to ensure consistent and secure 191 signature generation and operation. [Oslo] 192 8. XML-signatures must be developed as part of the broader Web design 193 philosophy of decentralization, URIs, Web data, 194 modularity/layering/extensibility, and assertions as statements 195 about statements. [Berners-Lee, WebData] In this context, existing 196 cryptographic provider (and infrastructure) primitives should be 197 taken advantage of. [List(Solo)] 199 3 3. Requirements 201 3.1 1. Signature Data Model and Syntax 203 1. XML-signature data structures must be based on the RDF data model 204 [RDF] but need not use the RDF serialization syntax. [Charter] 205 2. XML-signatures apply to any resource addressable by a locator -- 206 including non-XML content. XML-signature referents are identified 207 with XML locators (URIs or fragments) within the manifest that 208 refer to external or internal resources (i.e., network accessible 209 or within the same XML document/package). [Berners-Lee, Brown, 210 List(Vincent), WS, XFDL] 211 3. XML-signatures must be able to apply to a part or totality of a 212 XML document. [Charter, Brown] 213 Comment: A related requirement under consideration is requiring 214 the specification to support the ability to indicate those 215 portions of a document one signs via exclusion of those portions 216 one does not wish to sign. This feature allows one to create 217 signatures that have document closure, retain ancestor 218 information, and retain element order of non-continuous regions 219 that must be signed. We are considering implementing this 220 requirement via (1) a special element, (2) an 221 exclude list accompanying the resource locator, or (3) a request 222 to change the XML-Fragment or XPointer specifications to yield 223 this functionality. See List(Boyer(1,2)) for further discussion of 224 this issue. 225 4. Multiple XML-signatures must be able to exist over the static 226 content of a Web resource given varied keys, content 227 transormations, and algorithm specifications (signature, hash, 228 canonicalization, etc.). [Charter, Brown] 229 5. XML-signatures are first class objects themselves and consequently 230 must be able to be referenced and signed. [Berners-Lee] 231 6. The specification must permit the use of varied digital signature 232 and message authentication codes, such as symmetric and asymmetric 233 authentication schemes as well as dynamic agreement of keying 234 material. [Brown] Resource or algorithm identifier are a first 235 class objects, and must be addressable by a URI. [Beners-Lee] 236 7. XML-signatures must be able to apply to the original version of an 237 included/encoded resource. [WS-list (Brown/Himes)] 239 3.2 2. Format 241 1. An XML-signature must be an XML element (as defined by production 242 39 of the XML1.0 specification. [XML]) 243 2. An XML document of a certain type must still be recognizable as 244 its original type when signed. For example, an XML form, when 245 signed, should still be recognizable as a XML form to its 246 application after it has been signed. [WS-summary] 247 3. XML-signature must provide a mechanism that facilitates the 248 production of composite documents -- by addition or deletion -- 249 while preserving the signature characteristics (integrity, 250 authentication, and non-repudiatability) of the consituent parts. 251 [Charter, Brown, List(Bugbee)] 252 4. A key use of XML-signatures will be detached Web signatures. 253 However, signatures may be embedded within or encapsulate XML or 254 encoded content. [Charter] This WG must specify a simple method of 255 packaging and encapsulation if no W3C Recommendation is available. 257 3.3 3. Cryptography and Processing 259 1. The specification must permit arbitrary cryptographic signature 260 and message authentication algorithms, symmetric and asymmetric 261 authentication schemes, and key agreement methods. [Brown] 262 2. The specification must specify at least one mandatory to implement 263 signature canonicalization, content canonicalization, hash, and 264 signature algorithm. 265 3. In the event of redundant attributes within the XML Signature 266 syntax and relevant cryptographic blobs, XML Signature 267 applications prefer the XML Signature semantics. 268 Comment: Another possibility is that an error should be generated, 269 however it isn't where a conflict will be flagged between the 270 various function and application layers regardless. 272 3.4 4. Coordination 274 1. The XML Signature specification should meet the requirements of 275 the following applications: 276 1. Internet Open Trading Protocol v1.0 [IOTP] 277 2. Financial Services Mark Up Language v2.0 [Charter] 278 3. At least one forms application [XFA, XFDL] 279 2. To ensure that all requirements within this document are 280 adequately addressed, the XML Signature specification must be 281 reviewed by a designated member of the following communities: 282 1. XML Syntax Working Group: canonicalization dependencies. 283 [Charter] 284 2. XML Linking Working Group: signature referants. [Charter] 285 3. XML Schema Working Group: signature schema design. [Charter] 286 4. Metadata Coordination Group: data model design. [Charter] 287 5. W3C Internationalization Interest Group: [AC Review] 288 6. XML Package Working Group: signed content in/over packages. 289 7. XML Fragment Working Group: signing portions of XML content. 290 Comment: Members of the WG are very interested in signing and 291 processing XML fragments and packaged components. Boyer asserts 292 that [XML-fragment] does not "identify non-contiguous portions of 293 a document in such a way that the relative positions of the 294 connected components is preserved." Packaging is a capability 295 critical to XML-Signature applications, but it is clearly 296 dependent on clear trust/semantic definitions, package application 297 requirements, and even cache-like application requirements. It is 298 not clear how this work will be addressed. 300 4 4. References 302 AC Review 303 Misha Wolf. "The Charter should include the I18N WG in the 304 section on 'Coordination with Other Groups.'" 305 http://lists.w3.org/Archives/Team/xml-dsig-review/1999May/0007. 306 html 308 Berners-Lee 309 Axioms of Web Architecture: URIs. 310 http://www.w3.org/DesignIssues/Axioms.html 311 Web Architecture from 50,000 feet 312 http://www.w3.org/DesignIssues/Architecture.html 314 Brown-XML-DSig 315 Internet Draft. Digital Signatures for XML 316 http://search.ietf.org/internet-drafts/draft-ietf-xmldsig-signa 317 ture-00.txt 319 Charter 320 XML Signature (xmldsig) Charter. 321 http://www.w3.org/1999/05/XML-DSig-charter-990521.html 323 DOMHASH 324 Internet Draft. Digest Values for DOM (DOMHASH) 325 http://search.ietf.org/internet-drafts/draft-hiroshi-dom-hash-0 326 1.txt 328 FSML 329 FSML 1.5 Reference Specification 330 http://www.echeck.org/library/ref/fsml-v1500a.pdf 332 Infoset-Req 333 XML Information Set Requirements Note. 334 http://www.w3.org/TR/1999/NOTE-xml-infoset-req-19990218.html 336 IOTP 337 Internet Open Trading Protocol v1.0 338 draft-ietf-trade-iotp-v1.0-protocol-04.txt 340 IOTP-DSig 341 Internet Draft. Digital Signatures for the Internet Open 342 Trading Protocol 343 http://www.ietf.org/internet-drafts/draft-ietf-trade-iotp-v1.0- 344 dsig-00.txt 346 Oslo 347 Minutes of the XML Signature WG Sessions at IETF face-to-face 348 meeting in Oslo. 350 RDF 351 RDF Schema 352 http://www.w3.org/TR/1999/PR-rdf-schema-19990303 353 RDF Model and Syntax 354 http://www.w3.org/TR/1999/REC-rdf-syntax-19990222 356 Signature WG List 357 http://lists.w3.org/Archives/Public/w3c-ietf-xmldsig/ 359 URI 360 Uniform Resource Identifiers (URI): Generic Syntax 361 http://www.ietf.org/rfc/rfc2396.txt 363 WS (list, summary) 364 XML-DSig '99: The W3C Signed XML Workshop 365 http://www.w3.org/DSig/signed-XML99/ 366 http://www.w3.org/DSig/signed-XML99/summary.html 368 XLink 369 XML Linking Language 370 http://www.w3.org/1999/07/WD-xlink-19990726 372 XML 373 Extensible Markup Language (XML) Recommendation. 374 http://www.w3.org/TR/1998/REC-xml-19980210 376 XML-C14N 377 XML Canonicalization Requirements. 378 http://www.w3.org/TR/1999/NOTE-xml-canonical-req-19990605 380 XFA 381 XML Forms Architecture (XFA) 382 http://www.w3.org/Submission/1999/05/ 384 XFDL 385 Extensible Forms Description Language (XFDL) 4.0 386 http://www.w3.org/Submission/1998/16/ 388 XML-Fragment 389 XML-Fragment Interchange 390 http://www.w3.org/1999/06/WD-xml-fragment-19990630.html 392 XML-namespaces 393 Namespaces in XML 394 http://www.w3.org/TR/1999/REC-xml-names-19990114 396 XML-schema 397 XML Schema Part 1: Structures 398 http://www.w3.org/1999/05/06-xmlschema-1/ 399 XML Schema Part 2: Datatypes 400 http://www.w3.org/1999/05/06-xmlschema-2/ 402 XPointer 403 XML Pointer Language (XPointer) 404 http://www.w3.org/1999/07/WD-xptr-19990709 406 WebData 407 Web Architecture: Describing and Exchanging Data. 408 http://www.w3.org/1999/04/WebData