TRADE Working Group Kent Davidson INTERNET-DRAFT Differential Yoshiaki Kawatsura Hitachi Expires: May 2000 November 1999 draft-ietf-trade-iotp-v1.0-dsig-05.txt Digital Signatures for the v1.0 Internet Open Trading Protocol (IOTP) ------- ---------- --- --- ---- -------- ---- ------- -------- ------ Status of This Document This draft, file name draft-ietf-trade-iotp-v1.0-dsig-05.txt, is a part of the Internet Open Trading Protocol Specification version 1.0, and is intended to become an Informational RFC. Distribution of this document is unlimited. Comments should be sent to the TRADE working group mailing list . This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months. Internet-Drafts may be updated, replaced, or obsoleted by other documents at any time. It is not appropriate to use Internet- Drafts as reference material or to cite them other than as a ``working draft'' or ``work in progress.'' The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Abstract A syntax and procedures are described for the computation and verification of digital signatures for use within Version 1.0 of the Internet Open Trading Protocol (IOTP). [Changes from previous draft: correction of one line in DTD, move acknowledgement to the front.] K. Davidson, Y. Kawatsura [Page 1] INTERNET-DRAFT Digital Signatures for IOTP November 1999 Copyright Copyright (C) 1999. The Internet Society. All Rights Reserved. Acknowledgement This document is based on work originally done on general XML digital signatures by Richard Brown of GlobeSet, Inc. Other contributors to the design of the IOTP DSIG DTD include, in alphabetic order: David Burdett, Commerce One Andrew Drapp, Hitachi Donald Eastlake 3rd, IBM Table of Contents Status of This Document....................................1 Abstract...................................................1 Copyright..................................................2 Acknowledgement............................................2 Table of Contents..........................................2 1. Introduction............................................4 2. Objective and Requirements..............................5 3. Signature Basics........................................6 3.1 Signature Element......................................6 3.2 Digest Element.........................................6 3.3 Originator and Recipient Information Elements..........7 3.4 Algorithm Element......................................8 4. Detailed Signature Syntax...............................8 4.1 Uniform Resource Names.................................8 4.2 IotpSignatures.........................................8 4.3 Signature Component....................................9 4.3.1 Signature............................................9 4.3.2 Manifest............................................10 4.3.3 Algorithm...........................................11 4.3.4 Digest..............................................11 4.3.5 Attribute...........................................12 K. Davidson, Y. Kawatsura [Page 2] INTERNET-DRAFT Digital Signatures for IOTP November 1999 4.3.6 OriginatorInfo......................................13 4.3.7 RecipientInfo.......................................13 4.3.8 KeyIdentifier.......................................14 4.3.9 Parameter...........................................15 4.4 Certificate Component.................................16 4.4.1 Certificate.........................................16 4.4.2 IssuerAndSerialNumber...............................17 4.5 Common Components.....................................17 4.5.1 Value...............................................17 4.5.2 Locator.............................................18 5. Supported Algorithms...................................18 5.1 Digest Algorithms.....................................18 5.1.1 SHA1................................................19 5.1.2 DOM-HASH............................................19 5.2 Signature Algorithms..................................20 5.2.1 DSA.................................................20 5.2.2 HMAC................................................21 5.2.3 RSA.................................................22 5.2.4 ECDSA...............................................23 6. Examples...............................................24 7. Signature DTD..........................................25 8. Security Considerations................................28 Full Copyright Statement..................................28 References................................................29 Author's Addresses........................................31 Expiration and File Name..................................31 K. Davidson, Y. Kawatsura [Page 3] INTERNET-DRAFT Digital Signatures for IOTP November 1999 1. Introduction The Internet Open Trading Protocol (IOTP) provides a payment system independent interoperable framework for Internet commerce as documented in [RFC xxx1]. All IOTP messages are XML documents. XML, the Extensible Markup Language [XML], is a syntactical standard promulgated by the World Wide Web Consortium. XML is intended primarily for structuring data exchanged and served over the World Wide Web. Although IOTP assumes that any payment system used with it provides its own security, there are numerous cases where IOTP requires authentication and integrity services for portions of the XML messages it specifies. K. Davidson, Y. Kawatsura [Page 4] INTERNET-DRAFT Digital Signatures for IOTP November 1999 2. Objective and Requirements This document covers how digital signatures may be used with XML documents to provide authentication and tamper-proof protocol messages specifically for Version 1.0 of the IOTP protocol. The reader should recognize that an effort towards general XML digital signatures exists but is unlikely to produce its final result in time for IOTP Version 1.0. Future versions of IOTP will probably adopt by reference the results of this general XML digital signature effort. The objective of this document is to propose syntax and procedures for the computation and verification of digital signatures applicable to Version 1.0 IOTP protocol messages, providing for: -- Authentication of IOTP transactions -- Provide a means by which an IOTP message may be made "tamper- proof", or detection of tampering is made evident -- Describe a set of available digest and signature algorithms at least one of which is mandatory to implement for interoperability -- Easily integrate within the IOTP 1.0 Specification -- Provide lightweight signatures with minimal redundancy -- Allow signed portions of IOTP message to be "forwarded" to another trading roles with different signature algorithms than the original recipient K. Davidson, Y. Kawatsura [Page 5] INTERNET-DRAFT Digital Signatures for IOTP November 1999 3. Signature Basics 3.1 Signature Element This specification consists primarily of the definition of an XML element known as the Signature element. This element consists of two sub-elements. The first one is a set of authenticated attributes, known as the signature Manifest, which comprises such things as a unique reference to the resources being authenticated and an indication of the keying material and algorithms being used. The second sub-element consists of the digital signature value. (resource information block) (originator information block) (recipient information block) (other attributes) (signature algorithms information block) (encoded signature value) The digital signature is not computed directly from the pieces of information to be authenticated. Instead, the digital signature is computed from a set of authenticated attributes (the Manifest), which include references to, and a digests of, those pieces of information. The authentication is therefore "indirect". 3.2 Digest Element The Digest element consists of a unique and unambiguous reference to the XML resources being authenticated. It is constructed of a locator and the digest value data itself. The Digest algorithm is referred to indirectly via a DigestAlgorithmRef, so that Digest algorithms may be shared by multiple resources. (Digest value) K. Davidson, Y. Kawatsura [Page 6] INTERNET-DRAFT Digital Signatures for IOTP November 1999 The resource locator is implemented as a simple XML Link [XLink]. This not only provides a unique addressing scheme for internal and external resources, but also facilitates authentication of composite documents. 3.3 Originator and Recipient Information Elements The purpose of the Originator and Recipient information elements is to provide identification and keying material for these respective parties. (identification information block) (keying material information block) (identification information block) (keying material information block) The actual content of these two elements depends on the authentication scheme being used and the existence or non-existence of a prior relationship between the parties. In some circumstances, it may be quite difficult to distinguish between identification and keying material information. A unique reference to a digital certificate provides for both. This may also stand true for an account number when a prior relationship exists between the parties. The Originator information element is mandatory. Depending on the existence or non-existence of a prior relationship with the recipient, this block either refers to a public credential such as a digital certificate or displays a unique identifier known by the recipient. The Recipient information element may be used when a document contains multiple signature information blocks, each being intended for a particular recipient. A unique reference in the Recipient information block helps the recipients identify their respective Signature information block. The Recipient information element may also be used when determination of the authentication key consists of a combination of keying material provided by both parties. This would be the case, for example, when establishing a key by means of Diffie Hellman [Schneier] Key Exchange algorithm. K. Davidson, Y. Kawatsura [Page 7] INTERNET-DRAFT Digital Signatures for IOTP November 1999 3.4 Algorithm Element The Algorithm element is a generalised place to put any type of algorithm used within the signed IOTP message. The Algorithm may be a Signature algorithm or a Digest algorithm. Each algorithm contains parameters specific to the algorithm used. (algorithm information block) Algorithms are required to contain an ID which allows for indirect reference to them from other places in the XML signature. 4. Detailed Signature Syntax 4.1 Uniform Resource Names To prevent potential name conflicts in the definition of the numerous type qualifiers considered herein, this specification uses Uniform Resource Names [RFC 2141]. 4.2 IotpSignatures The IotpSignatures element is the top-level element in an IOTP signature block. It consists of a collection of Signature elements, and an optional set of Certificates. Content Description Signature: A collection of Signature elements. Certificate: Zero or more certificates used for signing Attributes Description ID: Element identifier that may be used to reference the entire Signature element from a Resource element when implementing endorsement. K. Davidson, Y. Kawatsura [Page 8] INTERNET-DRAFT Digital Signatures for IOTP November 1999 4.3 Signature Component 4.3.1 Signature The Signature element constitutes the majority of this specification. It is comprised of two sub-elements. The first one is a set of attributes, known as the Manifest, which actually constitutes the authenticated part of the document. The second sub-element consists of the signature value or values. The Value element contained within the Signature element is the encoded form of the signature of the Manifest element, and thus provides the verification of the Manifest. The process for generating the signed value is a multi-step process, involving a canonicalization algorithm, a digest algorithm, and a signature algorithm. First, the Manifest is canonicalized with an algorithm specified within the Algorithm element of the Manifest. The canonicalized form removes any inconsistencies in white space introduced by XML parsing engines. This canonicalized form is then converted into a digest form which uniquely identifies the canonicalized document. Any slight modification in the original document will result in a very different digest value. Finally, the digest is then signed using a public/symmetric key algorithm which digitally stamps the digest (with the certificate of the signer if available). The final signed digest is the value which is stored within the Signature's Value element. Content Description Manifest: A set of attributes that actually constitutes the authenticated part of the document. Value: One or more encodings of signature values. Multiple values allow for a multiple algorithms to be supported within a single signature component. Attributes Description K. Davidson, Y. Kawatsura [Page 9] INTERNET-DRAFT Digital Signatures for IOTP November 1999 ID: Element identifier that may be used to reference the Signature element from a Resource element when implementing endorsement. 4.3.2 Manifest The Manifest element consists of a collection of attributes that specify such things as as references to the resources being authenticated and an indication of the keying material and algorithms to be used. Content Description Algorithm: A list of algorithms used for signing, digest computation, and canonicalization. Digest: A list of digests of resources to be authentication and signed. Attribute: Optional element that consists of a collection of complementary attributes to be authenticated. OriginatorInfo: Element that provides identification and keying material information related to the originator. RecipientInfo: Optional element that provides identification and keying material information related to the recipient. Attributes Description LocatorHrefBase: The LocatorHrefBase provides a similar construct to the HTML HREFBASE attribute and implicitly sets all relative URL references within the Manifest to be relative to the HrefBase. For example, the IOTP Manifest may contain: And subsequent Locators may be: K. Davidson, Y. Kawatsura [Page 10] INTERNET-DRAFT Digital Signatures for IOTP November 1999 An implementation should concatenate the two locator references with "#" to create the entire URL. See definition of the Locator attribute on the Digest element for more detail. 4.3.3 Algorithm This specification uses an Algorithm data type which indicates many different types of algoirithms. The Algorithm element allows for specification of sub-algorithms as parameters of the primary algorithm. This is performed via a parameter within the algorithm that provides a reference to another Algorithm. An example of this is shown in the Parameter section. Content Description Parameter: The contents of an Algorithm element consists of an optional collection of Parameter elements which are specified on a per algorithm basis. Attributes Description ID: The ID of the algorithm is used by the Digest and RecipientInfo to refer to the signing or digest algorithm used. type: The type of algorithm, either a digest or signature. This is implied by the element to which the algorithm is referred. That is, if the DigestAlgorithmRef refers to an algorithm, it is implicit by reference that the targetted algorithm is a digest. name: The type of the algorithm expressed as a Uniform Resource Name. 4.3.4 Digest The Digest element consists of the fingerprint of a given resource. This element is constructed of two sub-elements. This first one indicates the algorithm to be used for computation of the fingerprint. The second element consists of the fingerprint value. K. Davidson, Y. Kawatsura [Page 11] INTERNET-DRAFT Digital Signatures for IOTP November 1999 Content Description Locator: Contains a "HREF" or URL Locator for the resources to be fingerprinted. For use within IOTP a "scheme" with the value "iotp" may be used with the following structure: 'iotp:#'. This should be interpreted as referring to an element with an ID attribute that matches in any IOTP Message that has a TransRefBlk Block with an IotpTransId that matches . If the LocatorHrefBase attribute is set on the Manifest element of which this Digest element is a child, then concatenate the value of the LocatorHrefBase attribute with the value of the Locator attribute before identifying the element that is being referred to. If the LocatorHrefBase attribute is omitted, should be interpreted as the currebt IotpTransId, which is included in the IOTP message which contains the Manifest component. Value: Encoding of the fingerprint value. Attributes Description DigestAlgorithmRef: ID Reference of algorithm used for computation of the digest. 4.3.5 Attribute The Attribute element consists of a complementary piece of information, which shall be included in the authenticated part of the document. This element has been defined primarily for enabling some level of customization in the signature element. This is the area where a specific IOTP implementation may include custom attributes which must be authenticated directly. An Attribute element consists of a value, a type, and a criticality. At this time, no IOTP specific attributes are specified. K. Davidson, Y. Kawatsura [Page 12] INTERNET-DRAFT Digital Signatures for IOTP November 1999 Content Description ANY: The actual value of an attribute depends solely upon its type. Attributes Description type: Type of the attribute. critical: Boolean value that indicates if the attribute is critical (true) or not (false). A recipient shall reject a signature that contains a critical attribute that he does not recognise. However, an unrecognised non-critical attribute may be ignored. 4.3.6 OriginatorInfo The OriginatorInfo element is used for providing identification and keying material information for the originator. Content Description ANY: Identification and keying material information may consist of ANY construct. Such a definition allows the adoption of application-specific schemes. Attributes Description OriginatorRef: A reference to the IOTP Org ID of the originating signer. 4.3.7 RecipientInfo The RecipientInfo element is used for providing identification and keying material information for the recipient. This element is used K. Davidson, Y. Kawatsura [Page 13] INTERNET-DRAFT Digital Signatures for IOTP November 1999 either for enabling recognition of a Signature element by a given recipient or when determination of the authentication key consists of the combination of keying material provided by both the recipient and the originator. The RecipientInfo attributes provide a centralized location where signatures, algorithms, and certificates intended for a particular recipient are specified. The signature certificate reference ID MUST point to a certificate object. Content Description ANY: Identification and keying material information may consist of ANY construct. Attributes Description SignatureAlgorithmRef: A reference to the signature algorithm used to sign the SignatureValueRef intended for this recipient. The signature algorithm reference ID MUST point to a signature algorithm within the Manifest. SignatureValueRef: A reference to the signature value for this recipient. The signature value reference ID MUST point to a value structure directly included within a Manifest. This reference can be omitted if the application can specify the digest value. SignatureCertRef: A reference to the certificate used to sign the Value pointed to by the SignatureValueRef. This reference can be omitted if the application can identify the certificate. RecipientRefs: A list of references to the IOTP Org ID of the recipients this signature is intended for. 4.3.8 KeyIdentifier The key identifier element can identify the shared public/symmetric key identification between parties that benefit from a prior K. Davidson, Y. Kawatsura [Page 14] INTERNET-DRAFT Digital Signatures for IOTP November 1999 relationship. This element can be included in the ReceipientInfo Element. 4.3.9 Parameter A Parameter element provides the value of a particular algorithm parameter, whose name and format have been specified for the algorithm considered. For IOTP 1.0, the following parameter type is standardized: "AlgorithmRef". An AlgorithmRef contains an ID of a "sub-Algorithm" used when computing a sequence of algorithms. For example, a signature algorithm actually signs a digest algorithm. To specify a chain of algorithms used to compute a signature, AlgorithmRef parameter types are used in the following manner: A2 A1 Content Description ANY: The contents of a Parameter element consists of ANY valid construct, which is specified on a per algorithm per parameter basis. Attributes Description type: The type of the parameter expressed as a free form string, whose value is specified on a per algorithm basis. K. Davidson, Y. Kawatsura [Page 15] INTERNET-DRAFT Digital Signatures for IOTP November 1999 4.4 Certificate Component 4.4.1 Certificate The Certificate element may be used for either providing the value of a digital certificate or specifying a location from where it may be retrieved. Content Description IssuerAndSerialNumber: Unique identifier of this certificate. This element has been made mandatory is order to prevent unnecessary decoding during validation of a certificate chain. This feature also helps certificates caching, especially when the value is not directly provided. Value: Encoding of the certificate value. The actual value to be encoded depends upon the type of the certificate. Locator: XML link element that could be used for retrieving a copy of the digital certificate. The actual value being returned by means of this locator depends upon the security protocol being used. Attributes Description ID: Element identifier that may be used to reference the Cerfiticate element from a RecipientInfo element. type: Type of the digital certificate. This attribute is specified as a Universal Resource Name. Support for the X.509 version 3 certificate [X.509] is mandatory in this sepecification if the Certificate element is used. The URN for such certificates is "urn:X500:X509v3". K. Davidson, Y. Kawatsura [Page 16] INTERNET-DRAFT Digital Signatures for IOTP November 1999 4.4.2 IssuerAndSerialNumber The IssuerAndSerialNumber element identifies a certificate, and thereby an entity and a public key, by the name of the certificate issuer and an issuer-specific certificate identification. Attributes Description issuer: Name of the issuing certification authority. See [RFC 2253] for RECOMMENDED syntax. number: Issuer-specific certificate identification. 4.5 Common Components 4.5.1 Value A value contains the "raw" data of a signature or digest algorithm, usually in a base-64 encoded form. See [RFC 2045] for algorithm used to base-64 encode data. Content Description PCDATA: Content value after adequate encoding. Attributes Description encoding: This attribute specifies the decoding scheme to be employed for recovering the original byte stream from the content of the element. This document recognises the following two schemes: none: the content has not been subject to any particular encoding. This does not preclude however the use of native XML encoding such as K. Davidson, Y. Kawatsura [Page 17] INTERNET-DRAFT Digital Signatures for IOTP November 1999 CDATA section or XML escaping. base64: The content has been encoded by means of the base64 encoding scheme. 4.5.2 Locator The Locator element consists of simple XML link [XLink]. This element allows unambiguous reference to a resource or fragment of a resource. Attributes Description xml:link: Required XML link attribute that specifies the nature of the link (simple in this case). href: Locator value that may contains either a URI [RFC 2396], a fragment identifier, or both. 5. Supported Algorithms The IOTP specification 1.0 requires the implementation of the DSA, DOM-HASH, SHA1, HMAC algorithms. Implementation of RSA is also recommended. 5.1 Digest Algorithms This specification contemplates two types of digest algorithms, both of which provide a digest string as a result: Surface string digest algorithms These algorithms do not have any particular knowledge about the content being digested and operate on the raw content value. Any changes in the surface string of a given content affect directly the value of the digest being produced. Canonical digest algorithms K. Davidson, Y. Kawatsura [Page 18] INTERNET-DRAFT Digital Signatures for IOTP November 1999 These algorithms have been tailored for a particular content type and produce a digest value that depends upon the core semantics of such content. Changes limited to the surface string of a given content do not affect the value of the digest being produced unless they affect the core semantic. 5.1.1 SHA1 Surface string digest algorithm designed by NIST and NSA for use with the Digital Signature Standard. This algorithm produces a 160-bit hash value. This algorithm is documented in NIST FIPS Publication 180-1 [SHA1]. This algorithm does not require any parameter. The SHA1 URN used for this specification is "urn:nist-gov:sha1". 5.1.2 DOM-HASH XML canonical digest algorithm proposed by IBM Tokyo Research Laboratory. This algorithm operates on the DOM representation of the document and provides an unambiguous means for recursive computation of the hash value of the nodes that constitute the DOM tree [RFC xxx2]. This algorithm has many applications such as computation of digital signature and synchronization of DOM trees. However, because the hash value of an element is computed from the hash values of the inner elements, this algorithm is better adapted to small documents that do not require one-pass processing. As of today, this algorithm is limited to the contents of an XML document and, therefore, does not provide for authentication of the internal or external subset of the DTD. The DOM-HASH algorithm requires a single parameter, which shall include a surface string digest algorithm such as SHA1. The DOM-HASH URN used for this specification is "urn:ibm-com:dom- hash". The DOM-HASH uses a surface-string digest algorithm for computation of a fingerprint. The SHA1 is recommended in this specification. Example K. Davidson, Y. Kawatsura [Page 19] INTERNET-DRAFT Digital Signatures for IOTP November 1999 P.3 5.2 Signature Algorithms This specification uses the terminology of 'digital signature' for qualifying indifferently digital signature and message authentication codes. Thus, the signature algorithms contemplated herein include public key digital signature algorithms such as ECDSA and message authentication codes such as HMAC [RFC 2104]. 5.2.1 DSA Public-key signature algorithm proposed by NIST for use with the Digital Signature Standard. This standard is documented in NIST FIPS Publication 186 [DSS] and ANSI X9.30 [X9.30]. The DSA algorithm requires a single parameter, which includes the canonical digest algorithm to be used for computing the fingerprint of the signature Manifest. The DSA URN used in this specification is "urn:nist-gov:dsa". The DSA uses a canonical or surfce-string digest algorithm for computation of the Manifest fingerprint. The DOM-HASH is recommended in this specification. Signature Value Encoding: The output of this algorithm consists of a pair of integers usually referred by the pair (r, s). The signature value shall consist of the concatenation of two octet-streams that respectively result from the octet-encoding of the values r and s. Integer to octet-stream conversion shall be done according to PKCS#1 [RFC 2437] specification with a k parameter equals to 20. Example P.4 P.5 K. Davidson, Y. Kawatsura [Page 20] INTERNET-DRAFT Digital Signatures for IOTP November 1999 5.2.2 HMAC Message Authentication Code proposed by H. Krawczyk et al. and documented in [RFC 2104]. This specification adopts a scheme that differs a bit from the common usage of this algorithm -- computation of the MAC is performed on the hash of the contents being authenticated instead of the actual contents. Thence, the actual signature value output by the algorithm might be depicted as follows: SignatureValue = HMAC( SecretKey, H(Manifest)) This specification also considered HMAC output truncation such as proposed by Preneel and van Oorschot. In their paper [PV] these two researchers have shown some analytical advantages of truncating the output of hash-based MAC functions. Such output truncation is also considered in the RFC document. HMAC requires three parameters. The first one consists of a canonical digest algorithm. The second one consists of a hash function. The last one is optional and specifies the length in bit of the truncated output. If this last parameter is absent, no truncation shall occur. The HMAC URN used in this specification is "urn:ietf-org:hmac". Canonical digest algorithm: Canonical or surface-string digest algorithm is to be used for computation of the Manifest fingerprint. The type of this parameter is set to "AlgorithmRef". The recommended value of this Parameter should be the ID reference for the Algorithm element DOM-HASH. Hash-function: Hash function is to be used to compute the MAC value from the secret key and the fingerprint of the signature Manifest. The type of this parameter is set to "HashAlgorithmRef" and the value of this parameter should be set to the ID reference for the Algorithm element of SHA1. Output-length: Length in bits of the truncated MAC value. The type of this parameter is set to "KeyLength" and the value of this parameter is set the length in bits of the truncated MAC value. Signature Value Encoding: The output of this algorithm can be assumed as a large integer value. The signature value shall consist of the octet-encoded value of this integer. Integer to octet-stream conversion shall be done according to PKCS#1 [RFC 2437] specification with a k parameter equals to ((Hlen +7) mod8), Mlen being the length in bits of the MAC value. K. Davidson, Y. Kawatsura [Page 21] INTERNET-DRAFT Digital Signatures for IOTP November 1999 Example P.4 P.5 128 P.5 5.2.3 RSA Public-key signature algorithm proposed by RSA Laboratories and documented in PKCS#1 [RFC 2437]. This specification adopts the RSA encryption algorithm with padding block type 01. For computing the signature value, the signer shall first digest the signature Manifest and then encrypt the resulting digest with his private key. This signature algorithm requires a single parameter, which consists of the canonical digest algorithm to be used for computing the fingerprint of the signature Manifest. Specifications The RSA URN used in this specification is "urn:rsasdi-com:rsa- encription". The RSA uses a canonical or surfce-string digest algorithm for computation of the Manifest fingerprint. The DOM-HASH is recommended in this specification. Signature Value Encoding: The output of this algorithm consists of single octet-stream. No further encoding is required. Example P.4 P.5 K. Davidson, Y. Kawatsura [Page 22] INTERNET-DRAFT Digital Signatures for IOTP November 1999 5.2.4 ECDSA Public-key signature algorithm proposed independently by Neil Koblitz and Victor Miller. This algorithm is being proposed as an ANSI standard and is documented in ANSI X9.62 standard proposal [X9.62] and IEEE/P1363 standard draft proposal [IEEE P1363]. The ECDSA algorithm requires a single parameter, which consists of the canonical digest algorithm to be used for computing the fingerprint of the signature Manifest. Specifications The ECDSA URN used in this specification is "urn:ansi-org:ecdsa". The ECDSA uses a canonical or surfce-string digest algorithm for computation of the Manifest fingerprint. The DOM-HASH [RFC xxx2] is recommended in this specification. Signature Value Encoding: The output of this algorithm consists of a pair of integers usually referred by the pair (r, s). The signature value shall consist of the concatenation of two octet-streams that respectively result from the octet-encoding of the values r and s. Integer to octet-stream conversion shall be done according to PKCS#1 [RFC 2437] specification with a k parameter equals to 20. Example P.4 P.5 K. Davidson, Y. Kawatsura [Page 23] INTERNET-DRAFT Digital Signatures for IOTP November 1999 6. Examples The following is an example signed IOTP message: P.5 P.3 xsqsfasDys2h44u4ehJDe54he5j4dJYTJ 9dj28fjakA9sked0Ks01k2d7a0kgmf9dk19lf63kkDSs0 K. Davidson, Y. Kawatsura [Page 24] INTERNET-DRAFT Digital Signatures for IOTP November 1999 xsqsfasDys2h44u4ehJDe54he5j4dJYTJ= snroasdfnas934k 7. Signature DTD K. Davidson, Y. Kawatsura [Page 26] INTERNET-DRAFT Digital Signatures for IOTP November 1999 K. Davidson, Y. Kawatsura [Page 27] INTERNET-DRAFT Digital Signatures for IOTP November 1999 8. Security Considerations This entire document concerns the IOTP v1 protocol signature element which is used for authentication. See the Security Considerations section of [RFC xxxx] "Internet Open Trading Protocol - IOTP, Version 1.0". Full Copyright Statement Copyright (C) The Internet Society 1999. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. K. Davidson, Y. Kawatsura [Page 28] INTERNET-DRAFT Digital Signatures for IOTP November 1999 References [DSA] - Federal Information Processing Standards Plublication FIPS PUB 186, "Digital Signature Standard(DSS)", 1994, [IEEE P1363] - IEEE P1363, "Standard Specifications for Public-Key Cryptography", draft, 1997, [PV] - B. Preneel and P. van Oorschot, "Building fast MACs from hash functions", Advances in Cryptology -- CRYPTO'95 Proceedings, Lecture Notes in Computer Science, Springer-Verlag Vol.963, 1995, pp. 1-14. [RFC 1321] - R. Rivest, "The MD5 Message-Digest Algorithm", April 1992. [RFC 2045]- N. Freed & N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies", November 1996. [RFC 2046] - N. Freed & N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types", November 1996. [RFC 2104] - H. Krawczyk, M. Bellare, R. Canetti, "HMAC: Keyed- Hashing for Message Authentication", February 1997. [RFC 2141] - R. Moats, "URN Syntax", May 1997. [RFC 2253] - W. Wahl, S. Kille, T. Howes, "Lightweight Directory Access Protocol (v3): UTF-8 String Representation of Distinguished Names", December 1997. [RFC 2396] - T. Berners-Lee, R. Fielding, L. Masinter, "Uniform Resource Identifiers (URI): Generic Syntax", August 1998. [RFC 2437] - B. Kaliski, J. Staddon, "PKCS #1: RSA Cryptography Specifications, Version 2.0", October 1998. [RFC xxx1] - D. Burdett, "Interenet Open Trading Protocol - IOTP, Version 1.0", September 1999. (currently draft-ietf-trade-iotp-v1.0- protcool-*.txt) [RFC xxx2] - H. Maruyama, K. Tamura, & N. Uramot, "Digest Values for DOM (DOMHASH)", September 1999. (currently draft-ietf-trade-hiroshi- dom-hash-*.txt) [Schneier] - Bruce Schneier, "Applied Cryptography: Protocols, Algorithms, and Source Code in C", 1996, John Wiley and Sons [SHA1] - NIST FIPS PUB 180-1, "Secure Hash Standard," National K. Davidson, Y. Kawatsura [Page 29] INTERNET-DRAFT Digital Signatures for IOTP November 1999 Institute of Standards and Technology, U.S. Department of Commerce, April 1995. [X.509] - ITU-T Recommendation X.509 (1997 E), "Information Technology - Open Systems Interconnection - The Directory: Authentication Framework", June 1997. [X9.30] - ASC X9 Secretariat: American Bankers Association, "American National Standard for Financial Services - Public Key Cryptography Using Irreversible Algorithms for the Financial Services Industry - Part 1: The Digital Signature Algorithm(DSA)", 1995. [X9.62] - ASC X9 Secretariat: American Bankers Association,"American National Standard for Financial Services - Public Key Cryptography Using Irreversible Algorithms for the Financial Services Industry - The Elliptic Curve Digital Signature Algorithm (ECDSA)", draft, 1997. [XLink] - Eve Maler, Steve DeRose, "XML Linking Language (XLink)", [XML] - Tim Bray, Jean Paoli, C. M. Sperber-McQueen, "Extensible Markup Language (XML) 1.0", K. Davidson, Y. Kawatsura [Page 30] INTERNET-DRAFT Digital Signatures for IOTP November 1999 Author's Addresses The authors of this document are: Kent M. Davidson Differential, Inc. 440 Clyde Ave. Mountain View, CA 94043 USA email: kent@differential.com Yoshiaki Kawatsura Hitachi, Ltd. 890-12 Kashimada Saiwai Kawasaki, Kanagawa 2118567 Japan email: kawatura@bisd.hitachi.co.jp Expiration and File Name This draft expires May 2000. Its file name is draft-ietf-trade-iotp-v1.0-dsig-05.txt. K. Davidson, Y. Kawatsura [Page 31]