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 >
- WG Last Call Extended: draft-ietf-smime-rcek-02.t… Housley, Russ
- RE: WG Last Call Extended: draft-ietf-smime-rcek-… Jim Schaad