Subject: current state of IOTP Digital Signature Draft

From: "Donald E. Eastlake 3rd" <[email-masked]>
Date: Wed, 30 Jun 1999 08:44:58 -0400

The current state of the IOTP Digital Signature draft is attached.

Donald

TRADE Working Group                                        Kent Davidson
INTERNET-DRAFT                                              Differential
Expires: December 1999                                         June 1999

       Digital Signatures for the Internet Open Trading Protocol
       ------- ---------- --- --- -------- ---- ------- --------

Status of This Document

   This draft, file name draft-ietf-trade-iotp-v1.0-dsig-01.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 <[email-masked]>.

   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 as listed 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).

Kent Davidson                                                   [Page 1]


INTERNET-DRAFT        Digital Signatures for IOTP              June 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
      3.4 Algorithm Element......................................6
      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.............................................8
      4.3.3 Algorithm............................................9
      4.3.4 Digest..............................................10
      4.3.5 Attribute...........................................10
      4.3.6 OriginatorInfo......................................11
      4.3.7 RecipientInfo.......................................11
      4.3.8 Parameter...........................................12
      4.4 Certificate Component.................................13
      4.4.1 Certificate.........................................13
      4.4.2 IssuerAndSerialNumber...............................14
      4.5 Common Components.....................................15
      4.5.1 Value...............................................15
      4.5.2 Locator.............................................15
      5. Supported Algorithms...................................16
      5.1 Digest Algorithms.....................................16
      5.1.1 DOM-HASH............................................16
      5.1.2 SHA1................................................17
      5.1.3 MD5.................................................17
      5.2 Signature Algorithms..................................17
      5.2.1 DSA.................................................17
      5.2.2 HMAC................................................18
      5.2.3 RSA.................................................18
      6. Examples...............................................18
      7. Signature DTD..........................................19
      8. References.............................................22

      9. Credits................................................23
      Expiration and File Name..................................23

Kent Davidson                                                   [Page 2]


INTERNET-DRAFT        Digital Signatures for IOTP              June 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 Signatures for IOTP              June 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.

   <Signature>
           <Manifest>
                   (resource information block)
                   (originator information block)
                   (recipient information block)
                   (other attributes)
                   (signature algorithms information block)
           </Manifest>
           <Value encoding "encoding scheme">
                   (encoded signature value)
           <Value>
   </Signature>

   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.

Kent Davidson                                                   [Page 4]


INTERNET-DRAFT        Digital Signatures for IOTP              June 1999

   <Digest DigestAlgorithmRef "D.1">
       <Locator href "resource locator"/>
       <Value>
            (Digest value)
       </Value>
   </Digest>

   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.

   <OriginatorInfo>
       (identification information block)
       (keying material information block)
   </OriginatorInfo>

   <RecipientInfo>
       (identification information block)
       (keying material information block)
   </RecipientInfo>

   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.

Kent Davidson                                                   [Page 5]


INTERNET-DRAFT        Digital Signatures for IOTP              June 1999

   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.

3.4 Algorithm Element

   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 type "digest" id 12>
       (algorithm information block)
   </Algorithm>

   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.

   <!ELEMENT IOTPSignatures (Certificate*, Signature+) >
   <!ATTLIST IOTPSignatures
           ID             ID            #IMPLIED >

   Content Description

Kent Davidson                                                   [Page 6]


INTERNET-DRAFT        Digital Signatures for IOTP              June 1999

   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.

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 canoicalized 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-key algorithm which
   digitally stamps the digest with the certificate of the signer. The
   final signed digest is the value which is stored within the
   Signature's Value element.

Kent Davidson                                                   [Page 7]


INTERNET-DRAFT        Digital Signatures for IOTP              June 1999

   <!ELEMENT Signature (Manifest, Value+) >
   <!ATTLIST Signature
           ID              ID            #IMPLIED >

   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.

   <!ELEMENT Manifest
           (       Algorithm+,
                   Digest+,
                   Attribute*,
                   OriginatorInfo,
                   RecipientInfo+,
           )
   <!ATTLIST Manifest
           LocatorHRefBase          CDATA        #IMPLIED

   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.

