TRADE Working Group Kent Davidson
INTERNET-DRAFT Differential
Expires: August 1999 February 1999
Digital Signatures for the Internet Open Trading Protocol
------- ---------- --- --- -------- ---- ------- --------
Status of This Document
This draft, file name draft-ietf-trade-iotp-v1.0-dsig-00.txt, is an
addendum to the Internet Open Trading Protocol Specification version
1.0, and is intended to become an Informational RFC. Distribution of
this document is unlimited. Comments should be sent to the TRADE
working group mailing list <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
months. Internet-Drafts may be updated, replaced, or obsoleted by
other documents at any time. It is not appropriate to use Internet-
Drafts as reference material or to cite them other than as a
``working draft'' or ``work in progress.''
To view the entire list of current Internet-Drafts, please check the
"1id-abstracts.txt" listing contained in the Internet-Drafts Shadow
Directories on ftp.is.co.za (Africa), ftp.nordu.net (Northern
Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au (Pacific
Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu (US West Coast).
Abstract
A syntax and procedures are described for the computation and
verification of digital signatures for use within Version 1.0 of the
Internet Open Trading Protocol (IOTP).
Kent Davidson [Page 1]
INTERNET-DRAFT Digital Sigantures for IOTP February 1999
Table of Contents
Status of This Document....................................1
Abstract...................................................1
Table of Contents..........................................2
1. Introduction............................................3
2. Objective and Requirements..............................3
3. Signature Basics........................................4
3.1 Signature Element......................................4
3.2 Digest Element.........................................4
3.3 Originator and Recipient Information Elements..........5
4. Detailed Signature Syntax...............................6
4.1 Uniform Resource Names.................................6
4.2 IOTPSignatures.........................................6
4.3 Signature Component....................................7
4.3.1 Signature............................................7
4.3.2 Manifest.............................................7
4.3.3 Algorithm............................................8
4.3.4 Digest...............................................9
4.3.5 Attributes..........................................10
4.3.6 Attribute...........................................10
4.3.7 OriginatorInfo......................................10
4.3.8 RecipientInfo.......................................11
4.3.9 Parameter...........................................12
4.4 Certificate Component.................................13
4.4.1 Certificate.........................................13
4.4.2 IssuerAndSerialNumber...............................13
4.5 Common Components.....................................14
4.5.1 Value...............................................14
4.5.2 Locator.............................................15
5. Supported Algorithms...................................15
5.1 Digest Algorithms.....................................15
5.1.1 DOM-HASH............................................16
5.1.2 SHA1................................................16
5.1.3 MD5.................................................16
5.2 Signature Algorithms..................................16
5.2.1 DSA.................................................17
5.2.2 HMAC................................................17
5.2.3 RSA.................................................17
6. Examples...............................................17
7. Signature DTD..........................................19
8. References.............................................21
9. Credits................................................22
Expiration and File Name..................................22
Kent Davidson [Page 2]
INTERNET-DRAFT Digital Sigantures for IOTP February 1999
1. Introduction
The Internet Open Trading Protocol (IOTP) provides a payment system
independent interoperable framework for Internet commerce as
documented in draft-ietf-trade-iotp-v1.0-protocol-*.txt. All IOTP
messages are XML documents. XML, the Extensible Markup Language
[XML], is a syntactical standard promulgated by the World Wide Web
Consortium. XML is intended primarily for structuring data exchanged
and served over the World Wide Web.
Although IOTP assumes that any payment system used with it provides
its own security, there are numerous cases where IOTP requires
authentication and integrity services for portions of the XML
messages it specifies.
2. Objective and Requirements
This document covers how digital signatures may be used with XML
documents to provide authentication and tamper-proof protocol
messages specifically for Version 1.0 of the IOTP protocol. The
reader should recognize that an effort towards general XML digital
signatures exists but is unlikely to produce its final result in time
for IOTP Version 1.0. Future versions of IOTP will probably just
adopt by reference the results of this general XML digital signature
effort.
The objective of this document is to propose syntax and procedures
for the computation and verification of digital signatures applicable
to Verion 1.0 IOTP protocol messages, providing for:
-- Authentication of IOTP transactions
-- Provide a means by which an IOTP message may be made "tamper-
proof", or detection of tampering is made evident
-- Describe a set of available digest and signature algorithms at
least one of which is mandatory to implement for interoperability
-- Easily integrate within the IOTP 1.0 Specification
-- Provide lightweight signatures with minimal redundancy
-- Allow a signed portions of IOTP message to be "forwarded" to
another trading roles with different signature algorithms than the
original recipient
Kent Davidson [Page 3]
INTERNET-DRAFT Digital Sigantures for IOTP February 1999
3. Signature Basics
3.1 Signature Element
This specification consists primarily of the definition of an XML
element known as the Signature element. This element consists of two
sub-elements. The first one is a set of authenticated attributes,
known as the signature Manifest, which comprises such things as a
unique reference to the resources being authenticated and an
indication of the keying material and algorithms being used. The
second sub-element consists of the digital signature value.
<Signature>
<Manifest>
(resource information block)
(originator information block)
(recipient information block)
(other attributes)
(signature algorithms information block)
</Manifest>
<Value encoding= "encoding scheme">
(encoded signature value)
<Value>
</Signature>
The digital signature is not computed directly from the pieces of
information to be authenticated. Instead, the digital signature is
computed from a set of authenticated attributes (the Manifest), which
include references to, and a digests of, those pieces of information.
The authentication is therefore "indirect".
3.2 Digest Element
The Digest element consists of a unique and unambiguous reference to
the XML resources being authenticated. It is constructed of a locator
and the digest value data itself. The Digest algorithm is referred to
indirectly via a DigestAlgorithmRef, so that Digest algorithms may be
shared by multiple resources.
<Resource>
<Locator href= "resource locator"/>
<Digest DigestAlgorithmRef=D.1>
(digest information block)
</Digest>
</Resource>
Kent Davidson [Page 4]
INTERNET-DRAFT Digital Sigantures for IOTP February 1999
The resource locator is implemented as a simple XML Link [XLink].
This not only provides a unique addressing scheme for internal and
external resources, but also facilitates authentication of composite
documents.
3.3 Originator and Recipient Information Elements
The purpose of the Originator and Recipient information elements is
providing identification and keying material for these respective
parties.
<OriginatorInfo>
(identification information block)
(keying material information block)
</OriginatorInfo>
<RecipientInfo>
(identification information block)
(keying material information block)
</RecipientInfo>
The actual content of these two elements depends on the
authentication scheme being used and the existence or non-existence
of a prior relationship between the parties. In some circumstances,
it may be quite difficult to distinguish between identification and
keying material information. A unique reference to a digital
certificate provides for both. This may also stand true for an
account number when a prior relationship exists between the parties.
The Originator information element is mandatory. Depending on the
existence or non-existence of a prior relationship with the
recipient, this block either refers to a public credential such as a
digital certificate or displays a unique identifier known by the
recipient.
The Recipient information element may be used when a document
contains multiple signature information blocks, each being intended
for a particular recipient. A unique reference in the Recipient
information block helps the recipients identify their respective
Signature information block.
The Recipient information element may also be used when determination
of the authentication key consists of a combination of keying
material provided by both parties. This would be the case, for
example, when establishing a key by means of Diffie Hellman
[Schneier] Key Exchange algorithm.
Kent Davidson [Page 5]
INTERNET-DRAFT Digital Sigantures for IOTP February 1999
The Algorithm element is a generalised place to place any type of
algorithm used within the signed IOTP message. The Algorithm may be a
Signature algorithm or a Digest algorithm. Each algorithm contains
parameters specific to the algorithm used.
<Algorithm type="digest" id=12>
(algorithm information block)
</Algorithm>
Algorithms are required to contain an ID which allows for indirect
reference to them from other places in the XML signature.
4. Detailed Signature Syntax
4.1 Uniform Resource Names
To prevent potential name conflicts in the definition of the numerous
type qualifiers considered herein, this specification uses Uniform
Resource Names [RFC 2141].
4.2 IOTPSignatures
The IOTPSignatures element is the top-level element in an IOTP
signature block. It consists of a collection of Signature elements,
and an optional set of Certificates.
<!ELEMENT IOTPSignatures (Signature+, Certificate*) >
<!ATTLIST IOTPSignatures
ID ID #IMPLIED >
Content Description
Signature: A collection of Signature elements.
Certificate: Zero or more certificates used for signing
Attributes Description
ID: Element identifier that may be used to referencing the entire
Signature element from a Resource element when implementing
endorsement.
Kent Davidson [Page 6]
INTERNET-DRAFT Digital Sigantures for IOTP February 1999
4.3 Signature Component
4.3.1 Signature
The Signature element constitutes the majority of this specification.
It is comprised of two sub-elements. The first one is a set of
attributes, known as the Manifest, which actually constitutes the
authenticated part of the document. The second sub-element consists
of the signature value or values.
<!ELEMENT Signature (Manifest, Value+) >
<!ATTLIST Signature
ID ID #IMPLIED >
Content Description
Manifest: A set of attributes that actually constitutes the
authenticated part of the document.
Value: One or more encodings of signature values. Multiple values
allow for a multiple algorithms to be supported within a single
signature block.
Attributes Description
ID: Element identifier that may be used to referencing the Signature
element from a Resource element when implementing endorsement.
4.3.2 Manifest
The Manifest element consists of a collection of attributes that
specify such things as as references to the resources being
authenticated and an indication of the keying material and algorithms
to be used.
<!ELEMENT Manifest
( Algorithm+,
Digest+,
Attributes?,
OriginatorInfo,
RecipientInfo+,
)
<!ATTLIST Manifest
LocatorHRefBase CDATA #IMPLIED
>
Kent Davidson [Page 7]
INTERNET-DRAFT Digital Sigantures for IOTP February 1999
Content Description
Algorithm: A list of algorithms used for signing, digest computation,
and canonicalization.
Digest: A list of digests of resources to be authentication and
signed.
Attributes: Optional element that consists of a collection of
complementary attributes to be authenticated.
OriginatorInfo: Element that provides identification and keying
material information related to the originator.
RecipientInfo: Optional element that provides identification and
keying material information related to the recipient.
Attributes Description
LocatorHrefBase: The LocatorHrefBase provides a similar construct to
the HTML HREFBASE attribute and implicitly sets all relative URL
references within the Manifest to be relative to the HrefBase. For
example, the IOTP Manifest may contain:
<Manifest
LocatorHrefBase='iotp:globally-unique-tid#>
And subsequent Locators may be:
<Locator href="C.9">
An implementation should concatenate the two locator references to
create the entire URL.
4.3.3 Algorithm
This specification uses an Algorithm data type which indicates many
different types of algoirithms. The Algorithm element allows for
specification of sub-algorithms as parameters of the primary
algorithm. This is performed via a parameter within the algorithm
that provides a reference to another Algorithm. An example of this is
shown in the Parameter section.
<!ELEMENT Algorithm (Parameter*) > <!ATTRLIST Algorithm
id ID #REQUIRED
type (digest|signature) #IMPLIED
name NMTOKEN #REQUIRED >
Kent Davidson [Page 8]
INTERNET-DRAFT Digital Sigantures for IOTP February 1999
Content Description
Parameter: The contents of an Algorithm element consists of an
optional collection of Parameter elements which are specified on a
per algorithm basis.
Attributes Description
id: The ID of the algorithm is used by the Digest and RecipientInfo
to refer to the signing or digest algorithm used.
type: The type of algorithm, either a digest or signature. This is
implied by the element to which the algorithm is referred. That is,
if the DigestAlgorithmRef refers to an algorithm, it is implicit by
reference that the targetted algorithm is a digest.
name: The type of the algorithm expressed as a Uniform Resource
Name.
4.3.4 Digest
The Digest element consists of the fingerprint of a given resource.
This element is constructed of two sub-elements. This first one
indicates the algorithm to be used for computation of the
fingerprint. The second element consists of the fingerprint value.
<!ELEMENT Digest (Locator, Value) >
<!ATTLIST Digest
DigestAlgorithmRef IDREF #REQUIRED
>
Content Description
Locator: Contains a "HREF" or URL locator for the resource to be
fingerprinted. References to IOTP messages.
Value: Encoding of the fingerprint value.
Attributes Description
DigestAlgorithmRef: ID Reference of algorithm used for computation of
the digest.
Kent Davidson [Page 9]
INTERNET-DRAFT Digital Sigantures for IOTP February 1999
4.3.5 Attributes
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
information, which shall be included in the authenticated part of the
document. This element has been defined primarily for enabling some
level of customization in the signature element. An Attribute element
consists of a value, a type, and a criticality.
At this time, no IOTP specific attributes are specified.
<!ELEMENT Attribute ( ANY ) >
<!ATTLIST Attribute
type NMTOKEN #REQUIRED
critical ( true | false ) #REQUIRED
>
Content Description
ANY: The actual value of an attribute depends solely upon its type.
Attributes Description
type: Type of the attribute.
critical: Boolean value that indicates if the attribute is critical
(true) or not (false). A recipient shall reject a signature that
contains a critical attribute that he does not recognise. However, an
unrecognised non-critical attribute may be ignored.
4.3.7 OriginatorInfo
The OriginatorInfo element is used for providing identification and
keying material information for the originator.
Kent Davidson [Page 10]
INTERNET-DRAFT Digital Sigantures for IOTP February 1999
<!ELEMENT OriginatorInfo ANY >
<!ATTLIST OriginatorInfo
OriginatorRef NMTOKEN #IMPLIED
>
Content Description
ANY: Identification and keying material information may consist of
ANY construct. Such a definition allows the adoption of
application-specific schemes. Attributes Description
OriginatorRef: A reference to the IOTP Org ID of the originating
signer.
4.3.8 RecipientInfo
The RecipientInfo element is used for providing identification and
keying material information for the recipient. This element is used
either for enabling recognition of a Signature element by a given
recipient or when determination of the authentication key consists of
the combination of keying material provided by both the recipient and
the originator.
The RecipientInfo attributes provide a centralized location where
signatures, algorithms, and certificates intended for a particular
recipient are specified.
The signature certificate reference ID MUST point to a certificate
object.
<!ELEMENT RecipientInfo ANY >
<!ATTLIST RecipientInfo
SignatureAlgorithmRef IDREF #REQUIRED
SignatureValueRef IDREF #REQUIRED
SignatureCertRef IDREF #IMPLIED
RecipientRefs NMTOKENS #IMPLIED
>
Content Description
ANY: Identification and keying material information may consist of
ANY construct.
Attributes Description
SignatureAlgorithmRef: A reference to the signature algorithm used to
sign the SignatureValueRef intended for this recipient. The signature
algorithm reference ID MUST point to a signature algorithm within the
Kent Davidson [Page 11]
INTERNET-DRAFT Digital Sigantures for IOTP February 1999
Manifest.
SignatureValueRef: A reference to the signature value for this
recipient. The signature value reference ID MUST point to a value
structure directly included within a Manifest.
SignatureCertRef: A reference to the certificate used to sign the
Value pointed to by the SignatureValueRef.
RecipientRefs: A list of references to the IOTP Org ID of the
recipients this signature is intended for.
4.3.9 Parameter
A Parameter element provides the value of a particular algorithm
parameter, whose name and format have been specified for the
algorithm considered.
<!ELEMENT Parameter ANY >
<!ATTLIST Parameter
type PCDATA #REQUIRED
>
For IOTP 1.0, the following parameter type is standardized:
"AlgorithmRef".
An AlgorithmRef contains an ID of a "sub-Algorithm" used when
computing a sequence of algorithms. For example, a signature
algorithm actually signs a digest algorithm. To specify a chain of
algorithms used to compute a signature, AlgorithmRef parameter types
are used in the following manner:
<Algorithm ID=A1 type="digest" name="urn:ibm:dom-hash">
<Parameter type='AlgorithmRef'>A2</Parameter>
</Algorithm>
<Algorithm ID=A2 type="digest" name="urn:fips:sha1">
</Algorithm>
<Algorithm ID=A3 type="signature" name="urn:ibm:hmac">
<Parameter type='AlgorithmRef'>A1</Parameter>
</Algorithm>
Content Description
ANY: The contents of a Parameter element consists of ANY valid
construct, which is specified on a per algorithm per parameter basis.
Attributes Description
Kent Davidson [Page 12]
INTERNET-DRAFT Digital Sigantures for IOTP February 1999
type: The type of the parameter expressed as a free form string,
whose value is specified on a per algorithm basis.
4.4 Certificate Component
4.4.1 Certificate
The Certificate element may be used for either providing the value of
a digital certificate or specifying a location from where it may be
retrieved.
<!ELEMENT Certificate
( IssuerAndSerialNumber
( Value | Locator ) )
>
<!ATTLIST Certificate
ID ID #IMPLIED
type NMTOKEN #REQUIRED >
Content Description
IssuerAndSerialNumber: Unique identifier of this certificate. This
element has been made mandatory is order to prevent unnecessary
decoding during validation of a certificate chain. This feature also
helps certificates caching, especially when the value is not directly
provided.
Value: Encoding of the certificate value. The actual value to be
encoded depends upon the type of the certificate.
Locator: XML link element that could be used for retrieving a copy of
the digital certificate. The actual value being returned by means of
this locator depends upon the security protocol being used.
Attributes Description
type: Type of the digital certificate. This attribute is specified
as a Universal Resource Name, as indicated in the "Supported
Algorithms" section.
4.4.2 IssuerAndSerialNumber
The IssuerAndSerialNumber element identifies a certificate, and
thereby an entity and a public key, by the name of the certificate
Kent Davidson [Page 13]
INTERNET-DRAFT Digital Sigantures for IOTP February 1999
issuer and an issuer-specific certificate identification.
<!ELEMENT IssuerAndSerialNumber EMPTY >
<!ATTLIST IssuerAndSerialNumber
issuer CDATA #REQUIRED
number CDATA #REQUIRED >
Attributes Description
issuer: Name of the issuing certification authority.
number: Issuer-specific certificate identification.
4.5 Common Components
4.5.1 Value
A value contains the "raw" data of a signature or digest algorithm,
usually in a base-64 encoded form. See [RFC 2045] for algorithm used
to base-64 encode data.
<!ELEMENT Value ( #PCDATA ) > <!ATTLIST Value
id ID #IMPLIED
encoding (base64|none) #IMPLIED 'base64' >
Content Description
PCDATA: Content value after adequate encoding.
Attributes Description
encoding: This attribute specifies the decoding scheme to be
employed for recovering the original byte stream from the content of
the element. This document recognises the following two schemes:
none: the content has not been subject to any particular encoding.
This does not preclude however the use of native XML encoding such as
CDATA section or XML escaping.
base64: The content has been encoded by means of the base64 encoding
scheme.
Kent Davidson [Page 14]
INTERNET-DRAFT Digital Sigantures for IOTP February 1999
4.5.2 Locator
The Locator element consists of simple XML link [XLink]. This
element allows unambiguous reference to a resource or fragment of a
resource.
<!ELEMENT Locator EMPTY>
<!ATTLIST Locator
xml:link CDATA #FIXED 'simple'
href CDATA #REQUIRED >
Attributes Description
xml:link: Required XML link attribute that specifies the nature of
the link (simple in this case).
href: Locator value that may contains either a URI [RFC 2396], a
fragment identifier, or both.
5. Supported Algorithms
The IOTP specification 1.0 requires the implementation of the DOM-
HASH, SHA1, MD5, DSA, and HMAC algorithms to provide a compliant
implementation of IOTP 1.0. Implementation of RSA is also
recommended.
5.1 Digest Algorithms
This specification contemplates two types of digest algorithms, both
of which provide a digest string as a result:
Surface string digest algorithms
These algorithms do not have any particular knowledge about the
content being digested and operate on the raw content value. Changes
in the surface string of a given content affect directly the value of
the digest being produced.
Canonical digest algorithms
These algorithms have been tailored for a particular content type and
produce a digest value that depends upon the core semantics of such
content. Changes limited to the surface string of a given content do
not affect the value of the digest being produced.
Kent Davidson [Page 15]
INTERNET-DRAFT Digital Sigantures for IOTP February 1999
5.1.1 DOM-HASH
XML canonical digest algorithm proposed by IBM Tokyo Research
Laboratory. This algorithm operates on the DOM representation of the
document and provides an unambiguous means for recursive computation
of the hash value of the nodes that constitute the DOM tree.
The DOM-HASH algorithm requires a single parameter, which shall
consist of a surface string digest algorithm such as SHA1.
The DOM-HASH URN used for this specification is "urn:ibm:dom-hash".
Example
<Algorithm name="urn:ibm:dom-hash" type=digest>
</Algorithm>
5.1.2 SHA1
Surface string digest algorithm designed by hte US government for use
with the Digital Signature Standard. This algorithm produces a 160-
bit hash value.
This algorithm does not require any parameter.
The SHA1 URN used for this specification is "urn:fips:sha1".
5.1.3 MD5
The MD5 Algorithm was invented by RSA Data Securities and is similar
to its predecessors, MD2 and MD4, but faster and simpler than MD2
while stronger than MD4. [RFC 1321]
The MD5 Algorithm takes no parameters.
The MD5 URN used for this specification is "urn:rsa:md5".
5.2 Signature Algorithms
This specification uses the terminology of 'digital signature' for
qualifying indifferently digital signature and message authentication
codes. Thus, the signature algorithms contemplated herein include
public key digital signature algorithms such as DSA and message
authentication codes such as HMAC [RFC 2104].
Kent Davidson [Page 16]
INTERNET-DRAFT Digital Sigantures for IOTP February 1999
5.2.1 DSA
TODO
The DSA URN used in this specification is "urn:fips:dsa".
5.2.2 HMAC
Generalities [RFC 2104] TODO
The HMAC URN used in this specification is is "urn:ibm:hmac".
5.2.3 RSA
TODO
The RSA URN used in this specification is "urn:rsa:rsa".
6. Examples
The following is an example signed IOTP message:
<OtpMessage>
<TransRefBlk ID=C.1>
<TransId
ID=C.2
version="1.0"
OtpTransID="foo"
OtpTransType="foo"
TransTimeStamp=1258402394>
</TransId>
<MsgId xml:lang=en SoftwareID=1.0>
</MsgId>
</TransRefBlk>
<AuthReqBlk ID=C.3>
<Org
ID=C.7
OrgId="shop 1.0"
OtpMsgIdPrefix="foo"
ShortDesc="Widgets,Inc."
LogoNetLocn="http://www.widgets.com/Banner2.12.99.gif">
<TradingRole ID=C.8 TradingRole="foo">
</TradingRole>
<ContactInfo Tel="408-864-0600" Email="info@widgets.com">
Kent Davidson [Page 17]
INTERNET-DRAFT Digital Sigantures for IOTP February 1999
</ContactInfo>
</Org>
</AuthReqBlk>
<IOTPSignatures>
<Signature>
<Manifest LocatorHrefBase="iotp:">
<Algorithm name="urn:sha1" type=digest ID=S.1>
</Algorithm>
<Algorithm name="urn:rsa" type=signature ID=S.2>
<Parameter type=AlgorithmRef>S.1</Parameter>
</Algorithm>
<Algorithm name="urn:dom-hash" type=digest ID=S.3>
<Parameter type=AlgorithmRef>S.1</Parameter>
</Algorithm>
<Digest DigestAlgorithmRef=S.3>
<Locator href="C.1"/>
<Value>
xsqsfasDys2h44u4ehJDe54he5j4dJYTJ=
</Value>
</Digest>
<Digest DigestAlgorithmRef=S.3>
<Locator href="C.3"/>
<Value>
ked0Ks01k2d7a0kgmf9dk19lf63kkDSs0=
</Value>
</Digest>
<OriginatorInfo
OriginatorRef=C.7>
</OriginatorInfo>
<RecipientInfo
SignatureAlgorithmRef=S.2
SignatureValueRef=V.1
RecipientRef=M.8>
</RecipientInfo>
</Manifest>
<Value ID=V.1>
9dj28fjakA9sked0Ks01k2d7a0kgmf9dk19lf63kkDSs0=
</Value>
</Signature>
</IOTPSignatures>
</OtpMessage>
Kent Davidson [Page 18]
INTERNET-DRAFT Digital Sigantures for IOTP February 1999
7. Signature DTD
<!--
******************************************************
* IOTP SIGNATURES BLOCK DEFINITION *
******************************************************
-->
<!ELEMENT IOTPSignatures (Signature+, Certificate*) >
<!ATTLIST IOTPSignatures
ID ID #IMPLIED >
<!--
******************************************************
* IOTP SIGNATURE COMPONENT DEFINITION *
******************************************************
-->
<!ELEMENT Signature (Manifest, Value+) >
<!ATTLIST Signature
ID ID #IMPLIED >
<!ELEMENT Manifest
( Algorithm+,
Digest+,
Attributes?,
OriginatorInfo,
RecipientInfo+,
)
<!ATTLIST Manifest
LocatorHRefBase CDATA #IMPLIED
>
<!ELEMENT Algorithm (Parameter*) >
<!ATTRLIST Algorithm
id ID #REQUIRED
type (digest|signature) #IMPLIED
name NMTOKEN #REQUIRED >
<!ELEMENT Digest (Locator, Value) >
<!ATTLIST Digest
DigestAlgorithmRef IDREF #REQUIRED
>
Kent Davidson [Page 19]
INTERNET-DRAFT Digital Sigantures for IOTP February 1999
<!ELEMENT Attributes (Attribute+) >
<!ELEMENT Attribute ( #PCDATA ) >
<!ATTLIST Attribute
type NMTOKEN #REQUIRED
critical ( true | false ) #REQUIRED
>
<!ELEMENT OriginatorInfo ANY >
<!ATTLIST OriginatorInfo
OriginatorRef NMTOKEN #IMPLIED
>
<!ELEMENT RecipientInfo ANY >
<!ATTLIST RecipientInfo
SignatureAlgorithmRef IDREF #REQUIRED
SignatureValueRef IDREF #REQUIRED
SignatureCertRef IDREF #IMPLIED
RecipientRefs NMTOKENS #IMPLIED
>
<!ELEMENT Parameter ANY >
<!ATTLIST Parameter
type PCDATA #REQUIRED
>
<!--
******************************************************
* IOTP CERTIFICATE COMPONENT DEFINITION *
******************************************************
-->
<!ELEMENT Certificate
( IssuerAndSerialNumber
( Value | Locator ) )
>
<!ATTLIST Certificate
ID ID #IMPLIED
type NMTOKEN #REQUIRED >
<!ELEMENT IssuerAndSerialNumber EMPTY >
<!ATTLIST IssuerAndSerialNumber
issuer CDATA #REQUIRED
number CDATA #REQUIRED >
<!--
******************************************************
* IOTP SHARED COMPONENT DEFINITION *
******************************************************
-->
Kent Davidson [Page 20]
INTERNET-DRAFT Digital Sigantures for IOTP February 1999
<!ELEMENT Value ( #PCDATA ) >
<!ATTLIST Value
id ID #IMPLIED
encoding (base64|none) #IMPLIED 'base64'
>
<!ELEMENT Locator EMPTY>
<!ATTLIST Locator
xml:link CDATA #FIXED 'simple'
href CDATA #REQUIRED >
8. References
[RFC 1321] - R. Rivest, "The MD5 Message-Digest Algorithm", April
1992.
[RFC 2045]- N. Freed & N. Borenstein, "Multipurpose Internet Mail
Extensions (MIME) Part One: Format of Internet Message Bodies",
November 1996.
[RFC 2046] - N. Freed & N. Borenstein, "Multipurpose Internet Mail
Extensions (MIME) Part Two: Media Types", November 1996.
[RFC 2104] - H. Krawczyk, M. Bellare, R. Canetti, "HMAC: Keyed-
Hashing for Message Authentication", February 1997.
[RFC 2141] - R. Moats, "URN Syntax", May 1997.
[RFC 2396] - T. Berners-Lee, R. Fielding, L. Masinter, "Uniform
Resource Identifiers (URI): Generic Syntax", August 1998.
[Schneier] - Bruce Schneier, "Applied Cryptography: Protocols,
Algorithms, and Source Code in C", 1996, John Wiley and Sons
[XLink] - Eve Maler, Steve DeRose, "XML Linking Language (XLink)",
<http://www.w3.org/TR/1998/WD-xlink-19980303>
[XML] - Tim Bray, Jean Paoli, C. M. Sperber-McQueen, "Extensible
Markup Language (XML) 1.0", <http://www.w3.org/TR/1998/REC-xml-
19980210>
Kent Davidson [Page 21]
INTERNET-DRAFT Digital Sigantures for IOTP February 1999
9. Credits
This document is based on work originally done on general XML digital
signatures by Richard Brown at GlobeSet, Inc. <rdbrown@GlobeSet.com>
but has been narrowed and changed.
The editor of this document is:
Kent M. Davidson
Differential, Inc.
10054 Pasadena Ave.
Cupertino, CA 95014 USA
email: kent@differential.com
Contributors to the design of the IOTP DTD include, in alphabetic
order:
David Burdett, Mondex
Andrew Drapp, Hitachi
Donald Eastlake 3rd, IBM
Yoshiaki Kawatsura, Hitachi
Expiration and File Name
This draft expires August 1999.
Its file name is draft-ietf-trade-iotp-v1.0-dsig-00.txt.
Kent Davidson [Page 22]
