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.
--> 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.
--> Make sense? Can anyone explain how ephemeral-static
Diffie-Hellman provides security with AuthenticatedData?
------------------------------------------------------------------------
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?
-------------------------------------------------------------------------
c. Section 2.1.1, the reference to Section 7.2 for the ECDSA-Sig-Value is
incorrect.
--> Agree.
-------------------------------------------------------------------------
d. Sections 2.1.2 and 2.1.3, there seems to be some confusion as to whether
the message digest is a bit string, an octet string or an integer.
According to ANSI X9.30 Part 2, FIPS 180-1 and a 1999 draft revision of ANSI
X9.62, which is only available on the ANSI X9F1 web site, the message digest
is a bit string. However, according to this ID and the SECG SEC1 standard,
the message digest is an octet string. Finally, according to the approved
ANSI X9.62:1988 standard, the message digest magically becomes the integer
"e". Which one is correct?
--> It seems like ANSI views octet strings as a subset of bit
strings---rather than viewing "octet strings" and "bit strings" as
separate sets, as IEEE prefers. Fortunately, it seems like all specs
are equivalent for the cases of interest. We'll try to clarify the ID
here.
-------------------------------------------------------------------------
e. Sections 2.1.2 and 2.1.3, the ID should explain why it is making these
exceptions from the ANSI X9.62 standard with the integer "e".
--> Agree.
-------------------------------------------------------------------------
f. Section 2.1.2, the last sentence should be referring to Section 8.2 when
mentioning the ECDSA-Sig-Value syntax.
--> Agree.
-------------------------------------------------------------------------
g. Section 2.1.3, it is the integer "e'" and not "e" that is mentioned in
Section 5.4.1 of ANSI X9.62.
--> Agree.
-------------------------------------------------------------------------
h. Section 3.1.1, the last sentence of the second paragraph should indicate
that the ECPoint represents the sending agent's ephemeral EC public key.
--> Agree.
-------------------------------------------------------------------------
i. Section 3.1.1, the reference to Section 7.1 for the
dhSinglePass-stdDH-sha1kdf-scheme object identifier is incorrect.
--> Agree.
-------------------------------------------------------------------------
j. Sections 3.1.3 and 3.2.3 should both indicate that the "SharedData" is
the DER encoding of ECC-CMS-SharedInfo from Section 8.2 similarly to
Sections 3.1.2 and 3.2.2.
--> Agree.
-------------------------------------------------------------------------
k. Section 3.2.1, it is not clear why the version is mentioned in this case
and not under Section 3.1.1 since the value of 3 for the version is not
different than CMS when using the KeyAgreeRecipientInfo.
--> Agree.
-------------------------------------------------------------------------
l. Section 3.2.1, you should be referring to Section 8.2 when mentioning
the ECPoint that represents the sending agent's ephemeral EC public key.
--> Agree.
-------------------------------------------------------------------------
m. Section 5, why do you not refer to SEC2 instead of SEC3 when
recommending elliptic curve domain parameters?
--> Agree.
-------------------------------------------------------------------------
n. Section 7, as per other RFCs (e.g. RFC 2876 (KEA), RFC 2984 (CAST), RFC
3058 (IDEA)), it would be very useful to include some specific DER encoding
of the SMIMECapability (e.g. ECDSA, ECDH with Triple DES wrapping).
--> Agree.
-------------------------------------------------------------------------
o. Section 8.2, when referring to ANSI X9.63 key derivation function in the
last paragraph, the ID should also be referring to the appropriate section
of X9.63 that specifies this key derivation function (i.e. Section 5.6.3).
--> Agree.
-------------------------------------------------------------------------
p. Section 9, although ANSI X9.62 was approved in January 1999, the
official date for referring to this standard is still 1998.
--> Agree.
-------------------------------------------------------------------------
q. Section 9, according to the SECG web site, SEC3 is still a draft
standard and has not yet been approved.
--> Agree.
-------------------------------------------------------------------------
Thanks again,
Best regards,
Dan & Simon