From owner-ietf-smime@mail.imc.org  Sat Sep  2 17:50:46 2000
Received: from ns.secondary.com (ns.secondary.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA16581
	for <smime-archive@odin.ietf.org>; Sat, 2 Sep 2000 17:50:45 -0400 (EDT)
Received: by ns.secondary.com (8.9.3/8.9.3) id OAA08987
	for ietf-smime-bks; Sat, 2 Sep 2000 14:01:16 -0700 (PDT)
Received: from cane.deming.com (mail.deming.com [208.236.41.137])
	by ns.secondary.com (8.9.3/8.9.3) with SMTP id OAA08983
	for <ietf-smime@imc.org>; Sat, 2 Sep 2000 14:01:15 -0700 (PDT)
Received: from 208.236.41.137 by cane.deming.com with ESMTP (Tumbleweed
 MMS SMTP Relay (MMS v4.6)); Sat, 02 Sep 2000 14:02:00 -0700
X-Server-Uuid: 1a012586-24e9-11d1-adae-00a024bc53c5
Received: by mail.deming.com with Internet Mail Service (5.5.2650.21) id
 <Q2XXPBG2>; Sat, 2 Sep 2000 14:02:00 -0700
Message-ID: <01FF24001403D011AD7B00A024BC53C5A770E7@mail.deming.com>
From: "Blake Ramsdell" <blake.ramsdell@tumbleweed.com>
To: "'ietf-smime@imc.org'" <ietf-smime@imc.org>
Subject: Mandatory to implement key wrap algorithm for S/MIME summary
Date: Sat, 2 Sep 2000 14:01:56 -0700
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
X-WSS-ID: 15AFB54280456-01-01
Content-Type: text/plain; 
 charset=iso-8859-1
Content-Transfer-Encoding: 7bit
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

It appears that we have reached at least preliminary consensus for the
mandatory to implement algorithms for S/MIME.  Note that these mandatory to
implement algorithms are not for CMS in general, but for the S/MIME profile
of CMS.

1. The mandatory to implement algorithms should change in light of the
patent expiration for RSA.

2. The use of RSA as the mandatory to implement key wrapping algorithm is
acceptable, and the mode of operation will be PKCS #1 v1.5, not OAEP.  This
seems to reflect the reasoned discussions of at least ten working group
participants.  This will include adding a security consideration note that
explains the attack and points to a descriptive reference.

3. The use of Diffie-Hellman will only be included for backward
compatibility, and thus can be a SHOULD implement.

If we are going to use the PKCS #1 v1.5 implementation of RSA key wrapping,
then we should document the concerns about its use, and potentially point to
an RFC or other document that has a full explanation (as Paul pointed out
earlier).

Based on this list, I believe that enough information exists to move
draft-ramsdell-smime31-msg and draft-ramsdell-smime31-cert into the working
group, and start finishing this up.

Blake



From owner-ietf-smime@mail.imc.org  Sat Sep  2 18:59:36 2000
Received: from ns.secondary.com (ns.secondary.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA17144
	for <smime-archive@odin.ietf.org>; Sat, 2 Sep 2000 18:59:36 -0400 (EDT)
Received: by ns.secondary.com (8.9.3/8.9.3) id OAA09031
	for ietf-smime-bks; Sat, 2 Sep 2000 14:04:31 -0700 (PDT)
Received: from cane.deming.com (mail.deming.com [208.236.41.137])
	by ns.secondary.com (8.9.3/8.9.3) with SMTP id OAA09024
	for <ietf-smime@imc.org>; Sat, 2 Sep 2000 14:04:29 -0700 (PDT)
Received: from 208.236.41.137 by cane.deming.com with ESMTP (Tumbleweed
 MMS SMTP Relay (MMS v4.6)); Sat, 02 Sep 2000 14:05:17 -0700
X-Server-Uuid: 1a012586-24e9-11d1-adae-00a024bc53c5
Received: by mail.deming.com with Internet Mail Service (5.5.2650.21) id
 <Q2XXPBGJ>; Sat, 2 Sep 2000 14:05:16 -0700
Message-ID: <01FF24001403D011AD7B00A024BC53C5A770E8@mail.deming.com>
From: "Blake Ramsdell" <blake.ramsdell@tumbleweed.com>
To: "'ietf-smime@imc.org'" <ietf-smime@imc.org>
Subject: RE: Mandatory to implement key wrap algorithm for S/MIME
 summary
Date: Sat, 2 Sep 2000 14:05:16 -0700
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
X-WSS-ID: 15AFB40780466-01-01
Content-Type: text/plain; 
 charset=iso-8859-1
Content-Transfer-Encoding: 7bit
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

One more thing -- it may be important to do some kind of revision to the
working group charter if we would like to finish this up.  Based on the
level of interest both on the mailing list and at the meeting in Pittsburgh,
it seems like a no-brainer and that people are interested in pursuing this
in the working group, and the charter should be amended.

Blake

>  -----Original Message-----
> From: 	Blake Ramsdell  
> Sent:	Saturday, September 02, 2000 2:02 PM
> To:	'ietf-smime@imc.org'
> Subject:	Mandatory to implement key wrap algorithm for S/MIME summary
> 
> It appears that we have reached at least preliminary consensus for the
> mandatory to implement algorithms for S/MIME.  Note that these mandatory
> to implement algorithms are not for CMS in general, but for the S/MIME
> profile of CMS.
> 
> 1. The mandatory to implement algorithms should change in light of the
> patent expiration for RSA.
> 
> 2. The use of RSA as the mandatory to implement key wrapping algorithm is
> acceptable, and the mode of operation will be PKCS #1 v1.5, not OAEP.
> This seems to reflect the reasoned discussions of at least ten working
> group participants.  This will include adding a security consideration
> note that explains the attack and points to a descriptive reference.
> 
> 3. The use of Diffie-Hellman will only be included for backward
> compatibility, and thus can be a SHOULD implement.
> 
> If we are going to use the PKCS #1 v1.5 implementation of RSA key
> wrapping, then we should document the concerns about its use, and
> potentially point to an RFC or other document that has a full explanation
> (as Paul pointed out earlier).
> 
> Based on this list, I believe that enough information exists to move
> draft-ramsdell-smime31-msg and draft-ramsdell-smime31-cert into the
> working group, and start finishing this up.
> 
> Blake



From owner-ietf-smime@mail.imc.org  Tue Sep  5 07:18:16 2000
Received: from ns.secondary.com (ns.secondary.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA28091
	for <smime-archive@odin.ietf.org>; Tue, 5 Sep 2000 07:18:16 -0400 (EDT)
Received: by ns.secondary.com (8.9.3/8.9.3) id DAA04126
	for ietf-smime-bks; Tue, 5 Sep 2000 03:44:25 -0700 (PDT)
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by ns.secondary.com (8.9.3/8.9.3) with ESMTP id DAA04122
	for <ietf-smime@imc.org>; Tue, 5 Sep 2000 03:44:24 -0700 (PDT)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA27370;
	Tue, 5 Sep 2000 06:45:54 -0400 (EDT)
Message-Id: <200009051045.GAA27370@ietf.org>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: ietf-smime@imc.org
From: Internet-Drafts@ietf.org
Reply-to: Internet-Drafts@ietf.org
Subject: I-D ACTION:draft-ietf-smime-idea-07.txt
Date: Tue, 05 Sep 2000 06:45:54 -0400
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>

--NextPart

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 the IDEA Encryption Algorithm in CMS
	Author(s)	: S. Teiwes, P. Hartmann, D. Kuenzi
	Filename	: draft-ietf-smime-idea-07.txt
	Pages		: 6
	Date		: 01-Sep-00
	
This memo specifies how to incorporate IDEA (International Data
Encryption Algorithm) [IDEA] into S/MIME [SMIME2, SMIME3] as 
an additional strong algorithm for symmetric encryption. For 
organizations who make use of IDEA for data security purposes 
it is of high interest that IDEA is also available in S/MIME. 
The intention of this memo is to provide the OIDs and algorithms 
required that IDEA can be included in S/MIME for symmetric content
and key encryption.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-smime-idea-07.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-idea-07.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-idea-07.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.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="mailserv@ietf.org"

Content-Type: text/plain
Content-ID:	<20000901143530.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-ietf-smime-idea-07.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-smime-idea-07.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<20000901143530.I-D@ietf.org>

--OtherAccess--

--NextPart--




From owner-ietf-smime@mail.imc.org  Tue Sep  5 13:23:33 2000
Received: from ns.secondary.com (ns.secondary.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA09306
	for <smime-archive@odin.ietf.org>; Tue, 5 Sep 2000 13:23:32 -0400 (EDT)
Received: by ns.secondary.com (8.9.3/8.9.3) id JAA02051
	for ietf-smime-bks; Tue, 5 Sep 2000 09:41:21 -0700 (PDT)
Received: from wfhqex05.gfgsi.com (netva01.wangfed.com [206.137.100.2])
	by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA02047
	for <ietf-smime@imc.org>; Tue, 5 Sep 2000 09:41:20 -0700 (PDT)
Received: by wfhqex05.gfgsi.com with Internet Mail Service (5.5.2650.21)
	id <RLYR6MP7>; Tue, 5 Sep 2000 12:42:45 -0400
Message-ID: <4B0D36365AD3D2118FF40060972A16C0016D03F8@wfhqex01.wangfed.com>
From: "Pawling, John" <John.Pawling@wang.com>
To: "'ietf-smime@imc.org'" <ietf-smime@imc.org>
Subject: RE: Mandatory to implement key wrap algorithm for S/MIME summary
Date: Tue, 5 Sep 2000 12:42:19 -0400 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-1"
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>

All,

Blake stated: "Note that these mandatory to implement algorithms are not for
CMS in general, but for the S/MIME profile of CMS."  I have the following
comments:  

RFC 2630 (CMS), section 12.3.1, states: "CMS implementations must include
key agreement using X9.42 Ephemeral-Static Diffie-Hellman."  To be
consistent with the working group's consensus, I believe that this text
needs to be changed to: "CMS implementations should include key agreement
using X9.42 Ephemeral-Static Diffie-Hellman."   

RFC 2630, section 12.3.2, states: "CMS implementations should include key
transport using RSA." To be consistent with the working group's consensus, I
believe that this text needs to be changed to: "CMS implementations must
include key transport using RSA."   

RFC 2630, section 12.2, states: "CMS implementations must include DSA.  CMS
implementations may include RSA."  To be consistent with the working group's
consensus, I believe that this text needs to be changed to: "CMS
implementations must include both DSA and RSA." 

============================================
John Pawling, john.pawling@wang.com
Wang Government Services, Inc.,
A Getronics Company
============================================ 



From owner-ietf-smime@mail.imc.org  Tue Sep  5 17:47:03 2000
Received: from ns.secondary.com (ns.secondary.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA14464
	for <smime-archive@odin.ietf.org>; Tue, 5 Sep 2000 17:47:02 -0400 (EDT)
Received: by ns.secondary.com (8.9.3/8.9.3) id OAA11047
	for ietf-smime-bks; Tue, 5 Sep 2000 14:17:13 -0700 (PDT)
Received: from roadblock.missi.ncsc.mil (roadblock.missi.ncsc.mil [144.51.50.70])
	by ns.secondary.com (8.9.3/8.9.3) with ESMTP id OAA11043
	for <ietf-smime@imc.org>; Tue, 5 Sep 2000 14:17:12 -0700 (PDT)
Received: from roadblock.missi.ncsc.mil (root@localhost)
	by roadblock.missi.ncsc.mil with ESMTP id RAA01131
	for <ietf-smime@imc.org>; Tue, 5 Sep 2000 17:01:44 -0400 (EDT)
Message-Id: <200009052101.RAA01127@roadblock.missi.ncsc.mil>
Date: Tue, 5 Sep 2000 17:13:17 -0400 (EDT)
From: "David P. Kemp" <dpkemp@missi.ncsc.mil>
Reply-To: "David P. Kemp" <dpkemp@missi.ncsc.mil>
Subject: RE: Mandatory to implement key wrap algorithm for S/MIME summary
To: ietf-smime@imc.org
MIME-Version: 1.0
Content-Type: TEXT/plain; charset=us-ascii
Content-MD5: BRIsUomwU8pgvP+CMlvzCw==
X-Mailer: dtmail 1.3.0 CDE Version 1.3 SunOS 5.7 sun4u sparc 
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>

John,

I agree with Blake's implication that CMS "should not" (little letters)
contain algorithm requirements; conformance should be controlled
exclusively by specifications which reference CMS.  This enables CMS to
remain stable as opinions concerning algorithms change.  Where would we
be if X.509 said every certificate-using application MUST support
id-sa-sqMod-nWithRSA signatures?

I believe the statements quoted below should be removed without replacement
in the next version of CMS.

Dave



> From: "Pawling, John" <John.Pawling@wang.com>
> To: "'ietf-smime@imc.org'" <ietf-smime@imc.org>
> Subject: RE: Mandatory to implement key wrap algorithm for S/MIME summary
> Date: Tue, 5 Sep 2000 12:42:19 -0400 
> 
> All,
> 
> Blake stated: "Note that these mandatory to implement algorithms are not for
> CMS in general, but for the S/MIME profile of CMS."  I have the following
> comments:  
> 
> RFC 2630 (CMS), section 12.3.1, states: "CMS implementations must include
> key agreement using X9.42 Ephemeral-Static Diffie-Hellman."  To be
> consistent with the working group's consensus, I believe that this text
> needs to be changed to: "CMS implementations should include key agreement
> using X9.42 Ephemeral-Static Diffie-Hellman."   
> 
> RFC 2630, section 12.3.2, states: "CMS implementations should include key
> transport using RSA." To be consistent with the working group's consensus, I
> believe that this text needs to be changed to: "CMS implementations must
> include key transport using RSA."   
> 
> RFC 2630, section 12.2, states: "CMS implementations must include DSA.  CMS
> implementations may include RSA."  To be consistent with the working group's
> consensus, I believe that this text needs to be changed to: "CMS
> implementations must include both DSA and RSA." 
> 
> ============================================
> John Pawling, john.pawling@wang.com
> Wang Government Services, Inc.,
> A Getronics Company
> ============================================ 



From owner-ietf-smime@mail.imc.org  Wed Sep  6 07:48:33 2000
Received: from ns.secondary.com (ns.secondary.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA08679
	for <smime-archive@odin.ietf.org>; Wed, 6 Sep 2000 07:48:32 -0400 (EDT)
Received: by ns.secondary.com (8.9.3/8.9.3) id DAA21198
	for ietf-smime-bks; Wed, 6 Sep 2000 03:43:39 -0700 (PDT)
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by ns.secondary.com (8.9.3/8.9.3) with ESMTP id DAA21193
	for <ietf-smime@imc.org>; Wed, 6 Sep 2000 03:43:38 -0700 (PDT)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA07021;
	Wed, 6 Sep 2000 06:45:13 -0400 (EDT)
Message-Id: <200009061045.GAA07021@ietf.org>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: ietf-smime@imc.org
From: Internet-Drafts@ietf.org
Reply-to: Internet-Drafts@ietf.org
Subject: I-D ACTION:draft-ietf-smime-rcek-00.txt
Date: Wed, 06 Sep 2000 06:45:13 -0400
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>

--NextPart

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-00.txt
	Pages		: 7
	Date		: 05-Sep-00
	
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-00.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-00.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-00.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.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="mailserv@ietf.org"

Content-Type: text/plain
Content-ID:	<20000905150122.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-ietf-smime-rcek-00.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-smime-rcek-00.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<20000905150122.I-D@ietf.org>

--OtherAccess--

--NextPart--




From owner-ietf-smime@mail.imc.org  Wed Sep  6 12:32:17 2000
Received: from ns.secondary.com (ns.secondary.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA16942
	for <smime-archive@odin.ietf.org>; Wed, 6 Sep 2000 12:32:16 -0400 (EDT)
Received: (from majordomo@localhost)
	by ns.secondary.com (8.9.3/8.9.3) id JAA13367
	for ietf-smime-bks; Wed, 6 Sep 2000 09:00:01 -0700 (PDT)
Received: from wfhqex05.gfgsi.com (netva01.wangfed.com [206.137.100.2])
	by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA13360
	for <ietf-smime@imc.org>; Wed, 6 Sep 2000 09:00:00 -0700 (PDT)
Received: by wfhqex05.gfgsi.com with Internet Mail Service (5.5.2650.21)
	id <RLYR6R9F>; Wed, 6 Sep 2000 12:02:21 -0400
Message-ID: <4B0D36365AD3D2118FF40060972A16C0016D040B@wfhqex01.wangfed.com>
From: "Pawling, John" <John.Pawling@wang.com>
To: ietf-smime@imc.org
Subject: RE: Mandatory to implement key wrap algorithm for S/MIME summary
Date: Wed, 6 Sep 2000 12:01:06 -0400 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-1"
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>

All,

Since RFC 2630 (CMS) will be used as the standard security protocol for
several communication protocols that may have different (and changing) sets
of algorithm implementation requirements, I agree with Dave Kemp's
recommendation to change the text in RFC 2630 stating the algorithm
implementation requirements.  I believe that it is appropriate for RFC 2630
(or an appendix to RFC 2630) to define how algorithms are used with the CMS
security protocol, but should not specify algorithm implementation
requirements.  For each communication protocol, a separate profile should be
developed specifying the algorithm implementation requirements for using RFC
2630 with that communication protocol.  For example, the S/MIME v3 algorithm
implementation requirements should be stated in the revised S/MIME v3
Message Specification (as proposed by Blake).  

Recommend the following changes to RFC 2630:

1) Section 12.1: 

OLD: "CMS implementations must include SHA-1.  CMS implementations should
include MD5."  

NEW: "This section describes how the SHA-1 and MD5 digest algorithms are
used with CMS."


2) Section 12.2:

OLD: "CMS implementations must include DSA.  CMS implementations may include
RSA." 

NEW: "This section describes how the DSA and RSA signature algorithms are
used with CMS."   


3) Section 12.3.1: 

OLD: "CMS implementations must include key agreement using X9.42
Ephemeral-Static Diffie-Hellman."  

NEW: "This section describes how key agreement is implemented in CMS using
the X9.42 Ephemeral-Static Diffie-Hellman algorithm."    


4) Section 12.3.1:

OLD: "CMS implementations must include key agreement of Triple-DES pairwise
key-encryption keys and Triple-DES wrapping of Triple-DES content-encryption
keys.  CMS implementations should include key agreement of RC2 pairwise
key-encryption keys and RC2 wrapping of RC2 content-encryption keys.  The
key wrap algorithm for Triple-DES and RC2 is described in section 12.3.3."

NEW: "Section 12.3.3.1 specifies the key wrap algorithm for use with CMS for
key agreement of Triple-DES pairwise key-encryption keys and Triple-DES
wrapping of Triple-DES content-encryption keys.  Section 12.3.3.2 specifies
the key wrap algorithm for use with CMS for key agreement of RC2 pairwise
key-encryption keys and RC2 wrapping of RC2 content-encryption keys."


5) Section 12.3.2: 

OLD: "CMS implementations should include key transport using RSA.  RSA
implementations must include key transport of Triple-DES content-encryption
keys.  RSA implementations should include key transport of RC2
content-encryption keys."

NEW: "This section describes how key transport is implemented in CMS using
RSA in conjunction with Triple-DES and RC2 content-encryption keys."  


6) Section 12.4:

OLD: "CMS implementations must include Triple-DES in CBC mode.  CMS
implementations should include RC2 in CBC mode."

NEW: "This section describes how the Triple-DES (in CBC mode) and RC2 (in
CBC mode) content encryption algorithms are used with CMS."


7) Section 12.6: 

OLD: "CMS implementations must include encryption of a Triple-DES
content-encryption key with a Triple-DES key-encryption key using the
algorithm specified in Sections 12.6.2 and 12.6.3.  CMS implementations
should include encryption of a RC2 content-encryption key with a RC2
key-encryption key using the algorithm specified in Sections 12.6.4 and
12.6.5."  

NEW: "Sections 12.6.2 and 12.6.3 specify the algorithm for use with CMS to
encrypt a Triple-DES content-encryption key with a Triple-DES key-encryption
key.  Sections 12.6.4 and 12.6.5 specify the algorithm for use with CMS to
encrypt a RC2 content-encryption key with a RC2 key-encryption key."  


8) Section 12, intro: 

OLD: "This section lists the algorithms that must be implemented.
Additional algorithms that should be implemented are also included."

NEW: "This section describes how selected algorithms are used with CMS."


Recommend that the revised S/MIME v3 Message Specification should state the
S/MIME working group's consensus regarding each of the aforementioned
algorithm implementation requirements.  

============================================
John Pawling, john.pawling@wang.com
Wang Government Services, Inc.,
A Getronics Company
============================================ 


