TRADE Working Group Kent Davidson INTERNET-DRAFT Differential Expires: August 1999 February 1999 Digital Signatures for the Internet Open Trading Protocol ------- ---------- --- --- -------- ---- ------- -------- Status of This Document This draft, file name draft-ietf-trade-iotp-v1.0-dsig-00.txt, is an addendum to 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.'' To view the entire list of current Internet-Drafts, please check the "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow Directories on ftp.is.co.za (Africa), ftp.nordu.net (Northern Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au (Pacific Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu (US West Coast). 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). Kent Davidson [Page 1] INTERNET-DRAFT Digital Sigantures for IOTP February 1999 Table of Contents Status of This Document....................................1 Abstract...................................................1 Table of Contents..........................................2 1. Introduction............................................3 2. Objective and Requirements..............................3 3. Signature Basics........................................4 3.1 Signature Element......................................4 3.2 Digest Element.........................................4 3.3 Originator and Recipient Information Elements..........5 4. Detailed Signature Syntax...............................6 4.1 Uniform Resource Names.................................6 4.2 IOTPSignatures.........................................6 4.3 Signature Component....................................7 4.3.1 Signature............................................7 4.3.2 Manifest.............................................7 4.3.3 Algorithm............................................8 4.3.4 Digest...............................................9 4.3.5 Attributes..........................................10 4.3.6 Attribute...........................................10 4.3.7 OriginatorInfo......................................10 4.3.8 RecipientInfo.......................................11 4.3.9 Parameter...........................................12 4.4 Certificate Component.................................13 4.4.1 Certificate.........................................13 4.4.2 IssuerAndSerialNumber...............................13 4.5 Common Components.....................................14 4.5.1 Value...............................................14 4.5.2 Locator.............................................15 5. Supported Algorithms...................................15 5.1 Digest Algorithms.....................................15 5.1.1 DOM-HASH............................................16 5.1.2 SHA1................................................16 5.1.3 MD5.................................................16 5.2 Signature Algorithms..................................16 5.2.1 DSA.................................................17 5.2.2 HMAC................................................17 5.2.3 RSA.................................................17 6. Examples...............................................17 7. Signature DTD..........................................19 8. References.............................................21 9. Credits................................................22 Expiration and File Name..................................22 Kent Davidson [Page 2] INTERNET-DRAFT Digital Sigantures for IOTP February 1999 1. Introduction The Internet Open Trading Protocol (IOTP) provides a payment system independent interoperable framework for Internet commerce as documented in draft-ietf-trade-iotp-v1.0-protocol-*.txt. 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. 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 just 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 Verion 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 a signed portions of IOTP message to be "forwarded" to another trading roles with different signature algorithms than the original recipient Kent Davidson [Page 3] INTERNET-DRAFT Digital Sigantures for IOTP February 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 information block) Kent Davidson [Page 4] INTERNET-DRAFT Digital Sigantures for IOTP February 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 providing 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. Kent Davidson [Page 5] INTERNET-DRAFT Digital Sigantures for IOTP February 1999 The Algorithm element is a generalised place to place 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 referencing the entire Signature element from a Resource element when implementing endorsement. Kent Davidson [Page 6] INTERNET-DRAFT Digital Sigantures for IOTP February 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. 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 block. Attributes Description ID: Element identifier that may be used to referencing 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. Kent Davidson [Page 7] INTERNET-DRAFT Digital Sigantures for IOTP February 1999 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. Attributes: 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: 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 Kent Davidson [Page 12] INTERNET-DRAFT Digital Sigantures for IOTP February 1999 type: The type of the parameter expressed as a free form string, whose value is specified on a per algorithm basis. 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 type: Type of the digital certificate. This attribute is specified as a Universal Resource Name, as indicated in the "Supported Algorithms" section. 4.4.2 IssuerAndSerialNumber The IssuerAndSerialNumber element identifies a certificate, and thereby an entity and a public key, by the name of the certificate Kent Davidson [Page 13] INTERNET-DRAFT Digital Sigantures for IOTP February 1999 issuer and an issuer-specific certificate identification. Attributes Description issuer: Name of the issuing certification authority. 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 CDATA section or XML escaping. base64: The content has been encoded by means of the base64 encoding scheme. Kent Davidson [Page 14] INTERNET-DRAFT Digital Sigantures for IOTP February 1999 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 DOM- HASH, SHA1, MD5, DSA, and HMAC algorithms to provide a compliant implementation of IOTP 1.0. 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. Changes in the surface string of a given content affect directly the value of the digest being produced. Canonical digest algorithms 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. Kent Davidson [Page 15] INTERNET-DRAFT Digital Sigantures for IOTP February 1999 5.1.1 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. The DOM-HASH algorithm requires a single parameter, which shall consist of a surface string digest algorithm such as SHA1. The DOM-HASH URN used for this specification is "urn:ibm:dom-hash". Example 5.1.2 SHA1 Surface string digest algorithm designed by hte US government for use with the Digital Signature Standard. This algorithm produces a 160- bit hash value. This algorithm does not require any parameter. The SHA1 URN used for this specification is "urn:fips:sha1". 5.1.3 MD5 The MD5 Algorithm was invented by RSA Data Securities and is similar to its predecessors, MD2 and MD4, but faster and simpler than MD2 while stronger than MD4. [RFC 1321] The MD5 Algorithm takes no parameters. The MD5 URN used for this specification is "urn:rsa:md5". 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 DSA and message authentication codes such as HMAC [RFC 2104]. Kent Davidson [Page 16] INTERNET-DRAFT Digital Sigantures for IOTP February 1999 5.2.1 DSA TODO The DSA URN used in this specification is "urn:fips:dsa". 5.2.2 HMAC Generalities [RFC 2104] TODO The HMAC URN used in this specification is is "urn:ibm:hmac". 5.2.3 RSA TODO The RSA URN used in this specification is "urn:rsa:rsa". 6. Examples The following is an example signed IOTP message: Kent Davidson [Page 17] INTERNET-DRAFT Digital Sigantures for IOTP February 1999 S.1 S.1 xsqsfasDys2h44u4ehJDe54he5j4dJYTJ= ked0Ks01k2d7a0kgmf9dk19lf63kkDSs0= 9dj28fjakA9sked0Ks01k2d7a0kgmf9dk19lf63kkDSs0= Kent Davidson [Page 18] INTERNET-DRAFT Digital Sigantures for IOTP February 1999 7. Signature DTD Kent Davidson [Page 19] INTERNET-DRAFT Digital Sigantures for IOTP February 1999 Kent Davidson [Page 20] INTERNET-DRAFT Digital Sigantures for IOTP February 1999 8. References [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 2396] - T. Berners-Lee, R. Fielding, L. Masinter, "Uniform Resource Identifiers (URI): Generic Syntax", August 1998. [Schneier] - Bruce Schneier, "Applied Cryptography: Protocols, Algorithms, and Source Code in C", 1996, John Wiley and Sons [XLink] - Eve Maler, Steve DeRose, "XML Linking Language (XLink)", [XML] - Tim Bray, Jean Paoli, C. M. Sperber-McQueen, "Extensible Markup Language (XML) 1.0", Kent Davidson [Page 21] INTERNET-DRAFT Digital Sigantures for IOTP February 1999 9. Credits This document is based on work originally done on general XML digital signatures by Richard Brown at GlobeSet, Inc. but has been narrowed and changed. The editor of this document is: Kent M. Davidson Differential, Inc. 10054 Pasadena Ave. Cupertino, CA 95014 USA email: kent@differential.com Contributors to the design of the IOTP DTD include, in alphabetic order: David Burdett, Mondex Andrew Drapp, Hitachi Donald Eastlake 3rd, IBM Yoshiaki Kawatsura, Hitachi Expiration and File Name This draft expires August 1999. Its file name is draft-ietf-trade-iotp-v1.0-dsig-00.txt. Kent Davidson [Page 22]