Subject: IOTP Disg Spec version 01

From: David Burdett <[email-masked]>
Date: Mon, 23 Aug 1999 16:42:05 -0700

I've read through the specification and spotted the following mainly minor
problems.

David
===============
COMMENTS
=========
2. Objectives and Requirements
------------------------------
Says " signature algorithms one of which is mandatory..." yet section 5.
Supported algorithms seems to *require* that five algorithms are supported.
Do we require support of several or just one? I'd go for just one ... but
which?

4.2 IOTPSignatures
------------------
Suggest changing "IOTPSignatures" ==> "IotpSignatures" this makes it
consistent with other uses of "Iotp" in attribute and element names in the
main IOTP specification. Also need to change DTD in section 7.

4.3.1 Signature
---------------
Sixth para says ... "the digest is then signed using a public-key
alghorithm". I thought we were also allowing shared secret keys/symmetric
signatures?

4.3.2 Manifest
--------------
Defintion of LocatorHrefBase. After "... to create the entire URL." suggest
adding "See definition of the Locator attribute on the Digest element for
more detail." (also see next comment).

Also don't we need "//" in the example as in ...
"iotp://<globally-unique-tid>#"

4.3.4 Digest
------------
Locator Attribute: I think we need to be more specific about how to refer to
another IOTP element. Therefore suggest clarifying the defintion of Locator
as follows:

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

	"iotp://<globally-unique-tid>#<id-value>"

This should be interpreted as referring to "An element with an ID attribute
that matches <id-value> in any IOTP Message that has a Transaction Id Block
with an IotpTransId that matches <globally-unique-tid>.

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

4.5.1 Value
-----------
DTD error Remove "#IMPLIED" from definition of encoding attribute. Also need
to change signature DTD in section 7.

TYPOS
=====
Status of this Document
-----------------------
1. Some funny double quotes on last line of third para.

3.2 Digest Element
------------------
1. "Equals" missing from "<Digest DigestAlgorithmRef= ..." and "Locator
href= ..."

3.3 Orginator and Recipient Information Elements
------------------------------------------------
1. First para ... "is providing" ==> "to provide"

3.4 Algorithm Element
---------------------
1. In Example first line should be ...
<Algorithm type='digest' id='12'>

4.2 IOTPSignatures
------------------
1. In DTD change "id" to "ID"
2. In description of ID attribute: change "to referenceing" ==> "to
reference"

4.3.1 Signature
---------------
1. Fifth para spelling eror: "canoicalized" ==> "canonicalized"
2. "Value" attribute defintion: change "single signature block" to "single
signature component",
3. In description of ID attribute: change "to referenceing" ==> "to
reference"

4.3.3 Algorithm
---------------
1. In DTD and description of attribute change "id" to "ID"

6. Examples
-----------
1. "IOtpTransId" ==> "IotpTransId"
2. "IOtpTransType" ==> "IotpTransType"

9. References
-------------
"Interenet" ==> "Internet"

10. Author's
------------
Change "David Burdett, Mondex" to "David Burdett, Commerce One"

Advanced Technology, CommerceOne
1600 Riviera Ave, Suite 200, Walnut Creek, CA 94596, USA
Tel: +1 (925) 941 4422; Email: [email-masked]

---

From: Yoshiaki KAWATSURA <[email-masked]>
Date: Tue, 24 Aug 1999 11:45:27 +0900 (JST)

David,
My comments are below.

>>>>> Mon, 23 Aug 1999 16:42:05 -0700,

> I've read through the specification and spotted the following mainly minor

I suggest RSA,SHA1 and DomHash are required to implement and DSA,
MD5 are recommended to implement. What do you think?

> 4.2 IOTPSignatures

I will change.

> 4.3.1 Signature

I agree with you. I suggest to add the KeyIdentifier element as followings:

<!ELEMENT KeyIdentifier EMPTY>
<!ATTLIST dsig:Identifier
  value             CDATA        #REQUIRED

This element is in the OriginatorInfo component and use to identify
the shared key.

What do you think?

> 4.3.4 Digest

I do not think the LocatorHrefBase attribute needs. I want to drop
this attribute.  What do you think?

> 4.5.1 Value

Ok, I will change from #IMPLIED to #REQUIRED.

> Status of this Document

Sorry. I will change.

> 3.2 Digest Element

I will change.

> 3.3 Orginator and Recipient Information Elements

I will change.

> 3.4 Algorithm Element

I will change.

> 4.2 IOTPSignatures

will do.

> 4.3.1 Signature

I will change.

> 4.3.3 Algorithm

Will do.

> 6. Examples

I will change.

> 9. References

I will change.

> 10. Author's

I will change.

> Tel: +1 (925) 941 4422; Email: [email-masked]

----
Yoshiaki Kawatsura : E-mail [email-masked]
 Business & Information Systems Development Division, Hitachi,Ltd.
Voice: +81-44-549-1713(direct) Fax: +81-44-549-1721
-----------------------------------------------------------------------
Message addressed to: [email-masked]
Archive available at: http://www.elistx.com/archives/ietf-trade/
To (un)subscribe send a message with "subscribe" or "unsubscribe" in the
body to: [email-masked]

---

From: "Donald E. Eastlake 3rd" <[email-masked]>
Date: Tue, 24 Aug 1999 00:00:36 -0400

From:  Yoshiaki KAWATSURA <[email-masked]>
Message-Id:  <[email-masked]>
To:  [email-masked]
Cc:  [email-masked]
Cc:  [email-masked]
In-Reply-To:  Your message of "Mon, 23 Aug 1999 16:42:05 -0700"
	     	<123B7EB05559D311B0D900A0C9EA3D7604F1C6@NEPTUNE>
References:  <123B7EB05559D311B0D900A0C9EA3D7604F1C6@NEPTUNE>
Date:  Tue, 24 Aug 1999 11:45:27 +0900 (JST)

>MD5 are recommended to implement. What do you think?

I believe that DSA is more favored by the IESG so I would make it and
HMAC-SHA1 (for secret key) mandatory with RSA recommended.  I'm not
sure there is any reason to recommend MD5 or HAMS-MD5.

>This element is in the OriginatorInfo component and use to identify

Sounds reasonable.

>> 4.3.2 Manifest

Right.  In fact, I think it is wrong since "scheme://" is supposed to
be followed by [username[:password]@]domain-name[:port].

>> 4.3.4 Digest

Drop // as above.

>this attribute.  What do you think?

We previously decided that there might be many resources being signed
and a long transaction id so it saved enough space.  I suggest we leave
it in unless there are others who want to drop it...

>Voice: +81-44-549-1713(direct) Fax: +81-44-549-1721

Donald