Hi Daniel,
See my responses below preceded by FR>.
Cheers,
Francois
___________________________________
Francois Rousseau
Director of Standards and Conformance
Chrysalis-ITS
One Chrysalis Way
Ottawa, Ontario, CANADA, K2G 6P9
frousseau(_at_)chrysalis-its(_dot_)com Tel. (613) 723-5076 ext. 3419
http://www.chrysalis-its.com Fax. (613) 723-5078
-----Original Message-----
From: Daniel Brown [mailto:dbrown(_at_)certicom(_dot_)com]
Sent: Wednesday, March 07, 2001 18:58
To: FRousseau(_at_)chrysalis-its(_dot_)com
Cc: Simon Blake-Wilson; ietf-smime(_at_)imc(_dot_)org
Subject: RE: I-D ACTION:draft-ietf-smime-ecc-03.txt
Hi Francois,
Your comments are greatly appreciated, thank you.
The responses to your comments are preceded by -->. Comment-response
pairs are separated by line of -'s. Most of your comments, we'll fold
into the draft. There are a couple where we have follow-up
questions---see below.
-------------------------------------------------------------------------
a. Sections 1, 3.2, 4.1 and 8.2, it is not clear why only the ECMQV key
agreement algorithm is supported with AuthenticatedData and not also the
ECDH key agreement algorithm. Although ECMQV is comparable to KEA, which
can also be used with AuthenticatedData, ECDH is the analog to the X9.42
Diffie-Hellman key agreement algorithm specified in RFC 2630 and is the
default algorithm with AuthenticatedData.
--> We looked at RFC 2630 which specifies the use of ephemeral-static
Diffie-Hellman within AuthenticatedData---but we didn't understand how
this mechanism provides authentication of the sender since the sender
is not certified. We didn't want to include the analogous technique
based on these concerns.
FR> However, as indicated in Section 4 of your ID, AuthenticatedData lacks
non-repudiation, and so in some instances is preferable to SignedData (For
example, the sending agent may not want the message to be authenticated when
forwarded). Using ephemeral-static ECDH within AuthenticatedData can
achieve this goal, but not necessarily ECMQV or static-static ECDH, which
both require a certified public key from the sender. As per Section 9 of
RFC 2630, the goal of AuthenticatedData is to protect the integrity of the
content, but not to necessarily provide authentication of the sender. Note
also that RFC 2631 specifies both the ephemeral-static and the static-static
Diffie-Hellman modes.
--> Of course we could have included static-static ECDH, but this
would involve a fixed Diffie-Hellman "shared secret" (Z) between each
pair of correspondents, which seems undesirable.
FR> True, but I though this was the reason under Section 8.2 of your ID that
the octet string ukm in the entityUInfo field of the ECC-CMS-SharedInfo
could optionally be supplied by the sending agent. By mandating the use of
the octet string ukm with the static-static ECDH, you would certainly avoid
this undesirable effect. Similarly, in Section 2.1.2 of RFC 2631, the
partyAInfo MUST be used in Static-Static mode, but MAY appear in
Ephemeral-Static mode to avoid this same undesirable effect.
--> Make sense? Can anyone explain how ephemeral-static
Diffie-Hellman provides security with AuthenticatedData?
FR> I do not consider myself an expert with AuthenticatedData, but see my
two responses above.
------------------------------------------------------------------------
b. Section 1.1, although this section lists the key words used in this ID
as per RFC 2119, they are in reality used quite sparsely throughout this ID.
--> So do you want us to add more use of key words to the document?
FR> Yes since it will make checking of conformance with this ID much easier
in the future.
[snip]