draft-ietf-trade-iotp-v1.0-dsig-05.txt   rfc2802.txt 
TRADE Working Group Kent Davidson
INTERNET-DRAFT Differential Network Working Group K. Davidson
Yoshiaki Kawatsura Request for Comments: 2802 Differential
Category: Informational Y. Kawatsura
Hitachi Hitachi
Expires: May 2000 November 1999 April 2000
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 Memo
This draft, file name draft-ietf-trade-iotp-v1.0-dsig-05.txt, is a
part of the Internet Open Trading Protocol Specification version 1.0,
and is intended to become an Informational RFC. Distribution of this
document is unlimited. Comments should be sent to the TRADE working
group mailing list <ietf-trade@elistx.com>.
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 This memo provides information for the Internet community. It does
months. Internet-Drafts may be updated, replaced, or obsoleted by not specify an Internet standard of any kind. Distribution of this
other documents at any time. It is not appropriate to use Internet- memo is unlimited.
Drafts as reference material or to cite them other than as a
``working draft'' or ``work in progress.''
The list of current Internet-Drafts can be accessed at Copyright Notice
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at Copyright (C) The Internet Society (2000). All Rights Reserved.
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 Acknowledgment
acknowledgement to the front.]
Copyright
Copyright (C) 1999. The Internet Society. All Rights Reserved.
Acknowledgement
This document is based on work originally done on general XML digital This document is based on work originally done on general XML digital
signatures by signatures by:
Richard Brown of GlobeSet, Inc. <rdbrown@GlobeSet.com> Richard Brown of GlobeSet, Inc. <rdbrown@GlobeSet.com>
Other contributors to the design of the IOTP DSIG DTD include, in Other contributors to the design of the IOTP DSIG DTD include, in
alphabetic order: alphabetic order:
David Burdett, Commerce One David Burdett, Commerce One
Andrew Drapp, Hitachi Andrew Drapp, Hitachi
Donald Eastlake 3rd, IBM Donald Eastlake 3rd, Motorola, Inc.
Table of Contents Table of Contents
Status of This Document....................................1 1. Introduction............................................3
Abstract...................................................1 2. Objective and Requirements..............................3
3. Signature Basics........................................3
Copyright..................................................2 3.1 Signature Element......................................3
Acknowledgement............................................2 3.2 Digest Element.........................................4
Table of Contents..........................................2 3.3 Originator and Recipient Information Elements..........5
3.4 Algorithm Element......................................5
1. Introduction............................................4 4. Detailed Signature Syntax...............................6
4.1 Uniform Resource Names.................................6
2. Objective and Requirements..............................5 4.2 IotpSignatures.........................................6
4.3 Signature Component....................................6
3. Signature Basics........................................6 4.3.1 Signature............................................6
3.1 Signature Element......................................6 4.3.2 Manifest.............................................7
3.2 Digest Element.........................................6 4.3.3 Algorithm............................................9
3.3 Originator and Recipient Information Elements..........7 4.3.4 Digest...............................................9
3.4 Algorithm Element......................................8 4.3.5 Attribute...........................................10
4. Detailed Signature Syntax...............................8 4.3.6 OriginatorInfo......................................11
4.1 Uniform Resource Names.................................8 4.3.7 RecipientInfo.......................................11
4.2 IotpSignatures.........................................8 4.3.8 KeyIdentifier.......................................12
4.3 Signature Component....................................9 4.3.9 Parameter...........................................13
4.3.1 Signature............................................9 4.4 Certificate Component.................................13
4.3.2 Manifest............................................10 4.4.1 Certificate.........................................13
4.3.3 Algorithm...........................................11 4.4.2 IssuerAndSerialNumber...............................14
4.3.4 Digest..............................................11 4.5 Common Components.....................................15
4.3.5 Attribute...........................................12 4.5.1 Value...............................................15
4.3.6 OriginatorInfo......................................13 4.5.2 Locator.............................................15
4.3.7 RecipientInfo.......................................13 5. Supported Algorithms...................................16
4.3.8 KeyIdentifier.......................................14 5.1 Digest Algorithms.....................................16
4.3.9 Parameter...........................................15 5.1.1 SHA1................................................16
4.4 Certificate Component.................................16 5.1.2 DOM-HASH............................................17
4.4.1 Certificate.........................................16 5.2 Signature Algorithms..................................17
4.4.2 IssuerAndSerialNumber...............................17 5.2.1 DSA.................................................17
4.5 Common Components.....................................17 5.2.2 HMAC................................................18
4.5.1 Value...............................................17 5.2.3 RSA.................................................20
4.5.2 Locator.............................................18 5.2.4 ECDSA...............................................20
5. Supported Algorithms...................................18 6. Examples...............................................21
5.1 Digest Algorithms.....................................18 7. Signature DTD..........................................23
5.1.1 SHA1................................................19 8. Security Considerations................................25
5.1.2 DOM-HASH............................................19 References................................................26
5.2 Signature Algorithms..................................20 Authors' Addresses........................................28
5.2.1 DSA.................................................20 Full Copyright Statement..................................29
5.2.2 HMAC................................................21
5.2.3 RSA.................................................22
5.2.4 ECDSA...............................................23
6. Examples...............................................24
7. Signature DTD..........................................25
8. Security Considerations................................28
Full Copyright Statement..................................28
References................................................29
Author's Addresses........................................31
Expiration and File Name..................................31
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 xxx1]. All IOTP messages are XML documents. XML, documented in [RFC 2801]. All IOTP messages are XML documents. XML,
the Extensible Markup Language [XML], is a syntactical standard the Extensible Markup Language [XML], is a syntactical standard
promulgated by the World Wide Web Consortium. XML is intended promulgated by the World Wide Web Consortium. XML is intended
primarily for structuring data exchanged and served over the World primarily for structuring data 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.
skipping to change at page 8, line 7 skipping to change at page 5, line 49
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 put any type of The Algorithm element is a generalized 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.
4. Detailed Signature Syntax 4. Detailed Signature Syntax
4.1 Uniform Resource Names 4.1 Uniform Resource Names
To prevent potential name conflicts in the definition of the numerous To prevent potential name conflicts in the definition of the numerous
type qualifiers considered herein, this specification uses Uniform type qualifiers considered herein, this specification uses Uniform
skipping to change at page 10, line 4 skipping to change at page 7, line 42
Content Description Content Description
Manifest: A set of attributes that actually constitutes the Manifest: A set of attributes that actually constitutes the
authenticated part of the document. authenticated part of the document.
Value: One or more encodings of signature values. Multiple values Value: One or more encodings of signature values. Multiple values
allow for a multiple algorithms to be supported within a single allow for a multiple algorithms to be supported within a single
signature component. signature component.
Attributes Description Attributes Description
ID: Element identifier that may be used to reference the Signature ID: Element identifier that may be used to reference the Signature
element from a Resource element when implementing endorsement. element from a Resource element when implementing endorsement.
4.3.2 Manifest 4.3.2 Manifest
The Manifest element consists of a collection of attributes that The Manifest element consists of a collection of attributes that
specify such things as as references to the resources being specify such things as references to the resources being
authenticated and an indication of the keying material and algorithms authenticated and an indication of the keying material and algorithms
to be used. to be used.
<!ELEMENT Manifest <!ELEMENT Manifest
( Algorithm+, ( Algorithm+,
Digest+, Digest+,
Attribute*, Attribute*,
OriginatorInfo, OriginatorInfo,
RecipientInfo+, RecipientInfo+,
) )
skipping to change at page 11, line 40 skipping to change at page 9, line 34
per algorithm basis. per algorithm basis.
Attributes Description Attributes Description
ID: The ID of the algorithm is used by the Digest and RecipientInfo ID: The ID of the algorithm is used by the Digest and RecipientInfo
to refer to the signing or digest algorithm used. to refer to the signing or digest algorithm used.
type: The type of algorithm, either a digest or signature. This is type: The type of algorithm, either a digest or signature. This is
implied by the element to which the algorithm is referred. That is, implied by the element to which the algorithm is referred. That is,
if the DigestAlgorithmRef refers to an algorithm, it is implicit by if the DigestAlgorithmRef refers to an algorithm, it is implicit by
reference that the targetted algorithm is a digest. reference that the targeted algorithm is a digest.
name: The type of the algorithm expressed as a Uniform Resource name: The type of the algorithm expressed as a Uniform Resource
Name. Name.
4.3.4 Digest 4.3.4 Digest
The Digest element consists of the fingerprint of a given resource. The Digest element consists of the fingerprint of a given resource.
This element is constructed of two sub-elements. This first one This element is constructed of two sub-elements. This first one
indicates the algorithm to be used for computation of the indicates the algorithm to be used for computation of the
fingerprint. The second element consists of the fingerprint value. fingerprint. The second element consists of the fingerprint value.
skipping to change at page 12, line 9 skipping to change at page 10, line 4
The Digest element consists of the fingerprint of a given resource. The Digest element consists of the fingerprint of a given resource.
This element is constructed of two sub-elements. This first one This element is constructed of two sub-elements. This first one
indicates the algorithm to be used for computation of the indicates the algorithm to be used for computation of the
fingerprint. The second element consists of the fingerprint value. fingerprint. The second element consists of the fingerprint value.
<!ELEMENT Digest (Locator, Value) > <!ELEMENT Digest (Locator, Value) >
<!ATTLIST Digest <!ATTLIST Digest
DigestAlgorithmRef IDREF #REQUIRED DigestAlgorithmRef IDREF #REQUIRED
> >
Content Description Content Description
Locator: Contains a "HREF" or URL Locator for the resources to be Locator: Contains a "HREF" or URL Locator for the resources to be
fingerprinted. For use within IOTP a "scheme" with the value "iotp" fingerprinted. For use within IOTP a "scheme" with the value "iotp"
may be used with the following structure: may be used with the following structure:
'iotp:<globally-unique-tid>#<id-value>'. 'iotp:<globally-unique-tid>#<id-value>'.
This should be interpreted as referring to an element with an ID This should be interpreted as referring to an element with an ID
attribute that matches <id-value> in any IOTP Message that has a attribute that matches <id-value> in any IOTP Message that has a
TransRefBlk Block with an IotpTransId that matches <globally-unique- TransRefBlk Block with an IotpTransId that matches <globally-unique-
tid>. tid>.
If the LocatorHrefBase attribute is set on the Manifest element of If the LocatorHrefBase attribute is set on the Manifest element of
which this Digest element is a child, then concatenate the value of which this Digest element is a child, then concatenate the value of
the LocatorHrefBase attribute with the value of the Locator attribute the LocatorHrefBase attribute with the value of the Locator attribute
before identifying the element that is being referred to. before identifying the element that is being referred to.
If the LocatorHrefBase attribute is omitted, <globally-unique-tid> If the LocatorHrefBase attribute is omitted, <globally-unique-tid>
should be interpreted as the currebt IotpTransId, which is included should be interpreted as the current IotpTransId, which is included
in the IOTP message which contains the Manifest component. in the IOTP message which contains the Manifest component.
Value: Encoding of the fingerprint value. Value: Encoding of the fingerprint value.
Attributes Description Attributes Description
DigestAlgorithmRef: ID Reference of algorithm used for computation of DigestAlgorithmRef: ID Reference of algorithm used for computation of
the digest. the digest.
4.3.5 Attribute 4.3.5 Attribute
skipping to change at page 13, line 10 skipping to change at page 11, line 4
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
type: Type of the attribute. type: Type of the attribute.
critical: Boolean value that indicates if the attribute is critical critical: Boolean value that indicates if the attribute is critical
(true) or not (false). A recipient shall reject a signature that (true) or not (false). A recipient shall reject a signature that
contains a critical attribute that he does not recognise. However, an contains a critical attribute that he does not recognize. However, an
unrecognised non-critical attribute may be ignored. unrecognized non-critical attribute may be ignored.
4.3.6 OriginatorInfo 4.3.6 OriginatorInfo
The OriginatorInfo element is used for providing identification and The OriginatorInfo element is used for providing identification and
keying material information for the originator. keying material information for the originator.
<!ELEMENT OriginatorInfo ANY > <!ELEMENT OriginatorInfo ANY >
<!ATTLIST OriginatorInfo <!ATTLIST OriginatorInfo
OriginatorRef NMTOKEN #IMPLIED OriginatorRef NMTOKEN #IMPLIED
> >
skipping to change at page 15, line 32 skipping to change at page 13, line 25
For IOTP 1.0, the following parameter type is standardized: For IOTP 1.0, the following parameter type is standardized:
"AlgorithmRef". "AlgorithmRef".
An AlgorithmRef contains an ID of a "sub-Algorithm" used when An AlgorithmRef contains an ID of a "sub-Algorithm" used when
computing a sequence of algorithms. For example, a signature computing a sequence of algorithms. For example, a signature
algorithm actually signs a digest algorithm. To specify a chain of algorithm actually signs a digest algorithm. To specify a chain of
algorithms used to compute a signature, AlgorithmRef parameter types algorithms used to compute a signature, AlgorithmRef parameter types
are used in the following manner: are used in the following manner:
<Algorithm ID='A1' type='digest' name='urn:ibm-com:dom-hash'> <Algorithm ID='A1' type='digest' name='urn:ibm-com:dom-hash'>
<Parameter type='AlgorithmRef'>A2</Parameter> <Parameter type='AlgorithmRef'>A2</Parameter>
</Algorithm> </Algorithm>
<Algorithm ID='A2' type='digest' name='urn:nist-gov:sha1'> <Algorithm ID='A2' type='digest' name='urn:nist-gov:sha1'>
</Algorithm> </Algorithm>
<Algorithm ID='A3' type='signature' name='urn:rsasdi-com:rsa-encryption'> <Algorithm ID='A3' type='signature' name='urn:rsasdi-com:rsa-encryption'>
<Parameter type='AlgorithmRef'>A1</Parameter> <Parameter type='AlgorithmRef'>A1</Parameter>
</Algorithm> </Algorithm>
Content Description Content Description
ANY: The contents of a Parameter element consists of ANY valid ANY: The contents of a Parameter element consists of ANY valid
construct, which is specified on a per algorithm per parameter basis. construct, which is specified on a per algorithm per parameter basis.
Attributes Description Attributes Description
type: The type of the parameter expressed as a free form string, type: The type of the parameter expressed as a free form string,
whose value is specified on a per algorithm basis. whose value is specified on a per algorithm basis.
skipping to change at page 16, line 38 skipping to change at page 14, line 30
Value: Encoding of the certificate value. The actual value to be Value: Encoding of the certificate value. The actual value to be
encoded depends upon the type of the certificate. encoded depends upon the type of the certificate.
Locator: XML link element that could be used for retrieving a copy of Locator: XML link element that could be used for retrieving a copy of
the digital certificate. The actual value being returned by means of the digital certificate. The actual value being returned by means of
this locator depends upon the security protocol being used. this locator depends upon the security protocol being used.
Attributes Description Attributes Description
ID: Element identifier that may be used to reference the Cerfiticate ID: Element identifier that may be used to reference the Certificate
element from a RecipientInfo element. element from a RecipientInfo element.
type: Type of the digital certificate. This attribute is specified as type: Type of the digital certificate. This attribute is specified as
a Universal Resource Name. Support for the X.509 version 3 a Universal Resource Name. Support for the X.509 version 3
certificate [X.509] is mandatory in this sepecification if the certificate [X.509] is mandatory in this specification if the
Certificate element is used. The URN for such certificates is Certificate element is used. The URN for such certificates is
"urn:X500:X509v3". "urn:X500:X509v3".
4.4.2 IssuerAndSerialNumber 4.4.2 IssuerAndSerialNumber
The IssuerAndSerialNumber element identifies a certificate, and The IssuerAndSerialNumber element identifies a certificate, and
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 >
skipping to change at page 17, line 45 skipping to change at page 15, line 34
> >
Content Description Content Description
PCDATA: Content value after adequate encoding. PCDATA: Content value after adequate encoding.
Attributes Description Attributes Description
encoding: This attribute specifies the decoding scheme to be encoding: This attribute specifies the decoding scheme to be
employed for recovering the original byte stream from the content of employed for recovering the original byte stream from the content of
the element. This document recognises the following two schemes: the element. This document recognizes the following two schemes:
none: the content has not been subject to any particular encoding. none: the content has not been subject to any particular encoding.
This does not preclude however the use of native XML encoding such as This does not preclude however the use of native XML encoding such as
CDATA section or XML escaping. CDATA section or XML escaping.
base64: The content has been encoded by means of the base64 encoding base64: The content has been encoded by means of the base64 encoding
scheme. scheme.
4.5.2 Locator 4.5.2 Locator
skipping to change at page 19, line 27 skipping to change at page 17, line 11
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 [RFC of the hash value of the nodes that constitute the DOM tree [RFC
xxx2]. This algorithm has many applications such as computation of 2803]. This algorithm has many applications such as computation of
digital signature and synchronization of DOM trees. However, because digital signature and synchronization of DOM trees. However, because
the hash value of an element is computed from the hash values of the the hash value of an element is computed from the hash values of the
inner elements, this algorithm is better adapted to small documents inner elements, this algorithm is better adapted to small documents
that do 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
skipping to change at page 20, line 28 skipping to change at page 18, line 11
Public-key signature algorithm proposed by NIST for use with the Public-key signature algorithm proposed by NIST for use with the
Digital Signature Standard. This standard is documented in NIST FIPS Digital Signature Standard. This standard is documented in NIST FIPS
Publication 186 [DSS] and ANSI X9.30 [X9.30]. Publication 186 [DSS] and ANSI X9.30 [X9.30].
The DSA algorithm requires a single parameter, which includes the The DSA algorithm requires a single parameter, which includes the
canonical digest algorithm to be used for computing the fingerprint canonical digest algorithm to be used for computing the fingerprint
of the signature Manifest. of the signature Manifest.
The DSA URN used in this specification is "urn:nist-gov:dsa". The DSA URN used in this specification is "urn:nist-gov:dsa".
The DSA uses a canonical or surfce-string digest algorithm for The DSA uses a canonical or surface-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 [RFC 2437] 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 et 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))
This specification also considered HMAC output truncation such as This specification also considered HMAC output truncation such as
proposed by Preneel and van Oorschot. In their paper [PV] these two proposed by Preneel and van Oorschot. In their paper [PV] these two
researchers have shown some analytical advantages of truncating the researchers have shown some analytical advantages of truncating the
output of hash-based MAC functions. Such output truncation is also output of hash-based MAC functions. Such output truncation is also
considered in the RFC document. considered in the RFC document.
HMAC requires three parameters. The first one consists of a canonical HMAC requires three parameters. The first one consists of a canonical
digest algorithm. The second one consists of a hash function. The digest algorithm. The second one consists of a hash function. The
last one is optional and specifies the length in bit of the truncated last one is optional and specifies the length in bit of the truncated
skipping to change at page 22, line 7 skipping to change at page 19, line 38
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 [RFC 2437] specification with a k parameter equals to to PKCS#1 [RFC 2437] specification with a k parameter equals to
((Hlen +7) mod8), Mlen being the length in bits of the MAC value. ((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
skipping to change at page 22, line 36 skipping to change at page 20, line 24
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.
Specifications Specifications
The RSA URN used in this specification is "urn:rsasdi-com:rsa- The RSA URN used in this specification is "urn:rsasdi-com:rsa-
encription". encription".
The RSA uses a canonical or surfce-string digest algorithm for The RSA uses a canonical or surface-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 single octet-stream. No The output of this algorithm consists of single octet-stream. No
further encoding is required. further encoding is required.
Example Example
<Algorithm name='urn:rsasdi-com:rsa-encription' <Algorithm name='urn:rsasdi-com:rsa-encription'
type='signature' ID='P.3'> 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.4 ECDSA 5.2.4 ECDSA
Public-key signature algorithm proposed independently by Neil Koblitz Public-key signature algorithm proposed independently by Neil Koblitz
and Victor Miller. This algorithm is being proposed as an ANSI and Victor Miller. This algorithm is being proposed as an ANSI
standard and is documented in ANSI X9.62 standard proposal [X9.62] standard and is documented in ANSI X9.62 standard proposal [X9.62]
and IEEE/P1363 standard draft proposal [IEEE P1363]. and IEEE/P1363 standard draft proposal [IEEE P1363].
skipping to change at page 23, line 24 skipping to change at page 21, line 13
and IEEE/P1363 standard draft proposal [IEEE P1363]. and IEEE/P1363 standard draft proposal [IEEE P1363].
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 surface-string digest algorithm for
computation of the Manifest fingerprint. The DOM-HASH [RFC xxx2] is computation of the Manifest fingerprint. The DOM-HASH [RFC 2803] is
recommended 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 [RFC 2437] 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'>
</Algorithm> </Algorithm>
6. Examples 6. Examples
The following is an example signed IOTP message: The following is an example signed IOTP message:
skipping to change at page 24, line 29 skipping to change at page 22, line 11
</MsgId> </MsgId>
</TransRefBlk> </TransRefBlk>
<IotpSignatures> <IotpSignatures>
<Signature> <Signature>
<Manifest> <Manifest>
<Algorithm name='urn:nist-gov:sha1' <Algorithm name='urn:nist-gov:sha1'
type='digest' ID='P.3'> type='digest' ID='P.3'>
</Algorithm> </Algorithm>
<Algorithm name='urn:nist-gov:dsa' <Algorithm name='urn:nist-gov:dsa'
type='signature' ID='P.4'> type='signature' ID='P.4'>
<Parameter type="AlgorithmRef">P.5</Parameter> <Parameter type='AlgorithmRef'>P.5</Parameter>
</Algorithm> </Algorithm>
<Algorithm name='urn:ibm-com:dom-hash' <Algorithm name='urn:ibm-com:dom-hash'
type='digest' ID='P.5'> type='digest' ID='P.5'>
<Parameter type='AlgorithmRef'>P.3</Parameter> <Parameter type='AlgorithmRef'>P.3</Parameter>
</Algorithm> </Algorithm>
<Digest DigestAlgorithmRef='P.6'> <Digest DigestAlgorithmRef='P.6'>
<Locator href='P.1'/> <Locator href='P.1'/>
<Value> <Value>
xsqsfasDys2h44u4ehJDe54he5j4dJYTJ xsqsfasDys2h44u4ehJDe54he5j4dJYTJ
</Value> </Value>
skipping to change at page 28, line 9 skipping to change at page 25, line 31
<!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
This entire document concerns the IOTP v1 protocol signature element This entire document concerns the IOTP v1 protocol signature element
which is used for authentication. See the Security Considerations which is used for authentication. See the Security Considerations
section of [RFC xxxx] "Internet Open Trading Protocol - IOTP, Version section of [RFC 2801] "Internet Open Trading Protocol - IOTP, Version
1.0". 1.0".
Full Copyright Statement References
Copyright (C) The Internet Society 1999. [DSA] Federal Information Processing Standards Publication
FIPS PUB 186, "Digital Signature Standard(DSS)", 1994,
<http://csrc.nist.gov>
This document and translations of it may be copied and furnished to [IEEE P1363] IEEE P1363, "Standard Specifications for Public-Key
others, and derivative works that comment on or otherwise explain it Cryptography", Work in Progress, 1997,
or assist in its implementation may be prepared, copied, published <http://stdsbbs.ieee.org/>
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be [PV] Preneel, B. and P. van Oorschot, "Building fast MACs
revoked by the Internet Society or its successors or assigns. from hash functions", Advances in Cryptology --
CRYPTO'95 Proceedings, Lecture Notes in Computer
Science, Springer-Verlag Vol.963, 1995, pp. 1-14.
This document and the information contained herein is provided on an [RFC 1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 1321, April 1992.
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
References [RFC 2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail
Extensions (MIME) Part One: Format of Internet Message
Bodies", RFC 2045, November 1996.
[DSA] - Federal Information Processing Standards Plublication FIPS [RFC 2046] Freed N. and N. Borenstein, "Multipurpose Internet Mail
PUB 186, "Digital Signature Standard(DSS)", 1994, Extensions (MIME) Part Two: Media Types", RFC 2046,
<http://csrc.nist.gov> November 1996.
[IEEE P1363] - IEEE P1363, "Standard Specifications for Public-Key [RFC 2104] Krawczyk, H., Bellare, M. and R. Canetti, "HMAC: Keyed-
Cryptography", draft, 1997, <http://stdsbbs.ieee.org/> Hashing for Message Authentication", RFC 2104, February
1997.
[PV] - B. Preneel and P. van Oorschot, "Building fast MACs from hash [RFC 2141] Moats, R., "URN Syntax", RFC 2141, May 1997.
functions", Advances in Cryptology -- CRYPTO'95 Proceedings, Lecture
Notes in Computer Science, Springer-Verlag Vol.963, 1995, pp. 1-14.
[RFC 1321] - R. Rivest, "The MD5 Message-Digest Algorithm", April [RFC 2253] Wahl, W., Kille, S. and T. Howes, "Lightweight Directory
1992. Access Protocol (v3): UTF-8 String Representation of
Distinguished Names", RFC 2253, December 1997.
[RFC 2045]- N. Freed & N. Borenstein, "Multipurpose Internet Mail [RFC 2396] Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform
Extensions (MIME) Part One: Format of Internet Message Bodies", Resource Identifiers (URI): Generic Syntax", RFC 2396,
November 1996. August 1998.
[RFC 2046] - N. Freed & N. Borenstein, "Multipurpose Internet Mail [RFC 2437] Kaliski, B. and J. Staddon, "PKCS #1: RSA Cryptography
Extensions (MIME) Part Two: Media Types", November 1996. Specifications, Version 2.0", RFC 2437, October 1998.
[RFC 2104] - H. Krawczyk, M. Bellare, R. Canetti, "HMAC: Keyed- [RFC 2801] Burdett, D., "Internet Open Trading Protocol - IOTP,
Hashing for Message Authentication", February 1997. Version 1.0", RFC 2801, April 2000.
[RFC 2141] - R. Moats, "URN Syntax", May 1997. [RFC 2803] Maruyama, H., Tamura, K. and N. Uramot, "Digest Values
for DOM (DOMHASH)", RFC 2803, April 2000.
[RFC 2253] - W. Wahl, S. Kille, T. Howes, "Lightweight Directory [Schneier] Bruce Schneier, "Applied Cryptography: Protocols,
Access Protocol (v3): UTF-8 String Representation of Distinguished Algorithms, and Source Code in C", 1996, John Wiley and
Names", December 1997. Sons
[RFC 2396] - T. Berners-Lee, R. Fielding, L. Masinter, "Uniform [SHA1] NIST FIPS PUB 180-1, "Secure Hash Standard," National
Resource Identifiers (URI): Generic Syntax", August 1998. Institute of Standards and Technology, U.S. Department
of Commerce, April 1995.
[RFC 2437] - B. Kaliski, J. Staddon, "PKCS #1: RSA Cryptography [X.509] ITU-T Recommendation X.509 (1997 E), "Information
Specifications, Version 2.0", October 1998. Technology - Open Systems Interconnection - The
Directory: Authentication Framework", June 1997.
[RFC xxx1] - D. Burdett, "Interenet Open Trading Protocol - IOTP, [X9.30] ASC X9 Secretariat: American Bankers Association,
Version 1.0", September 1999. (currently draft-ietf-trade-iotp-v1.0- "American National Standard for Financial Services -
protcool-*.txt) Public Key Cryptography Using Irreversible Algorithms
for the Financial Services Industry - Part 1: The
Digital Signature Algorithm(DSA)", 1995.
[RFC xxx2] - H. Maruyama, K. Tamura, & N. Uramot, "Digest Values for [X9.62] ASC X9 Secretariat: American Bankers
DOM (DOMHASH)", September 1999. (currently draft-ietf-trade-hiroshi- Association,"American National Standard for Financial
dom-hash-*.txt) Services - Public Key Cryptography Using Irreversible
Algorithms for the Financial Services Industry - The
Elliptic Curve Digital Signature Algorithm (ECDSA)",
Work in Progress, 1997.
[Schneier] - Bruce Schneier, "Applied Cryptography: Protocols, [XLink] Eve Maler, Steve DeRose, "XML Linking Language (XLink)",
Algorithms, and Source Code in C", 1996, John Wiley and Sons <http://www.w3.org/TR/1998/WD-xlink-19980303>
[SHA1] - NIST FIPS PUB 180-1, "Secure Hash Standard," National [XML] Tim Bray, Jean Paoli, C. M. Sperber-McQueen, "Extensible
Institute of Standards and Technology, U.S. Department of Commerce, Markup Language (XML) 1.0",
April 1995. <http://www.w3.org/TR/1998/REC-xml-19980210>
[X.509] - ITU-T Recommendation X.509 (1997 E), "Information Authors' Addresses
Technology - Open Systems Interconnection - The Directory:
Authentication Framework", June 1997.
[X9.30] - ASC X9 Secretariat: American Bankers Association, "American The authors of this document are:
National Standard for Financial Services - Public Key Cryptography
Using Irreversible Algorithms for the Financial Services Industry -
Part 1: The Digital Signature Algorithm(DSA)", 1995.
[X9.62] - ASC X9 Secretariat: American Bankers Association,"American Kent M. Davidson
National Standard for Financial Services - Public Key Cryptography Differential, Inc.
Using Irreversible Algorithms for the Financial Services Industry - 440 Clyde Ave.
The Elliptic Curve Digital Signature Algorithm (ECDSA)", draft, 1997. Mountain View, CA 94043 USA
[XLink] - Eve Maler, Steve DeRose, "XML Linking Language (XLink)", EMail: kent@differential.com
<http://www.w3.org/TR/1998/WD-xlink-19980303>
[XML] - Tim Bray, Jean Paoli, C. M. Sperber-McQueen, "Extensible Yoshiaki Kawatsura
Markup Language (XML) 1.0", <http://www.w3.org/TR/1998/REC-xml- Hitachi, Ltd.
19980210> 890-12 Kashimada Saiwai Kawasaki,
Kanagawa 2128567 Japan
Author's Addresses EMail: kawatura@bisd.hitachi.co.jp
The authors of this document are: Full Copyright Statement
Kent M. Davidson Copyright (C) The Internet Society (2000). All Rights Reserved.
Differential, Inc.
440 Clyde Ave.
Mountain View, CA 94043 USA
email: kent@differential.com
Yoshiaki Kawatsura This document and translations of it may be copied and furnished to
Hitachi, Ltd. others, and derivative works that comment on or otherwise explain it
890-12 Kashimada Saiwai Kawasaki, or assist in its implementation may be prepared, copied, published
Kanagawa 2118567 Japan and distributed, in whole or in part, without restriction of any
email: kawatura@bisd.hitachi.co.jp kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
Expiration and File Name The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
This draft expires May 2000. This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Its file name is draft-ietf-trade-iotp-v1.0-dsig-05.txt. Acknowledgement
Funding for the RFC Editor function is currently provided by the
Internet Society.
 End of changes. 73 change blocks. 
226 lines changed or deleted 192 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/