draft-ietf-trade-iotp-v1.0-dsig-00.txt   draft-ietf-trade-iotp-v1.0-dsig-01.txt 
TRADE Working Group Kent Davidson TRADE Working Group Kent Davidson
INTERNET-DRAFT Differential INTERNET-DRAFT Differential
Expires: August 1999 February 1999 Yoshiai Kawatsura
Hitachi
Expires: February 2000 August 1999
Digital Signatures for the Internet Open Trading Protocol Digital Signatures for the Internet Open Trading Protocol (IOTP)
------- ---------- --- --- -------- ---- ------- -------- ------- ---------- --- --- -------- ---- ------- -------- ------
Status of This Document Status of This Document
This draft, file name draft-ietf-trade-iotp-v1.0-dsig-00.txt, is an This draft, file name draft-ietf-trade-iotp-v1.0-dsig-01.txt, is a
addendum to the Internet Open Trading Protocol Specification version part of the Internet Open Trading Protocol Specification version 1.0,
1.0, and is intended to become an Informational RFC. Distribution of and is intended to become an Informational RFC. Distribution of this
this document is unlimited. Comments should be sent to the TRADE document is unlimited. Comments should be sent to the TRADE working
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 on ftp.is.co.za (Africa), ftp.nordu.net (Northern
Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au (Pacific The list of Internet-Draft Shadow Directories can be accessed at
Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu (US West Coast). 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).
Table of Contents Table of Contents
Status of This Document....................................1 Status of This Document....................................1
skipping to change at page 2, line 19 skipping to change at page 2, line 19
Table of Contents..........................................2 Table of Contents..........................................2
1. Introduction............................................3 1. Introduction............................................3
2. Objective and Requirements..............................3 2. Objective and Requirements..............................3
3. Signature Basics........................................4 3. Signature Basics........................................4
3.1 Signature Element......................................4 3.1 Signature Element......................................4
3.2 Digest Element.........................................4 3.2 Digest Element.........................................4
3.3 Originator and Recipient Information Elements..........5 3.3 Originator and Recipient Information Elements..........5
3.4 Algorithm Element......................................6
4. Detailed Signature Syntax...............................6 4. Detailed Signature Syntax...............................6
4.1 Uniform Resource Names.................................6 4.1 Uniform Resource Names.................................6
4.2 IOTPSignatures.........................................6 4.2 IOTPSignatures.........................................6
4.3 Signature Component....................................7 4.3 Signature Component....................................7
4.3.1 Signature............................................7 4.3.1 Signature............................................7
4.3.2 Manifest.............................................7 4.3.2 Manifest.............................................8
4.3.3 Algorithm............................................8 4.3.3 Algorithm............................................9
4.3.4 Digest...............................................9 4.3.4 Digest...............................................9
4.3.5 Attributes..........................................10 4.3.5 Attribute...........................................10
4.3.6 Attribute...........................................10 4.3.6 OriginatorInfo......................................11
4.3.7 OriginatorInfo......................................10 4.3.7 RecipientInfo.......................................11
4.3.8 RecipientInfo.......................................11 4.3.8 Parameter...........................................12
4.3.9 Parameter...........................................12
4.4 Certificate Component.................................13 4.4 Certificate Component.................................13
4.4.1 Certificate.........................................13 4.4.1 Certificate.........................................13
4.4.2 IssuerAndSerialNumber...............................13 4.4.2 IssuerAndSerialNumber...............................14
4.5 Common Components.....................................14 4.5 Common Components.....................................14
4.5.1 Value...............................................14 4.5.1 Value...............................................14
4.5.2 Locator.............................................15 4.5.2 Locator.............................................15
5. Supported Algorithms...................................15 5. Supported Algorithms...................................15
5.1 Digest Algorithms.....................................15 5.1 Digest Algorithms.....................................16
5.1.1 DOM-HASH............................................16 5.1.1 DOM-HASH............................................16
5.1.2 SHA1................................................16 5.1.2 SHA1................................................16
5.1.3 MD5.................................................16 5.1.3 MD5.................................................17
5.2 Signature Algorithms..................................16 5.2 Signature Algorithms..................................17
5.2.1 DSA.................................................17 5.2.1 DSA.................................................17
5.2.2 HMAC................................................17 5.2.2 HMAC................................................17
5.2.3 RSA.................................................17 5.2.3 RSA.................................................17
6. Examples...............................................17 6. Examples...............................................17
7. Signature DTD..........................................19 7. Signature DTD..........................................19
8. References.............................................21
9. Credits................................................22 8. Security Considerations................................22
Expiration and File Name..................................22 9. References.............................................22
9. Author's Addresses.....................................23
Expiration and File Name..................................23
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 draft-ietf-trade-iotp-v1.0-protocol-*.txt. All IOTP documented in [RFC xxx, draft-ietf-trade-iotp-v1.0-protocol-*.txt].
messages are XML documents. XML, the Extensible Markup Language All IOTP messages are XML documents. XML, the Extensible Markup
[XML], is a syntactical standard promulgated by the World Wide Web Language [XML], is a syntactical standard promulgated by the World
Consortium. XML is intended primarily for structuring data exchanged Wide Web Consortium. XML is intended primarily for structuring data
and served over the World Wide Web. exchanged and served over the World 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
messages specifically for Version 1.0 of the IOTP protocol. The messages specifically for Version 1.0 of the IOTP protocol. The
reader should recognize that an effort towards general XML digital reader should recognize that an effort towards general XML digital
signatures exists but is unlikely to produce its final result in time signatures exists but is unlikely to produce its final result in time
for IOTP Version 1.0. Future versions of IOTP will probably just for IOTP Version 1.0. Future versions of IOTP will probably just
adopt by reference the results of this general XML digital signature adopt by reference the results of this general XML digital signature
effort. effort.
The objective of this document is to propose syntax and procedures The objective of this document is to propose syntax and procedures
for the computation and verification of digital signatures applicable for the computation and verification of digital signatures applicable
to Verion 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 a signed portions of IOTP message to be "forwarded" to
another trading roles with different signature algorithms than the another trading roles with different signature algorithms than the
skipping to change at page 4, line 25 skipping to change at page 4, line 25
second sub-element consists of the digital signature value. second sub-element consists of the digital signature value.
<Signature> <Signature>
<Manifest> <Manifest>
(resource information block) (resource information block)
(originator information block) (originator information block)
(recipient information block) (recipient information block)
(other attributes) (other attributes)
(signature algorithms information block) (signature algorithms information block)
</Manifest> </Manifest>
<Value encoding= "encoding scheme"> <Value encoding 'encoding scheme'>
(encoded signature value) (encoded signature value)
<Value> <Value>
</Signature> </Signature>
The digital signature is not computed directly from the pieces of The digital signature is not computed directly from the pieces of
information to be authenticated. Instead, the digital signature is information to be authenticated. Instead, the digital signature is
computed from a set of authenticated attributes (the Manifest), which computed from a set of authenticated attributes (the Manifest), which
include references to, and a digests of, those pieces of information. include references to, and a digests of, those pieces of information.
The authentication is therefore "indirect". The authentication is therefore "indirect".
3.2 Digest Element 3.2 Digest Element
The Digest element consists of a unique and unambiguous reference to The Digest element consists of a unique and unambiguous reference to
the XML resources being authenticated. It is constructed of a locator the XML resources being authenticated. It is constructed of a locator
and the digest value data itself. The Digest algorithm is referred to and the digest value data itself. The Digest algorithm is referred to
indirectly via a DigestAlgorithmRef, so that Digest algorithms may be indirectly via a DigestAlgorithmRef, so that Digest algorithms may be
shared by multiple resources. shared by multiple resources.
<Resource> <Digest DigestAlgorithmRef 'D.1'>
<Locator href= "resource locator"/> <Locator href 'resource locator'/>
<Digest DigestAlgorithmRef=D.1> <Value>
(digest information block) (Digest value)
</Value>
</Digest> </Digest>
</Resource>
The resource locator is implemented as a simple XML Link [XLink]. The resource locator is implemented as a simple XML Link [XLink].
This not only provides a unique addressing scheme for internal and This not only provides a unique addressing scheme for internal and
external resources, but also facilitates authentication of composite external resources, but also facilitates authentication of composite
documents. documents.
3.3 Originator and Recipient Information Elements 3.3 Originator and Recipient Information Elements
The purpose of the Originator and Recipient information elements is The purpose of the Originator and Recipient information elements is
providing identification and keying material for these respective providing identification and keying material for these respective
parties. parties.
skipping to change at page 6, line 5 skipping to change at page 6, line 5
for a particular recipient. A unique reference in the Recipient for a particular recipient. A unique reference in the Recipient
information block helps the recipients identify their respective information block helps the recipients identify their respective
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
The Algorithm element is a generalised place to place any type of The Algorithm element is a generalised place to place 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
skipping to change at page 6, line 33 skipping to change at page 6, line 35
Resource Names [RFC 2141]. Resource Names [RFC 2141].
4.2 IOTPSignatures 4.2 IOTPSignatures
The IOTPSignatures element is the top-level element in an IOTP The IOTPSignatures element is the top-level element in an IOTP
signature block. It consists of a collection of Signature elements, signature block. It consists of a collection of Signature elements,
and an optional set of Certificates. and an optional set of Certificates.
<!ELEMENT IOTPSignatures (Signature+, Certificate*) > <!ELEMENT IOTPSignatures (Signature+, Certificate*) >
<!ATTLIST IOTPSignatures <!ATTLIST IOTPSignatures
ID ID #IMPLIED > id ID #IMPLIED >
Content Description Content Description
Signature: A collection of Signature elements. Signature: A collection of Signature elements.
Certificate: Zero or more certificates used for signing Certificate: Zero or more certificates used for signing
Attributes Description Attributes Description
ID: Element identifier that may be used to referencing the entire ID: Element identifier that may be used to referencing the entire
skipping to change at page 7, line 15 skipping to change at page 7, line 15
4.3 Signature Component 4.3 Signature Component
4.3.1 Signature 4.3.1 Signature
The Signature element constitutes the majority of this specification. The Signature element constitutes the majority of this specification.
It is comprised of two sub-elements. The first one is a set of It is comprised of two sub-elements. The first one is a set of
attributes, known as the Manifest, which actually constitutes the attributes, known as the Manifest, which actually constitutes the
authenticated part of the document. The second sub-element consists authenticated part of the document. The second sub-element consists
of the signature value or values. of the signature value or values.
The Value element contained within the Signature element is the
encoded form of the signature of the Manifest element, and thus
provides the verification of the Manifest.
The process for generating the signed value is a multi-step process,
involving a canonicalization algorithm, a digest algorithm, and a
signature algorithm.
First, the Manifest is canonicalized with an algorithm specified
within the Algorithm element of the Manifest. The canonicalized form
removes any inconsistencies in white space introduced by XML parsing
engines.
This canonicalized form is then converted into a digest form which
uniquely identifies the canoicalized document. Any slight
modification in the original document will result in a very different
digest value.
Finally, the digest is then signed using a public-key algorithm which
digitally stamps the digest with the certificate of the signer. The
final signed digest is the value which is stored within the
Signature's Value element.
<!ELEMENT Signature (Manifest, Value+) > <!ELEMENT Signature (Manifest, Value+) >
<!ATTLIST Signature <!ATTLIST Signature
ID ID #IMPLIED > ID ID #IMPLIED >
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
skipping to change at page 7, line 43 skipping to change at page 8, line 17
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 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+,
Attributes?, Attribute*,
OriginatorInfo, OriginatorInfo,
RecipientInfo+, RecipientInfo+,
) )
<!ATTLIST Manifest <!ATTLIST Manifest
LocatorHRefBase CDATA #IMPLIED LocatorHRefBase CDATA #IMPLIED
> >
Content Description Content Description
Algorithm: A list of algorithms used for signing, digest computation, Algorithm: A list of algorithms used for signing, digest computation,
and canonicalization. and canonicalization.
Digest: A list of digests of resources to be authentication and Digest: A list of digests of resources to be authentication and
signed. signed.
Attributes: Optional element that consists of a collection of Attribute: Optional element that consists of a collection of
complementary attributes to be authenticated. complementary attributes to be authenticated.
OriginatorInfo: Element that provides identification and keying OriginatorInfo: Element that provides identification and keying
material information related to the originator. material information related to the originator.
RecipientInfo: Optional element that provides identification and RecipientInfo: Optional element that provides identification and
keying material information related to the recipient. keying material information related to the recipient.
Attributes Description Attributes Description
LocatorHrefBase: The LocatorHrefBase provides a similar construct to LocatorHrefBase: The LocatorHrefBase provides a similar construct to
the HTML HREFBASE attribute and implicitly sets all relative URL the HTML HREFBASE attribute and implicitly sets all relative URL
references within the Manifest to be relative to the HrefBase. For references within the Manifest to be relative to the HrefBase. For
example, the IOTP Manifest may contain: example, the IOTP Manifest may contain:
<Manifest <Manifest
LocatorHrefBase='iotp:globally-unique-tid#> LocatorHrefBase='iotp:globally-unique-tid#'>
And subsequent Locators may be: And subsequent Locators may be:
<Locator href="C.9"> <Locator href='C.9'>
An implementation should concatenate the two locator references to An implementation should concatenate the two locator references to
create the entire URL. create the entire URL.
4.3.3 Algorithm 4.3.3 Algorithm
This specification uses an Algorithm data type which indicates many This specification uses an Algorithm data type which indicates many
different types of algoirithms. The Algorithm element allows for different types of algoirithms. The Algorithm element allows for
specification of sub-algorithms as parameters of the primary specification of sub-algorithms as parameters of the primary
algorithm. This is performed via a parameter within the algorithm algorithm. This is performed via a parameter within the algorithm
that provides a reference to another Algorithm. An example of this is that provides a reference to another Algorithm. An example of this is
shown in the Parameter section. shown in the Parameter section.
<!ELEMENT Algorithm (Parameter*) > <!ATTRLIST Algorithm <!ELEMENT Algorithm (Parameter*) >
<!ATTLIST Algorithm
id ID #REQUIRED id ID #REQUIRED
type (digest|signature) #IMPLIED type (digest|signature) #IMPLIED
name NMTOKEN #REQUIRED > name NMTOKEN #REQUIRED >
Content Description Content Description
Parameter: The contents of an Algorithm element consists of an Parameter: The contents of an Algorithm element consists of an
optional collection of Parameter elements which are specified on a optional collection of Parameter elements which are specified on a
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.
skipping to change at page 10, line 5 skipping to change at page 10, line 23
Locator: Contains a "HREF" or URL locator for the resource to be Locator: Contains a "HREF" or URL locator for the resource to be
fingerprinted. References to IOTP messages. fingerprinted. References to IOTP messages.
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 Attributes 4.3.5 Attribute
The Attributes element consists of a collection of complementary
attributes, which are included in the authenticated part of the
document. This is the area where a specific IOTP implementation may
include custom attributes which must be authenticated directly.
<!ELEMENT Attributes (Attribute+ )>
Content Description
Attribute: Collection of Attribute elements.
4.3.6 Attribute
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. An Attribute element level of customization in the signature element. This is the area
consists of a value, a type, and a criticality. where a specific IOTP implementation may include custom attributes
which must be authenticated directly. An Attribute element consists
of a value, a type, and a criticality.
At this time, no IOTP specific attributes are specified. 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
skipping to change at page 10, line 47 skipping to change at page 11, line 6
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 recognise. However, an
unrecognised non-critical attribute may be ignored. unrecognised non-critical attribute may be ignored.
4.3.7 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
> >
Content Description Content Description
ANY: Identification and keying material information may consist of ANY: Identification and keying material information may consist of
ANY construct. Such a definition allows the adoption of ANY construct. Such a definition allows the adoption of
application-specific schemes. Attributes Description application-specific schemes.
Attributes Description
OriginatorRef: A reference to the IOTP Org ID of the originating OriginatorRef: A reference to the IOTP Org ID of the originating
signer. signer.
4.3.8 RecipientInfo 4.3.7 RecipientInfo
The RecipientInfo element is used for providing identification and The RecipientInfo element is used for providing identification and
keying material information for the recipient. This element is used keying material information for the recipient. This element is used
either for enabling recognition of a Signature element by a given either for enabling recognition of a Signature element by a given
recipient or when determination of the authentication key consists of recipient or when determination of the authentication key consists of
the combination of keying material provided by both the recipient and the combination of keying material provided by both the recipient and
the originator. the originator.
The RecipientInfo attributes provide a centralized location where The RecipientInfo attributes provide a centralized location where
signatures, algorithms, and certificates intended for a particular signatures, algorithms, and certificates intended for a particular
recipient are specified. recipient are specified.
The signature certificate reference ID MUST point to a certificate The signature certificate reference ID MUST point to a certificate
object. object.
<!ELEMENT RecipientInfo ANY > <!ELEMENT RecipientInfo ANY >
<!ATTLIST RecipientInfo <!ATTLIST RecipientInfo
SignatureAlgorithmRef IDREF #REQUIRED SignatureAlgorithmRef IDREF #REQUIRED
SignatureValueRef IDREF #REQUIRED SignatureValueRef IDREF #IMPLIED
SignatureCertRef IDREF #IMPLIED SignatureCertRef IDREF #IMPLIED
RecipientRefs NMTOKENS #IMPLIED RecipientRefs NMTOKENS #IMPLIED
> >
Content Description Content Description
ANY: Identification and keying material information may consist of ANY: Identification and keying material information may consist of
ANY construct. ANY construct.
Attributes Description Attributes Description
SignatureAlgorithmRef: A reference to the signature algorithm used to SignatureAlgorithmRef: A reference to the signature algorithm used to
sign the SignatureValueRef intended for this recipient. The signature sign the SignatureValueRef intended for this recipient. The signature
algorithm reference ID MUST point to a signature algorithm within the algorithm reference ID MUST point to a signature algorithm within the
Manifest. Manifest.
SignatureValueRef: A reference to the signature value for this SignatureValueRef: A reference to the signature value for this
recipient. The signature value reference ID MUST point to a value recipient. The signature value reference ID MUST point to a value
structure directly included within a Manifest. structure directly included within a Manifest. This reference can be
omitted if the application can specify the digest value.
SignatureCertRef: A reference to the certificate used to sign the SignatureCertRef: A reference to the certificate used to sign the
Value pointed to by the SignatureValueRef. Value pointed to by the SignatureValueRef. This reference can be
omitted if the application can identify the certificate.
RecipientRefs: A list of references to the IOTP Org ID of the RecipientRefs: A list of references to the IOTP Org ID of the
recipients this signature is intended for. recipients this signature is intended for.
4.3.9 Parameter 4.3.8 Parameter
A Parameter element provides the value of a particular algorithm A Parameter element provides the value of a particular algorithm
parameter, whose name and format have been specified for the parameter, whose name and format have been specified for the
algorithm considered. algorithm considered.
<!ELEMENT Parameter ANY > <!ELEMENT Parameter ANY >
<!ATTLIST Parameter <!ATTLIST Parameter
type PCDATA #REQUIRED type CDATA #REQUIRED
> >
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:dom-hash"> <Algorithm ID A1 type 'digest' name 'urn:ibm:dom-hash'>
<Parameter type='AlgorithmRef'>A2</Parameter> <Parameter type 'AlgorithmRef'>A2</Parameter>
</Algorithm> </Algorithm>
<Algorithm ID=A2 type="digest" name="urn:fips:sha1"> <Algorithm ID A2 type 'digest' name 'urn:fips:sha1'>
</Algorithm> </Algorithm>
<Algorithm ID=A3 type="signature" name="urn:ibm:hmac"> <Algorithm ID A3 type 'signature' name 'urn:ibm:hmac'>
<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.
4.4 Certificate Component 4.4 Certificate Component
4.4.1 Certificate 4.4.1 Certificate
The Certificate element may be used for either providing the value of The Certificate element may be used for either providing the value of
a digital certificate or specifying a location from where it may be a digital certificate or specifying a location from where it may be
retrieved. retrieved.
skipping to change at page 13, line 16 skipping to change at page 13, line 36
4.4 Certificate Component 4.4 Certificate Component
4.4.1 Certificate 4.4.1 Certificate
The Certificate element may be used for either providing the value of The Certificate element may be used for either providing the value of
a digital certificate or specifying a location from where it may be a digital certificate or specifying a location from where it may be
retrieved. retrieved.
<!ELEMENT Certificate <!ELEMENT Certificate
( IssuerAndSerialNumber ( IssuerAndSerialNumber,
( Value | Locator ) ) ( Value | Locator ) )
> >
<!ATTLIST Certificate <!ATTLIST Certificate
ID ID #IMPLIED id ID #IMPLIED
type NMTOKEN #REQUIRED > type NMTOKEN #REQUIRED >
Content Description Content Description
IssuerAndSerialNumber: Unique identifier of this certificate. This IssuerAndSerialNumber: Unique identifier of this certificate. This
element has been made mandatory is order to prevent unnecessary element has been made mandatory is order to prevent unnecessary
decoding during validation of a certificate chain. This feature also decoding during validation of a certificate chain. This feature also
helps certificates caching, especially when the value is not directly helps certificates caching, especially when the value is not directly
provided. provided.
skipping to change at page 14, line 25 skipping to change at page 14, line 43
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.
<!ELEMENT Value ( #PCDATA ) > <!ATTLIST Value <!ELEMENT Value ( #PCDATA ) >
<!ATTLIST Value
id ID #IMPLIED id ID #IMPLIED
encoding (base64|none) #IMPLIED 'base64' > encoding (base64|none) #IMPLIED 'base64'
>
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 recognises the following two schemes:
skipping to change at page 16, line 18 skipping to change at page 16, line 37
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. of the hash value of the nodes that constitute the DOM tree.
The DOM-HASH algorithm requires a single parameter, which shall The DOM-HASH algorithm requires a single parameter, which shall
consist of a surface string digest algorithm such as SHA1. consist of a surface string digest algorithm such as SHA1.
The DOM-HASH URN used for this specification is "urn:ibm:dom-hash". The DOM-HASH URN used for this specification is "urn:ibm:dom-hash".
Example Example
<Algorithm name="urn:ibm:dom-hash" type=digest> <Algorithm name='urn:ibm:dom-hash' type='digest'>
</Algorithm> </Algorithm>
5.1.2 SHA1 5.1.2 SHA1
Surface string digest algorithm designed by hte US government for use Surface string digest algorithm designed by the US government for use
with the Digital Signature Standard. This algorithm produces a 160- with the Digital Signature Standard. This algorithm produces a 160-
bit hash value. bit hash value.
This algorithm does not require any parameter. This algorithm does not require any parameter.
The SHA1 URN used for this specification is "urn:fips:sha1". The SHA1 URN used for this specification is "urn:fips:sha1".
5.1.3 MD5 5.1.3 MD5
The MD5 Algorithm was invented by RSA Data Securities and is similar The MD5 Algorithm was invented by RSA Data Securities and is similar
skipping to change at page 17, line 7 skipping to change at page 17, line 25
5.2 Signature Algorithms 5.2 Signature Algorithms
This specification uses the terminology of 'digital signature' for This specification uses the terminology of 'digital signature' for
qualifying indifferently digital signature and message authentication qualifying indifferently digital signature and message authentication
codes. Thus, the signature algorithms contemplated herein include codes. Thus, the signature algorithms contemplated herein include
public key digital signature algorithms such as DSA and message public key digital signature algorithms such as DSA and message
authentication codes such as HMAC [RFC 2104]. authentication codes such as HMAC [RFC 2104].
5.2.1 DSA 5.2.1 DSA
TODO
The DSA URN used in this specification is "urn:fips:dsa". The DSA URN used in this specification is "urn:fips:dsa".
5.2.2 HMAC 5.2.2 HMAC
Generalities [RFC 2104] TODO See [RFC 2104]
The HMAC URN used in this specification is is "urn:ibm:hmac". The HMAC URN used in this specification is is "urn:ibm:hmac".
5.2.3 RSA 5.2.3 RSA
TODO
The RSA URN used in this specification is "urn:rsa:rsa". The RSA URN used in this specification is "urn:rsa:rsa".
6. Examples 6. Examples
The following is an example signed IOTP message: The following is an example signed IOTP message:
<OtpMessage> <IotpMessage>
<TransRefBlk ID=C.1> <TransRefBlk ID='M.1'>
<TransId <TransId
ID=C.2 ID='M.2'
version="1.0" version='1.0'
OtpTransID="foo" IOtpTransID='19990809215923@www.iotp.org'
OtpTransType="foo" IOtpTransType='BaselinePurchase'
TransTimeStamp=1258402394> TransTimeStamp='1999-08-09T12:58:40.000Z+9'>
</TransId> </TransId>
<MsgId xml:lang=en SoftwareID=1.0> <MsgId xml:lang='en' SoftwareID='Iotp wallet version 1.0'>
</MsgId> </MsgId>
</TransRefBlk> </TransRefBlk>
<AuthReqBlk ID=C.3>
<Org
ID=C.7
OrgId="shop 1.0"
OtpMsgIdPrefix="foo"
ShortDesc="Widgets,Inc."
LogoNetLocn="http://www.widgets.com/Banner2.12.99.gif">
<TradingRole ID=C.8 TradingRole="foo">
</TradingRole>
<ContactInfo Tel="408-864-0600" Email="info@widgets.com">
</ContactInfo>
</Org>
</AuthReqBlk>
<IOTPSignatures> <IOTPSignatures>
<Signature> <Signature>
<Manifest LocatorHrefBase="iotp:"> <Manifest LocatorHrefBase='iotp:'>
<Algorithm name="urn:sha1" type=digest ID=S.1> <Algorithm name='urn:sha1' type='digest' id='P.3'>
</Algorithm> </Algorithm>
<Algorithm name="urn:rsa" type=signature ID=S.2> <Algorithm name='urn:rsa' type='signature' ID='P.4'>
<Parameter type=AlgorithmRef>S.1</Parameter> <Parameter type AlgorithmRef>P.5</Parameter>
</Algorithm> </Algorithm>
<Algorithm name="urn:dom-hash" type=digest ID=S.3> <Algorithm name='urn:dom-hash' type='digest' id='P.5'>
<Parameter type=AlgorithmRef>S.1</Parameter> <Parameter type='AlgorithmRef'>P.3</Parameter>
</Algorithm> </Algorithm>
<Digest DigestAlgorithmRef=S.3> <Digest DigestAlgorithmRef='P.6'>
<Locator href="C.1"/> <Locator href='P.1'/>
<Value>
xsqsfasDys2h44u4ehJDe54he5j4dJYTJ=
</Value>
</Digest>
<Digest DigestAlgorithmRef=S.3>
<Locator href="C.3"/>
<Value> <Value>
ked0Ks01k2d7a0kgmf9dk19lf63kkDSs0= xsqsfasDys2h44u4ehJDe54he5j4dJYTJ
</Value> </Value>
</Digest> </Digest>
<OriginatorInfo <OriginatorInfo
OriginatorRef=C.7> <IssuerAndSerialNumber
issuer='o=Iotp Ltd., c=US'
number='12345678987654'/>
</OriginatorInfo> </OriginatorInfo>
<RecipientInfo <RecipientInfo
SignatureAlgorithmRef=S.2 SignatureAlgorithmRef='P.4'
SignatureValueRef=V.1
RecipientRef=M.8>
</RecipientInfo> </RecipientInfo>
</Manifest> </Manifest>
<Value ID=V.1> <Value>
9dj28fjakA9sked0Ks01k2d7a0kgmf9dk19lf63kkDSs0= 9dj28fjakA9sked0Ks01k2d7a0kgmf9dk19lf63kkDSs0
</Value> </Value>
</Signature> </Signature>
<Certificate type='urn:X500:X509v3'>
<IssuerAndSerialNumber
issuer='o=GlobeSet Inc., c=US'
number='123456789102356'/>
<Value>
xsqsfasDys2h44u4ehJDe54he5j4dJYTJ=
</Value>
</Certificate>
</IOTPSignatures> </IOTPSignatures>
<PayExchBlk ID='P.1'>
</OtpMessage> <PaySchemeData
ID='P.2'
PaymentRef='M.5'
ContentSoftwareId='abcdefg'>
<PackagedContent Name='FirstPiece'>
snroasdfnas934k
</PackagedContent>
</PaySchemeData>
</PayExchBlk>
</IotpMessage>
7. Signature DTD 7. Signature DTD
<!-- <!--
****************************************************** ******************************************************
* IOTP SIGNATURES BLOCK DEFINITION * * IOTP SIGNATURES BLOCK DEFINITION *
****************************************************** ******************************************************
--> -->
<!ELEMENT IOTPSignatures (Signature+, Certificate*) > <!ELEMENT IOTPSignatures (Signature+, Certificate*) >
<!ATTLIST IOTPSignatures <!ATTLIST IOTPSignatures
ID ID #IMPLIED > ID ID #IMPLIED
>
<!-- <!--
****************************************************** ******************************************************
* IOTP SIGNATURE COMPONENT DEFINITION * * IOTP SIGNATURE COMPONENT DEFINITION *
****************************************************** ******************************************************
--> -->
<!ELEMENT Signature (Manifest, Value+) > <!ELEMENT Signature (Manifest, Value+) >
<!ATTLIST Signature <!ATTLIST Signature
ID ID #IMPLIED > ID ID #IMPLIED
>
<!ELEMENT Manifest <!ELEMENT Manifest
( Algorithm+, ( Algorithm+,
Digest+, Digest+,
Attributes?, Attribute*,
OriginatorInfo, OriginatorInfo,
RecipientInfo+, RecipientInfo+
) )
>
<!ATTLIST Manifest <!ATTLIST Manifest
LocatorHRefBase CDATA #IMPLIED LocatorHRefBase CDATA #IMPLIED
> >
<!ELEMENT Algorithm (Parameter*) > <!ELEMENT Algorithm (Parameter*) >
<!ATTRLIST Algorithm <!ATTLIST Algorithm
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 Attributes (Attribute+) >
<!ELEMENT Attribute ( #PCDATA ) > <!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
> >
<!ELEMENT RecipientInfo ANY > <!ELEMENT RecipientInfo ANY >
<!ATTLIST RecipientInfo <!ATTLIST RecipientInfo
SignatureAlgorithmRef IDREF #REQUIRED SignatureAlgorithmRef IDREF #REQUIRED
SignatureValueRef IDREF #REQUIRED SignatureValueRef IDREF #IMPLIED
SignatureCertRef IDREF #IMPLIED SignatureCertRef IDREF #IMPLIED
RecipientRefs NMTOKENS #IMPLIED RecipientRefs NMTOKENS #IMPLIED
> >
<!ELEMENT Parameter ANY > <!ELEMENT Parameter ANY >
<!ATTLIST Parameter <!ATTLIST Parameter
type PCDATA #REQUIRED type CDATA #REQUIRED
> >
<!-- <!--
****************************************************** ******************************************************
* IOTP CERTIFICATE COMPONENT DEFINITION * * IOTP CERTIFICATE COMPONENT DEFINITION *
****************************************************** ******************************************************
--> -->
<!ELEMENT Certificate <!ELEMENT Certificate
( IssuerAndSerialNumber ( IssuerAndSerialNumber, ( Value | Locator ) )
( Value | Locator ) )
> >
<!ATTLIST Certificate <!ATTLIST Certificate
ID ID #IMPLIED ID ID #IMPLIED
type NMTOKEN #REQUIRED > type NMTOKEN #REQUIRED
>
<!ELEMENT IssuerAndSerialNumber EMPTY > <!ELEMENT IssuerAndSerialNumber EMPTY >
<!ATTLIST IssuerAndSerialNumber <!ATTLIST IssuerAndSerialNumber
issuer CDATA #REQUIRED issuer CDATA #REQUIRED
number CDATA #REQUIRED > number CDATA #REQUIRED
>
<!-- <!--
****************************************************** ******************************************************
* 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) #IMPLIED '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. References 8. Security Considerations
This entire document concerns the IOTP v1 protocol signature element
which is used for authentication. See the Security Considerations
section of [RFC xxxx] "Interenet Open Trading Protocol - IOTP,
Version 1.0".
9. References
[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 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,
Version 1.0", August 1999. (currently draft-ietf-trade-iotp-v1.0-
protcool-*.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
[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>
9. Credits 9. Author's Addresses
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 Richard Brown at GlobeSet, Inc. <rdbrown@GlobeSet.com> signatures by Richard Brown at GlobeSet, Inc. <rdbrown@GlobeSet.com>
but has been narrowed and changed. but has been narrowed and changed.
The editor of this document is: The authors of this document are:
Kent M. Davidson Kent M. Davidson
Differential, Inc. Differential, Inc.
10054 Pasadena Ave. 440 Clyde Ave.
Cupertino, CA 95014 USA Mountain View, CA 94043 USA
email: kent@differential.com email: kent@differential.com
Yoshiaki Kawatsura
Hitachi, Ltd.
890 Kashimada Saiwai Kawasaki,
Kanagawa 2118567 Japan
email: kawatura@bisd.hitachi.co.jp
Contributors to the design of the IOTP DTD include, in alphabetic Contributors to the design of the IOTP DTD include, in alphabetic
order: order:
David Burdett, Mondex David Burdett, Mondex
Andrew Drapp, Hitachi Andrew Drapp, Hitachi
Donald Eastlake 3rd, IBM Donald Eastlake 3rd, IBM
Yoshiaki Kawatsura, Hitachi
Expiration and File Name Expiration and File Name
This draft expires August 1999. This draft expires February 2000.
Its file name is draft-ietf-trade-iotp-v1.0-dsig-00.txt. Its file name is draft-ietf-trade-iotp-v1.0-dsig-01.txt.
 End of changes. 

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