Subject: RE: IOTP Disg Spec version 01

From: David Burdett <[email-masked]>
Date: Tue, 24 Aug 1999 13:37:22 -0700

Yoshiaki

Basically I agree with your comments as modified by Don except with respect
to my comment on section 4.5.1 (Value element). I also think that we should
keep the LocatorHrefBase attribute.

Currently in the DTD Value is defined as follows:

   <!ELEMENT Value ( #PCDATA ) >
   <!ATTLIST Value
           id              ID           #IMPLIED
           encoding    (base64|none)    #IMPLIED      'base64'

This is not legal. So my suggestion was meant to suggest that we change it
to:

   <!ELEMENT Value ( #PCDATA ) >
   <!ATTLIST Value
           id              ID           #IMPLIED
           encoding    (base64|none)    'base64'

This means that if there is no encoding attribute present then an encoding
of 'base64' should be implied. If we make it required, then we can't give a
list of valid values.

Regards

David

-----Original Message-----
From: Donald E. Eastlake 3rd [mailto:[email-masked]]
Sent: Monday, August 23, 1999 9:01 PM
To: Yoshiaki KAWATSURA
Cc: [email-masked]; [email-masked]
Subject: Re: IOTP Disg Spec version 01 

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)

>David,
>My comments are below.
>
>>>>>> Mon, 23 Aug 1999 16:42:05 -0700,
>	David Burdett <[email-masked]> said:
>
>> 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?
>
>I suggest RSA,SHA1 and DomHash are required to implement and DSA,
>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.

>> 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.
>
>I will change.
>
>> 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?
>
>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?

Sounds reasonable.

>> 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>#"

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
>> ------------
>> 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>"

Drop // as above.

>> 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."
>
>I do not think the LocatorHrefBase attribute needs. I want to drop
>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...

>> 4.5.1 Value
>> -----------
>> DTD error Remove "#IMPLIED" from definition of encoding attribute. Also
need
>> to change signature DTD in section 7.
>
>Ok, I will change from #IMPLIED to #REQUIRED.
>
>
>> TYPOS
>> =====
>> Status of this Document
>> -----------------------
>> 1. Some funny double quotes on last line of third para.
>
>Sorry. I will change.
>
>> 3.2 Digest Element
>> ------------------
>> 1. "Equals" missing from "<Digest DigestAlgorithmRef= ..." and "Locator
>> href= ..."
>
>I will change.
>
>> 3.3 Orginator and Recipient Information Elements
>> ------------------------------------------------
>> 1. First para ... "is providing" ==> "to provide"
>
>I will change.
>
>> 3.4 Algorithm Element
>> ---------------------
>> 1. In Example first line should be ...
>> <Algorithm type='digest' id='12'>
>
>I will change.
>
>> 4.2 IOTPSignatures
>> ------------------
>> 1. In DTD change "id" to "ID"
>> 2. In description of ID attribute: change "to referenceing" ==> "to
>> reference"
>
>will do.
>
>> 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"
>
>I will change.
>
>> 4.3.3 Algorithm
>> ---------------
>> 1. In DTD and description of attribute change "id" to "ID"
>
>Will do.
>
>> 6. Examples
>> -----------
>> 1. "IOtpTransId" ==> "IotpTransId"
>> 2. "IOtpTransType" ==> "IotpTransType"
>
>I will change.
>
>> 9. References
>> -------------
>> "Interenet" ==> "Internet"
>
>I will change.
>
>> 10. Author's
>> ------------
>> Change "David Burdett, Mondex" to "David Burdett, Commerce One"
>
>I will change.
>
>> Advanced Technology, CommerceOne
>> 1600 Riviera Ave, Suite 200, Walnut Creek, CA 94596, USA
>> 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

Donald
-----------------------------------------------------------------------
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: Yoshiaki KAWATSURA <[email-masked]>
Date: Wed, 25 Aug 1999 10:03:08 +0900 (JST)

David,
My comment is below,
>>>>> Tue, 24 Aug 1999 13:37:22 -0700,

> of 'base64' should be implied. If we make it required, then we can't give a

Oh, my apologize...

According to LocatorHrefRef, I agree with you.
I will send my comment for the minimum required algorithms by separate mail.

Regards,
----

---

From: Yoshiaki KAWATSURA <[email-masked]>
Date: Wed, 25 Aug 1999 15:25:05 +0900 (JST)

Don and Burdett,

> sure there is any reason to recommend MD5 or HAMS-MD5.

I believe that RSA is better than DSA as the mandate signature algorithm
because RSA is used in the major protocol even as the signature algorithm.
RSA is used in major payment protocol, SET which uses RSA as the 
signature algorithm.

----

---

From: Patrik Fältström <[email-masked]>
Date: Wed, 25 Aug 1999 08:55:57 +0200

>> sure there is any reason to recommend MD5 or HAMS-MD5.

This is exactly the current procedures, as RSA is patented in the US, and
therefore can not be implemented by everyone on the planet.

   Patrik Faltstrom
   Area Director, Applications Area

---

From: "Donald E. Eastlake 3rd" <[email-masked]>
Date: Wed, 25 Aug 1999 08:32:53 -0400

Looking at CMS in RFC 2630, it mandates the implementation of both RSA
and DSA.  We could also go that way and make both mandatory.  I just
believe that IESG approval will be more difficult if DSA is not
mandatory, whether or not RSA is.  In most cases people will be using
crypto libraries that support both.

Donald

From:  Yoshiaki KAWATSURA <[email-masked]>
Message-Id:  <[email-masked]>
To:  [email-masked]
Cc:  [email-masked], [email-masked]
Cc:  [email-masked]
In-Reply-To:  Your message of "Tue, 24 Aug 1999 13:37:22 -0700"
	     	<123B7EB05559D311B0D900A0C9EA3D7604F1CB@NEPTUNE>
References:  <123B7EB05559D311B0D900A0C9EA3D7604F1CB@NEPTUNE>
Date:  Wed, 25 Aug 1999 15:25:05 +0900 (JST)
Sender:  Yoshiaki KAWATSURA <[email-masked]>

---

From: Yoshiaki KAWATSURA <[email-masked]>
Date: Thu, 26 Aug 1999 11:29:03 +0900 (JST)

I understood for your feedback.

I discussed about this topic with the specialist of crypt in my company
 yesterday. He mentioned to me that

(1) the basic patent of RSA will be expired sooner
(2) RSA is constantly modified for security in widely-used environment 
    than DSA.
(3) ECDSA should be mandatory, not DSA because 
    (3-1) Now is in a transition from DSA to ECDSA
    (3-2) ECDSA is also standardized by ANSI and IEEE.
    (3-3) ECDSA is harder than DSA to be attacked because of 
          its complex structure

So I suggest ECDSA and RSA should be mandatory.

----

>>>>> Wed, 25 Aug 1999 08:32:53 -0400,