rfc2802.txt

RFC 的详细文档！

Network Working Group                                        K. Davidson
Request for Comments: 2802                                  Differential
Category: Informational                                     Y. Kawatsura
                                                                 Hitachi
                                                              April 2000


 Digital Signatures for the v1.0 Internet Open Trading Protocol (IOTP)

Status of this Memo

   This memo provides information for the Internet community.  It does
   not specify an Internet standard of any kind.  Distribution of this
   memo is unlimited.

Copyright Notice

   Copyright (C) The Internet Society (2000).  All Rights Reserved.

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

Acknowledgment

   This document is based on work originally done on general XML digital
   signatures by:

     Richard Brown of GlobeSet, Inc. <[e-mail]>

   Other contributors to the design of the IOTP DSIG DTD include, in
   alphabetic order:

     David Burdett, Commerce One
     Andrew Drapp, Hitachi
     Donald Eastlake 3rd, Motorola, Inc.













Davidson & Kawatsura         Informational                      [Page 1]

RFC 2802              Digital Signatures for IOTP             April 2000


Table of Contents

   1. Introduction............................................3
   2. Objective and Requirements..............................3
   3. Signature Basics........................................3
   3.1 Signature Element......................................3
   3.2 Digest Element.........................................4
   3.3 Originator and Recipient Information Elements..........5
   3.4 Algorithm Element......................................5
   4. Detailed Signature Syntax...............................6
   4.1 Uniform Resource Names.................................6
   4.2 IotpSignatures.........................................6
   4.3 Signature Component....................................6
   4.3.1 Signature............................................6
   4.3.2 Manifest.............................................7
   4.3.3 Algorithm............................................9
   4.3.4 Digest...............................................9
   4.3.5 Attribute...........................................10
   4.3.6 OriginatorInfo......................................11
   4.3.7 RecipientInfo.......................................11
   4.3.8 KeyIdentifier.......................................12
   4.3.9 Parameter...........................................13
   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 SHA1................................................16
   5.1.2 DOM-HASH............................................17
   5.2 Signature Algorithms..................................17
   5.2.1 DSA.................................................17
   5.2.2 HMAC................................................18
   5.2.3 RSA.................................................20
   5.2.4 ECDSA...............................................20
   6. Examples...............................................21
   7. Signature DTD..........................................23
   8. Security Considerations................................25
   References................................................26
   Authors' Addresses........................................28
   Full Copyright Statement..................................29








Davidson & Kawatsura         Informational                      [Page 2]

RFC 2802              Digital Signatures for IOTP             April 2000


1. Introduction

   The Internet Open Trading Protocol (IOTP) provides a payment system
   independent interoperable framework for Internet commerce as
   documented in [RFC 2801]. 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 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

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



Davidson & Kawatsura         Informational                      [Page 3]

RFC 2802              Digital Signatures for IOTP             April 2000


   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.

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








Davidson & Kawatsura         Informational                      [Page 4]

RFC 2802              Digital Signatures for IOTP             April 2000


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.

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

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



Davidson & Kawatsura         Informational                      [Page 5]

RFC 2802              Digital Signatures for IOTP             April 2000


      <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 (Signature+, Certificate*) >
   <!ATTLIST IotpSignatures
           ID             ID            #IMPLIED >

   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.

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.





Davidson & Kawatsura         Informational                      [Page 6]

RFC 2802              Digital Signatures for IOTP             April 2000


   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.

   <!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 component.

   Attributes Description

   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 references to the resources being
   authenticated and an indication of the keying material and algorithms
   to be used.




Davidson & Kawatsura         Informational                      [Page 7]

RFC 2802              Digital Signatures for IOTP             April 2000


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