RE: I-D ACTION:draft-ietf-smime-rcek-01.txt

Mike Just <mike.just@entrust.com> Tue, 13 February 2001 23:49 UTC

Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA02808 for <smime-archive@odin.ietf.org>; Tue, 13 Feb 2001 18:49:01 -0500 (EST)
Received: (from majordomo@localhost) by above.proper.com (8.9.3/8.9.3) id OAA08925 for ietf-smime-bks; Tue, 13 Feb 2001 14:45:51 -0800 (PST)
Received: from sottmxs02.entrust.com (gatekeeper.entrust.com [204.101.128.170]) by above.proper.com (8.9.3/8.9.3) with ESMTP id OAA08919 for <ietf-smime@imc.org>; Tue, 13 Feb 2001 14:45:50 -0800 (PST)
Received: by sottmxs02.entrust.com with Internet Mail Service (5.5.2650.21) id <1RVQGWYX>; Tue, 13 Feb 2001 17:45:22 -0500
Message-ID: <C69F91F7FDEEC74F8BF6BF9861B2F61303441A@sottmxs07>
From: Mike Just <mike.just@entrust.com>
To: ietf-smime@imc.org
Cc: "'stephen.farrell@baltimore.ie'" <stephen.farrell@baltimore.ie>, "'turners@ieca.com'" <turners@ieca.com>
Subject: RE: I-D ACTION:draft-ietf-smime-rcek-01.txt
Date: Tue, 13 Feb 2001 17:45:19 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0960E.A462A290"
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>

Hi Stephen, Sean,

Possibly another item worth including in the Security Considerations
section. Suppose MSG1 is sent to a set S1 of users. In the case where MSG2
is sent to only a subset of users in S1, all users from S1 will still be
able to decrypt MSG2 (since MSG2.KEK is computed only from MSG1.CEK).  I
don't think you intended for your solution to be used for such dynamic
recipient sets, but it might be worth explicitly mentioning this unfortunate
side-effect of key re-use in any case. (Might be enough to mention that the
recipient lists must be the same for each message.)

Mike J.  

> -----Original Message-----
> From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org]
> Sent: Friday, February 09, 2001 7:27 AM
> Cc: ietf-smime@imc.org
> Subject: I-D ACTION:draft-ietf-smime-rcek-01.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.
> 
> 	Title		: Reuse of CMS Content Encryption Keys
> 	Author(s)	: S. Farrell, S. Turner
> 	Filename	: draft-ietf-smime-rcek-01.txt
> 	Pages		: 7
> 	Date		: 08-Feb-01
> 	
> This note describes a way to include a key identifier in a CMS
> enveloped data structure, so that the content encryption key can be
> re-used for further enveloped data packets.
> 
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-ietf-smime-rcek-01.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-rcek-01.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:
> 	mailserv@ietf.org.
> In the body type:
> 	"FILE /internet-drafts/draft-ietf-smime-rcek-01.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.
>