Kent Davidson                                                   [Page 8]


INTERNET-DRAFT        Digital Signatures for IOTP              June 1999

   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:

   <Manifest
           LocatorHrefBase 'iotp:globally-unique-tid#'>

   And subsequent Locators may be:

   <Locator href "C.9">

   An implementation should concatenate the two locator references to
   create the entire URL.

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.

   <!ELEMENT Algorithm (Parameter*) > <!ATTRLIST Algorithm
           id             ID                #REQUIRED
           type     (digest|signature)      #IMPLIED
           name           NMTOKEN           #REQUIRED >

   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.

Kent Davidson                                                   [Page 9]


INTERNET-DRAFT        Digital Signatures for IOTP              June 1999

   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.

   <!ELEMENT Digest (Locator, Value) >
   <!ATTLIST Digest
           DigestAlgorithmRef       IDREF    #REQUIRED

   Content Description

   Locator: Contains a "HREF" or URL locator for the resource to be
   fingerprinted. References to IOTP messages.

   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.

Kent Davidson                                                  [Page 10]


INTERNET-DRAFT        Digital Signatures for IOTP              June 1999

   <!ELEMENT Attribute ( ANY ) >
   <!ATTLIST Attribute
           type               NMTOKEN           #REQUIRED
           critical        ( true | false )     #REQUIRED

   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.

   <!ELEMENT OriginatorInfo ANY >
   <!ATTLIST OriginatorInfo
           OriginatorRef       NMTOKEN      #IMPLIED

   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
   either for enabling recognition of a Signature element by a given
   recipient or when determination of the authentication key consists of

Kent Davidson                                                  [Page 11]


INTERNET-DRAFT        Digital Signatures for IOTP              June 1999

   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.

   <!ELEMENT RecipientInfo ANY >
   <!ATTLIST RecipientInfo
           SignatureAlgorithmRef   IDREF        #REQUIRED
           SignatureValueRef       IDREF        #REQUIRED
           SignatureCertRef        IDREF        #IMPLIED
           RecipientRefs           NMTOKENS     #IMPLIED

   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.

   SignatureCertRef: A reference to the certificate used to sign the
   Value pointed to by the SignatureValueRef.

   RecipientRefs: A list of references to the IOTP Org ID of the
   recipients this signature is intended for.

4.3.8 Parameter

   A Parameter element provides the value of a particular algorithm
   parameter, whose name and format have been specified for the
   algorithm considered.

Kent Davidson                                                  [Page 12]


INTERNET-DRAFT        Digital Signatures for IOTP              June 1999

   <!ELEMENT Parameter ANY >
   <!ATTLIST Parameter
           type       PCDATA       #REQUIRED

   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:

   <Algorithm ID A1 type "digest" name "urn:ibm:dom-hash">
           <Parameter type 'AlgorithmRef'>A2</Parameter>
   </Algorithm>
   <Algorithm ID A2 type "digest" name "urn:fips:sha1">
   </Algorithm>
   <Algorithm ID A3 type "signature" name "urn:ibm:hmac">
           <Parameter type 'AlgorithmRef'>A1</Parameter>
   </Algorithm>

   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.

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.

Kent Davidson                                                  [Page 13]


INTERNET-DRAFT        Digital Signatures for IOTP              June 1999

   <!ELEMENT Certificate
   (       IssuerAndSerialNumber,
           ( Value | Locator ) )
   <!ATTLIST Certificate
           ID           ID           #IMPLIED
           type         NMTOKEN      #REQUIRED >

   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
   issuer and an issuer-specific certificate identification.

   <!ELEMENT IssuerAndSerialNumber EMPTY >
   <!ATTLIST IssuerAndSerialNumber
           issuer        CDATA         #REQUIRED
           number        CDATA         #REQUIRED >

   Attributes Description

   issuer: Name of the issuing certification authority.

   number: Issuer-specific certificate identification.

Kent Davidson                                                  [Page 14]


