RE: WG Last Call Extended: draft-ietf-smime-rcek-02.txt

"Jim Schaad" <jimsch5@home.com> Wed, 02 May 2001 01:34 UTC

Received: from above.proper.com ([208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA14318 for <smime-archive@odin.ietf.org>; Tue, 1 May 2001 21:34:35 -0400 (EDT)
Received: by above.proper.com (8.9.3/8.9.3) id RAA19204 for ietf-smime-bks; Tue, 1 May 2001 17:48:51 -0700 (PDT)
Received: from femail3.sdc1.sfba.home.com (femail3.sdc1.sfba.home.com [24.0.95.83]) by above.proper.com (8.9.3/8.9.3) with ESMTP id RAA19199 for <ietf-smime@imc.org>; Tue, 1 May 2001 17:48:44 -0700 (PDT)
Received: from revelation ([65.4.166.11]) by femail3.sdc1.sfba.home.com (InterMail vM.4.01.03.20 201-229-121-120-20010223) with SMTP id <20010502004601.XJIP26961.femail3.sdc1.sfba.home.com@revelation> for <ietf-smime@imc.org>; Tue, 1 May 2001 17:46:01 -0700
Reply-To: jimsch@exmsft.com
From: Jim Schaad <jimsch5@home.com>
To: ietf-smime@imc.org
Subject: RE: WG Last Call Extended: draft-ietf-smime-rcek-02.txt
Date: Tue, 01 May 2001 17:51:40 -0700
Message-ID: <001f01c0d2a2$0d735110$0e00a8c0@soaringhawk.net>
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0)
In-Reply-To: <5.0.1.4.2.20010501094656.01c28d58@exna07.securitydynamics.com>
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Sender: owner-ietf-smime@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:ietf-smime-request@imc.org?body=unsubscribe>
Content-Transfer-Encoding: 7bit

I have the following comments:

1.  Section 4, para 6:  The following paragraph does not make complete sense
to me.

   keyAlg is the algorithm identifier (and associated parameters, if
   any), for the MSG2 key encryption algorithm. Note that it is not
   necessary to protect this field MSG.KEK is only used by the
   originator.

   I think what this is suppose to imply is that if the field is modified it
is a denial of service attack but nothing more (i.e. the originator and
receiver will use different algorithms to derive the KEK from the CEK and
the decrypt will fail).  If the field is only used by the originator, why
send it at all.

2.  Appendix A:  PBKDF2-params needs to have the comma removed following the
last field.

jim


> -----Original Message-----
> From: owner-ietf-smime@mail.imc.org
> [mailto:owner-ietf-smime@mail.imc.org]On Behalf Of Housley, Russ
> Sent: Tuesday, May 01, 2001 6:49 AM
> To: ietf-smime@imc.org
> Subject: WG Last Call Extended: draft-ietf-smime-rcek-02.txt
>
>
> Steve Farrell has updated the RCEK document to address the
> comments raised
> during WG Last Call.  To give everyone a chance to review the
> updates, I am
> extending the WG Last Call until 7 May 2001.  Please post any
> remaining
> issues to the S/MIME WG mail list.
>
> 	Title		: Reuse of CMS Content Encryption Keys
> 	Author(s)	: S. Farrell, S. Turner
> 	Filename	: draft-ietf-smime-rcek-02.txt
> 	Pages		: 9
> 	Date		: 30-Apr-01
>
> Russ
>