From owner-ietf-smime@mail.imc.org  Mon Sep 11 02:32:56 2000
Received: from ns.secondary.com (ns.secondary.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA27144
	for <smime-archive@odin.ietf.org>; Mon, 11 Sep 2000 02:32:55 -0400 (EDT)
Received: by ns.secondary.com (8.9.3/8.9.3) id WAA00513
	for ietf-smime-bks; Sun, 10 Sep 2000 22:50:00 -0700 (PDT)
Received: from cc.sookmyung.ac.kr (cc.sookmyung.ac.kr [203.252.201.4])
	by ns.secondary.com (8.9.3/8.9.3) with ESMTP id WAA00506
	for <ietf-smime@imc.org>; Sun, 10 Sep 2000 22:49:57 -0700 (PDT)
Received: from sookmyung.ac.kr (pc_rhee.sookmyung.ac.kr [203.252.195.65])
	by cc.sookmyung.ac.kr (8.9.3/8.9.3) with ESMTP id OAA24015
	for <ietf-smime@imc.org>; Mon, 11 Sep 2000 14:50:25 +0900 (KST)
Message-ID: <39BC72AC.C25D3B7@sookmyung.ac.kr>
Date: Mon, 11 Sep 2000 14:50:36 +0900
From: Gwangsoo Rhee <rhee@sookmyung.ac.kr>
X-Mailer: Mozilla 4.72 [en] (Win98; U)
X-Accept-Language: en
MIME-Version: 1.0
To: "ietf-smime@imc.org" <ietf-smime@imc.org>
Subject: Question on basicConstraints from RFC 2632
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
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

The material below is from RFC 2632.
Seems to me that the statements about end-entity certificates
in the last two paragraphs conflict with each other.
One says that end-entity certificates contain a basicConstraints
extension
and another says they shouldn't.
Maybe I misunderstood those statements.
Could anyone please enlighten me on the subject?

Many thanks.

++++++++++++++++++++++++++++++++++++++++++++++

4.4.1 Basic Constraints Certificate Extension

   The basic constraints extension serves to delimit the role and
   position of an issuing authority or end-entity certificate plays in a

   chain of certificates.

   For example, certificates issued to CAs and subordinate CAs contain a

   basic constraint extension that identifies them as issuing authority
   certificates. End-entity certificates contain an extension that
   constrains the certificate from being an issuing authority
   certificate.

   Certificates SHOULD contain a basicConstraints extension in CA
   certificates, and SHOULD NOT contain that extension in end entity
   certificates.

--

---------------------------------------
Gwangsoo Rhee <rhee@sookmyung.ac.kr>
Sookmyung University, Korea
tel: +82-2-710-9429  fax: 710-9296
---------------------------------------




From owner-ietf-smime@mail.imc.org  Mon Sep 11 05:17:03 2000
Received: from ns.secondary.com (ns.secondary.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA27915
	for <smime-archive@odin.ietf.org>; Mon, 11 Sep 2000 05:17:03 -0400 (EDT)
Received: by ns.secondary.com (8.9.3/8.9.3) id BAA03785
	for ietf-smime-bks; Mon, 11 Sep 2000 01:43:56 -0700 (PDT)
Received: from exchsvr1.entegrity.com (exchsvr1.entegrity.com [207.215.19.3])
	by ns.secondary.com (8.9.3/8.9.3) with ESMTP id BAA03781
	for <ietf-smime@imc.org>; Mon, 11 Sep 2000 01:43:55 -0700 (PDT)
Received: from dharter (213-123-77-70.btconnect.com [213.123.77.70]) by exchsvr1.entegrity.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21)
	id RQJ8JRX5; Mon, 11 Sep 2000 01:39:15 -0700
From: "Darren Harter" <darren.harter@entegrity.com>
To: "'Gwangsoo Rhee'" <rhee@sookmyung.ac.kr>, <ietf-smime@imc.org>
Subject: RE: Question on basicConstraints from RFC 2632
Date: Mon, 11 Sep 2000 09:43:42 +0100
Message-ID: <000601c01bcc$63f87700$0100a8c0@entegrity.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0
In-Reply-To: <39BC72AC.C25D3B7@sookmyung.ac.kr>
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Importance: Normal
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

Gwangsoo Rhee,

The last paragraph states that an end-entity certificate SHOULD NOT contain
a basic contraints extension, it doesn't say that it MUST NOT contain one.
As a consequence, an end-entity certificate MAY contain a basic contraints
extension, and it if it does the semantic meaning of that extension is as
described in the first paragraph.

This is a typical example of the standard providing a discretionary
recommendation rather than a mandatory instruction.  In this case it is
quite right and proper, and aids interoperability.  It follows the usual aim
of IETF standards in being precise in what you send, but flexible in what
you receive.

Hope this helps,

Darren
---------------------------------------------------------------------
Darren Harter B.Sc. (Hons) MBCS CEng
European Professional Services Group,
Entegrity Solutions Corp.


-----Original Message-----
From: owner-ietf-smime@mail.imc.org
[mailto:owner-ietf-smime@mail.imc.org]On Behalf Of Gwangsoo Rhee
Sent: 11 September 2000 06:51
To: ietf-smime@imc.org
Subject: Question on basicConstraints from RFC 2632


The material below is from RFC 2632.
Seems to me that the statements about end-entity certificates
in the last two paragraphs conflict with each other.
One says that end-entity certificates contain a basicConstraints
extension
and another says they shouldn't.
Maybe I misunderstood those statements.
Could anyone please enlighten me on the subject?

Many thanks.

++++++++++++++++++++++++++++++++++++++++++++++

4.4.1 Basic Constraints Certificate Extension

   The basic constraints extension serves to delimit the role and
   position of an issuing authority or end-entity certificate plays in a

   chain of certificates.

   For example, certificates issued to CAs and subordinate CAs contain a

   basic constraint extension that identifies them as issuing authority
   certificates. End-entity certificates contain an extension that
   constrains the certificate from being an issuing authority
   certificate.

   Certificates SHOULD contain a basicConstraints extension in CA
   certificates, and SHOULD NOT contain that extension in end entity
   certificates.

--

---------------------------------------
Gwangsoo Rhee <rhee@sookmyung.ac.kr>
Sookmyung University, Korea
tel: +82-2-710-9429  fax: 710-9296
---------------------------------------



From owner-ietf-smime@mail.imc.org  Mon Sep 11 11:46:42 2000
Received: from ns.secondary.com (ns.secondary.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA05281
	for <smime-archive@odin.ietf.org>; Mon, 11 Sep 2000 11:46:42 -0400 (EDT)
Received: (from majordomo@localhost)
	by ns.secondary.com (8.9.3/8.9.3) id IAA12351
	for ietf-smime-bks; Mon, 11 Sep 2000 08:12:58 -0700 (PDT)
Received: from roadblock.missi.ncsc.mil ([144.51.50.70])
	by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA12343
	for <ietf-smime@imc.org>; Mon, 11 Sep 2000 08:12:57 -0700 (PDT)
Received: from roadblock.missi.ncsc.mil (root@localhost)
	by roadblock.missi.ncsc.mil with ESMTP id KAA04364
	for <ietf-smime@imc.org>; Mon, 11 Sep 2000 10:59:32 -0400 (EDT)
Message-Id: <200009111459.KAA04359@roadblock.missi.ncsc.mil>
Date: Mon, 11 Sep 2000 11:09:18 -0400 (EDT)
From: "David P. Kemp" <dpkemp@missi.ncsc.mil>
Reply-To: "David P. Kemp" <dpkemp@missi.ncsc.mil>
Subject: RE: Question on basicConstraints from RFC 2632
To: ietf-smime@imc.org
MIME-Version: 1.0
Content-Type: TEXT/plain; charset=us-ascii
Content-MD5: G5soqN9sTU+hHqxr3yUyVA==
X-Mailer: dtmail 1.3.0 CDE Version 1.3 SunOS 5.7 sun4u sparc 
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>

I believe a paragraph where one sentence says "does contain" and
the following sentence says "SHOULD NOT contain" the same information
would be contradictory and confusing.

However, a (very) careful reading of RFC 2632's "End-entity certificates
contain an extension that constrains the certificate from being an
issuing authority certificate." reveals that the extension in question
need not be basicConstraints.

RFC 2459 (the PKIX profile) says that BasicConstraints MUST appear in
CA certs and SHOULD NOT appear in end entity certs.  It also says that
the Key Usage extension, when used, SHOULD be marked critical.
Since nearly every end-entity cert will have a key usage extension
anyway and since that extension will preclude the EE cert from being an
issuing authority cert (if CA usage bit is not set), including
basicConstraints in EE certificates which also contain keyUsage is
superfluous.

In a typical example of a standard catering to every possible
viewpoint, son-of-RFC 2459 now says basicConstraints MAY appear, either
critical or non-critical, in end entity certificates.  I view this as
a step away from clarity; SHOULD NOT provides guidance without
prohibiting alternatives.

If son-of-RFC 2632 is going to contain MAY/SHOULD/MUST statements
concerning certificate extensions, I recommend aligning the CA
certificate requirement with PKIX and adding a clarifying sentence at
the end of section 4.4.1:

    Certificates SHOULD contain a basicConstraints extension in
    CA certificates, and SHOULD NOT contain that extension in end
    entity certificates.  End entity certificates SHOULD contain a
    key usage extension.


Section 4.4.2 could use a complete rewrite - it currently says nothing
about including keyUsage in EE certs, and also says nothing about
distinguishing between signature and encryption certificates.  It
delves deep into the details of encrypt/decrypt-only, which seems
especially bizarre given the absence of even a cursory discussion of
digitalSignature, keyEncipherment, and keyAgreement.  I'll provide some
suggested text for 4.4.2 later.

Dave




> From: "Darren Harter" <darren.harter@entegrity.com>
> 
> Gwangsoo Rhee,
> 
> The last paragraph states that an end-entity certificate SHOULD NOT contain
> a basic contraints extension, it doesn't say that it MUST NOT contain one.
> As a consequence, an end-entity certificate MAY contain a basic contraints
> extension, and it if it does the semantic meaning of that extension is as
> described in the first paragraph.
> 
> This is a typical example of the standard providing a discretionary
> recommendation rather than a mandatory instruction.  In this case it is
> quite right and proper, and aids interoperability.  It follows the usual aim
> of IETF standards in being precise in what you send, but flexible in what
> you receive.
> 
> Hope this helps,
> 
> Darren
> ---------------------------------------------------------------------
> Darren Harter B.Sc. (Hons) MBCS CEng
> European Professional Services Group,
> Entegrity Solutions Corp.
> 
> 
> -----Original Message-----
> From: owner-ietf-smime@mail.imc.org
> [mailto:owner-ietf-smime@mail.imc.org]On Behalf Of Gwangsoo Rhee
> Sent: 11 September 2000 06:51
> To: ietf-smime@imc.org
> Subject: Question on basicConstraints from RFC 2632
> 
> 
> The material below is from RFC 2632.
> Seems to me that the statements about end-entity certificates
> in the last two paragraphs conflict with each other.
> One says that end-entity certificates contain a basicConstraints
> extension
> and another says they shouldn't.
> Maybe I misunderstood those statements.
> Could anyone please enlighten me on the subject?
> 
> Many thanks.
> 
> ++++++++++++++++++++++++++++++++++++++++++++++
> 
> 4.4.1 Basic Constraints Certificate Extension
> 
>    The basic constraints extension serves to delimit the role and
>    position of an issuing authority or end-entity certificate plays in a
>    chain of certificates.
> 
>    For example, certificates issued to CAs and subordinate CAs contain a
>    basic constraint extension that identifies them as issuing authority
>    certificates. End-entity certificates contain an extension that
>    constrains the certificate from being an issuing authority
>    certificate.
> 
>    Certificates SHOULD contain a basicConstraints extension in CA
>    certificates, and SHOULD NOT contain that extension in end entity
>    certificates.
> 
> --




From owner-ietf-smime@mail.imc.org  Tue Sep 12 07:28:00 2000
Received: from ns.secondary.com (ns.secondary.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA29813
	for <smime-archive@odin.ietf.org>; Tue, 12 Sep 2000 07:28:00 -0400 (EDT)
Received: by ns.secondary.com (8.9.3/8.9.3) id DAA12809
	for ietf-smime-bks; Tue, 12 Sep 2000 03:49:07 -0700 (PDT)
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by ns.secondary.com (8.9.3/8.9.3) with ESMTP id DAA12800
	for <ietf-smime@imc.org>; Tue, 12 Sep 2000 03:49:05 -0700 (PDT)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA28788;
	Tue, 12 Sep 2000 06:51:10 -0400 (EDT)
Message-Id: <200009121051.GAA28788@ietf.org>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: ietf-smime@imc.org
From: Internet-Drafts@ietf.org
Reply-to: Internet-Drafts@ietf.org
Subject: I-D ACTION:draft-ietf-smime-ecc-02.txt
Date: Tue, 12 Sep 2000 06:51:10 -0400
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>

--NextPart

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
	Filename	: draft-ietf-smime-ecc-02.txt
	Pages		: 15
	Date		: 11-Sep-00
	
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-02.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-02.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-ecc-02.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.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="mailserv@ietf.org"

Content-Type: text/plain
Content-ID:	<20000911143530.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-ietf-smime-ecc-02.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-smime-ecc-02.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<20000911143530.I-D@ietf.org>

--OtherAccess--

--NextPart--




From owner-ietf-smime@mail.imc.org  Thu Sep 14 11:17:16 2000
Received: from ns.secondary.com (ns.secondary.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA16863
	for <smime-archive@odin.ietf.org>; Thu, 14 Sep 2000 11:17:16 -0400 (EDT)
Received: by ns.secondary.com (8.9.3/8.9.3) id HAA18237
	for ietf-smime-bks; Thu, 14 Sep 2000 07:35:09 -0700 (PDT)
Received: from mail.kpnqwest.ch (mail.eunet.ch [146.228.10.7])
	by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA18233
	for <ietf-smime@imc.org>; Thu, 14 Sep 2000 07:35:07 -0700 (PDT)
From: sdjfsdjkfnu@tpntms.anjes.com.tw
Received: from oettinger.davidoff.ch ([195.49.110.243]) by mail.kpnqwest.ch (8.9.3/1.34) via ESMTP id OAA22718
	for <ietf-smime@imc.org>; Thu, 14 Sep 2000 14:36:53 GMT
	env-from (sdjfsdjkfnu@tpntms.anjes.com.tw)
Received: from mail.mindspring.com by oettinger.davidoff.ch via SMTP
	id smtp\t9ef158v.in; 14 Sep 2000 15:01:00 +0200
To: <ietf-smime@imc.org>
Date: Thu, 14 Sep 2000 05:26:27
Message-Id: <548.115940.189181@mail.mindspring.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
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

GET YOUR OWN 100 MEG WEBSITE FOR ONLY $11.95 PER MONTH TODAY!

STOP PAYING $19.95 or more TODAY for your web site, WHEN YOU CAN 
GET ONE FOR ONLY $11.95 PER MONTH!

DO YOU ALREADY HAVE A WEBSITE? ALL YOU HAVE TO DO IS TRANSFER THE 
DOMAIN TO OUR SERVERS AND UPLOAD YOUR DATA AND YOU ARE READY TO 
GO! YOUR NEW WEB SPACE CAN BE CREATED INSTANTLY WITH JUST A 
SIMPLE PHONE CALL TO  OUR OFFICE.

YOU CAN CHANGE THE DESIGN OF YOUR SITE AS MUCH AS YOU WANT with 
no extra charge!  UNLIMITED TRAFFIC -- no extra charge!

FRONT PAGE EXTENSIONS are FULLY SUPPORTED.

A SET UP FEE OF $40.00 APPLIES for FIRST TIME CUSTOMERS.

ALL FEES PREPAID IN ADVANCE FOR THE YEAR PLUS A $40.00 SET UP 
CHARGE.

FOR DETAILS CALL 1 888 248 0765  

Webhosting International

 
 
 
 
 
 
 
 
 
 
 


From owner-ietf-smime@mail.imc.org  Thu Sep 14 11:41:29 2000
Received: from ns.secondary.com (ns.secondary.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA17399
	for <smime-archive@odin.ietf.org>; Thu, 14 Sep 2000 11:41:29 -0400 (EDT)
Received: (from majordomo@localhost)
	by ns.secondary.com (8.9.3/8.9.3) id IAA18930
	for ietf-smime-bks; Thu, 14 Sep 2000 08:09:24 -0700 (PDT)
Received: from SOTTMXS01.entrust.com (gatekeeper.entrust.com [204.101.128.170])
	by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA18926
	for <ietf-smime@imc.org>; Thu, 14 Sep 2000 08:09:22 -0700 (PDT)
Received: by SOTTMXS01.entrust.com with Internet Mail Service (5.5.2650.21)
	id <S76SN8M4>; Thu, 14 Sep 2000 11:13:16 -0400
Message-ID: <3120721CA75DD411B8340090273D20B1283B04@sottmxs06.entrust.com>
From: Robert Zuccherato <robert.zuccherato@entrust.com>
To: ietf-smime@imc.org
Subject: Comments on draft-ietf-smime-rcek-00.txt
Date: Thu, 14 Sep 2000 11:05:32 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C01E5D.3A7CE7B0"
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>

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C01E5D.3A7CE7B0
Content-Type: text/plain;
	charset="iso-8859-1"

I have a few comments on the draft proposing the re-use of content
encryption keys (draft-ietf-smime-rcek-00.txt).  

The CEKMaxDecrypts makes this scheme vulnerable to a denial-of-service
attack in two ways.  First, the attacker could just resend a message
MaxDecrypt times and the CEKReference would no longer be valid and
potentially not accessible.  Does it make more sense to limit the lifetime
of the CEKReference by time (maybe give the number of seconds it is to be
active) instead of number of decrypts?  Also, since the attribute is
unprotected it could be changed (i.e. reduced) so that the CEKReference
isn't available as long as intended.  Why not allow the attribute to be
protected?  These possibilities should at least be mentioned in the Security
Considerations.

Why not just mandate that the CEK and KEK algorithms must be the same?  This
wouldn't seem to be too much of an imposition.  This removes the need for a
KDF.  If you really want to allow different algorithms, the KDF included
seems kind of ad-hoc.  I would be more comfortable if a more standard KDF
was used.  Perhaps the KDF from IEEE P1363 would be appropriate.

Thanks,

	Robert Zuccherato
	Entrust Technologies


------_=_NextPart_001_01C01E5D.3A7CE7B0
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2652.35">
<TITLE>Comments on draft-ietf-smime-rcek-00.txt</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2 FACE=3D"Arial">I have a few comments on the draft =
proposing the re-use of content encryption keys =
(draft-ietf-smime-rcek-00.txt).&nbsp; </FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">The CEKMaxDecrypts makes this scheme =
vulnerable to a denial-of-service attack in two ways.&nbsp; First, the =
attacker could just resend a message MaxDecrypt times and the =
CEKReference would no longer be valid and potentially not =
accessible.&nbsp; Does it make more sense to limit the lifetime of the =
CEKReference by time (maybe give the number of seconds it is to be =
active) instead of number of decrypts?&nbsp; Also, since the attribute =
is unprotected it could be changed (i.e. reduced) so that the =
CEKReference isn't available as long as intended.&nbsp; Why not allow =
the attribute to be protected?&nbsp; These possibilities should at =
least be mentioned in the Security Considerations.</FONT></P>

<P><FONT SIZE=3D2 FACE=3D"Arial">Why not just mandate that the CEK and =
KEK algorithms must be the same?&nbsp; This wouldn't seem to be too =
much of an imposition.&nbsp; This removes the need for a KDF.&nbsp; If =
you really want to allow different algorithms, the KDF included seems =
kind of ad-hoc.&nbsp; I would be more comfortable if a more standard =
KDF was used.&nbsp; Perhaps the KDF from IEEE P1363 would be =
appropriate.</FONT></P>

<P><FONT SIZE=3D2 FACE=3D"Arial">Thanks,</FONT>
</P>

<P>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=3D2 =
FACE=3D"Arial">Robert Zuccherato</FONT>
<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=3D2 =
FACE=3D"Arial">Entrust Technologies</FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C01E5D.3A7CE7B0--


From owner-ietf-smime@mail.imc.org  Thu Sep 14 15:08:55 2000
Received: from ns.secondary.com (ns.secondary.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA22700
	for <smime-archive@odin.ietf.org>; Thu, 14 Sep 2000 15:08:54 -0400 (EDT)
Received: by ns.secondary.com (8.9.3/8.9.3) id LAA28552
	for ietf-smime-bks; Thu, 14 Sep 2000 11:48:13 -0700 (PDT)
Received: from mail.spyrus.com (mail.spyrus.com [207.212.34.20])
	by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA28548
	for <ietf-smime@imc.org>; Thu, 14 Sep 2000 11:48:12 -0700 (PDT)
Received: from rhousley_laptop.spyrus.com ([209.172.119.205])
	by mail.spyrus.com (8.9.3/8.9.3) with ESMTP id LAA25686;
	Thu, 14 Sep 2000 11:49:55 -0700 (PDT)
Message-Id: <4.3.2.7.2.20000914144037.00bb1bf0@mail.spyrus.com>
X-Sender: rhousley@mail.spyrus.com
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
Date: Thu, 14 Sep 2000 14:46:56 -0400
To: Robert Zuccherato <robert.zuccherato@entrust.com>
From: Russ Housley <housley@spyrus.com>
Subject: Re: Comments on draft-ietf-smime-rcek-00.txt
Cc: ietf-smime@imc.org
In-Reply-To: <3120721CA75DD411B8340090273D20B1283B04@sottmxs06.entrust.c
 om>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
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>

Robert:

There are important environments where the KEK and CEK algorithms are 
different.  Usually, these environment mandate a stronger algorithm for the 
KEK.  This seems like a very reasonable policy, and I think that we should 
not prohibit it.

Russ

At 11:05 AM 09/14/2000 -0400, Robert Zuccherato wrote:
>Why not just mandate that the CEK and KEK algorithms must be the 
>same?  This wouldn't seem to be too much of an imposition.  This removes 
>the need for a KDF.  If you really want to allow different algorithms, the 
>KDF included seems kind of ad-hoc.  I would be more comfortable if a more 
>standard KDF was used.  Perhaps the KDF from IEEE P1363 would be appropriate.



From owner-ietf-smime@mail.imc.org  Fri Sep 15 07:29:06 2000
Received: from ns.secondary.com (ns.secondary.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA17607
	for <smime-archive@odin.ietf.org>; Fri, 15 Sep 2000 07:29:05 -0400 (EDT)
Received: by ns.secondary.com (8.9.3/8.9.3) id EAA08024
	for ietf-smime-bks; Fri, 15 Sep 2000 04:05:39 -0700 (PDT)
Received: from balinese.baltimore.ie (firewall-user@pc215-8.indigo.ie [194.125.215.8])
	by ns.secondary.com (8.9.3/8.9.3) with ESMTP id EAA08020
	for <ietf-smime@imc.org>; Fri, 15 Sep 2000 04:05:37 -0700 (PDT)
Received: by balinese.baltimore.ie; id MAA16808; Fri, 15 Sep 2000 12:07:58 +0100 (GMT/IST)
Received: from bobcat.ie.baltimore.com(10.153.25.10) by balinese.baltimore.ie via smap (V4.2)
	id xma016670; Fri, 15 Sep 00 12:07:13 +0100
Received: from baltimore.ie (ip219-221.ie.baltimore.com [192.168.21.219])
	by bobcat.baltimore.ie (8.9.3/8.9.3) with ESMTP id MAA18177;
	Fri, 15 Sep 2000 12:07:12 +0100
Message-ID: <39C20375.961C5C64@baltimore.ie>
Date: Fri, 15 Sep 2000 12:09:41 +0100
From: Stephen Farrell <stephen.farrell@baltimore.ie>
Reply-To: stephen.farrell@baltimore.ie
Organization: Baltimore Technologies Ltd.
X-Mailer: Mozilla 4.72 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Robert Zuccherato <robert.zuccherato@entrust.com>
CC: ietf-smime@imc.org, xme <stephen.farrell@baltimore.ie>
Subject: Re: Comments on draft-ietf-smime-rcek-00.txt
References: <3120721CA75DD411B8340090273D20B1283B04@sottmxs06.entrust.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
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


Hi Rob,

> Robert Zuccherato wrote:
> 
> I have a few comments on the draft proposing the re-use of content encryption keys
> (draft-ietf-smime-rcek-00.txt).
> 
> The CEKMaxDecrypts makes this scheme vulnerable to a denial-of-service attack in two ways.  First,
> the attacker could just resend a message MaxDecrypt times and the CEKReference would no longer be
> valid and potentially not accessible.  Does it make more sense to limit the lifetime of the
> CEKReference by time (maybe give the number of seconds it is to be active) instead of number of
> decrypts?  

I don't want to get into into clock synchronisation issues, so an expiry time would be
bad. A TTL might be ok, but I'd suspect that its easier for an application using this
scheme to guess or know the maxDecrypts value rather than a TTL. 

> Also, since the attribute is unprotected it could be changed (i.e. reduced) so that the
> CEKReference isn't available as long as intended. Why not allow the attribute to be protected?

Protection is not disallowed, just out of scope for this draft.

> These possibilities should at least be mentioned in the Security Considerations.

Fair enough, will add some more text along these lines.

> 
> Why not just mandate that the CEK and KEK algorithms must be the same?  This wouldn't seem to be
> too much of an imposition.  This removes the need for a KDF.  

Though I agree with you, its clear that others don't (e.g. Russ), so it looks
like we have to include some KDF:-(

> If you really want to allow
> different algorithms, the KDF included seems kind of ad-hoc. I would be more comfortable if a
> more standard KDF was used.  Perhaps the KDF from IEEE P1363 would be appropriate.

I'm perfectly happy to change this to whatever folks prefer. The current
one is ad-hoc as you say, its (only?) benefit is that it only needs the
content encryption algorithm, but I'm not sure if that's significant.

What do others think?

Stephen.


-- 
____________________________________________________________
Stephen Farrell         				   
Baltimore Technologies,   tel: (direct line) +353 1 647 7406
61 Fitzwilliam Lane,                    fax: +353 1 647 7499
Dublin 2.                mailto:stephen.farrell@baltimore.ie
Ireland                             http://www.baltimore.com


From owner-ietf-smime@mail.imc.org  Sun Sep 17 17:38:06 2000
Received: from ns.secondary.com (ns.secondary.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA11813
	for <smime-archive@odin.ietf.org>; Sun, 17 Sep 2000 17:38:06 -0400 (EDT)
Received: by ns.secondary.com (8.9.3/8.9.3) id OAA17667
	for ietf-smime-bks; Sun, 17 Sep 2000 14:07:50 -0700 (PDT)
Received: from kydmsrv.koyoinc.co.jp (kydmsrv.koyoinc.co.jp [210.145.15.116])
	by ns.secondary.com (8.9.3/8.9.3) with ESMTP id OAA17663
	for <ietf-smime@mail.proper.com>; Sun, 17 Sep 2000 14:07:49 -0700 (PDT)
Received: from auiaui ([209.206.4.83])
          by kydmsrv.koyoinc.co.jp (Lotus Domino Release 5.0.2b)
          with ESMTP id 2000091803042413:10187 ;
          Mon, 18 Sep 2000 03:04:24 +0900 
From: "Darren Harris" <wrk23@kozmail.com>
Subject: Easy Start #39F9
To: join39w@ns.secondary.com
X-Mailer: Mozilla 4.70 [en] (Win95; I)
Mime-Version: 1.0
Date: Sun, 17 Sep 2000 12:43:07 -0500
X-MIMETrack: Itemize by SMTP Server on Tokyo/Koyoinc(Release 5.0.2b|28 December 1999) at
 2000/09/18 03:04:26 AM,
	Serialize by Router on Tokyo/Koyoinc(Release 5.0.2b|28 December 1999) at
 2000/09/18 06:21:03 AM,
	Serialize complete at 2000/09/18 06:21:03 AM
Message-ID: <OF02EEB633.157BAE30-ON4925695D.006348B0@koyoinc.co.jp>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by ns.secondary.com id OAA17664
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: 8bit

              
Accepting credit cards for your business 

has never been so easy & affordable!

Our specialty is establishing your merchant account!

NO APPLICATION FEE!

NO PROGRAMMING FEE!

$9.95 PROCESSING FEE

Call today and apply:

(888) 264-9272

Now you can design your web site with our

complete software package, which includes:

     Domain Registration 
     Web Hosting 
     Web Design Tools 
     Shopping Cart 
     Credit Card Processing Integration

Quick, Easy and Affordable at just $99.00!

Call (888) 264-9272 and order today!


************************************************************
If you receive this message and have never joined one of our 
email lists you can be removed  by replying to:
mailto:ylkp2@netscape.net?subject=remove
************************************************************





From owner-ietf-smime@mail.imc.org  Mon Sep 18 00:43:38 2000
Received: from ns.secondary.com (ns.secondary.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA16343
	for <smime-archive@odin.ietf.org>; Mon, 18 Sep 2000 00:43:38 -0400 (EDT)
Received: by ns.secondary.com (8.9.3/8.9.3) id VAA25092
	for ietf-smime-bks; Sun, 17 Sep 2000 21:07:53 -0700 (PDT)
Received: from kydmsrv.koyoinc.co.jp (kydmsrv.koyoinc.co.jp [210.145.15.116])
	by ns.secondary.com (8.9.3/8.9.3) with ESMTP id VAA25087
	for <ietf-smime@mail.proper.com>; Sun, 17 Sep 2000 21:07:51 -0700 (PDT)
Received: from auiaui ([209.206.4.83])
          by kydmsrv.koyoinc.co.jp (Lotus Domino Release 5.0.2b)
          with ESMTP id 2000091803042413:10187 ;
          Mon, 18 Sep 2000 03:04:24 +0900 
From: "Darren Harris" <wrk23@kozmail.com>
Subject: Easy Start #39F9
To: join39w@ns.secondary.com
X-Mailer: Mozilla 4.70 [en] (Win95; I)
Mime-Version: 1.0
Date: Sun, 17 Sep 2000 12:43:07 -0500
X-MIMETrack: Itemize by SMTP Server on Tokyo/Koyoinc(Release 5.0.2b|28 December 1999) at
 2000/09/18 03:04:26 AM,
	Serialize by Router on Tokyo/Koyoinc(Release 5.0.2b|28 December 1999) at
 2000/09/18 01:21:56 PM,
	Serialize complete at 2000/09/18 01:21:56 PM
Message-ID: <OF02EEB633.157BAE30-ON4925695D.006348B0@koyoinc.co.jp>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by ns.secondary.com id VAA25089
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: 8bit

              
Accepting credit cards for your business 

has never been so easy & affordable!

Our specialty is establishing your merchant account!

NO APPLICATION FEE!

NO PROGRAMMING FEE!

$9.95 PROCESSING FEE

Call today and apply:

(888) 264-9272

Now you can design your web site with our

complete software package, which includes:

     Domain Registration 
     Web Hosting 
     Web Design Tools 
     Shopping Cart 
     Credit Card Processing Integration

Quick, Easy and Affordable at just $99.00!

Call (888) 264-9272 and order today!


************************************************************
If you receive this message and have never joined one of our 
email lists you can be removed  by replying to:
mailto:ylkp2@netscape.net?subject=remove
************************************************************





From owner-ietf-smime@mail.imc.org  Mon Sep 18 06:55:35 2000
Received: from ns.secondary.com (ns.secondary.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA01804
	for <smime-archive@odin.ietf.org>; Mon, 18 Sep 2000 06:55:34 -0400 (EDT)
Received: by ns.secondary.com (8.9.3/8.9.3) id DAA06151
	for ietf-smime-bks; Mon, 18 Sep 2000 03:30:35 -0700 (PDT)
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by ns.secondary.com (8.9.3/8.9.3) with ESMTP id DAA06147
	for <ietf-smime@imc.org>; Mon, 18 Sep 2000 03:30:33 -0700 (PDT)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA01359;
	Mon, 18 Sep 2000 06:33:08 -0400 (EDT)
Message-Id: <200009181033.GAA01359@ietf.org>
To: IETF-Announce: ;
Cc: RFC Editor <rfc-editor@isi.edu>, IANA <iana@iana.org>
Cc: Internet Architecture Board <iab@isi.edu>
Cc: ietf-smime@imc.org
From: The IESG <iesg-secretary@ietf.org>
Subject: Protocol Action: Use of the CAST-128 Encryption Algorithm in
	 CMS to Proposed Standard
Date: Mon, 18 Sep 2000 06:33:08 -0400
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>



The IESG has approved the Internet-Draft 'Use of the CAST-128
Encryption Algorithm in CMS' <draft-ietf-smime-cast-128-02.txt> as a
Proposed Standard.  This document is the product of the S/MIME Mail
Security Working Group.  The IESG contact persons are Jeffrey Schiller
and Marcus Leech.

 
Technical Summary
 
This protocol specifies the mechanisms and OIDs necessary to use the
CAST-128 [RFC2144] encryption algorithm with the S/MIME Cryptographic
Message Syntax [RFC2630]. This cipher supports a variable length key
(40 - 128 bits) and is available worldwide without royalties. It is
considered by the cryptographic community as a valid and reasonable
cipher.

Working Group Summary

There was WG consensus on promotion to Proposed Standard.

Protocol Quality

The protocol has been independently reviewed for the IESG by both
Marcus Leech and Jeff Schiller.



From owner-ietf-smime@mail.imc.org  Tue Sep 19 11:39:27 2000
Received: from ns.secondary.com (ns.secondary.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA17841
	for <smime-archive@odin.ietf.org>; Tue, 19 Sep 2000 11:39:26 -0400 (EDT)
Received: by ns.secondary.com (8.9.3/8.9.3) id HAA24946
	for ietf-smime-bks; Tue, 19 Sep 2000 07:40:48 -0700 (PDT)
Received: from balinese.baltimore.ie (firewall-user@pc215-8.indigo.ie [194.125.215.8])
	by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA24740;
	Tue, 19 Sep 2000 07:39:57 -0700 (PDT)
Received: by balinese.baltimore.ie; id PAA11985; Tue, 19 Sep 2000 15:42:37 +0100 (GMT/IST)
Received: from bobcat.ie.baltimore.com(10.153.25.10) by balinese.baltimore.ie via smap (V4.2)
	id xma011799; Tue, 19 Sep 00 15:41:58 +0100
Received: from ocelot.ie.baltimore.com (IDENT:root@ocelot [192.168.21.10])
	by bobcat.baltimore.ie (8.9.3/8.9.3) with ESMTP id PAA26305;
	Tue, 19 Sep 2000 15:41:57 +0100
Received: from ocelot.ie.baltimore.com (afarrell@localhost [127.0.0.1])
	by ocelot.ie.baltimore.com (8.8.7/8.8.7) with ESMTP id PAA12950;
	Tue, 19 Sep 2000 15:41:56 +0100
Message-Id: <200009191441.PAA12950@ocelot.ie.baltimore.com>
To: ietf-pkix@imc.org
Cc: ietf-smime@imc.org
Subject: Re: Q: Is possible indefinite form of length encoding in DER? 
In-Reply-To: Your message of "Tue, 19 Sep 2000 11:39:46 +0900."
             <39C6D1F2.F08FE367@initech.com> 
Date: Tue, 19 Sep 2000 15:41:56 +0100
From: Andrew Farrell <afarrell@baltimore.ie>
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>

ChungKil Kim <chkim@initech.com> wrote:

>In some S/MIME messages, there are indefinite form of length encoding.
>Is it possible?

>In PKCS specs, only use DER?

An important thing to remember is that although it's often specified
that a signature must be over the DER encoding of an object, it's not
necessarily true that what is transmitted has to be that encoding.

On the ridiculous end of this rule is a certificate in which everything
is indefinite length encoded - perfectly valid AFAIK, as long as you
re-encode before verifying.

On the more practical end, it is often impossible to know when composing
a PKCS#7 SignedData how long the data being signed is. As a result all
the layers surrounding the Content (ContentInfo, SignedData,
EncapsulatedContentInfo) are encoded indefinite length, and the content
itself is encoded as a contructed octet string. The signature is over
the contents octets of the DER encoding, and so it is never necessary
even to count the length of the assembled octetstring. The individual
strings are simply fed to the digests as they appear.

Andrew


From owner-ietf-smime@mail.imc.org  Tue Sep 19 13:38:05 2000
Received: from ns.secondary.com (ns.secondary.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA21133
	for <smime-archive@odin.ietf.org>; Tue, 19 Sep 2000 13:38:05 -0400 (EDT)
Received: by ns.secondary.com (8.9.3/8.9.3) id JAA03528
	for ietf-smime-bks; Tue, 19 Sep 2000 09:59:09 -0700 (PDT)
Received: from tholian.securitydynamics.com (tholian.securid.com [204.167.112.129])
	by ns.secondary.com (8.9.3/8.9.3) with SMTP id JAA03523;
	Tue, 19 Sep 2000 09:59:07 -0700 (PDT)
Received: from sdtihq24.securitydynamics.com by tholian.securitydynamics.com
          via smtpd (for mail.imc.org [208.184.76.43]) with SMTP; 19 Sep 2000 17:00:42 UT
Received: from exrsa01.rsa.com (exrsa01.securitydynamics.com [10.81.217.7])
	by sdtihq24.securid.com (Pro-8.9.3/Pro-8.9.3) with ESMTP id MAA17603;
	Tue, 19 Sep 2000 12:59:06 -0400 (EDT)
Received: by exrsa01.rsa.com with Internet Mail Service (5.5.2448.0)
	id <SC8Y2BVV>; Tue, 19 Sep 2000 10:01:47 -0700
Message-ID: <E7B6CB80230AD31185AD0008C7EBC4D28213A1@exrsa01.rsa.com>
From: "Kingdon, Kevin" <kevin@rsasecurity.com>
To: "'Andrew Farrell'" <afarrell@baltimore.ie>, ietf-pkix@imc.org
Cc: ietf-smime@imc.org
Subject: RE: Q: Is possible indefinite form of length encoding in DER? 
Date: Tue, 19 Sep 2000 10:01:46 -0700
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
Content-Type: text/plain;
	charset="iso-8859-1"
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>

See comments below:

-----Original Message-----
From: Andrew Farrell [mailto:afarrell@baltimore.ie]
Sent: Tuesday, September 19, 2000 7:42 AM
To: ietf-pkix@imc.org
Cc: ietf-smime@imc.org
Subject: Re: Q: Is possible indefinite form of length encoding in DER? 


<SNIP/>

On the ridiculous end of this rule is a certificate in which everything
is indefinite length encoded - perfectly valid AFAIK, as long as you
re-encode before verifying.

<KWK>
Further complicating matters is the fact that some commercial products
incorrectly sign the BER encoding. So to validate a signature against a
BER-encoded message, you may have to try validating the with the transmitted
encoding and if that fails try re-coding and validating against the
DER-encoding of the message. (Note that signing BER is flawed if there is a
possibility that an intermediate processor will re-code the BER encoding
into a different but equivalent BER encoding. This usually doesn't happen
with BER, but it is expected to happen with XML-encoded documents. Thus
there is increased emphasis on "canonicalization" procedures for XML digital
signatures.)
</KWK>

<SNIP/>


From owner-ietf-smime@mail.imc.org  Wed Sep 20 10:04:06 2000
Received: from ns.secondary.com (ns.secondary.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA23333
	for <smime-archive@odin.ietf.org>; Wed, 20 Sep 2000 10:04:05 -0400 (EDT)
Received: (from majordomo@localhost)
	by ns.secondary.com (8.9.3/8.9.3) id FAA22966
	for ietf-smime-bks; Wed, 20 Sep 2000 05:56:22 -0700 (PDT)
Received: from bdcsql1.al-rostamani.co.ae ([194.170.227.9])
	by ns.secondary.com (8.9.3/8.9.3) with SMTP id FAA22959
	for <ietf-smime@imc.org>; Wed, 20 Sep 2000 05:55:55 -0700 (PDT)
Date: Wed, 20 Sep 2000 05:55:55 -0700 (PDT)
From: nile333@kadet.co.uk
Message-Id: <200009201255.FAA22959@ns.secondary.com>
Received: from SMTP agent by mail gateway 
 Wed, 20 Sep 2000 17:01:36 --400
Received: from firewall-in.al-rostamani.co.ae by bdcsql1.al-rostamani.co.ae with SMTP (Microsoft Exchange Internet Mail Service Version 5.0.1460.8)
	id TFDHQ4XS; Wed, 20 Sep 2000 16:42:33 +0400
Received: from SMTP agent by mail gateway 
 Wed, 20 Sep 2000 16:47:36 --400
To: nile333@kadet.co.uk
Subject: So, How in the heck have you been?
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>


So, How in the heck have you been?

Do you remember holding previous conversations regarding business and
money making opportunities? I did not send this to you in error!

You Said:

If only I could find an easier way to make a higher income!

and

If I had more money, I could spend more time with my Family, and less
time at work and I sure could use more money so I could pay off my
bills once and for all!

And

I would love to get involved in a business in which will generate money
while I am not at work (like a Gas Pump)!

Dear Friend,

There is a possibility that we haven’t met, but you were chosen by
someone to receive this E-Mail. Please, please, print this off and
read thoroughly. Be sure that you don’t miss any of the points
outlined.  Then put it down, and then read it again. I am sending
you a whole lot of information in which you might not understand
the first time you read it. If you don’t believe this  program
will work for you, send it to 10-20 of your closest friends
(in which you trust deeply),  and ask them what they think?
This really works! Have faith, don’t miss this opportunity,
get involved also, and it will work for you as it does for us!!!!

Due to the popularity of this letter on the Internet, A Major Nightly
News Program recently dedicated an entire show to the investigation of
the
program described below to see if it really can make people money.
The show also investigated whether or not the program was legal. Their
findings proved that there are absolutely no laws prohibiting the
participation in the program. This has helped to show people that this
is a simple, harmless and fun way to make extra money at home. The
results have been truly remarkable. So many people are participating
that those involved are doing much better than ever before. Since
everyone makes more as more people try it out, its been very exciting.

You will understand only if you get involved!
********** THE ENTIRE PLAN IS HERE BELOW **********
**** Print This Now For Future Reference ****

$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$
If you would like to make AT LEAST $50,000 in less than 90 days! If not,

forward this to someone who would like to make this kind of money.
It works (like designed) but only for those who follow it to the letter!

Please read this program THEN READ IT AGAIN!!
$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$

THIS IS A LEGITIMATE. LEGAL, MONEY MAKING OPPORTUNITY!! It does NOT
require you to come into contact with people or make or take any
telephone
calls. Just follow the instructions, and you will make money. This
simplified e-mail marketing program works perfectly 100% EVERY TIME!

E-mail is the sales tool of the future. Take advantage of this virtually

free method of advertising NOW!!! The longer you wait, the more people
will
be doing business using e-mail. Get your piece of this action!!!

Hello, My name is Johnathon Rourke, I’m from Rhode Island.  The enclosed

information is something I almost let slip through my fingers.
Fortunately, sometime later I re-read everything and gave some thought
and study to it. Two years ago, the corporation I worked for the past
twelve yearsdown-sized and my position was eliminated. After
unproductive
job interviews, I decided to open my own business. Over the past year,I
incurred many unforeseen financial problems. I owed my family, friends
and
creditors over$35,000. The economy was taking a toll on my business and
I
just could not seem to make ends meet. I had to refinance and borrow
against
my home to support my family and struggling business.

AT THAT MOMENT something significant happened in my life. I am writing
to share the experience I hopes that this could change your life
FOREVER.
FINANCIALLY$$$!!!

In mid December, I received this program in my e-mail. Six months prior
to
receiving this program I had been sending away for information on
various
business opportunities. All of the programs I received, in my
opinion,were
not cost effective. They were either toodifficult for me to comprehend
or
the initial investment was too muchfor me to risk to see if they would
work.
But as I was saying, in December of 1997 I received this program.I
didn’t
send for it, or ask for it, they just got my name off a mailing list.

THANK GOODNESS FOR THAT!!!

After reading it several times, to make sure I was reading it correctly.
I
couldn’t believe my eyes! Here was a MONEY MAKING MACHINE I could start
immediately without any debt. Like most of you I was still a little
skeptical and a little worried about the legalaspects of it all. So I
checked it out with the U.S. Post Office (1-800-725-2161 24-hrs)  and
they
confirmed that it is indeed legal ! After determining the program was
LEGAL
I decided WHY NOT!?!??

Initially I sent out 10,000 e-mails. It cost me about $15 for my time
on-line. The great thing about e-mail is that I don’t need any paper for

printing to send out the program, and because I also send the product
(reports) by e-mail, my only expense is my time. In less than one week,I
was
starting to receive orders for REPORT #1.

By January 13, I had received 26 orders for REPORT #1. Your goal is to
RECEIVE at least 20 ORDERS FOR REPORT #1 WITHIN 2 WEEKS. IF YOU DON’T
SEND OUT MORE PROGRAMS UNTIL YOU DO. My first step in making $50,000 in
90
days was done. By January 30, I had received 196 orders for REPORT #2.
Your
goal is to RECEIVE AT LEAST 100+ ORDERS FOR REPORT #2 WITHIN
2 WEEKS. IF NOT SEND OUT MORE PROGRAMS UNTIL YOU! DO. ONCE YOU HAVE
100 ORDERS, THE REST IS EASY, RELAX, YOU WILL MAKE YOUR $50,000 GOAL.

Well, I had 196 orders for REPORT #2. 96 more than I needed. So I
sat back and relaxed.

By March 1, of my e-mailing of 10,000, received $58,000 with more coming
in
every day. I paid off ALL my debts and bought a much need new car!
Please
take your time to read this plan, IT WILL CHANGE YOUR LIFE FOREVER$!!!
Remember, it won’t work if you don’t try it. This program does work, But
you
must follow it EXACTLY! Especially the rules of not trying to place your

name in a different place. It won’t work and you’ll lose out on a lot of

money! In order for this program to work, you must meet your goal of 20+

orders for REPORT #1, and 100+ orders for REPORT #2 and you will make
$50,000 or more in 90 days.

I AM LIVING PROOF THAT IT WORKS!!!

If you choose not to participate in this program, I am sorry. It really
is a great opportunity with little cost or risk to you.  If you choose
toparticipate, follow the program and you will be on your way to
financial security. If you are a fellow business owner and
are financial trouble like I was, or you want to start your own
business, consider this a sign. I DID! $$

Sincerely,
Johnathon Rourke

A PERSONAL NOTE FROM THE ORIGINATOR OF THIS PROGRAM: By the time you
have read the enclosed program and reports, you should have concluded
that
such a program, and one that is legal, cpuld not have been created by an

amateur. Let me tell you a little about myself. I had a profitable
business
for 10 years. Then in 1979 my business began falling off. I was doing
the
same things that were previously successful for me, but it wasn’t
working.
Finally, I figured it out. It wasn’t me, it was the economy. Inflation
and
recession had replaced the stable economy that had been with us since
1945.
I don’t have to tell you what happened to the unemployment rate because
many
of you know from first hand experience. There were more failures and
bankruptcies than ever before. The middle class was vanishing. Those who

knew what they were doing invested wisely and moved up. Those who did
not,
including those who never had anything to save or invest, were moving
down into the ranks of the poor. As the saying goes, THE RICH GET RICHER

ANDTHE POOR GET POORER.  The traditional methods of making money will
never
allow you to move up or get rich, inflation will see to that You have
just
received the rest of  your life, with NO RISK and JUST A LITTLE BIT OF
EFFORT. You can make more money in the next few months than you have
everimagined.I should also point out that I will not see a penny of this

money, nor anyone else who has provided a testimonial for this program.
I
retired from the program after sending thousands and thousands of
programs.
Follow the program EXACTLY AS INSTRUCTED. Do not change it in any way.
It
works exceedingly well as it is now. Remember to e-mail a copyof this
exciting report to everyone you can think of. One of the people you send

this to may send out 50,000 and your name will be on everyone of them!
REMEMBER though, ------ the MORE YOU SEND OUT, the more potential
customers
you will reach. So my friend, I have given you the ideas,  information,
materials and opportunity to become financially independent.

IT IS UP TO YOU!! NOW DO IT!!

BEFORE YOU delete this program from your in box, as I almost did, take a

little time to read it and REALLY THINK ABOUT IT. Get a pencil and
figure out what could happen when YOU participate. Figure out the worst
possible response and no matter how you calculate it, you will still
make a
lot of money! You will definitely get back what you invested. Any doubts
you
have will vanish when your first orders come in. $$$ IT WORKS!!! $$$

Jody Jacobs Richmond, VA.

HERE’S HOW THIS AMAZING PROGRAM WILL MAKE YOU THOUSANDS OF
DOLLARS$$$$!!!!

This method of raising capital REALLY WORKS 100% EVERY TIME. I am sure
that you could use up to $50,000 or more in the next 90 days. Before you
say
BULL, please read this program carefully. This is not a chain letter,but
a
perfectly legal money making business. As with all multi-level
businesses,
we build our business by recruiting new partners and selling our
products.
Every state in the USA allows you to recruit new multi-level business
partners, and we sell and deliver a product for EVERY dollar received.

YOUR ORDERS COME BY MAIL AND ARE FILLED BY E-MAIL, so you are not
involved in personal selling. You do it privately in your own home,
store or
office. This is the EASIEST marketing plan anywhere! It is simply order
filling by e-mail! The product is informational and instructional
material,
keys to the secrets for everyone on how to open the doors to the magic
world
of E-COMMERCE, the information highway, the wave of the future !

PLAN SUMMARY:

(1) You order the 4 reports listed below ($5 each) They come to you by
e-mail.

(2)  Save a copy of this entire letter and put your name after Report #1
and
move the other names down.

(3)  Via the internet, access Yahoo.com or any of the other major search

engines to locate hundreds of bulk e-mail service companies (search for
bulk
email) and have them send 25,000  50,000 emails for you about $49+.

(4)  Orders will come to you by postal mail simply e-mail them the
Report they ordered. Let me ask you  isn’t this about as easy as it
gets?

By the way there are over 50 MILLION e-mail address with millions more
joining the internet each year so don’t worry about running out or
saturation. People are used to seeing and hearing the same
advertisements every day on radio/TV. How many times have you received
the same pizza flyers on your door? Then one day you are hungry for
pizza
and order one. Same thing with this letter. I received this letter many
times  then one day I decided it was time to try it.

YOU CAN START TODAY UST DO THESE EASY STEPS: STEP #1 ORDER THE FOUR
REPORTS

Order the four reports shown on the list below (you can’t sell them if
you don’t order them).  For each report, send $5.00 CASH, the NAME &
NUMBER
OF THE REPORT YOU ARE ORDERING, YOUR E-MAIL ADDRESS, and YOUR NAME &
RETURN
ADDRESS (in case of a problem) to the person whose name appears on the
list
next to the report.MAKE SURE YOUR RETURN ADDRESS IS ON YOUR ENVELOPE IN
CASE OF ANY MAIL PROBLEMS! Within a few days you will receive, by e-mail

each of the four reports.Save them on your computer so you can send them
to
the 1,000’s of people who will  order them from you.

STEP #2. ADD YOUR MAILING ADDRESS TO THIS LETTER

a. Look below for the listing of the four reports.
b. After you’ve ordered the four reports, delete the name and address
under REPORT #4. This person has made it through the cycle.
c. Move the name and address under REPORT #3 down to REPORT #4.
d. Move the name and address under REPORT #2 down to REPORT #3.
e. Move the name and address under REPORT #1 down to REPORT #2.
f. Insert your name/address in the REPORT #1 position. Please make sure
you

COPY ALL INFORMATION, every name and address, ACCURATELY!

STEP #3. Take this entire letter, including the modified list of names,
and save it to your computer. Make NO changes to these instructions. Now
you
are ready to use this entire e-mail to send by e-mail to prospects.

Report #1 will tell you how to download bulk email software and email
address so you can send it out to thousands of people while you sleep!
Remember that 50,000+ new people are joining the internet every month!
Your cost to participate in this is practically nothing ( surely you can

afford $20 and initial bulk mailing cost). You obviously already have a
computer and an Internet connection and e-mail is FREE! There are two
primary methods of building your downline: METHOD #1: SENDING BULK
E-MAIL
let’s say that you decide to start small, just to see how it goes, and
we’ll
assume you and all those involved email out only 2,000 programs each.
Let’s
also assume that the mailing receives a 0.5% response. The response
could be
much better. Also, many people will email out thousands of thousands of
programs instead of 2,000 (Why stop at 2000?) But continuing with this
example, you send out only 2,000 programs. With a 0.5% response, that is

only 10 orders for REPORT #1. Those 10 people respond by sending out
2,000
programs each for a total of 20,000. Out of those 0.5%, 100 people
respond
and order REPORT #2.Those 100 mail out 2,000 programs each for a total
of
200,000. The 0.5% response to that is 1,000 orders for REPORT #3. Those
1,000 send out 2,000  programs each for a 2,000,000 total. The 0.5%
response
to that is 10,000 orders for REPORT #4. That’s 10,000 $5 bills for you.
CASH!!! Your total income in this example is $50 + $500 + $5000 +
$50,000
for a total of $55,550!!!

REMEMBER FRIEND, THIS IS ASSUMING 1,990 OUT OF THE 2,000 PEOPLE YOU MAIL
TO
WILL DO ABSOLUTELY NOTHING AND TRASH THIS PROGRAM! DARE TO THINK FOR A
MOMENT WHAT WOULD HAPPEN IF EVERYONE, OR HALF SENT OUT 100,000 PROGRAMS
INSTEAD OF 2,000. Believe me, many people will do just that, and more!

METHOD #2 PLACING FREE ADS ON THE INTERNET Advertising on the internet
is very, very inexpensive, and there are HUNDREDS of FREE places to
advertise. Let’s say you decide to start small to see how well it works.

Assume your goal is to get ONLY 10 people to participate on your first
level. (Placing a lot of FREE ads on the Internet will EASILY get a
larger
response). Also assume that everyone else in YOUR ORGANIZATION gets only
10
downline members. Look how this small number accumulates to achieve the
STAGGERING results below:

1St level  your first 10 send you $5........................$50
2nd level  10 members from those 10 ($5 x 100)............$500
3rd level  10 members from those 100 ($5 x 1,000)......$5,000
4th level 10 members from those 1,000 ($5 x 10,000)..$50,000
$$$$$$ THIS TOTALS
------------------------------------------------55,5550
$$$$$

AMAZING ISN’T IT Remember friends, this assumes that the people who
participate only recruit 10 people each. Think for a moment what would
happen if they got 20 people to participate! Most people get 100’s of
participants and many will continue to work this program, sending out
programs WITH YOUR NAME ON THEM for years! THINK ABOUT IT!
People are going to get emails about this plan from you or somebody else
and
many will work this plan  the question is Don’t you want your name to be
on
the emails they will send out?

*** DON’T MISS OUT !!!***
***JUST TRY IT ONCE !!!***
***SEE WHAT HAPPENS !!!***
***YOU'LL BE AMAZED !!!***

ALWAYS PROVIDE SAME DAY SERVICE ON ALL ORDERS! This will guarantee that
the e-mail THEY send out with YOUR name and address on it will be prompt

because they can’t advertise until they receive the report!

GET STARTED TODAY: PLACE YOUR ORDER FOR THE FOUR REPORTS NOW. Note:--
ALWAYS SEND $5 CASH (U.S. CURRENCY) FOR EACH REPORT. CHECKS NOT
ACCEPTED.
Make sure the cash is concealed by wrapping it in two sheets of paper.
On
one of those sheets write:

(a) the number & name of the report you are ordering
(b) your e-mail address, and
(c) your name & postal address.

REPORT #1b The Insider’s Guide to Advertising for Free on the Internet
ORDER REPORT #1 FROM:

NICK NICHOLAS
473 MICHIGAN ST
ST.PAUL, MN 55102

NOTE: I and every member below are dedicated at helping you with this
program so it will work for you also. TRY US!

REPORT #2 The Insider’s Guide to Sending Bulk E-Mail on the Internet
ORDER REPORT #2 FROM:

DIANE COLON
1811 TAMARIND AVE # 206
LOS ANGELES, CA. 90028

REPORT #3 The Secrets to Multilevel Marketing on the Internet
ORDER REPORT #3 FROM:

MELISSA HOGENMILLER
3709 MONHEIM ROAD
CONOVER, WI 54519

REPORT #4 How to become a Millionaire utilizing the Power of Multilevel
Marketing and the Internet
ORDER REPORT #4 FROM:

CATHY BARROW
10 SYCAMORE STREET
CONWAY, SC 29527

*************TIPS FOR SUCCESS***************
TREAT THIS AS YOUR BUSINESS! Be prompt, professional, and follow the
directions accurately.  Send for the four reports IMMEDIATELY so you
will have them when the orders start coming in because: When you
receive a $5 order you MUST send out the requested product/report.
It is required for this to be a legal business and they need the
reports to send out their letter (with your name on them).

--ALWAYS PROVIDE SAME-DAY SERVICE ON THE ORDERS YOU RECEIVE. Be
patient and persistent with this program- If you follow the
instructions exactly results WILL FOLLOW. $$$$

************ YOUR SUCCESS GUIDELINES ***************

Follow these guidelines to guarantee your success: If you don’t receive
20 orders for REPORT #1 within two weeks, continue advertising or
sending
e-mail until you do. Then a couple of weeks later you should receive at
least 100 orders for REPORT #2. If you don’t continue advertising or
sending
e-mail until you do. Once you have received 100 or more orders for
REPORT
#2, YOU CAN RELAX, because the system is already working for you, and
the
cash will continue to roll in! THIS IS IMPORTANT TO REMEMBER:  Every
time
your name is moved down on the list, you are placed in front of a
DIFFERENT
report. You can KEEP TRACK of your  PROGRESS by watching which report
people
are ordering from you. To generate more income, simply send another
batch of
e-mails or continue placing ads and start the whole process again! There
is
no limit to the income you will generate from this business! Before you
make
your decision as to whether or not you participate in this program.
Please
answer one question:

ARE YOU HAPPY WITH YOUR PRESENT INCOME OR JOB?

1. If the answer is no, then please look at the following facts about
this super simple MLM program: NO face to face selling, NO meetings, NO
inventory! NO Telephone calls, NO big cost to start! Nothing to learn,
No skills needed! (Surely you know how to send email?)

2. No equipment to buy you already have a computer and internet
connection so you have everything you need to fill orders!

3. You are selling a product which does NOT COST ANYTHING TO PRODUCE OR
SHIP! (Email copies of the reports are FREE!)

4. All of your customers pay you in CASH! This program will change your
LIFE  FOREEVER!! Look at the potential for you to be able to quit your
job and live a life of luxury you could only dream about! Imagine
getting out of debt and buying the car and home of your dreams and
being able to work a super-high paying leisurely easy business from
home!

$$$ FINALLY MAKE SOME DREAMS COME TRUE! $$$ ACT NOW!
Take your first step toward achieving financial independence.  Order
the reports and follow the program outlined above __ SUCCESS will be
your reward.

Thank you for your time and consideration. PLEASE NOT: If you need
help with starting a business, registering a business name, learning
now income tax is handled, etc., contact your local office of the
Small Business Administration  (A Federal Agency) 1-800-827-5722
for free help and answers to questions. Also the Internal Revenue
Service offers free help via telephone and free seminars about
business tax requirements. Your earnings are highly dependent on
your activities and advertising. The information contained on this
site and in the report constitutes no guarantees stated nor implied.
In the event that it is determined that this site or report
constitutes a guarantee of any kind, that guarantee is now void. The
earnings amounts listed on this site and in the report are estimates
only. If you have any questions of the legality of this program,
contact the Office of Associate Director for Marketing Practices,
Federal Trade Commission, Bureau of Consumer Protection in
Washington DC.

Under Bill s.1618 TITLE III passed by the 105th US Congress this
letter cannot be considered spam as long as the sender includes
contact information and a method of removal. This is a one time
e-mail transmission. No request for removal is necessary.





From owner-ietf-smime@mail.imc.org  Fri Sep 22 13:35:57 2000
Received: from ns.secondary.com (ns.secondary.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA21360
	for <smime-archive@odin.ietf.org>; Fri, 22 Sep 2000 13:35:57 -0400 (EDT)
Received: by ns.secondary.com (8.9.3/8.9.3) id JAA11388
	for ietf-smime-bks; Fri, 22 Sep 2000 09:54:42 -0700 (PDT)
Received: from smtp.scotland.net (plug.sol.co.uk [194.247.64.1])
	by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA11160;
	Fri, 22 Sep 2000 09:52:43 -0700 (PDT)
Received: from e2h2p31.scotland.net ([148.176.238.32] helo=JOHNVARSYSTEM)
	by smtp.scotland.net with smtp (Exim 3.14 #10)
	id 13cW6N-0007Nu-00; Fri, 22 Sep 2000 17:55:07 +0100
From: "John Ross" <ross@secstan.com>
To: "ietf-pkix@imc. org" <ietf-pkix@imc.org>,
        "Ietf distribution list" <ietf-smime@imc.org>
Subject: ETSI documents for open comment
Date: Fri, 22 Sep 2000 17:54:34 +0100
Message-ID: <KGEPIFMENMPBAHHCDBLCEENACGAA.ross@secstan.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700
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>
X-MIME-Autoconverted: from 8bit to quoted-printable by ns.secondary.com id JAA11388
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id NAA21360

Three draft standards which relate to IETF work items in PKIX and S/MIME
have been posted on the ETSI El Sign Web-site for comments. Comments are
requested on these documents by 13th October 2000 to the ETSI El Sign e-mail
list EL-SIGN@LIST.ETSI.FR.

To register with the EL-SIGN list and download the draft documents see:
http://www.etsi.org/sec/el-sign.htm

The three documents are:

1.  Qualified Certificate Profile: Please put "QC profile" in the front of
the Subject field of all
submissions to the e-mail list on this topic.

2. Time Stamping Profile: Please put "TS profile" in the front of the
Subject field of all submissions
to the e-mail list on this topic.

3. Revised Electronic Signature Formats: Please put "ES Formats" in the
front of the Subject field of all submissions to the e-mail list on this
topic.

Regards

György Endersz, Telia Research AB.  gyorgy.g.endersz@telia.se
Denis Pinkas, Bull.                 pinkas@bull.net
Stefan Santesson, AddTrust.	      stefan@accurata.se
John Ross, Security & Standards.    ross@secstan.com





From owner-ietf-smime@mail.imc.org  Fri Sep 22 20:34:55 2000
Received: from ns.secondary.com (ns.secondary.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA29246
	for <smime-archive@odin.ietf.org>; Fri, 22 Sep 2000 20:34:54 -0400 (EDT)
Received: by ns.secondary.com (8.9.3/8.9.3) id RAA20172
	for ietf-smime-bks; Fri, 22 Sep 2000 17:06:05 -0700 (PDT)
Received: from www.com2000.co.kr (com2000.co.kr [203.236.86.98])
	by ns.secondary.com (8.9.3/8.9.3) with ESMTP id RAA20168
	for <ietf-smime@mail.proper.com>; Fri, 22 Sep 2000 17:05:59 -0700 (PDT)
Received: from host ([206.133.176.96])
          by www.com2000.co.kr (Lotus Domino Release 5.0.2c)
          with ESMTP id 2000092309050839:2151 ;
          Sat, 23 Sep 2000 09:05:08 +0900 
From: "Brendon Mills" <bbker4@safe-mail.net>
Subject: Do You Invest? # DEF
To: stock39d@ns.secondary.com
X-Mailer: Microsoft Outlook Express 4.72.1712.3
X-MimeOLE: Produced By Microsoft MimeOLE VÐßD.1712.3
Mime-Version: 1.0
Date: Fri, 22 Sep 2000 18:51:58 -0500
X-MIMETrack: Itemize by SMTP Server on millecom/Com2000(Release 5.0.2c|2000. 2. 18.) at
 2000-09-23 09:05:10,
	Serialize by Router on millecom/Com2000(Release 5.0.2c|2000. 2. 18.) at
 2000-09-23 09:05:36,
	Serialize complete at 2000-09-23 09:05:36
Message-ID: <OFF64B9AB2.74973318-ON49256963.0000793B@com2000.co.kr>
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-Type: text/plain; charset=unknown-8bit

Do you invest in the stockmarket?

If you invest in technology stocks and are familiar with their trading 
patterns, then you must have seen where many a company's stocks have gone 
from near obscurity to double-digit gains in a very short time frame. These 
tremendous opportunities have inspired us to seek out similar potential 
"big gainers" while they are still in their "near obscurity" stage prior 
to making a big move. These are companies with solid business fundamentals, 
strong management, and huge upside potential because of a solid
product or technology.

We believe that such an opportunity exists in Indexonly Technologies. 
This innovative tech company developed the Internet's first Business 
Search Directory designed for Internet and Wireless use, utilizing its 
own unique computerized content filtering and sorting methods, and a 
committed and proactive community-based franchisee sales force. Their
community-based sales force assures users receive the most accurate 
information on business throughout the world, regardless
of whether they are sitting at their computer or traveling. Indexonly.com 
has a well-developed Path to Profitability (P2P), which
means that profitability, is months, not years, away. The 
Indexonly.com Business Search Directory eliminates, for its users,
millions of irrelevant "matches" and virtually all connections to dead 
links and provides a break-through solution to the all too
frequently asked question: "If the Internet is so good, then why can't 
I find what I am looking for?" http://www.Indexonly.com allows users to
find all the plumbers in their area, or all the hotels in the destination
they wish to visit. They are not restricted to just companies
with Websites or companies that advertise. Indexonly.com lists all companies.

The attached illustration demonstrates how you can use your wireless devices
to access the Indexonly.com Business Search Directory and with only 4 clicks 
find a hotel in San Francisco. Then with a push of a button on your PDA or 
mobile phone, you can then directly contact or telephone the hotel and 
make a reservation. For more information please contact Kirk Hinton Financial at:
Email: khfrelations@hotmail.com
Toll free: 1-877-899-9950 or Phone:(604) 605-1225 

                                  Visit the site at http://www.indexonly.com

////////////////////////////////////////////////////////
If you wish to be removed from this list reply to:
mailto:bbker4@netscape.net?subject=remove
////////////////////////////////////////////////////////





From owner-ietf-smime@mail.imc.org  Tue Sep 26 11:31:38 2000
Received: from ns.secondary.com (ns.secondary.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA11148
	for <smime-archive@odin.ietf.org>; Tue, 26 Sep 2000 11:31:38 -0400 (EDT)
Received: by ns.secondary.com (8.9.3/8.9.3) id HAA17637
	for ietf-smime-bks; Tue, 26 Sep 2000 07:39:14 -0700 (PDT)
Received: from mail.ec.auckland.ac.nz (mail.student.auckland.ac.nz [130.216.35.201])
	by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA17632
	for <ietf-smime@imc.org>; Tue, 26 Sep 2000 07:39:12 -0700 (PDT)
Received: from kahu.cs.auckland.ac.nz (pgut001@kahu.cs.auckland.ac.nz [130.216.36.13]) by mail.ec.auckland.ac.nz (8.9.3/8.8.6/cs-master) with SMTP id CAA19499 for <ietf-smime@imc.org>; Wed, 27 Sep 2000 02:42:24 +1200 (NZST) (sender pgut001@cs.auckland.ac.nz)
Received: by kahu.cs.auckland.ac.nz (relaymail v0.9)
	id <96997934711908>; Wed, 27 Sep 2000 02:42:27 (NZST)
From: pgut001@cs.aucKland.ac.nz (Peter Gutmann)
To: ietf-smime@imc.org
Subject: Re: Question on basicConstraints from RFC 2632
Reply-To: pgut001@cs.aucKland.ac.nz
X-Charge-To: pgut001
X-Authenticated: relaymail v0.9 on kahu.cs.auckland.ac.nz
Date: Wed, 27 Sep 2000 02:42:27 (NZST)
Message-ID: <96997934711908@kahu.cs.auckland.ac.nz>
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>

Gwangsoo Rhee <rhee@sookmyung.ac.kr> writes:

>The material below is from RFC 2632. Seems to me that the statements about
>end-entity certificates in the last two paragraphs conflict with each other.
>One says that end-entity certificates contain a basicConstraints extension and
>another says they shouldn't. Maybe I misunderstood those statements. Could
>anyone please enlighten me on the subject?

It's a problem with RFC 2459 which is covered, in the X.509 style guide,
http://www.cs.auckland.ac.nz/~pgut001/pubs/x509guide.txt.  Most of the certs
I've seen seem to ignore the RFC 2459 text, including a basicConstraints
extension in end entity certs, so the problems described in the guide shouldn't
occur much.

Peter.



From owner-ietf-smime@mail.imc.org  Fri Sep 29 12:45:44 2000
Received: from ns.secondary.com (ns.secondary.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA02777
	for <smime-archive@odin.ietf.org>; Fri, 29 Sep 2000 12:45:43 -0400 (EDT)
Received: (from majordomo@localhost)
	by ns.secondary.com (8.9.3/8.9.3) id IAA01147
	for ietf-smime-bks; Fri, 29 Sep 2000 08:44:54 -0700 (PDT)
Received: from aeposmail.aepos.com ([209.112.11.5])
	by ns.secondary.com (8.9.3/8.9.3) with SMTP id IAA01143
	for <ietf-smime@imc.org>; Fri, 29 Sep 2000 08:44:52 -0700 (PDT)
From: mkicksee@aepos.adga.ca
Received: by aeposmail.aepos.com(Lotus SMTP MTA v4.6.4  (830.2 3-23-1999))  id 85256969.005A757B ; Fri, 29 Sep 2000 12:28:03 -0400
X-Lotus-FromDomain: AEPOS
To: ietf-smime@imc.org
Message-ID: <85256969.005A7423.00@aeposmail.aepos.com>
Date: Fri, 29 Sep 2000 11:50:13 -0400
Subject: ESS Questions
Mime-Version: 1.0
Content-type: text/plain; charset=us-ascii
Content-Disposition: inline
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>



   I have carefully and meticulously read through RFC2634 (Enhanced Security
Services for S/MIME), and have questions about various sections of it.  Any
insight into these issues would be greatly appreciated.


3.4.2 Processing Equivalent Labels

Q.  If an organization has a security policy that maps another organization's
security labels to its own, and also trusts a message sender to specify
equivalent security labels, and the two disagree (e.g. A sender applies Acme's
"Confidential" label and claims that this is equivalent to Widgets' "Private",
but Widgets' security policy states that Acme's "Confidential" is equivalent to
Widgets' "Secret"), which label should the receiving agent (or MLA) at Widgets
use for access control?  Should the more restrictive of the two be applied?

4.1 Mail List Expansion

Q.    A mail list agent must add its own mlData record to the mlExpansionHistory
attribute in the outer signed layer of the message, creating the
mlExpansionHistory attribute (and possibly the signed layer that contains it) as
needed.  It must also check that all the mlExpansionHistory attributes that it
can verify are identical.

   What happens if an MLA can't verify a particular signerInfo because it uses
an unknown algorithm?  It cannot modify the mlExpansionHistory attribute in the
signerInfo, since it A) cannot trust it, and B) cannot generate the new
signature for it using the same algorithm.  If it only modifies the signerInfos
that it can sign, they no longer match, and the next MLA that can verify all the
signerInfos will (correctly) reject the message, since the mlExpansionHistory
attributes won't match.  The only solution would be to drop the signerInfo that
the MLA cannot verify, despite the fact that it may be valid.

Q.  How should a mail list agent process a message if the only signerInfo in the
outer layer is signed using an unknown algorithm?  Since it cannot verify the
signerInfo, it should not process or expand its mlExpansionHistory list.  It
should not add an additional outer signature layer, since its attributes would
not include those of the previous outer layer.  Replacing the existing (possibly
valid) signerInfo is not a good option either, since previous MLAs may have
specified attributes in it (e.g. lists of additional signed receipt recipients).
Should the MLA refuse to process the message?

4.2.3.1 Processing for EnvelopedData

Q.  When re-encrypting a message (or its content-encryption key), why does the
MLA list itself as the message originator?  This allows anyone with access to
the MLA's private key (e.g. the MLA's administrator) to decrypt any message it
has ever processed.  Also, the original sender can no longer decrypt copies of
the message that were routed.  If the original encrypted data is instead
retained, and the content encryption key (CEK) is extracted (using the MLA's
private key) and encrypted once for each recipient, the originator's copy of the
CEK could be left unchanged.  Once processing is finished, the MLA would no
longer have access to the plaintext.  If message archiving is required, the MLA
could save a copy of the message in an archive, encrypting the CEK for any
desired profile, not necessarily its own.

   If it were not for the need to search for a security label, this approach
would avoid the need for the MLA to extract the plaintext of the message at all,
and it would only require the (much smaller) CEK briefly.  The MLA would not
even need to know the algorithm used to encrypt the message, merely its OID and
parameters.

4.2.3.2 Processing for SignedData

Q.  Step 2 of this process has been changed from the Internet draft version
(draft-ietf-smime-ess-09.txt).  It seems that now if the "outer" signed data
layer is absent or does not contain an mlExpansionHistory attribute, the MLA
simply adds a new outer signed layer, lists itself in the mlExpansionHistory
attribute, and sends the message to the recipients.  It would no longer expand
any encrypted data for the recipients.  If someone sent a message that was
encrypted then signed to the MLA, the recipients would not be able to decrypt
it.  Have I misread this paragraph?

5. Signing Certificate Attribute

Q.  How does the signingCertificate attribute enhance the security of the
message?

   The signingCertificate attribute is signed.  Therefore, before a receiving
agent should trust its value, it must verify the signature.  To verify the
signature, it must locate the signer's certificate and those of all issuers in a
chain until it finds a trusted root certificate.  As the receiving agent has
already located the certificates required to verify the signature, of what use
is the signingCertificate attribute?  This is a Catch-22 situation, since the
required information is only of use when it is unavailable.

   Using the signingCertificate to identify authorization certificates is no
better.  If the signature on the attribute is not trusted, then the policy also
cannot be trusted and should be ignored.  If the signature on the attribute has
been verified, and the authorization policy indicates that the signature is not
to be trusted under current circumstances, the policy has already been violated.
In fact, the signature should not be trusted to identify the policy that
indicates that the signature should not be trusted, and again the policy should
be ignored.  This is also a Catch-22 situation.

   An attacker attempting one of the attacks mentioned in this section could
replace both the signingCertificate attribute and the certificate, signing the
attribute with the new certificate.  The recipient would have no way of
detecting this, and may be lulled into a false sense of security by the presence
of the (substituted) signingCertificate attribute.

   The only use I can see for this attribute would be in a case where the
signature is intended to be used for (as an example) data integrity but not
non-repudiation (e.g. a server securing data in transit).  In this case, an
attribute certificate might identify the usage intended, and the
signingCertificate attribute could identify the attribute certificate.  This
could be achieved more simply either by including the signing certificate's
intended uses in the certificate itself, or by a statement (or disclaimer)
placed in the signed message itself by the sender stating the intended use of
the signature (e.g. "I am signing this message for data integrity purposes.  I
do not warrant that the information it contains is accurate.").

5.4 Signing Certificate Attribute Definition

Q.  SigningCertificate is a signed attribute.  An MLA processing a message is
supposed to copy the values of all the signed attributes in the outer signature
layer when applying or replacing a signature layer.  Shouldn't the
signingCertificate attribute be omitted from this?  It would refer to the
previous MLA's certificate, not the current MLA's.  Also, an MLA may require the
signingCertificate attribute for its own signature, and (since there can be only
one signingCertificate attribute in the signerInfo) would not be able to include
its own if it copied the previous MLA's signingCertificate attribute.

5.4.1 Certificate Identification

Q.  Why must SHA-1 be used for generating the hash value of the certificate?
Some agents may only process other algorithms (e.g. MD5).  Also, someone may
develop other (possibly superior) hash algorithms in the future, which might
become the new required standard.  Why isn't there a field in the ESSCertID to
identify the algorithm used?




From owner-ietf-smime@mail.imc.org  Fri Sep 29 16:12:54 2000
Received: from ns.secondary.com (ns.secondary.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA06472
	for <smime-archive@odin.ietf.org>; Fri, 29 Sep 2000 16:12:54 -0400 (EDT)
Received: (from majordomo@localhost)
	by ns.secondary.com (8.9.3/8.9.3) id LAA04746
	for ietf-smime-bks; Fri, 29 Sep 2000 11:48:22 -0700 (PDT)
Received: from wfhqex05.gfgsi.com (netva01.wangfed.com [206.137.100.2])
	by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA04742
	for <ietf-smime@imc.org>; Fri, 29 Sep 2000 11:48:19 -0700 (PDT)
Received: by wfhqex05.gfgsi.com with Internet Mail Service (5.5.2650.21)
	id <TRNYW29K>; Fri, 29 Sep 2000 14:53:34 -0400
Message-ID: <4B0D36365AD3D2118FF40060972A16C0019B1553@wfhqex01.wangfed.com>
From: "Pawling, John" <John.Pawling@wang.com>
To: ietf-smime@imc.org
Subject: RE: ESS Questions
Date: Fri, 29 Sep 2000 14:51:24 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-1"
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>

Please see my comments embedded below.

=====================================
John Pawling, john.pawling@wang.com
Getronics Government Solutions, LLC
=====================================


-----Original Message-----
From: mkicksee@aepos.adga.ca [mailto:mkicksee@aepos.adga.ca]
Sent: Friday, September 29, 2000 11:50 AM
To: ietf-smime@imc.org
Subject: ESS Questions




   I have carefully and meticulously read through RFC2634 (Enhanced Security
Services for S/MIME), and have questions about various sections of it.  Any
insight into these issues would be greatly appreciated.


3.4.2 Processing Equivalent Labels

Q.  If an organization has a security policy that maps another
organization's
security labels to its own, and also trusts a message sender to specify
equivalent security labels, and the two disagree (e.g. A sender applies
Acme's
"Confidential" label and claims that this is equivalent to Widgets'
"Private",
but Widgets' security policy states that Acme's "Confidential" is equivalent
to
Widgets' "Secret"), which label should the receiving agent (or MLA) at
Widgets
use for access control?  Should the more restrictive of the two be applied?

[JSP: Section 3.4.2 states: "A receiving agent SHOULD process the
ESSSecurityLabel before   processing any EquivalentLabels. If the policy in
the ESSSecurityLabel is understood by the receiving agent, it MUST process
that label and MUST ignore all EquivalentLabels."]


4.1 Mail List Expansion

Q.    A mail list agent must add its own mlData record to the
mlExpansionHistory
attribute in the outer signed layer of the message, creating the
mlExpansionHistory attribute (and possibly the signed layer that contains
it) as
needed.  It must also check that all the mlExpansionHistory attributes that
it
can verify are identical.

   What happens if an MLA can't verify a particular signerInfo because it
uses
an unknown algorithm? 

[JSP: Section 4.1. states: "A recipient MUST verify the signature of the
SignerInfo which covers   the mlExpansionHistory attribute before processing
the mlExpansionHistory, and MUST NOT process the mlExpansionHistory
attribute unless the signature over it has been verified."]  


It cannot modify the mlExpansionHistory attribute in the
signerInfo, since it A) cannot trust it, and B) cannot generate the new
signature for it using the same algorithm.  If it only modifies the
signerInfos
that it can sign, they no longer match, and the next MLA that can verify all
the
signerInfos will (correctly) reject the message, since the
mlExpansionHistory
attributes won't match.  The only solution would be to drop the signerInfo
that
the MLA cannot verify, despite the fact that it may be valid.

[JSP: This is subject to debate.  I believe that the MLA should add a new
signerInfo including its mlExpansionHistory attribute and should preserve
the signerInfos that it can't verify.  If the MLA omits the signerInfos that
it can't verify from the new signedData object, then that could cause mail
list expansion loops.  For example, if an RSA-only MLA sends a message to a
DSA-only MLA which is expanding a mail list that includes the original
RSA-only MLA.]


Q.  How should a mail list agent process a message if the only signerInfo in
the
outer layer is signed using an unknown algorithm?  Since it cannot verify
the
signerInfo, it should not process or expand its mlExpansionHistory list.  It
should not add an additional outer signature layer, since its attributes
would
not include those of the previous outer layer.  Replacing the existing
(possibly
valid) signerInfo is not a good option either, since previous MLAs may have
specified attributes in it (e.g. lists of additional signed receipt
recipients).
Should the MLA refuse to process the message?

[JSP: Same answer as above.]


4.2.3.1 Processing for EnvelopedData

Q.  When re-encrypting a message (or its content-encryption key), why does
the
MLA list itself as the message originator? 

[JSP: The MLA includes itself as the originator to support the use of key
agreement algorithms (such as static-static Diffie-Hellman or Key Exchange
Algorithm (KEA)) that require the originator's public key material to
generate the key encryption key.]


This allows anyone with access to
the MLA's private key (e.g. the MLA's administrator) to decrypt any message
it
has ever processed.  

[JSP: The fact that the original sender sent the encrypted message to the
MLA allows anyone with access to the MLA's private key to decrypt the
message.]


Also, the original sender can no longer decrypt copies of
the message that were routed. 

[JSP: IF the original sender is part of the expanded mail list, then she
will receive a copy that she can decrypt.]


If the original encrypted data is instead
retained, and the content encryption key (CEK) is extracted (using the MLA's
private key) and encrypted once for each recipient, the originator's copy of
the
CEK could be left unchanged.  

[JSP:  RFC 2634 already specifies that the original encrypted data must be
retained.  If the original sender needs to decrypt the message sent by the
MLA, then the original sender should be included in the mail list, then she
will receive a copy that she can decrypt.]


Once processing is finished, the MLA would no
longer have access to the plaintext.  If message archiving is required, the
MLA
could save a copy of the message in an archive, encrypting the CEK for any
desired profile, not necessarily its own.

[JSP: The MLA must be trusted.  It has access to the key material required
to decrypt every encrypted message that is sent to it.]

<snip>


4.2.3.2 Processing for SignedData

Q.  Step 2 of this process has been changed from the Internet draft version
(draft-ietf-smime-ess-09.txt).  It seems that now if the "outer" signed data
layer is absent or does not contain an mlExpansionHistory attribute, the MLA
simply adds a new outer signed layer, lists itself in the mlExpansionHistory
attribute, and sends the message to the recipients.  It would no longer
expand
any encrypted data for the recipients.  If someone sent a message that was
encrypted then signed to the MLA, the recipients would not be able to
decrypt
it.  Have I misread this paragraph?

[JSP: You have misinterpreted the paragraph.]


5. Signing Certificate Attribute

Q.  How does the signingCertificate attribute enhance the security of the
message?

[JSP: It can be used to indicate other certificates such as attribute
certificates or public key certificates that include additional information
(such as the sender's Clearance attribute) needed to process the message.] 

<snip>
 
An attacker attempting one of the attacks mentioned in this section could
replace both the signingCertificate attribute and the certificate, signing
the
attribute with the new certificate.  The recipient would have no way of
detecting this, and may be lulled into a false sense of security by the
presence
of the (substituted) signingCertificate attribute.

[JSP: If the signingCertificate signed attribute is modified, then the
verification of the signature included in the signerInfo will fail.]

<snip>

5.4 Signing Certificate Attribute Definition

Q.  SigningCertificate is a signed attribute.  An MLA processing a message
is
supposed to copy the values of all the signed attributes in the outer
signature
layer when applying or replacing a signature layer.  Shouldn't the
signingCertificate attribute be omitted from this?  It would refer to the
previous MLA's certificate, not the current MLA's.  Also, an MLA may require
the
signingCertificate attribute for its own signature, and (since there can be
only
one signingCertificate attribute in the signerInfo) would not be able to
include
its own if it copied the previous MLA's signingCertificate attribute.

[JSP:  I agree that the MLA should omit or replace the SigningCertificate
signed attribute in the signerInfo that it signs.]

<snip>


From owner-ietf-smime@mail.imc.org  Sat Sep 30 08:15:32 2000
Received: from ns.secondary.com (ns.secondary.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA27909
	for <smime-archive@odin.ietf.org>; Sat, 30 Sep 2000 08:15:31 -0400 (EDT)
Received: (from majordomo@localhost)
	by ns.secondary.com (8.9.3/8.9.3) id EAA27989
	for ietf-smime-bks; Sat, 30 Sep 2000 04:23:26 -0700 (PDT)
Received: from tlc.trustair.com.tw (tlc.trustair.com.tw [210.66.110.2])
	by ns.secondary.com (8.9.3/8.9.3) with ESMTP id EAA27985
	for <ietf-smime@mail.proper.com>; Sat, 30 Sep 2000 04:23:19 -0700 (PDT)
Message-Id: <200009301123.EAA27985@ns.secondary.com>
Received: from host (sdn-ar-001riprovp305.dialsprint.net [168.191.126.171]) by tlc.trustair.com.tw with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2448.0)
	id T70RL8NH; Sat, 30 Sep 2000 19:18:02 +0800
From: "Harry Owen" <gm25k@parsmail.com>
Subject: VIP List #538B
To: join393k@ns.secondary.com
X-Mailer: Microsoft Outlook Express 4.72.1712.3
X-MimeOLE: Produced By Microsoft MimeOLE VÐßD.1712.3
Mime-Version: 1.0
Date: Sat, 30 Sep 2000 07:12:20 -0500
Content-Type: multipart/mixed; boundary="----=_NextPart_000_007F_01BDF6C7.FABAC1B0"
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>

This is a MIME Message

------=_NextPart_000_007F_01BDF6C7.FABAC1B0
Content-Type: multipart/alternative; boundary="----=_NextPart_001_0080_01BDF6C7.FABAC1B0"

------=_NextPart_001_0080_01BDF6C7.FABAC1B0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

***** This is an HTML Message ! *****


------=_NextPart_001_0080_01BDF6C7.FABAC1B0
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!doctype html public "-//w3c//dtd html 4=2E0
 transitional//en">
 <html>
 <head>
    
    <title>Executive Guild Membership
 ApplicationResponse-O-Matic Form</title>
 </head>
 <body text=3D"#808080" bgcolor=3D"#FFCC99"
 link=3D"#800040" vlink=3D"#FF0000" alink=3D"#8080C0">
 <p><font color=3D"#000000">Dear Professional,<br>
 <br>
 You have been selected as a potential candidate for a free<br>
 listing in the 2000 - 2001 Edition of the International Executive<br>
 Guild Registry=2E<br>
 <br>
 Please accept our congratulations for this coveted honor=2E<br>
 <br>
 As this edition is so important in view of the new millennium, the<br>
 International Executive Guild Registry will be published in two<br>
 different formats; the searchable CD-ROM and the Online Registry=2E<br>
 <br>
 Since inclusion can be considered recognition of your career position<br>=

 and professionalism, each candidate is evaluated in keeping with high<br>=

 standards of individual achievement=2E In light of this, the Internationa=
l<br>
 Executive Guild thinks that you may make an interesting biographical<br>
 subject=2E<br>
 <br>
 We look forward to your inclusion and appearance in the International<br>=

 Executive Guild's Registry=2E Best wishes for your continued success=2E<b=
r>
 <br>
 International Executive Guild<br>
 Listing Dept=2E<br>
 <br>
 </font></p>
 <p>
 <hr WIDTH=3D"100%">
 <p align=3D"center"><b><i><font color=3D"#000000">If you
 wish to be removed from our list, please submit
 your request</font></i></b>
 <br><b><i><font face=3D"Times New
 Roman,Times"><font color=3D"#000000">at the
 bottom of this email=2E</font></font></i></b>
 </p>
 <hr WIDTH=3D"100%">
 <table WIDTH=3D"695" >
 <caption><script language=3D"JavaScript">
 
 <!--
 function validate_form() {
   validity =3D true; // assume valid
   if (!check_empty(document=2Eform=2Ebusphone=2Evalue))
         { validity =3D false; alert('Day Time
 Phone field is empty!'); }
     if (validity)
         alert ("Thank you for your registration!
 "
                 + "Your form is now being passed
 to your browser's "
                 + "Mail Delivery Sub-System for
 NORMAL"
                 + " NON-ENCRYPTED email
 delivery=2E"
                 + "  All email addresses are
 removed from our system"
                 + " upon registration=2E  Please
 click OK to proceed");
   return validity;
 }

 function check_empty(text) {
   return (text=2Elength > 0); // returns false if
 empty
 }
 
 // -->
 
 </script>
 
 
 <!-- CHANGE EMAIL ADDRESS IN ACTION OF FORM -->
 
 <form name=3D"form"
  method=3D"post"
  action=3D"mailto:kapwx@ukmax=2Ecom?SUBJECT=3DInternet Lead"
  enctype=3D"text/plain"
  onSubmit=3D"return validate_form()"></caption>
 
 <tr>
 <td></td>
 </tr>
 
 <tr>
 <td VALIGN=3DTOP COLSPAN=3D"2">
 <center><b><i><font color=3D"#000000"><font
 size=3D+3>International Executive Guild</font></font></i></b>
 <br><b><font color=3D"#000000"><font
 size=3D+2>Registration Form</font></font></b>
 <br><b><font color=3D"#000000">(US and Canada
 Only)</font></b>
 <br>
 <hr WIDTH=3D"100%"></center>
 </td>
 </tr>
 
 <tr>
 <td VALIGN=3DTOP COLSPAN=3D"2"><i><font
 face=3D"arial,helvetica"><font
 color=3D"#000000"><font size=3D+0>Please
 fill out this form if you would like to be
 included on The International
 Executive Guild, For accuracy and
 publication purposes, please
 complete and send this form at the earliest
 opportunity=2E There is </font>no
 charge or obligation<font size=3D+0> to be listed
 on The International Executive Guild=2E</font></font></font></i>
 <br>
 <hr WIDTH=3D"100%"></td>
 </tr>
 
 <tr>
 <td VALIGN=3DTOP></td>
 </tr>
 
 <tr>
 <td ALIGN=3DRIGHT WIDTH=3D"300"><b><font
 face=3D"arial,helvetica"><font
 color=3D"#000000"><font size=3D-1>Your
 Name</font></font></font></b></td>
 
 <td ALIGN=3DLEFT WIDTH=3D"300"><input type=3D"text"
 value size=3D"50" maxlength=3D"250" name=3D"Name"></td>
 </tr>
 
 <tr>
 <td ALIGN=3DRIGHT WIDTH=3D"300"><b><font
 face=3D"arial,helvetica"><font
 color=3D"#000000"><font size=3D-1>Your
 Company</font></font></font></b></td>
 
 <td ALIGN=3DLEFT WIDTH=3D"300"><input type=3D"text"
 value size=3D"50" maxlength=3D"250"
 name=3D"Company"></td>
 </tr>
 
 <tr>
 <td ALIGN=3DRIGHT WIDTH=3D"300"><b><font
 face=3D"arial,helvetica"><font
 color=3D"#000000"><font size=3D-
 1>Title</font></font></font></b></td>
 
 <td ALIGN=3DLEFT WIDTH=3D"300"><input type=3D"text"
 value size=3D"50" maxlength=3D"250"
 name=3D"Title"></td>
 </tr>
 
 <tr>
 <td ALIGN=3DRIGHT WIDTH=3D"300"><b><font
 face=3D"arial,helvetica"><font
 color=3D"#000000"><font size=3D-
 1>Address</font></font></font></b></td>
 
 <td ALIGN=3DLEFT WIDTH=3D"300"><input type=3D"text"
 value size=3D"50" maxlength=3D"250"
 name=3D"Address"></td>
 </tr>
 
 <tr>
 <td ALIGN=3DRIGHT WIDTH=3D"300"><b><font
 face=3D"arial,helvetica"><font
 color=3D"#000000"><font size=3D-
 1>City</font></font></font></b></td>
 
 <td ALIGN=3DLEFT WIDTH=3D"300"><input type=3D"text"
 value size=3D"50" maxlength=3D"250" name=3D"City"></td>
 </tr>
 
 <tr>
 <td ALIGN=3DRIGHT WIDTH=3D"300"><b><font
 face=3D"arial,helvetica"><font
 color=3D"#000000"><font size=3D-1>State
 or Province</font></font></font></b></td>
 
 <td ALIGN=3DLEFT WIDTH=3D"300"><input type=3D"text"
 value size=3D"12" maxlength=3D"50" name=3D"State"></td>
 </tr>
 
 <tr>
 <td ALIGN=3DRIGHT WIDTH=3D"300"><b><font
 face=3D"arial,helvetica"><font
 color=3D"#000000"><font size=3D-
 1>Country</font></font></font></b></td>
 
 <td ALIGN=3DLEFT WIDTH=3D"300"><select
 NAME=3D"Country" Size=3D"1"><option SELECTED><font
 color=3D"#000000">USA<option
 SELECTED>Canada</font></select></td>
 </tr>
 
 <tr>
 <td ALIGN=3DRIGHT WIDTH=3D"300"><b><font
 face=3D"arial,helvetica"><font
 color=3D"#000000"><font size=3D-1>ZIP/Postal
 Code</font></font></font></b></td>
 
 <td ALIGN=3DLEFT VALIGN=3DCENTER WIDTH=3D"300"><input
 type=3D"text" value size=3D"12" maxlength=3D"50"
 name=3D"Zip"></td>
 </tr>
 
 <tr>
 <td ALIGN=3DRIGHT WIDTH=3D"300"><b><font
 face=3D"arial,helvetica"><font
 color=3D"#000000"><font size=3D-1>Day
 Time Telephone</font></font></font></b></td>
 
 <td ALIGN=3DLEFT WIDTH=3D"300"><input type=3D"text"
 value size=3D"22" maxlength=3D"50"
 name=3D"busphone"></td>
 </tr>
 
 <tr>
 <td>
 <div align=3Dright><b><font
 face=3D"Arial,Helvetica"><font
 color=3D"#000000"><font size=3D-1>Home
 Phone</font></font></font></b></div>
 </td>
 
 <td><input type=3D"text" value size=3D"22"
 maxlength=3D"50" name=3D"homephone"><b><font
 color=3D"#000000"><font size=3D-2>(Not
 To Be Published)</font></font></b></td>
 </tr>
 
 <tr>
 <td>
 <div align=3Dright><b><font
 face=3D"Arial,Helvetica"><font
 color=3D"#000000"><font size=3D-
 1>Email</font></font></font></b></div>
 </td>
 
 <td><input type=3D"text" value size=3D"50"
 maxlength=3D"100" name=3D"Email"></td>
 </tr>
 
 <tr>
 <td></td>
 
 <td></td>
 </tr>
 </table>
 
 <center>
 <p>
 <hr WIDTH=3D"100%"><b><font
 face=3D"ARIAL,HELVETICA"><font
 color=3D"#000000"><font size=3D-1>TO
 HELP US IN CONSIDERING YOUR APPLICATION, PLEASE
 TELL US A LITTLE ABOUT
 YOURSELF=2E=2E=2E</font></font></font></b>
 <br>
 <hr WIDTH=3D"100%"></center>
 
 <center><table WIDTH=3D"81%" >
 <tr>
 <td ALIGN=3DRIGHT VALIGN=3DTOP WIDTH=3D"300"><b><font
 face=3D"arial,helvetica"><font
 color=3D"#000000"><font size=3D-1>Your
 Business</font></font></font></b></td>
 
 <td>
 <div align=3Dright><input type=3D"text" value
 size=3D"50" maxlength=3D"200"
 name=3D"business"></div>
 <font face=3D"arial,helvetica"><font color=3D"#000000"><font
 size=3D-1>(Financial
 Svcs, Banking, Computer Hardware, Software, Professional Svcs,
 Chemicals,
 Apparel, Aerospace, Food, Government, Utility,
 etc=2E)</font></font></font></td>
 </tr>
 
 <tr>
 <td ALIGN=3DRIGHT VALIGN=3DTOP WIDTH=3D"300"><b><font
 face=3D"arial,helvetica"><font
 color=3D"#000000"><font size=3D-1>Type
 of Organization</font></font></font></b></td>
 
 <td>
 <div align=3Dright><input type=3D"text" value size=3D"50" maxlength=3D"25=
0"
 name=3D"Orgtype"></div>
 <font face=3D"arial,helvetica"><font color=3D"#000000"><font size=3D-1>(M=
fg,
 Dist/Wholesaler, Retailer, Law Firm,</font></font></font>
 <br><font face=3D"arial,helvetica"><font color=3D"#000000"><font
 size=3D-1>Investment
 Bank, Commercial Bank, University,</font></font></font>
 <br><font face=3D"arial,helvetica"><font color=3D"#000000"><font
 size=3D-1>Financial
 Consultants, Ad Agency, Contractor, Broker,
 etc=2E)</font></font></font></td>
 </tr>
 
 <tr>
 <td VALIGN=3DTOP WIDTH=3D"300">
 <div align=3Dright><b><font face=3D"arial,helvetica"><font
 color=3D"#000000"><font
 size=3D-1>Your
 Business Expertise</font></font></font></b></div>
 </td>
 
 <td>
 <div align=3Dright><input type=3D"text" value size=3D"50" maxlength=3D"25=
0"
 name=3D"expertise"></div>
 <font face=3D"arial,helvetica"><font color=3D"#000000"><font
 size=3D-1>(Corp=2EMgmt,
 Marketing, Civil Engineering,</font></font></font>
 <br><font face=3D"arial,helvetica"><font color=3D"#000000"><font size=3D-=
1>Tax
 
 Law, Nuclear Physics, Database Development, Operations, Pathologist,
 Mortgage
 Banking, etc=2E)</font></font></font></td>
 </tr>
 
 <tr>
 <td ALIGN=3DRIGHT VALIGN=3DTOP WIDTH=3D"300"><b><font
 face=3D"arial,helvetica"><font
 color=3D"#000000"><font size=3D-1>Major
 Product Line</font></font></font></b></td>

 <td>
 <div align=3Dright><input type=3D"text" value size=3D"50" maxlength=3D"25=
0"
 name=3D"product"></div>
 <font face=3D"arial,helvetica"><font color=3D"#000000"><font
 size=3D-1>(Integrated
 Circuits, Commercial Aircraft, Adhesives, Cosmetics, Plastic Components,
 
 Snack Foods, etc=2E)</font></font></font></td>
 </tr>
 </table></center>
 
 <center>
 <p><input NAME=3D"submit" TYPE=3D"submit" VALUE=3D" Submit By E-Mail "><i=
nput
 NAME=3D"reset" TYPE=3D"reset" VALUE=3D" Clear Form "></form>
 <br><b><font color=3D"#000000"><font size=3D-1>Note: Submitting this form=

 will
 be made by email, not by use of&nbsp; www=2E&nbsp; Confirmation of its de=
livery
 is made by browsing your outgoing mail=2E</font></font></b>
 <br>
 <hr WIDTH=3D"100%"><b><i><font face=3D"arial,helvetica"><font
 color=3D"#000000"><font
 size=3D-1>Thank
 you for filling in this form, we will contact you with more
 information=2E</font></font></font></i></b>
 <br>
 <hr WIDTH=3D"100%">
 <br><b><font size=3D+1>List
 Removal</font></b>
 <br><b><font color=3D"#000000"><font size=3D-1><a
 href=3D"mailto:kmpt@educastmail=2Ecom?subject=3Dremove">Click
 Here</a></font></font></b></center>
 
 </body>
 </html>

------=_NextPart_001_0080_01BDF6C7.FABAC1B0--

------=_NextPart_000_007F_01BDF6C7.FABAC1B0--






Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id EAA27989 for ietf-smime-bks; Sat, 30 Sep 2000 04:23:26 -0700 (PDT)
Received: from tlc.trustair.com.tw (tlc.trustair.com.tw [210.66.110.2]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id EAA27985 for <ietf-smime@mail.proper.com>; Sat, 30 Sep 2000 04:23:19 -0700 (PDT)
Message-Id: <200009301123.EAA27985@ns.secondary.com>
Received: from host (sdn-ar-001riprovp305.dialsprint.net [168.191.126.171]) by tlc.trustair.com.tw with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2448.0) id T70RL8NH; Sat, 30 Sep 2000 19:18:02 +0800
From: "Harry Owen" <gm25k@parsmail.com>
Subject: VIP List #538B
To: join393k
X-Mailer: Microsoft Outlook Express 4.72.1712.3
X-MimeOLE: Produced By Microsoft MimeOLE VÐßD.1712.3
Mime-Version: 1.0
Date: Sat, 30 Sep 2000 07:12:20 -0500
Content-Type: multipart/mixed; boundary="----=_NextPart_000_007F_01BDF6C7.FABAC1B0"
Content-Transfer-Encoding: 7bit
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>

This is a MIME Message

------=_NextPart_000_007F_01BDF6C7.FABAC1B0
Content-Type: multipart/alternative; boundary="----=_NextPart_001_0080_01BDF6C7.FABAC1B0"

------=_NextPart_001_0080_01BDF6C7.FABAC1B0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

***** This is an HTML Message ! *****


------=_NextPart_001_0080_01BDF6C7.FABAC1B0
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!doctype html public "-//w3c//dtd html 4=2E0
 transitional//en">
 <html>
 <head>
    
    <title>Executive Guild Membership
 ApplicationResponse-O-Matic Form</title>
 </head>
 <body text=3D"#808080" bgcolor=3D"#FFCC99"
 link=3D"#800040" vlink=3D"#FF0000" alink=3D"#8080C0">
 <p><font color=3D"#000000">Dear Professional,<br>
 <br>
 You have been selected as a potential candidate for a free<br>
 listing in the 2000 - 2001 Edition of the International Executive<br>
 Guild Registry=2E<br>
 <br>
 Please accept our congratulations for this coveted honor=2E<br>
 <br>
 As this edition is so important in view of the new millennium, the<br>
 International Executive Guild Registry will be published in two<br>
 different formats; the searchable CD-ROM and the Online Registry=2E<br>
 <br>
 Since inclusion can be considered recognition of your career position<br>=

 and professionalism, each candidate is evaluated in keeping with high<br>=

 standards of individual achievement=2E In light of this, the Internationa=
l<br>
 Executive Guild thinks that you may make an interesting biographical<br>
 subject=2E<br>
 <br>
 We look forward to your inclusion and appearance in the International<br>=

 Executive Guild's Registry=2E Best wishes for your continued success=2E<b=
r>
 <br>
 International Executive Guild<br>
 Listing Dept=2E<br>
 <br>
 </font></p>
 <p>
 <hr WIDTH=3D"100%">
 <p align=3D"center"><b><i><font color=3D"#000000">If you
 wish to be removed from our list, please submit
 your request</font></i></b>
 <br><b><i><font face=3D"Times New
 Roman,Times"><font color=3D"#000000">at the
 bottom of this email=2E</font></font></i></b>
 </p>
 <hr WIDTH=3D"100%">
 <table WIDTH=3D"695" >
 <caption><script language=3D"JavaScript">
 
 <!--
 function validate_form() {
   validity =3D true; // assume valid
   if (!check_empty(document=2Eform=2Ebusphone=2Evalue))
         { validity =3D false; alert('Day Time
 Phone field is empty!'); }
     if (validity)
         alert ("Thank you for your registration!
 "
                 + "Your form is now being passed
 to your browser's "
                 + "Mail Delivery Sub-System for
 NORMAL"
                 + " NON-ENCRYPTED email
 delivery=2E"
                 + "  All email addresses are
 removed from our system"
                 + " upon registration=2E  Please
 click OK to proceed");
   return validity;
 }

 function check_empty(text) {
   return (text=2Elength > 0); // returns false if
 empty
 }
 
 // -->
 
 </script>
 
 
 <!-- CHANGE EMAIL ADDRESS IN ACTION OF FORM -->
 
 <form name=3D"form"
  method=3D"post"
  action=3D"mailto:kapwx@ukmax=2Ecom?SUBJECT=3DInternet Lead"
  enctype=3D"text/plain"
  onSubmit=3D"return validate_form()"></caption>
 
 <tr>
 <td></td>
 </tr>
 
 <tr>
 <td VALIGN=3DTOP COLSPAN=3D"2">
 <center><b><i><font color=3D"#000000"><font
 size=3D+3>International Executive Guild</font></font></i></b>
 <br><b><font color=3D"#000000"><font
 size=3D+2>Registration Form</font></font></b>
 <br><b><font color=3D"#000000">(US and Canada
 Only)</font></b>
 <br>
 <hr WIDTH=3D"100%"></center>
 </td>
 </tr>
 
 <tr>
 <td VALIGN=3DTOP COLSPAN=3D"2"><i><font
 face=3D"arial,helvetica"><font
 color=3D"#000000"><font size=3D+0>Please
 fill out this form if you would like to be
 included on The International
 Executive Guild, For accuracy and
 publication purposes, please
 complete and send this form at the earliest
 opportunity=2E There is </font>no
 charge or obligation<font size=3D+0> to be listed
 on The International Executive Guild=2E</font></font></font></i>
 <br>
 <hr WIDTH=3D"100%"></td>
 </tr>
 
 <tr>
 <td VALIGN=3DTOP></td>
 </tr>
 
 <tr>
 <td ALIGN=3DRIGHT WIDTH=3D"300"><b><font
 face=3D"arial,helvetica"><font
 color=3D"#000000"><font size=3D-1>Your
 Name</font></font></font></b></td>
 
 <td ALIGN=3DLEFT WIDTH=3D"300"><input type=3D"text"
 value size=3D"50" maxlength=3D"250" name=3D"Name"></td>
 </tr>
 
 <tr>
 <td ALIGN=3DRIGHT WIDTH=3D"300"><b><font
 face=3D"arial,helvetica"><font
 color=3D"#000000"><font size=3D-1>Your
 Company</font></font></font></b></td>
 
 <td ALIGN=3DLEFT WIDTH=3D"300"><input type=3D"text"
 value size=3D"50" maxlength=3D"250"
 name=3D"Company"></td>
 </tr>
 
 <tr>
 <td ALIGN=3DRIGHT WIDTH=3D"300"><b><font
 face=3D"arial,helvetica"><font
 color=3D"#000000"><font size=3D-
 1>Title</font></font></font></b></td>
 
 <td ALIGN=3DLEFT WIDTH=3D"300"><input type=3D"text"
 value size=3D"50" maxlength=3D"250"
 name=3D"Title"></td>
 </tr>
 
 <tr>
 <td ALIGN=3DRIGHT WIDTH=3D"300"><b><font
 face=3D"arial,helvetica"><font
 color=3D"#000000"><font size=3D-
 1>Address</font></font></font></b></td>
 
 <td ALIGN=3DLEFT WIDTH=3D"300"><input type=3D"text"
 value size=3D"50" maxlength=3D"250"
 name=3D"Address"></td>
 </tr>
 
 <tr>
 <td ALIGN=3DRIGHT WIDTH=3D"300"><b><font
 face=3D"arial,helvetica"><font
 color=3D"#000000"><font size=3D-
 1>City</font></font></font></b></td>
 
 <td ALIGN=3DLEFT WIDTH=3D"300"><input type=3D"text"
 value size=3D"50" maxlength=3D"250" name=3D"City"></td>
 </tr>
 
 <tr>
 <td ALIGN=3DRIGHT WIDTH=3D"300"><b><font
 face=3D"arial,helvetica"><font
 color=3D"#000000"><font size=3D-1>State
 or Province</font></font></font></b></td>
 
 <td ALIGN=3DLEFT WIDTH=3D"300"><input type=3D"text"
 value size=3D"12" maxlength=3D"50" name=3D"State"></td>
 </tr>
 
 <tr>
 <td ALIGN=3DRIGHT WIDTH=3D"300"><b><font
 face=3D"arial,helvetica"><font
 color=3D"#000000"><font size=3D-
 1>Country</font></font></font></b></td>
 
 <td ALIGN=3DLEFT WIDTH=3D"300"><select
 NAME=3D"Country" Size=3D"1"><option SELECTED><font
 color=3D"#000000">USA<option
 SELECTED>Canada</font></select></td>
 </tr>
 
 <tr>
 <td ALIGN=3DRIGHT WIDTH=3D"300"><b><font
 face=3D"arial,helvetica"><font
 color=3D"#000000"><font size=3D-1>ZIP/Postal
 Code</font></font></font></b></td>
 
 <td ALIGN=3DLEFT VALIGN=3DCENTER WIDTH=3D"300"><input
 type=3D"text" value size=3D"12" maxlength=3D"50"
 name=3D"Zip"></td>
 </tr>
 
 <tr>
 <td ALIGN=3DRIGHT WIDTH=3D"300"><b><font
 face=3D"arial,helvetica"><font
 color=3D"#000000"><font size=3D-1>Day
 Time Telephone</font></font></font></b></td>
 
 <td ALIGN=3DLEFT WIDTH=3D"300"><input type=3D"text"
 value size=3D"22" maxlength=3D"50"
 name=3D"busphone"></td>
 </tr>
 
 <tr>
 <td>
 <div align=3Dright><b><font
 face=3D"Arial,Helvetica"><font
 color=3D"#000000"><font size=3D-1>Home
 Phone</font></font></font></b></div>
 </td>
 
 <td><input type=3D"text" value size=3D"22"
 maxlength=3D"50" name=3D"homephone"><b><font
 color=3D"#000000"><font size=3D-2>(Not
 To Be Published)</font></font></b></td>
 </tr>
 
 <tr>
 <td>
 <div align=3Dright><b><font
 face=3D"Arial,Helvetica"><font
 color=3D"#000000"><font size=3D-
 1>Email</font></font></font></b></div>
 </td>
 
 <td><input type=3D"text" value size=3D"50"
 maxlength=3D"100" name=3D"Email"></td>
 </tr>
 
 <tr>
 <td></td>
 
 <td></td>
 </tr>
 </table>
 
 <center>
 <p>
 <hr WIDTH=3D"100%"><b><font
 face=3D"ARIAL,HELVETICA"><font
 color=3D"#000000"><font size=3D-1>TO
 HELP US IN CONSIDERING YOUR APPLICATION, PLEASE
 TELL US A LITTLE ABOUT
 YOURSELF=2E=2E=2E</font></font></font></b>
 <br>
 <hr WIDTH=3D"100%"></center>
 
 <center><table WIDTH=3D"81%" >
 <tr>
 <td ALIGN=3DRIGHT VALIGN=3DTOP WIDTH=3D"300"><b><font
 face=3D"arial,helvetica"><font
 color=3D"#000000"><font size=3D-1>Your
 Business</font></font></font></b></td>
 
 <td>
 <div align=3Dright><input type=3D"text" value
 size=3D"50" maxlength=3D"200"
 name=3D"business"></div>
 <font face=3D"arial,helvetica"><font color=3D"#000000"><font
 size=3D-1>(Financial
 Svcs, Banking, Computer Hardware, Software, Professional Svcs,
 Chemicals,
 Apparel, Aerospace, Food, Government, Utility,
 etc=2E)</font></font></font></td>
 </tr>
 
 <tr>
 <td ALIGN=3DRIGHT VALIGN=3DTOP WIDTH=3D"300"><b><font
 face=3D"arial,helvetica"><font
 color=3D"#000000"><font size=3D-1>Type
 of Organization</font></font></font></b></td>
 
 <td>
 <div align=3Dright><input type=3D"text" value size=3D"50" maxlength=3D"25=
0"
 name=3D"Orgtype"></div>
 <font face=3D"arial,helvetica"><font color=3D"#000000"><font size=3D-1>(M=
fg,
 Dist/Wholesaler, Retailer, Law Firm,</font></font></font>
 <br><font face=3D"arial,helvetica"><font color=3D"#000000"><font
 size=3D-1>Investment
 Bank, Commercial Bank, University,</font></font></font>
 <br><font face=3D"arial,helvetica"><font color=3D"#000000"><font
 size=3D-1>Financial
 Consultants, Ad Agency, Contractor, Broker,
 etc=2E)</font></font></font></td>
 </tr>
 
 <tr>
 <td VALIGN=3DTOP WIDTH=3D"300">
 <div align=3Dright><b><font face=3D"arial,helvetica"><font
 color=3D"#000000"><font
 size=3D-1>Your
 Business Expertise</font></font></font></b></div>
 </td>
 
 <td>
 <div align=3Dright><input type=3D"text" value size=3D"50" maxlength=3D"25=
0"
 name=3D"expertise"></div>
 <font face=3D"arial,helvetica"><font color=3D"#000000"><font
 size=3D-1>(Corp=2EMgmt,
 Marketing, Civil Engineering,</font></font></font>
 <br><font face=3D"arial,helvetica"><font color=3D"#000000"><font size=3D-=
1>Tax
 
 Law, Nuclear Physics, Database Development, Operations, Pathologist,
 Mortgage
 Banking, etc=2E)</font></font></font></td>
 </tr>
 
 <tr>
 <td ALIGN=3DRIGHT VALIGN=3DTOP WIDTH=3D"300"><b><font
 face=3D"arial,helvetica"><font
 color=3D"#000000"><font size=3D-1>Major
 Product Line</font></font></font></b></td>

 <td>
 <div align=3Dright><input type=3D"text" value size=3D"50" maxlength=3D"25=
0"
 name=3D"product"></div>
 <font face=3D"arial,helvetica"><font color=3D"#000000"><font
 size=3D-1>(Integrated
 Circuits, Commercial Aircraft, Adhesives, Cosmetics, Plastic Components,
 
 Snack Foods, etc=2E)</font></font></font></td>
 </tr>
 </table></center>
 
 <center>
 <p><input NAME=3D"submit" TYPE=3D"submit" VALUE=3D" Submit By E-Mail "><i=
nput
 NAME=3D"reset" TYPE=3D"reset" VALUE=3D" Clear Form "></form>
 <br><b><font color=3D"#000000"><font size=3D-1>Note: Submitting this form=

 will
 be made by email, not by use of&nbsp; www=2E&nbsp; Confirmation of its de=
livery
 is made by browsing your outgoing mail=2E</font></font></b>
 <br>
 <hr WIDTH=3D"100%"><b><i><font face=3D"arial,helvetica"><font
 color=3D"#000000"><font
 size=3D-1>Thank
 you for filling in this form, we will contact you with more
 information=2E</font></font></font></i></b>
 <br>
 <hr WIDTH=3D"100%">
 <br><b><font size=3D+1>List
 Removal</font></b>
 <br><b><font color=3D"#000000"><font size=3D-1><a
 href=3D"mailto:kmpt@educastmail=2Ecom?subject=3Dremove">Click
 Here</a></font></font></b></center>
 
 </body>
 </html>

------=_NextPart_001_0080_01BDF6C7.FABAC1B0--

------=_NextPart_000_007F_01BDF6C7.FABAC1B0--





Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id LAA04746 for ietf-smime-bks; Fri, 29 Sep 2000 11:48:22 -0700 (PDT)
Received: from wfhqex05.gfgsi.com (netva01.wangfed.com [206.137.100.2]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA04742 for <ietf-smime@imc.org>; Fri, 29 Sep 2000 11:48:19 -0700 (PDT)
Received: by wfhqex05.gfgsi.com with Internet Mail Service (5.5.2650.21) id <TRNYW29K>; Fri, 29 Sep 2000 14:53:34 -0400
Message-ID: <4B0D36365AD3D2118FF40060972A16C0019B1553@wfhqex01.wangfed.com>
From: "Pawling, John" <John.Pawling@wang.com>
To: ietf-smime@imc.org
Subject: RE: ESS Questions
Date: Fri, 29 Sep 2000 14:51:24 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-1"
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>

Please see my comments embedded below.

=====================================
John Pawling, john.pawling@wang.com
Getronics Government Solutions, LLC
=====================================


-----Original Message-----
From: mkicksee@aepos.adga.ca [mailto:mkicksee@aepos.adga.ca]
Sent: Friday, September 29, 2000 11:50 AM
To: ietf-smime@imc.org
Subject: ESS Questions




   I have carefully and meticulously read through RFC2634 (Enhanced Security
Services for S/MIME), and have questions about various sections of it.  Any
insight into these issues would be greatly appreciated.


3.4.2 Processing Equivalent Labels

Q.  If an organization has a security policy that maps another
organization's
security labels to its own, and also trusts a message sender to specify
equivalent security labels, and the two disagree (e.g. A sender applies
Acme's
"Confidential" label and claims that this is equivalent to Widgets'
"Private",
but Widgets' security policy states that Acme's "Confidential" is equivalent
to
Widgets' "Secret"), which label should the receiving agent (or MLA) at
Widgets
use for access control?  Should the more restrictive of the two be applied?

[JSP: Section 3.4.2 states: "A receiving agent SHOULD process the
ESSSecurityLabel before   processing any EquivalentLabels. If the policy in
the ESSSecurityLabel is understood by the receiving agent, it MUST process
that label and MUST ignore all EquivalentLabels."]


4.1 Mail List Expansion

Q.    A mail list agent must add its own mlData record to the
mlExpansionHistory
attribute in the outer signed layer of the message, creating the
mlExpansionHistory attribute (and possibly the signed layer that contains
it) as
needed.  It must also check that all the mlExpansionHistory attributes that
it
can verify are identical.

   What happens if an MLA can't verify a particular signerInfo because it
uses
an unknown algorithm? 

[JSP: Section 4.1. states: "A recipient MUST verify the signature of the
SignerInfo which covers   the mlExpansionHistory attribute before processing
the mlExpansionHistory, and MUST NOT process the mlExpansionHistory
attribute unless the signature over it has been verified."]  


It cannot modify the mlExpansionHistory attribute in the
signerInfo, since it A) cannot trust it, and B) cannot generate the new
signature for it using the same algorithm.  If it only modifies the
signerInfos
that it can sign, they no longer match, and the next MLA that can verify all
the
signerInfos will (correctly) reject the message, since the
mlExpansionHistory
attributes won't match.  The only solution would be to drop the signerInfo
that
the MLA cannot verify, despite the fact that it may be valid.

[JSP: This is subject to debate.  I believe that the MLA should add a new
signerInfo including its mlExpansionHistory attribute and should preserve
the signerInfos that it can't verify.  If the MLA omits the signerInfos that
it can't verify from the new signedData object, then that could cause mail
list expansion loops.  For example, if an RSA-only MLA sends a message to a
DSA-only MLA which is expanding a mail list that includes the original
RSA-only MLA.]


Q.  How should a mail list agent process a message if the only signerInfo in
the
outer layer is signed using an unknown algorithm?  Since it cannot verify
the
signerInfo, it should not process or expand its mlExpansionHistory list.  It
should not add an additional outer signature layer, since its attributes
would
not include those of the previous outer layer.  Replacing the existing
(possibly
valid) signerInfo is not a good option either, since previous MLAs may have
specified attributes in it (e.g. lists of additional signed receipt
recipients).
Should the MLA refuse to process the message?

[JSP: Same answer as above.]


4.2.3.1 Processing for EnvelopedData

Q.  When re-encrypting a message (or its content-encryption key), why does
the
MLA list itself as the message originator? 

[JSP: The MLA includes itself as the originator to support the use of key
agreement algorithms (such as static-static Diffie-Hellman or Key Exchange
Algorithm (KEA)) that require the originator's public key material to
generate the key encryption key.]


This allows anyone with access to
the MLA's private key (e.g. the MLA's administrator) to decrypt any message
it
has ever processed.  

[JSP: The fact that the original sender sent the encrypted message to the
MLA allows anyone with access to the MLA's private key to decrypt the
message.]


Also, the original sender can no longer decrypt copies of
the message that were routed. 

[JSP: IF the original sender is part of the expanded mail list, then she
will receive a copy that she can decrypt.]


If the original encrypted data is instead
retained, and the content encryption key (CEK) is extracted (using the MLA's
private key) and encrypted once for each recipient, the originator's copy of
the
CEK could be left unchanged.  

[JSP:  RFC 2634 already specifies that the original encrypted data must be
retained.  If the original sender needs to decrypt the message sent by the
MLA, then the original sender should be included in the mail list, then she
will receive a copy that she can decrypt.]


Once processing is finished, the MLA would no
longer have access to the plaintext.  If message archiving is required, the
MLA
could save a copy of the message in an archive, encrypting the CEK for any
desired profile, not necessarily its own.

[JSP: The MLA must be trusted.  It has access to the key material required
to decrypt every encrypted message that is sent to it.]

<snip>


4.2.3.2 Processing for SignedData

Q.  Step 2 of this process has been changed from the Internet draft version
(draft-ietf-smime-ess-09.txt).  It seems that now if the "outer" signed data
layer is absent or does not contain an mlExpansionHistory attribute, the MLA
simply adds a new outer signed layer, lists itself in the mlExpansionHistory
attribute, and sends the message to the recipients.  It would no longer
expand
any encrypted data for the recipients.  If someone sent a message that was
encrypted then signed to the MLA, the recipients would not be able to
decrypt
it.  Have I misread this paragraph?

[JSP: You have misinterpreted the paragraph.]


5. Signing Certificate Attribute

Q.  How does the signingCertificate attribute enhance the security of the
message?

[JSP: It can be used to indicate other certificates such as attribute
certificates or public key certificates that include additional information
(such as the sender's Clearance attribute) needed to process the message.] 

<snip>
 
An attacker attempting one of the attacks mentioned in this section could
replace both the signingCertificate attribute and the certificate, signing
the
attribute with the new certificate.  The recipient would have no way of
detecting this, and may be lulled into a false sense of security by the
presence
of the (substituted) signingCertificate attribute.

[JSP: If the signingCertificate signed attribute is modified, then the
verification of the signature included in the signerInfo will fail.]

<snip>

5.4 Signing Certificate Attribute Definition

Q.  SigningCertificate is a signed attribute.  An MLA processing a message
is
supposed to copy the values of all the signed attributes in the outer
signature
layer when applying or replacing a signature layer.  Shouldn't the
signingCertificate attribute be omitted from this?  It would refer to the
previous MLA's certificate, not the current MLA's.  Also, an MLA may require
the
signingCertificate attribute for its own signature, and (since there can be
only
one signingCertificate attribute in the signerInfo) would not be able to
include
its own if it copied the previous MLA's signingCertificate attribute.

[JSP:  I agree that the MLA should omit or replace the SigningCertificate
signed attribute in the signerInfo that it signs.]

<snip>


Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id IAA01147 for ietf-smime-bks; Fri, 29 Sep 2000 08:44:54 -0700 (PDT)
Received: from aeposmail.aepos.com ([209.112.11.5]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id IAA01143 for <ietf-smime@imc.org>; Fri, 29 Sep 2000 08:44:52 -0700 (PDT)
From: mkicksee@aepos.adga.ca
Received: by aeposmail.aepos.com(Lotus SMTP MTA v4.6.4  (830.2 3-23-1999))  id 85256969.005A757B ; Fri, 29 Sep 2000 12:28:03 -0400
X-Lotus-FromDomain: AEPOS
To: ietf-smime@imc.org
Message-ID: <85256969.005A7423.00@aeposmail.aepos.com>
Date: Fri, 29 Sep 2000 11:50:13 -0400
Subject: ESS Questions
Mime-Version: 1.0
Content-type: text/plain; charset=us-ascii
Content-Disposition: inline
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>

   I have carefully and meticulously read through RFC2634 (Enhanced Security
Services for S/MIME), and have questions about various sections of it.  Any
insight into these issues would be greatly appreciated.


3.4.2 Processing Equivalent Labels

Q.  If an organization has a security policy that maps another organization's
security labels to its own, and also trusts a message sender to specify
equivalent security labels, and the two disagree (e.g. A sender applies Acme's
"Confidential" label and claims that this is equivalent to Widgets' "Private",
but Widgets' security policy states that Acme's "Confidential" is equivalent to
Widgets' "Secret"), which label should the receiving agent (or MLA) at Widgets
use for access control?  Should the more restrictive of the two be applied?

4.1 Mail List Expansion

Q.    A mail list agent must add its own mlData record to the mlExpansionHistory
attribute in the outer signed layer of the message, creating the
mlExpansionHistory attribute (and possibly the signed layer that contains it) as
needed.  It must also check that all the mlExpansionHistory attributes that it
can verify are identical.

   What happens if an MLA can't verify a particular signerInfo because it uses
an unknown algorithm?  It cannot modify the mlExpansionHistory attribute in the
signerInfo, since it A) cannot trust it, and B) cannot generate the new
signature for it using the same algorithm.  If it only modifies the signerInfos
that it can sign, they no longer match, and the next MLA that can verify all the
signerInfos will (correctly) reject the message, since the mlExpansionHistory
attributes won't match.  The only solution would be to drop the signerInfo that
the MLA cannot verify, despite the fact that it may be valid.

Q.  How should a mail list agent process a message if the only signerInfo in the
outer layer is signed using an unknown algorithm?  Since it cannot verify the
signerInfo, it should not process or expand its mlExpansionHistory list.  It
should not add an additional outer signature layer, since its attributes would
not include those of the previous outer layer.  Replacing the existing (possibly
valid) signerInfo is not a good option either, since previous MLAs may have
specified attributes in it (e.g. lists of additional signed receipt recipients).
Should the MLA refuse to process the message?

4.2.3.1 Processing for EnvelopedData

Q.  When re-encrypting a message (or its content-encryption key), why does the
MLA list itself as the message originator?  This allows anyone with access to
the MLA's private key (e.g. the MLA's administrator) to decrypt any message it
has ever processed.  Also, the original sender can no longer decrypt copies of
the message that were routed.  If the original encrypted data is instead
retained, and the content encryption key (CEK) is extracted (using the MLA's
private key) and encrypted once for each recipient, the originator's copy of the
CEK could be left unchanged.  Once processing is finished, the MLA would no
longer have access to the plaintext.  If message archiving is required, the MLA
could save a copy of the message in an archive, encrypting the CEK for any
desired profile, not necessarily its own.

   If it were not for the need to search for a security label, this approach
would avoid the need for the MLA to extract the plaintext of the message at all,
and it would only require the (much smaller) CEK briefly.  The MLA would not
even need to know the algorithm used to encrypt the message, merely its OID and
parameters.

4.2.3.2 Processing for SignedData

Q.  Step 2 of this process has been changed from the Internet draft version
(draft-ietf-smime-ess-09.txt).  It seems that now if the "outer" signed data
layer is absent or does not contain an mlExpansionHistory attribute, the MLA
simply adds a new outer signed layer, lists itself in the mlExpansionHistory
attribute, and sends the message to the recipients.  It would no longer expand
any encrypted data for the recipients.  If someone sent a message that was
encrypted then signed to the MLA, the recipients would not be able to decrypt
it.  Have I misread this paragraph?

5. Signing Certificate Attribute

Q.  How does the signingCertificate attribute enhance the security of the
message?

   The signingCertificate attribute is signed.  Therefore, before a receiving
agent should trust its value, it must verify the signature.  To verify the
signature, it must locate the signer's certificate and those of all issuers in a
chain until it finds a trusted root certificate.  As the receiving agent has
already located the certificates required to verify the signature, of what use
is the signingCertificate attribute?  This is a Catch-22 situation, since the
required information is only of use when it is unavailable.

   Using the signingCertificate to identify authorization certificates is no
better.  If the signature on the attribute is not trusted, then the policy also
cannot be trusted and should be ignored.  If the signature on the attribute has
been verified, and the authorization policy indicates that the signature is not
to be trusted under current circumstances, the policy has already been violated.
In fact, the signature should not be trusted to identify the policy that
indicates that the signature should not be trusted, and again the policy should
be ignored.  This is also a Catch-22 situation.

   An attacker attempting one of the attacks mentioned in this section could
replace both the signingCertificate attribute and the certificate, signing the
attribute with the new certificate.  The recipient would have no way of
detecting this, and may be lulled into a false sense of security by the presence
of the (substituted) signingCertificate attribute.

   The only use I can see for this attribute would be in a case where the
signature is intended to be used for (as an example) data integrity but not
non-repudiation (e.g. a server securing data in transit).  In this case, an
attribute certificate might identify the usage intended, and the
signingCertificate attribute could identify the attribute certificate.  This
could be achieved more simply either by including the signing certificate's
intended uses in the certificate itself, or by a statement (or disclaimer)
placed in the signed message itself by the sender stating the intended use of
the signature (e.g. "I am signing this message for data integrity purposes.  I
do not warrant that the information it contains is accurate.").

5.4 Signing Certificate Attribute Definition

Q.  SigningCertificate is a signed attribute.  An MLA processing a message is
supposed to copy the values of all the signed attributes in the outer signature
layer when applying or replacing a signature layer.  Shouldn't the
signingCertificate attribute be omitted from this?  It would refer to the
previous MLA's certificate, not the current MLA's.  Also, an MLA may require the
signingCertificate attribute for its own signature, and (since there can be only
one signingCertificate attribute in the signerInfo) would not be able to include
its own if it copied the previous MLA's signingCertificate attribute.

5.4.1 Certificate Identification

Q.  Why must SHA-1 be used for generating the hash value of the certificate?
Some agents may only process other algorithms (e.g. MD5).  Also, someone may
develop other (possibly superior) hash algorithms in the future, which might
become the new required standard.  Why isn't there a field in the ESSCertID to
identify the algorithm used?




Received: by ns.secondary.com (8.9.3/8.9.3) id HAA17637 for ietf-smime-bks; Tue, 26 Sep 2000 07:39:14 -0700 (PDT)
Received: from mail.ec.auckland.ac.nz (mail.student.auckland.ac.nz [130.216.35.201]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA17632 for <ietf-smime@imc.org>; Tue, 26 Sep 2000 07:39:12 -0700 (PDT)
Received: from kahu.cs.auckland.ac.nz (pgut001@kahu.cs.auckland.ac.nz [130.216.36.13]) by mail.ec.auckland.ac.nz (8.9.3/8.8.6/cs-master) with SMTP id CAA19499 for <ietf-smime@imc.org>; Wed, 27 Sep 2000 02:42:24 +1200 (NZST) (sender pgut001@cs.auckland.ac.nz)
Received: by kahu.cs.auckland.ac.nz (relaymail v0.9) id <96997934711908>; Wed, 27 Sep 2000 02:42:27 (NZST)
From: pgut001@cs.aucKland.ac.nz (Peter Gutmann)
To: ietf-smime@imc.org
Subject: Re: Question on basicConstraints from RFC 2632
Reply-To: pgut001@cs.aucKland.ac.nz
X-Charge-To: pgut001
X-Authenticated: relaymail v0.9 on kahu.cs.auckland.ac.nz
Date: Wed, 27 Sep 2000 02:42:27 (NZST)
Message-ID: <96997934711908@kahu.cs.auckland.ac.nz>
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>

Gwangsoo Rhee <rhee@sookmyung.ac.kr> writes:

>The material below is from RFC 2632. Seems to me that the statements about
>end-entity certificates in the last two paragraphs conflict with each other.
>One says that end-entity certificates contain a basicConstraints extension and
>another says they shouldn't. Maybe I misunderstood those statements. Could
>anyone please enlighten me on the subject?

It's a problem with RFC 2459 which is covered, in the X.509 style guide,
http://www.cs.auckland.ac.nz/~pgut001/pubs/x509guide.txt.  Most of the certs
I've seen seem to ignore the RFC 2459 text, including a basicConstraints
extension in end entity certs, so the problems described in the guide shouldn't
occur much.

Peter.



Received: by ns.secondary.com (8.9.3/8.9.3) id RAA20172 for ietf-smime-bks; Fri, 22 Sep 2000 17:06:05 -0700 (PDT)
Received: from www.com2000.co.kr (com2000.co.kr [203.236.86.98]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id RAA20168 for <ietf-smime@mail.proper.com>; Fri, 22 Sep 2000 17:05:59 -0700 (PDT)
Received: from host ([206.133.176.96]) by www.com2000.co.kr (Lotus Domino Release 5.0.2c) with ESMTP id 2000092309050839:2151 ; Sat, 23 Sep 2000 09:05:08 +0900 
From: "Brendon Mills" <bbker4@safe-mail.net>
Subject: Do You Invest? # DEF
To: stock39d
X-Mailer: Microsoft Outlook Express 4.72.1712.3
X-MimeOLE: Produced By Microsoft MimeOLE VÐßD.1712.3
Mime-Version: 1.0
Date: Fri, 22 Sep 2000 18:51:58 -0500
X-MIMETrack: Itemize by SMTP Server on millecom/Com2000(Release 5.0.2c|2000. 2. 18.) at 2000-09-23 09:05:10, Serialize by Router on millecom/Com2000(Release 5.0.2c|2000. 2. 18.) at 2000-09-23 09:05:36, Serialize complete at 2000-09-23 09:05:36
Message-ID: <OFF64B9AB2.74973318-ON49256963.0000793B@com2000.co.kr>
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>

Do you invest in the stockmarket?

If you invest in technology stocks and are familiar with their trading 
patterns, then you must have seen where many a company's stocks have gone 
from near obscurity to double-digit gains in a very short time frame. These 
tremendous opportunities have inspired us to seek out similar potential 
"big gainers" while they are still in their "near obscurity" stage prior 
to making a big move. These are companies with solid business fundamentals, 
strong management, and huge upside potential because of a solid
product or technology.

We believe that such an opportunity exists in Indexonly Technologies. 
This innovative tech company developed the Internet's first Business 
Search Directory designed for Internet and Wireless use, utilizing its 
own unique computerized content filtering and sorting methods, and a 
committed and proactive community-based franchisee sales force. Their
community-based sales force assures users receive the most accurate 
information on business throughout the world, regardless
of whether they are sitting at their computer or traveling. Indexonly.com 
has a well-developed Path to Profitability (P2P), which
means that profitability, is months, not years, away. The 
Indexonly.com Business Search Directory eliminates, for its users,
millions of irrelevant "matches" and virtually all connections to dead 
links and provides a break-through solution to the all too
frequently asked question: "If the Internet is so good, then why can't 
I find what I am looking for?" http://www.Indexonly.com allows users to
find all the plumbers in their area, or all the hotels in the destination
they wish to visit. They are not restricted to just companies
with Websites or companies that advertise. Indexonly.com lists all companies.

The attached illustration demonstrates how you can use your wireless devices
to access the Indexonly.com Business Search Directory and with only 4 clicks 
find a hotel in San Francisco. Then with a push of a button on your PDA or 
mobile phone, you can then directly contact or telephone the hotel and 
make a reservation. For more information please contact Kirk Hinton Financial at:
Email: khfrelations@hotmail.com
Toll free: 1-877-899-9950 or Phone:(604) 605-1225 

                                  Visit the site at http://www.indexonly.com

////////////////////////////////////////////////////////
If you wish to be removed from this list reply to:
mailto:bbker4@netscape.net?subject=remove
////////////////////////////////////////////////////////





Received: by ns.secondary.com (8.9.3/8.9.3) id JAA11388 for ietf-smime-bks; Fri, 22 Sep 2000 09:54:42 -0700 (PDT)
Received: from smtp.scotland.net (plug.sol.co.uk [194.247.64.1]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA11160; Fri, 22 Sep 2000 09:52:43 -0700 (PDT)
Received: from e2h2p31.scotland.net ([148.176.238.32] helo=JOHNVARSYSTEM) by smtp.scotland.net with smtp (Exim 3.14 #10) id 13cW6N-0007Nu-00; Fri, 22 Sep 2000 17:55:07 +0100
From: "John Ross" <ross@secstan.com>
To: "ietf-pkix@imc. org" <ietf-pkix@imc.org>, "Ietf distribution list" <ietf-smime@imc.org>
Subject: ETSI documents for open comment
Date: Fri, 22 Sep 2000 17:54:34 +0100
Message-ID: <KGEPIFMENMPBAHHCDBLCEENACGAA.ross@secstan.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700
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>

Three draft standards which relate to IETF work items in PKIX and S/MIME
have been posted on the ETSI El Sign Web-site for comments. Comments are
requested on these documents by 13th October 2000 to the ETSI El Sign e-mail
list EL-SIGN@LIST.ETSI.FR.

To register with the EL-SIGN list and download the draft documents see:
http://www.etsi.org/sec/el-sign.htm

The three documents are:

1.  Qualified Certificate Profile: Please put "QC profile" in the front of
the Subject field of all
submissions to the e-mail list on this topic.

2. Time Stamping Profile: Please put "TS profile" in the front of the
Subject field of all submissions
to the e-mail list on this topic.

3. Revised Electronic Signature Formats: Please put "ES Formats" in the
front of the Subject field of all submissions to the e-mail list on this
topic.

Regards

György Endersz, Telia Research AB.  gyorgy.g.endersz@telia.se
Denis Pinkas, Bull.                 pinkas@bull.net
Stefan Santesson, AddTrust.	      stefan@accurata.se
John Ross, Security & Standards.    ross@secstan.com





Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id FAA22966 for ietf-smime-bks; Wed, 20 Sep 2000 05:56:22 -0700 (PDT)
Received: from bdcsql1.al-rostamani.co.ae ([194.170.227.9]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id FAA22959 for <ietf-smime@imc.org>; Wed, 20 Sep 2000 05:55:55 -0700 (PDT)
Date: Wed, 20 Sep 2000 05:55:55 -0700 (PDT)
From: nile333@kadet.co.uk
Message-Id: <200009201255.FAA22959@ns.secondary.com>
Received: from SMTP agent by mail gateway  Wed, 20 Sep 2000 17:01:36 --400
Received: from firewall-in.al-rostamani.co.ae by bdcsql1.al-rostamani.co.ae with SMTP (Microsoft Exchange Internet Mail Service Version 5.0.1460.8) id TFDHQ4XS; Wed, 20 Sep 2000 16:42:33 +0400
Received: from SMTP agent by mail gateway  Wed, 20 Sep 2000 16:47:36 --400
To: nile333@kadet.co.uk
Subject: So, How in the heck have you been?
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>

So, How in the heck have you been?

Do you remember holding previous conversations regarding business and
money making opportunities? I did not send this to you in error!

You Said:

If only I could find an easier way to make a higher income!

and

If I had more money, I could spend more time with my Family, and less
time at work and I sure could use more money so I could pay off my
bills once and for all!

And

I would love to get involved in a business in which will generate money
while I am not at work (like a Gas Pump)!

Dear Friend,

There is a possibility that we haven’t met, but you were chosen by
someone to receive this E-Mail. Please, please, print this off and
read thoroughly. Be sure that you don’t miss any of the points
outlined.  Then put it down, and then read it again. I am sending
you a whole lot of information in which you might not understand
the first time you read it. If you don’t believe this  program
will work for you, send it to 10-20 of your closest friends
(in which you trust deeply),  and ask them what they think?
This really works! Have faith, don’t miss this opportunity,
get involved also, and it will work for you as it does for us!!!!

Due to the popularity of this letter on the Internet, A Major Nightly
News Program recently dedicated an entire show to the investigation of
the
program described below to see if it really can make people money.
The show also investigated whether or not the program was legal. Their
findings proved that there are absolutely no laws prohibiting the
participation in the program. This has helped to show people that this
is a simple, harmless and fun way to make extra money at home. The
results have been truly remarkable. So many people are participating
that those involved are doing much better than ever before. Since
everyone makes more as more people try it out, its been very exciting.

You will understand only if you get involved!
********** THE ENTIRE PLAN IS HERE BELOW **********
**** Print This Now For Future Reference ****

$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$
If you would like to make AT LEAST $50,000 in less than 90 days! If not,

forward this to someone who would like to make this kind of money.
It works (like designed) but only for those who follow it to the letter!

Please read this program THEN READ IT AGAIN!!
$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$

THIS IS A LEGITIMATE. LEGAL, MONEY MAKING OPPORTUNITY!! It does NOT
require you to come into contact with people or make or take any
telephone
calls. Just follow the instructions, and you will make money. This
simplified e-mail marketing program works perfectly 100% EVERY TIME!

E-mail is the sales tool of the future. Take advantage of this virtually

free method of advertising NOW!!! The longer you wait, the more people
will
be doing business using e-mail. Get your piece of this action!!!

Hello, My name is Johnathon Rourke, I’m from Rhode Island.  The enclosed

information is something I almost let slip through my fingers.
Fortunately, sometime later I re-read everything and gave some thought
and study to it. Two years ago, the corporation I worked for the past
twelve yearsdown-sized and my position was eliminated. After
unproductive
job interviews, I decided to open my own business. Over the past year,I
incurred many unforeseen financial problems. I owed my family, friends
and
creditors over$35,000. The economy was taking a toll on my business and
I
just could not seem to make ends meet. I had to refinance and borrow
against
my home to support my family and struggling business.

AT THAT MOMENT something significant happened in my life. I am writing
to share the experience I hopes that this could change your life
FOREVER.
FINANCIALLY$$$!!!

In mid December, I received this program in my e-mail. Six months prior
to
receiving this program I had been sending away for information on
various
business opportunities. All of the programs I received, in my
opinion,were
not cost effective. They were either toodifficult for me to comprehend
or
the initial investment was too muchfor me to risk to see if they would
work.
But as I was saying, in December of 1997 I received this program.I
didn’t
send for it, or ask for it, they just got my name off a mailing list.

THANK GOODNESS FOR THAT!!!

After reading it several times, to make sure I was reading it correctly.
I
couldn’t believe my eyes! Here was a MONEY MAKING MACHINE I could start
immediately without any debt. Like most of you I was still a little
skeptical and a little worried about the legalaspects of it all. So I
checked it out with the U.S. Post Office (1-800-725-2161 24-hrs)  and
they
confirmed that it is indeed legal ! After determining the program was
LEGAL
I decided WHY NOT!?!??

Initially I sent out 10,000 e-mails. It cost me about $15 for my time
on-line. The great thing about e-mail is that I don’t need any paper for

printing to send out the program, and because I also send the product
(reports) by e-mail, my only expense is my time. In less than one week,I
was
starting to receive orders for REPORT #1.

By January 13, I had received 26 orders for REPORT #1. Your goal is to
RECEIVE at least 20 ORDERS FOR REPORT #1 WITHIN 2 WEEKS. IF YOU DON’T
SEND OUT MORE PROGRAMS UNTIL YOU DO. My first step in making $50,000 in
90
days was done. By January 30, I had received 196 orders for REPORT #2.
Your
goal is to RECEIVE AT LEAST 100+ ORDERS FOR REPORT #2 WITHIN
2 WEEKS. IF NOT SEND OUT MORE PROGRAMS UNTIL YOU! DO. ONCE YOU HAVE
100 ORDERS, THE REST IS EASY, RELAX, YOU WILL MAKE YOUR $50,000 GOAL.

Well, I had 196 orders for REPORT #2. 96 more than I needed. So I
sat back and relaxed.

By March 1, of my e-mailing of 10,000, received $58,000 with more coming
in
every day. I paid off ALL my debts and bought a much need new car!
Please
take your time to read this plan, IT WILL CHANGE YOUR LIFE FOREVER$!!!
Remember, it won’t work if you don’t try it. This program does work, But
you
must follow it EXACTLY! Especially the rules of not trying to place your

name in a different place. It won’t work and you’ll lose out on a lot of

money! In order for this program to work, you must meet your goal of 20+

orders for REPORT #1, and 100+ orders for REPORT #2 and you will make
$50,000 or more in 90 days.

I AM LIVING PROOF THAT IT WORKS!!!

If you choose not to participate in this program, I am sorry. It really
is a great opportunity with little cost or risk to you.  If you choose
toparticipate, follow the program and you will be on your way to
financial security. If you are a fellow business owner and
are financial trouble like I was, or you want to start your own
business, consider this a sign. I DID! $$

Sincerely,
Johnathon Rourke

A PERSONAL NOTE FROM THE ORIGINATOR OF THIS PROGRAM: By the time you
have read the enclosed program and reports, you should have concluded
that
such a program, and one that is legal, cpuld not have been created by an

amateur. Let me tell you a little about myself. I had a profitable
business
for 10 years. Then in 1979 my business began falling off. I was doing
the
same things that were previously successful for me, but it wasn’t
working.
Finally, I figured it out. It wasn’t me, it was the economy. Inflation
and
recession had replaced the stable economy that had been with us since
1945.
I don’t have to tell you what happened to the unemployment rate because
many
of you know from first hand experience. There were more failures and
bankruptcies than ever before. The middle class was vanishing. Those who

knew what they were doing invested wisely and moved up. Those who did
not,
including those who never had anything to save or invest, were moving
down into the ranks of the poor. As the saying goes, THE RICH GET RICHER

ANDTHE POOR GET POORER.  The traditional methods of making money will
never
allow you to move up or get rich, inflation will see to that You have
just
received the rest of  your life, with NO RISK and JUST A LITTLE BIT OF
EFFORT. You can make more money in the next few months than you have
everimagined.I should also point out that I will not see a penny of this

money, nor anyone else who has provided a testimonial for this program.
I
retired from the program after sending thousands and thousands of
programs.
Follow the program EXACTLY AS INSTRUCTED. Do not change it in any way.
It
works exceedingly well as it is now. Remember to e-mail a copyof this
exciting report to everyone you can think of. One of the people you send

this to may send out 50,000 and your name will be on everyone of them!
REMEMBER though, ------ the MORE YOU SEND OUT, the more potential
customers
you will reach. So my friend, I have given you the ideas,  information,
materials and opportunity to become financially independent.

IT IS UP TO YOU!! NOW DO IT!!

BEFORE YOU delete this program from your in box, as I almost did, take a

little time to read it and REALLY THINK ABOUT IT. Get a pencil and
figure out what could happen when YOU participate. Figure out the worst
possible response and no matter how you calculate it, you will still
make a
lot of money! You will definitely get back what you invested. Any doubts
you
have will vanish when your first orders come in. $$$ IT WORKS!!! $$$

Jody Jacobs Richmond, VA.

HERE’S HOW THIS AMAZING PROGRAM WILL MAKE YOU THOUSANDS OF
DOLLARS$$$$!!!!

This method of raising capital REALLY WORKS 100% EVERY TIME. I am sure
that you could use up to $50,000 or more in the next 90 days. Before you
say
BULL, please read this program carefully. This is not a chain letter,but
a
perfectly legal money making business. As with all multi-level
businesses,
we build our business by recruiting new partners and selling our
products.
Every state in the USA allows you to recruit new multi-level business
partners, and we sell and deliver a product for EVERY dollar received.

YOUR ORDERS COME BY MAIL AND ARE FILLED BY E-MAIL, so you are not
involved in personal selling. You do it privately in your own home,
store or
office. This is the EASIEST marketing plan anywhere! It is simply order
filling by e-mail! The product is informational and instructional
material,
keys to the secrets for everyone on how to open the doors to the magic
world
of E-COMMERCE, the information highway, the wave of the future !

PLAN SUMMARY:

(1) You order the 4 reports listed below ($5 each) They come to you by
e-mail.

(2)  Save a copy of this entire letter and put your name after Report #1
and
move the other names down.

(3)  Via the internet, access Yahoo.com or any of the other major search

engines to locate hundreds of bulk e-mail service companies (search for
bulk
email) and have them send 25,000  50,000 emails for you about $49+.

(4)  Orders will come to you by postal mail simply e-mail them the
Report they ordered. Let me ask you  isn’t this about as easy as it
gets?

By the way there are over 50 MILLION e-mail address with millions more
joining the internet each year so don’t worry about running out or
saturation. People are used to seeing and hearing the same
advertisements every day on radio/TV. How many times have you received
the same pizza flyers on your door? Then one day you are hungry for
pizza
and order one. Same thing with this letter. I received this letter many
times  then one day I decided it was time to try it.

YOU CAN START TODAY UST DO THESE EASY STEPS: STEP #1 ORDER THE FOUR
REPORTS

Order the four reports shown on the list below (you can’t sell them if
you don’t order them).  For each report, send $5.00 CASH, the NAME &
NUMBER
OF THE REPORT YOU ARE ORDERING, YOUR E-MAIL ADDRESS, and YOUR NAME &
RETURN
ADDRESS (in case of a problem) to the person whose name appears on the
list
next to the report.MAKE SURE YOUR RETURN ADDRESS IS ON YOUR ENVELOPE IN
CASE OF ANY MAIL PROBLEMS! Within a few days you will receive, by e-mail

each of the four reports.Save them on your computer so you can send them
to
the 1,000’s of people who will  order them from you.

STEP #2. ADD YOUR MAILING ADDRESS TO THIS LETTER

a. Look below for the listing of the four reports.
b. After you’ve ordered the four reports, delete the name and address
under REPORT #4. This person has made it through the cycle.
c. Move the name and address under REPORT #3 down to REPORT #4.
d. Move the name and address under REPORT #2 down to REPORT #3.
e. Move the name and address under REPORT #1 down to REPORT #2.
f. Insert your name/address in the REPORT #1 position. Please make sure
you

COPY ALL INFORMATION, every name and address, ACCURATELY!

STEP #3. Take this entire letter, including the modified list of names,
and save it to your computer. Make NO changes to these instructions. Now
you
are ready to use this entire e-mail to send by e-mail to prospects.

Report #1 will tell you how to download bulk email software and email
address so you can send it out to thousands of people while you sleep!
Remember that 50,000+ new people are joining the internet every month!
Your cost to participate in this is practically nothing ( surely you can

afford $20 and initial bulk mailing cost). You obviously already have a
computer and an Internet connection and e-mail is FREE! There are two
primary methods of building your downline: METHOD #1: SENDING BULK
E-MAIL
let’s say that you decide to start small, just to see how it goes, and
we’ll
assume you and all those involved email out only 2,000 programs each.
Let’s
also assume that the mailing receives a 0.5% response. The response
could be
much better. Also, many people will email out thousands of thousands of
programs instead of 2,000 (Why stop at 2000?) But continuing with this
example, you send out only 2,000 programs. With a 0.5% response, that is

only 10 orders for REPORT #1. Those 10 people respond by sending out
2,000
programs each for a total of 20,000. Out of those 0.5%, 100 people
respond
and order REPORT #2.Those 100 mail out 2,000 programs each for a total
of
200,000. The 0.5% response to that is 1,000 orders for REPORT #3. Those
1,000 send out 2,000  programs each for a 2,000,000 total. The 0.5%
response
to that is 10,000 orders for REPORT #4. That’s 10,000 $5 bills for you.
CASH!!! Your total income in this example is $50 + $500 + $5000 +
$50,000
for a total of $55,550!!!

REMEMBER FRIEND, THIS IS ASSUMING 1,990 OUT OF THE 2,000 PEOPLE YOU MAIL
TO
WILL DO ABSOLUTELY NOTHING AND TRASH THIS PROGRAM! DARE TO THINK FOR A
MOMENT WHAT WOULD HAPPEN IF EVERYONE, OR HALF SENT OUT 100,000 PROGRAMS
INSTEAD OF 2,000. Believe me, many people will do just that, and more!

METHOD #2 PLACING FREE ADS ON THE INTERNET Advertising on the internet
is very, very inexpensive, and there are HUNDREDS of FREE places to
advertise. Let’s say you decide to start small to see how well it works.

Assume your goal is to get ONLY 10 people to participate on your first
level. (Placing a lot of FREE ads on the Internet will EASILY get a
larger
response). Also assume that everyone else in YOUR ORGANIZATION gets only
10
downline members. Look how this small number accumulates to achieve the
STAGGERING results below:

1St level  your first 10 send you $5........................$50
2nd level  10 members from those 10 ($5 x 100)............$500
3rd level  10 members from those 100 ($5 x 1,000)......$5,000
4th level 10 members from those 1,000 ($5 x 10,000)..$50,000
$$$$$$ THIS TOTALS
------------------------------------------------55,5550
$$$$$

AMAZING ISN’T IT Remember friends, this assumes that the people who
participate only recruit 10 people each. Think for a moment what would
happen if they got 20 people to participate! Most people get 100’s of
participants and many will continue to work this program, sending out
programs WITH YOUR NAME ON THEM for years! THINK ABOUT IT!
People are going to get emails about this plan from you or somebody else
and
many will work this plan  the question is Don’t you want your name to be
on
the emails they will send out?

*** DON’T MISS OUT !!!***
***JUST TRY IT ONCE !!!***
***SEE WHAT HAPPENS !!!***
***YOU'LL BE AMAZED !!!***

ALWAYS PROVIDE SAME DAY SERVICE ON ALL ORDERS! This will guarantee that
the e-mail THEY send out with YOUR name and address on it will be prompt

because they can’t advertise until they receive the report!

GET STARTED TODAY: PLACE YOUR ORDER FOR THE FOUR REPORTS NOW. Note:--
ALWAYS SEND $5 CASH (U.S. CURRENCY) FOR EACH REPORT. CHECKS NOT
ACCEPTED.
Make sure the cash is concealed by wrapping it in two sheets of paper.
On
one of those sheets write:

(a) the number & name of the report you are ordering
(b) your e-mail address, and
(c) your name & postal address.

REPORT #1b The Insider’s Guide to Advertising for Free on the Internet
ORDER REPORT #1 FROM:

NICK NICHOLAS
473 MICHIGAN ST
ST.PAUL, MN 55102

NOTE: I and every member below are dedicated at helping you with this
program so it will work for you also. TRY US!

REPORT #2 The Insider’s Guide to Sending Bulk E-Mail on the Internet
ORDER REPORT #2 FROM:

DIANE COLON
1811 TAMARIND AVE # 206
LOS ANGELES, CA. 90028

REPORT #3 The Secrets to Multilevel Marketing on the Internet
ORDER REPORT #3 FROM:

MELISSA HOGENMILLER
3709 MONHEIM ROAD
CONOVER, WI 54519

REPORT #4 How to become a Millionaire utilizing the Power of Multilevel
Marketing and the Internet
ORDER REPORT #4 FROM:

CATHY BARROW
10 SYCAMORE STREET
CONWAY, SC 29527

*************TIPS FOR SUCCESS***************
TREAT THIS AS YOUR BUSINESS! Be prompt, professional, and follow the
directions accurately.  Send for the four reports IMMEDIATELY so you
will have them when the orders start coming in because: When you
receive a $5 order you MUST send out the requested product/report.
It is required for this to be a legal business and they need the
reports to send out their letter (with your name on them).

--ALWAYS PROVIDE SAME-DAY SERVICE ON THE ORDERS YOU RECEIVE. Be
patient and persistent with this program- If you follow the
instructions exactly results WILL FOLLOW. $$$$

************ YOUR SUCCESS GUIDELINES ***************

Follow these guidelines to guarantee your success: If you don’t receive
20 orders for REPORT #1 within two weeks, continue advertising or
sending
e-mail until you do. Then a couple of weeks later you should receive at
least 100 orders for REPORT #2. If you don’t continue advertising or
sending
e-mail until you do. Once you have received 100 or more orders for
REPORT
#2, YOU CAN RELAX, because the system is already working for you, and
the
cash will continue to roll in! THIS IS IMPORTANT TO REMEMBER:  Every
time
your name is moved down on the list, you are placed in front of a
DIFFERENT
report. You can KEEP TRACK of your  PROGRESS by watching which report
people
are ordering from you. To generate more income, simply send another
batch of
e-mails or continue placing ads and start the whole process again! There
is
no limit to the income you will generate from this business! Before you
make
your decision as to whether or not you participate in this program.
Please
answer one question:

ARE YOU HAPPY WITH YOUR PRESENT INCOME OR JOB?

1. If the answer is no, then please look at the following facts about
this super simple MLM program: NO face to face selling, NO meetings, NO
inventory! NO Telephone calls, NO big cost to start! Nothing to learn,
No skills needed! (Surely you know how to send email?)

2. No equipment to buy you already have a computer and internet
connection so you have everything you need to fill orders!

3. You are selling a product which does NOT COST ANYTHING TO PRODUCE OR
SHIP! (Email copies of the reports are FREE!)

4. All of your customers pay you in CASH! This program will change your
LIFE  FOREEVER!! Look at the potential for you to be able to quit your
job and live a life of luxury you could only dream about! Imagine
getting out of debt and buying the car and home of your dreams and
being able to work a super-high paying leisurely easy business from
home!

$$$ FINALLY MAKE SOME DREAMS COME TRUE! $$$ ACT NOW!
Take your first step toward achieving financial independence.  Order
the reports and follow the program outlined above __ SUCCESS will be
your reward.

Thank you for your time and consideration. PLEASE NOT: If you need
help with starting a business, registering a business name, learning
now income tax is handled, etc., contact your local office of the
Small Business Administration  (A Federal Agency) 1-800-827-5722
for free help and answers to questions. Also the Internal Revenue
Service offers free help via telephone and free seminars about
business tax requirements. Your earnings are highly dependent on
your activities and advertising. The information contained on this
site and in the report constitutes no guarantees stated nor implied.
In the event that it is determined that this site or report
constitutes a guarantee of any kind, that guarantee is now void. The
earnings amounts listed on this site and in the report are estimates
only. If you have any questions of the legality of this program,
contact the Office of Associate Director for Marketing Practices,
Federal Trade Commission, Bureau of Consumer Protection in
Washington DC.

Under Bill s.1618 TITLE III passed by the 105th US Congress this
letter cannot be considered spam as long as the sender includes
contact information and a method of removal. This is a one time
e-mail transmission. No request for removal is necessary.





Received: by ns.secondary.com (8.9.3/8.9.3) id JAA03528 for ietf-smime-bks; Tue, 19 Sep 2000 09:59:09 -0700 (PDT)
Received: from tholian.securitydynamics.com (tholian.securid.com [204.167.112.129]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id JAA03523; Tue, 19 Sep 2000 09:59:07 -0700 (PDT)
Received: from sdtihq24.securitydynamics.com by tholian.securitydynamics.com via smtpd (for mail.imc.org [208.184.76.43]) with SMTP; 19 Sep 2000 17:00:42 UT
Received: from exrsa01.rsa.com (exrsa01.securitydynamics.com [10.81.217.7]) by sdtihq24.securid.com (Pro-8.9.3/Pro-8.9.3) with ESMTP id MAA17603; Tue, 19 Sep 2000 12:59:06 -0400 (EDT)
Received: by exrsa01.rsa.com with Internet Mail Service (5.5.2448.0) id <SC8Y2BVV>; Tue, 19 Sep 2000 10:01:47 -0700
Message-ID: <E7B6CB80230AD31185AD0008C7EBC4D28213A1@exrsa01.rsa.com>
From: "Kingdon, Kevin" <kevin@rsasecurity.com>
To: "'Andrew Farrell'" <afarrell@baltimore.ie>, ietf-pkix@imc.org
Cc: ietf-smime@imc.org
Subject: RE: Q: Is possible indefinite form of length encoding in DER? 
Date: Tue, 19 Sep 2000 10:01:46 -0700
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
Content-Type: text/plain; charset="iso-8859-1"
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>

See comments below:

-----Original Message-----
From: Andrew Farrell [mailto:afarrell@baltimore.ie]
Sent: Tuesday, September 19, 2000 7:42 AM
To: ietf-pkix@imc.org
Cc: ietf-smime@imc.org
Subject: Re: Q: Is possible indefinite form of length encoding in DER? 


<SNIP/>

On the ridiculous end of this rule is a certificate in which everything
is indefinite length encoded - perfectly valid AFAIK, as long as you
re-encode before verifying.

<KWK>
Further complicating matters is the fact that some commercial products
incorrectly sign the BER encoding. So to validate a signature against a
BER-encoded message, you may have to try validating the with the transmitted
encoding and if that fails try re-coding and validating against the
DER-encoding of the message. (Note that signing BER is flawed if there is a
possibility that an intermediate processor will re-code the BER encoding
into a different but equivalent BER encoding. This usually doesn't happen
with BER, but it is expected to happen with XML-encoded documents. Thus
there is increased emphasis on "canonicalization" procedures for XML digital
signatures.)
</KWK>

<SNIP/>


Received: by ns.secondary.com (8.9.3/8.9.3) id HAA24946 for ietf-smime-bks; Tue, 19 Sep 2000 07:40:48 -0700 (PDT)
Received: from balinese.baltimore.ie (firewall-user@pc215-8.indigo.ie [194.125.215.8]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA24740; Tue, 19 Sep 2000 07:39:57 -0700 (PDT)
Received: by balinese.baltimore.ie; id PAA11985; Tue, 19 Sep 2000 15:42:37 +0100 (GMT/IST)
Received: from bobcat.ie.baltimore.com(10.153.25.10) by balinese.baltimore.ie via smap (V4.2) id xma011799; Tue, 19 Sep 00 15:41:58 +0100
Received: from ocelot.ie.baltimore.com (IDENT:root@ocelot [192.168.21.10]) by bobcat.baltimore.ie (8.9.3/8.9.3) with ESMTP id PAA26305; Tue, 19 Sep 2000 15:41:57 +0100
Received: from ocelot.ie.baltimore.com (afarrell@localhost [127.0.0.1]) by ocelot.ie.baltimore.com (8.8.7/8.8.7) with ESMTP id PAA12950; Tue, 19 Sep 2000 15:41:56 +0100
Message-Id: <200009191441.PAA12950@ocelot.ie.baltimore.com>
To: ietf-pkix@imc.org
Cc: ietf-smime@imc.org
Subject: Re: Q: Is possible indefinite form of length encoding in DER? 
In-Reply-To: Your message of "Tue, 19 Sep 2000 11:39:46 +0900." <39C6D1F2.F08FE367@initech.com> 
Date: Tue, 19 Sep 2000 15:41:56 +0100
From: Andrew Farrell <afarrell@baltimore.ie>
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>

ChungKil Kim <chkim@initech.com> wrote:

>In some S/MIME messages, there are indefinite form of length encoding.
>Is it possible?

>In PKCS specs, only use DER?

An important thing to remember is that although it's often specified
that a signature must be over the DER encoding of an object, it's not
necessarily true that what is transmitted has to be that encoding.

On the ridiculous end of this rule is a certificate in which everything
is indefinite length encoded - perfectly valid AFAIK, as long as you
re-encode before verifying.

On the more practical end, it is often impossible to know when composing
a PKCS#7 SignedData how long the data being signed is. As a result all
the layers surrounding the Content (ContentInfo, SignedData,
EncapsulatedContentInfo) are encoded indefinite length, and the content
itself is encoded as a contructed octet string. The signature is over
the contents octets of the DER encoding, and so it is never necessary
even to count the length of the assembled octetstring. The individual
strings are simply fed to the digests as they appear.

Andrew


Received: by ns.secondary.com (8.9.3/8.9.3) id DAA06151 for ietf-smime-bks; Mon, 18 Sep 2000 03:30:35 -0700 (PDT)
Received: from ietf.org (odin.ietf.org [132.151.1.176]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id DAA06147 for <ietf-smime@imc.org>; Mon, 18 Sep 2000 03:30:33 -0700 (PDT)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA01359; Mon, 18 Sep 2000 06:33:08 -0400 (EDT)
Message-Id: <200009181033.GAA01359@ietf.org>
To: IETF-Announce: ;
Cc: RFC Editor <rfc-editor@isi.edu>, IANA <iana@iana.org>
Cc: Internet Architecture Board <iab@isi.edu>
Cc: ietf-smime@imc.org
From: The IESG <iesg-secretary@ietf.org>
Subject: Protocol Action: Use of the CAST-128 Encryption Algorithm in CMS to Proposed Standard
Date: Mon, 18 Sep 2000 06:33:08 -0400
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>

The IESG has approved the Internet-Draft 'Use of the CAST-128
Encryption Algorithm in CMS' <draft-ietf-smime-cast-128-02.txt> as a
Proposed Standard.  This document is the product of the S/MIME Mail
Security Working Group.  The IESG contact persons are Jeffrey Schiller
and Marcus Leech.

 
Technical Summary
 
This protocol specifies the mechanisms and OIDs necessary to use the
CAST-128 [RFC2144] encryption algorithm with the S/MIME Cryptographic
Message Syntax [RFC2630]. This cipher supports a variable length key
(40 - 128 bits) and is available worldwide without royalties. It is
considered by the cryptographic community as a valid and reasonable
cipher.

Working Group Summary

There was WG consensus on promotion to Proposed Standard.

Protocol Quality

The protocol has been independently reviewed for the IESG by both
Marcus Leech and Jeff Schiller.



Received: by ns.secondary.com (8.9.3/8.9.3) id VAA25092 for ietf-smime-bks; Sun, 17 Sep 2000 21:07:53 -0700 (PDT)
Received: from kydmsrv.koyoinc.co.jp (kydmsrv.koyoinc.co.jp [210.145.15.116]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id VAA25087 for <ietf-smime@mail.proper.com>; Sun, 17 Sep 2000 21:07:51 -0700 (PDT)
Received: from auiaui ([209.206.4.83]) by kydmsrv.koyoinc.co.jp (Lotus Domino Release 5.0.2b) with ESMTP id 2000091803042413:10187 ; Mon, 18 Sep 2000 03:04:24 +0900 
From: "Darren Harris" <wrk23@kozmail.com>
Subject: Easy Start #39F9
To: join39w
X-Mailer: Mozilla 4.70 [en] (Win95; I)
Mime-Version: 1.0
Date: Sun, 17 Sep 2000 12:43:07 -0500
X-MIMETrack: Itemize by SMTP Server on Tokyo/Koyoinc(Release 5.0.2b|28 December 1999) at 2000/09/18 03:04:26 AM, Serialize by Router on Tokyo/Koyoinc(Release 5.0.2b|28 December 1999) at 2000/09/18 01:21:56 PM, Serialize complete at 2000/09/18 01:21:56 PM
Message-ID: <OF02EEB633.157BAE30-ON4925695D.006348B0@koyoinc.co.jp>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by ns.secondary.com id VAA25089
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>

              
Accepting credit cards for your business 

has never been so easy & affordable!

Our specialty is establishing your merchant account!

NO APPLICATION FEE!

NO PROGRAMMING FEE!

$9.95 PROCESSING FEE

Call today and apply:

(888) 264-9272

Now you can design your web site with our

complete software package, which includes:

     Domain Registration 
     Web Hosting 
     Web Design Tools 
     Shopping Cart 
     Credit Card Processing Integration

Quick, Easy and Affordable at just $99.00!

Call (888) 264-9272 and order today!


************************************************************
If you receive this message and have never joined one of our 
email lists you can be removed  by replying to:
mailto:ylkp2@netscape.net?subject=remove
************************************************************





Received: by ns.secondary.com (8.9.3/8.9.3) id OAA17667 for ietf-smime-bks; Sun, 17 Sep 2000 14:07:50 -0700 (PDT)
Received: from kydmsrv.koyoinc.co.jp (kydmsrv.koyoinc.co.jp [210.145.15.116]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id OAA17663 for <ietf-smime@mail.proper.com>; Sun, 17 Sep 2000 14:07:49 -0700 (PDT)
Received: from auiaui ([209.206.4.83]) by kydmsrv.koyoinc.co.jp (Lotus Domino Release 5.0.2b) with ESMTP id 2000091803042413:10187 ; Mon, 18 Sep 2000 03:04:24 +0900 
From: "Darren Harris" <wrk23@kozmail.com>
Subject: Easy Start #39F9
To: join39w
X-Mailer: Mozilla 4.70 [en] (Win95; I)
Mime-Version: 1.0
Date: Sun, 17 Sep 2000 12:43:07 -0500
X-MIMETrack: Itemize by SMTP Server on Tokyo/Koyoinc(Release 5.0.2b|28 December 1999) at 2000/09/18 03:04:26 AM, Serialize by Router on Tokyo/Koyoinc(Release 5.0.2b|28 December 1999) at 2000/09/18 06:21:03 AM, Serialize complete at 2000/09/18 06:21:03 AM
Message-ID: <OF02EEB633.157BAE30-ON4925695D.006348B0@koyoinc.co.jp>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by ns.secondary.com id OAA17664
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>

              
Accepting credit cards for your business 

has never been so easy & affordable!

Our specialty is establishing your merchant account!

NO APPLICATION FEE!

NO PROGRAMMING FEE!

$9.95 PROCESSING FEE

Call today and apply:

(888) 264-9272

Now you can design your web site with our

complete software package, which includes:

     Domain Registration 
     Web Hosting 
     Web Design Tools 
     Shopping Cart 
     Credit Card Processing Integration

Quick, Easy and Affordable at just $99.00!

Call (888) 264-9272 and order today!


************************************************************
If you receive this message and have never joined one of our 
email lists you can be removed  by replying to:
mailto:ylkp2@netscape.net?subject=remove
************************************************************





Received: by ns.secondary.com (8.9.3/8.9.3) id EAA08024 for ietf-smime-bks; Fri, 15 Sep 2000 04:05:39 -0700 (PDT)
Received: from balinese.baltimore.ie (firewall-user@pc215-8.indigo.ie [194.125.215.8]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id EAA08020 for <ietf-smime@imc.org>; Fri, 15 Sep 2000 04:05:37 -0700 (PDT)
Received: by balinese.baltimore.ie; id MAA16808; Fri, 15 Sep 2000 12:07:58 +0100 (GMT/IST)
Received: from bobcat.ie.baltimore.com(10.153.25.10) by balinese.baltimore.ie via smap (V4.2) id xma016670; Fri, 15 Sep 00 12:07:13 +0100
Received: from baltimore.ie (ip219-221.ie.baltimore.com [192.168.21.219]) by bobcat.baltimore.ie (8.9.3/8.9.3) with ESMTP id MAA18177; Fri, 15 Sep 2000 12:07:12 +0100
Message-ID: <39C20375.961C5C64@baltimore.ie>
Date: Fri, 15 Sep 2000 12:09:41 +0100
From: Stephen Farrell <stephen.farrell@baltimore.ie>
Reply-To: stephen.farrell@baltimore.ie
Organization: Baltimore Technologies Ltd.
X-Mailer: Mozilla 4.72 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Robert Zuccherato <robert.zuccherato@entrust.com>
CC: ietf-smime@imc.org, xme <stephen.farrell@baltimore.ie>
Subject: Re: Comments on draft-ietf-smime-rcek-00.txt
References: <3120721CA75DD411B8340090273D20B1283B04@sottmxs06.entrust.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
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 Rob,

> Robert Zuccherato wrote:
> 
> I have a few comments on the draft proposing the re-use of content encryption keys
> (draft-ietf-smime-rcek-00.txt).
> 
> The CEKMaxDecrypts makes this scheme vulnerable to a denial-of-service attack in two ways.  First,
> the attacker could just resend a message MaxDecrypt times and the CEKReference would no longer be
> valid and potentially not accessible.  Does it make more sense to limit the lifetime of the
> CEKReference by time (maybe give the number of seconds it is to be active) instead of number of
> decrypts?  

I don't want to get into into clock synchronisation issues, so an expiry time would be
bad. A TTL might be ok, but I'd suspect that its easier for an application using this
scheme to guess or know the maxDecrypts value rather than a TTL. 

> Also, since the attribute is unprotected it could be changed (i.e. reduced) so that the
> CEKReference isn't available as long as intended. Why not allow the attribute to be protected?

Protection is not disallowed, just out of scope for this draft.

> These possibilities should at least be mentioned in the Security Considerations.

Fair enough, will add some more text along these lines.

> 
> Why not just mandate that the CEK and KEK algorithms must be the same?  This wouldn't seem to be
> too much of an imposition.  This removes the need for a KDF.  

Though I agree with you, its clear that others don't (e.g. Russ), so it looks
like we have to include some KDF:-(

> If you really want to allow
> different algorithms, the KDF included seems kind of ad-hoc. I would be more comfortable if a
> more standard KDF was used.  Perhaps the KDF from IEEE P1363 would be appropriate.

I'm perfectly happy to change this to whatever folks prefer. The current
one is ad-hoc as you say, its (only?) benefit is that it only needs the
content encryption algorithm, but I'm not sure if that's significant.

What do others think?

Stephen.


-- 
____________________________________________________________
Stephen Farrell         				   
Baltimore Technologies,   tel: (direct line) +353 1 647 7406
61 Fitzwilliam Lane,                    fax: +353 1 647 7499
Dublin 2.                mailto:stephen.farrell@baltimore.ie
Ireland                             http://www.baltimore.com


Received: by ns.secondary.com (8.9.3/8.9.3) id LAA28552 for ietf-smime-bks; Thu, 14 Sep 2000 11:48:13 -0700 (PDT)
Received: from mail.spyrus.com (mail.spyrus.com [207.212.34.20]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA28548 for <ietf-smime@imc.org>; Thu, 14 Sep 2000 11:48:12 -0700 (PDT)
Received: from rhousley_laptop.spyrus.com ([209.172.119.205]) by mail.spyrus.com (8.9.3/8.9.3) with ESMTP id LAA25686; Thu, 14 Sep 2000 11:49:55 -0700 (PDT)
Message-Id: <4.3.2.7.2.20000914144037.00bb1bf0@mail.spyrus.com>
X-Sender: rhousley@mail.spyrus.com
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
Date: Thu, 14 Sep 2000 14:46:56 -0400
To: Robert Zuccherato <robert.zuccherato@entrust.com>
From: Russ Housley <housley@spyrus.com>
Subject: Re: Comments on draft-ietf-smime-rcek-00.txt
Cc: ietf-smime@imc.org
In-Reply-To: <3120721CA75DD411B8340090273D20B1283B04@sottmxs06.entrust.c om>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
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>

Robert:

There are important environments where the KEK and CEK algorithms are 
different.  Usually, these environment mandate a stronger algorithm for the 
KEK.  This seems like a very reasonable policy, and I think that we should 
not prohibit it.

Russ

At 11:05 AM 09/14/2000 -0400, Robert Zuccherato wrote:
>Why not just mandate that the CEK and KEK algorithms must be the 
>same?  This wouldn't seem to be too much of an imposition.  This removes 
>the need for a KDF.  If you really want to allow different algorithms, the 
>KDF included seems kind of ad-hoc.  I would be more comfortable if a more 
>standard KDF was used.  Perhaps the KDF from IEEE P1363 would be appropriate.



Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id IAA18930 for ietf-smime-bks; Thu, 14 Sep 2000 08:09:24 -0700 (PDT)
Received: from SOTTMXS01.entrust.com (gatekeeper.entrust.com [204.101.128.170]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA18926 for <ietf-smime@imc.org>; Thu, 14 Sep 2000 08:09:22 -0700 (PDT)
Received: by SOTTMXS01.entrust.com with Internet Mail Service (5.5.2650.21) id <S76SN8M4>; Thu, 14 Sep 2000 11:13:16 -0400
Message-ID: <3120721CA75DD411B8340090273D20B1283B04@sottmxs06.entrust.com>
From: Robert Zuccherato <robert.zuccherato@entrust.com>
To: ietf-smime@imc.org
Subject: Comments on draft-ietf-smime-rcek-00.txt
Date: Thu, 14 Sep 2000 11:05:32 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C01E5D.3A7CE7B0"
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>

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C01E5D.3A7CE7B0
Content-Type: text/plain;
	charset="iso-8859-1"

I have a few comments on the draft proposing the re-use of content
encryption keys (draft-ietf-smime-rcek-00.txt).  

The CEKMaxDecrypts makes this scheme vulnerable to a denial-of-service
attack in two ways.  First, the attacker could just resend a message
MaxDecrypt times and the CEKReference would no longer be valid and
potentially not accessible.  Does it make more sense to limit the lifetime
of the CEKReference by time (maybe give the number of seconds it is to be
active) instead of number of decrypts?  Also, since the attribute is
unprotected it could be changed (i.e. reduced) so that the CEKReference
isn't available as long as intended.  Why not allow the attribute to be
protected?  These possibilities should at least be mentioned in the Security
Considerations.

Why not just mandate that the CEK and KEK algorithms must be the same?  This
wouldn't seem to be too much of an imposition.  This removes the need for a
KDF.  If you really want to allow different algorithms, the KDF included
seems kind of ad-hoc.  I would be more comfortable if a more standard KDF
was used.  Perhaps the KDF from IEEE P1363 would be appropriate.

Thanks,

	Robert Zuccherato
	Entrust Technologies


------_=_NextPart_001_01C01E5D.3A7CE7B0
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2652.35">
<TITLE>Comments on draft-ietf-smime-rcek-00.txt</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2 FACE=3D"Arial">I have a few comments on the draft =
proposing the re-use of content encryption keys =
(draft-ietf-smime-rcek-00.txt).&nbsp; </FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">The CEKMaxDecrypts makes this scheme =
vulnerable to a denial-of-service attack in two ways.&nbsp; First, the =
attacker could just resend a message MaxDecrypt times and the =
CEKReference would no longer be valid and potentially not =
accessible.&nbsp; Does it make more sense to limit the lifetime of the =
CEKReference by time (maybe give the number of seconds it is to be =
active) instead of number of decrypts?&nbsp; Also, since the attribute =
is unprotected it could be changed (i.e. reduced) so that the =
CEKReference isn't available as long as intended.&nbsp; Why not allow =
the attribute to be protected?&nbsp; These possibilities should at =
least be mentioned in the Security Considerations.</FONT></P>

<P><FONT SIZE=3D2 FACE=3D"Arial">Why not just mandate that the CEK and =
KEK algorithms must be the same?&nbsp; This wouldn't seem to be too =
much of an imposition.&nbsp; This removes the need for a KDF.&nbsp; If =
you really want to allow different algorithms, the KDF included seems =
kind of ad-hoc.&nbsp; I would be more comfortable if a more standard =
KDF was used.&nbsp; Perhaps the KDF from IEEE P1363 would be =
appropriate.</FONT></P>

<P><FONT SIZE=3D2 FACE=3D"Arial">Thanks,</FONT>
</P>

<P>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=3D2 =
FACE=3D"Arial">Robert Zuccherato</FONT>
<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=3D2 =
FACE=3D"Arial">Entrust Technologies</FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C01E5D.3A7CE7B0--


Received: by ns.secondary.com (8.9.3/8.9.3) id HAA18237 for ietf-smime-bks; Thu, 14 Sep 2000 07:35:09 -0700 (PDT)
Received: from mail.kpnqwest.ch (mail.eunet.ch [146.228.10.7]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA18233 for <ietf-smime@imc.org>; Thu, 14 Sep 2000 07:35:07 -0700 (PDT)
From: sdjfsdjkfnu@tpntms.anjes.com.tw
Received: from oettinger.davidoff.ch ([195.49.110.243]) by mail.kpnqwest.ch (8.9.3/1.34) via ESMTP id OAA22718 for <ietf-smime@imc.org>; Thu, 14 Sep 2000 14:36:53 GMT env-from (sdjfsdjkfnu@tpntms.anjes.com.tw)
Received: from mail.mindspring.com by oettinger.davidoff.ch via SMTP id smtp\t9ef158v.in; 14 Sep 2000 15:01:00 +0200
To: <ietf-smime@imc.org>
Date: Thu, 14 Sep 2000 05:26:27
Message-Id: <548.115940.189181@mail.mindspring.com>
Subject: 
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
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>

GET YOUR OWN 100 MEG WEBSITE FOR ONLY $11.95 PER MONTH TODAY!

STOP PAYING $19.95 or more TODAY for your web site, WHEN YOU CAN 
GET ONE FOR ONLY $11.95 PER MONTH!

DO YOU ALREADY HAVE A WEBSITE? ALL YOU HAVE TO DO IS TRANSFER THE 
DOMAIN TO OUR SERVERS AND UPLOAD YOUR DATA AND YOU ARE READY TO 
GO! YOUR NEW WEB SPACE CAN BE CREATED INSTANTLY WITH JUST A 
SIMPLE PHONE CALL TO  OUR OFFICE.

YOU CAN CHANGE THE DESIGN OF YOUR SITE AS MUCH AS YOU WANT with 
no extra charge!  UNLIMITED TRAFFIC -- no extra charge!

FRONT PAGE EXTENSIONS are FULLY SUPPORTED.

A SET UP FEE OF $40.00 APPLIES for FIRST TIME CUSTOMERS.

ALL FEES PREPAID IN ADVANCE FOR THE YEAR PLUS A $40.00 SET UP 
CHARGE.

FOR DETAILS CALL 1 888 248 0765  

Webhosting International

 
 
 
 
 
 
 
 
 
 
 


Received: by ns.secondary.com (8.9.3/8.9.3) id DAA12809 for ietf-smime-bks; Tue, 12 Sep 2000 03:49:07 -0700 (PDT)
Received: from ietf.org (odin.ietf.org [132.151.1.176]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id DAA12800 for <ietf-smime@imc.org>; Tue, 12 Sep 2000 03:49:05 -0700 (PDT)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA28788; Tue, 12 Sep 2000 06:51:10 -0400 (EDT)
Message-Id: <200009121051.GAA28788@ietf.org>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: ietf-smime@imc.org
From: Internet-Drafts@ietf.org
Reply-to: Internet-Drafts@ietf.org
Subject: I-D ACTION:draft-ietf-smime-ecc-02.txt
Date: Tue, 12 Sep 2000 06:51:10 -0400
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>

--NextPart

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
	Filename	: draft-ietf-smime-ecc-02.txt
	Pages		: 15
	Date		: 11-Sep-00
	
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-02.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-02.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-ecc-02.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.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="mailserv@ietf.org"

Content-Type: text/plain
Content-ID:	<20000911143530.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-ietf-smime-ecc-02.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-smime-ecc-02.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<20000911143530.I-D@ietf.org>

--OtherAccess--

--NextPart--




Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id IAA12351 for ietf-smime-bks; Mon, 11 Sep 2000 08:12:58 -0700 (PDT)
Received: from roadblock.missi.ncsc.mil ([144.51.50.70]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA12343 for <ietf-smime@imc.org>; Mon, 11 Sep 2000 08:12:57 -0700 (PDT)
Received: from roadblock.missi.ncsc.mil (root@localhost) by roadblock.missi.ncsc.mil with ESMTP id KAA04364 for <ietf-smime@imc.org>; Mon, 11 Sep 2000 10:59:32 -0400 (EDT)
Message-Id: <200009111459.KAA04359@roadblock.missi.ncsc.mil>
Date: Mon, 11 Sep 2000 11:09:18 -0400 (EDT)
From: "David P. Kemp" <dpkemp@missi.ncsc.mil>
Reply-To: "David P. Kemp" <dpkemp@missi.ncsc.mil>
Subject: RE: Question on basicConstraints from RFC 2632
To: ietf-smime@imc.org
MIME-Version: 1.0
Content-Type: TEXT/plain; charset=us-ascii
Content-MD5: G5soqN9sTU+hHqxr3yUyVA==
X-Mailer: dtmail 1.3.0 CDE Version 1.3 SunOS 5.7 sun4u sparc 
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>

I believe a paragraph where one sentence says "does contain" and
the following sentence says "SHOULD NOT contain" the same information
would be contradictory and confusing.

However, a (very) careful reading of RFC 2632's "End-entity certificates
contain an extension that constrains the certificate from being an
issuing authority certificate." reveals that the extension in question
need not be basicConstraints.

RFC 2459 (the PKIX profile) says that BasicConstraints MUST appear in
CA certs and SHOULD NOT appear in end entity certs.  It also says that
the Key Usage extension, when used, SHOULD be marked critical.
Since nearly every end-entity cert will have a key usage extension
anyway and since that extension will preclude the EE cert from being an
issuing authority cert (if CA usage bit is not set), including
basicConstraints in EE certificates which also contain keyUsage is
superfluous.

In a typical example of a standard catering to every possible
viewpoint, son-of-RFC 2459 now says basicConstraints MAY appear, either
critical or non-critical, in end entity certificates.  I view this as
a step away from clarity; SHOULD NOT provides guidance without
prohibiting alternatives.

If son-of-RFC 2632 is going to contain MAY/SHOULD/MUST statements
concerning certificate extensions, I recommend aligning the CA
certificate requirement with PKIX and adding a clarifying sentence at
the end of section 4.4.1:

    Certificates SHOULD contain a basicConstraints extension in
    CA certificates, and SHOULD NOT contain that extension in end
    entity certificates.  End entity certificates SHOULD contain a
    key usage extension.


Section 4.4.2 could use a complete rewrite - it currently says nothing
about including keyUsage in EE certs, and also says nothing about
distinguishing between signature and encryption certificates.  It
delves deep into the details of encrypt/decrypt-only, which seems
especially bizarre given the absence of even a cursory discussion of
digitalSignature, keyEncipherment, and keyAgreement.  I'll provide some
suggested text for 4.4.2 later.

Dave




> From: "Darren Harter" <darren.harter@entegrity.com>
> 
> Gwangsoo Rhee,
> 
> The last paragraph states that an end-entity certificate SHOULD NOT contain
> a basic contraints extension, it doesn't say that it MUST NOT contain one.
> As a consequence, an end-entity certificate MAY contain a basic contraints
> extension, and it if it does the semantic meaning of that extension is as
> described in the first paragraph.
> 
> This is a typical example of the standard providing a discretionary
> recommendation rather than a mandatory instruction.  In this case it is
> quite right and proper, and aids interoperability.  It follows the usual aim
> of IETF standards in being precise in what you send, but flexible in what
> you receive.
> 
> Hope this helps,
> 
> Darren
> ---------------------------------------------------------------------
> Darren Harter B.Sc. (Hons) MBCS CEng
> European Professional Services Group,
> Entegrity Solutions Corp.
> 
> 
> -----Original Message-----
> From: owner-ietf-smime@mail.imc.org
> [mailto:owner-ietf-smime@mail.imc.org]On Behalf Of Gwangsoo Rhee
> Sent: 11 September 2000 06:51
> To: ietf-smime@imc.org
> Subject: Question on basicConstraints from RFC 2632
> 
> 
> The material below is from RFC 2632.
> Seems to me that the statements about end-entity certificates
> in the last two paragraphs conflict with each other.
> One says that end-entity certificates contain a basicConstraints
> extension
> and another says they shouldn't.
> Maybe I misunderstood those statements.
> Could anyone please enlighten me on the subject?
> 
> Many thanks.
> 
> ++++++++++++++++++++++++++++++++++++++++++++++
> 
> 4.4.1 Basic Constraints Certificate Extension
> 
>    The basic constraints extension serves to delimit the role and
>    position of an issuing authority or end-entity certificate plays in a
>    chain of certificates.
> 
>    For example, certificates issued to CAs and subordinate CAs contain a
>    basic constraint extension that identifies them as issuing authority
>    certificates. End-entity certificates contain an extension that
>    constrains the certificate from being an issuing authority
>    certificate.
> 
>    Certificates SHOULD contain a basicConstraints extension in CA
>    certificates, and SHOULD NOT contain that extension in end entity
>    certificates.
> 
> --




Received: by ns.secondary.com (8.9.3/8.9.3) id BAA03785 for ietf-smime-bks; Mon, 11 Sep 2000 01:43:56 -0700 (PDT)
Received: from exchsvr1.entegrity.com (exchsvr1.entegrity.com [207.215.19.3]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id BAA03781 for <ietf-smime@imc.org>; Mon, 11 Sep 2000 01:43:55 -0700 (PDT)
Received: from dharter (213-123-77-70.btconnect.com [213.123.77.70]) by exchsvr1.entegrity.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id RQJ8JRX5; Mon, 11 Sep 2000 01:39:15 -0700
From: "Darren Harter" <darren.harter@entegrity.com>
To: "'Gwangsoo Rhee'" <rhee@sookmyung.ac.kr>, <ietf-smime@imc.org>
Subject: RE: Question on basicConstraints from RFC 2632
Date: Mon, 11 Sep 2000 09:43:42 +0100
Message-ID: <000601c01bcc$63f87700$0100a8c0@entegrity.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0
In-Reply-To: <39BC72AC.C25D3B7@sookmyung.ac.kr>
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Importance: Normal
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>

Gwangsoo Rhee,

The last paragraph states that an end-entity certificate SHOULD NOT contain
a basic contraints extension, it doesn't say that it MUST NOT contain one.
As a consequence, an end-entity certificate MAY contain a basic contraints
extension, and it if it does the semantic meaning of that extension is as
described in the first paragraph.

This is a typical example of the standard providing a discretionary
recommendation rather than a mandatory instruction.  In this case it is
quite right and proper, and aids interoperability.  It follows the usual aim
of IETF standards in being precise in what you send, but flexible in what
you receive.

Hope this helps,

Darren
---------------------------------------------------------------------
Darren Harter B.Sc. (Hons) MBCS CEng
European Professional Services Group,
Entegrity Solutions Corp.


-----Original Message-----
From: owner-ietf-smime@mail.imc.org
[mailto:owner-ietf-smime@mail.imc.org]On Behalf Of Gwangsoo Rhee
Sent: 11 September 2000 06:51
To: ietf-smime@imc.org
Subject: Question on basicConstraints from RFC 2632


The material below is from RFC 2632.
Seems to me that the statements about end-entity certificates
in the last two paragraphs conflict with each other.
One says that end-entity certificates contain a basicConstraints
extension
and another says they shouldn't.
Maybe I misunderstood those statements.
Could anyone please enlighten me on the subject?

Many thanks.

++++++++++++++++++++++++++++++++++++++++++++++

4.4.1 Basic Constraints Certificate Extension

   The basic constraints extension serves to delimit the role and
   position of an issuing authority or end-entity certificate plays in a

   chain of certificates.

   For example, certificates issued to CAs and subordinate CAs contain a

   basic constraint extension that identifies them as issuing authority
   certificates. End-entity certificates contain an extension that
   constrains the certificate from being an issuing authority
   certificate.

   Certificates SHOULD contain a basicConstraints extension in CA
   certificates, and SHOULD NOT contain that extension in end entity
   certificates.

--

---------------------------------------
Gwangsoo Rhee <rhee@sookmyung.ac.kr>
Sookmyung University, Korea
tel: +82-2-710-9429  fax: 710-9296
---------------------------------------



Received: by ns.secondary.com (8.9.3/8.9.3) id WAA00513 for ietf-smime-bks; Sun, 10 Sep 2000 22:50:00 -0700 (PDT)
Received: from cc.sookmyung.ac.kr (cc.sookmyung.ac.kr [203.252.201.4]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id WAA00506 for <ietf-smime@imc.org>; Sun, 10 Sep 2000 22:49:57 -0700 (PDT)
Received: from sookmyung.ac.kr (pc_rhee.sookmyung.ac.kr [203.252.195.65]) by cc.sookmyung.ac.kr (8.9.3/8.9.3) with ESMTP id OAA24015 for <ietf-smime@imc.org>; Mon, 11 Sep 2000 14:50:25 +0900 (KST)
Message-ID: <39BC72AC.C25D3B7@sookmyung.ac.kr>
Date: Mon, 11 Sep 2000 14:50:36 +0900
From: Gwangsoo Rhee <rhee@sookmyung.ac.kr>
X-Mailer: Mozilla 4.72 [en] (Win98; U)
X-Accept-Language: en
MIME-Version: 1.0
To: "ietf-smime@imc.org" <ietf-smime@imc.org>
Subject: Question on basicConstraints from RFC 2632
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
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>

The material below is from RFC 2632.
Seems to me that the statements about end-entity certificates
in the last two paragraphs conflict with each other.
One says that end-entity certificates contain a basicConstraints
extension
and another says they shouldn't.
Maybe I misunderstood those statements.
Could anyone please enlighten me on the subject?

Many thanks.

++++++++++++++++++++++++++++++++++++++++++++++

4.4.1 Basic Constraints Certificate Extension

   The basic constraints extension serves to delimit the role and
   position of an issuing authority or end-entity certificate plays in a

   chain of certificates.

   For example, certificates issued to CAs and subordinate CAs contain a

   basic constraint extension that identifies them as issuing authority
   certificates. End-entity certificates contain an extension that
   constrains the certificate from being an issuing authority
   certificate.

   Certificates SHOULD contain a basicConstraints extension in CA
   certificates, and SHOULD NOT contain that extension in end entity
   certificates.

--

---------------------------------------
Gwangsoo Rhee <rhee@sookmyung.ac.kr>
Sookmyung University, Korea
tel: +82-2-710-9429  fax: 710-9296
---------------------------------------




Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id JAA13367 for ietf-smime-bks; Wed, 6 Sep 2000 09:00:01 -0700 (PDT)
Received: from wfhqex05.gfgsi.com (netva01.wangfed.com [206.137.100.2]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA13360 for <ietf-smime@imc.org>; Wed, 6 Sep 2000 09:00:00 -0700 (PDT)
Received: by wfhqex05.gfgsi.com with Internet Mail Service (5.5.2650.21) id <RLYR6R9F>; Wed, 6 Sep 2000 12:02:21 -0400
Message-ID: <4B0D36365AD3D2118FF40060972A16C0016D040B@wfhqex01.wangfed.com>
From: "Pawling, John" <John.Pawling@wang.com>
To: ietf-smime@imc.org
Subject: RE: Mandatory to implement key wrap algorithm for S/MIME summary
Date: Wed, 6 Sep 2000 12:01:06 -0400 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-1"
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>

All,

Since RFC 2630 (CMS) will be used as the standard security protocol for
several communication protocols that may have different (and changing) sets
of algorithm implementation requirements, I agree with Dave Kemp's
recommendation to change the text in RFC 2630 stating the algorithm
implementation requirements.  I believe that it is appropriate for RFC 2630
(or an appendix to RFC 2630) to define how algorithms are used with the CMS
security protocol, but should not specify algorithm implementation
requirements.  For each communication protocol, a separate profile should be
developed specifying the algorithm implementation requirements for using RFC
2630 with that communication protocol.  For example, the S/MIME v3 algorithm
implementation requirements should be stated in the revised S/MIME v3
Message Specification (as proposed by Blake).  

Recommend the following changes to RFC 2630:

1) Section 12.1: 

OLD: "CMS implementations must include SHA-1.  CMS implementations should
include MD5."  

NEW: "This section describes how the SHA-1 and MD5 digest algorithms are
used with CMS."


2) Section 12.2:

OLD: "CMS implementations must include DSA.  CMS implementations may include
RSA." 

NEW: "This section describes how the DSA and RSA signature algorithms are
used with CMS."   


3) Section 12.3.1: 

OLD: "CMS implementations must include key agreement using X9.42
Ephemeral-Static Diffie-Hellman."  

NEW: "This section describes how key agreement is implemented in CMS using
the X9.42 Ephemeral-Static Diffie-Hellman algorithm."    


4) Section 12.3.1:

OLD: "CMS implementations must include key agreement of Triple-DES pairwise
key-encryption keys and Triple-DES wrapping of Triple-DES content-encryption
keys.  CMS implementations should include key agreement of RC2 pairwise
key-encryption keys and RC2 wrapping of RC2 content-encryption keys.  The
key wrap algorithm for Triple-DES and RC2 is described in section 12.3.3."

NEW: "Section 12.3.3.1 specifies the key wrap algorithm for use with CMS for
key agreement of Triple-DES pairwise key-encryption keys and Triple-DES
wrapping of Triple-DES content-encryption keys.  Section 12.3.3.2 specifies
the key wrap algorithm for use with CMS for key agreement of RC2 pairwise
key-encryption keys and RC2 wrapping of RC2 content-encryption keys."


5) Section 12.3.2: 

OLD: "CMS implementations should include key transport using RSA.  RSA
implementations must include key transport of Triple-DES content-encryption
keys.  RSA implementations should include key transport of RC2
content-encryption keys."

NEW: "This section describes how key transport is implemented in CMS using
RSA in conjunction with Triple-DES and RC2 content-encryption keys."  


6) Section 12.4:

OLD: "CMS implementations must include Triple-DES in CBC mode.  CMS
implementations should include RC2 in CBC mode."

NEW: "This section describes how the Triple-DES (in CBC mode) and RC2 (in
CBC mode) content encryption algorithms are used with CMS."


7) Section 12.6: 

OLD: "CMS implementations must include encryption of a Triple-DES
content-encryption key with a Triple-DES key-encryption key using the
algorithm specified in Sections 12.6.2 and 12.6.3.  CMS implementations
should include encryption of a RC2 content-encryption key with a RC2
key-encryption key using the algorithm specified in Sections 12.6.4 and
12.6.5."  

NEW: "Sections 12.6.2 and 12.6.3 specify the algorithm for use with CMS to
encrypt a Triple-DES content-encryption key with a Triple-DES key-encryption
key.  Sections 12.6.4 and 12.6.5 specify the algorithm for use with CMS to
encrypt a RC2 content-encryption key with a RC2 key-encryption key."  


8) Section 12, intro: 

OLD: "This section lists the algorithms that must be implemented.
Additional algorithms that should be implemented are also included."

NEW: "This section describes how selected algorithms are used with CMS."


Recommend that the revised S/MIME v3 Message Specification should state the
S/MIME working group's consensus regarding each of the aforementioned
algorithm implementation requirements.  

============================================
John Pawling, john.pawling@wang.com
Wang Government Services, Inc.,
A Getronics Company
============================================ 


Received: by ns.secondary.com (8.9.3/8.9.3) id DAA21198 for ietf-smime-bks; Wed, 6 Sep 2000 03:43:39 -0700 (PDT)
Received: from ietf.org (odin.ietf.org [132.151.1.176]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id DAA21193 for <ietf-smime@imc.org>; Wed, 6 Sep 2000 03:43:38 -0700 (PDT)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA07021; Wed, 6 Sep 2000 06:45:13 -0400 (EDT)
Message-Id: <200009061045.GAA07021@ietf.org>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: ietf-smime@imc.org
From: Internet-Drafts@ietf.org
Reply-to: Internet-Drafts@ietf.org
Subject: I-D ACTION:draft-ietf-smime-rcek-00.txt
Date: Wed, 06 Sep 2000 06:45:13 -0400
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>

--NextPart

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-00.txt
	Pages		: 7
	Date		: 05-Sep-00
	
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-00.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-00.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-00.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.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="mailserv@ietf.org"

Content-Type: text/plain
Content-ID:	<20000905150122.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-ietf-smime-rcek-00.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-smime-rcek-00.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<20000905150122.I-D@ietf.org>

--OtherAccess--

--NextPart--




Received: by ns.secondary.com (8.9.3/8.9.3) id OAA11047 for ietf-smime-bks; Tue, 5 Sep 2000 14:17:13 -0700 (PDT)
Received: from roadblock.missi.ncsc.mil (roadblock.missi.ncsc.mil [144.51.50.70]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id OAA11043 for <ietf-smime@imc.org>; Tue, 5 Sep 2000 14:17:12 -0700 (PDT)
Received: from roadblock.missi.ncsc.mil (root@localhost) by roadblock.missi.ncsc.mil with ESMTP id RAA01131 for <ietf-smime@imc.org>; Tue, 5 Sep 2000 17:01:44 -0400 (EDT)
Message-Id: <200009052101.RAA01127@roadblock.missi.ncsc.mil>
Date: Tue, 5 Sep 2000 17:13:17 -0400 (EDT)
From: "David P. Kemp" <dpkemp@missi.ncsc.mil>
Reply-To: "David P. Kemp" <dpkemp@missi.ncsc.mil>
Subject: RE: Mandatory to implement key wrap algorithm for S/MIME summary
To: ietf-smime@imc.org
MIME-Version: 1.0
Content-Type: TEXT/plain; charset=us-ascii
Content-MD5: BRIsUomwU8pgvP+CMlvzCw==
X-Mailer: dtmail 1.3.0 CDE Version 1.3 SunOS 5.7 sun4u sparc 
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>

John,

I agree with Blake's implication that CMS "should not" (little letters)
contain algorithm requirements; conformance should be controlled
exclusively by specifications which reference CMS.  This enables CMS to
remain stable as opinions concerning algorithms change.  Where would we
be if X.509 said every certificate-using application MUST support
id-sa-sqMod-nWithRSA signatures?

I believe the statements quoted below should be removed without replacement
in the next version of CMS.

Dave



> From: "Pawling, John" <John.Pawling@wang.com>
> To: "'ietf-smime@imc.org'" <ietf-smime@imc.org>
> Subject: RE: Mandatory to implement key wrap algorithm for S/MIME summary
> Date: Tue, 5 Sep 2000 12:42:19 -0400 
> 
> All,
> 
> Blake stated: "Note that these mandatory to implement algorithms are not for
> CMS in general, but for the S/MIME profile of CMS."  I have the following
> comments:  
> 
> RFC 2630 (CMS), section 12.3.1, states: "CMS implementations must include
> key agreement using X9.42 Ephemeral-Static Diffie-Hellman."  To be
> consistent with the working group's consensus, I believe that this text
> needs to be changed to: "CMS implementations should include key agreement
> using X9.42 Ephemeral-Static Diffie-Hellman."   
> 
> RFC 2630, section 12.3.2, states: "CMS implementations should include key
> transport using RSA." To be consistent with the working group's consensus, I
> believe that this text needs to be changed to: "CMS implementations must
> include key transport using RSA."   
> 
> RFC 2630, section 12.2, states: "CMS implementations must include DSA.  CMS
> implementations may include RSA."  To be consistent with the working group's
> consensus, I believe that this text needs to be changed to: "CMS
> implementations must include both DSA and RSA." 
> 
> ============================================
> John Pawling, john.pawling@wang.com
> Wang Government Services, Inc.,
> A Getronics Company
> ============================================ 



Received: by ns.secondary.com (8.9.3/8.9.3) id JAA02051 for ietf-smime-bks; Tue, 5 Sep 2000 09:41:21 -0700 (PDT)
Received: from wfhqex05.gfgsi.com (netva01.wangfed.com [206.137.100.2]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA02047 for <ietf-smime@imc.org>; Tue, 5 Sep 2000 09:41:20 -0700 (PDT)
Received: by wfhqex05.gfgsi.com with Internet Mail Service (5.5.2650.21) id <RLYR6MP7>; Tue, 5 Sep 2000 12:42:45 -0400
Message-ID: <4B0D36365AD3D2118FF40060972A16C0016D03F8@wfhqex01.wangfed.com>
From: "Pawling, John" <John.Pawling@wang.com>
To: "'ietf-smime@imc.org'" <ietf-smime@imc.org>
Subject: RE: Mandatory to implement key wrap algorithm for S/MIME summary
Date: Tue, 5 Sep 2000 12:42:19 -0400 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-1"
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>

All,

Blake stated: "Note that these mandatory to implement algorithms are not for
CMS in general, but for the S/MIME profile of CMS."  I have the following
comments:  

RFC 2630 (CMS), section 12.3.1, states: "CMS implementations must include
key agreement using X9.42 Ephemeral-Static Diffie-Hellman."  To be
consistent with the working group's consensus, I believe that this text
needs to be changed to: "CMS implementations should include key agreement
using X9.42 Ephemeral-Static Diffie-Hellman."   

RFC 2630, section 12.3.2, states: "CMS implementations should include key
transport using RSA." To be consistent with the working group's consensus, I
believe that this text needs to be changed to: "CMS implementations must
include key transport using RSA."   

RFC 2630, section 12.2, states: "CMS implementations must include DSA.  CMS
implementations may include RSA."  To be consistent with the working group's
consensus, I believe that this text needs to be changed to: "CMS
implementations must include both DSA and RSA." 

============================================
John Pawling, john.pawling@wang.com
Wang Government Services, Inc.,
A Getronics Company
============================================ 



Received: by ns.secondary.com (8.9.3/8.9.3) id DAA04126 for ietf-smime-bks; Tue, 5 Sep 2000 03:44:25 -0700 (PDT)
Received: from ietf.org (odin.ietf.org [132.151.1.176]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id DAA04122 for <ietf-smime@imc.org>; Tue, 5 Sep 2000 03:44:24 -0700 (PDT)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA27370; Tue, 5 Sep 2000 06:45:54 -0400 (EDT)
Message-Id: <200009051045.GAA27370@ietf.org>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: ietf-smime@imc.org
From: Internet-Drafts@ietf.org
Reply-to: Internet-Drafts@ietf.org
Subject: I-D ACTION:draft-ietf-smime-idea-07.txt
Date: Tue, 05 Sep 2000 06:45:54 -0400
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>

--NextPart

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 the IDEA Encryption Algorithm in CMS
	Author(s)	: S. Teiwes, P. Hartmann, D. Kuenzi
	Filename	: draft-ietf-smime-idea-07.txt
	Pages		: 6
	Date		: 01-Sep-00
	
This memo specifies how to incorporate IDEA (International Data
Encryption Algorithm) [IDEA] into S/MIME [SMIME2, SMIME3] as 
an additional strong algorithm for symmetric encryption. For 
organizations who make use of IDEA for data security purposes 
it is of high interest that IDEA is also available in S/MIME. 
The intention of this memo is to provide the OIDs and algorithms 
required that IDEA can be included in S/MIME for symmetric content
and key encryption.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-smime-idea-07.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-idea-07.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-idea-07.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.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="mailserv@ietf.org"

Content-Type: text/plain
Content-ID:	<20000901143530.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-ietf-smime-idea-07.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-smime-idea-07.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<20000901143530.I-D@ietf.org>

--OtherAccess--

--NextPart--




Received: by ns.secondary.com (8.9.3/8.9.3) id OAA09031 for ietf-smime-bks; Sat, 2 Sep 2000 14:04:31 -0700 (PDT)
Received: from cane.deming.com (mail.deming.com [208.236.41.137]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id OAA09024 for <ietf-smime@imc.org>; Sat, 2 Sep 2000 14:04:29 -0700 (PDT)
Received: from 208.236.41.137 by cane.deming.com with ESMTP (Tumbleweed MMS SMTP Relay (MMS v4.6)); Sat, 02 Sep 2000 14:05:17 -0700
X-Server-Uuid: 1a012586-24e9-11d1-adae-00a024bc53c5
Received: by mail.deming.com with Internet Mail Service (5.5.2650.21) id <Q2XXPBGJ>; Sat, 2 Sep 2000 14:05:16 -0700
Message-ID: <01FF24001403D011AD7B00A024BC53C5A770E8@mail.deming.com>
From: "Blake Ramsdell" <blake.ramsdell@tumbleweed.com>
To: "'ietf-smime@imc.org'" <ietf-smime@imc.org>
Subject: RE: Mandatory to implement key wrap algorithm for S/MIME summary
Date: Sat, 2 Sep 2000 14:05:16 -0700
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
X-WSS-ID: 15AFB40780466-01-01
Content-Type: text/plain;  charset=iso-8859-1
Content-Transfer-Encoding: 7bit
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>

One more thing -- it may be important to do some kind of revision to the
working group charter if we would like to finish this up.  Based on the
level of interest both on the mailing list and at the meeting in Pittsburgh,
it seems like a no-brainer and that people are interested in pursuing this
in the working group, and the charter should be amended.

Blake

>  -----Original Message-----
> From: 	Blake Ramsdell  
> Sent:	Saturday, September 02, 2000 2:02 PM
> To:	'ietf-smime@imc.org'
> Subject:	Mandatory to implement key wrap algorithm for S/MIME summary
> 
> It appears that we have reached at least preliminary consensus for the
> mandatory to implement algorithms for S/MIME.  Note that these mandatory
> to implement algorithms are not for CMS in general, but for the S/MIME
> profile of CMS.
> 
> 1. The mandatory to implement algorithms should change in light of the
> patent expiration for RSA.
> 
> 2. The use of RSA as the mandatory to implement key wrapping algorithm is
> acceptable, and the mode of operation will be PKCS #1 v1.5, not OAEP.
> This seems to reflect the reasoned discussions of at least ten working
> group participants.  This will include adding a security consideration
> note that explains the attack and points to a descriptive reference.
> 
> 3. The use of Diffie-Hellman will only be included for backward
> compatibility, and thus can be a SHOULD implement.
> 
> If we are going to use the PKCS #1 v1.5 implementation of RSA key
> wrapping, then we should document the concerns about its use, and
> potentially point to an RFC or other document that has a full explanation
> (as Paul pointed out earlier).
> 
> Based on this list, I believe that enough information exists to move
> draft-ramsdell-smime31-msg and draft-ramsdell-smime31-cert into the
> working group, and start finishing this up.
> 
> Blake



Received: by ns.secondary.com (8.9.3/8.9.3) id OAA08987 for ietf-smime-bks; Sat, 2 Sep 2000 14:01:16 -0700 (PDT)
Received: from cane.deming.com (mail.deming.com [208.236.41.137]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id OAA08983 for <ietf-smime@imc.org>; Sat, 2 Sep 2000 14:01:15 -0700 (PDT)
Received: from 208.236.41.137 by cane.deming.com with ESMTP (Tumbleweed MMS SMTP Relay (MMS v4.6)); Sat, 02 Sep 2000 14:02:00 -0700
X-Server-Uuid: 1a012586-24e9-11d1-adae-00a024bc53c5
Received: by mail.deming.com with Internet Mail Service (5.5.2650.21) id <Q2XXPBG2>; Sat, 2 Sep 2000 14:02:00 -0700
Message-ID: <01FF24001403D011AD7B00A024BC53C5A770E7@mail.deming.com>
From: "Blake Ramsdell" <blake.ramsdell@tumbleweed.com>
To: "'ietf-smime@imc.org'" <ietf-smime@imc.org>
Subject: Mandatory to implement key wrap algorithm for S/MIME summary
Date: Sat, 2 Sep 2000 14:01:56 -0700
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
X-WSS-ID: 15AFB54280456-01-01
Content-Type: text/plain;  charset=iso-8859-1
Content-Transfer-Encoding: 7bit
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>

It appears that we have reached at least preliminary consensus for the
mandatory to implement algorithms for S/MIME.  Note that these mandatory to
implement algorithms are not for CMS in general, but for the S/MIME profile
of CMS.

1. The mandatory to implement algorithms should change in light of the
patent expiration for RSA.

2. The use of RSA as the mandatory to implement key wrapping algorithm is
acceptable, and the mode of operation will be PKCS #1 v1.5, not OAEP.  This
seems to reflect the reasoned discussions of at least ten working group
participants.  This will include adding a security consideration note that
explains the attack and points to a descriptive reference.

3. The use of Diffie-Hellman will only be included for backward
compatibility, and thus can be a SHOULD implement.

If we are going to use the PKCS #1 v1.5 implementation of RSA key wrapping,
then we should document the concerns about its use, and potentially point to
an RFC or other document that has a full explanation (as Paul pointed out
earlier).

Based on this list, I believe that enough information exists to move
draft-ramsdell-smime31-msg and draft-ramsdell-smime31-cert into the working
group, and start finishing this up.

Blake