INTERNET-DRAFT        Digital Signatures for IOTP              June 1999

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.

   <!ELEMENT Value ( #PCDATA ) > <!ATTLIST Value
           id                ID            #IMPLIED
           encoding      (base64|none)     #IMPLIED       'base64' >

   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.

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.

   <!ELEMENT Locator EMPTY>
   <!ATTLIST Locator
           xml:link         CDATA        #FIXED         'simple'
           href             CDATA        #REQUIRED >

   Attributes Description

   xml:link: Required XML link attribute that specifies the nature of
   the link (simple in this case).

Kent Davidson                                                  [Page 15]


INTERNET-DRAFT        Digital Signatures for IOTP              June 1999

   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.

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".

Kent Davidson                                                  [Page 16]


INTERNET-DRAFT        Digital Signatures for IOTP              June 1999

   Example
   <Algorithm name "urn:ibm:dom-hash" type digest>
   </Algorithm>

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].

5.2.1 DSA

   TODO

   The DSA URN used in this specification is "urn:fips:dsa".

Kent Davidson                                                  [Page 17]


INTERNET-DRAFT        Digital Signatures for IOTP              June 1999

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:

   <OtpMessage>
      <TransRefBlk ID "C.1">
          <TransId
              ID "C.2"
              version "1.0"
              OtpTransID "foo"
              OtpTransType "foo"
              TransTimeStamp "1258402394">
          </TransId>
          <MsgId xml:lang "en" SoftwareID "1.0">
          </MsgId>
      </TransRefBlk>
      <AuthReqBlk ID "C.3">
          <Org
              ID "C.7"
              OrgId "shop 1.0"
              OtpMsgIdPrefix "foo"
              ShortDesc "Widgets,Inc."
              LogoNetLocn "http://www.widgets.com/Banner2.12.99.gif">
              <TradingRole ID "C.8" TradingRole "foo">
              </TradingRole>
              <ContactInfo Tel "408-864-0600" Email "[email-masked]">
              </ContactInfo>
          </Org>
      </AuthReqBlk>
      <IOTPSignatures>
          <Signature>
              <Manifest LocatorHrefBase "iotp:">

Kent Davidson                                                  [Page 18]


INTERNET-DRAFT        Digital Signatures for IOTP              June 1999

                  <Algorithm name "urn:sha1" type digest ID "S.1">
                  </Algorithm>
                  <Algorithm name "urn:rsa" type signature ID "S.2">
                      <Parameter type AlgorithmRef>S.3</Parameter>
                  </Algorithm>
                  <Algorithm name "urn:dom-hash" type "digest" ID "S.3">
                      <Parameter type AlgorithmRef>S.1</Parameter>
                  </Algorithm>
                  <Digest DigestAlgorithmRef "S.3">
                      <Locator href "C.1"/>
                      <Value>
                          xsqsfasDys2h44u4ehJDe54he5j4dJYTJ
                      </Value>
                  </Digest>
                  <Digest DigestAlgorithmRef "S.3">
                      <Locator href "C.3"/>
                      <Value>
                          ked0Ks01k2d7a0kgmf9dk19lf63kkDSs0
                      </Value>
                  </Digest>
                  <OriginatorInfo
                      OriginatorRef "C.7">
                  </OriginatorInfo>
                  <RecipientInfo
                      SignatureAlgorithmRef "S.2"
                      SignatureValueRef "V.1"
                      RecipientRef "M.8">
                  </RecipientInfo>
              </Manifest>
              <Value ID "V.1">
                  9dj28fjakA9sked0Ks01k2d7a0kgmf9dk19lf63kkDSs0
              </Value>
          </Signature>
      </IOTPSignatures>
   </OtpMessage>

7. Signature DTD

   <!--
   ******************************************************
   * IOTP SIGNATURES BLOCK DEFINITION                   *
   ******************************************************
   -->

   <!ELEMENT IOTPSignatures (Certificate*, Signature+) >
   <!ATTLIST IOTPSignatures
           ID        ID        #IMPLIED

Kent Davidson                                                  [Page 19]


