idnits 2.17.1 draft-ietf-trade-iotp-v1.0-dsig-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: ---------------------------------------------------------------------------- ** 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? ** Bad filename characters: the document name given in the document, 'draft-ietf-trade-iotp-v1.0-dsig-01.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-01.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-01.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-01.txt,', but the file name used is 'draft-ietf-trade-iotp-v1.0-dsig-01' == 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 496: '...ate reference ID MUST point to a certi...' RFC 2119 keyword, line 516: '...thm reference ID MUST point to a signa...' RFC 2119 keyword, line 520: '...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 (August 1999) is 9014 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 629, but not defined == Unused Reference: 'RFC 2046' is defined on line 951, 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: 12 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 Yoshiai Kawatsura 4 Hitachi 5 Expires: February 2000 August 1999 7 Digital Signatures for the Internet Open Trading Protocol (IOTP) 8 ------- ---------- --- --- -------- ---- ------- -------- ------ 10 Status of This Document 12 This draft, file name draft-ietf-trade-iotp-v1.0-dsig-01.txt, is a 13 part of the Internet Open Trading Protocol Specification version 1.0, 14 and is intended to become an Informational RFC. Distribution of this 15 document is unlimited. Comments should be sent to the TRADE working 16 group mailing list . 18 This document is an Internet-Draft and is in full conformance with 19 all provisions of Section 10 of RFC2026. Internet-Drafts are working 20 documents of the Internet Engineering Task Force (IETF), its areas, 21 and its working groups. Note that other groups may also distribute 22 working documents as Internet-Drafts. 24 Internet-Drafts are draft documents valid for a maximum of six 25 months. Internet-Drafts may be updated, replaced, or obsoleted by 26 other documents at any time. It is not appropriate to use Internet- 27 Drafts as reference material or to cite them other than as a 28 ``working draft'' or ``work in progress.'' 30 The list of current Internet-Drafts can be accessed at 31 http://www.ietf.org/ietf/1id-abstracts.txt 33 The list of Internet-Draft Shadow Directories can be accessed at 34 http://www.ietf.org/shadow.html. 36 Abstract 38 A syntax and procedures are described for the computation and 39 verification of digital signatures for use within Version 1.0 of the 40 Internet Open Trading Protocol (IOTP). 42 Table of Contents 44 Status of This Document....................................1 45 Abstract...................................................1 47 Table of Contents..........................................2 49 1. Introduction............................................3 50 2. Objective and Requirements..............................3 52 3. Signature Basics........................................4 53 3.1 Signature Element......................................4 54 3.2 Digest Element.........................................4 55 3.3 Originator and Recipient Information Elements..........5 56 3.4 Algorithm Element......................................6 57 4. Detailed Signature Syntax...............................6 58 4.1 Uniform Resource Names.................................6 59 4.2 IOTPSignatures.........................................6 60 4.3 Signature Component....................................7 61 4.3.1 Signature............................................7 62 4.3.2 Manifest.............................................8 63 4.3.3 Algorithm............................................9 64 4.3.4 Digest...............................................9 65 4.3.5 Attribute...........................................10 66 4.3.6 OriginatorInfo......................................11 67 4.3.7 RecipientInfo.......................................11 68 4.3.8 Parameter...........................................12 69 4.4 Certificate Component.................................13 70 4.4.1 Certificate.........................................13 71 4.4.2 IssuerAndSerialNumber...............................14 72 4.5 Common Components.....................................14 73 4.5.1 Value...............................................14 74 4.5.2 Locator.............................................15 75 5. Supported Algorithms...................................15 76 5.1 Digest Algorithms.....................................16 77 5.1.1 DOM-HASH............................................16 78 5.1.2 SHA1................................................16 79 5.1.3 MD5.................................................17 80 5.2 Signature Algorithms..................................17 81 5.2.1 DSA.................................................17 82 5.2.2 HMAC................................................17 83 5.2.3 RSA.................................................17 84 6. Examples...............................................17 85 7. Signature DTD..........................................19 87 8. Security Considerations................................22 88 9. References.............................................22 90 9. Author's Addresses.....................................23 91 Expiration and File Name..................................23 93 1. Introduction 95 The Internet Open Trading Protocol (IOTP) provides a payment system 96 independent interoperable framework for Internet commerce as 97 documented in [RFC xxx, draft-ietf-trade-iotp-v1.0-protocol-*.txt]. 98 All IOTP messages are XML documents. XML, the Extensible Markup 99 Language [XML], is a syntactical standard promulgated by the World 100 Wide Web Consortium. XML is intended primarily for structuring data 101 exchanged and served over the World Wide Web. 103 Although IOTP assumes that any payment system used with it provides 104 its own security, there are numerous cases where IOTP requires 105 authentication and integrity services for portions of the XML 106 messages it specifies. 108 2. Objective and Requirements 110 This document covers how digital signatures may be used with XML 111 documents to provide authentication and tamper-proof protocol 112 messages specifically for Version 1.0 of the IOTP protocol. The 113 reader should recognize that an effort towards general XML digital 114 signatures exists but is unlikely to produce its final result in time 115 for IOTP Version 1.0. Future versions of IOTP will probably just 116 adopt by reference the results of this general XML digital signature 117 effort. 119 The objective of this document is to propose syntax and procedures 120 for the computation and verification of digital signatures applicable 121 to Version 1.0 IOTP protocol messages, providing for: 123 -- Authentication of IOTP transactions 124 -- Provide a means by which an IOTP message may be made "tamper- 125 proof", or detection of tampering is made evident 126 -- Describe a set of available digest and signature algorithms at 127 least one of which is mandatory to implement for interoperability 128 -- Easily integrate within the IOTP 1.0 Specification 129 -- Provide lightweight signatures with minimal redundancy 130 -- Allow a signed portions of IOTP message to be "forwarded" to 131 another trading roles with different signature algorithms than the 132 original recipient 134 3. Signature Basics 136 3.1 Signature Element 138 This specification consists primarily of the definition of an XML 139 element known as the Signature element. This element consists of two 140 sub-elements. The first one is a set of authenticated attributes, 141 known as the signature Manifest, which comprises such things as a 142 unique reference to the resources being authenticated and an 143 indication of the keying material and algorithms being used. The 144 second sub-element consists of the digital signature value. 146 147 148 (resource information block) 149 (originator information block) 150 (recipient information block) 151 (other attributes) 152 (signature algorithms information block) 153 154 155 (encoded signature value) 156 157 159 The digital signature is not computed directly from the pieces of 160 information to be authenticated. Instead, the digital signature is 161 computed from a set of authenticated attributes (the Manifest), which 162 include references to, and a digests of, those pieces of information. 164 The authentication is therefore "indirect". 166 3.2 Digest Element 168 The Digest element consists of a unique and unambiguous reference to 169 the XML resources being authenticated. It is constructed of a locator 170 and the digest value data itself. The Digest algorithm is referred to 171 indirectly via a DigestAlgorithmRef, so that Digest algorithms may be 172 shared by multiple resources. 174 175 176 177 (Digest value) 178 179 180 The resource locator is implemented as a simple XML Link [XLink]. 181 This not only provides a unique addressing scheme for internal and 182 external resources, but also facilitates authentication of composite 183 documents. 185 3.3 Originator and Recipient Information Elements 187 The purpose of the Originator and Recipient information elements is 188 providing identification and keying material for these respective 189 parties. 191 192 (identification information block) 193 (keying material information block) 194 196 197 (identification information block) 198 (keying material information block) 199 201 The actual content of these two elements depends on the 202 authentication scheme being used and the existence or non-existence 203 of a prior relationship between the parties. In some circumstances, 204 it may be quite difficult to distinguish between identification and 205 keying material information. A unique reference to a digital 206 certificate provides for both. This may also stand true for an 207 account number when a prior relationship exists between the parties. 209 The Originator information element is mandatory. Depending on the 210 existence or non-existence of a prior relationship with the 211 recipient, this block either refers to a public credential such as a 212 digital certificate or displays a unique identifier known by the 213 recipient. 215 The Recipient information element may be used when a document 216 contains multiple signature information blocks, each being intended 217 for a particular recipient. A unique reference in the Recipient 218 information block helps the recipients identify their respective 219 Signature information block. 221 The Recipient information element may also be used when determination 222 of the authentication key consists of a combination of keying 223 material provided by both parties. This would be the case, for 224 example, when establishing a key by means of Diffie Hellman 225 [Schneier] Key Exchange algorithm. 227 3.4 Algorithm Element 229 The Algorithm element is a generalised place to place any type of 230 algorithm used within the signed IOTP message. The Algorithm may be a 231 Signature algorithm or a Digest algorithm. Each algorithm contains 232 parameters specific to the algorithm used. 234 235 (algorithm information block) 236 238 Algorithms are required to contain an ID which allows for indirect 239 reference to them from other places in the XML signature. 241 4. Detailed Signature Syntax 243 4.1 Uniform Resource Names 245 To prevent potential name conflicts in the definition of the numerous 246 type qualifiers considered herein, this specification uses Uniform 247 Resource Names [RFC 2141]. 249 4.2 IOTPSignatures 251 The IOTPSignatures element is the top-level element in an IOTP 252 signature block. It consists of a collection of Signature elements, 253 and an optional set of Certificates. 255 256 259 Content Description 261 Signature: A collection of Signature elements. 263 Certificate: Zero or more certificates used for signing 265 Attributes Description 267 ID: Element identifier that may be used to referencing the entire 268 Signature element from a Resource element when implementing 269 endorsement. 271 4.3 Signature Component 273 4.3.1 Signature 275 The Signature element constitutes the majority of this specification. 276 It is comprised of two sub-elements. The first one is a set of 277 attributes, known as the Manifest, which actually constitutes the 278 authenticated part of the document. The second sub-element consists 279 of the signature value or values. 281 The Value element contained within the Signature element is the 282 encoded form of the signature of the Manifest element, and thus 283 provides the verification of the Manifest. 285 The process for generating the signed value is a multi-step process, 286 involving a canonicalization algorithm, a digest algorithm, and a 287 signature algorithm. 289 First, the Manifest is canonicalized with an algorithm specified 290 within the Algorithm element of the Manifest. The canonicalized form 291 removes any inconsistencies in white space introduced by XML parsing 292 engines. 294 This canonicalized form is then converted into a digest form which 295 uniquely identifies the canoicalized document. Any slight 296 modification in the original document will result in a very different 297 digest value. 299 Finally, the digest is then signed using a public-key algorithm which 300 digitally stamps the digest with the certificate of the signer. The 301 final signed digest is the value which is stored within the 302 Signature's Value element. 304 305 308 Content Description 310 Manifest: A set of attributes that actually constitutes the 311 authenticated part of the document. 313 Value: One or more encodings of signature values. Multiple values 314 allow for a multiple algorithms to be supported within a single 315 signature block. 317 Attributes Description 318 ID: Element identifier that may be used to referencing the Signature 319 element from a Resource element when implementing endorsement. 321 4.3.2 Manifest 323 The Manifest element consists of a collection of attributes that 324 specify such things as as references to the resources being 325 authenticated and an indication of the keying material and algorithms 326 to be used. 328 339 Content Description 341 Algorithm: A list of algorithms used for signing, digest computation, 342 and canonicalization. 344 Digest: A list of digests of resources to be authentication and 345 signed. 347 Attribute: Optional element that consists of a collection of 348 complementary attributes to be authenticated. 350 OriginatorInfo: Element that provides identification and keying 351 material information related to the originator. 353 RecipientInfo: Optional element that provides identification and 354 keying material information related to the recipient. 356 Attributes Description 358 LocatorHrefBase: The LocatorHrefBase provides a similar construct to 359 the HTML HREFBASE attribute and implicitly sets all relative URL 360 references within the Manifest to be relative to the HrefBase. For 361 example, the IOTP Manifest may contain: 363 366 And subsequent Locators may be: 368 370 An implementation should concatenate the two locator references to 371 create the entire URL. 373 4.3.3 Algorithm 375 This specification uses an Algorithm data type which indicates many 376 different types of algoirithms. The Algorithm element allows for 377 specification of sub-algorithms as parameters of the primary 378 algorithm. This is performed via a parameter within the algorithm 379 that provides a reference to another Algorithm. An example of this is 380 shown in the Parameter section. 382 383 388 Content Description 390 Parameter: The contents of an Algorithm element consists of an 391 optional collection of Parameter elements which are specified on a 392 per algorithm basis. 394 Attributes Description 396 id: The ID of the algorithm is used by the Digest and RecipientInfo 397 to refer to the signing or digest algorithm used. 399 type: The type of algorithm, either a digest or signature. This is 400 implied by the element to which the algorithm is referred. That is, 401 if the DigestAlgorithmRef refers to an algorithm, it is implicit by 402 reference that the targetted algorithm is a digest. 404 name: The type of the algorithm expressed as a Uniform Resource 405 Name. 407 4.3.4 Digest 409 The Digest element consists of the fingerprint of a given resource. 410 This element is constructed of two sub-elements. This first one 411 indicates the algorithm to be used for computation of the 412 fingerprint. The second element consists of the fingerprint value. 414 415 419 Content Description 421 Locator: Contains a "HREF" or URL locator for the resource to be 422 fingerprinted. References to IOTP messages. 424 Value: Encoding of the fingerprint value. 426 Attributes Description 428 DigestAlgorithmRef: ID Reference of algorithm used for computation of 429 the digest. 431 4.3.5 Attribute 433 The Attribute element consists of a complementary piece of 434 information, which shall be included in the authenticated part of the 435 document. This element has been defined primarily for enabling some 436 level of customization in the signature element. This is the area 437 where a specific IOTP implementation may include custom attributes 438 which must be authenticated directly. An Attribute element consists 439 of a value, a type, and a criticality. 441 At this time, no IOTP specific attributes are specified. 443 444 449 Content Description 451 ANY: The actual value of an attribute depends solely upon its type. 453 Attributes Description 455 type: Type of the attribute. 457 critical: Boolean value that indicates if the attribute is critical 458 (true) or not (false). A recipient shall reject a signature that 459 contains a critical attribute that he does not recognise. However, an 460 unrecognised non-critical attribute may be ignored. 462 4.3.6 OriginatorInfo 464 The OriginatorInfo element is used for providing identification and 465 keying material information for the originator. 467 468 472 Content Description 474 ANY: Identification and keying material information may consist of 475 ANY construct. Such a definition allows the adoption of 476 application-specific schemes. 478 Attributes Description 480 OriginatorRef: A reference to the IOTP Org ID of the originating 481 signer. 483 4.3.7 RecipientInfo 485 The RecipientInfo element is used for providing identification and 486 keying material information for the recipient. This element is used 487 either for enabling recognition of a Signature element by a given 488 recipient or when determination of the authentication key consists of 489 the combination of keying material provided by both the recipient and 490 the originator. 492 The RecipientInfo attributes provide a centralized location where 493 signatures, algorithms, and certificates intended for a particular 494 recipient are specified. 496 The signature certificate reference ID MUST point to a certificate 497 object. 499 500 507 Content Description 509 ANY: Identification and keying material information may consist of 510 ANY construct. 512 Attributes Description 514 SignatureAlgorithmRef: A reference to the signature algorithm used to 515 sign the SignatureValueRef intended for this recipient. The signature 516 algorithm reference ID MUST point to a signature algorithm within the 517 Manifest. 519 SignatureValueRef: A reference to the signature value for this 520 recipient. The signature value reference ID MUST point to a value 521 structure directly included within a Manifest. This reference can be 522 omitted if the application can specify the digest value. 524 SignatureCertRef: A reference to the certificate used to sign the 525 Value pointed to by the SignatureValueRef. This reference can be 526 omitted if the application can identify the certificate. 528 RecipientRefs: A list of references to the IOTP Org ID of the 529 recipients this signature is intended for. 531 4.3.8 Parameter 533 A Parameter element provides the value of a particular algorithm 534 parameter, whose name and format have been specified for the 535 algorithm considered. 537 538 542 For IOTP 1.0, the following parameter type is standardized: 543 "AlgorithmRef". 545 An AlgorithmRef contains an ID of a "sub-Algorithm" used when 546 computing a sequence of algorithms. For example, a signature 547 algorithm actually signs a digest algorithm. To specify a chain of 548 algorithms used to compute a signature, AlgorithmRef parameter types 549 are used in the following manner: 551 552 A2 553 554 555 556 557 A1 558 560 Content Description 562 ANY: The contents of a Parameter element consists of ANY valid 563 construct, which is specified on a per algorithm per parameter basis. 565 Attributes Description 567 type: The type of the parameter expressed as a free form string, 568 whose value is specified on a per algorithm basis. 570 4.4 Certificate Component 572 4.4.1 Certificate 574 The Certificate element may be used for either providing the value of 575 a digital certificate or specifying a location from where it may be 576 retrieved. 578 582 586 Content Description 588 IssuerAndSerialNumber: Unique identifier of this certificate. This 589 element has been made mandatory is order to prevent unnecessary 590 decoding during validation of a certificate chain. This feature also 591 helps certificates caching, especially when the value is not directly 592 provided. 594 Value: Encoding of the certificate value. The actual value to be 595 encoded depends upon the type of the certificate. 597 Locator: XML link element that could be used for retrieving a copy of 598 the digital certificate. The actual value being returned by means of 599 this locator depends upon the security protocol being used. 601 Attributes Description 603 type: Type of the digital certificate. This attribute is specified 604 as a Universal Resource Name, as indicated in the "Supported 605 Algorithms" section. 607 4.4.2 IssuerAndSerialNumber 609 The IssuerAndSerialNumber element identifies a certificate, and 610 thereby an entity and a public key, by the name of the certificate 611 issuer and an issuer-specific certificate identification. 613 614 618 Attributes Description 620 issuer: Name of the issuing certification authority. 622 number: Issuer-specific certificate identification. 624 4.5 Common Components 626 4.5.1 Value 628 A value contains the "raw" data of a signature or digest algorithm, 629 usually in a base-64 encoded form. See [RFC 2045] for algorithm used 630 to base-64 encode data. 632 633 639 Content Description 641 PCDATA: Content value after adequate encoding. 643 Attributes Description 645 encoding: This attribute specifies the decoding scheme to be 646 employed for recovering the original byte stream from the content of 647 the element. This document recognises the following two schemes: 649 none: the content has not been subject to any particular encoding. 650 This does not preclude however the use of native XML encoding such as 651 CDATA section or XML escaping. 653 base64: The content has been encoded by means of the base64 encoding 654 scheme. 656 4.5.2 Locator 658 The Locator element consists of simple XML link [XLink]. This 659 element allows unambiguous reference to a resource or fragment of a 660 resource. 662 663 667 Attributes Description 669 xml:link: Required XML link attribute that specifies the nature of 670 the link (simple in this case). 672 href: Locator value that may contains either a URI [RFC 2396], a 673 fragment identifier, or both. 675 5. Supported Algorithms 677 The IOTP specification 1.0 requires the implementation of the DOM- 678 HASH, SHA1, MD5, DSA, and HMAC algorithms to provide a compliant 679 implementation of IOTP 1.0. Implementation of RSA is also 680 recommended. 682 5.1 Digest Algorithms 684 This specification contemplates two types of digest algorithms, both 685 of which provide a digest string as a result: 687 Surface string digest algorithms 689 These algorithms do not have any particular knowledge about the 690 content being digested and operate on the raw content value. Changes 691 in the surface string of a given content affect directly the value of 692 the digest being produced. 694 Canonical digest algorithms 696 These algorithms have been tailored for a particular content type and 697 produce a digest value that depends upon the core semantics of such 698 content. Changes limited to the surface string of a given content do 699 not affect the value of the digest being produced. 701 5.1.1 DOM-HASH 703 XML canonical digest algorithm proposed by IBM Tokyo Research 704 Laboratory. This algorithm operates on the DOM representation of the 705 document and provides an unambiguous means for recursive computation 706 of the hash value of the nodes that constitute the DOM tree. 708 The DOM-HASH algorithm requires a single parameter, which shall 709 consist of a surface string digest algorithm such as SHA1. 711 The DOM-HASH URN used for this specification is "urn:ibm:dom-hash". 713 Example 714 715 717 5.1.2 SHA1 719 Surface string digest algorithm designed by the US government for use 720 with the Digital Signature Standard. This algorithm produces a 160- 721 bit hash value. 723 This algorithm does not require any parameter. 725 The SHA1 URN used for this specification is "urn:fips:sha1". 727 5.1.3 MD5 729 The MD5 Algorithm was invented by RSA Data Securities and is similar 730 to its predecessors, MD2 and MD4, but faster and simpler than MD2 731 while stronger than MD4. [RFC 1321] 733 The MD5 Algorithm takes no parameters. 735 The MD5 URN used for this specification is "urn:rsa:md5". 737 5.2 Signature Algorithms 739 This specification uses the terminology of 'digital signature' for 740 qualifying indifferently digital signature and message authentication 741 codes. Thus, the signature algorithms contemplated herein include 742 public key digital signature algorithms such as DSA and message 743 authentication codes such as HMAC [RFC 2104]. 745 5.2.1 DSA 747 The DSA URN used in this specification is "urn:fips:dsa". 749 5.2.2 HMAC 751 See [RFC 2104] 753 The HMAC URN used in this specification is is "urn:ibm:hmac". 755 5.2.3 RSA 757 The RSA URN used in this specification is "urn:rsa:rsa". 759 6. Examples 761 The following is an example signed IOTP message: 763 764 765 771 772 773 774 775 776 777 778 779 780 781 P.5 782 783 784 P.3 785 786 787 788 789 xsqsfasDys2h44u4ehJDe54he5j4dJYTJ 790 791 792 796 797 800 801 802 9dj28fjakA9sked0Ks01k2d7a0kgmf9dk19lf63kkDSs0 803 804 805 806 809 810 xsqsfasDys2h44u4ehJDe54he5j4dJYTJ= 811 812 813 814 815 819 820 snroasdfnas934k 821 822 823 824 826 7. Signature DTD 828 834 835 839 845 846 850 859 862 863 869 870 874 875 880 881 885 886 893 894 898 904 908 912 913 918 923 924 929 930 935 8. Security Considerations 937 This entire document concerns the IOTP v1 protocol signature element 938 which is used for authentication. See the Security Considerations 939 section of [RFC xxxx] "Interenet Open Trading Protocol - IOTP, 940 Version 1.0". 942 9. References 944 [RFC 1321] - R. Rivest, "The MD5 Message-Digest Algorithm", April 945 1992. 947 [RFC 2045]- N. Freed & N. Borenstein, "Multipurpose Internet Mail 948 Extensions (MIME) Part One: Format of Internet Message Bodies", 949 November 1996. 951 [RFC 2046] - N. Freed & N. Borenstein, "Multipurpose Internet Mail 952 Extensions (MIME) Part Two: Media Types", November 1996. 954 [RFC 2104] - H. Krawczyk, M. Bellare, R. Canetti, "HMAC: Keyed- 955 Hashing for Message Authentication", February 1997. 957 [RFC 2141] - R. Moats, "URN Syntax", May 1997. 959 [RFC 2396] - T. Berners-Lee, R. Fielding, L. Masinter, "Uniform 960 Resource Identifiers (URI): Generic Syntax", August 1998. 962 [RFC xxxx] - D. Burdett, "Interenet Open Trading Protocol - IOTP, 963 Version 1.0", August 1999. (currently draft-ietf-trade-iotp-v1.0- 964 protcool-*.txt) 966 [Schneier] - Bruce Schneier, "Applied Cryptography: Protocols, 967 Algorithms, and Source Code in C", 1996, John Wiley and Sons 969 [XLink] - Eve Maler, Steve DeRose, "XML Linking Language (XLink)", 970 972 [XML] - Tim Bray, Jean Paoli, C. M. Sperber-McQueen, "Extensible 973 Markup Language (XML) 1.0", 976 9. Author's Addresses 978 This document is based on work originally done on general XML digital 979 signatures by Richard Brown at GlobeSet, Inc. 980 but has been narrowed and changed. 982 The authors of this document are: 984 Kent M. Davidson 985 Differential, Inc. 986 440 Clyde Ave. 987 Mountain View, CA 94043 USA 988 email: kent@differential.com 990 Yoshiaki Kawatsura 991 Hitachi, Ltd. 992 890 Kashimada Saiwai Kawasaki, 993 Kanagawa 2118567 Japan 994 email: kawatura@bisd.hitachi.co.jp 996 Contributors to the design of the IOTP DTD include, in alphabetic 997 order: 999 David Burdett, Mondex 1001 Andrew Drapp, Hitachi 1003 Donald Eastlake 3rd, IBM 1005 Expiration and File Name 1007 This draft expires February 2000. 1009 Its file name is draft-ietf-trade-iotp-v1.0-dsig-01.txt.