Subject: I-D ACTION:draft-ietf-smime-ecc-03.txt

From: [email-masked]
Date: Wed, 07 Mar 2001 07:46:41 -0500

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the S/MIME Mail Security Working Group of the IETF.

	Title		: Use of ECC Algorithms in CMS
	Author(s)	: D. Brown, S. Blake-Wilson, P. Lambert
	Filename	: draft-ietf-smime-ecc-03.txt
	Pages		: 15
	Date		: 06-Mar-01
	
This document describes how to use Elliptic Curve Cryptography
(ECC) public-key algorithms in the Cryptographic Message Syntax
(CMS).  The ECC algorithms support the creation of digital
signatures and the exchange of keys to encrypt or authenticate
content.  The definition of the algorithm processing is based on
the ANSI X9.62 standard and the ANSI X9.63 draft, developed by the
ANSI X9F1 working group.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-smime-ecc-03.txt

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-smime-ecc-03.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-ietf-smime-ecc-03.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

---

From: [email-masked]
Date: Wed, 7 Mar 2001 15:13:52 -0500

Hi Simon,

I had a quick look over this latest Internet Draft (ID) on how to use
Elliptic Curve Cryptography (ECC) public-key algorithms in the Cryptographic
Message Syntax (CMS) and came up with the following technical and editorial
comments:

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.

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.

c.  Section 2.1.1, the reference to Section 7.2 for the ECDSA-Sig-Value is
incorrect.

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?

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

f.  Section 2.1.2, the last sentence should be referring to Section 8.2 when
mentioning the ECDSA-Sig-Value syntax.

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.

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.

i.  Section 3.1.1, the reference to Section 7.1 for the
dhSinglePass-stdDH-sha1kdf-scheme object identifier is incorrect.

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.

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.

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.

m.  Section 5, why do you not refer to SEC2 instead of SEC3 when
recommending elliptic curve domain parameters?

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).

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).

p.  Section 9, although ANSI X9.62 was approved in January 1999, the
official date for referring to this standard is still 1998.

q.  Section 9, according to the SECG web site, SEC3 is still a draft
standard and has not yet been approved.

Please feel free to contact me if you have any question on these comments.

Cheers,

Francois
___________________________________
Francois Rousseau
Director of Standards and Conformance
Chrysalis-ITS
One Chrysalis Way
Ottawa, Ontario, CANADA, K2G 6P9
[email-masked]    Tel. (613) 723-5076 ext. 3419
http://www.chrysalis-its.com   Fax. (613) 723-5078

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Wednesday, March 07, 2001 07:47
Cc: [email-masked]
Subject: I-D ACTION:draft-ietf-smime-ecc-03.txt

A New Internet-Draft is available from the on-line Internet-Drafts
directories.
This draft is a work item of the S/MIME Mail Security Working Group of the
IETF.

---

From: "Daniel Brown" <[email-masked]>
Date: Wed, 7 Mar 2001 18:57:38 -0500

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.

-------------------------------------------------------------------------

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

------------------------------------------------------------------------

--> So do you want us to add more use of key words to the document?

-------------------------------------------------------------------------

--> Agree.

-------------------------------------------------------------------------

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

-------------------------------------------------------------------------

--> Agree.

-------------------------------------------------------------------------

--> Agree.

-------------------------------------------------------------------------

--> Agree.

-------------------------------------------------------------------------

--> Agree.

-------------------------------------------------------------------------

--> Agree.

-------------------------------------------------------------------------

--> Agree.

-------------------------------------------------------------------------

--> Agree.

-------------------------------------------------------------------------

--> Agree.

-------------------------------------------------------------------------

--> Agree.

-------------------------------------------------------------------------

--> Agree.

-------------------------------------------------------------------------

--> Agree.

-------------------------------------------------------------------------

--> Agree.

-------------------------------------------------------------------------

--> Agree.

-------------------------------------------------------------------------

Thanks again,

Best regards,

Dan & Simon

---

From: [email-masked]
Date: Thu, 8 Mar 2001 10:16:44 -0500

Hi Daniel,

See my responses below preceded by FR>.

Cheers, 

Francois

-----Original Message-----
From: Daniel Brown [mailto:[email-masked]]
Sent: Wednesday, March 07, 2001 18:58
To: [email-masked]
Cc: Simon Blake-Wilson; [email-masked]
Subject: RE: I-D ACTION:draft-ietf-smime-ecc-03.txt

Hi Francois,

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.

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.

FR> I do not consider myself an expert with AuthenticatedData, but see my
two responses above.

FR> Yes since it will make checking of conformance with this ID much easier
in the future.

[snip]

---

From: "Simon Blake-Wilson" <[email-masked]>
Date: Thu, 8 Mar 2001 16:02:21 -0500

Hi Francois,

Thanks. I think we only have one issue left open ... see below marked SBW>.

Best regards. Simon

SBW> I'm still confused. I don't think ephemeral-static DH or ECDH can
provide either data origin authentication or data integrity when used
with AuthenticatedData ... because the sender is not authenticated, an
attacker can both insert and alter messages. So I don't think
ephemeral-static DH provides any security with AuthData. Please can someone
explain to me what it provides if I'm missing something!

SBW> I agree that only the shared secret Z is fixed, and varying ukm can result
in a session specific
key. However fixed Z still seems undesirable, and I don't think its sensible to
include static-static
ECDH in our draft for AuthData when it is not included in CMS for AuthData. Am I
getting anywhere
convincing you? If CMS added static-static DH for AuthData, we could certainly
add it to our draft.

[email-masked] on 03/08/2001 10:16:44 AM

To:   Daniel Brown/Certicom@Certicom
cc:   Simon Blake-Wilson/Certicom@Certicom, [email-masked]
Subject:  RE: I-D ACTION:draft-ietf-smime-ecc-03.txt

Hi Daniel,

Cheers,

Francois

-----Original Message-----
From: Daniel Brown [mailto:[email-masked]]
Sent: Wednesday, March 07, 2001 18:58
To: [email-masked]
Cc: Simon Blake-Wilson; [email-masked]
Subject: RE: I-D ACTION:draft-ietf-smime-ecc-03.txt

Hi Francois,

[snip]