idnits 2.17.1 draft-brown-xml-dsig-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-25) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. 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 Internet-Drafts being working documents. ** 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? ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. ** Bad filename characters: the document name given in the document, 'draft-brown-xml-dsig-00.txt,', contains other characters than digits, lowercase letters and dash. ** Missing revision: the document name given in the document, 'draft-brown-xml-dsig-00.txt,', does not give the document revision number ~~ Missing draftname component: the document name given in the document, 'draft-brown-xml-dsig-00.txt,', does not seem to contain all the document name components required ('draft' prefix, document source, document name, and revision) -- see https://www.ietf.org/id-info/guidelines#naming for more information. == Mismatching filename: the document gives the document name as 'draft-brown-xml-dsig-00.txt,', but the file name used is 'draft-brown-xml-dsig-00' == 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 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 separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 1060: '... the current DTD MUST be able to recog...' Miscellaneous warnings: ---------------------------------------------------------------------------- == Couldn't figure out when the document was first submitted -- there may comments or warnings related to the use of a disclaimer for pre-RFC5378 work that could not be issued because of this. Please check the Legal Provisions document at https://trustee.ietf.org/license-info to determine if you need the pre-RFC5378 disclaimer. -- The document date (January 1999) is 9232 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) ** Downref: Normative reference to an Informational RFC: RFC 2104 ** Obsolete normative reference: RFC 2141 (Obsoleted by RFC 8141) ** Obsolete normative reference: RFC 2396 (Obsoleted by RFC 3986) -- Possible downref: Non-RFC (?) normative reference: ref. 'Schneier' -- Possible downref: Non-RFC (?) normative reference: ref. 'XLink' -- Possible downref: Non-RFC (?) normative reference: ref. 'XML' Summary: 14 errors (**), 1 flaw (~~), 3 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Draft Richard D. Brown 2 GlobeSet, Inc. 3 Expires July 1999 January 1999 5 Digital Signatures for XML 6 ------- ---------- --- --- 8 Richard D. Brown 9 GlobeSet, Inc. 11 Status of This Document 13 This draft, file name draft-brown-xml-dsig-00.txt, is intended to be 14 become a Proposed Standard RFC. Distribution of this document is 15 unlimited. Comments should be sent to the DSIG mailing list or to the author. 18 This document is an Internet-Draft. Internet-Drafts are working 19 documents of the Internet Engineering Task Force (IETF), its areas, 20 and its working groups. Note that other groups may also distribute 21 working documents as Internet-Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six 24 months. Internet-Drafts may be updated, replaced, or obsoleted by 25 other documents at any time. It is not appropriate to use Internet- 26 Drafts as reference material or to cite them other than as a 27 ``working draft'' or ``work in progress.'' 29 To view the entire list of current Internet-Drafts, please check the 30 "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow 31 Directories on ftp.is.co.za (Africa), ftp.nordu.net (Northern 32 Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au (Pacific 33 Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu (US West Coast). 35 Abstract 37 A syntax and procedures for the computation and verification of XML 38 digital signatures is specified. 40 Table of Contents 42 Status of This Document....................................1 43 Abstract...................................................1 45 Table of Contents..........................................2 47 1. Introduction............................................4 48 2. Objective and Requirements..............................4 49 3. Signature Basics........................................5 50 3.1 Signature Element......................................5 51 3.2 Resource Element.......................................5 52 3.3 Other Attributes Element...............................6 53 3.4 Originator and Recipient Information Elements..........6 54 3.5 Key Agreement Algorithm Element........................7 55 3.6 Signature Algorithm Element............................8 56 4. Signature Principles....................................8 57 4.1 Enabling Signature in XML Applications.................8 58 4.2 Encapsulating Arbitrary Contents.......................9 59 4.3 Implementing Endorsement..............................10 60 4.4 Supporting Composite Documents........................10 61 4.5 Facilitating One-pass Processing......................11 62 5. Detailed Signature Syntax..............................12 63 5.1 Namespace Attributes..................................12 64 5.2 dsig:eval Global Attribute............................13 65 5.3 Uniform Resource Names................................14 66 5.4 Document..............................................14 67 5.5 DigestAlgorithm.......................................15 68 5.6 Algorithm.............................................16 69 5.7 Parameter.............................................16 70 5.8 Package...............................................17 71 5.9 ContentInfo...........................................18 72 5.10 Value................................................18 73 5.11 Signatures...........................................19 74 5.12 Signature............................................19 75 5.13 Manifest.............................................20 76 5.14 Resource.............................................20 77 5.15 Locator..............................................21 78 5.16 Digest...............................................21 79 5.17 Attributes...........................................22 80 5.18 Attribute............................................22 81 5.19 Date.................................................23 82 5.20 OriginatorInfo.......................................24 83 5.21 RecipientInfo........................................24 84 5.22 Identifier...........................................25 85 5.23 IssuerAndSerialNumber................................25 86 5.24 SignatureAlgorithm...................................26 87 5.25 Certificates.........................................26 88 5.26 Certificate..........................................26 89 5.27 Integer..............................................27 90 5.28 Real.................................................28 91 5.29 Keyword..............................................28 92 5.30 Resources............................................29 93 6. Supported Algorithms...................................29 94 6.1 Digest Algorithms.....................................30 95 6.2 Key Agreement Algorithms..............................30 96 6.3 Key Exchange Aglorithms...............................30 97 6.4 Signature Algorithms..................................31 98 6.5 SHA1..................................................31 99 6.6 DOM-HASH..............................................31 100 6.7 XHASH.................................................32 101 6.8 PKCS12-PBE............................................32 102 6.9 HMAC..................................................33 103 6.10 DSA..................................................33 104 6.11 RSA..................................................33 105 6.12 ECDSA................................................34 106 7. Uniform Resource Names.................................34 107 8. Certificate Supplement.................................34 108 9. Conformance Requirements...............................35 109 10. Examples..............................................35 110 10.1 Signature DTD - Embedded Content.....................35 111 10.2 Signature DTD - Detached Signature...................37 112 10.3 Extended DTD - Domain-specific Attribute.............38 113 11. Signature DTD.........................................40 114 12. Security Considerations...............................41 116 References................................................42 117 Author's Address..........................................42 118 Expiration and File Name..................................42 120 1. Introduction 122 XML, the Extensible Markup Language [XML], is a syntactical standard 123 elaborated by the World Wide Web Consortium. XML is a subset of an 124 existing and widely used international text processing standard known 125 as SGML (Standard Generalized Markup Language). XML is intended 126 primarily for structuring data exchanged and served over the World 127 Wide Web. 129 As it is anticipated that XML will be widely used in the exchange of 130 business and commercial data, and it has been already established 131 that digital signatures will play an important role in enabling 132 electronic commerce, the necessity to promote a digital signature 133 standard for general XML documents becomes evident. 135 Drafted with IOTP (Internet Open Trading Protocol) requirements in 136 mind, this document has been further enhanced as comments were 137 received and alternative proposals disclosed. It is now expected that 138 it provides a more general solution to signing XML documents. 140 2. Objective and Requirements 142 The objective of this document is to propose syntax and procedures 143 for the computation and verification of digital signatures applicable 144 to general XML documents. 146 This proposal has been established in light of the requirements that 147 have been gathered while reviewing diverse projects and alternative 148 approaches such as IOTP [draft-ietf-trade-iotp-v1.0-protocol-*.txt], 149 eCheck [x], BIPS [x], SDML [x], and XMLDSIG [x]. The following 150 requirements have been identified: 152 -- The solution shall provide a means for building authentication 153 into XML applications, but shall also propose an XML alternative 154 to binary signature syntax for signing arbitrary contents. 156 -- The solution shall provide indifferently for digital signature and 157 message authentication codes, considering symmetric and asymmetric 158 authentication schemes as well as dynamic negotiation of keying 159 material. 161 -- The solution shall provide a mechanism that eases the production 162 of composite documents that consist of the combination by addition 163 or deletion of authenticated blocks of information, while 164 preserving verifiability of the origin and authenticity of these 165 blocks of information. 167 -- The solution shall enable authentication of part or totality of an 168 XML document. 170 -- The solution shall enable authentication of internal and external 171 resources. 173 -- The solution shall provide for extended signature functionality 174 such as co-signature, endorsement, plurality of recipients, etc. 176 3. Signature Basics 178 3.1 Signature Element 180 This specification consists primarily of the definition of an XML 181 element known as the Signature element. This element is comprised of 182 two sub-elements. The first one is a set of authenticated attributes, 183 known as the signature Manifest, which comprises such things as a 184 unique reference to the resource being authenticated and an 185 indication of the keying material and algorithms being used. The 186 second sub-element consists of the digital signature value. 188 189 190 (resource information block) 191 (originator information block) 192 (recipient information block) 193 (other attributes) 194 (signature algorithms information block) 195 196 197 (encoded signature value) 198 199 201 The digital signature is not computed directly from the pieces of 202 information to be authenticated. Instead, the digital signature is 203 computed from a set of authenticated attributes (the Manifest), which 204 include a reference to, and a digest of, these pieces of information. 205 The authentication is therefore "indirect". 207 3.2 Resource Element 209 The Resource element consists of a unique and unambiguous reference 210 to the resource being authenticated. It is constructed of a locator, 211 a fingerprint, and optionally a content-type qualifier. 213 214 215 216 217 (digest information block) 218 219 221 The resource locator is implemented as a simple XML Link [XLink]. 222 This not only provides a unique addressing scheme for internal and 223 external resources, but also facilitates authentication of composite 224 documents. 226 3.3 Other Attributes Element 228 The Attributes element consists of a collection of Attribute elements 229 that could be used for inserting specific pieces of information 230 directly into the Signature element. An Attribute element is 231 constructed of a type, a criticality, and a value. 233 234 235 236 237 238 (ANY attribute value) 239 240 242 The attribute value consists of ANY content that is defined in the 243 application DTD. Nevertheless, to facilitate the adoption of such as 244 'signing-time.' 246 3.4 Originator and Recipient Information Elements 248 The purpose of the Originator and Recipient information elements 249 consists of providing identification and keying material for these 250 respective parties. 252 253 (identification information block) 254 (keying material information block) 255 257 258 (identification information block) 259 (keying material information block) 260 262 The actual content of these two elements depends on the 263 authentication scheme being used and the existence or non-existence 264 of a prior relationship between the parties. In some circumstances, 265 it may be quite difficult to distinguish between identification and 266 keying material information. A unique reference to a digital 267 certificate provides for both. This may also stand true for an 268 account number when a prior relationship exists between the parties. 270 The Originator information element is mandatory. Depending on the 271 existence or non-existence of a prior relationship with the 272 recipient, this block either refers to a public credential such as a 273 digital certificate or displays a unique identifier known by the 274 recipient. 276 The Recipient information element may be used when a document 277 contains multiple signature information blocks, each being intended 278 for a particular recipient. A unique reference in the Recipient 279 information block helps the recipients identify their respective 280 Signature information block. 282 The Recipient information element may also be used when determination 283 of the authentication key consists of a combination of keying 284 material provided by both parties. This would be the case, for 285 example, when establishing a key by means of Diffie Hellman 286 [Schneier] Key Exchange algorithm. 288 3.5 Key Agreement Algorithm Element 290 The Key Agreement Algorithm element indicates the algorithm to be 291 used for deriving a one-time session key from a master key. Usage of 292 one-time session key prevents some kinds of attack that require a 293 large volume of cipher-text to be produced by a given key. 295 296 (algorithm information block) 297 299 3.6 Signature Algorithm Element 301 The Signature Algorithm element indicates the algorithm to be used 302 for computation of the signature value. 304 305 (algorithm information block) 306 308 In consideration of the requirements stated previously, this document 309 uses the terminology of "signature" for qualifying indifferently 310 signature and authentication schemes. Therefore, the signature 311 algorithm mentioned above might refer to a signature algorithm such 312 as DSS or to a message authentication code (MAC) such as HMAC. 314 4. Signature Principles 316 4.1 Enabling Signature in XML Applications 318 As mentioned previously, this specification provides a means for 319 building authentication into general XML applications. The mechanism 320 adopted herein considers the "XML Namespaces" specifications[x], 321 which define the requirements for combining multiple DTDs or parts of 322 individual DTD into a single document. 324 According to these specifications, an XML application can build 325 digital signature support by referring explicitly to the elements 326 defined in the Signature DTD. This is accomplished by associating a 327 namespace prefix to the Signature DTD and qualifying Signature 328 element names by means of this prefix. 330 Association of a namespace prefix to a DTD shall be done by means of 331 a xmlns attribute, which could appear in any element that either 332 refers to or contains sub-elements that refer to elements of the DTD 333 considered. A qualified name consists of a namespace prefix, a colon, 334 and a name. 336 338 339 ... 340 342 343 344 345 346 ... 347 348 ... 349 350 351 ... 352 353 354 356 [The XML Namespaces specifications are still work in progress at W3C. 357 A final draft should be available soon, as the specifications entered 358 "last call" September 16, 1998. 360 There are still a few unknowns regarding combination of DTD and use 361 of qualified names in an application DTD that inherits definitions 362 from another DTD. The current paragraph will be developed, as 363 clarifications will be obtained.] 365 4.2 Encapsulating Arbitrary Contents 367 To facilitate encapsulation of arbitrary contents into an XML 368 document, the Signature DTD defines a Package element. Quite similar 369 to a MIME wrapper, this element provides for such things as content 370 type and content encoding. 372 373 374 375 (safe content) 376 377 379 Though it addresses a similar purpose, the Package element specified 380 by this draft proposal is radically different from the one given in 381 the " XML Package" proposal[x]. Such decision has been driven by the 382 possibility to leverage other element definitions of this DTD. 383 However, the current definition might be amended in time if the 384 Package proposal were to be adopted. 386 4.3 Implementing Endorsement 388 Endorsement consists of signing another signature. To facilitate 389 endorsement, the definition of the Signature element provides for an 390 element identifier attribute, which can be used to target a Signature 391 element from a Resource element. 393 394 395 396 397 ... 398 399 ... 400 401 ... 402 404 405 406 408 ... 409 410 ... 411 412 ... 413 415 4.4 Supporting Composite Documents 417 Some protocols consist of the exchange of documents that result from 418 the combination by addition or deletion of common information blocks. 419 This proposal preserves verifiability of the origin and authenticity 420 of these blocks of information as they are exchanged between parties. 422 To facilitate creation and verifiability of composite documents, the 423 current draft proposal has adopted an element, known as the Resources 424 element, which consist of a collection of Resource elements. The 425 authentication of the Resources element is sufficient for ensuring 426 proper authentication of the blocks of information that it 427 references, and verifiability is preserved when individual blocks of 428 information are missing. 430 431 ... 432 434 435 ... 436 438 439 440 441 ... 442 443 444 445 ... 446 447 449 450 451 452 453 ... 454 455 ... 456 460 The adoption of simple XML links as resource locators makes possible 461 the authentication of composite documents. If IDREFs were used 462 instead, it would have been impossible to ensure validity of partial 463 documents - some IDREFs could have been left referencing non-embedded 464 IDs. 466 4.5 Facilitating One-pass Processing 468 Without further definitions, it would be impossible to determine 469 which blocks of information require authentication and which 470 algorithms need to be employed before interpretation of the Resource 471 elements. These elements being generally located at the end of the 472 document, this restriction would prevent computation of the digests 473 during acquisition of the blocks of information. 475 To facilitate one-pass processing, this specification uses another 476 functionality offered by the namespaces proposal. This functionality 477 provides for the definition of global attributes that may be used and 478 recognized across multiple elements. This document specifies the 479 dsig:eval global attribute, which could be used for identifying the 480 blocks of information to be authenticated. This attribute shall 481 reference a Digest Algorithms element, which should be declared 482 before making use of the attribute. 484 485 ... 486 488 490 ... 491 493 494 495 496 497 ... 498 499 ... 500 501 ... 502 504 When encountering the dsig:eval global attribute on the Authenticated 505 Block element, the XML parser is immediately aware of the requirement 506 of computing the digest of this element. All the pieces of 507 information necessary for such computation are provided by the Digest 508 Algorithm element referenced by the attribute. 510 5. Detailed Signature Syntax 512 Though it is expected that Signature support will be primarily built 513 into general XML applications by incorporating definitions of the 514 Signature DTD into other XML applications, the Signature DTD defines 515 the elements necessary to providing an XML alternative to binary 516 signature syntaxes. 518 5.1 Namespace Attributes 520 All the elements defined by the Signature DTD are explicitly bound to 521 the XMLDSIG namespace by means of a dsig prefix. In order to make 522 sure that every element could be individually imported by other XML 523 applications, the element definitions given hereinafter 524 systematically declare a fixed xmlns:dsig attribute. 526 528 533 Recall that many XML applications, presumably including namespaces- 534 sensitive ones, fail to require validating processors. For correct 535 operation with such applications, namespaces declarations must be 536 also provided either directly or via default attributes declared in 537 the internal subset of the DTD. 539 5.2 dsig:eval Global Attribute 541 As mentioned previously, this draft proposal specifies a dsig:eval 542 global attribute that could be used for identifying a block of 543 information to be authenticated. This attribute shall refer to a 544 Digest Algorithms element, which should be declared before making use 545 of the attribute. 547 The XML Namespaces specifications do not explicitly provide for 548 declaration of global attributes. Distinguishing between global 549 attributes and element attributes exists only in the prose 550 description of such attributes. An essential property of global 551 attributes consists nonetheless of the uniqueness of their name that 552 is independent of the elements where they are defined. 554 The definition of elements that could be subject to authentication 555 may define the dsig:eval attribute as follows: 557 559 563 Recall that the namespace prefix that is bound to the XMLDSIG 564 namespace shall be defined before being employed. However, such 565 definition may occur in the element that defines the dsig:eval 566 attribute. 568 The reader shall notice that the terminology "dsig:eval" is 569 inappropriate and used solely for illustrative purposes. This simply 570 means that the name of this attribute is hash and it belongs to the 571 XMLDSIG namespace (whatever prefix is used). 573 5.3 Uniform Resource Names 575 To prevent potential name conflicts in the definition of the numerous 576 type qualifiers considered herein, this specification uses Uniform 577 Resource Names [RFC 2141]. Nonetheless, the current draft proposal 578 leverages established standards such as MIME types by providing 579 unambiguous mapping conventions. 581 A complete list of proposed URNs is given in appendix. This list is 582 temporary and will be submitted for approval to the authors or 583 promoters of the algorithms and data types referenced by these URNs. 585 5.4 Document 587 The Document element constitutes the outermost envelope of an XML 588 document that conforms to the Signature DTD. The definition of this 589 element has been intentionally kept simple and is intended to provide 590 an XML alternative to the ASN1 data types Authenticated Data and 591 Signed Data defined by CMS[x] and PKCS7[x] binary syntax standards. 593 It is expected that this simple, though complete, definition will 594 help the adoption of this proposal and facilitate the production of 595 conformant implementations by a plurality of providers. This 596 definition does not preclude however the definition of more 597 sophisticated constructions to be adopted by particular XML 598 applications. Such applications may either redefine the Document 599 element or promote their own DTD, which shall be partially 600 constructed of elements defined by the Signature DTD. 602 607 611 The definition given above has been deemed sufficient for 612 implementing the following functionality provided by CMS or PKCS7: 613 Authentication of arbitrary contents: This may be done by adequate 614 encapsulation and encoding of the arbitrary contents into the 615 Package element, which shall be further authenticated by means of 616 a Signature element. 617 -- Detached signature: This may be done by means of a Signature 618 element that refers to a resource external to the document. 619 -- Authentication versus signature: The distinction between 620 authentication and signature only depends upon the algorithms 621 being employed for computation of the "signature" value. 622 -- Plurality of recipients: This consists of the insertion of a 623 plurality of Signature elements, each making use of recipient- 624 dependent keying material. 625 -- Plurality of signers: This consists of the insertion of a 626 plurality of Signature elements, each making use of originator- 627 dependent keying material. 629 Content Description 631 DigestAlgorithms: This element has been made mandatory whenever 632 the document embeds the contents to be authenticated. This 633 element specifies the algorithms to be used for computation 634 of the digest of the Package element, thus enabling one-pass 635 processing. 637 Package: This element is used for enveloping and encoding of the 638 contents to be authenticated. Whenever employed, this 639 element shall make use of the dsig:eval global attribute to 640 refer to the Digest Algorithms element described above. 642 Signatures: This element consists of a collection of Signature 643 elements. 645 Certificates: This element consists of a collection of 646 Certificate elements, which may be required by a given key 647 management infrastructure. 649 The definition of collection elements (i.e. Certificates and 650 Signatures) for the sole purpose of grouping similar sub-elements has 651 been adopted for facilitat- ing DOM manipulations. 653 5.5 DigestAlgorithm 655 The purpose of the DigestAlgorithm element consists of specifying the 656 algorithm to be employed in the computation of a message digest. This 657 element is used either as a standalone element for enabling one-pass 658 processing or as a sub-element of the Digest element. 660 662 667 Content Description 668 Algorithm: Algorithm and parameters to be used for Computation of 669 the digest value. 671 Attributes Description 673 id: Element identifier that is used on standalone element for 674 enabling reference by the dsig:eval global attribute. 676 5.6 Algorithm 678 The current draft proposal has adopted a unique Algorithm data type. 679 Though noticeably different from its ASN1 counterpart, this data type 680 serves a similar purpose and provides for the definition of 681 algorithm-specific parameters. The most noticeable difference with 682 ASN1 consists of the assimilation of sub-algorithms as parameters of 683 the primary algorithm. 685 687 692 Content Description 694 Parameter: The contents of an Algorithm element consists of an 695 optional collection of Parameter elements which are specified 696 on a per algorithm basis. 698 Attributes Description 700 type: The type of the algorithm expressed as a Uniform Resource 701 Name. 703 5.7 Parameter 705 A Parameter element provides the value of a particular algorithm 706 parameter, Whose name and format have been specified fo rthe 707 algorithm considered. 709 711 716 Content Description 718 ANY: The contents of a Parameter element consists of ANY valid 719 Construct, which is specified on a per algoritm per parameter 720 basis. 722 Attributes Description 724 type: The type of the parameter expressed as a free form string, 725 whose value is specified on a per algorithm basis. 727 5.8 Package 729 The Package element enables encapsulation of an arbitrary content 730 into an XML document. Behaving like a MIME wrapper, the Package 731 element provides for such things as content type identification and 732 content encoding. 734 738 744 Content Description 746 ContentInfo: Type qualifier for the content. 748 Value: Content value. 750 Attributes Description 752 id: Element identifier that could be used for referencing this 753 element from a Resource element. 755 5.9 ContentInfo 757 The purpose of the ContentInfo element is to describe a given content 758 such that a receiving user agent can deal with the data in an 759 appropriate manner. 761 763 769 Attributes Description 771 type: Type of the content expressed as a Universal Resource Name. 773 subtype: Optional sub-classing of the content type. 775 5.10 Value 777 779 784 Content Description 786 PCDATA: Content value after adequate encoding. 788 Attributes Description 790 encoding: This attribute specifies the decoding scheme to be 791 employed for recovering the original byte stream from the 792 content of the element. The current draft proposal recognizes 793 the following two schemes: 795 none: the content has not been subject to any particular 796 encoding. This does not preclude however the use of native 797 XML encoding such as CDATA section or XML escaping. 799 base64: The content has been encoded by means of the base64 800 encoding scheme. 802 5.11 Signatures 804 The Signatures element consists of a collection of Signature 805 elements. As mentioned in a previous paragraph, this element has been 806 defined for the purpose of facilitating DOM manipulations. 808 810 814 Content Description 816 Signature: A collection of Signature elements. 818 5.12 Signature 820 The Signature element constitutes the core of this specification. It 821 is comprised of two sub-elements. The first one is a set of 822 attributes, known as the Manifest, which actually constitutes the 823 authenticated part of the document. The second sub-element consists 824 of the signature value. 826 828 834 Content Description 836 Manifest: A set of attributes that actually constitutes the 837 authenticated part of the document. 839 Value: Encoding of the signature value. 841 Attributes Description 843 id: Element identifier that could be used for referencing the 844 Signature element from a Resource element when implementing 845 endorsement. 847 5.13 Manifest 849 The Manifest element consists of a collection of attributes that 850 specify such things as a unique reference to the resource being 851 authenticated and an indication of the keying material and algorithms 852 to be used. 854 860 864 Content Description 866 Resource: Unique and unambiguous reference to the resource being 867 authenticated. 869 Attributes: Optional element that consists of a collection of 870 complementary attributes to be authenticated. 872 OriginatorInfo: Element that provides dentification and keying 873 material information related to the originator. 875 RecipientInfo: Optional element that provides identification and 876 keying material information related to the recipient. 878 KeyAgreementAlgorithm: Optional element that indicates the 879 algorithm to be used for establishment of a one-time session 880 key. 882 SignatureAlgorithm: Algorithm to be used for computation of the 883 signature value. 885 5.14 Resource 887 The Resource element consists of a unique and unambiguous reference 888 to a resource being authenticated. It is comprised of a resource 889 locator, a fingerprint, and optionally a content-type qualifier. 891 895 899 Content Description 901 ContentInfo: Content type qualifier. 903 Locator: Locator value that contains either a URI [RFC 2396], a 904 fragment identifier, or both. Notice that making use of a 905 fragment identifier for a document content other than XML is 906 out of the scope of this draft proposal and may lead to 907 inconsistent results. 909 Digest: Fingerprint of the resource. 911 5.15 Locator 913 The Locator element consists of simple XML link [XLink]. This 914 element allows unambiguous reference to a resource or fragment of a 915 resource. 917 919 925 Attributes Description 927 xml:link Required XML link attribute that specifies the nature of 928 the link (simple in this case). 930 href: Locator value that may contains either a URI [RFC 2396], a 931 fragment identifier, or both. 933 5.16 Digest 935 The Digest element consists of the fingerprint of a given resource. 936 This element is constructed of two sub-elements. This first one 937 indicates the algorithm to be used for computation of the 938 fingerprint. The second element consists of the fingerprint value. 940 942 946 Content Description 948 DigestAlgorithm: Algorithm to be used for computation of the 949 fingerprint. 951 Value: Encoding of the fingerprint value. 953 5.17 Attributes 955 The Attributes element consists of a collection of complementary 956 attributes, which shall be included in the authenticated part of the 957 document. 959 961 965 Content Description 967 Attribute: Collection of Attribute elements. 969 5.18 Attribute 971 The Attribute element consists of a complementary piece of 972 information, which shall be included in the authenticated part of the 973 document. Though the current draft proposal defines well-known 974 attributes, this element has been defined primarily for enabling some 975 level of customization in the signature element. An Attribute element 976 consists of a value, a type, and a criticality. 978 980 986 Content Description 988 ANY: The actual value of an attribute depends solely upon its 989 type. 991 Attributes Description 993 type: Type of the attribute. 995 critical: Boolean value that indicates if the attribute is 996 critical (true) or not (false). A recipient shall reject a 997 signature that contains a critical attribute that he does not 998 recognize. However, an unrecognized non-critical attribute 999 may be ignored. 1001 Signing-time Attribute 1003 Standard attribute that could be used for specifying the time at 1004 which the originator purportedly performed the signature process. 1005 This attribute content shall be given as a Date element (cf. 1006 element description). The type identifier of this attribute is 1007 given in the URN appendix. 1009 5.19 Date 1011 The Date element consists of a constrained ISO 8601:1998 date and 1012 time value. 1014 1016 1021 Attributes Description 1023 value: Identification data value. 1025 Date Format 1026 The current draft proposal requires date values to be expressed 1027 according to the following pattern: YYYY '-' MM '-' DD 'T' hh 1028 ':' mm [':' ss ['.' f+]]('+' | '-') hhmm 1030 YYYY: four-digit year 1031 MM: two-digit month (01=January, etc.) 1032 DD: two-digit day of the month (01-31) 1033 hh: two digits of hour (00-23) 1034 mm: two digits of minute (00-59) 1035 ss: two digits of second (00-59) optional 1036 f: digit(s) of fractions of second - optional 1037 zzzz: four digits of amount of offset from UTC expressed in hour 1038 (00-11) and minute (00-59) 1040 For example "1994-11-05T16:15:02.031-0500" denotes November 5, 1041 1994, 4:15:02 pm and 31 milliseconds, US Eastern Standard 1042 Time. 1044 5.20 OriginatorInfo 1046 The OriginatorInfo element is used for providing identification and 1047 keying material information for the originator. 1049 1051 1055 Content Description 1057 ANY: Identification and keying material information may consist 1058 of ANY construct. Such a definition allows the adoption of 1059 application-specific schemes. However, implementations that 1060 comply with the current DTD MUST be able to recognize and 1061 process the elements Identifier and IssuerAndSerialNumber 1062 defined below. 1064 5.21 RecipientInfo 1066 The RecipientInfo element is used for providing identification and 1067 keying material information for the recipient. This element is used 1068 either for enabling recognition of a Signature element by a given 1069 recipient or when determination of the authentication key consists of 1070 the combination of keying material provided by both the recipient and 1071 the originator. 1073 Content Description 1075 The content of this element is similar to the one defined for the 1076 Originator (cf. OriginatorInfo element descrition). 1078 5.22 Identifier 1080 The Identifier element enables identification between parties that 1081 benefit from a prior relationship. The actual meaning and content of 1082 this element is left to the parties. 1084 1086 1091 Attributes Description 1093 value: Identification data value. 1095 5.23 IssuerAndSerialNumber 1097 The IssuerAndSerialNumber element identifies a certificate, and 1098 thereby an entity and a public key, by the distinguished name of the 1099 certificate issuer and an issuer-specific certificate serial number. 1101 1103 1109 Attributes Description 1111 issuer: Distinguished name of the issuing certification 1112 authority. 1114 number: Issuer-specific certificate serial number. 1116 5.24 SignatureAlgorithm 1118 The SignatureAlgorithms element is used for specifying the algorithms 1119 to be used for computation of the signature value. 1121 1123 1127 Content Description 1129 Algorithm: Algorithm and parameters to be used for computation of 1130 the signature value. 1132 5.25 Certificates 1134 The Certificates element consists of a collection of Certificate 1135 elements. The Certificate elements contained in this element are 1136 intended to be sufficient to make chains from the originator 1137 credential(s) to a recognized "certification authority" for all the 1138 recipients. However, this element may contain more Certificate 1139 elements than necessary or, alternatively, less than necessary if it 1140 is known that recipients have an alternate means of obtaining 1141 necessary certificates. 1143 1145 1149 Content Description 1151 Certificate: A collection of Certificate elements. 1153 5.26 Certificate 1155 The Certificate element may be used for either providing the value of 1156 a digital certificate or specifying a location from where it may be 1157 retrieved. 1159 1164 1169 Content Description 1171 IssuerAndSerialNumber: Unique identifier of this certificate. 1172 This element has been made mandatory is order to prevent 1173 unnecessary decoding during validation of a certificate 1174 chain. This feature also helps certificates caching, 1175 especially when the value is not directly provided. 1177 Value: Encoding of the certificate value. The actual value to be 1178 encoded depends upon the type of the certificate. 1180 Locator: XML link element that could be used for retrieving a copy 1181 of the digital certificate. The actual value being returned 1182 by means of this locator depends upon the protocol being 1183 used. 1185 Attributes Description 1187 type: Type of the digital certificate. This attribute is 1188 specified as a Universal Resource Name (cf. Certificate 1189 Supplement). 1191 5.27 Integer 1193 The Integer element is a primary data type that is used in the 1194 definition of algorithm parameters. 1196 1198 1203 Attributes Description 1205 value: Value of the element given according to the format given 1206 below. 1208 Integer Format 1210 The current specification requires integer values to be expressed 1211 According to the following pattern: 1213 ['+'|'-'] n+ 1215 For example, +128, -35635, and 64535 are valid integer 1216 values. 1218 5.28 Real 1220 The Real element is a primary data type that is used in the 1221 definition of algorithm parameters. 1223 1225 1230 Attributes Description 1232 value: Value of the element given according to the format given 1233 below. 1235 Real Format 1237 The current specification requires real values to be expressed 1238 according To the following pattern: 1240 ['+'|'-'] n+ ['. ' f+]['E' ('+'|'-') ee] 1242 For example, 12, -12.34, +12.34E-01, and +0.5 are valid real 1243 numbers. 1245 5.29 Keyword 1247 The Keyword element is a primary data type that is used in the 1248 definition of algorithm parameters. 1250 1252 1257 Attributes Description 1259 value: Value of the element given as a free form string. 1261 5.30 Resources 1263 The Resources element consists of a collection of Resource elements. 1264 Though inaccessible from the Document element of the Signature DTD, 1265 this element is available to more sophisticated constructs that make 1266 use of composite documents. 1268 1270 1276 Content Description 1278 Resource: A collection of Resource elements. 1280 Attributes Description 1282 id: Element identifier that could be used for referencing this 1283 element from a Resource element. 1285 6. Supported Algorithms 1287 This specification uses a unique Algorithm data type. Though 1288 noticeably different from its ASN1 counterpart, this data type serves 1289 a similar purpose and provides for the definition of algorithm- 1290 specific parameters. 1292 The most noticeable difference with ASN1 consists of the assimilation 1293 of sub-algorithms as parameters of the primary algorithm. In other 1294 words, where ASN1 recognizes an algorithm of the type AlgxWithAlgy 1295 (i.e. DsaWithSha1) the current specifications recognize Algx with an 1296 Algy parameter. Such a recursive construct is expected to facilitate 1297 integration with cryptographic toolkits. 1299 6.1 Digest Algorithms 1301 This specificaiton contemplates two kinds of digest algorithms: 1303 Surface string digest algorithms: These algorithms do not have any 1304 particular knowledge about the content being digested and operate 1305 on the raw content value. Changes in the surface string of a given 1306 content affect directly the value of the digest being produced. 1308 Canonical digest algorithms: These algorithms have been tailored for 1309 a particular content type and produce a digest value that depends 1310 upon the core semantics of such content. Changes limited to the 1311 surface string of a given content do not affect the value of the 1312 digest being produced. 1314 6.2 Key Agreement Algorithms 1316 A key-agreement algorithm consists of a function that is used for 1317 deriving a one-time session key from a given master key. Usage of 1318 one-time session keys prevents some kinds of attacks that require a 1319 large volume of cipher-text to be produced with a given key. 1321 Key-agreement algorithms shall not be mistaken with key-exchange 1322 algorithms, which may be implicitly employed for computation of a 1323 master key that results from the combination of keying material 1324 provided by the parties involved in an exchange. In other words, 1325 parties provided with credentials such as Diffie-Hellmann-based 1326 certificates shall establish the value of the master key by means of 1327 the key exchange algorithm and may further derive a one-time session 1328 key from this master key by means of a key-agreement algorithm. A 1329 similar procedure is recommended when making use of a message 1330 authentication code and a shared secret. 1332 6.3 Key Exchange Aglorithms 1334 A key-exchange algorithm consists of a function that is used for 1335 deriving a one-time session key from a given master key. (TBD) 1337 6.4 Signature Algorithms 1339 This specification abusively uses the terminology of 'digital 1340 signature' for qualifying indifferently digital signature and message 1341 authentication codes. Thus, the signature algorithms contemplated 1342 herein include public key digital signature algorithms such as DSA 1343 and message authentication codes such as HMAC [RFC 2104]. 1345 6.5 SHA1 1347 Surface string digest algorithm designed by NIST and NSA for use with 1348 the Digital Signature Standard. This algorithm produces a 160-bit 1349 hash value. 1351 This algorithm does not require any parameter. 1353 6.6 DOM-HASH 1355 XML canonical digest algorithm proposed by IBM Tokyo Research 1356 Laboratory and documented in the DOMHASH proposal[x]. This algorithm 1357 operates on the DOM representation of the document and provides an 1358 unambiguous means for recursive computation of the hash value of the 1359 nodes that constitute the DOM tree. This algorithm has many 1360 applications such as computation of digital signature and 1361 synchronization of DOM trees. However, because the hash value of an 1362 element is computed from the hash values of the inner elements, this 1363 algorithm is better adapted to small documents that do not require 1364 one-pass processing. 1366 As of today, this algorithm is limited to the contents of an XML 1367 document and, therefore, does not provide for authentication of the 1368 internal or external subset of the DTD. Also, there is no explicit 1369 support for XML Namespaces. 1371 The DOM-HASH algorithm requires a single parameter, which shall 1372 consist of a surface string digest algorithm such as SHA1. 1374 Example 1376 1377 1378 1379 1380 1382 6.7 XHASH 1384 XML canonical digest algorithm proposed by GlobeSet and documented in 1385 the XHASH proposal[x]. This algorithm has been inspired by the DOM- 1386 HASH proposal, but operates closer to the surface string of the 1387 document. Elements and attributes are subject to formalization in a 1388 way quite similar to the one proposed by DOM-HASH - XML delimiters 1389 are represented by binary values and entities are replaced by their 1390 actual values. However, formalization happens as elements are 1391 acquired. Furthermore, this algorithm has been tailored for explicit 1392 support of the XML Namespaces and it takes into account some 1393 specifics of this specification (e.g. dsig:eval attribute). 1395 The XHASH algorithm makes use of two parameters. The first one 1396 consists of a surface string digest algorithm such as SHA1. The 1397 second one, optional, may be used for specifying how non-significant 1398 SPACE characters shall be handled by default. Actually, the XML 1399 Specifications define the xml:space attribute that could be used for 1400 specifying if non-significant SPACE characters are to be preserved. 1401 However, possible values for this attribute are limited to 'default' 1402 and 'preserve'. Thus, there is no known way to explicitly specify 1403 that non-significant SPACE characters should be discarded. 1405 Example 1407 1408 1409 1410 1411 1412 1413 1414 1416 6.8 PKCS12-PBE 1418 Key-agreement algorithm proposed by RSA Laboratories and documented 1419 in PKCS12[x]. This algorithm is a generalization of the PBE algorithm 1420 defined in PKCS5[x] and provides for the generation of symmetric keys 1421 and other cryptographic parameters from an established password. 1423 This algorithm requires three parameters. The first one consists of a 1424 one-way hash function (i.e. SHA1), the second one of a random string 1425 (salt), and the last one of an iteration count. 1427 Example 1429 1430 1431 1432 1433 1434 1435 Abkirjegks123qwgtawd456g47 1436 1437 1438 1439 1440 1441 1443 6.9 HMAC 1445 Generalities [RFC 2104] 1447 Example 1449 1450 1451 1452 1453 1454 1455 1456 1457 1458 1459 1460 1462 6.10 DSA 1464 6.11 RSA 1465 6.12 ECDSA 1467 1468 1469 1470 1471 1472 1473 1474 1475 1476 1477 1478 1479 1480 1481 1482 1483 1484 1485 1486 1488 7. Uniform Resource Names 1490 Generalities [RFC 2141] 1492 Content-type URNs 1493 Leveraging MIME [RFC 2046] types. 1494 Other content-types 1496 Algorithm URNs 1498 Certificate Type URNs 1500 8. Certificate Supplement 1502 Locator Protocols (HTTP, LDAP) 1504 Expected Formats 1506 9. Conformance Requirements 1508 TBD 1510 10. Examples 1512 The URN given in the following examples are purely illustrative and, 1513 therefore, shall not be used as reference material. 1515 10.1 Signature DTD - Embedded Content 1517 1518 1522 1523 1524 > 1525 1526 > 1527 1528 1529 1530 1531 1532 1534 1536 1537 1538 abncjflf311257gghn6mj2k134h64AANHdd12== 1539 1540 1542 1544 1545 1546 1547 1548 1549 1550 > 1551 1552 > 1553 1554 1555 1556 1557 1558 1559 bndWGryrt245u6t1dgURTIrr4ir5= 1560 1561 1562 1563 1564 1567 1568 1569 1571 1572 1573 1574 1575 1576 1577 1578 1579 1580 1581 1582 1583 1584 1585 1586 1587 1588 1589 1590 xsqsfasDys2h44u4ehJDe54he5j4dJYTJ= 1591 1592 1594 1596 1598 1599 1603 1604 1606 1607 1610 1611 xsqsfasDys2h44u4ehJDe54he5j4dJYTJ 1612 1613 1615 1617 1619 10.2 Signature DTD - Detached Signature 1621 1622 1625 1627 1629 1630 1631 1632 1633 1634 1635 1636 1637 bndWGryrt245u6t1dgURTIrr4ir5= 1638 1639 1640 1641 1642 1645 1646 1647 1649 1650 1652 1653 1654 1655 1656 1657 1658 1659 1660 1661 1662 1663 1664 1665 1666 1667 1668 1669 xsqsfasDys2h44u4ehJDe54he5j4dJYTJ= 1670 1671 1673 1675 1677 1678 1681 1682 1684 1686 1688 10.3 Extended DTD - Domain-specific Attribute 1690 1691 1696 1697 1701 ]> 1702 1703 1704 1705 1706 1707 1708 > 1709 1710 > 1711 1712 1713 1714 1715 1716 1717 bndWGryrt245u6t1dgURTIrr4ir5= 1718 1719 1720 1721 1722 1723 1724 1725 > 1726 1727 > 1728 1729 1730 1731 1732 1733 1734 bndWGryrt245u6t1dgURTIrr4ir5= 1735 1736 1737 1738 1739 1740 1741 1742 1743 1744 > 1745 1746 > 1747 1748 1749 1750 1752 1753 1754 bndWGryrt245u6t1dgURTIrr4ir5= 1755 1756 1757 1758 1759 1760 1761 1762 1766 1767 1768 1769 1770 1771 1772 1773 1774 1775 1776 1777 1778 1779 1780 1781 1782 1783 1784 1785 xsqsfasDys2h44u4ehJDe54he5j4dJYTJ= 1786 1787 1788 1790 11. Signature DTD 1792 (Insert here) 1794 12. Security Considerations 1796 The entirety of this document is concerned with a signature standard 1797 for XML. 1799 References 1801 [RFC 2046] - N. Freed & N. Borenstein, "Multipurpose Internet Mail 1802 Extensions (MIME) Part Two: Media Types", November 1996. 1804 [RFC 2104] - H. Krawczyk, M. Bellare, R. Canetti, "HMAC: Keyed- 1805 Hashing for Message Authentication", February 1997. 1807 [RFC 2141] - R. Moats, "URN Syntax", May 1997. 1809 [RFC 2396] - T. Berners-Lee, R. Fielding, L. Masinter, "Uniform 1810 Resource Identifiers (URI): Generic Syntax", August 1998. 1812 [Schneier] - Bruce Schneier, "Applied Cryptography: Protocols, 1813 Algorithms, and Source Code in C", 1996, John Wiley and Sons 1815 [XLink] - Eve Maler, Steve DeRose, "XML Linking Language (XLink)", 1816 1818 [XML] - Tim Bray, Jean Paoli, C. M. Sperber-McQueen, "Extensible 1819 Markup Language (XML) 1.0", 1822 [...more to come] 1824 draft-ietf-trade-iotp-v1.0-protocol-*.txt - David Burdett 1826 Author's Address 1828 Richard D. Brown 1829 GlobeSet, Inc. 1830 1250 Capital of TX Hwy. So. 1831 Building One, Suite 300 1832 Austin, TX 78746 USA 1834 EMail: richard_dbrown@globeset.com 1836 Expiration and File Name 1838 This draft expires July 1999. 1840 Its file name is draft-brown-xml-dsig-00.doc.