RFC relevance of parameter

As per Relevance of the word parameter, we have this rfc below:

Network Working Group K.
Request for Comments: 2802
Category: Informational Y.

April 2000

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

Status of this

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

Copyright

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

A syntax and procedures are described for the computation
verification of digital signatures for use within Version 1.0 of
Internet Open Trading Protocol (IOTP).

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

Richard Brown of GlobeSet, Inc.
Other contributors to the design of the IOTP DSIG DTD include,
alphabetic order

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

Davidson & Kawatsura Informational [Page 1]

RFC 2802 Digital Signatures for IOTP April 2000

Table of

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

Davidson & Kawatsura Informational [Page 2]

RFC 2802 Digital Signatures for IOTP April 2000

1.

The Internet Open Trading Protocol (IOTP) provides a payment
independent interoperable framework for Internet commerce
documented in [RFC 2801]. All IOTP messages are XML documents. XML
the Extensible Markup Language [XML], is a syntactical
promulgated by the World Wide Web Consortium. XML is
primarily for structuring data exchanged and served over the
Wide Web

Although IOTP assumes that any payment system used with it
its own security, there are numerous cases where IOTP
authentication and integrity services for portions of the
messages it specifies

2. Objective and

This document covers how digital signatures may be used with
documents to provide authentication and tamper-proof
messages specifically for Version 1.0 of the IOTP protocol.
reader should recognize that an effort towards general XML
signatures exists but is unlikely to produce its final result in
for IOTP Version 1.0. Future versions of IOTP will probably adopt
reference the results of this general XML digital signature effort

The objective of this document is to propose syntax and
for the computation and verification of digital signatures
to Version 1.0 IOTP protocol messages, providing for

-- Authentication of IOTP
-- Provide a means by which an IOTP message may be made "tamper
proof", or detection of tampering is made
-- Describe a set of available digest and signature algorithms
least one of which is mandatory to implement for
-- Easily integrate within the IOTP 1.0
-- Provide lightweight signatures with minimal
-- Allow signed portions of IOTP message to be "forwarded" to
trading roles with different signature algorithms than
original

3. Signature

3.1 Signature

This specification consists primarily of the definition of an
element known as the Signature element. This element consists of
sub-elements. The first one is a set of authenticated attributes
known as the signature Manifest, which comprises such things as

Davidson & Kawatsura Informational [Page 3]

RFC 2802 Digital Signatures for IOTP April 2000

unique reference to the resources being authenticated and
indication of the keying material and algorithms being used.
second sub-element consists of the digital signature value

