Subject: Re: Comments of IOTP DSIG.

From: "Donald E. Eastlake 3rd" <[email-masked]>
Date: Thu, 01 Apr 1999 01:11:40 -0500

From:  Yoshiaki KAWATSURA <[email-masked]>
Message-Id:  <[email-masked]>
To:  [email-masked]
Cc:  [email-masked]
Date:  Tue, 30 Mar 1999 15:30:10 +0900 (JST)

>I have some comments for IOTP DSIG.
>
>(a) 3.2 Digest Element
>There is no DTD definition of Resource Element.
>We should add the definition of DTD.

Due to the limited requirements of IOTP, we put multiple digests into
the Manifest and don't really need a separate Resource element, do we?

>(b) 4.3.5 I do not understand why the Attributes element is needed.
>I think that this is because there is no attribute in Attributes.  
>
>I suggest to remove the followings,
>
>Current:
>   <!ELEMENT Manifest
>           (       Algorithm+,
>                   Digest+,
>                   Attributes?,
>                   OriginatorInfo,
>                   RecipientInfo+,
>           )
>
>
>My New Suggestion:
>   <!ELEMENT Manifest
>           (       Algorithm+,
>                   Digest+,
>                   Attribute*,
>                   OriginatorInfo,
>                   RecipientInfo+,
>           )

You have a point but I think that on balance we should leave it there
in case some implementation of v1.0 wants to add some authenticated
attribute.

>(c) The XML reference is only the backward reference, such that one
>pass procedure, in order to lighten the signature process.
>
>Therefore I suggest the following replacement.
>
> (1) To exchange the order between Signature Component and Certificate
>     Component.

I think the main concern is to avoid buffering the main part of the
docment.  Buffering the IOTPSignatures element doesn't seem like such
a big thing.  Still, I don't have any problem with swapping these.
Does anyone else have an opinion?

> (2) To exchange the order between Manifest Element and Value Element.

Same comment as (1) above...

>(d) I just wonder who and how will the ANY data define in 4.3.7, 4.3.8
>and 4.3.9?  Additionally, who and how will the type data define in
>4.4.1?  We should define the above data for the reason of
>interoperability.  And I suggest that these data(include chapter 5)
>should be defined in the separate document.

For 4.3.9, what type of parameter is appropriate is defined by the
Algorithm.

For 4.3.7 and 4.3.8, the signer and verifier can agree on what they
want to put there.  In v1.0, they are assumed to have prior
acquaintenace and can agree on this.

On 4.4.1, I guess at least one value should be put in the Supported
Algorithms section, like it says...

>(e) 5 Supported Algorithm
>The current draft specifies the supported algorithms as follows,
>"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."
>I think this is very restricted because the REQUIRE is used as the same
>mean of MANDATORY in the RFC2026, so I suggest "requires the
>implementaton of" should be replaced by "should implement."

The idea was that at least one algorithm of each required type should
be mandatory so that any two compliant implementations can
interoperate.  I suppose MD5 should be dropped from the list.  The
ones that are required are all, as far as I know, free from licensing
restrictions.

>Regards,
>----
>Yoshiaki Kawatsura : E-mail [email-masked]
> Business & Information Systems Development Devision, Hitachi,Ltd.
>Voice: +81-44-549-1713(direct) Fax: +81-44-549-1721

Thanks,
Donald
===================================================================
 Donald E. Eastlake 3rd   +1 914-276-2668   [email-masked]
 65 Shindegan Hill Rd, RR#1  +1 914-784-7913(w)     [email-masked]
 Carmel, NY 10512 USA
-----------------------------------------------------------------------
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: "Kent M. Davidson" <[email-masked]>
Date: Thu, 01 Apr 1999 14:41:07 -0800

>We should add the definition of DTD.

Sorry, this was an oversight. I will remove the extraneous Resource references in the document.

>I suggest to remove the followings,

This is merely a matter of style, and really doesn't make any functional difference except you can reference all Attributes via a single node. Unless other people think it's a good idea to remove it, I'd rather leave it in.

> (2) To exchange the order between Manifest Element and Value Element.

Ordering in XML is arbitrary and does not need to be enforced. You may order the elements in your XML document in whatever order you wish. No need to change the document.

>should be defined in the separate document.

Anyone may define the ANY data definition. It is intended for anyone to put information they deem necessary into the element. An acceptible implementation can only view the attributes defined by the standard, and ignore any other internal elements.

>Algorithms section, like it says...

Thanks!

-Kent.

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

_____________________________________________________________
Kent M. Davidson
VP Engineering
Differential, Inc.
http://www.differential.com
main (650)426-1100
fax  (650)426-1101

---

From: Yoshiaki KAWATSURA <[email-masked]>
Date: Tue, 06 Apr 1999 11:26:04 +0900 (JST)

Kent,
>>>>> Thu, 01 Apr 1999 14:41:07 -0800,
 
 > This is merely a matter of style, and really doesn't make any functional difference except you can reference all Attributes via a single node. Unless other people think it's a good idea to remove…
 
Yes, this is just a matter of style, but this would be considered important.
you write about the objective for your draft Chapter 2 as following:
"-- Provide lightweight signatures with minimal redundancy"
It seems to me that this part of your draft might contradict this objective.
What do other people think?
 
 > Ordering in XML is arbitrary and does not need to be enforced. You
 > may order the elements in your XML document in whatever order you
 > wish. No need to change the document.
 
I would rather take different perspective. We have to obey the DTD
definition different from the specification. For example, if we use
the internal DTD in the IOTP wallet, this might occur the DTD error.

Regards,
----