INTERNET-DRAFT        Digital Signatures for IOTP              June 1999

   <!--
   ******************************************************
   * IOTP SIGNATURE COMPONENT DEFINITION                *
   ******************************************************
   -->

   <!ELEMENT Signature (Manifest, Value+) >
   <!ATTLIST Signature
           ID         ID        #IMPLIED

   <!ELEMENT Manifest
           (       Algorithm+,
                   Digest+,
                   Attribute*,
                   OriginatorInfo,
                   RecipientInfo+
           )

   <!ATTLIST Manifest
           LocatorHRefBase       CDATA             #IMPLIED

   <!ELEMENT Algorithm (Parameter*) >
   <!ATTLIST Algorithm
           id                    ID                #REQUIRED
           type            (digest|signature)      #IMPLIED
           name                  NMTOKEN           #REQUIRED

   <!ELEMENT Digest (Locator, Value) >
   <!ATTLIST Digest
           DigestAlgorithmRef    IDREF             #REQUIRED

   <!ELEMENT Attribute ( #PCDATA ) >
   <!ATTLIST Attribute
           type                   NMTOKEN           #REQUIRED
           critical            ( true | false )     #REQUIRED

   <!ELEMENT OriginatorInfo ANY >
   <!ATTLIST OriginatorInfo
           OriginatorRef           NMTOKEN          #IMPLIED

   <!ELEMENT RecipientInfo ANY >

Kent Davidson                                                  [Page 20]


INTERNET-DRAFT        Digital Signatures for IOTP              June 1999

   <!ATTLIST RecipientInfo
           SignatureAlgorithmRef   IDREF            #REQUIRED
           SignatureValueRef       IDREF            #REQUIRED
           SignatureCertRef        IDREF            #IMPLIED
           RecipientRefs           NMTOKENS         #IMPLIED

   <!ELEMENT Parameter ANY >
   <!ATTLIST Parameter
           type                     CDATA           #REQUIRED

   <!--
   ******************************************************
   * IOTP CERTIFICATE COMPONENT DEFINITION              *
   ******************************************************
   -->

   <!ELEMENT Certificate
     (  IssuerAndSerialNumber,  ( Value | Locator ) )

   <!ATTLIST Certificate
           ID                        ID                #IMPLIED
           type                      NMTOKEN           #REQUIRED

   <!ELEMENT IssuerAndSerialNumber EMPTY >
   <!ATTLIST IssuerAndSerialNumber
           issuer                     CDATA            #REQUIRED
           number                     CDATA            #REQUIRED

   <!--
   ******************************************************
   * IOTP SHARED COMPONENT DEFINITION                   *
   ******************************************************
   -->
   <!ELEMENT Value ( #PCDATA ) >
   <!ATTLIST Value
           id              ID           #IMPLIED
           encoding    (base64|none)    #IMPLIED      'base64'

   <!ELEMENT Locator EMPTY>
   <!ATTLIST Locator
           xml:link        CDATA         #FIXED        'simple'
           href            CDATA         #REQUIRED

Kent Davidson                                                  [Page 21]


INTERNET-DRAFT        Digital Signatures for IOTP              June 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)",
   <http://www.w3.org/TR/1998/WD-xlink-19980303>

   [XML] - Tim Bray, Jean Paoli, C. M. Sperber-McQueen, "Extensible
   Markup Language (XML) 1.0", <http://www.w3.org/TR/1998/REC-xml-
   19980210>

Kent Davidson                                                  [Page 22]


INTERNET-DRAFT        Digital Signatures for IOTP              June 1999

9. Credits

   This document is based on work originally done on general XML digital
   signatures by Richard Brown at GlobeSet, Inc. <[email-masked]>
   but has been narrowed and changed.

   The editor of this document is:

        Kent M. Davidson
        Differential, Inc.
        440 Clyde Ave.
        Mountain View, CA 94043 USA

        email: [email-masked]

   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 December 1999.

   Its file name is draft-ietf-trade-iotp-v1.0-dsig-01.txt.

Kent Davidson                                                  [Page 23]