idnits 2.17.1 draft-ietf-trade-iotp-v1.0-dsig-03.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-03', contains other characters than digits, lowercase letters and dash. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 1) being 64 lines 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. ** There is 1 instance of too long lines in the document, the longest one being 4 characters in excess of 72. ** 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 525: '...ate reference ID MUST point to a certi...' RFC 2119 keyword, line 545: '...thm reference ID MUST point to a signa...' RFC 2119 keyword, line 549: '...lue reference ID MUST point to a value...' Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == 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 (September 1999) is 8982 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 675, but not defined == Missing Reference: 'DSS' is mentioned on line 802, but not defined == Unused Reference: 'DSA' is defined on line 1195, but no explicit reference was found in the text == Unused Reference: 'RFC 1321' is defined on line 1206, but no explicit reference was found in the text == Unused Reference: 'RFC 2046' is defined on line 1213, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. 'DSA' -- Possible downref: Non-RFC (?) normative reference: ref. 'IEEE P1363' -- Possible downref: Non-RFC (?) normative reference: ref. 'PV' ** 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) ** Obsolete normative reference: RFC 2437 (Obsoleted by RFC 3447) -- Possible downref: Non-RFC (?) normative reference: ref. 'Schneier' -- Possible downref: Non-RFC (?) normative reference: ref. 'SHA1' -- Possible downref: Non-RFC (?) normative reference: ref. 'XLink' -- Possible downref: Non-RFC (?) normative reference: ref. 'XML' Summary: 13 errors (**), 0 flaws (~~), 9 warnings (==), 8 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 Yoshiaki Kawatsura 4 Hitachi 5 Expires: March 2000 September 1999 6 draft-ietf-trade-iotp-v1.0-dsig-03.txt 8 Digital Signatures for the v1.0 Internet Open Trading Protocol (IOTP) 9 ------- ---------- --- --- ---- -------- ---- ------- -------- ------ 11 Status of This Document 13 This draft, file name draft-ietf-trade-iotp-v1.0-dsig-03.txt, is a 14 part of the Internet Open Trading Protocol Specification version 1.0, 15 and is intended to become an Informational RFC. Distribution of this 16 document is unlimited. Comments should be sent to the TRADE working 17 group mailing list . 19 This document is an Internet-Draft and is in full conformance with 20 all provisions of Section 10 of RFC2026. Internet-Drafts are working 21 documents of the Internet Engineering Task Force (IETF), its areas, 22 and its working groups. Note that other groups may also distribute 23 working documents as Internet-Drafts. 25 Internet-Drafts are draft documents valid for a maximum of six 26 months. Internet-Drafts may be updated, replaced, or obsoleted by 27 other documents at any time. It is not appropriate to use Internet- 28 Drafts as reference material or to cite them other than as a 29 ``working draft'' or ``work in progress.'' 31 The list of current Internet-Drafts can be accessed at 32 http://www.ietf.org/ietf/1id-abstracts.txt 34 The list of Internet-Draft Shadow Directories can be accessed at 35 http://www.ietf.org/shadow.html. 37 To view the entire list of current Internet-Drafts, please check the 38 "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow 39 Directories as listed at . 41 Abstract 43 A syntax and procedures are described for the computation and 44 verification of digital signatures for use within Version 1.0 of the 45 Internet Open Trading Protocol (IOTP). 47 Copyright 49 Copyright (C) 1999. The Internet Society. All Rights Reserved. 51 Table of Contents 53 Status of This Document....................................1 54 Abstract...................................................1 55 Copyright..................................................1 57 Table of Contents..........................................2 59 1. Introduction............................................4 61 2. Objective and Requirements..............................5 63 3. Signature Basics........................................6 64 3.1 Signature Element......................................6 65 3.2 Digest Element.........................................6 66 3.3 Originator and Recipient Information Elements..........7 67 3.4 Algorithm Element......................................8 68 4. Detailed Signature Syntax...............................8 69 4.1 Uniform Resource Names.................................8 70 4.2 IotpSignatures.........................................8 71 4.3 Signature Component....................................9 72 4.3.1 Signature............................................9 73 4.3.2 Manifest............................................10 74 4.3.3 Algorithm...........................................11 75 4.3.4 Digest..............................................11 76 4.3.5 Attribute...........................................12 77 4.3.6 OriginatorInfo......................................13 78 4.3.7 RecipientInfo.......................................13 79 4.3.8 KeyIdentifier.......................................14 80 4.3.9 Parameter...........................................15 81 4.4 Certificate Component.................................16 82 4.4.1 Certificate.........................................16 83 4.4.2 IssuerAndSerialNumber...............................17 84 4.5 Common Components.....................................17 85 4.5.1 Value...............................................17 86 4.5.2 Locator.............................................18 87 5. Supported Algorithms...................................18 88 5.1 Digest Algorithms.....................................18 89 5.1.1 SHA1................................................19 90 5.1.2 DOM-HASH............................................19 91 5.2 Signature Algorithms..................................20 92 5.2.1 DSA.................................................20 93 5.2.2 HMAC................................................21 94 5.2.3 RSA.................................................22 95 5.2.4 ECDSA...............................................23 96 6. Examples...............................................24 97 7. Signature DTD..........................................25 99 8. Security Considerations................................28 100 Full Copyright Statement..................................28 101 References................................................29 103 Author's Addresses........................................31 104 Expiration and File Name..................................31 106 1. Introduction 108 The Internet Open Trading Protocol (IOTP) provides a payment system 109 independent interoperable framework for Internet commerce as 110 documented in [RFC xxx1]. All IOTP messages are XML documents. XML, 111 the Extensible Markup Language [XML], is a syntactical standard 112 promulgated by the World Wide Web Consortium. XML is intended 113 primarily for structuring data exchanged and served over the World 114 Wide Web. 116 Although IOTP assumes that any payment system used with it provides 117 its own security, there are numerous cases where IOTP requires 118 authentication and integrity services for portions of the XML 119 messages it specifies. 121 2. Objective and Requirements 123 This document covers how digital signatures may be used with XML 124 documents to provide authentication and tamper-proof protocol 125 messages specifically for Version 1.0 of the IOTP protocol. The 126 reader should recognize that an effort towards general XML digital 127 signatures exists but is unlikely to produce its final result in time 128 for IOTP Version 1.0. Future versions of IOTP will probably adopt by 129 reference the results of this general XML digital signature effort. 131 The objective of this document is to propose syntax and procedures 132 for the computation and verification of digital signatures applicable 133 to Version 1.0 IOTP protocol messages, providing for: 135 -- Authentication of IOTP transactions 136 -- Provide a means by which an IOTP message may be made "tamper- 137 proof", or detection of tampering is made evident 138 -- Describe a set of available digest and signature algorithms at 139 least one of which is mandatory to implement for interoperability 140 -- Easily integrate within the IOTP 1.0 Specification 141 -- Provide lightweight signatures with minimal redundancy 142 -- Allow signed portions of IOTP message to be "forwarded" to another 143 trading roles with different signature algorithms than the 144 original recipient 146 3. Signature Basics 148 3.1 Signature Element 150 This specification consists primarily of the definition of an XML 151 element known as the Signature element. This element consists of two 152 sub-elements. The first one is a set of authenticated attributes, 153 known as the signature Manifest, which comprises such things as a 154 unique reference to the resources being authenticated and an 155 indication of the keying material and algorithms being used. The 156 second sub-element consists of the digital signature value. 158 159 160 (resource information block) 161 (originator information block) 162 (recipient information block) 163 (other attributes) 164 (signature algorithms information block) 165 166 167 (encoded signature value) 168 169 171 The digital signature is not computed directly from the pieces of 172 information to be authenticated. Instead, the digital signature is 173 computed from a set of authenticated attributes (the Manifest), which 174 include references to, and a digests of, those pieces of information. 176 The authentication is therefore "indirect". 178 3.2 Digest Element 180 The Digest element consists of a unique and unambiguous reference to 181 the XML resources being authenticated. It is constructed of a locator 182 and the digest value data itself. The Digest algorithm is referred to 183 indirectly via a DigestAlgorithmRef, so that Digest algorithms may be 184 shared by multiple resources. 186 187 188 189 (Digest value) 190 191 192 The resource locator is implemented as a simple XML Link [XLink]. 193 This not only provides a unique addressing scheme for internal and 194 external resources, but also facilitates authentication of composite 195 documents. 197 3.3 Originator and Recipient Information Elements 199 The purpose of the Originator and Recipient information elements is 200 to provide identification and keying material for these respective 201 parties. 203 204 (identification information block) 205 (keying material information block) 206 208 209 (identification information block) 210 (keying material information block) 211 213 The actual content of these two elements depends on the 214 authentication scheme being used and the existence or non-existence 215 of a prior relationship between the parties. In some circumstances, 216 it may be quite difficult to distinguish between identification and 217 keying material information. A unique reference to a digital 218 certificate provides for both. This may also stand true for an 219 account number when a prior relationship exists between the parties. 221 The Originator information element is mandatory. Depending on the 222 existence or non-existence of a prior relationship with the 223 recipient, this block either refers to a public credential such as a 224 digital certificate or displays a unique identifier known by the 225 recipient. 227 The Recipient information element may be used when a document 228 contains multiple signature information blocks, each being intended 229 for a particular recipient. A unique reference in the Recipient 230 information block helps the recipients identify their respective 231 Signature information block. 233 The Recipient information element may also be used when determination 234 of the authentication key consists of a combination of keying 235 material provided by both parties. This would be the case, for 236 example, when establishing a key by means of Diffie Hellman 237 [Schneier] Key Exchange algorithm. 239 3.4 Algorithm Element 241 The Algorithm element is a generalised place to put any type of 242 algorithm used within the signed IOTP message. The Algorithm may be a 243 Signature algorithm or a Digest algorithm. Each algorithm contains 244 parameters specific to the algorithm used. 246 247 (algorithm information block) 248 250 Algorithms are required to contain an ID which allows for indirect 251 reference to them from other places in the XML signature. 253 4. Detailed Signature Syntax 255 4.1 Uniform Resource Names 257 To prevent potential name conflicts in the definition of the numerous 258 type qualifiers considered herein, this specification uses Uniform 259 Resource Names [RFC 2141]. 261 4.2 IotpSignatures 263 The IotpSignatures element is the top-level element in an IOTP 264 signature block. It consists of a collection of Signature elements, 265 and an optional set of Certificates. 267 268 271 Content Description 273 Signature: A collection of Signature elements. 275 Certificate: Zero or more certificates used for signing 277 Attributes Description 279 ID: Element identifier that may be used to reference the entire 280 Signature element from a Resource element when implementing 281 endorsement. 283 4.3 Signature Component 285 4.3.1 Signature 287 The Signature element constitutes the majority of this specification. 288 It is comprised of two sub-elements. The first one is a set of 289 attributes, known as the Manifest, which actually constitutes the 290 authenticated part of the document. The second sub-element consists 291 of the signature value or values. 293 The Value element contained within the Signature element is the 294 encoded form of the signature of the Manifest element, and thus 295 provides the verification of the Manifest. 297 The process for generating the signed value is a multi-step process, 298 involving a canonicalization algorithm, a digest algorithm, and a 299 signature algorithm. 301 First, the Manifest is canonicalized with an algorithm specified 302 within the Algorithm element of the Manifest. The canonicalized form 303 removes any inconsistencies in white space introduced by XML parsing 304 engines. 306 This canonicalized form is then converted into a digest form which 307 uniquely identifies the canonicalized document. Any slight 308 modification in the original document will result in a very different 309 digest value. 311 Finally, the digest is then signed using a public/symmetric key 312 algorithm which digitally stamps the digest (with the certificate of 313 the signer if available). The final signed digest is the value which 314 is stored within the Signature's Value element. 316 317 320 Content Description 322 Manifest: A set of attributes that actually constitutes the 323 authenticated part of the document. 325 Value: One or more encodings of signature values. Multiple values 326 allow for a multiple algorithms to be supported within a single 327 signature component. 329 Attributes Description 330 ID: Element identifier that may be used to reference the Signature 331 element from a Resource element when implementing endorsement. 333 4.3.2 Manifest 335 The Manifest element consists of a collection of attributes that 336 specify such things as as references to the resources being 337 authenticated and an indication of the keying material and algorithms 338 to be used. 340 351 Content Description 353 Algorithm: A list of algorithms used for signing, digest computation, 354 and canonicalization. 356 Digest: A list of digests of resources to be authentication and 357 signed. 359 Attribute: Optional element that consists of a collection of 360 complementary attributes to be authenticated. 362 OriginatorInfo: Element that provides identification and keying 363 material information related to the originator. 365 RecipientInfo: Optional element that provides identification and 366 keying material information related to the recipient. 368 Attributes Description 370 LocatorHrefBase: The LocatorHrefBase provides a similar construct to 371 the HTML HREFBASE attribute and implicitly sets all relative URL 372 references within the Manifest to be relative to the HrefBase. For 373 example, the IOTP Manifest may contain: 375 377 And subsequent Locators may be: 379 381 An implementation should concatenate the two locator references with 382 "#" to create the entire URL. See definition of the Locator attribute 383 on the Digest element for more detail. 385 4.3.3 Algorithm 387 This specification uses an Algorithm data type which indicates many 388 different types of algoirithms. The Algorithm element allows for 389 specification of sub-algorithms as parameters of the primary 390 algorithm. This is performed via a parameter within the algorithm 391 that provides a reference to another Algorithm. An example of this is 392 shown in the Parameter section. 394 395 400 Content Description 402 Parameter: The contents of an Algorithm element consists of an 403 optional collection of Parameter elements which are specified on a 404 per algorithm basis. 406 Attributes Description 408 ID: The ID of the algorithm is used by the Digest and RecipientInfo 409 to refer to the signing or digest algorithm used. 411 type: The type of algorithm, either a digest or signature. This is 412 implied by the element to which the algorithm is referred. That is, 413 if the DigestAlgorithmRef refers to an algorithm, it is implicit by 414 reference that the targetted algorithm is a digest. 416 name: The type of the algorithm expressed as a Uniform Resource 417 Name. 419 4.3.4 Digest 421 The Digest element consists of the fingerprint of a given resource. 422 This element is constructed of two sub-elements. This first one 423 indicates the algorithm to be used for computation of the 424 fingerprint. The second element consists of the fingerprint value. 426 427 431 Content Description 433 Locator: Contains a "HREF" or URL Locator for the resources to be 434 fingerprinted. For use within IOTP a "scheme" with the value "iotp" 435 may be used with the following structure: 437 'iotp:#'. 439 This should be interpreted as referring to an element with an ID 440 attribute that matches in any IOTP Message that has a 441 TransRefBlk Block with an IotpTransId that matches . 444 If the LocatorHrefBase attribute is set on the Manifest element of 445 which this Digest element is a child, then concatenate the value of 446 the LocatorHrefBase attribute with the value of the Locator attribute 447 before identifying the element that is being referred to. 449 If the LocatorHrefBase attribute is omitted, 450 should be interpreted as the currebt IotpTransId, which is included 451 in the IOTP message which contains the Manifest component. 453 Value: Encoding of the fingerprint value. 455 Attributes Description 457 DigestAlgorithmRef: ID Reference of algorithm used for computation of 458 the digest. 460 4.3.5 Attribute 462 The Attribute element consists of a complementary piece of 463 information, which shall be included in the authenticated part of the 464 document. This element has been defined primarily for enabling some 465 level of customization in the signature element. This is the area 466 where a specific IOTP implementation may include custom attributes 467 which must be authenticated directly. An Attribute element consists 468 of a value, a type, and a criticality. 470 At this time, no IOTP specific attributes are specified. 472 473 478 Content Description 480 ANY: The actual value of an attribute depends solely upon its type. 482 Attributes Description 484 type: Type of the attribute. 486 critical: Boolean value that indicates if the attribute is critical 487 (true) or not (false). A recipient shall reject a signature that 488 contains a critical attribute that he does not recognise. However, an 489 unrecognised non-critical attribute may be ignored. 491 4.3.6 OriginatorInfo 493 The OriginatorInfo element is used for providing identification and 494 keying material information for the originator. 496 497 501 Content Description 503 ANY: Identification and keying material information may consist of 504 ANY construct. Such a definition allows the adoption of 505 application-specific schemes. 507 Attributes Description 509 OriginatorRef: A reference to the IOTP Org ID of the originating 510 signer. 512 4.3.7 RecipientInfo 514 The RecipientInfo element is used for providing identification and 515 keying material information for the recipient. This element is used 516 either for enabling recognition of a Signature element by a given 517 recipient or when determination of the authentication key consists of 518 the combination of keying material provided by both the recipient and 519 the originator. 521 The RecipientInfo attributes provide a centralized location where 522 signatures, algorithms, and certificates intended for a particular 523 recipient are specified. 525 The signature certificate reference ID MUST point to a certificate 526 object. 528 529 536 Content Description 538 ANY: Identification and keying material information may consist of 539 ANY construct. 541 Attributes Description 543 SignatureAlgorithmRef: A reference to the signature algorithm used to 544 sign the SignatureValueRef intended for this recipient. The signature 545 algorithm reference ID MUST point to a signature algorithm within the 546 Manifest. 548 SignatureValueRef: A reference to the signature value for this 549 recipient. The signature value reference ID MUST point to a value 550 structure directly included within a Manifest. This reference can be 551 omitted if the application can specify the digest value. 553 SignatureCertRef: A reference to the certificate used to sign the 554 Value pointed to by the SignatureValueRef. This reference can be 555 omitted if the application can identify the certificate. 557 RecipientRefs: A list of references to the IOTP Org ID of the 558 recipients this signature is intended for. 560 4.3.8 KeyIdentifier 562 The key identifier element can identify the shared public/symmetric 563 key identification between parties that benefit from a prior 564 relationship. This element can be included in the ReceipientInfo 565 Element. 567 568 572 4.3.9 Parameter 574 A Parameter element provides the value of a particular algorithm 575 parameter, whose name and format have been specified for the 576 algorithm considered. 578 579 583 For IOTP 1.0, the following parameter type is standardized: 584 "AlgorithmRef". 586 An AlgorithmRef contains an ID of a "sub-Algorithm" used when 587 computing a sequence of algorithms. For example, a signature 588 algorithm actually signs a digest algorithm. To specify a chain of 589 algorithms used to compute a signature, AlgorithmRef parameter types 590 are used in the following manner: 592 593 A2 594 595 596 597 598 A1 599 601 Content Description 603 ANY: The contents of a Parameter element consists of ANY valid 604 construct, which is specified on a per algorithm per parameter basis. 606 Attributes Description 608 type: The type of the parameter expressed as a free form string, 609 whose value is specified on a per algorithm basis. 611 4.4 Certificate Component 613 4.4.1 Certificate 615 The Certificate element may be used for either providing the value of 616 a digital certificate or specifying a location from where it may be 617 retrieved. 619 623 627 Content Description 629 IssuerAndSerialNumber: Unique identifier of this certificate. This 630 element has been made mandatory is order to prevent unnecessary 631 decoding during validation of a certificate chain. This feature also 632 helps certificates caching, especially when the value is not directly 633 provided. 635 Value: Encoding of the certificate value. The actual value to be 636 encoded depends upon the type of the certificate. 638 Locator: XML link element that could be used for retrieving a copy of 639 the digital certificate. The actual value being returned by means of 640 this locator depends upon the security protocol being used. 642 Attributes Description 644 ID: Element identifier that may be used to reference the Cerfiticate 645 element from a RecipientInfo element. 647 type: Type of the digital certificate. This attribute is specified as 648 a Universal Resource Name. Support for the X.509 version 3 649 certificate [X.509] is mandatory in this sepecification if the 650 Certificate element is used. The URN for such certificates is 651 "urn:X500:X509v3". 653 4.4.2 IssuerAndSerialNumber 655 The IssuerAndSerialNumber element identifies a certificate, and 656 thereby an entity and a public key, by the name of the certificate 657 issuer and an issuer-specific certificate identification. 659 660 664 Attributes Description 666 issuer: Name of the issuing certification authority. 668 number: Issuer-specific certificate identification. 670 4.5 Common Components 672 4.5.1 Value 674 A value contains the "raw" data of a signature or digest algorithm, 675 usually in a base-64 encoded form. See [RFC 2045] for algorithm used 676 to base-64 encode data. 678 679 684 Content Description 686 PCDATA: Content value after adequate encoding. 688 Attributes Description 690 encoding: This attribute specifies the decoding scheme to be 691 employed for recovering the original byte stream from the content of 692 the element. This document recognises the following two schemes: 694 none: the content has not been subject to any particular encoding. 695 This does not preclude however the use of native XML encoding such as 696 CDATA section or XML escaping. 698 base64: The content has been encoded by means of the base64 encoding 699 scheme. 701 4.5.2 Locator 703 The Locator element consists of simple XML link [XLink]. This 704 element allows unambiguous reference to a resource or fragment of a 705 resource. 707 708 712 Attributes Description 714 xml:link: Required XML link attribute that specifies the nature of 715 the link (simple in this case). 717 href: Locator value that may contains either a URI [RFC 2396], a 718 fragment identifier, or both. 720 5. Supported Algorithms 722 The IOTP specification 1.0 requires the implementation of the DSA, 723 DOM-HASH, SHA1, HMAC algorithms. Implementation of RSA is also 724 recommended. 726 5.1 Digest Algorithms 728 This specification contemplates two types of digest algorithms, both 729 of which provide a digest string as a result: 731 Surface string digest algorithms 733 These algorithms do not have any particular knowledge about the 734 content being digested and operate on the raw content value. Any 735 changes in the surface string of a given content affect directly the 736 value of the digest being produced. 738 Canonical digest algorithms 740 These algorithms have been tailored for a particular content type and 741 produce a digest value that depends upon the core semantics of such 742 content. Changes limited to the surface string of a given content do 743 not affect the value of the digest being produced unless they affect 744 the core semantic. 746 5.1.1 SHA1 748 Surface string digest algorithm designed by NIST and NSA for use with 749 the Digital Signature Standard. This algorithm produces a 160-bit 750 hash value. This algorithm is documented in NIST FIPS Publication 751 180-1 [SHA1]. 753 This algorithm does not require any parameter. 755 The SHA1 URN used for this specification is "urn:nist-gov:sha1". 757 5.1.2 DOM-HASH 759 XML canonical digest algorithm proposed by IBM Tokyo Research 760 Laboratory. This algorithm operates on the DOM representation of the 761 document and provides an unambiguous means for recursive computation 762 of the hash value of the nodes that constitute the DOM tree [RFC 763 xxx2]. This algorithm has many applications such as computation of 764 digital signature and synchronization of DOM trees. However, because 765 the hash value of an element is computed from the hash values of the 766 inner elements, this algorithm is better adapted to small documents 767 that do not require one-pass processing. 769 As of today, this algorithm is limited to the contents of an XML 770 document and, therefore, does not provide for authentication of the 771 internal or external subset of the DTD. 773 The DOM-HASH algorithm requires a single parameter, which shall 774 include a surface string digest algorithm such as SHA1. 776 The DOM-HASH URN used for this specification is "urn:ibm-com:dom- 777 hash". 779 The DOM-HASH uses a surface-string digest algorithm for computation 780 of a fingerprint. The SHA1 is recommended in this specification. 782 Example 783 784 785 786 P.3 788 790 5.2 Signature Algorithms 792 This specification uses the terminology of 'digital signature' for 793 qualifying indifferently digital signature and message authentication 794 codes. Thus, the signature algorithms contemplated herein include 795 public key digital signature algorithms such as ECDSA and message 796 authentication codes such as HMAC [RFC 2104]. 798 5.2.1 DSA 800 Public-key signature algorithm proposed by NIST for use with the 801 Digital Signature Standard. This standard is documented in NIST FIPS 802 Publication 186 [DSS] and ANSI X9.30 [X9.30]. 804 The DSA algorithm requires a single parameter, which includes the 805 canonical digest algorithm to be used for computing the fingerprint 806 of the signature Manifest. 808 The DSA URN used in this specification is "urn:nist-gov:dsa". 810 The DSA uses a canonical or surfce-string digest algorithm for 811 computation of the Manifest fingerprint. The DOM-HASH is recommended 812 in this specification. 814 Signature Value Encoding: 816 The output of this algorithm consists of a pair of integers usually 817 referred by the pair (r, s). The signature value shall consist of the 818 concatenation of two octet-streams that respectively result from the 819 octet-encoding of the values r and s. Integer to octet-stream 820 conversion shall be done according to PKCS#1 [RFC 2437] specification 821 with a k parameter equals to 20. 823 Example 824 825 P.4 826 827 828 P.5 829 830 831 833 5.2.2 HMAC 835 Message Authentication Code proposed by H. Krawczyk et al. and 836 documented in [RFC 2104]. 838 This specification adopts a scheme that differs a bit from the common 839 usage of this algorithm -- computation of the MAC is performed on the 840 hash of the contents being authenticated instead of the actual 841 contents. Thence, the actual signature value output by the algorithm 842 might be depicted as follows: 844 SignatureValue = HMAC( SecretKey, H(Manifest)) 846 This specification also considered HMAC output truncation such as 847 proposed by Preneel and van Oorschot. In their paper [PV] these two 848 researchers have shown some analytical advantages of truncating the 849 output of hash-based MAC functions. Such output truncation is also 850 considered in the RFC document. 852 HMAC requires three parameters. The first one consists of a canonical 853 digest algorithm. The second one consists of a hash function. The 854 last one is optional and specifies the length in bit of the truncated 855 output. If this last parameter is absent, no truncation shall occur. 857 The HMAC URN used in this specification is "urn:ietf-org:hmac". 859 Canonical digest algorithm: Canonical or surface-string digest 860 algorithm is to be used for computation of the Manifest fingerprint. 861 The type of this parameter is set to "AlgorithmRef". The recommended 862 value of this Parameter should be the ID reference for the Algorithm 863 element DOM-HASH. 865 Hash-function: Hash function is to be used to compute the MAC value 866 from the secret key and the fingerprint of the signature Manifest. 867 The type of this parameter is set to "HashAlgorithmRef" and the value 868 of this parameter should be set to the ID reference for the Algorithm 869 element of SHA1. 871 Output-length: Length in bits of the truncated MAC value. The type of 872 this parameter is set to "KeyLength" and the value of this parameter 873 is set the length in bits of the truncated MAC value. 875 Signature Value Encoding: 877 The output of this algorithm can be assumed as a large integer value. 878 The signature value shall consist of the octet-encoded value of this 879 integer. Integer to octet-stream conversion shall be done according 880 to PKCS#1 [RFC 2437] specification with a k parameter equals to 881 ((Hlen +7) mod8), Mlen being the length in bits of the MAC value. 883 Example 884 885 P.4 886 P.5 887 128 888 889 890 P.5 891 892 893 895 5.2.3 RSA 897 Public-key signature algorithm proposed by RSA Laboratories and 898 documented in PKCS#1 [RFC 2437]. 900 This specification adopts the RSA encryption algorithm with padding 901 block type 01. For computing the signature value, the signer shall 902 first digest the signature Manifest and then encrypt the resulting 903 digest with his private key. 905 This signature algorithm requires a single parameter, which consists 906 of the canonical digest algorithm to be used for computing the 907 fingerprint of the signature Manifest. 909 Specifications 911 The RSA URN used in this specification is "urn:rsasdi-com:rsa- 912 encription". 914 The RSA uses a canonical or surfce-string digest algorithm for 915 computation of the Manifest fingerprint. The DOM-HASH is recommended 916 in this specification. 918 Signature Value Encoding: 920 The output of this algorithm consists of single octet-stream. No 921 further encoding is required. 923 Example 924 926 P.4 927 928 929 P.5 931 932 933 935 5.2.4 ECDSA 937 Public-key signature algorithm proposed independently by Neil Koblitz 938 and Victor Miller. This algorithm is being proposed as an ANSI 939 standard and is documented in ANSI X9.62 standard proposal [X9.62] 940 and IEEE/P1363 standard draft proposal [IEEE P1363]. 942 The ECDSA algorithm requires a single parameter, which consists of 943 the canonical digest algorithm to be used for computing the 944 fingerprint of the signature Manifest. 946 Specifications 948 The ECDSA URN used in this specification is "urn:ansi-org:ecdsa". 950 The ECDSA uses a canonical or surfce-string digest algorithm for 951 computation of the Manifest fingerprint. The DOM-HASH [RFC xxx2] is 952 recommended in this specification. 954 Signature Value Encoding: 956 The output of this algorithm consists of a pair of integers usually 957 referred by the pair (r, s). The signature value shall consist of the 958 concatenation of two octet-streams that respectively result from the 959 octet-encoding of the values r and s. Integer to octet-stream 960 conversion shall be done according to PKCS#1 [RFC 2437] specification 961 with a k parameter equals to 20. 963 Example 964 965 P.4 966 967 968 P.5 969 970 971 973 6. Examples 975 The following is an example signed IOTP message: 977 978 979 985 986 987 988 989 990 991 992 994 995 997 P.5 998 999 1001 P.3 1002 1003 1004 1005 1006 xsqsfasDys2h44u4ehJDe54he5j4dJYTJ 1007 1008 1009 1013 1014 1017 1018 1019 9dj28fjakA9sked0Ks01k2d7a0kgmf9dk19lf63kkDSs0 1020 1021 1022 1023 1026 1027 xsqsfasDys2h44u4ehJDe54he5j4dJYTJ= 1028 1029 1030 1031 1032 1036 1037 snroasdfnas934k 1038 1039 1040 1041 1043 7. Signature DTD 1045 1051 1052 1056 1062 1063 1067 1076 1080 1081 1087 1088 1092 1093 1098 1099 1103 1104 1111 1112 1116 1117 1120 1126 1130 1135 1136 1141 1146 1147 1152 1153 1158 8. Security Considerations 1160 This entire document concerns the IOTP v1 protocol signature element 1161 which is used for authentication. See the Security Considerations 1162 section of [RFC xxxx] "Internet Open Trading Protocol - IOTP, Version 1163 1.0". 1165 Full Copyright Statement 1167 Copyright (C) The Internet Society 1999. 1169 This document and translations of it may be copied and furnished to 1170 others, and derivative works that comment on or otherwise explain it 1171 or assist in its implementation may be prepared, copied, published 1172 and distributed, in whole or in part, without restriction of any 1173 kind, provided that the above copyright notice and this paragraph are 1174 included on all such copies and derivative works. However, this 1175 document itself may not be modified in any way, such as by removing 1176 the copyright notice or references to the Internet Society or other 1177 Internet organizations, except as needed for the purpose of 1178 developing Internet standards in which case the procedures for 1179 copyrights defined in the Internet Standards process must be 1180 followed, or as required to translate it into languages other than 1181 English. 1183 The limited permissions granted above are perpetual and will not be 1184 revoked by the Internet Society or its successors or assigns. 1186 This document and the information contained herein is provided on an 1187 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 1188 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 1189 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 1190 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 1191 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1193 References 1195 [DSA] - Federal Information Processing Standards Plublication FIPS 1196 PUB 186, "Digital Signature Standard(DSS)", 1994, 1197 1199 [IEEE P1363] - IEEE P1363, "Standard Specifications for Public-Key 1200 Cryptography", draft, 1997, 1202 [PV] - B. Preneel and P. van Oorschot, "Building fast MACs from hash 1203 functions", Advances in Cryptology -- CRYPTO'95 Proceedings, Lecture 1204 Notes in Computer Science, Springer-Verlag Vol.963, 1995, pp. 1-14. 1206 [RFC 1321] - R. Rivest, "The MD5 Message-Digest Algorithm", April 1207 1992. 1209 [RFC 2045]- N. Freed & N. Borenstein, "Multipurpose Internet Mail 1210 Extensions (MIME) Part One: Format of Internet Message Bodies", 1211 November 1996. 1213 [RFC 2046] - N. Freed & N. Borenstein, "Multipurpose Internet Mail 1214 Extensions (MIME) Part Two: Media Types", November 1996. 1216 [RFC 2104] - H. Krawczyk, M. Bellare, R. Canetti, "HMAC: Keyed- 1217 Hashing for Message Authentication", February 1997. 1219 [RFC 2141] - R. Moats, "URN Syntax", May 1997. 1221 [RFC 2396] - T. Berners-Lee, R. Fielding, L. Masinter, "Uniform 1222 Resource Identifiers (URI): Generic Syntax", August 1998. 1224 [RFC 2437] - B. Kaliski, J. Staddon, "PKCS #1: RSA Cryptography 1225 Specifications, Version 2.0", October 1998. 1227 [RFC xxx1] - D. Burdett, "Interenet Open Trading Protocol - IOTP, 1228 Version 1.0", September 1999. (currently draft-ietf-trade-iotp-v1.0- 1229 protcool-*.txt) 1231 [RFC xxx2] - H. Maruyama, K. Tamura, & N. Uramot, "Digest Values for 1232 DOM (DOMHASH)", September 1999. (currently draft-ietf-trade-hiroshi- 1233 dom-hash-*.txt) 1235 [Schneier] - Bruce Schneier, "Applied Cryptography: Protocols, 1236 Algorithms, and Source Code in C", 1996, John Wiley and Sons 1238 [SHA1] - NIST FIPS PUB 180-1, "Secure Hash Standard," National 1239 Institute of Standards and Technology, U.S. Department of Commerce, 1240 April 1995. 1242 [X.509] - ITU-T Recommendation X.509 (1997 E), "Information 1243 Technology - Open Systems Interconnection - The Directory: 1244 Authentication Framework", June 1997. 1246 [X9.30] - ASC X9 Secretariat: American Bankers Association, "American 1247 National Standard for Financial Services - Public Key Cryptography 1248 Using Irreversible Algorithms for the Financial Services Industry - 1249 Part 1: The Digital Signature Algorithm(DSA)", 1995. 1251 [X9.62] - ASC X9 Secretariat: American Bankers Association,"American 1252 National Standard for Financial Services - Public Key Cryptography 1253 Using Irreversible Algorithms for the Financial Services Industry - 1254 The Elliptic Curve Digital Signature Algorithm (ECDSA)", draft, 1997. 1256 [XLink] - Eve Maler, Steve DeRose, "XML Linking Language (XLink)", 1257 1259 [XML] - Tim Bray, Jean Paoli, C. M. Sperber-McQueen, "Extensible 1260 Markup Language (XML) 1.0", 1263 Author's Addresses 1265 This document is based on work originally done on general XML digital 1266 signatures by Richard Brown at GlobeSet, Inc. 1267 but has been narrowed and changed. 1269 The authors of this document are: 1271 Kent M. Davidson 1272 Differential, Inc. 1273 440 Clyde Ave. 1274 Mountain View, CA 94043 USA 1275 email: kent@differential.com 1277 Yoshiaki Kawatsura 1278 Hitachi, Ltd. 1279 890-12 Kashimada Saiwai Kawasaki, 1280 Kanagawa 2118567 Japan 1281 email: kawatura@bisd.hitachi.co.jp 1283 Contributors to the design of the IOTP DTD include, in alphabetic 1284 order: 1286 David Burdett, Commerce One 1288 Andrew Drapp, Hitachi 1290 Donald Eastlake 3rd, IBM 1292 Expiration and File Name 1294 This draft expires March 2000. 1296 Its file name is draft-ietf-trade-iotp-v1.0-dsig-03.txt.