draft-ietf-trade-iotp-v1.0-dsig-04.txt   draft-ietf-trade-iotp-v1.0-dsig-05.txt 
TRADE Working Group Kent Davidson TRADE Working Group Kent Davidson
INTERNET-DRAFT Differential INTERNET-DRAFT Differential
Yoshiaki Kawatsura Yoshiaki Kawatsura
Hitachi Hitachi
Expires: March 2000 September 1999 Expires: May 2000 November 1999
draft-ietf-trade-iotp-v1.0-dsig-02.txt draft-ietf-trade-iotp-v1.0-dsig-05.txt
Digital Signatures for the v1.0 Internet Open Trading Protocol (IOTP) Digital Signatures for the v1.0 Internet Open Trading Protocol (IOTP)
------- ---------- --- --- ---- -------- ---- ------- -------- ------ ------- ---------- --- --- ---- -------- ---- ------- -------- ------
Status of This Document Status of This Document
This draft, file name draft-ietf-trade-iotp-v1.0-dsig-02.txt, is a 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, part of the Internet Open Trading Protocol Specification version 1.0,
and is intended to become an Informational RFC. Distribution of this and is intended to become an Informational RFC. Distribution of this
document is unlimited. Comments should be sent to the TRADE working document is unlimited. Comments should be sent to the TRADE working
group mailing list <ietf-trade@elistx.com>. group mailing list <ietf-trade@elistx.com>.
This document is an Internet-Draft and is in full conformance with This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026. Internet-Drafts are working all provisions of Section 10 of RFC2026. Internet-Drafts are working
documents of the Internet Engineering Task Force (IETF), its areas, documents of the Internet Engineering Task Force (IETF), its areas,
and its working groups. Note that other groups may also distribute and its working groups. Note that other groups may also distribute
working documents as Internet-Drafts. working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six Internet-Drafts are draft documents valid for a maximum of six
months. Internet-Drafts may be updated, replaced, or obsoleted by months. Internet-Drafts may be updated, replaced, or obsoleted by
other documents at any time. It is not appropriate to use Internet- other documents at any time. It is not appropriate to use Internet-
Drafts as reference material or to cite them other than as a Drafts as reference material or to cite them other than as a
``working draft'' or ``work in progress.'' ``working draft'' or ``work in progress.''
To view the entire list of current Internet-Drafts, please check the The list of current Internet-Drafts can be accessed at
"1id-abstracts.txt" listing contained in the Internet-Drafts Shadow http://www.ietf.org/ietf/1id-abstracts.txt
Directories as listed at <http://www.ietf.org/shadow.html>.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
Abstract Abstract
A syntax and procedures are described for the computation and A syntax and procedures are described for the computation and
verification of digital signatures for use within Version 1.0 of the verification of digital signatures for use within Version 1.0 of the
Internet Open Trading Protocol (IOTP). Internet Open Trading Protocol (IOTP).
[Changes from previous draft: correction of one line in DTD, move
acknowledgement to the front.]
Copyright Copyright
Copyright (C) The Internet Society 1999. 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. <rdbrown@GlobeSet.com>
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 Table of Contents
Status of This Document....................................1 Status of This Document....................................1
Abstract...................................................1 Abstract...................................................1
Copyright..................................................1
Copyright..................................................2
Acknowledgement............................................2
Table of Contents..........................................2 Table of Contents..........................................2
1. Introduction............................................4 1. Introduction............................................4
2. Objective and Requirements..............................5 2. Objective and Requirements..............................5
3. Signature Basics........................................6 3. Signature Basics........................................6
3.1 Signature Element......................................6 3.1 Signature Element......................................6
3.2 Digest Element.........................................6 3.2 Digest Element.........................................6
3.3 Originator and Recipient Information Elements..........7 3.3 Originator and Recipient Information Elements..........7
skipping to change at page 3, line 4 skipping to change at page 3, line 28
5.2 Signature Algorithms..................................20 5.2 Signature Algorithms..................................20
5.2.1 DSA.................................................20 5.2.1 DSA.................................................20
5.2.2 HMAC................................................21 5.2.2 HMAC................................................21
5.2.3 RSA.................................................22 5.2.3 RSA.................................................22
5.2.4 ECDSA...............................................23 5.2.4 ECDSA...............................................23
6. Examples...............................................24 6. Examples...............................................24
7. Signature DTD..........................................25 7. Signature DTD..........................................25
8. Security Considerations................................28 8. Security Considerations................................28
Full Copyright Statement..................................28 Full Copyright Statement..................................28
References................................................29 References................................................29
Author's Addresses........................................31 Author's Addresses........................................31
Expiration and File Name..................................31 Expiration and File Name..................................31
1. Introduction 1. Introduction
The Internet Open Trading Protocol (IOTP) provides a payment system The Internet Open Trading Protocol (IOTP) provides a payment system
independent interoperable framework for Internet commerce as independent interoperable framework for Internet commerce as
documented in [RFC xxxx, draft-ietf-trade-iotp-v1.0-protocol-*.txt]. documented in [RFC xxx1]. All IOTP messages are XML documents. XML,
All IOTP messages are XML documents. XML, the Extensible Markup the Extensible Markup Language [XML], is a syntactical standard
Language [XML], is a syntactical standard promulgated by the World promulgated by the World Wide Web Consortium. XML is intended
Wide Web Consortium. XML is intended primarily for structuring data primarily for structuring data exchanged and served over the World
exchanged and served over the World Wide Web. Wide Web.
Although IOTP assumes that any payment system used with it provides Although IOTP assumes that any payment system used with it provides
its own security, there are numerous cases where IOTP requires its own security, there are numerous cases where IOTP requires
authentication and integrity services for portions of the XML authentication and integrity services for portions of the XML
messages it specifies. messages it specifies.
2. Objective and Requirements 2. Objective and Requirements
This document covers how digital signatures may be used with XML This document covers how digital signatures may be used with XML
documents to provide authentication and tamper-proof protocol documents to provide authentication and tamper-proof protocol
skipping to change at page 5, line 26 skipping to change at page 5, line 26
for the computation and verification of digital signatures applicable for the computation and verification of digital signatures applicable
to Version 1.0 IOTP protocol messages, providing for: to Version 1.0 IOTP protocol messages, providing for:
-- Authentication of IOTP transactions -- Authentication of IOTP transactions
-- Provide a means by which an IOTP message may be made "tamper- -- Provide a means by which an IOTP message may be made "tamper-
proof", or detection of tampering is made evident proof", or detection of tampering is made evident
-- Describe a set of available digest and signature algorithms at -- Describe a set of available digest and signature algorithms at
least one of which is mandatory to implement for interoperability least one of which is mandatory to implement for interoperability
-- Easily integrate within the IOTP 1.0 Specification -- Easily integrate within the IOTP 1.0 Specification
-- Provide lightweight signatures with minimal redundancy -- Provide lightweight signatures with minimal redundancy
-- Allow a signed portions of IOTP message to be "forwarded" to -- Allow signed portions of IOTP message to be "forwarded" to another
another trading roles with different signature algorithms than the trading roles with different signature algorithms than the
original recipient original recipient
3. Signature Basics 3. Signature Basics
3.1 Signature Element 3.1 Signature Element
This specification consists primarily of the definition of an XML This specification consists primarily of the definition of an XML
element known as the Signature element. This element consists of two element known as the Signature element. This element consists of two
sub-elements. The first one is a set of authenticated attributes, sub-elements. The first one is a set of authenticated attributes,
known as the signature Manifest, which comprises such things as a known as the signature Manifest, which comprises such things as a
skipping to change at page 8, line 7 skipping to change at page 8, line 7
Signature information block. Signature information block.
The Recipient information element may also be used when determination The Recipient information element may also be used when determination
of the authentication key consists of a combination of keying of the authentication key consists of a combination of keying
material provided by both parties. This would be the case, for material provided by both parties. This would be the case, for
example, when establishing a key by means of Diffie Hellman example, when establishing a key by means of Diffie Hellman
[Schneier] Key Exchange algorithm. [Schneier] Key Exchange algorithm.
3.4 Algorithm Element 3.4 Algorithm Element
The Algorithm element is a generalised place to place any type of The Algorithm element is a generalised place to put any type of
algorithm used within the signed IOTP message. The Algorithm may be a algorithm used within the signed IOTP message. The Algorithm may be a
Signature algorithm or a Digest algorithm. Each algorithm contains Signature algorithm or a Digest algorithm. Each algorithm contains
parameters specific to the algorithm used. parameters specific to the algorithm used.
<Algorithm type='digest' ID='12'> <Algorithm type='digest' ID='12'>
(algorithm information block) (algorithm information block)
</Algorithm> </Algorithm>
Algorithms are required to contain an ID which allows for indirect Algorithms are required to contain an ID which allows for indirect
reference to them from other places in the XML signature. reference to them from other places in the XML signature.
skipping to change at page 13, line 5 skipping to change at page 13, line 5
The Attribute element consists of a complementary piece of The Attribute element consists of a complementary piece of
information, which shall be included in the authenticated part of the information, which shall be included in the authenticated part of the
document. This element has been defined primarily for enabling some document. This element has been defined primarily for enabling some
level of customization in the signature element. This is the area level of customization in the signature element. This is the area
where a specific IOTP implementation may include custom attributes where a specific IOTP implementation may include custom attributes
which must be authenticated directly. An Attribute element consists which must be authenticated directly. An Attribute element consists
of a value, a type, and a criticality. of a value, a type, and a criticality.
At this time, no IOTP specific attributes are specified. At this time, no IOTP specific attributes are specified.
<!ELEMENT Attribute ( ANY ) > <!ELEMENT Attribute ANY >
<!ATTLIST Attribute <!ATTLIST Attribute
type NMTOKEN #REQUIRED type NMTOKEN #REQUIRED
critical ( true | false ) #REQUIRED critical ( true | false ) #REQUIRED
> >
Content Description Content Description
ANY: The actual value of an attribute depends solely upon its type. ANY: The actual value of an attribute depends solely upon its type.
Attributes Description Attributes Description
skipping to change at page 17, line 18 skipping to change at page 17, line 18
thereby an entity and a public key, by the name of the certificate thereby an entity and a public key, by the name of the certificate
issuer and an issuer-specific certificate identification. issuer and an issuer-specific certificate identification.
<!ELEMENT IssuerAndSerialNumber EMPTY > <!ELEMENT IssuerAndSerialNumber EMPTY >
<!ATTLIST IssuerAndSerialNumber <!ATTLIST IssuerAndSerialNumber
issuer CDATA #REQUIRED issuer CDATA #REQUIRED
number CDATA #REQUIRED > number CDATA #REQUIRED >
Attributes Description Attributes Description
issuer: Name of the issuing certification authority. issuer: Name of the issuing certification authority. See [RFC 2253]
for RECOMMENDED syntax.
number: Issuer-specific certificate identification. number: Issuer-specific certificate identification.
4.5 Common Components 4.5 Common Components
4.5.1 Value 4.5.1 Value
A value contains the "raw" data of a signature or digest algorithm, 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 usually in a base-64 encoded form. See [RFC 2045] for algorithm used
to base-64 encode data. to base-64 encode data.
skipping to change at page 19, line 24 skipping to change at page 19, line 26
This algorithm does not require any parameter. This algorithm does not require any parameter.
The SHA1 URN used for this specification is "urn:nist-gov:sha1". The SHA1 URN used for this specification is "urn:nist-gov:sha1".
5.1.2 DOM-HASH 5.1.2 DOM-HASH
XML canonical digest algorithm proposed by IBM Tokyo Research XML canonical digest algorithm proposed by IBM Tokyo Research
Laboratory. This algorithm operates on the DOM representation of the Laboratory. This algorithm operates on the DOM representation of the
document and provides an unambiguous means for recursive computation document and provides an unambiguous means for recursive computation
of the hash value of the nodes that constitute the DOM tree. This of the hash value of the nodes that constitute the DOM tree [RFC
algorithm has many applications such as computation of digital xxx2]. This algorithm has many applications such as computation of
signature and synchronization of DOM trees. However, because the hash digital signature and synchronization of DOM trees. However, because
value of an element is computed from the hash values of the inner the hash value of an element is computed from the hash values of the
elements, this algorithm is better adapted to small documents that do inner elements, this algorithm is better adapted to small documents
not require one-pass processing. that do not require one-pass processing.
As of today, this algorithm is limited to the contents of an XML As of today, this algorithm is limited to the contents of an XML
document and, therefore, does not provide for authentication of the document and, therefore, does not provide for authentication of the
internal or external subset of the DTD. internal or external subset of the DTD.
The DOM-HASH algorithm requires a single parameter, which shall The DOM-HASH algorithm requires a single parameter, which shall
include a surface string digest algorithm such as SHA1. include a surface string digest algorithm such as SHA1.
The DOM-HASH URN used for this specification is "urn:ibm-com:dom- The DOM-HASH URN used for this specification is "urn:ibm-com:dom-
hash". hash".
skipping to change at page 20, line 36 skipping to change at page 20, line 38
The DSA uses a canonical or surfce-string digest algorithm for The DSA uses a canonical or surfce-string digest algorithm for
computation of the Manifest fingerprint. The DOM-HASH is recommended computation of the Manifest fingerprint. The DOM-HASH is recommended
in this specification. in this specification.
Signature Value Encoding: Signature Value Encoding:
The output of this algorithm consists of a pair of integers usually 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 referred by the pair (r, s). The signature value shall consist of the
concatenation of two octet-streams that respectively result from the concatenation of two octet-streams that respectively result from the
octet-encoding of the values r and s. Integer to octet-stream octet-encoding of the values r and s. Integer to octet-stream
conversion shall be done according to PKCS#1 [PKCS#1] specification conversion shall be done according to PKCS#1 [RFC 2437] specification
with a k parameter equals to 20. with a k parameter equals to 20.
Example Example
<Algorithm name='urn:nist-gov:dsa' type='signature' ID='P.3'> <Algorithm name='urn:nist-gov:dsa' type='signature' ID='P.3'>
<Parameter type="AlgorithmRef">P.4</Parameter> <Parameter type="AlgorithmRef">P.4</Parameter>
</Algorithm> </Algorithm>
<Algorithm name='urn:ibm-com:dom-hash' type='digest' ID='P.4'> <Algorithm name='urn:ibm-com:dom-hash' type='digest' ID='P.4'>
<Parameter type='AlgorithmRef'>P.5</Parameter> <Parameter type='AlgorithmRef'>P.5</Parameter>
</Algorithm> </Algorithm>
<Algorithm name='urn:nist-gov:sha1' type='digest' ID='P.5'> <Algorithm name='urn:nist-gov:sha1' type='digest' ID='P.5'>
</Algorithm> </Algorithm>
5.2.2 HMAC 5.2.2 HMAC
Message Authentication Code proposed by H. Krawczyk and al. and Message Authentication Code proposed by H. Krawczyk et al. and
documented in [RFC 2104]. documented in [RFC 2104].
This specification adopts a scheme that differs a bit from the common This specification adopts a scheme that differs a bit from the common
usage of this algorithm -- computation of the MAC is performed on the usage of this algorithm -- computation of the MAC is performed on the
hash of the contents being authenticated instead of the actual hash of the contents being authenticated instead of the actual
contents. Thence, the actual signature value output by the algorithm contents. Thence, the actual signature value output by the algorithm
might be depicted as follows: might be depicted as follows:
SignatureValue = HMAC( SecretKey, H(Manifest)) SignatureValue = HMAC( SecretKey, H(Manifest))
skipping to change at page 21, line 52 skipping to change at page 21, line 52
Output-length: Length in bits of the truncated MAC value. The type of 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 this parameter is set to "KeyLength" and the value of this parameter
is set the length in bits of the truncated MAC value. is set the length in bits of the truncated MAC value.
Signature Value Encoding: Signature Value Encoding:
The output of this algorithm can be assumed as a large integer value. 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 The signature value shall consist of the octet-encoded value of this
integer. Integer to octet-stream conversion shall be done according integer. Integer to octet-stream conversion shall be done according
to PKCS#1 [PKCS#1] specification with a k parameter equals to ((Hlen to PKCS#1 [RFC 2437] specification with a k parameter equals to
+7) mod8), Mlen being the length in bits of the MAC value. ((Hlen +7) mod8), Mlen being the length in bits of the MAC value.
Example Example
<Algorithm name='urn:ietf-org:hmac' type='signature' ID='P.3'> <Algorithm name='urn:ietf-org:hmac' type='signature' ID='P.3'>
<Parameter type="AlgorithmRef">P.4</Parameter> <Parameter type="AlgorithmRef">P.4</Parameter>
<Parameter type="HashAlgorithmRef">P.5</Parameter> <Parameter type="HashAlgorithmRef">P.5</Parameter>
<Parameter type="KeyLength">128</Parameter> <Parameter type="KeyLength">128</Parameter>
</Algorithm> </Algorithm>
<Algorithm name='urn:ibm-com:dom-hash' type='digest' ID='P.4'> <Algorithm name='urn:ibm-com:dom-hash' type='digest' ID='P.4'>
<Parameter type='AlgorithmRef'>P.5</Parameter> <Parameter type='AlgorithmRef'>P.5</Parameter>
</Algorithm> </Algorithm>
<Algorithm name='urn:nist-gov:sha1' type='digest' ID='P.5'> <Algorithm name='urn:nist-gov:sha1' type='digest' ID='P.5'>
</Algorithm> </Algorithm>
5.2.3 RSA 5.2.3 RSA
Public-key signature algorithm proposed by RSA Laboratories and Public-key signature algorithm proposed by RSA Laboratories and
documented in PKCS#1 [PKCS#1]. documented in PKCS#1 [RFC 2437].
This specification adopts the RSA encryption algorithm with padding This specification adopts the RSA encryption algorithm with padding
block type 01. For computing the signature value, the signer shall block type 01. For computing the signature value, the signer shall
first digest the signature Manifest and then encrypt the resulting first digest the signature Manifest and then encrypt the resulting
digest with his private key. digest with his private key.
This signature algorithm requires a single parameter, which consists This signature algorithm requires a single parameter, which consists
of the canonical digest algorithm to be used for computing the of the canonical digest algorithm to be used for computing the
fingerprint of the signature Manifest. fingerprint of the signature Manifest.
skipping to change at page 23, line 24 skipping to change at page 23, line 24
The ECDSA algorithm requires a single parameter, which consists of The ECDSA algorithm requires a single parameter, which consists of
the canonical digest algorithm to be used for computing the the canonical digest algorithm to be used for computing the
fingerprint of the signature Manifest. fingerprint of the signature Manifest.
Specifications Specifications
The ECDSA URN used in this specification is "urn:ansi-org:ecdsa". The ECDSA URN used in this specification is "urn:ansi-org:ecdsa".
The ECDSA uses a canonical or surfce-string digest algorithm for The ECDSA uses a canonical or surfce-string digest algorithm for
computation of the Manifest fingerprint. The DOM-HASH is recommended computation of the Manifest fingerprint. The DOM-HASH [RFC xxx2] is
in this specification. recommended in this specification.
Signature Value Encoding: Signature Value Encoding:
The output of this algorithm consists of a pair of integers usually 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 referred by the pair (r, s). The signature value shall consist of the
concatenation of two octet-streams that respectively result from the concatenation of two octet-streams that respectively result from the
octet-encoding of the values r and s. Integer to octet-stream octet-encoding of the values r and s. Integer to octet-stream
conversion shall be done according to PKCS#1 [PKCS#1] specification conversion shall be done according to PKCS#1 [RFC 2437] specification
with a k parameter equals to 20. with a k parameter equals to 20.
Example Example
<Algorithm name='urn:ansi-org:ecdsa' type='signature' ID='P.3'> <Algorithm name='urn:ansi-org:ecdsa' type='signature' ID='P.3'>
<Parameter type="AlgorithmRef">P.4</Parameter> <Parameter type="AlgorithmRef">P.4</Parameter>
</Algorithm> </Algorithm>
<Algorithm name='urn:ibm-com:dom-hash' type='digest' ID='P.4'> <Algorithm name='urn:ibm-com:dom-hash' type='digest' ID='P.4'>
<Parameter type='AlgorithmRef'>P.5</Parameter> <Parameter type='AlgorithmRef'>P.5</Parameter>
</Algorithm> </Algorithm>
<Algorithm name='urn:nist-gov:sha1' type='digest' ID='P.5'> <Algorithm name='urn:nist-gov:sha1' type='digest' ID='P.5'>
skipping to change at page 26, line 26 skipping to change at page 26, line 26
ID ID #REQUIRED ID ID #REQUIRED
type (digest|signature) #IMPLIED type (digest|signature) #IMPLIED
name NMTOKEN #REQUIRED name NMTOKEN #REQUIRED
> >
<!ELEMENT Digest (Locator, Value) > <!ELEMENT Digest (Locator, Value) >
<!ATTLIST Digest <!ATTLIST Digest
DigestAlgorithmRef IDREF #REQUIRED DigestAlgorithmRef IDREF #REQUIRED
> >
<!ELEMENT Attribute ( ANY ) > <!ELEMENT Attribute ANY >
<!ATTLIST Attribute <!ATTLIST Attribute
type NMTOKEN #REQUIRED type NMTOKEN #REQUIRED
critical ( true | false ) #REQUIRED critical ( true | false ) #REQUIRED
> >
<!ELEMENT OriginatorInfo ANY > <!ELEMENT OriginatorInfo ANY >
<!ATTLIST OriginatorInfo <!ATTLIST OriginatorInfo
OriginatorRef NMTOKEN #IMPLIED OriginatorRef NMTOKEN #IMPLIED
> >
skipping to change at page 27, line 33 skipping to change at page 27, line 33
> >
<!-- <!--
****************************************************** ******************************************************
* IOTP SHARED COMPONENT DEFINITION * * IOTP SHARED COMPONENT DEFINITION *
****************************************************** ******************************************************
--> -->
<!ELEMENT Value ( #PCDATA ) > <!ELEMENT Value ( #PCDATA ) >
<!ATTLIST Value <!ATTLIST Value
ID ID #IMPLIED ID ID #IMPLIED
encoding (base64|none) #IMPLIED 'base64' encoding (base64|none 'base64'
> >
<!ELEMENT Locator EMPTY> <!ELEMENT Locator EMPTY>
<!ATTLIST Locator <!ATTLIST Locator
xml:link CDATA #FIXED 'simple' xml:link CDATA #FIXED 'simple'
href CDATA #REQUIRED href CDATA #REQUIRED
> >
8. Security Considerations 8. Security Considerations
skipping to change at page 29, line 14 skipping to change at page 29, line 14
References References
[DSA] - Federal Information Processing Standards Plublication FIPS [DSA] - Federal Information Processing Standards Plublication FIPS
PUB 186, "Digital Signature Standard(DSS)", 1994, PUB 186, "Digital Signature Standard(DSS)", 1994,
<http://csrc.nist.gov> <http://csrc.nist.gov>
[IEEE P1363] - IEEE P1363, "Standard Specifications for Public-Key [IEEE P1363] - IEEE P1363, "Standard Specifications for Public-Key
Cryptography", draft, 1997, <http://stdsbbs.ieee.org/> Cryptography", draft, 1997, <http://stdsbbs.ieee.org/>
[PKCS#1] - RSA Laboratories, "PKCS #1: RSA Encription Standard.
Version 1.5", November 1993.
[PV] - B. Preneel and P. van Oorschot, "Building fast MACs from hash [PV] - B. Preneel and P. van Oorschot, "Building fast MACs from hash
functions", Advances in Cryptology -- CRYPTO'95 Proceedings, Lecture functions", Advances in Cryptology -- CRYPTO'95 Proceedings, Lecture
Notes in Computer Science, Springer-Verlag Vol.963, 1995, pp. 1-14. Notes in Computer Science, Springer-Verlag Vol.963, 1995, pp. 1-14.
[RFC 1321] - R. Rivest, "The MD5 Message-Digest Algorithm", April [RFC 1321] - R. Rivest, "The MD5 Message-Digest Algorithm", April
1992. 1992.
[RFC 2045]- N. Freed & N. Borenstein, "Multipurpose Internet Mail [RFC 2045]- N. Freed & N. Borenstein, "Multipurpose Internet Mail
Extensions (MIME) Part One: Format of Internet Message Bodies", Extensions (MIME) Part One: Format of Internet Message Bodies",
November 1996. November 1996.
[RFC 2046] - N. Freed & N. Borenstein, "Multipurpose Internet Mail [RFC 2046] - N. Freed & N. Borenstein, "Multipurpose Internet Mail
Extensions (MIME) Part Two: Media Types", November 1996. Extensions (MIME) Part Two: Media Types", November 1996.
[RFC 2104] - H. Krawczyk, M. Bellare, R. Canetti, "HMAC: Keyed- [RFC 2104] - H. Krawczyk, M. Bellare, R. Canetti, "HMAC: Keyed-
Hashing for Message Authentication", February 1997. Hashing for Message Authentication", February 1997.
[RFC 2141] - R. Moats, "URN Syntax", May 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 [RFC 2396] - T. Berners-Lee, R. Fielding, L. Masinter, "Uniform
Resource Identifiers (URI): Generic Syntax", August 1998. Resource Identifiers (URI): Generic Syntax", August 1998.
[RFC xxxx] - D. Burdett, "Interenet Open Trading Protocol - IOTP, [RFC 2437] - B. Kaliski, J. Staddon, "PKCS #1: RSA Cryptography
Version 1.0", August 1999. (currently draft-ietf-trade-iotp-v1.0- 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) 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, [Schneier] - Bruce Schneier, "Applied Cryptography: Protocols,
Algorithms, and Source Code in C", 1996, John Wiley and Sons Algorithms, and Source Code in C", 1996, John Wiley and Sons
[SHA1] - NIST FIPS PUB 180-1, "Secure Hash Standard," National [SHA1] - NIST FIPS PUB 180-1, "Secure Hash Standard," National
Institute of Standards and Technology, U.S. Department of Commerce, Institute of Standards and Technology, U.S. Department of Commerce,
April 1995. April 1995.
[X.509] - ITU-T Recommendation X.509 (1997 E), "Information [X.509] - ITU-T Recommendation X.509 (1997 E), "Information
Technology - Open Systems Interconnection - The Directory: Technology - Open Systems Interconnection - The Directory:
Authentication Framework", June 1997. Authentication Framework", June 1997.
skipping to change at page 31, line 7 skipping to change at page 31, line 7
[XLink] - Eve Maler, Steve DeRose, "XML Linking Language (XLink)", [XLink] - Eve Maler, Steve DeRose, "XML Linking Language (XLink)",
<http://www.w3.org/TR/1998/WD-xlink-19980303> <http://www.w3.org/TR/1998/WD-xlink-19980303>
[XML] - Tim Bray, Jean Paoli, C. M. Sperber-McQueen, "Extensible [XML] - Tim Bray, Jean Paoli, C. M. Sperber-McQueen, "Extensible
Markup Language (XML) 1.0", <http://www.w3.org/TR/1998/REC-xml- Markup Language (XML) 1.0", <http://www.w3.org/TR/1998/REC-xml-
19980210> 19980210>
Author's Addresses Author's Addresses
This document is based on work originally done on general XML digital
signatures by Richard Brown at GlobeSet, Inc. <rdbrown@GlobeSet.com>
but has been narrowed and changed.
The authors of this document are: The authors of this document are:
Kent M. Davidson Kent M. Davidson
Differential, Inc. Differential, Inc.
440 Clyde Ave. 440 Clyde Ave.
Mountain View, CA 94043 USA Mountain View, CA 94043 USA
email: kent@differential.com email: kent@differential.com
Yoshiaki Kawatsura Yoshiaki Kawatsura
Hitachi, Ltd. Hitachi, Ltd.
890-12 Kashimada Saiwai Kawasaki, 890-12 Kashimada Saiwai Kawasaki,
Kanagawa 2118567 Japan Kanagawa 2118567 Japan
email: kawatura@bisd.hitachi.co.jp email: kawatura@bisd.hitachi.co.jp
Contributors to the design of the IOTP DTD include, in alphabetic
order:
David Burdett, Commerce One
Andrew Drapp, Hitachi
Donald Eastlake 3rd, IBM
Expiration and File Name Expiration and File Name
This draft expires March 2000. This draft expires May 2000.
Its file name is draft-ietf-trade-iotp-v1.0-dsig-02.txt. Its file name is draft-ietf-trade-iotp-v1.0-dsig-05.txt.
 End of changes. 

This html diff was produced by rfcdiff 1.25, available from http://www.levkowetz.com/ietf/tools/rfcdiff/