idnits 2.17.1 draft-ietf-trade-iotp-v1.0-dsig-05.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-05', contains other characters than digits, lowercase letters and dash. == 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. ** 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 540: '...ate reference ID MUST point to a certi...' RFC 2119 keyword, line 560: '...thm reference ID MUST point to a signa...' RFC 2119 keyword, line 564: '...lue reference ID MUST point to a value...' RFC 2119 keyword, line 682: '... for RECOMMENDED syntax....' 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 (November 1999) is 8922 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 691, but not defined == Missing Reference: 'DSS' is mentioned on line 816, but not defined == Unused Reference: 'DSA' is defined on line 1209, but no explicit reference was found in the text == Unused Reference: 'RFC 1321' is defined on line 1220, but no explicit reference was found in the text == Unused Reference: 'RFC 2046' is defined on line 1227, 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 2253 (Obsoleted by RFC 4510, RFC 4514) ** 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: 14 errors (**), 0 flaws (~~), 8 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: May 2000 November 1999 6 draft-ietf-trade-iotp-v1.0-dsig-05.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-05.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 Abstract 39 A syntax and procedures are described for the computation and 40 verification of digital signatures for use within Version 1.0 of the 41 Internet Open Trading Protocol (IOTP). 43 [Changes from previous draft: correction of one line in DTD, move 44 acknowledgement to the front.] 46 Copyright 48 Copyright (C) 1999. The Internet Society. All Rights Reserved. 50 Acknowledgement 52 This document is based on work originally done on general XML digital 53 signatures by 55 Richard Brown of GlobeSet, Inc. 57 Other contributors to the design of the IOTP DSIG DTD include, in 58 alphabetic order: 60 David Burdett, Commerce One 61 Andrew Drapp, Hitachi 62 Donald Eastlake 3rd, IBM 64 Table of Contents 66 Status of This Document....................................1 67 Abstract...................................................1 69 Copyright..................................................2 70 Acknowledgement............................................2 71 Table of Contents..........................................2 73 1. Introduction............................................4 75 2. Objective and Requirements..............................5 77 3. Signature Basics........................................6 78 3.1 Signature Element......................................6 79 3.2 Digest Element.........................................6 80 3.3 Originator and Recipient Information Elements..........7 81 3.4 Algorithm Element......................................8 82 4. Detailed Signature Syntax...............................8 83 4.1 Uniform Resource Names.................................8 84 4.2 IotpSignatures.........................................8 85 4.3 Signature Component....................................9 86 4.3.1 Signature............................................9 87 4.3.2 Manifest............................................10 88 4.3.3 Algorithm...........................................11 89 4.3.4 Digest..............................................11 90 4.3.5 Attribute...........................................12 91 4.3.6 OriginatorInfo......................................13 92 4.3.7 RecipientInfo.......................................13 93 4.3.8 KeyIdentifier.......................................14 94 4.3.9 Parameter...........................................15 95 4.4 Certificate Component.................................16 96 4.4.1 Certificate.........................................16 97 4.4.2 IssuerAndSerialNumber...............................17 98 4.5 Common Components.....................................17 99 4.5.1 Value...............................................17 100 4.5.2 Locator.............................................18 101 5. Supported Algorithms...................................18 102 5.1 Digest Algorithms.....................................18 103 5.1.1 SHA1................................................19 104 5.1.2 DOM-HASH............................................19 105 5.2 Signature Algorithms..................................20 106 5.2.1 DSA.................................................20 107 5.2.2 HMAC................................................21 108 5.2.3 RSA.................................................22 109 5.2.4 ECDSA...............................................23 110 6. Examples...............................................24 111 7. Signature DTD..........................................25 113 8. Security Considerations................................28 114 Full Copyright Statement..................................28 116 References................................................29 118 Author's Addresses........................................31 119 Expiration and File Name..................................31 121 1. Introduction 123 The Internet Open Trading Protocol (IOTP) provides a payment system 124 independent interoperable framework for Internet commerce as 125 documented in [RFC xxx1]. All IOTP messages are XML documents. XML, 126 the Extensible Markup Language [XML], is a syntactical standard 127 promulgated by the World Wide Web Consortium. XML is intended 128 primarily for structuring data exchanged and served over the World 129 Wide Web. 131 Although IOTP assumes that any payment system used with it provides 132 its own security, there are numerous cases where IOTP requires 133 authentication and integrity services for portions of the XML 134 messages it specifies. 136 2. Objective and Requirements 138 This document covers how digital signatures may be used with XML 139 documents to provide authentication and tamper-proof protocol 140 messages specifically for Version 1.0 of the IOTP protocol. The 141 reader should recognize that an effort towards general XML digital 142 signatures exists but is unlikely to produce its final result in time 143 for IOTP Version 1.0. Future versions of IOTP will probably adopt by 144 reference the results of this general XML digital signature effort. 146 The objective of this document is to propose syntax and procedures 147 for the computation and verification of digital signatures applicable 148 to Version 1.0 IOTP protocol messages, providing for: 150 -- Authentication of IOTP transactions 151 -- Provide a means by which an IOTP message may be made "tamper- 152 proof", or detection of tampering is made evident 153 -- Describe a set of available digest and signature algorithms at 154 least one of which is mandatory to implement for interoperability 155 -- Easily integrate within the IOTP 1.0 Specification 156 -- Provide lightweight signatures with minimal redundancy 157 -- Allow signed portions of IOTP message to be "forwarded" to another 158 trading roles with different signature algorithms than the 159 original recipient 161 3. Signature Basics 163 3.1 Signature Element 165 This specification consists primarily of the definition of an XML 166 element known as the Signature element. This element consists of two 167 sub-elements. The first one is a set of authenticated attributes, 168 known as the signature Manifest, which comprises such things as a 169 unique reference to the resources being authenticated and an 170 indication of the keying material and algorithms being used. The 171 second sub-element consists of the digital signature value. 173 174 175 (resource information block) 176 (originator information block) 177 (recipient information block) 178 (other attributes) 179 (signature algorithms information block) 180 181 182 (encoded signature value) 183 184 186 The digital signature is not computed directly from the pieces of 187 information to be authenticated. Instead, the digital signature is 188 computed from a set of authenticated attributes (the Manifest), which 189 include references to, and a digests of, those pieces of information. 191 The authentication is therefore "indirect". 193 3.2 Digest Element 195 The Digest element consists of a unique and unambiguous reference to 196 the XML resources being authenticated. It is constructed of a locator 197 and the digest value data itself. The Digest algorithm is referred to 198 indirectly via a DigestAlgorithmRef, so that Digest algorithms may be 199 shared by multiple resources. 201 202 203 204 (Digest value) 205 206 207 The resource locator is implemented as a simple XML Link [XLink]. 208 This not only provides a unique addressing scheme for internal and 209 external resources, but also facilitates authentication of composite 210 documents. 212 3.3 Originator and Recipient Information Elements 214 The purpose of the Originator and Recipient information elements is 215 to provide identification and keying material for these respective 216 parties. 218 219 (identification information block) 220 (keying material information block) 221 223 224 (identification information block) 225 (keying material information block) 226 228 The actual content of these two elements depends on the 229 authentication scheme being used and the existence or non-existence 230 of a prior relationship between the parties. In some circumstances, 231 it may be quite difficult to distinguish between identification and 232 keying material information. A unique reference to a digital 233 certificate provides for both. This may also stand true for an 234 account number when a prior relationship exists between the parties. 236 The Originator information element is mandatory. Depending on the 237 existence or non-existence of a prior relationship with the 238 recipient, this block either refers to a public credential such as a 239 digital certificate or displays a unique identifier known by the 240 recipient. 242 The Recipient information element may be used when a document 243 contains multiple signature information blocks, each being intended 244 for a particular recipient. A unique reference in the Recipient 245 information block helps the recipients identify their respective 246 Signature information block. 248 The Recipient information element may also be used when determination 249 of the authentication key consists of a combination of keying 250 material provided by both parties. This would be the case, for 251 example, when establishing a key by means of Diffie Hellman 252 [Schneier] Key Exchange algorithm. 254 3.4 Algorithm Element 256 The Algorithm element is a generalised place to put any type of 257 algorithm used within the signed IOTP message. The Algorithm may be a 258 Signature algorithm or a Digest algorithm. Each algorithm contains 259 parameters specific to the algorithm used. 261 262 (algorithm information block) 263 265 Algorithms are required to contain an ID which allows for indirect 266 reference to them from other places in the XML signature. 268 4. Detailed Signature Syntax 270 4.1 Uniform Resource Names 272 To prevent potential name conflicts in the definition of the numerous 273 type qualifiers considered herein, this specification uses Uniform 274 Resource Names [RFC 2141]. 276 4.2 IotpSignatures 278 The IotpSignatures element is the top-level element in an IOTP 279 signature block. It consists of a collection of Signature elements, 280 and an optional set of Certificates. 282 283 286 Content Description 288 Signature: A collection of Signature elements. 290 Certificate: Zero or more certificates used for signing 292 Attributes Description 294 ID: Element identifier that may be used to reference the entire 295 Signature element from a Resource element when implementing 296 endorsement. 298 4.3 Signature Component 300 4.3.1 Signature 302 The Signature element constitutes the majority of this specification. 303 It is comprised of two sub-elements. The first one is a set of 304 attributes, known as the Manifest, which actually constitutes the 305 authenticated part of the document. The second sub-element consists 306 of the signature value or values. 308 The Value element contained within the Signature element is the 309 encoded form of the signature of the Manifest element, and thus 310 provides the verification of the Manifest. 312 The process for generating the signed value is a multi-step process, 313 involving a canonicalization algorithm, a digest algorithm, and a 314 signature algorithm. 316 First, the Manifest is canonicalized with an algorithm specified 317 within the Algorithm element of the Manifest. The canonicalized form 318 removes any inconsistencies in white space introduced by XML parsing 319 engines. 321 This canonicalized form is then converted into a digest form which 322 uniquely identifies the canonicalized document. Any slight 323 modification in the original document will result in a very different 324 digest value. 326 Finally, the digest is then signed using a public/symmetric key 327 algorithm which digitally stamps the digest (with the certificate of 328 the signer if available). The final signed digest is the value which 329 is stored within the Signature's Value element. 331 332 335 Content Description 337 Manifest: A set of attributes that actually constitutes the 338 authenticated part of the document. 340 Value: One or more encodings of signature values. Multiple values 341 allow for a multiple algorithms to be supported within a single 342 signature component. 344 Attributes Description 345 ID: Element identifier that may be used to reference the Signature 346 element from a Resource element when implementing endorsement. 348 4.3.2 Manifest 350 The Manifest element consists of a collection of attributes that 351 specify such things as as references to the resources being 352 authenticated and an indication of the keying material and algorithms 353 to be used. 355 366 Content Description 368 Algorithm: A list of algorithms used for signing, digest computation, 369 and canonicalization. 371 Digest: A list of digests of resources to be authentication and 372 signed. 374 Attribute: Optional element that consists of a collection of 375 complementary attributes to be authenticated. 377 OriginatorInfo: Element that provides identification and keying 378 material information related to the originator. 380 RecipientInfo: Optional element that provides identification and 381 keying material information related to the recipient. 383 Attributes Description 385 LocatorHrefBase: The LocatorHrefBase provides a similar construct to 386 the HTML HREFBASE attribute and implicitly sets all relative URL 387 references within the Manifest to be relative to the HrefBase. For 388 example, the IOTP Manifest may contain: 390 392 And subsequent Locators may be: 394 396 An implementation should concatenate the two locator references with 397 "#" to create the entire URL. See definition of the Locator attribute 398 on the Digest element for more detail. 400 4.3.3 Algorithm 402 This specification uses an Algorithm data type which indicates many 403 different types of algoirithms. The Algorithm element allows for 404 specification of sub-algorithms as parameters of the primary 405 algorithm. This is performed via a parameter within the algorithm 406 that provides a reference to another Algorithm. An example of this is 407 shown in the Parameter section. 409 410 415 Content Description 417 Parameter: The contents of an Algorithm element consists of an 418 optional collection of Parameter elements which are specified on a 419 per algorithm basis. 421 Attributes Description 423 ID: The ID of the algorithm is used by the Digest and RecipientInfo 424 to refer to the signing or digest algorithm used. 426 type: The type of algorithm, either a digest or signature. This is 427 implied by the element to which the algorithm is referred. That is, 428 if the DigestAlgorithmRef refers to an algorithm, it is implicit by 429 reference that the targetted algorithm is a digest. 431 name: The type of the algorithm expressed as a Uniform Resource 432 Name. 434 4.3.4 Digest 436 The Digest element consists of the fingerprint of a given resource. 437 This element is constructed of two sub-elements. This first one 438 indicates the algorithm to be used for computation of the 439 fingerprint. The second element consists of the fingerprint value. 441 442 446 Content Description 448 Locator: Contains a "HREF" or URL Locator for the resources to be 449 fingerprinted. For use within IOTP a "scheme" with the value "iotp" 450 may be used with the following structure: 452 'iotp:#'. 454 This should be interpreted as referring to an element with an ID 455 attribute that matches in any IOTP Message that has a 456 TransRefBlk Block with an IotpTransId that matches . 459 If the LocatorHrefBase attribute is set on the Manifest element of 460 which this Digest element is a child, then concatenate the value of 461 the LocatorHrefBase attribute with the value of the Locator attribute 462 before identifying the element that is being referred to. 464 If the LocatorHrefBase attribute is omitted, 465 should be interpreted as the currebt IotpTransId, which is included 466 in the IOTP message which contains the Manifest component. 468 Value: Encoding of the fingerprint value. 470 Attributes Description 472 DigestAlgorithmRef: ID Reference of algorithm used for computation of 473 the digest. 475 4.3.5 Attribute 477 The Attribute element consists of a complementary piece of 478 information, which shall be included in the authenticated part of the 479 document. This element has been defined primarily for enabling some 480 level of customization in the signature element. This is the area 481 where a specific IOTP implementation may include custom attributes 482 which must be authenticated directly. An Attribute element consists 483 of a value, a type, and a criticality. 485 At this time, no IOTP specific attributes are specified. 487 488 493 Content Description 495 ANY: The actual value of an attribute depends solely upon its type. 497 Attributes Description 499 type: Type of the attribute. 501 critical: Boolean value that indicates if the attribute is critical 502 (true) or not (false). A recipient shall reject a signature that 503 contains a critical attribute that he does not recognise. However, an 504 unrecognised non-critical attribute may be ignored. 506 4.3.6 OriginatorInfo 508 The OriginatorInfo element is used for providing identification and 509 keying material information for the originator. 511 512 516 Content Description 518 ANY: Identification and keying material information may consist of 519 ANY construct. Such a definition allows the adoption of 520 application-specific schemes. 522 Attributes Description 524 OriginatorRef: A reference to the IOTP Org ID of the originating 525 signer. 527 4.3.7 RecipientInfo 529 The RecipientInfo element is used for providing identification and 530 keying material information for the recipient. This element is used 531 either for enabling recognition of a Signature element by a given 532 recipient or when determination of the authentication key consists of 533 the combination of keying material provided by both the recipient and 534 the originator. 536 The RecipientInfo attributes provide a centralized location where 537 signatures, algorithms, and certificates intended for a particular 538 recipient are specified. 540 The signature certificate reference ID MUST point to a certificate 541 object. 543 544 551 Content Description 553 ANY: Identification and keying material information may consist of 554 ANY construct. 556 Attributes Description 558 SignatureAlgorithmRef: A reference to the signature algorithm used to 559 sign the SignatureValueRef intended for this recipient. The signature 560 algorithm reference ID MUST point to a signature algorithm within the 561 Manifest. 563 SignatureValueRef: A reference to the signature value for this 564 recipient. The signature value reference ID MUST point to a value 565 structure directly included within a Manifest. This reference can be 566 omitted if the application can specify the digest value. 568 SignatureCertRef: A reference to the certificate used to sign the 569 Value pointed to by the SignatureValueRef. This reference can be 570 omitted if the application can identify the certificate. 572 RecipientRefs: A list of references to the IOTP Org ID of the 573 recipients this signature is intended for. 575 4.3.8 KeyIdentifier 577 The key identifier element can identify the shared public/symmetric 578 key identification between parties that benefit from a prior 579 relationship. This element can be included in the ReceipientInfo 580 Element. 582 583 587 4.3.9 Parameter 589 A Parameter element provides the value of a particular algorithm 590 parameter, whose name and format have been specified for the 591 algorithm considered. 593 594 598 For IOTP 1.0, the following parameter type is standardized: 599 "AlgorithmRef". 601 An AlgorithmRef contains an ID of a "sub-Algorithm" used when 602 computing a sequence of algorithms. For example, a signature 603 algorithm actually signs a digest algorithm. To specify a chain of 604 algorithms used to compute a signature, AlgorithmRef parameter types 605 are used in the following manner: 607 608 A2 609 610 611 612 613 A1 614 616 Content Description 618 ANY: The contents of a Parameter element consists of ANY valid 619 construct, which is specified on a per algorithm per parameter basis. 621 Attributes Description 623 type: The type of the parameter expressed as a free form string, 624 whose value is specified on a per algorithm basis. 626 4.4 Certificate Component 628 4.4.1 Certificate 630 The Certificate element may be used for either providing the value of 631 a digital certificate or specifying a location from where it may be 632 retrieved. 634 638 642 Content Description 644 IssuerAndSerialNumber: Unique identifier of this certificate. This 645 element has been made mandatory is order to prevent unnecessary 646 decoding during validation of a certificate chain. This feature also 647 helps certificates caching, especially when the value is not directly 648 provided. 650 Value: Encoding of the certificate value. The actual value to be 651 encoded depends upon the type of the certificate. 653 Locator: XML link element that could be used for retrieving a copy of 654 the digital certificate. The actual value being returned by means of 655 this locator depends upon the security protocol being used. 657 Attributes Description 659 ID: Element identifier that may be used to reference the Cerfiticate 660 element from a RecipientInfo element. 662 type: Type of the digital certificate. This attribute is specified as 663 a Universal Resource Name. Support for the X.509 version 3 664 certificate [X.509] is mandatory in this sepecification if the 665 Certificate element is used. The URN for such certificates is 666 "urn:X500:X509v3". 668 4.4.2 IssuerAndSerialNumber 670 The IssuerAndSerialNumber element identifies a certificate, and 671 thereby an entity and a public key, by the name of the certificate 672 issuer and an issuer-specific certificate identification. 674 675 679 Attributes Description 681 issuer: Name of the issuing certification authority. See [RFC 2253] 682 for RECOMMENDED syntax. 684 number: Issuer-specific certificate identification. 686 4.5 Common Components 688 4.5.1 Value 690 A value contains the "raw" data of a signature or digest algorithm, 691 usually in a base-64 encoded form. See [RFC 2045] for algorithm used 692 to base-64 encode data. 694 695 700 Content Description 702 PCDATA: Content value after adequate encoding. 704 Attributes Description 706 encoding: This attribute specifies the decoding scheme to be 707 employed for recovering the original byte stream from the content of 708 the element. This document recognises the following two schemes: 710 none: the content has not been subject to any particular encoding. 711 This does not preclude however the use of native XML encoding such as 712 CDATA section or XML escaping. 714 base64: The content has been encoded by means of the base64 encoding 715 scheme. 717 4.5.2 Locator 719 The Locator element consists of simple XML link [XLink]. This 720 element allows unambiguous reference to a resource or fragment of a 721 resource. 723 724 728 Attributes Description 730 xml:link: Required XML link attribute that specifies the nature of 731 the link (simple in this case). 733 href: Locator value that may contains either a URI [RFC 2396], a 734 fragment identifier, or both. 736 5. Supported Algorithms 738 The IOTP specification 1.0 requires the implementation of the DSA, 739 DOM-HASH, SHA1, HMAC algorithms. Implementation of RSA is also 740 recommended. 742 5.1 Digest Algorithms 744 This specification contemplates two types of digest algorithms, both 745 of which provide a digest string as a result: 747 Surface string digest algorithms 749 These algorithms do not have any particular knowledge about the 750 content being digested and operate on the raw content value. Any 751 changes in the surface string of a given content affect directly the 752 value of the digest being produced. 754 Canonical digest algorithms 755 These algorithms have been tailored for a particular content type and 756 produce a digest value that depends upon the core semantics of such 757 content. Changes limited to the surface string of a given content do 758 not affect the value of the digest being produced unless they affect 759 the core semantic. 761 5.1.1 SHA1 763 Surface string digest algorithm designed by NIST and NSA for use with 764 the Digital Signature Standard. This algorithm produces a 160-bit 765 hash value. This algorithm is documented in NIST FIPS Publication 766 180-1 [SHA1]. 768 This algorithm does not require any parameter. 770 The SHA1 URN used for this specification is "urn:nist-gov:sha1". 772 5.1.2 DOM-HASH 774 XML canonical digest algorithm proposed by IBM Tokyo Research 775 Laboratory. This algorithm operates on the DOM representation of the 776 document and provides an unambiguous means for recursive computation 777 of the hash value of the nodes that constitute the DOM tree [RFC 778 xxx2]. This algorithm has many applications such as computation of 779 digital signature and synchronization of DOM trees. However, because 780 the hash value of an element is computed from the hash values of the 781 inner elements, this algorithm is better adapted to small documents 782 that do not require one-pass processing. 784 As of today, this algorithm is limited to the contents of an XML 785 document and, therefore, does not provide for authentication of the 786 internal or external subset of the DTD. 788 The DOM-HASH algorithm requires a single parameter, which shall 789 include a surface string digest algorithm such as SHA1. 791 The DOM-HASH URN used for this specification is "urn:ibm-com:dom- 792 hash". 794 The DOM-HASH uses a surface-string digest algorithm for computation 795 of a fingerprint. The SHA1 is recommended in this specification. 797 Example 798 799 800 801 P.3 802 804 5.2 Signature Algorithms 806 This specification uses the terminology of 'digital signature' for 807 qualifying indifferently digital signature and message authentication 808 codes. Thus, the signature algorithms contemplated herein include 809 public key digital signature algorithms such as ECDSA and message 810 authentication codes such as HMAC [RFC 2104]. 812 5.2.1 DSA 814 Public-key signature algorithm proposed by NIST for use with the 815 Digital Signature Standard. This standard is documented in NIST FIPS 816 Publication 186 [DSS] and ANSI X9.30 [X9.30]. 818 The DSA algorithm requires a single parameter, which includes the 819 canonical digest algorithm to be used for computing the fingerprint 820 of the signature Manifest. 822 The DSA URN used in this specification is "urn:nist-gov:dsa". 824 The DSA uses a canonical or surfce-string digest algorithm for 825 computation of the Manifest fingerprint. The DOM-HASH is recommended 826 in this specification. 828 Signature Value Encoding: 830 The output of this algorithm consists of a pair of integers usually 831 referred by the pair (r, s). The signature value shall consist of the 832 concatenation of two octet-streams that respectively result from the 833 octet-encoding of the values r and s. Integer to octet-stream 834 conversion shall be done according to PKCS#1 [RFC 2437] specification 835 with a k parameter equals to 20. 837 Example 838 839 P.4 840 841 842 P.5 843 844 845 847 5.2.2 HMAC 849 Message Authentication Code proposed by H. Krawczyk et al. and 850 documented in [RFC 2104]. 852 This specification adopts a scheme that differs a bit from the common 853 usage of this algorithm -- computation of the MAC is performed on the 854 hash of the contents being authenticated instead of the actual 855 contents. Thence, the actual signature value output by the algorithm 856 might be depicted as follows: 858 SignatureValue = HMAC( SecretKey, H(Manifest)) 860 This specification also considered HMAC output truncation such as 861 proposed by Preneel and van Oorschot. In their paper [PV] these two 862 researchers have shown some analytical advantages of truncating the 863 output of hash-based MAC functions. Such output truncation is also 864 considered in the RFC document. 866 HMAC requires three parameters. The first one consists of a canonical 867 digest algorithm. The second one consists of a hash function. The 868 last one is optional and specifies the length in bit of the truncated 869 output. If this last parameter is absent, no truncation shall occur. 871 The HMAC URN used in this specification is "urn:ietf-org:hmac". 873 Canonical digest algorithm: Canonical or surface-string digest 874 algorithm is to be used for computation of the Manifest fingerprint. 875 The type of this parameter is set to "AlgorithmRef". The recommended 876 value of this Parameter should be the ID reference for the Algorithm 877 element DOM-HASH. 879 Hash-function: Hash function is to be used to compute the MAC value 880 from the secret key and the fingerprint of the signature Manifest. 881 The type of this parameter is set to "HashAlgorithmRef" and the value 882 of this parameter should be set to the ID reference for the Algorithm 883 element of SHA1. 885 Output-length: Length in bits of the truncated MAC value. The type of 886 this parameter is set to "KeyLength" and the value of this parameter 887 is set the length in bits of the truncated MAC value. 889 Signature Value Encoding: 891 The output of this algorithm can be assumed as a large integer value. 892 The signature value shall consist of the octet-encoded value of this 893 integer. Integer to octet-stream conversion shall be done according 894 to PKCS#1 [RFC 2437] specification with a k parameter equals to 895 ((Hlen +7) mod8), Mlen being the length in bits of the MAC value. 897 Example 898 899 P.4 900 P.5 901 128 902 903 904 P.5 905 906 907 909 5.2.3 RSA 911 Public-key signature algorithm proposed by RSA Laboratories and 912 documented in PKCS#1 [RFC 2437]. 914 This specification adopts the RSA encryption algorithm with padding 915 block type 01. For computing the signature value, the signer shall 916 first digest the signature Manifest and then encrypt the resulting 917 digest with his private key. 919 This signature algorithm requires a single parameter, which consists 920 of the canonical digest algorithm to be used for computing the 921 fingerprint of the signature Manifest. 923 Specifications 925 The RSA URN used in this specification is "urn:rsasdi-com:rsa- 926 encription". 928 The RSA uses a canonical or surfce-string digest algorithm for 929 computation of the Manifest fingerprint. The DOM-HASH is recommended 930 in this specification. 932 Signature Value Encoding: 934 The output of this algorithm consists of single octet-stream. No 935 further encoding is required. 937 Example 938 940 P.4 941 942 943 P.5 945 946 947 949 5.2.4 ECDSA 951 Public-key signature algorithm proposed independently by Neil Koblitz 952 and Victor Miller. This algorithm is being proposed as an ANSI 953 standard and is documented in ANSI X9.62 standard proposal [X9.62] 954 and IEEE/P1363 standard draft proposal [IEEE P1363]. 956 The ECDSA algorithm requires a single parameter, which consists of 957 the canonical digest algorithm to be used for computing the 958 fingerprint of the signature Manifest. 960 Specifications 962 The ECDSA URN used in this specification is "urn:ansi-org:ecdsa". 964 The ECDSA uses a canonical or surfce-string digest algorithm for 965 computation of the Manifest fingerprint. The DOM-HASH [RFC xxx2] is 966 recommended in this specification. 968 Signature Value Encoding: 970 The output of this algorithm consists of a pair of integers usually 971 referred by the pair (r, s). The signature value shall consist of the 972 concatenation of two octet-streams that respectively result from the 973 octet-encoding of the values r and s. Integer to octet-stream 974 conversion shall be done according to PKCS#1 [RFC 2437] specification 975 with a k parameter equals to 20. 977 Example 978 979 P.4 980 981 982 P.5 983 984 985 987 6. Examples 989 The following is an example signed IOTP message: 991 992 993 999 1000 1001 1002 1003 1004 1005 1006 1008 1009 1011 P.5 1012 1013 1015 P.3 1016 1017 1018 1019 1020 xsqsfasDys2h44u4ehJDe54he5j4dJYTJ 1021 1022 1023 1027 1028 1031 1032 1033 9dj28fjakA9sked0Ks01k2d7a0kgmf9dk19lf63kkDSs0 1034 1035 1036 1037 1040 1041 xsqsfasDys2h44u4ehJDe54he5j4dJYTJ= 1042 1043 1044 1045 1046 1050 1051 snroasdfnas934k 1052 1053 1054 1055 1057 7. Signature DTD 1059 1065 1066 1070 1076 1077 1081 1090 1094 1095 1101 1102 1106 1107 1112 1113 1117 1118 1125 1126 1130 1131 1134 1140 1144 1149 1150 1155 1160 1161 1166 1167 1172 8. Security Considerations 1174 This entire document concerns the IOTP v1 protocol signature element 1175 which is used for authentication. See the Security Considerations 1176 section of [RFC xxxx] "Internet Open Trading Protocol - IOTP, Version 1177 1.0". 1179 Full Copyright Statement 1181 Copyright (C) The Internet Society 1999. 1183 This document and translations of it may be copied and furnished to 1184 others, and derivative works that comment on or otherwise explain it 1185 or assist in its implementation may be prepared, copied, published 1186 and distributed, in whole or in part, without restriction of any 1187 kind, provided that the above copyright notice and this paragraph are 1188 included on all such copies and derivative works. However, this 1189 document itself may not be modified in any way, such as by removing 1190 the copyright notice or references to the Internet Society or other 1191 Internet organizations, except as needed for the purpose of 1192 developing Internet standards in which case the procedures for 1193 copyrights defined in the Internet Standards process must be 1194 followed, or as required to translate it into languages other than 1195 English. 1197 The limited permissions granted above are perpetual and will not be 1198 revoked by the Internet Society or its successors or assigns. 1200 This document and the information contained herein is provided on an 1201 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 1202 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 1203 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 1204 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 1205 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1207 References 1209 [DSA] - Federal Information Processing Standards Plublication FIPS 1210 PUB 186, "Digital Signature Standard(DSS)", 1994, 1211 1213 [IEEE P1363] - IEEE P1363, "Standard Specifications for Public-Key 1214 Cryptography", draft, 1997, 1216 [PV] - B. Preneel and P. van Oorschot, "Building fast MACs from hash 1217 functions", Advances in Cryptology -- CRYPTO'95 Proceedings, Lecture 1218 Notes in Computer Science, Springer-Verlag Vol.963, 1995, pp. 1-14. 1220 [RFC 1321] - R. Rivest, "The MD5 Message-Digest Algorithm", April 1221 1992. 1223 [RFC 2045]- N. Freed & N. Borenstein, "Multipurpose Internet Mail 1224 Extensions (MIME) Part One: Format of Internet Message Bodies", 1225 November 1996. 1227 [RFC 2046] - N. Freed & N. Borenstein, "Multipurpose Internet Mail 1228 Extensions (MIME) Part Two: Media Types", November 1996. 1230 [RFC 2104] - H. Krawczyk, M. Bellare, R. Canetti, "HMAC: Keyed- 1231 Hashing for Message Authentication", February 1997. 1233 [RFC 2141] - R. Moats, "URN Syntax", May 1997. 1235 [RFC 2253] - W. Wahl, S. Kille, T. Howes, "Lightweight Directory 1236 Access Protocol (v3): UTF-8 String Representation of Distinguished 1237 Names", December 1997. 1239 [RFC 2396] - T. Berners-Lee, R. Fielding, L. Masinter, "Uniform 1240 Resource Identifiers (URI): Generic Syntax", August 1998. 1242 [RFC 2437] - B. Kaliski, J. Staddon, "PKCS #1: RSA Cryptography 1243 Specifications, Version 2.0", October 1998. 1245 [RFC xxx1] - D. Burdett, "Interenet Open Trading Protocol - IOTP, 1246 Version 1.0", September 1999. (currently draft-ietf-trade-iotp-v1.0- 1247 protcool-*.txt) 1249 [RFC xxx2] - H. Maruyama, K. Tamura, & N. Uramot, "Digest Values for 1250 DOM (DOMHASH)", September 1999. (currently draft-ietf-trade-hiroshi- 1251 dom-hash-*.txt) 1253 [Schneier] - Bruce Schneier, "Applied Cryptography: Protocols, 1254 Algorithms, and Source Code in C", 1996, John Wiley and Sons 1256 [SHA1] - NIST FIPS PUB 180-1, "Secure Hash Standard," National 1257 Institute of Standards and Technology, U.S. Department of Commerce, 1258 April 1995. 1260 [X.509] - ITU-T Recommendation X.509 (1997 E), "Information 1261 Technology - Open Systems Interconnection - The Directory: 1262 Authentication Framework", June 1997. 1264 [X9.30] - ASC X9 Secretariat: American Bankers Association, "American 1265 National Standard for Financial Services - Public Key Cryptography 1266 Using Irreversible Algorithms for the Financial Services Industry - 1267 Part 1: The Digital Signature Algorithm(DSA)", 1995. 1269 [X9.62] - ASC X9 Secretariat: American Bankers Association,"American 1270 National Standard for Financial Services - Public Key Cryptography 1271 Using Irreversible Algorithms for the Financial Services Industry - 1272 The Elliptic Curve Digital Signature Algorithm (ECDSA)", draft, 1997. 1274 [XLink] - Eve Maler, Steve DeRose, "XML Linking Language (XLink)", 1275 1277 [XML] - Tim Bray, Jean Paoli, C. M. Sperber-McQueen, "Extensible 1278 Markup Language (XML) 1.0", 1281 Author's Addresses 1283 The authors of this document are: 1285 Kent M. Davidson 1286 Differential, Inc. 1287 440 Clyde Ave. 1288 Mountain View, CA 94043 USA 1289 email: kent@differential.com 1291 Yoshiaki Kawatsura 1292 Hitachi, Ltd. 1293 890-12 Kashimada Saiwai Kawasaki, 1294 Kanagawa 2118567 Japan 1295 email: kawatura@bisd.hitachi.co.jp 1297 Expiration and File Name 1299 This draft expires May 2000. 1301 Its file name is draft-ietf-trade-iotp-v1.0-dsig-05.txt.