Subject: RE: S/MIME ECC Doc

From: "Simon Blake-Wilson" <[email-masked]>
Date: Mon, 23 Apr 2001 18:03:18 -0400

Hi Russ,

Thanks for the comments. Responses below ...

(1) The specification only employs SHA-1. Should it be extended to include
to SHA-256 in anticipation of 128-bit AES keys?

Our goal was not to specify "new crypto" in this spec but rather leave that up
to the groups that focus on writing crypto specs. I don't know of any crypto
specs that have added SHA-2 support yet. So I'd propose to specify use of SHA-1
until the crypto specs add SHA-2 ... at which point we can add SHA-2 support in
a new draft or a rev of this spec.

(2) Does the 1-pass D-H scheme use co-factor multiplication? I understand
that it is possible to do it done with or without co-factor multiplication,
so I am really seeking clarification here.  Are there IPR issues regarding
the choice?

All we do is reference X9.63 which allows either "regular" ECDH or "cofactor"
ECDH ... so yes the 1-pass ECDH scheme allows cofactor ECDH. There are IPR
issues with cofactor ECDH (as with other EC schemes) ... here's what I know
about Certicom's IPR in this area (usual disclaimers, etc, etc):

- Certicom's SMIME IPR statement ...
http://www.ietf.org/ietf/IPR/CERTICOM-SMIME-1
- Certicom's IEEE 1363 statement ...
http://grouper.ieee.org/groups/1363/P1363/patents.html
- As far as I know, the most relevant patent is 5,933,504.

(3) Can you say something about the unknown key-share attack on MQV?  I
understand that this vulnerability can be avoided by explicit key
authentication.  A paragraph in the Security Considerations section should
be sufficient.

Sure we'll add a paragraph to Security considerations. Briefly, unknown
key-share is about fooling Bob into thinking a CEK he actually shares with Alice
is in fact shared with Eve. If Eve can do this, then maybe she can fool Bob into
believing a message from Alice is in fact from Eve. Unknown key-share is
therefore mainly concerned with authenticated and encrypted data ... because for
example, Eve can always take a message that she sees Alice sign and send to Bob,
and replace it with the same message, signed with Eve's key. When 1-pass MQV is
used in CMS to authenticate then encrypt data, the unknown key-share issue with
MQV doesn't arise because the ephemeral public key of Alice is included inside
authenticated-data, and therefore inside the encrypted content.

(4) Section 3.2.2. "Parity bits adjusted according to the keywrap
algorithm" is rather vague.  Please extract the appropriate text from RFC 2630.

To be as clear as possible, we propose to replace the quoted text with a simple
reference to 2630.

Please let me know if the proposed resolutions are not okay.

Best regards. Simon

S. Blake-Wilson
Certicom Corp.

---

From: "Housley, Russ" <[email-masked]>
Date: Tue, 24 Apr 2001 16:06:06 -0400

>a new draft or a rev of this spec.

I have no problem with this.  Can we add a paragraph to the Security 
Considerations that warns implementors that a wider has MAY be specified 
when stronger (symmetric algorithms with longer key sizes) are supported 
(e.g., AES)?

>- As far as I know, the most relevant patent is 5,933,504.

Please add a Intellectual Property Rights section to the document.  Please 
take a look a section 9 of RFC 2459 for an example.  Also, take a look at 
the references made in the discussion of the RSA algorithm (the patent had 
not expired when RFC 2459 was published).  This provides a simple "heads up."

>authenticated-data, and therefore inside the encrypted content.

Thanks.  I look forward to the updated security considerations.

>To be as clear as possible, we propose to replace the quoted text with a 

Fine.  Please reference a particular section in RFC 2630.

Russ