idnits 2.17.1 draft-ietf-trade-iotp-v1.0-dsig-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 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-ietf-trade-iotp-v1.0-dsig-00.txt,', contains other characters than digits, lowercase letters and dash. ** Missing revision: the document name given in the document, 'draft-ietf-trade-iotp-v1.0-dsig-00.txt,', does not give the document revision number ~~ Missing draftname component: the document name given in the document, 'draft-ietf-trade-iotp-v1.0-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-ietf-trade-iotp-v1.0-dsig-00.txt,', but the file name used is 'draft-ietf-trade-iotp-v1.0-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 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. ** 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 475: '...ate reference ID MUST point to a certi...' RFC 2119 keyword, line 495: '...thm reference ID MUST point to a signa...' RFC 2119 keyword, line 499: '...lue reference ID MUST point to a value...' 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 (February 1999) is 9203 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: 'RFC 2045' is mentioned on line 605, but not defined == Unused Reference: 'RFC 2046' is defined on line 917, but no explicit reference was found in the text ** Downref: Normative reference to an Informational RFC: RFC 1321 ** 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: 17 errors (**), 1 flaw (~~), 5 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 TRADE Working Group Kent Davidson 2 INTERNET-DRAFT Differential 3 Expires: August 1999 February 1999 5 Digital Signatures for the Internet Open Trading Protocol 6 ------- ---------- --- --- -------- ---- ------- -------- 8 Status of This Document 10 This draft, file name draft-ietf-trade-iotp-v1.0-dsig-00.txt, is an 11 addendum to the Internet Open Trading Protocol Specification version 12 1.0, and is intended to become an Informational RFC. Distribution of 13 this document is unlimited. Comments should be sent to the TRADE 14 working group mailing list . 16 This document is an Internet-Draft and is in full conformance with 17 all provisions of Section 10 of RFC2026. Internet-Drafts are working 18 documents of the Internet Engineering Task Force (IETF), its areas, 19 and its working groups. Note that other groups may also distribute 20 working documents as Internet-Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six 23 months. Internet-Drafts may be updated, replaced, or obsoleted by 24 other documents at any time. It is not appropriate to use Internet- 25 Drafts as reference material or to cite them other than as a 26 ``working draft'' or ``work in progress.'' 28 To view the entire list of current Internet-Drafts, please check the 29 "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow 30 Directories on ftp.is.co.za (Africa), ftp.nordu.net (Northern 31 Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au (Pacific 32 Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu (US West Coast). 34 Abstract 36 A syntax and procedures are described for the computation and 37 verification of digital signatures for use within Version 1.0 of the 38 Internet Open Trading Protocol (IOTP). 40 Table of Contents 42 Status of This Document....................................1 43 Abstract...................................................1 45 Table of Contents..........................................2 47 1. Introduction............................................3 48 2. Objective and Requirements..............................3 50 3. Signature Basics........................................4 51 3.1 Signature Element......................................4 52 3.2 Digest Element.........................................4 53 3.3 Originator and Recipient Information Elements..........5 54 4. Detailed Signature Syntax...............................6 55 4.1 Uniform Resource Names.................................6 56 4.2 IOTPSignatures.........................................6 57 4.3 Signature Component....................................7 58 4.3.1 Signature............................................7 59 4.3.2 Manifest.............................................7 60 4.3.3 Algorithm............................................8 61 4.3.4 Digest...............................................9 62 4.3.5 Attributes..........................................10 63 4.3.6 Attribute...........................................10 64 4.3.7 OriginatorInfo......................................10 65 4.3.8 RecipientInfo.......................................11 66 4.3.9 Parameter...........................................12 67 4.4 Certificate Component.................................13 68 4.4.1 Certificate.........................................13 69 4.4.2 IssuerAndSerialNumber...............................13 70 4.5 Common Components.....................................14 71 4.5.1 Value...............................................14 72 4.5.2 Locator.............................................15 73 5. Supported Algorithms...................................15 74 5.1 Digest Algorithms.....................................15 75 5.1.1 DOM-HASH............................................16 76 5.1.2 SHA1................................................16 77 5.1.3 MD5.................................................16 78 5.2 Signature Algorithms..................................16 79 5.2.1 DSA.................................................17 80 5.2.2 HMAC................................................17 81 5.2.3 RSA.................................................17 82 6. Examples...............................................17 83 7. Signature DTD..........................................19 84 8. References.............................................21 86 9. Credits................................................22 87 Expiration and File Name..................................22 89 1. Introduction 91 The Internet Open Trading Protocol (IOTP) provides a payment system 92 independent interoperable framework for Internet commerce as 93 documented in draft-ietf-trade-iotp-v1.0-protocol-*.txt. All IOTP 94 messages are XML documents. XML, the Extensible Markup Language 95 [XML], is a syntactical standard promulgated by the World Wide Web 96 Consortium. XML is intended primarily for structuring data exchanged 97 and served over the World Wide Web. 99 Although IOTP assumes that any payment system used with it provides 100 its own security, there are numerous cases where IOTP requires 101 authentication and integrity services for portions of the XML 102 messages it specifies. 104 2. Objective and Requirements 106 This document covers how digital signatures may be used with XML 107 documents to provide authentication and tamper-proof protocol 108 messages specifically for Version 1.0 of the IOTP protocol. The 109 reader should recognize that an effort towards general XML digital 110 signatures exists but is unlikely to produce its final result in time 111 for IOTP Version 1.0. Future versions of IOTP will probably just 112 adopt by reference the results of this general XML digital signature 113 effort. 115 The objective of this document is to propose syntax and procedures 116 for the computation and verification of digital signatures applicable 117 to Verion 1.0 IOTP protocol messages, providing for: 119 -- Authentication of IOTP transactions 120 -- Provide a means by which an IOTP message may be made "tamper- 121 proof", or detection of tampering is made evident 122 -- Describe a set of available digest and signature algorithms at 123 least one of which is mandatory to implement for interoperability 124 -- Easily integrate within the IOTP 1.0 Specification 125 -- Provide lightweight signatures with minimal redundancy 126 -- Allow a signed portions of IOTP message to be "forwarded" to 127 another trading roles with different signature algorithms than the 128 original recipient 130 3. Signature Basics 132 3.1 Signature Element 134 This specification consists primarily of the definition of an XML 135 element known as the Signature element. This element consists of two 136 sub-elements. The first one is a set of authenticated attributes, 137 known as the signature Manifest, which comprises such things as a 138 unique reference to the resources being authenticated and an 139 indication of the keying material and algorithms being used. The 140 second sub-element consists of the digital signature value. 142 143 144 (resource information block) 145 (originator information block) 146 (recipient information block) 147 (other attributes) 148 (signature algorithms information block) 149 150 151 (encoded signature value) 152 153 155 The digital signature is not computed directly from the pieces of 156 information to be authenticated. Instead, the digital signature is 157 computed from a set of authenticated attributes (the Manifest), which 158 include references to, and a digests of, those pieces of information. 160 The authentication is therefore "indirect". 162 3.2 Digest Element 164 The Digest element consists of a unique and unambiguous reference to 165 the XML resources being authenticated. It is constructed of a locator 166 and the digest value data itself. The Digest algorithm is referred to 167 indirectly via a DigestAlgorithmRef, so that Digest algorithms may be 168 shared by multiple resources. 170 171 172 173 (digest information block) 174 175 176 The resource locator is implemented as a simple XML Link [XLink]. 177 This not only provides a unique addressing scheme for internal and 178 external resources, but also facilitates authentication of composite 179 documents. 181 3.3 Originator and Recipient Information Elements 183 The purpose of the Originator and Recipient information elements is 184 providing identification and keying material for these respective 185 parties. 187 188 (identification information block) 189 (keying material information block) 190 192 193 (identification information block) 194 (keying material information block) 195 197 The actual content of these two elements depends on the 198 authentication scheme being used and the existence or non-existence 199 of a prior relationship between the parties. In some circumstances, 200 it may be quite difficult to distinguish between identification and 201 keying material information. A unique reference to a digital 202 certificate provides for both. This may also stand true for an 203 account number when a prior relationship exists between the parties. 205 The Originator information element is mandatory. Depending on the 206 existence or non-existence of a prior relationship with the 207 recipient, this block either refers to a public credential such as a 208 digital certificate or displays a unique identifier known by the 209 recipient. 211 The Recipient information element may be used when a document 212 contains multiple signature information blocks, each being intended 213 for a particular recipient. A unique reference in the Recipient 214 information block helps the recipients identify their respective 215 Signature information block. 217 The Recipient information element may also be used when determination 218 of the authentication key consists of a combination of keying 219 material provided by both parties. This would be the case, for 220 example, when establishing a key by means of Diffie Hellman 221 [Schneier] Key Exchange algorithm. 223 The Algorithm element is a generalised place to place any type of 224 algorithm used within the signed IOTP message. The Algorithm may be a 225 Signature algorithm or a Digest algorithm. Each algorithm contains 226 parameters specific to the algorithm used. 228 229 (algorithm information block) 230 232 Algorithms are required to contain an ID which allows for indirect 233 reference to them from other places in the XML signature. 235 4. Detailed Signature Syntax 237 4.1 Uniform Resource Names 239 To prevent potential name conflicts in the definition of the numerous 240 type qualifiers considered herein, this specification uses Uniform 241 Resource Names [RFC 2141]. 243 4.2 IOTPSignatures 245 The IOTPSignatures element is the top-level element in an IOTP 246 signature block. It consists of a collection of Signature elements, 247 and an optional set of Certificates. 249 250 253 Content Description 255 Signature: A collection of Signature elements. 257 Certificate: Zero or more certificates used for signing 259 Attributes Description 261 ID: Element identifier that may be used to referencing the entire 262 Signature element from a Resource element when implementing 263 endorsement. 265 4.3 Signature Component 267 4.3.1 Signature 269 The Signature element constitutes the majority of this specification. 270 It is comprised of two sub-elements. The first one is a set of 271 attributes, known as the Manifest, which actually constitutes the 272 authenticated part of the document. The second sub-element consists 273 of the signature value or values. 275 276 279 Content Description 281 Manifest: A set of attributes that actually constitutes the 282 authenticated part of the document. 284 Value: One or more encodings of signature values. Multiple values 285 allow for a multiple algorithms to be supported within a single 286 signature block. 288 Attributes Description 290 ID: Element identifier that may be used to referencing the Signature 291 element from a Resource element when implementing endorsement. 293 4.3.2 Manifest 295 The Manifest element consists of a collection of attributes that 296 specify such things as as references to the resources being 297 authenticated and an indication of the keying material and algorithms 298 to be used. 300 310 Content Description 312 Algorithm: A list of algorithms used for signing, digest computation, 313 and canonicalization. 315 Digest: A list of digests of resources to be authentication and 316 signed. 318 Attributes: Optional element that consists of a collection of 319 complementary attributes to be authenticated. 321 OriginatorInfo: Element that provides identification and keying 322 material information related to the originator. 324 RecipientInfo: Optional element that provides identification and 325 keying material information related to the recipient. 327 Attributes Description 329 LocatorHrefBase: The LocatorHrefBase provides a similar construct to 330 the HTML HREFBASE attribute and implicitly sets all relative URL 331 references within the Manifest to be relative to the HrefBase. For 332 example, the IOTP Manifest may contain: 334 A2 530 531 532 533 534 A1 535 537 Content Description 539 ANY: The contents of a Parameter element consists of ANY valid 540 construct, which is specified on a per algorithm per parameter basis. 542 Attributes Description 543 type: The type of the parameter expressed as a free form string, 544 whose value is specified on a per algorithm basis. 546 4.4 Certificate Component 548 4.4.1 Certificate 550 The Certificate element may be used for either providing the value of 551 a digital certificate or specifying a location from where it may be 552 retrieved. 554 558 562 Content Description 564 IssuerAndSerialNumber: Unique identifier of this certificate. This 565 element has been made mandatory is order to prevent unnecessary 566 decoding during validation of a certificate chain. This feature also 567 helps certificates caching, especially when the value is not directly 568 provided. 570 Value: Encoding of the certificate value. The actual value to be 571 encoded depends upon the type of the certificate. 573 Locator: XML link element that could be used for retrieving a copy of 574 the digital certificate. The actual value being returned by means of 575 this locator depends upon the security protocol being used. 577 Attributes Description 579 type: Type of the digital certificate. This attribute is specified 580 as a Universal Resource Name, as indicated in the "Supported 581 Algorithms" section. 583 4.4.2 IssuerAndSerialNumber 585 The IssuerAndSerialNumber element identifies a certificate, and 586 thereby an entity and a public key, by the name of the certificate 587 issuer and an issuer-specific certificate identification. 589 590 594 Attributes Description 596 issuer: Name of the issuing certification authority. 598 number: Issuer-specific certificate identification. 600 4.5 Common Components 602 4.5.1 Value 604 A value contains the "raw" data of a signature or digest algorithm, 605 usually in a base-64 encoded form. See [RFC 2045] for algorithm used 606 to base-64 encode data. 608 612 Content Description 614 PCDATA: Content value after adequate encoding. 616 Attributes Description 618 encoding: This attribute specifies the decoding scheme to be 619 employed for recovering the original byte stream from the content of 620 the element. This document recognises the following two schemes: 622 none: the content has not been subject to any particular encoding. 623 This does not preclude however the use of native XML encoding such as 624 CDATA section or XML escaping. 626 base64: The content has been encoded by means of the base64 encoding 627 scheme. 629 4.5.2 Locator 631 The Locator element consists of simple XML link [XLink]. This 632 element allows unambiguous reference to a resource or fragment of a 633 resource. 635 636 640 Attributes Description 642 xml:link: Required XML link attribute that specifies the nature of 643 the link (simple in this case). 645 href: Locator value that may contains either a URI [RFC 2396], a 646 fragment identifier, or both. 648 5. Supported Algorithms 650 The IOTP specification 1.0 requires the implementation of the DOM- 651 HASH, SHA1, MD5, DSA, and HMAC algorithms to provide a compliant 652 implementation of IOTP 1.0. Implementation of RSA is also 653 recommended. 655 5.1 Digest Algorithms 657 This specification contemplates two types of digest algorithms, both 658 of which provide a digest string as a result: 660 Surface string digest algorithms 662 These algorithms do not have any particular knowledge about the 663 content being digested and operate on the raw content value. Changes 664 in the surface string of a given content affect directly the value of 665 the digest being produced. 667 Canonical digest algorithms 669 These algorithms have been tailored for a particular content type and 670 produce a digest value that depends upon the core semantics of such 671 content. Changes limited to the surface string of a given content do 672 not affect the value of the digest being produced. 674 5.1.1 DOM-HASH 676 XML canonical digest algorithm proposed by IBM Tokyo Research 677 Laboratory. This algorithm operates on the DOM representation of the 678 document and provides an unambiguous means for recursive computation 679 of the hash value of the nodes that constitute the DOM tree. 681 The DOM-HASH algorithm requires a single parameter, which shall 682 consist of a surface string digest algorithm such as SHA1. 684 The DOM-HASH URN used for this specification is "urn:ibm:dom-hash". 686 Example 687 688 690 5.1.2 SHA1 692 Surface string digest algorithm designed by hte US government for use 693 with the Digital Signature Standard. This algorithm produces a 160- 694 bit hash value. 696 This algorithm does not require any parameter. 698 The SHA1 URN used for this specification is "urn:fips:sha1". 700 5.1.3 MD5 702 The MD5 Algorithm was invented by RSA Data Securities and is similar 703 to its predecessors, MD2 and MD4, but faster and simpler than MD2 704 while stronger than MD4. [RFC 1321] 706 The MD5 Algorithm takes no parameters. 708 The MD5 URN used for this specification is "urn:rsa:md5". 710 5.2 Signature Algorithms 712 This specification uses the terminology of 'digital signature' for 713 qualifying indifferently digital signature and message authentication 714 codes. Thus, the signature algorithms contemplated herein include 715 public key digital signature algorithms such as DSA and message 716 authentication codes such as HMAC [RFC 2104]. 718 5.2.1 DSA 720 TODO 722 The DSA URN used in this specification is "urn:fips:dsa". 724 5.2.2 HMAC 726 Generalities [RFC 2104] TODO 728 The HMAC URN used in this specification is is "urn:ibm:hmac". 730 5.2.3 RSA 732 TODO 734 The RSA URN used in this specification is "urn:rsa:rsa". 736 6. Examples 738 The following is an example signed IOTP message: 740 741 742 748 749 750 751 752 753 759 760 761 762 763 764 765 766 767 768 769 770 771 S.1 772 773 774 S.1 775 776 777 778 779 xsqsfasDys2h44u4ehJDe54he5j4dJYTJ= 780 781 782 783 784 785 ked0Ks01k2d7a0kgmf9dk19lf63kkDSs0= 786 787 788 790 791 795 796 797 798 9dj28fjakA9sked0Ks01k2d7a0kgmf9dk19lf63kkDSs0= 799 800 801 803 805 7. Signature DTD 807 813 814 817 823 824 827 838 839 844 845 848 850 851 856 857 861 862 869 870 874 879 883 887 888 892 897 898 903 904 908 8. References 910 [RFC 1321] - R. Rivest, "The MD5 Message-Digest Algorithm", April 911 1992. 913 [RFC 2045]- N. Freed & N. Borenstein, "Multipurpose Internet Mail 914 Extensions (MIME) Part One: Format of Internet Message Bodies", 915 November 1996. 917 [RFC 2046] - N. Freed & N. Borenstein, "Multipurpose Internet Mail 918 Extensions (MIME) Part Two: Media Types", November 1996. 920 [RFC 2104] - H. Krawczyk, M. Bellare, R. Canetti, "HMAC: Keyed- 921 Hashing for Message Authentication", February 1997. 923 [RFC 2141] - R. Moats, "URN Syntax", May 1997. 925 [RFC 2396] - T. Berners-Lee, R. Fielding, L. Masinter, "Uniform 926 Resource Identifiers (URI): Generic Syntax", August 1998. 928 [Schneier] - Bruce Schneier, "Applied Cryptography: Protocols, 929 Algorithms, and Source Code in C", 1996, John Wiley and Sons 931 [XLink] - Eve Maler, Steve DeRose, "XML Linking Language (XLink)", 932 934 [XML] - Tim Bray, Jean Paoli, C. M. Sperber-McQueen, "Extensible 935 Markup Language (XML) 1.0", 938 9. Credits 940 This document is based on work originally done on general XML digital 941 signatures by Richard Brown at GlobeSet, Inc. 942 but has been narrowed and changed. 944 The editor of this document is: 946 Kent M. Davidson 947 Differential, Inc. 948 10054 Pasadena Ave. 949 Cupertino, CA 95014 USA 951 email: kent@differential.com 953 Contributors to the design of the IOTP DTD include, in alphabetic 954 order: 956 David Burdett, Mondex 958 Andrew Drapp, Hitachi 960 Donald Eastlake 3rd, IBM 962 Yoshiaki Kawatsura, Hitachi 964 Expiration and File Name 966 This draft expires August 1999. 968 Its file name is draft-ietf-trade-iotp-v1.0-dsig-00.txt.