<Signature
(resource information block
(originator information block
(recipient information block
(other attributes
(signature algorithms information block
encoding 'encoding scheme'>
(encoded signature value
Signature

The digital signature is not computed directly from the pieces
information to be authenticated. Instead, the digital signature
computed from a set of authenticated attributes (the Manifest),
include references to, and a digests of, those pieces of information

The authentication is therefore "indirect".

3.2 Digest

The Digest element consists of a unique and unambiguous reference
the XML resources being authenticated. It is constructed of a
and the digest value data itself. The Digest algorithm is referred
indirectly via a DigestAlgorithmRef, so that Digest algorithms may
shared by multiple resources

(Digest value

The resource locator is implemented as a simple XML Link [XLink].
This not only provides a unique addressing scheme for internal
external resources, but also facilitates authentication of
documents

Davidson & Kawatsura Informational [Page 4]

RFC 2802 Digital Signatures for IOTP April 2000

3.3 Originator and Recipient Information

The purpose of the Originator and Recipient information elements
to provide identification and keying material for these
parties

(identification information block
(keying material information block

(identification information block
(keying material information block

The actual content of these two elements depends on
authentication scheme being used and the existence or non-
of a prior relationship between the parties. In some circumstances
it may be quite difficult to distinguish between identification
keying material information. A unique reference to a
certificate provides for both. This may also stand true for
account number when a prior relationship exists between the parties

The Originator information element is mandatory. Depending on
existence or non-existence of a prior relationship with
recipient, this block either refers to a public credential such as
digital certificate or displays a unique identifier known by
recipient

The Recipient information element may be used when a
contains multiple signature information blocks, each being
for a particular recipient. A unique reference in the
information block helps the recipients identify their
Signature information block

The Recipient information element may also be used when
of the authentication key consists of a combination of
material provided by both parties. This would be the case,
example, when establishing a key by means of Diffie
[Schneier] Key Exchange algorithm

3.4 Algorithm

The Algorithm element is a generalized place to put any type
algorithm used within the signed IOTP message. The Algorithm may be
Signature algorithm or a Digest algorithm. Each algorithm
parameters specific to the algorithm used

Davidson & Kawatsura Informational [Page 5]

RFC 2802 Digital Signatures for IOTP April 2000

<Algorithm type='digest' ID='12'>
(algorithm information block
Algorithm

Algorithms are required to contain an ID which allows for
reference to them from other places in the XML signature

4. Detailed Signature

4.1 Uniform Resource

To prevent potential name conflicts in the definition of the
type qualifiers considered herein, this specification uses
Resource Names [RFC 2141].

4.2

The IotpSignatures element is the top-level element in an
signature block. It consists of a collection of Signature elements
and an optional set of Certificates

Signature+, Certificate*) >
ID ID #IMPLIED >

Content

Signature: A collection of Signature elements

Certificate: Zero or more certificates used for

Attributes

ID: Element identifier that may be used to reference the
Signature element from a Resource element when
endorsement

4.3 Signature

4.3.1

The Signature element constitutes the majority of this specification
It is comprised of two sub-elements. The first one is a set
attributes, known as the Manifest, which actually constitutes
authenticated part of the document. The second sub-element
of the signature value or values

Davidson & Kawatsura Informational [Page 6]

RFC 2802 Digital Signatures for IOTP April 2000

The Value element contained within the Signature element is
encoded form of the signature of the Manifest element, and
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
signature algorithm

First, the Manifest is canonicalized with an algorithm
within the Algorithm element of the Manifest. The canonicalized
removes any inconsistencies in white space introduced by XML
engines

This canonicalized form is then converted into a digest form
uniquely identifies the canonicalized document. Any
modification in the original document will result in a very
digest value

Finally, the digest is then signed using a public/symmetric
algorithm which digitally stamps the digest (with the certificate
the signer if available). The final signed digest is the value
is stored within the Signature's Value element

Signature (Manifest, Value+) >
ID ID #IMPLIED >

Content

Manifest: A set of attributes that actually constitutes
authenticated part of the document

Value: One or more encodings of signature values. Multiple
allow for a multiple algorithms to be supported within a
signature component

Attributes

ID: Element identifier that may be used to reference the
element from a Resource element when implementing endorsement

4.3.2

The Manifest element consists of a collection of attributes
specify such things as references to the resources
authenticated and an indication of the keying material and
to be used

Davidson & Kawatsura Informational [Page 7]

RFC 2802 Digital Signatures for IOTP April 2000

( Algorithm+,
Digest+,
Attribute*,
OriginatorInfo
RecipientInfo+,
)
LocatorHRefBase CDATA #
>

Content

Algorithm: A list of algorithms used for signing, digest computation
and canonicalization

Digest: A list of digests of resources to be authentication
signed

Attribute: Optional element that consists of a collection
complementary attributes to be authenticated

OriginatorInfo: Element that provides identification and
material information related to the originator

RecipientInfo: Optional element that provides identification
keying material information related to the recipient

Attributes

LocatorHrefBase: The LocatorHrefBase provides a similar construct
the HTML HREFBASE attribute and implicitly sets all relative
references within the Manifest to be relative to the HrefBase.
example, the IOTP Manifest may contain

And subsequent Locators may be

An implementation should concatenate the two locator references
"#" to create the entire URL. See definition of the Locator
on the Digest element for more detail

Davidson & Kawatsura Informational [Page 8]

RFC 2802 Digital Signatures for IOTP April 2000

4.3.3

This specification uses an Algorithm data type which indicates
different types of algoirithms. The Algorithm element allows
specification of sub-algorithms as parameters of the
algorithm. This is performed via a parameter within the
that provides a reference to another Algorithm. An example of this
shown in the Parameter section

Algorithm (Parameter*) >
ID ID #
type (digest|signature) #
name NMTOKEN #REQUIRED >

Content

Parameter: The contents of an Algorithm element consists of
optional collection of Parameter elements which are specified on
per algorithm basis

Attributes

ID: The ID of the algorithm is used by the Digest and
to refer to the signing or digest algorithm used

type: The type of algorithm, either a digest or signature. This
implied by the element to which the algorithm is referred. That is
if the DigestAlgorithmRef refers to an algorithm, it is implicit
reference that the targeted algorithm is a digest

name: The type of the algorithm expressed as a Uniform
Name

4.3.4

The Digest element consists of the fingerprint of a given resource
This element is constructed of two sub-elements. This first
indicates the algorithm to be used for computation of
fingerprint. The second element consists of the fingerprint value

DigestAlgorithmRef IDREF #
>

Davidson & Kawatsura Informational [Page 9]

RFC 2802 Digital Signatures for IOTP April 2000

Content

Locator: Contains a "HREF" or URL Locator for the resources to
fingerprinted. For use within IOTP a "scheme" with the value "iotp
may be used with the following structure

'iotp:<globally-unique-tid>#'.

This should be interpreted as referring to an element with an
attribute that matches in any IOTP Message that has
TransRefBlk Block with an IotpTransId that matches <globally-unique
tid>.

If the LocatorHrefBase attribute is set on the Manifest element
which this Digest element is a child, then concatenate the value
the LocatorHrefBase attribute with the value of the Locator
before identifying the element that is being referred to

If the LocatorHrefBase attribute is omitted, <globally-unique-tid
should be interpreted as the current IotpTransId, which is
in the IOTP message which contains the Manifest component

Value: Encoding of the fingerprint value

Attributes

DigestAlgorithmRef: ID Reference of algorithm used for computation
the digest

4.3.5

The Attribute element consists of a complementary piece
information, which shall be included in the authenticated part of
document. This element has been defined primarily for enabling
level of customization in the signature element. This is the
where a specific IOTP implementation may include custom
which must be authenticated directly. An Attribute element
of a value, a type, and a criticality

At this time, no IOTP specific attributes are specified

Attribute ANY >
type NMTOKEN #
critical ( true | false ) #
>

Davidson & Kawatsura Informational [Page 10]

RFC 2802 Digital Signatures for IOTP April 2000

Content

ANY: The actual value of an attribute depends solely upon its type

Attributes

type: Type of the attribute

critical: Boolean value that indicates if the attribute is
(true) or not (false). A recipient shall reject a signature
contains a critical attribute that he does not recognize. However,
unrecognized non-critical attribute may be ignored

4.3.6

The OriginatorInfo element is used for providing identification
keying material information for the originator

OriginatorRef NMTOKEN #
>

Content

ANY: Identification and keying material information may consist
ANY construct. Such a definition allows the adoption
application-specific schemes

Attributes

OriginatorRef: A reference to the IOTP Org ID of the
signer

4.3.7

The RecipientInfo element is used for providing identification
keying material information for the recipient. This element is
either for enabling recognition of a Signature element by a
recipient or when determination of the authentication key consists
the combination of keying material provided by both the recipient
the originator

The RecipientInfo attributes provide a centralized location
signatures, algorithms, and certificates intended for a
recipient are specified

Davidson & Kawatsura Informational [Page 11]

RFC 2802 Digital Signatures for IOTP April 2000

The signature certificate reference ID MUST point to a
object

SignatureAlgorithmRef IDREF #
SignatureValueRef IDREF #
SignatureCertRef IDREF #
RecipientRefs NMTOKENS #
>

Content

ANY: Identification and keying material information may consist
ANY construct

Attributes

SignatureAlgorithmRef: A reference to the signature algorithm used
sign the SignatureValueRef intended for this recipient. The
algorithm reference ID MUST point to a signature algorithm within
Manifest

SignatureValueRef: A reference to the signature value for
recipient. The signature value reference ID MUST point to a
structure directly included within a Manifest. This reference can
omitted if the application can specify the digest value

SignatureCertRef: A reference to the certificate used to sign
Value pointed to by the SignatureValueRef. This reference can
omitted if the application can identify the certificate

RecipientRefs: A list of references to the IOTP Org ID of
recipients this signature is intended for

4.3.8

The key identifier element can identify the shared public/
key identification between parties that benefit from a
relationship. This element can be included in the
Element

value CDATA #
>

Davidson & Kawatsura Informational [Page 12]

RFC 2802 Digital Signatures for IOTP April 2000

4.3.9

A Parameter element provides the value of a particular
parameter, whose name and format have been specified for
algorithm considered

Parameter ANY >
type CDATA #
>

For IOTP 1.0, the following parameter type is standardized
"AlgorithmRef".

An AlgorithmRef contains an ID of a "sub-Algorithm" used
computing a sequence of algorithms. For example, a
algorithm actually signs a digest algorithm. To specify a chain
algorithms used to compute a signature, AlgorithmRef parameter
are used in the following manner

<Algorithm ID='A1' type='digest' name='urn:ibm-com:dom-hash'>
<Parameter type='AlgorithmRef'>A2Parameter
Algorithm
<Algorithm ID='A2' type='digest' name='urn:nist-gov:sha1'>
Algorithm
<Algorithm ID='A3' type='signature' name='urn:rsasdi-com:rsa-encryption'>
<Parameter type='AlgorithmRef'>A1Parameter
Algorithm

Content

ANY: The contents of a Parameter element consists of ANY
construct, which is specified on a per algorithm per parameter basis

Attributes

type: The type of the parameter expressed as a free form string
whose value is specified on a per algorithm basis

4.4 Certificate

4.4.1

The Certificate element may be used for either providing the value
a digital certificate or specifying a location from where it may
retrieved

Davidson & Kawatsura Informational [Page 13]

RFC 2802 Digital Signatures for IOTP April 2000

( IssuerAndSerialNumber
( Value | Locator ) )
>
ID ID #
type NMTOKEN #REQUIRED >

Content

IssuerAndSerialNumber: Unique identifier of this certificate.
element has been made mandatory is order to prevent
decoding during validation of a certificate chain. This feature
helps certificates caching, especially when the value is not
provided

Value: Encoding of the certificate value. The actual value to
encoded depends upon the type of the certificate

Locator: XML link element that could be used for retrieving a copy
the digital certificate. The actual value being returned by means
this locator depends upon the security protocol being used

Attributes

ID: Element identifier that may be used to reference the
element from a RecipientInfo element

type: Type of the digital certificate. This attribute is specified
a Universal Resource Name. Support for the X.509 version 3
certificate [X.509] is mandatory in this specification if
Certificate element is used. The URN for such certificates
"urn:X500:X509v3".

4.4.2

The IssuerAndSerialNumber element identifies a certificate,
thereby an entity and a public key, by the name of the
issuer and an issuer-specific certificate identification

issuer CDATA #
number CDATA #REQUIRED >

Davidson & Kawatsura Informational [Page 14]

RFC 2802 Digital Signatures for IOTP April 2000

Attributes

issuer: Name of the issuing certification authority. See [RFC 2253]
for RECOMMENDED syntax

number: Issuer-specific certificate identification

4.5 Common

4.5.1

A value contains the "raw" data of a signature or digest algorithm
usually in a base-64 encoded form. See [RFC 2045] for algorithm
to base-64 encode data

ID ID #
encoding (base64|none) 'base64'
>

Content

PCDATA: Content value after adequate encoding

Attributes

encoding: This attribute specifies the decoding scheme to
employed for recovering the original byte stream from the content
the element. This document recognizes 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
CDATA section or XML escaping

base64: The content has been encoded by means of the base64
scheme

4.5.2

The Locator element consists of simple XML link [XLink].
element allows unambiguous reference to a resource or fragment of
resource

xml:link CDATA #FIXED 'simple
href CDATA #REQUIRED >

Davidson & Kawatsura Informational [Page 15]

RFC 2802 Digital Signatures for IOTP April 2000

Attributes

xml:link: Required XML link attribute that specifies the nature
the link (simple in this case).

href: Locator value that may contains either a URI [RFC 2396],
fragment identifier, or both

5. Supported

The IOTP specification 1.0 requires the implementation of the DSA
DOM-HASH, SHA1, HMAC algorithms. Implementation of RSA is
recommended

5.1 Digest

This specification contemplates two types of digest algorithms,
of which provide a digest string as a result

Surface string digest

These algorithms do not have any particular knowledge about
content being digested and operate on the raw content value.
changes in the surface string of a given content affect directly
value of the digest being produced

Canonical digest

These algorithms have been tailored for a particular content type
produce a digest value that depends upon the core semantics of
content. Changes limited to the surface string of a given content
not affect the value of the digest being produced unless they
the core semantic

5.1.1 SHA

Surface string digest algorithm designed by NIST and NSA for use
the Digital Signature Standard. This algorithm produces a 160-
hash value. This algorithm is documented in NIST FIPS
180-1 [SHA1].

This algorithm does not require any parameter

The SHA1 URN used for this specification is "urn:nist-gov:sha1".

Davidson & Kawatsura Informational [Page 16]

RFC 2802 Digital Signatures for IOTP April 2000

5.1.2 DOM-

XML canonical digest algorithm proposed by IBM Tokyo
Laboratory. This algorithm operates on the DOM representation of
document and provides an unambiguous means for recursive
of the hash value of the nodes that constitute the DOM tree [
2803]. This algorithm has many applications such as computation
digital signature and synchronization of DOM trees. However,
the hash value of an element is computed from the hash values of
inner elements, this algorithm is better adapted to small
that do not require one-pass processing

As of today, this algorithm is limited to the contents of an
document and, therefore, does not provide for authentication of
internal or external subset of the DTD

The DOM-HASH algorithm requires a single parameter, which
include a surface string digest algorithm such as SHA1.

The DOM-HASH URN used for this specification is "urn:ibm-com:dom
hash".

The DOM-HASH uses a surface-string digest algorithm for
of a fingerprint. The SHA1 is recommended in this specification

<Algorithm name='urn:fips:sha1' type='digest' ID='P.3'>
Algorithm

<Algorithm name='urn:ibm:dom-hash' type='digest' ID='P.5'>
<Parameter type='AlgorithmRef'>P.3Parameter
Algorithm

5.2 Signature

This specification uses the terminology of 'digital signature'
qualifying indifferently digital signature and message
codes. Thus, the signature algorithms contemplated herein
public key digital signature algorithms such as ECDSA and
authentication codes such as HMAC [RFC 2104].

5.2.1

Public-key signature algorithm proposed by NIST for use with
Digital Signature Standard. This standard is documented in NIST
Publication 186 [DSS] and ANSI X9.30 [X9.30].

Davidson & Kawatsura Informational [Page 17]

RFC 2802 Digital Signatures for IOTP April 2000

The DSA algorithm requires a single parameter, which includes
canonical digest algorithm to be used for computing the
of the signature Manifest

The DSA URN used in this specification is "urn:nist-gov:dsa".

The DSA uses a canonical or surface-string digest algorithm
computation of the Manifest fingerprint. The DOM-HASH is
in this specification

Signature Value Encoding

The output of this algorithm consists of a pair of integers
referred by the pair (r, s). The signature value shall consist of
concatenation of two octet-streams that respectively result from
octet-encoding of the values r and s. Integer to octet-
conversion shall be done according to PKCS#1 [RFC 2437]
with a k parameter equals to 20.

<Algorithm name='urn:nist-gov:dsa' type='signature' ID='P.3'>
<Parameter type='AlgorithmRef'>P.4Parameter
Algorithm
<Algorithm name='urn:ibm-com:dom-hash' type='digest' ID='P.4'>
<Parameter type='AlgorithmRef'>P.5Parameter
Algorithm
<Algorithm name='urn:nist-gov:sha1' type='digest' ID='P.5'>
Algorithm

5.2.2

Message Authentication Code proposed by H. Krawczyk et al.,
documented in [RFC 2104].

This specification adopts a scheme that differs a bit from the
usage of this algorithm -- computation of the MAC is performed on
hash of the contents being authenticated instead of the
contents. Thence, the actual signature value output by the
might be depicted as follows

SignatureValue = HMAC( SecretKey, H(Manifest))

This specification also considered HMAC output truncation such
proposed by Preneel and van Oorschot. In their paper [PV] these
researchers have shown some analytical advantages of truncating
output of hash-based MAC functions. Such output truncation is
considered in the RFC document

Davidson & Kawatsura Informational [Page 18]

RFC 2802 Digital Signatures for IOTP April 2000

HMAC requires three parameters. The first one consists of a
digest algorithm. The second one consists of a hash function.
last one is optional and specifies the length in bit of the
output. If this last parameter is absent, no truncation shall occur

The HMAC URN used in this specification is "urn:ietf-org:hmac".

Canonical digest algorithm: Canonical or surface-string
algorithm is to be used for computation of the Manifest fingerprint
The type of this parameter is set to "AlgorithmRef". The
value of this Parameter should be the ID reference for the
element DOM-HASH

Hash-function: Hash function is to be used to compute the MAC
from the secret key and the fingerprint of the signature Manifest
The type of this parameter is set to "HashAlgorithmRef" and the
of this parameter should be set to the ID reference for the
element of SHA1.

Output-length: Length in bits of the truncated MAC value. The type
this parameter is set to "KeyLength" and the value of this
is set the length in bits of the truncated MAC value

Signature Value Encoding

The output of this algorithm can be assumed as a large integer value
The signature value shall consist of the octet-encoded value of
integer. Integer to octet-stream conversion shall be done
to PKCS#1 [RFC 2437] specification with a k parameter equals
((Hlen +7) mod8), Mlen being the length in bits of the MAC value

<Algorithm name='urn:ietf-org:hmac' type='signature' ID='P.3'>
<Parameter type='AlgorithmRef'>P.4Parameter
<Parameter type='HashAlgorithmRef'>P.5Parameter
<Parameter type='KeyLength'>128Parameter
Algorithm
<Algorithm name='urn:ibm-com:dom-hash' type='digest' ID='P.4'>
<Parameter type='AlgorithmRef'>P.5Parameter
Algorithm
<Algorithm name='urn:nist-gov:sha1' type='digest' ID='P.5'>
Algorithm

Davidson & Kawatsura Informational [Page 19]

RFC 2802 Digital Signatures for IOTP April 2000

5.2.3

Public-key signature algorithm proposed by RSA Laboratories
documented in PKCS#1 [RFC 2437].

This specification adopts the RSA encryption algorithm with
block type 01. For computing the signature value, the signer
first digest the signature Manifest and then encrypt the
digest with his private key

This signature algorithm requires a single parameter, which
of the canonical digest algorithm to be used for computing
fingerprint of the signature Manifest

The RSA URN used in this specification is "urn:rsasdi-com:rsa
encription".

The RSA uses a canonical or surface-string digest algorithm
computation of the Manifest fingerprint. The DOM-HASH is
in this specification

Signature Value Encoding

The output of this algorithm consists of single octet-stream.
further encoding is required

<Algorithm name='urn:rsasdi-com:rsa-encription
type='signature' ID='P.3'>
<Parameter type='AlgorithmRef'>P.4Parameter
Algorithm
<Algorithm name='urn:ibm-com:dom-hash' type='digest' ID='P.4'>
<Parameter type='AlgorithmRef'>P.5Parameter
Algorithm
<Algorithm name='urn:nist-gov:sha1' type='digest' ID='P.5'>
Algorithm

5.2.4

Public-key signature algorithm proposed independently by Neil
and Victor Miller. This algorithm is being proposed as an
standard and is documented in ANSI X9.62 standard proposal [X9.62]
and IEEE/P1363 standard draft proposal [IEEE P1363].

Davidson & Kawatsura Informational [Page 20]

RFC 2802 Digital Signatures for IOTP April 2000

The ECDSA algorithm requires a single parameter, which consists
the canonical digest algorithm to be used for computing
fingerprint of the signature Manifest

The ECDSA URN used in this specification is "urn:ansi-org:ecdsa".

The ECDSA uses a canonical or surface-string digest algorithm
computation of the Manifest fingerprint. The DOM-HASH [RFC 2803]
recommended in this specification

Signature Value Encoding

The output of this algorithm consists of a pair of integers
referred by the pair (r, s). The signature value shall consist of
concatenation of two octet-streams that respectively result from
octet-encoding of the values r and s. Integer to octet-
conversion shall be done according to PKCS#1 [RFC 2437]
with a k parameter equals to 20.

<Algorithm name='urn:ansi-org:ecdsa' type='signature' ID='P.3'>
<Parameter type='AlgorithmRef'>P.4Parameter
Algorithm
<Algorithm name='urn:ibm-com:dom-hash' type='digest' ID='P.4'>
<Parameter type='AlgorithmRef'>P.5Parameter
Algorithm
<Algorithm name='urn:nist-gov:sha1' type='digest' ID='P.5'>
Algorithm

6.

The following is an example signed IOTP message

<
ID='M.2'
version='1.0'
IotpTransID='19990809215923@www.iotp.org
IotpTransType='BaselinePurchase
TransTimeStamp='1999-08-09T12:58:40.000Z+9'>

Davidson & Kawatsura Informational [Page 21]

RFC 2802 Digital Signatures for IOTP April 2000

<Signature
<Algorithm name='urn:nist-gov:sha1'
type='digest' ID='P.3'>
Algorithm
<Algorithm name='urn:nist-gov:dsa
type='signature' ID='P.4'>
<Parameter type='AlgorithmRef'>P.5Parameter
Algorithm
<Algorithm name='urn:ibm-com:dom-hash
type='digest' ID='P.5'>
<Parameter type='AlgorithmRef'>P.3Parameter
Algorithm

xsqsfasDys2h44u4ehJDe54he5j4
<
<
issuer='o=Iotp Ltd., c=US
number='12345678987654'/>
<
SignatureAlgorithmRef='P.4'
9dj28fjakA9sked0Ks01k2d7a0kgmf9dk19lf63kkDSs
Signature
<Certificate type='urn:X500:X509v3'>
<
issuer='o=GlobeSet Inc., c=US
number='123456789102356'/>
xsqsfasDys2h44u4ehJDe54he5j4dJYTJ
Certificate

<
ID='P.2'
PaymentRef='M.5'
ContentSoftwareId='abcdefg'>

snroasdfnas934

Davidson & Kawatsura Informational [Page 22]

RFC 2802 Digital Signatures for IOTP April 2000

7. Signature

Signature+ ,Certificate*) >
ID ID #
>

Signature (Manifest, Value+) >
ID ID #
>

( Algorithm+,
Digest+,
Attribute*,
OriginatorInfo
RecipientInfo
)
>

LocatorHRefBase CDATA #
>

Algorithm (Parameter*) >
ID ID #
type (digest|signature) #
name NMTOKEN #
>

Davidson & Kawatsura Informational [Page 23]

RFC 2802 Digital Signatures for IOTP April 2000

DigestAlgorithmRef IDREF #
>

Attribute ANY >
type NMTOKEN #
critical ( true | false ) #
>

OriginatorRef NMTOKEN #
>

SignatureAlgorithmRef IDREF #
SignatureValueRef IDREF #
SignatureCertRef IDREF #
RecipientRefs NMTOKENS #
>

value CDATA #
>

Parameter ANY >
type CDATA #
>

( IssuerAndSerialNumber, ( Value | Locator ) )
>

ID ID #
type NMTOKEN #
>

Davidson & Kawatsura Informational [Page 24]

RFC 2802 Digital Signatures for IOTP April 2000

issuer CDATA #
number CDATA #
>

ID ID #
encoding (base64|none 'base64'
>

xml:link CDATA #FIXED 'simple
href CDATA #
>

8. Security

This entire document concerns the IOTP v1 protocol signature
which is used for authentication. See the Security
section of [RFC 2801] "Internet Open Trading Protocol - IOTP,
1.0".

Davidson & Kawatsura Informational [Page 25]

RFC 2802 Digital Signatures for IOTP April 2000

[DSA] Federal Information Processing Standards
FIPS PUB 186, "Digital Signature Standard(DSS)", 1994,

[IEEE P1363] IEEE P1363, "Standard Specifications for Public-
Cryptography", Work in Progress, 1997,

[PV] Preneel, B. and P. van Oorschot, "Building fast
from hash functions", Advances in Cryptology --
CRYPTO'95 Proceedings, Lecture Notes in
Science, Springer-Verlag Vol.963, 1995, pp. 1-14.

[RFC 1321] Rivest, R., "The MD5 Message-Digest Algorithm",
1321, April 1992.

[RFC 2045] Freed, N. and N. Borenstein, "Multipurpose Internet
Extensions (MIME) Part One: Format of Internet
Bodies", RFC 2045, November 1996.

[RFC 2046] Freed N. and N. Borenstein, "Multipurpose Internet
Extensions (MIME) Part Two: Media Types", RFC 2046,
November 1996.

[RFC 2104] Krawczyk, H., Bellare, M. and R. Canetti, "HMAC: Keyed
Hashing for Message Authentication", RFC 2104,
1997.

[RFC 2141] Moats, R., "URN Syntax", RFC 2141, May 1997.

[RFC 2253] Wahl, W., Kille, S. and T. Howes, "Lightweight
Access Protocol (v3): UTF-8 String Representation
Distinguished Names", RFC 2253, December 1997.

[RFC 2396] Berners-Lee, T., Fielding, R. and L. Masinter, "
Resource Identifiers (URI): Generic Syntax", RFC 2396,
August 1998.

[RFC 2437] Kaliski, B. and J. Staddon, "PKCS #1: RSA
Specifications, Version 2.0", RFC 2437, October 1998.

[RFC 2801] Burdett, D., "Internet Open Trading Protocol - IOTP
Version 1.0", RFC 2801, April 2000.

[RFC 2803] Maruyama, H., Tamura, K. and N. Uramot, "Digest
for DOM (DOMHASH)", RFC 2803, April 2000.

Davidson & Kawatsura Informational [Page 26]

RFC 2802 Digital Signatures for IOTP April 2000

[Schneier] Bruce Schneier, "Applied Cryptography: Protocols
Algorithms, and Source Code in C", 1996, John Wiley

[SHA1] NIST FIPS PUB 180-1, "Secure Hash Standard,"
Institute of Standards and Technology, U.S.
of Commerce, April 1995.

[X.509] ITU-T Recommendation X.509 (1997 E), "
Technology - Open Systems Interconnection -
Directory: Authentication Framework", June 1997.

[X9.30] ASC X9 Secretariat: American Bankers Association
"American National Standard for Financial Services -
Public Key Cryptography Using Irreversible
for the Financial Services Industry - Part 1:
Digital Signature Algorithm(DSA)", 1995.

[X9.62] ASC X9 Secretariat: American
Association,"American National Standard for
Services - Public Key Cryptography Using
Algorithms for the Financial Services Industry -
Elliptic Curve Digital Signature Algorithm (ECDSA)",
Work in Progress, 1997.

[XLink] Eve Maler, Steve DeRose, "XML Linking Language (XLink)",

[XML] Tim Bray, Jean Paoli, C. M. Sperber-McQueen, "
Markup Language (XML) 1.0",

Davidson & Kawatsura Informational [Page 27]

RFC 2802 Digital Signatures for IOTP April 2000

Authors'

The authors of this document are

Kent M.
Differential, Inc
440 Clyde Ave
Mountain View, CA 94043

EMail: kent@differential.

Yoshiaki
Hitachi, Ltd
890-12 Kashimada Saiwai Kawasaki
Kanagawa 2128567

EMail: kawatura@bisd.hitachi.co.

Davidson & Kawatsura Informational [Page 28]

RFC 2802 Digital Signatures for IOTP April 2000

Full Copyright

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

This document and translations of it may be copied and furnished
others, and derivative works that comment on or otherwise explain
or assist in its implementation may be prepared, copied,
and distributed, in whole or in part, without restriction of
kind, provided that the above copyright notice and this paragraph
included on all such copies and derivative works. However,
document itself may not be modified in any way, such as by
the copyright notice or references to the Internet Society or
Internet organizations, except as needed for the purpose
developing Internet standards in which case the procedures
copyrights defined in the Internet Standards process must
followed, or as required to translate it into languages other
English

The limited permissions granted above are perpetual and will not
revoked by the Internet Society or its successors or assigns

This document and the information contained herein is provided on
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED,
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE

Funding for the RFC Editor function is currently provided by
Internet Society

Davidson & Kawatsura Informational [Page 29]

if you see any problems within the linking, don't worry be happy,
this is version 0.1 of the Relevance System and you gotta expect some crappy subroutines sometimes,
just be content we did not write this in Java, which would have made this "bigger and better" HAHAHHA.

RFC documents can be found at I.E.T.F.

Relevance System Copyright © 2002 Spectrum WorldResearch
other technical nosh by ServerMasters Corporation
collaboration of BobX