Re: I-D ACTION:draft-ietf-smime-idea-00.txt

[Dr Stephen Henson <[e-mail]>]

Russ Housley wrote:
> 
> Steve:
> 
> The reason for this requirement is that Ephemeral-Static Diffie-Hellman
> (E-S D-H) is the mandatory to implement key management algorithm.  The
> output of E-S D-H is a KEK.  So, the mandatory to implement key management
> algorithm requires a way to wrap the CEK in the resulting pairwise KEK.
> 
> Russ
> 
> At 05:24 PM 3/31/99 +0000, Dr Stephen Henson wrote:
> >Is there a potential conflict with CMS 12.3.1? That is:
> >
> >   Any symmetric encryption algorithm that a CMS implementation includes
> >   as a content-encryption algorithm must also be included as a key-
> >   encryption algorithm.
> >
> >As I understand this this means that a CMS implementation using IDEA
> >must also include a means to wrap content encryption keys with IDEA.
> >This would require additional information and a new OID
> >id-alg-CMSIDEAwrap for example.
> >

My point is that the S/MIME IDEA draft spec specifies a way to use IDEA
as a content encryption algorithm but does not include details of how to
use IDEA as a key encryption algorithm.

My interpretation of the quoted paragraph from CMS 12.3.1 (which may
well be incorrect) in the context of the IDEA spec is that any
implementation using IDEA as a content encryption algorithm must also
support IDEA as a key encryption algorithm which the draft S/MIME IDEA
specification does not define.

Again my interpretation of this would be that IDEA cannot be used with a
conformant CMS application until an IDEA key encryption algorithm (and
associated object identifier) is defined as well.

Steve.
-- 
Dr Stephen N. Henson.   http://www.drh-consultancy.demon.co.uk/
Personal Email: [e-mail] 
Senior crypto engineer, Celo Communications: http://www.celocom.com/
Core developer of the   OpenSSL project: http://www.openssl.org/
Business Email: [e-mail] PGP key: via homepage.





Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id QAA11655 for ietf-smime-bks; Wed, 31 Mar 1999 16:03:42 -0800 (PST)
Received: from finch-post-12.mail.demon.net (finch-post-12.mail.demon.net [194.217.242.41]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id QAA11650 for <[e-mail]>; Wed, 31 Mar 1999 16:03:41 -0800 (PST)
Received: from [193.237.150.98] (helo=celocom.com) by finch-post-12.mail.demon.net with esmtp (Exim 2.12 #1) id 10SUxZ-000E4R-0C; Thu, 1 Apr 1999 00:03:49 +0000
Message-ID: <[e-mail]>
Date: Thu, 01 Apr 1999 00:45:21 +0000
From: Dr Stephen Henson <[e-mail]>
Organization: Dr S N Henson
X-Mailer: Mozilla 4.08 [en] (Win95; U)
MIME-Version: 1.0
To: Russ Housley <[e-mail]>
CC: "[e-mail]" <[e-mail]>
Subject: Re: I-D ACTION:draft-ietf-smime-idea-00.txt
References: <[e-mail]> <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Russ Housley wrote:
> 
> Steve:
> 
> The reason for this requirement is that Ephemeral-Static Diffie-Hellman
> (E-S D-H) is the mandatory to implement key management algorithm.  The
> output of E-S D-H is a KEK.  So, the mandatory to implement key management
> algorithm requires a way to wrap the CEK in the resulting pairwise KEK.
> 
> Russ
> 
> At 05:24 PM 3/31/99 +0000, Dr Stephen Henson wrote:
> >Is there a potential conflict with CMS 12.3.1? That is:
> >
> >   Any symmetric encryption algorithm that a CMS implementation includes
> >   as a content-encryption algorithm must also be included as a key-
> >   encryption algorithm.
> >
> >As I understand this this means that a CMS implementation using IDEA
> >must also include a means to wrap content encryption keys with IDEA.
> >This would require additional information and a new OID
> >id-alg-CMSIDEAwrap for example.
> >

My point is that the S/MIME IDEA draft spec specifies a way to use IDEA
as a content encryption algorithm but does not include details of how to
use IDEA as a key encryption algorithm.

My interpretation of the quoted paragraph from CMS 12.3.1 (which may
well be incorrect) in the context of the IDEA spec is that any
implementation using IDEA as a content encryption algorithm must also
support IDEA as a key encryption algorithm which the draft S/MIME IDEA
specification does not define.

Again my interpretation of this would be that IDEA cannot be used with a
conformant CMS application until an IDEA key encryption algorithm (and
associated object identifier) is defined as well.

Steve.
-- 
Dr Stephen N. Henson.   http://www.drh-consultancy.demon.co.uk/
Personal Email: [e-mail] 
Senior crypto engineer, Celo Communications: http://www.celocom.com/
Core developer of the   OpenSSL project: http://www.openssl.org/
Business Email: [e-mail] PGP key: via homepage.




Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id OAA06069 for ietf-smime-bks; Wed, 31 Mar 1999 14:16:37 -0800 (PST)
Received: from spyrus.com (mail.spyrus.com [207.212.34.30]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id OAA06063 for <[e-mail]>; Wed, 31 Mar 1999 14:16:35 -0800 (PST)
Received: from rhousley_laptop.spyrus.com ([209.172.119.101]) by spyrus.com (8.7.6/8.7.3/arc) with SMTP id OAA00107; Wed, 31 Mar 1999 14:16:03 -0800 (PST)
Message-Id: <[e-mail]>
Message-Id: <[e-mail]>
X-Sender: [e-mail] (Unverified)
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 
Date: Wed, 31 Mar 1999 16:10:08 -0500
To: Dr Stephen Henson <[e-mail]>
From: Russ Housley <[e-mail]>
Subject: Re: I-D ACTION:draft-ietf-smime-idea-00.txt
Cc: "[e-mail]" <[e-mail]>
In-Reply-To: <[e-mail]>
References: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Steve:

The reason for this requirement is that Ephemeral-Static Diffie-Hellman
(E-S D-H) is the mandatory to implement key management algorithm.  The
output of E-S D-H is a KEK.  So, the mandatory to implement key management
algorithm requires a way to wrap the CEK in the resulting pairwise KEK.

Russ

At 05:24 PM 3/31/99 +0000, Dr Stephen Henson wrote:
>Is there a potential conflict with CMS 12.3.1? That is:
>
>   Any symmetric encryption algorithm that a CMS implementation includes
>   as a content-encryption algorithm must also be included as a key-
>   encryption algorithm.  
>
>As I understand this this means that a CMS implementation using IDEA
>must also include a means to wrap content encryption keys with IDEA.
>This would require additional information and a new OID
>id-alg-CMSIDEAwrap for example.
>
>Steve.
>-- 
>Dr Stephen N. Henson.   http://www.drh-consultancy.demon.co.uk/
>Personal Email: [e-mail] 
>Senior crypto engineer, Celo Communications: http://www.celocom.com/
>Core developer of the   OpenSSL project: http://www.openssl.org/
>Business Email: [e-mail] PGP key: via homepage.
>


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id NAA01416 for ietf-smime-bks; Wed, 31 Mar 1999 13:18:25 -0800 (PST)
Received: from ietf.org (odin.ietf.org [132.151.1.176]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id NAA01410 for <[e-mail]>; Wed, 31 Mar 1999 13:18:24 -0800 (PST)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA00714; Wed, 31 Mar 1999 16:17:59 -0500 (EST)
Message-Id: <[e-mail]>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: [e-mail]
From: [e-mail]
Reply-to: [e-mail]
Subject: I-D ACTION:draft-ietf-smime-ess-12.txt
Date: Wed, 31 Mar 1999 16:17:59 -0500
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?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		: Enhanced Security Services for S/MIME
	Author(s)	: P. Hoffman
	Filename	: draft-ietf-smime-ess-12.txt
	Pages		: 38
	Date		: 30-Mar-99
	
This document describes four optional security service extensions for
S/MIME. The services are:
 - signed receipts
 - security labels
 - secure mailing lists
 - signing certificates
The first three of these services provide functionality that is similar
to the Message Security Protocol [MSP4], but are useful in many other
environments, particularly business and finance. Signing certificates
are useful in any environment where certificates might be transmitted
with signed messages.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-smime-ess-12.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-ess-12.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:
	[e-mail].
In the body type:
	"FILE /internet-drafts/draft-ietf-smime-ess-12.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="[e-mail]"

Content-Type: text/plain
Content-ID:	<[e-mail]>

ENCODING mime
FILE /internet-drafts/draft-ietf-smime-ess-12.txt

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

Content-Type: text/plain
Content-ID:	<[e-mail]>

--OtherAccess--

--NextPart--




Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id MAA27820 for ietf-smime-bks; Wed, 31 Mar 1999 12:26:17 -0800 (PST)
Received: from post-20.mail.demon.net (post-20.mail.demon.net [194.217.242.27]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id MAA27815 for <[e-mail]>; Wed, 31 Mar 1999 12:26:16 -0800 (PST)
Received: from [193.237.150.98] (helo=celocom.com) by post-20.mail.demon.net with esmtp (Exim 2.10 #2) id 10SRZA-0000Iz-0K for [e-mail]; Wed, 31 Mar 1999 20:26:24 +0000
Message-ID: <[e-mail]>
Date: Wed, 31 Mar 1999 21:24:42 +0000
From: Dr Stephen Henson <[e-mail]>
Organization: Dr S N Henson
X-Mailer: Mozilla 4.08 [en] (Win95; U)
MIME-Version: 1.0
To: "[e-mail]" <[e-mail]>
Subject: RC2 keylength in CMS.
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

In CMS there are still a couple of references to the RC2 key length
being always 128 bits. Specifically 12.3.1 and 12.6. 

Whereas X9.42 refelects the change and that RC2 effective and real key
lengths are equal.

Steve.
-- 
Dr Stephen N. Henson.   http://www.drh-consultancy.demon.co.uk/
Personal Email: [e-mail] 
Senior crypto engineer, Celo Communications: http://www.celocom.com/
Core developer of the   OpenSSL project: http://www.openssl.org/
Business Email: [e-mail] PGP key: via homepage.



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id MAA26908 for ietf-smime-bks; Wed, 31 Mar 1999 12:14:49 -0800 (PST)
Received: from ietf.org (odin.ietf.org [132.151.1.176]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id MAA26902 for <[e-mail]>; Wed, 31 Mar 1999 12:14:47 -0800 (PST)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA28760; Wed, 31 Mar 1999 15:14:23 -0500 (EST)
Message-Id: <[e-mail]>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: [e-mail]
From: [e-mail]
Reply-to: [e-mail]
Subject: I-D ACTION:draft-ietf-smime-x942-07.txt
Date: Wed, 31 Mar 1999 15:14:22 -0500
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?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		: Diffie-Hellman Key Agreement Method
	Author(s)	: E. Rescorla
	Filename	: draft-ietf-smime-x942-07.txt
	Pages		: 10
	Date		: 30-Mar-99
	
This document standardizes one particular Diffie-Hellman variant,
   based on the ANSI X9.42 draft, developed by the ANSI X9F1 working
   group. Diffie-Hellman is a key agreement algorithm used by two par-
   ties to agree on a shared secret. An algorithm for converting the
   shared secret into an arbitrary amount of keying material is pro-
   vided. The resulting keying material is used as a symmetric encryp-
   tion key.  The Diffie-Hellman variant described requires the recipi-
   ent to have a certificate, but the originator may have a static key
   pair (with the public key placed in a certificate) or an ephemeral
   key pair.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-smime-x942-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-x942-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:
	[e-mail].
In the body type:
	"FILE /internet-drafts/draft-ietf-smime-x942-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="[e-mail]"

Content-Type: text/plain
Content-ID:	<[e-mail]>

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

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

Content-Type: text/plain
Content-ID:	<[e-mail]>

--OtherAccess--

--NextPart--




Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id IAA08847 for ietf-smime-bks; Wed, 31 Mar 1999 08:25:27 -0800 (PST)
Received: from post-20.mail.demon.net (post-20.mail.demon.net [194.217.242.27]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id IAA08837 for <[e-mail]>; Wed, 31 Mar 1999 08:25:22 -0800 (PST)
Received: from [193.237.150.98] (helo=celocom.com) by post-20.mail.demon.net with esmtp (Exim 2.10 #2) id 10SNnw-0005CW-0K for [e-mail]; Wed, 31 Mar 1999 16:25:25 +0000
Message-ID: <[e-mail]>
Date: Wed, 31 Mar 1999 17:24:09 +0000
From: Dr Stephen Henson <[e-mail]>
Organization: Dr S N Henson
X-Mailer: Mozilla 4.08 [en] (Win95; U)
MIME-Version: 1.0
To: "[e-mail]" <[e-mail]>
Subject: Re: I-D ACTION:draft-ietf-smime-idea-00.txt
References: <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Is there a potential conflict with CMS 12.3.1? That is:

   Any symmetric encryption algorithm that a CMS implementation includes
   as a content-encryption algorithm must also be included as a key-
   encryption algorithm.  

As I understand this this means that a CMS implementation using IDEA
must also include a means to wrap content encryption keys with IDEA.
This would require additional information and a new OID
id-alg-CMSIDEAwrap for example.

Steve.
-- 
Dr Stephen N. Henson.   http://www.drh-consultancy.demon.co.uk/
Personal Email: [e-mail] 
Senior crypto engineer, Celo Communications: http://www.celocom.com/
Core developer of the   OpenSSL project: http://www.openssl.org/
Business Email: [e-mail] PGP key: via homepage.



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id PAA16601 for ietf-smime-bks; Tue, 30 Mar 1999 15:38:15 -0800 (PST)
Received: from ietf.org (odin.ietf.org [132.151.1.176]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id PAA16596 for <[e-mail]>; Tue, 30 Mar 1999 15:38:14 -0800 (PST)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA00019; Tue, 30 Mar 1999 18:37:46 -0500 (EST)
Message-Id: <[e-mail]>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: [e-mail]
From: [e-mail]
Reply-to: [e-mail]
Subject: I-D ACTION:draft-ietf-smime-idea-00.txt
Date: Tue, 30 Mar 1999 18:37:46 -0500
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?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		: Incorporation of IDEA encryption algorithm in S/MIME
	Author(s)	: S. Teiwes, P. Hartmann, D. Kuenzi
	Filename	: draft-ietf-smime-idea-00.txt
	Pages		: 
	Date		: 29-Mar-99
	
   This memo describes how to incorporate the IDEA (International Data
   Encryption Algorithm) [IDEA] encryption algorithm into S/MIME
   (Secure/Multipurpose Internet Mail Extensions) [SMIME2, SMIME3]. The
   S/MIME standard provides a consistent way to send and receive secure
   MIME [MIME] data. Information security services are implemented on
   the basis of a set of cryptographic functions. Thus, digital
   signatures are used for secure authentication, non-repudiation of
   origin, and data integrity, whereas data encryption is used to assure
   data security and privacy.
 
   S/MIME is constructed as an open system. Its functionality for
   information security purposes can be flexibly extended to meet new
   requirements. At the same time it is assured that extended systems
   will be compatible with non-extended systems.
 
   The general functional capabilities and preferences of S/MIME are
   specified by the registered list of S/MIME object identifiers (OIDs).
   This list of OIDs is maintained by the Internet Mail Consortium at
   <http://www.imc.org/ietf-smime/oids.html>.
   The set of S/MIME functions provided by a client is expressed by the
   S/MIME capabilities attribute. This attribute contains a list of OIDs
   of supported cryptographic functions.


A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-smime-idea-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-idea-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:
	[e-mail].
In the body type:
	"FILE /internet-drafts/draft-ietf-smime-idea-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="[e-mail]"

Content-Type: text/plain
Content-ID:	<[e-mail]>

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

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

Content-Type: text/plain
Content-ID:	<[e-mail]>

--OtherAccess--

--NextPart--




Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id PAA16579 for ietf-smime-bks; Tue, 30 Mar 1999 15:37:48 -0800 (PST)
Received: from ietf.org (odin.ietf.org [132.151.1.176]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id PAA16574 for <[e-mail]>; Tue, 30 Mar 1999 15:37:46 -0800 (PST)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA29929; Tue, 30 Mar 1999 18:37:18 -0500 (EST)
Message-Id: <[e-mail]>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: [e-mail]
From: [e-mail]
Reply-to: [e-mail]
Subject: I-D ACTION:draft-ietf-smime-cms-12.txt
Date: Tue, 30 Mar 1999 18:37:18 -0500
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?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.

Note: This revision reflects comments received during the last call period.

	Title		: Cryptographic Message Syntax
	Author(s)	: R. Housley
	Filename	: draft-ietf-smime-cms-12.txt
	Pages		: 58
	Date		: 29-Mar-99
	
   This document describes the Cryptographic Message Syntax.  This
   syntax is used to digitally sign, digest, authenticate, or encrypt
   arbitrary messages.
 
   The Cryptographic Message Syntax is derived from PKCS #7 version 1.5
   as specified in RFC 2315 [PKCS#7].  Wherever possible, backward
   compatibility is preserved; however, changes were necessary to
   accommodate attribute certificate transfer and key agreement
   techniques for key management.
 
   This draft is being discussed on the 'ietf-smime' mailing list.  To
   join the list, send a message to <[e-mail]> with
   the single word 'subscribe' in the body of the message.  Also, there
   is a Web site for the mailing list at <http://www.imc.org/ietf-
   smime/>.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-smime-cms-12.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-cms-12.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:
	[e-mail].
In the body type:
	"FILE /internet-drafts/draft-ietf-smime-cms-12.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="[e-mail]"

Content-Type: text/plain
Content-ID:	<[e-mail]>

ENCODING mime
FILE /internet-drafts/draft-ietf-smime-cms-12.txt

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

Content-Type: text/plain
Content-ID:	<[e-mail]>

--OtherAccess--

--NextPart--




Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id TAA08195 for ietf-smime-bks; Mon, 29 Mar 1999 19:12:39 -0800 (PST)
Received: from gatekeeper.entrust.com (gatekeeper.entrust.com [204.101.128.170]) by mail.proper.com (8.8.8/8.8.5) with SMTP id TAA08181 for <[e-mail]>; Mon, 29 Mar 1999 19:12:35 -0800 (PST)
Received: 	id WAA13258; Mon, 29 Mar 1999 22:04:57 -0500
Received: by gateway id <G4CAYP83>; Mon, 29 Mar 1999 22:07:15 -0500
Message-ID: <01E1D01C12D7D211AFC70090273D20B112BD4C@sothmxs06>
From: Robert Zuccherato <[e-mail]>
To: [e-mail]
Subject: RE: I-D ACTION:draft-ietf-smime-small-subgroup-00.txt
Date: Mon, 29 Mar 1999 22:01:52 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.1960.3)
Content-Type: text/plain
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

As I mentioned at the meeting in Minneapolis, this draft is intended to be
an informational draft briefly describing the "small-subgroup" attacks on
Diffie-Hellman and methods to protect oneself from these attacks.  I would
encourage people to read this draft.  Comments and criticism are
appreciated.

> ----------
> From: 	[e-mail][SMTP:[e-mail]]
> Reply To: 	[e-mail]
> Sent: 	Monday, March 29, 1999 5:23 PM
> To: 	IETF-Announce
> Cc: 	[e-mail]
> Subject: 	I-D ACTION:draft-ietf-smime-small-subgroup-00.txt
> 
> <<Message: Microsoft Exchange Message>>
> 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		: Methods for Avoiding the 'Small-Subgroup' 
>                           Attacks on the Diffie-Hellman Key Agreement
> Method 
>                           for S/MIME
> 	Author(s)	: R. Zuccherato
> 	Filename	: draft-ietf-smime-small-subgroup-00.txt
> 	Pages		: 7
> 	Date		: 26-Mar-99
> 	
> In some circumstances the use of the Diffie-Hellman key agreement scheme
> in a prime order subgroup of a large prime p is vulnerable to certain
> attacks known as 'small-subgroup' attacks.  Methods exist, however, to
> prevent these attacks.  This document will describe the situations
> relevent to the S/MIME standard in which protection is required and the
> methods that can be used to to prevent these attacks.
> 
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-ietf-smime-small-subgroup-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-small-subgroup-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:
> 	[e-mail].
> In the body type:
> 	"FILE /internet-drafts/draft-ietf-smime-small-subgroup-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.
> 


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id OAA02653 for ietf-smime-bks; Mon, 29 Mar 1999 14:23:54 -0800 (PST)
Received: from ietf.org (odin.ietf.org [132.151.1.176]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id OAA02649 for <[e-mail]>; Mon, 29 Mar 1999 14:23:53 -0800 (PST)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA24297; Mon, 29 Mar 1999 17:23:18 -0500 (EST)
Message-Id: <[e-mail]>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: [e-mail]
From: [e-mail]
Reply-to: [e-mail]
Subject: I-D ACTION:draft-ietf-smime-small-subgroup-00.txt
Date: Mon, 29 Mar 1999 17:23:18 -0500
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?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		: Methods for Avoiding the 'Small-Subgroup' 
                          Attacks on the Diffie-Hellman Key Agreement Method 
                          for S/MIME
	Author(s)	: R. Zuccherato
	Filename	: draft-ietf-smime-small-subgroup-00.txt
	Pages		: 7
	Date		: 26-Mar-99
	
In some circumstances the use of the Diffie-Hellman key agreement scheme
in a prime order subgroup of a large prime p is vulnerable to certain
attacks known as 'small-subgroup' attacks.  Methods exist, however, to
prevent these attacks.  This document will describe the situations
relevent to the S/MIME standard in which protection is required and the
methods that can be used to to prevent these attacks.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-smime-small-subgroup-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-small-subgroup-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:
	[e-mail].
In the body type:
	"FILE /internet-drafts/draft-ietf-smime-small-subgroup-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="[e-mail]"

Content-Type: text/plain
Content-ID:	<[e-mail]>

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

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

Content-Type: text/plain
Content-ID:	<[e-mail]>

--OtherAccess--

--NextPart--




Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id OAA21102 for ietf-smime-bks; Fri, 26 Mar 1999 14:50:45 -0800 (PST)
Received: from apollo.jgvandyke.com (apollo.jgvandyke.com [158.189.10.100]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id OAA21098 for <[e-mail]>; Fri, 26 Mar 1999 14:50:43 -0800 (PST)
Received: from ajsn101.jgvandyke.com (ajsn101.jgvandyke.com [158.189.2.101]) by apollo.jgvandyke.com (8.8.8/8.8.8) with SMTP id SAA09153 for <[e-mail]>; Fri, 26 Mar 1999 18:04:09 -0500 (EST)
Received: from ajpc81 by ajsn101.jgvandyke.com (SMI-8.6/SMI-SVR4) id SAA29730; Fri, 26 Mar 1999 18:01:23 -0500
Date: Fri, 26 Mar 1999 18:01:23 -0500
Message-Id: <[e-mail]>
X-Sender: jsp@ajsn101
X-Mailer: Windows Eudora Version 1.4.4
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
To: [e-mail]
From: [e-mail] (John Pawling)
Subject: 3/17/99 S/MIME WG Mtg Minutes
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

All,

This message includes the minutes of the IETF S/MIME Working Group 
(WG) meeting held on 17 March 1999 in Minneapolis, MN, USA. These 
minutes were coordinated with the briefing presenters.  All briefing 
slides are stored at: ftp://ftp.ietf.org/ietf/smime/.  Reported by
John Pawling.


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

Introductions - Russ Housley
 
Russ reviewed the agenda.  Nobody objected to the agenda.


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

CMS Draft Discussion - Russ Housley

Russ presented the status of the February 1999 Cryptographic Message 
Syntax (CMS-11) Internet-Draft (I-D).  CMS-11 is in IETF Last Call.  
The majority of the comments received since the last meeting have 
focused on Section 12. (This is the section on algorithms and key 
wrapping support.)  CMS-11 includes new key wrap algorithms that 
resolve the issues raised on the S/MIME WG mail list regarding 
possible cryptographic vulnerabilities such as Burt Kaliski's comments 
regarding the "birthday attack". The completion of CMS depends on the 
Diffie-Hellman (D-H) Key Agreement Method I-D (X9.42 I-D).

Russ reviewed the highlights of the CMS-11 Key Wrapping Algorithm 
sections.  CMS-11 documents a mandatory-to-implement key wrapping 
algorithm that describes the process of wrapping a Triple-DES content 
encryption key (CEK) with a Triple-DES key encryption key (KEK). It 
documents another (optional) key wrapping algorithm that describes the 
process of wrapping an RC2 CEK with an RC2 KEK.  Each key wrapping 
algorithm includes instructions for key checksum, key wrap and key 
unwrap.  

The CMS-11 Checksum Algorithm is used to provide a CEK integrity check 
value.  The algorithm is:
   1.  Compute a 20 octet SHA-1 message digest on the CEK.
   2.  Use the most significant (first) eight octets of the message 
       digest value as the checksum value.

The Triple-DES key wrap algorithm encrypts a Triple-DES CEK with a 
Triple-DES KEK.  The CMS-11 Triple-DES key wrap algorithm is:
   1.  Set odd parity for each of the DES key octets comprising the 
       CEK, call the result CEK.
   2.  Compute an 8 octet key checksum value on CEK as described 
       above, call the result ICV.
   3.  Let CEKICV = CEK || ICV.
   4.  Generate 8 octets at random, call the result IV.
   5.  Encrypt CEKICV in CBC mode using the key-encryption key.  Use 
       the random value generated in the previous step as the 
       initialization vector (IV).  Call the ciphertext TEMP1.
   6.  Let TEMP2 = IV || TEMP1.
   7.  Reverse the order of the octets in TEMP2.  That is, the most 
       significant (first) octet is swapped with the least significant 
       (last) octet, and so on.  Call the result TEMP3.
   8.  Encrypt TEMP3 in CBC mode using the key-encryption key.  Use IV 
       of 0x4adda22c79e82105.  The ciphertext is 40 octets long.

The Triple-DES key unwrap algorithm decrypts a Triple-DES CEK using a 
Triple-DES KEK.  The CMS-11 DES key unwrap algorithm is:
   1.  If the wrapped CEK is not 40 octets, then error.
   2.  Decrypt the wrapped CEK in CBC mode using the KEK.  Use an IV 
       of 0x4adda22c79e82105.  Call the output TEMP3.
   3.  Reverse the order of the octets in TEMP3.  That is, the most 
       significant (first) octet is swapped with the least significant 
       (last) octet, and so on.  Call the result TEMP2.
   4.  Decompose the TEMP2 into IV and TEMP1.  IV is the most 
       significant (first) 8 octets, and TEMP1 is the least 
       significant (last) 32 octets.
   5.  Decrypt TEMP1 in CBC mode using the key-encryption key.  Use     
       the IV value from the previous step as the initialization 
       vector.  Call the ciphertext CEKICV.
   6.  Decompose the CEKICV into CEK and ICV. CEK is the most 
       significant (first) 24 octets, and ICV is the least significant 
       (last) 8 octets.
   7.  Compute an 8 octet key checksum value on CEK as described 
       above.  If the computed key checksum value does not match the 
       decrypted key checksum value, ICV, then error.
   8.  Check for odd parity each of the DES key octets comprising CEK.  
       If parity is incorrect, then there is an error.

Jim Schaad sent comments to the mail list regarding the CMS-11 RC2 Key 
Wrap Algorithm.  Russ briefed the following RC2 Key Wrap algorithm 
that includes Jim's comments:
1. Let LCEKPAD = LENGTH || CEK || RANDOM_PAD.
2. Compute checksum on LCEKPAD, call result ICV.
3. Let LCEKPADICV = CEK || ICV.
4. Generate 8 octets at random, call the result IV.
5. Encrypt LCEKPADICV in CBC mode using above IV. Call ciphertext 
   TEMP1. 
6. Let TEMP2 = IV || TEMP1.
7. Let TEMP3 = REVERSE(TEMP2)
8. Encrypt TEMP3 in CBC mode using IV of 0x4adda22c79e82105.

Russ briefed the following RC2 Key Wrap algorithm that includes Jim's 
comments:
1. If the wrapped key length is not a multiple of 8, then error.
2. Decrypt wrapped key in CBC mode using IV of 0x4adda22c79e82105.  
   Call the output TEMP3.
3. TEMP2 = REVERSE(TEMP3)
4. Decompose the TEMP2 into IV and TEMP1. 
5. Decrypt TEMP1 in CBC mode using IV from above.  Call the ciphertext 
   LCEKPADICV.
6. Decompose the LCEKPADICV into LCEKPAD and ICV. 
7. Validate ICV.
8. Decompose the LCEKPAD into LENGTH, CEK and PAD. 

Russ stated that he believes that Jim's proposed changes should be 
incorporated into CMS.  Nobody objected to the inclusion of Jim's 
proposals into CMS. 

Way Forward:  A new CMS draft (CMS-12) will include the harmonized 
Triple-DES and RC2 key wrap algorithms as stated above.  CMS-12 will 
be posted as soon as the repository opens for the submission of new 
IETF drafts.  CMS-12 is ready for discussion by the IESG when the 
X9.42 draft is completed.
 
Russ asked if there were any other unresolved issued regarding CMS. 
Denis Pinkas stated that he believes that CMS should specify how key 
validation is performed.  He is especially concerned with the case in 
which multiple Certification Authority (CA) certificates contain the 
same public key. A vast majority of the meeting attendees decided that 
the PKIX X.509 Certificate and CRL Profile (RFC2459) (referred to by 
the CERT I-D) specifies how key validation is performed and that CMS 
should not replicate that information.  


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

X9.42 Draft Discussion - Eric Rescorla

Eric discussed the status of the January 1999 D-H Key Agreement Method 
I-D (a.k.a. X9.42 I-D).  One change to be made is that the actual RC2 
key length will be the same as the effective key length.  Eric stated 
that he believes that this change resolves the RC2 partition attack.  

Eric also stated that Section 2.1.2, "Generation of Keying Material", 
will be changed to state that the KeySpecificInfo algorithm field will 
include the key wrap algorithm object identifier (OID) instead of the 
symmetric algorithm OID.  The examples will be enhanced to match this 
change.

Nobody objected to Eric's proposed changes.
  

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

Small Subgroup Attacks on D-H      Robert Zuccherato

Robert is developing an informational draft that will describe 
situations that require protection from "small subgroup" attacks on 
D-H.  The draft will also provide guidance on how to provide 
protection.

When is protection required?  In general, for sender:
1) If key is ephemeral, then no protection is required.
2) If key is static, protection is required.

In general, for a recipient (assuming static key):
1) If no information on the success of the decryption is available, no 
   protection is required.
2) If information on the success of the decryption is available, 
   protection is required.

Methods of Protection: 
1) The process by which the recipient's public key is validated by the 
   originator is described in the X9.42 draft.  This strategy is 
   possibly encumbered. Certicom has applied for a patent 
   covering the use of methods to avoid small subgroup attacks.
2) Public key validation by the CA is only realistic for static public 
   keys.
3) Choose p-1=2*q*r where r is product of "large" primes.  Must still 
   check whether public key is +/- 1.
4) Compatible Cofactor Exponentiation is described in IEEE P1363. Also 
   possibly encumbered.

Russ stated that the purpose of this document is to inform people of 
when they need to worry about small subgroup attacks.  Certicom has 
notified the S/MIME WG that they have a pending patent regarding small
subgroup attack protection.  If implementers need to be concerned with 
small subgroup attack protection, then they may wish to watch for 
this patent.
  
Eric Rescorla asked about the status of Certicom's offer for a 
royalty-free license that would allow S/MIME vendors to use the 
technology covered by their pending patent.  Russ stated that Certicom 
had not yet offered any royalty-free licenses because they do not 
believe that their pending patent covers any mandatory S/MIME 
requirements.  Russ also stated that this issue is still being worked.


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

MSG Draft Discussion - Blake Ramsdell

Blake stated that the 26 February 1999 S/MIME v3 Message Specification 
(MSG-07) I-D addresses the comments submitted to the mail list.  Blake 
stated that the MSG I-D has been submitted for IETF last call. Blake 
asked if anybody knew of any unresolved issued regarding MSG. 

Paul Hoffman proposed that the following statement should be added to 
Sec 2.2:  "Note that S/MIME v2 clients are only capable of verifying 
digital signatures using the rsaEncryption algorithm." Paul also 
proposed that the following statement should be added to Sec 2.3:  
"Note that S/MIME v2 clients are only capable of decrypting content 
encryption keys using the rsaEncryption algorithm."  Nobody objected 
to these changes.


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

CERT Draft Discussion - Blake Ramsdell

Blake stated that the 26 February 1999 S/MIME v3 Certificate Handling 
(CERT-07) I-D addresses the comments submitted to the mail list.  
Blake stated that the CERT I-D has been submitted for IETF last call. 

Blake asked if anybody knew of any unresolved issued regarding CERT.  
Denis Pinkas stated that he believed that CERT should be changed to 
state that a receiving agent "MUST support revocation" rather than 
"MUST support CRLs".  He said that his recommended wording would allow 
receiving agents to use other methods of revocation checking such as 
OCSP.  Eric Rescorla made the point that the CMS heading includes 
fields to carry CRLs, so the receiving agent must use them.  After 
several other attendees stated their opinions regarding the use of 
CRLs, Russ asked that the debate be put on hold until the end of the 
meeting so that the rest of the topics could be covered.

Denis has a second comment that he believed that the possible absence 
of the subject DN in a leaf certificate could present a problem. A 
vast majority of the meeting attendees decided that RFC2459 specifies 
how key validation is performed using certificates that may omit the 
subject DN and that CMS should not replicate that information.  

Paul Hoffman pointed out that section 3 in CERT-07 needed
to be modified to delete the "3.1" sub-section title. 


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

ESS Draft Discussion - Paul Hoffman

Paul stated that the 26 February 1999 Enhanced Security Services for 
SMIME (ESS-11) I-D addresses the comments submitted to the mail list.  
It has been submitted for IETF last call.  

Paul said that he will incorporate Francois Rousseau's comments sent 
to the mail list regarding the use of the signingCertificate 
attribute.


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

CERTDIST Draft Discussion - Jim Schaad

Jim stated that the 25 February 1999 Certificate Distribution 
(CERTDIST-03) I-D has not been significantly changed since the 
December 98 S/MIME WG meeting.  He said that he still needs to 
include example data in the document.  The next draft will be
submitted for S/MIME WG last call after the example data has been
added.


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

DOMSEC Draft Discussion - Bill Ottaway

Bill stated that the 17 November 1999 Domain Security Services using 
S/MIME (DOMSEC-01) I-D has been submitted to the mail list.  He stated  
that there has been no changes to the domsec draft since the December
98 S/MIME WG meeting. He is currently working on an implementation of 
domsec.  He intends to have a new draft, based on comments received
and experience gained, before the current draft expires in May 99.


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

Security Policies and Labels    Russ Housley

Russ stated that Weston Nicolls is developing an Internet draft that 
will document the security policies of Whirlpool, Caterpillar and 
Amoco.  The draft will also document how the ESSSecurityLabel can be 
used to implement those corporations' security policies.  Russ stated 
that the S/MIME WG Charter will be expanded to cover this work.  
Nobody objected.


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

S/MIME v3 Examples     Paul Hoffman

Paul stated that the 25 February 1999 Examples of CMS Message Bodies 
(EXAMPLES-00) I-D has been submitted to the mail list.  Paul stated 
that the document will include example keys, certificates and CRLs.  
The next draft will include CRLs.  The document will include some 
incorrect examples that flag common implementation errors. Paul is 
only going to coordinate putting this document together. He needs 
example data for the document and he needs people to volunteer to test 
the sample data.  Volunteers will be given credit in the document.  
Individuals would like to volunteer to do examples should contact Paul 
at [e-mail].


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

Wrap Up - Russ Housley

Russ stated that the CMS, ESS, MSG, CERT and X9.42 documents are in 
IETF Last Call.  He hopes to have these documents reviewed by the IESG 
as soon as possible.

John Pawling asked if there was a strategy for enhancing the S/MIME v3 
documents after they are approved by the IESG.  Russ stated that minor 
changes could be made in the documents when they progress from 
Proposed Standard to Draft Standard.  For example, the proposed change
to the CMS RecipientInfo syntax could be made when CMS progresses from
Proposed Standard to Draft Standard, if consensus is reached on the
handling of password-based key management.

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

Open Issues                     

The debate resumed regarding Denis Pinkas' proposal to change CERT so 
that it states that a receiving agent "MUST support revocation" rather 
than "MUST support CRLs".  After much exciting debate, the majority of 
the group reached consensus that CERT sections 2.1 and 4.1 must be 
changed to state the following:  "All agents MUST be capable of 
performing revocation checks using CRLs as specified in RFC2459.  All 
agents MUST perform revocation status checking in accordance with 
RFC2459."


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

ACTION ITEMS (These changes will be included in the S/MIME v3
documents after they have been discussed on the S/MIME WG mail
list):

1. Enhance CMS I-D to include Jim's comments regarding the RC2 key 
   wrapping and unwrapping algorithms (Russ Housley).
2. Enhance X9.42 I-D to include changes regarding RC2 key length and 
   key wrap algorithm OIDs (Eric Rescorla).
3. Develop I-D regarding small subgroup attacks on D-H (Robert 
   Zuccherato).
4. Enhance MSG I-D to include Paul's comments regarding S/MIME v2 
   agents to MSG draft (Blake Ramsdell).
5. Enhance CERT I-D sections 2.1 and 4.1 as described above (Blake 
   Ramsdell).
6. Enhance ESS I-D to include Francois Rousseau's comments regarding 
   signingCertificate attribute (Paul Hoffman).
7. Develop I-D regarding security policies and labels (Weston 
   Nicolls).
8. Incorporate sample data into Example I-D (Paul Hoffman).

=========================================================
John Pawling,  Director - Systems Engineering
J.G. Van Dyke & Associates, Inc., a Wang Global Company
[e-mail]
=========================================================




Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id LAA19477 for ietf-smime-bks; Fri, 26 Mar 1999 11:39:40 -0800 (PST)
Received: from spyrus.com (mail.spyrus.com [207.212.34.30]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id LAA19473 for <[e-mail]>; Fri, 26 Mar 1999 11:39:39 -0800 (PST)
Received: from rhousley_laptop.spyrus.com ([209.172.119.101]) by spyrus.com (8.7.6/8.7.3/arc) with SMTP id LAA18031; Fri, 26 Mar 1999 11:46:18 -0800 (PST)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 
Date: Fri, 26 Mar 1999 00:29:18 -0500
To: Francois Rousseau <[e-mail]>
From: Russ Housley <[e-mail]>
Subject: Re: Comment on CMS-11 (Temporary Version)
Cc: [e-mail]
In-Reply-To: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Francois:

Thanks for catching the long stangins omission.  Please make sure that I got
all of the places (see below).

Russ



>Russ,
>
>I had not noticed this one before but throughout Sections 12.3 various
>things (e.g. key agreement algorithm identifiers, key transport algorithm
>identifiers, key wrap algorithm identifiers, etc.) are referred as being
>located or used from the "EnvelopedData RecipientInfo...", however they
>could also be located or used from the "AuthenticatedData RecipientInfo..."
>
>Francois Rousseau
>AEPOS Technologies

= = = = = = = = = = = 

12.3  Key Management Algorithms

CMS accommodates three general key management techniques: key agreement, key
transport, and previously distributed symmetric key-encryption keys.

12.3.1  Key Agreement Algorithms

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

Any symmetric encryption algorithm that a CMS implementation includes as a
content-encryption algorithm must also be included as a key-encryption
algorithm.  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.

A CMS implementation may support mixed key-encryption and content-encryption
algorithms.  For example, a 128-bit RC2 content-encryption key may be wrapped
with 168-bit Triple-DES key-encryption key.  Similarly, a 40-bit RC2
content-encryption key may be wrapped with 128-bit RC2 key-encryption key.

For key agreement of RC2 key-encryption keys, 128 bits must be generated as
input to the key expansion process used to compute the RC2 effective key [RC2].

Key agreement algorithm identifiers are located in the EnvelopedData
RecipientInfo KeyAgreeRecipientInfo keyEncryptionAlgorithm and
AuthenticatedData RecipientInfo KeyAgreeRecipientInfo keyEncryptionAlgorithm
fields.

Key wrap algorithm identifiers are located in the KeyWrapAlgorithm parameters
within the EnvelopedData RecipientInfo KeyAgreeRecipientInfo
keyEncryptionAlgorithm and AuthenticatedData RecipientInfo
KeyAgreeRecipientInfo keyEncryptionAlgorithm fields.

Wrapped content-encryption keys are located in the EnvelopedData RecipientInfo
KeyAgreeRecipientInfo recipientEncryptedKeys encryptedKey and AuthenticatedData
RecipientInfo KeyAgreeRecipientInfo recipientEncryptedKeys encryptedKey fields.

12.3.1.1  X9.42 Ephemeral-Static Diffie-Hellman

Ephemeral-Static Diffie-Hellman key agreement is defined in RFC TBD1
[DH-X9.42].  When using Ephemeral-Static Diffie-Hellman, the EnvelopedData
RecipientInfo KeyAgreeRecipientInfo and AuthenticatedData RecipientInfo
KeyAgreeRecipientInfo fields are used as follows:

version must be 3.

originator must be the originatorKey alternative.  The originatorKey algorithm
fields must contain the dh-public-number object identifier with absent
parameters.  The originatorKey publicKey field must contain the sender's
ephemeral public key.  The dh-public-number object identifier is:

   dh-public-number OBJECT IDENTIFIER ::= { iso(1) member-body(2)
       us(840) ansi-x942(10046) number-type(2) 1 }

ukm may be absent.  When present, the ukm is used to ensure that a different
key-encryption key is generated when the ephemeral private key might be used
more than once.

keyEncryptionAlgorithm must be the id-alg-ESDH algorithm identifier.  The
algorithm identifier parameter field for id-alg-ESDH is KeyWrapAlgorihtm, and
this parameter must be present.  The KeyWrapAlgorithm denotes the symmetric
encryption algorithm used to encrypt the content-encryption key with the
pairwise key-encryption key generated using the Ephemeral-Static Diffie-Hellman
key agreement algorithm.  Triple-DES and RC2 key wrap algorithms are discussed
in section 12.3.3.  The id-alg-ESDH algorithm
identifier and parameter syntax is:

   id-alg-ESDH OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840)
       rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) alg(3) 5 }

   KeyWrapAlgorithm ::= AlgorithmIdentifier

recipientEncryptedKeys contains an identifier and an encrypted key for each
recipient.  The RecipientEncryptedKey KeyAgreeRecipientIdentifier must contain
either the issuerAndSerialNumber identifying the recipient's certificate or the
RecipientKeyIdentifier containing the subject key identifier from the
recipient's certificate.  In both cases, the recipient's certificate contains
the recipient's static public key.  RecipientEncryptedKey EncryptedKey must
contain the content-encryption key encrypted with the Ephemeral-Static
Diffie-Hellman generated pairwise key-encryption key using the algorithm
specified by the KeyWrapAlgortihm.

12.3.2  Key Transport Algorithms

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.

Key transport algorithm identifiers are located in the EnvelopedData
RecipientInfo KeyTransRecipientInfo keyEncryptionAlgorithm and
AuthenticatedData RecipientInfo KeyTransRecipientInfo keyEncryptionAlgorithm
fields.

Key transport encrypted content-encryption keys are located in the
EnvelopedData RecipientInfo KeyTransRecipientInfo EncryptedKey and
AuthenticatedData RecipientInfo KeyTransRecipientInfo EncryptedKey fields.

12.3.2.1  RSA

The RSA key transport algorithm is the RSA encryption scheme defined in RFC
2313 [PKCS#1], block type is 02, where the message to be encrypted is the
content-encryption key.  The algorithm identifier for RSA is:

   rsaEncryption OBJECT IDENTIFIER ::= { iso(1) member-body(2)
       us(840) rsadsi(113549) pkcs(1) pkcs-1(1) 1 }

The AlgorithmIdentifier parameters field must be present, and the parameters
field must contain NULL.

When using a Triple-DES content-encryption key, adjust the parity bits for each
DES key comprising the Triple-DES key prior to RSA encryption.

The use of RSA encryption, as defined in RFC 2313 [PKCS#1], to provide
confidentiality has a known vulnerability concerns.  The vulnerability is
primarily relevant to usage in interactive applications rather than to
store-and-forward environments.  Further information and proposed
countermeasures are discussed in the Security Considerations section of this
document.

Note that the same encryption scheme is also defined in RFC 2437 [NEWPKCS#1]. 
Within RFC 2437, this scheme is called RSAES-PKCS1-v1_5.

12.3.3  Symmetric Key-Encryption Key Algorithms

CMS implementations may include symmetric key-encryption key management.  Such
CMS implementations must include Triple-DES key-encryption keys wrapping
Triple-DES content-encryption keys, and such CMS implementations should include
RC2 key-encryption keys wrapping RC2 content-encryption keys.  A CMS
implementation may support mixed key-encryption and content-encryption
algorithms.  For example, a 40-bit RC2 content-encryption key may be wrapped
with 168-bit Triple-DES key-encryption key or with a 128-bit RC2 key-encryption
key.
 
Key wrap algorithm identifiers are located in the EnvelopedData RecipientInfo
KEKRecipientInfo keyEncryptionAlgorithm and AuthenticatedData RecipientInfo
KEKRecipientInfo keyEncryptionAlgorithm fields.

Wrapped content-encryption keys are located in the EnvelopedData RecipientInfo
KEKRecipientInfo encryptedKey and AuthenticatedData RecipientInfo
KEKRecipientInfo encryptedKey fields.

The output of a key agreement algorithm is a key-encryption key, and this
key-encryption key is used to encrypt the content-encryption key.  In
conjunction with key agreement algorithms, CMS implementations must include
encryption of content-encryption keys with the pairwise key-encryption key
generated using a key agreement algorithm.  To support key agreement, key wrap
algorithm identifiers are located in the KeyWrapAlgorithm parameter of the
EnvelopedData RecipientInfo KeyAgreeRecipientInfo keyEncryptionAlgorithm and
AuthenticatedData RecipientInfo KeyAgreeRecipientInfo keyEncryptionAlgorithm
fields, and wrapped content-encryption keys are located in the EnvelopedData
RecipientInfo KeyAgreeRecipientInfo recipientEncryptedKeys encryptedKey and
AuthenticatedData RecipientInfo KeyAgreeRecipientInfo recipientEncryptedKeys
encryptedKey fields.

12.3.3.1  Triple-DES Key Wrap

Triple-DES key encryption has the algorithm identifier:

   id-alg-CMS3DESwrap OBJECT IDENTIFIER ::= { iso(1) member-body(2)
       us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) alg(3) 6 }

The AlgorithmIdentifier parameter field must be NULL.

The key wrap algorithm used to encrypt a Triple-DES content-encryption key with
a Triple-DES key-encryption key is specified in section 12.6.

Out-of-band distribution of the Triple-DES key-encryption key used to encrypt
the Triple-DES content-encryption key is beyond of the scope of this document.

12.3.3.2  RC2 Key Wrap

RC2 key encryption has the algorithm identifier:

   id-alg-CMSRC2wrap OBJECT IDENTIFIER ::= { iso(1) member-body(2)
       us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) alg(3) 7 }

The AlgorithmIdentifier parameter field must be RC2wrapParameter:

   RC2wrapParameter ::= RC2ParameterVersion

   RC2ParameterVersion ::= INTEGER

The RC2 effective-key-bits (key size) greater than 32 and less than 256 is
encoded in the RC2ParameterVersion.  For the effective-key-bits of 40, 64, and
128, the rc2ParameterVersion values are 160, 120, and 58 respectively.  These
values are not simply the RC2 key length.  Note that the value 160 must be
encoded as two octets (00 A0), because the one octet (A0) encoding represents a
negative number.

The key wrap algorithm used to encrypt a RC2 content-encryption key with a RC2
key-encryption key is specified in section 12.6.

Out-of-band distribution of the RC2 key-encryption key used to encrypt the RC2
content-encryption key is beyond of the scope of this document.



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id IAA15788 for ietf-smime-bks; Fri, 26 Mar 1999 08:58:53 -0800 (PST)
Received: from broncho.ucok.edu (broncho.ucok.edu [192.206.65.10]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id IAA15763; Fri, 26 Mar 1999 08:58:35 -0800 (PST)
Received: from england.com ([196.40.0.38]) by broncho.ucok.edu (AIX4.2/UCB 8.7/8.7) with SMTP id KAA41558; Fri, 26 Mar 1999 10:41:22 -0600 (CST)
Message-Id: <[e-mail]>
Date: Sat, 27 Mar 99 00:03:49 EST
From: "[e-mail]" <[e-mail]>
To: [e-mail]
Subject: STOCKS ON THE MOVE!
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

PDC Innovative Industries Inc. (Symbol PDCI), OTC Boulletin Board is
prepared for a big move saids stock market analysts. Recently reverse
split 40 for 1 currently trading at 4 Dollars per share. If the stock hits
pre split level the price could easily hit 10 to 12 Dollars per share. PDCI
recently announces major news concerning production and sales
projections. Medical Stock Analyst see PDC's steri-pro invention as mayor
winner. For more info check Dow Jones Historical news.



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id NAA24424 for ietf-smime-bks; Wed, 24 Mar 1999 13:59:11 -0800 (PST)
Received: from spyrus.com (mail.spyrus.com [207.212.34.30]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id NAA24419 for <[e-mail]>; Wed, 24 Mar 1999 13:59:10 -0800 (PST)
Received: from rhousley_laptop.spyrus.com ([209.172.119.101]) by spyrus.com (8.7.6/8.7.3/arc) with SMTP id OAA08976; Wed, 24 Mar 1999 14:05:17 -0800 (PST)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 
Date: Wed, 24 Mar 1999 02:04:34 -0500
To: [e-mail] (John Pawling)
From: Russ Housley <[e-mail]>
Subject: Re: x942-06 Comment
Cc: [e-mail]
In-Reply-To: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Agree.


At 10:28 AM 3/24/99 -0500, John Pawling wrote:
>All,
>
>The 22-Mar-99 Diffie-Hellman Key Agreement Method I-D (x942-06), Section
>2.1.2 includes the following text regarding the KeySpecificInfo algorithm
>field:  "algorithm is the ASN.1 algorithm OID of the MEK wrapping algorithm
>with which this KEK will be used."  Recommend that "MEK" should be changed
>to "CEK" in the above text because "MEK" is not defined/used in the S/MIME
>v3 set of specs
>
>=========================================================
>John Pawling,  Director - Systems Engineering
>J.G. Van Dyke & Associates, Inc., a Wang Global Company
>=========================================================
>



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id HAA19922 for ietf-smime-bks; Wed, 24 Mar 1999 07:17:57 -0800 (PST)
Received: from apollo.jgvandyke.com (apollo.jgvandyke.com [158.189.10.100]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id HAA19918 for <[e-mail]>; Wed, 24 Mar 1999 07:17:55 -0800 (PST)
Received: from ajsn101.jgvandyke.com (ajsn101.jgvandyke.com [158.189.2.101]) by apollo.jgvandyke.com (8.8.8/8.8.8) with SMTP id KAA28582 for <[e-mail]>; Wed, 24 Mar 1999 10:31:08 -0500 (EST)
Received: from ajpc81 by ajsn101.jgvandyke.com (SMI-8.6/SMI-SVR4) id KAA16676; Wed, 24 Mar 1999 10:28:22 -0500
Date: Wed, 24 Mar 1999 10:28:22 -0500
Message-Id: <[e-mail]>
X-Sender: jsp@ajsn101
X-Mailer: Windows Eudora Version 1.4.4
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
To: [e-mail]
From: [e-mail] (John Pawling)
Subject: x942-06 Comment
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

All,

The 22-Mar-99 Diffie-Hellman Key Agreement Method I-D (x942-06), Section
2.1.2 includes the following text regarding the KeySpecificInfo algorithm
field:  "algorithm is the ASN.1 algorithm OID of the MEK wrapping algorithm
with which this KEK will be used."  Recommend that "MEK" should be changed
to "CEK" in the above text because "MEK" is not defined/used in the S/MIME
v3 set of specs

=========================================================
John Pawling,  Director - Systems Engineering
J.G. Van Dyke & Associates, Inc., a Wang Global Company
=========================================================



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id RAA16081 for ietf-smime-bks; Tue, 23 Mar 1999 17:00:11 -0800 (PST)
Received: from aum (ip11.proper.com [165.227.249.11]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id RAA16077 for <[e-mail]>; Tue, 23 Mar 1999 17:00:10 -0800 (PST)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.32 (Beta)
Date: Tue, 23 Mar 1999 17:04:47 -0800
To: [e-mail]
From: Paul Hoffman / IMC <[e-mail]>
Subject: Changes in CMS examples -00
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Greetings again. After talking to Blake Ramsdell and Jim Schaad, the two 
people who are probably going to generate the initial keys and certs for 
the -examples draft, we changed things a bit from the -00 draft. I thought 
I would put the changes on the list to generate some more thinking about 
the content of the draft itself.

In section 6.2, we removed the keys that were used in just that example.

In section 3.2, we added keys for Eve for examples of sharing D-H, and we 
made Diane's RSA key for both signing and encrypting.

In section 3.3, we added a cert for Eve, gave Diane a new RSA cert and a 
new DSS cert, had Alison not inherit her parameters from Carl, and made 
Diane inherit her DSS parameters from Carl.

Got all that? I'll be adding comments to the Base64 in the draft so you 
don't have to just read the names. Here's the text that will most likely be 
in -01.

3.2 Keys

The following keys are needed to create the samples. Note that 
BobPubDHEncrypt and DianePubDHEncrypt do *not* share Diffie-Hellman 
parameters; however, Bob and Eve share Diffie-Hellman parameters. (A joke 
about "safe sets" comes to mind, but is elided.)

AlicePrivDSSSign = XXXXX
AlicePrivRSASign = XXXXX
AlicePubDSSSign = XXXXX
AlicePubRSASign = XXXXX
BobPrivDHEncrypt = XXXXX
BobPrivRSAEncrypt = XXXXX
BobPubDHEncrypt = XXXXX
BobPubRSAEncrypt = XXXXX
CarlPrivDSSSign = XXXXX
CarlPrivRSASign = XXXXX
CarlPubDSSSign = XXXXX
CarlPubRSASign = XXXXX
DianePubDSSSign = XXXXX
DianePubRSASignEncrypt = XXXXX
DianePubDHEncrypt = XXXXX
EvePubDHEncryptBobParam = XXXXX
EvePrivDHEncryptBobParam = XXXXX
MailListTripleDES = XXXXX
MailListRC2 = XXXXX

3.3 Certificates

AliceDSSSignByCarlNoInherit = XXXXX
AliceRSASignByCarl = XXXXX
BobDHEncryptByCarl =  XXXXX
CarlDSSSelf = XXXXX
CarlRSASelf = XXXXX
DianeDSSSignByCarlInherit = XXXXX
DianeDHEncryptByCarl = XXXXX
DianeRSASignEncryptByCarl = XXXXX
EveDHEncryptByCarl = XXXXX



--Paul Hoffman, Director
--Internet Mail Consortium


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id OAA14390 for ietf-smime-bks; Tue, 23 Mar 1999 14:07:55 -0800 (PST)
Received: from spyrus.com (mail.spyrus.com [207.212.34.30]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id OAA14386 for <[e-mail]>; Tue, 23 Mar 1999 14:07:54 -0800 (PST)
Received: from rhousley_laptop.spyrus.com ([209.172.119.101]) by spyrus.com (8.7.6/8.7.3/arc) with SMTP id OAA16862 for <[e-mail]>; Tue, 23 Mar 1999 14:14:30 -0800 (PST)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 
Date: Tue, 23 Mar 1999 03:02:50 -0500
To: [e-mail]
From: Russ Housley <[e-mail]>
Subject: CERTDIST-03 Working Group Last Call
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

This message announces the begining of S/MIME Working Group Last call on
the CERTDIST document.  I expect Last Call to close in two weeks unless
significant issues are raised.

Russ



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id OAA14357 for ietf-smime-bks; Tue, 23 Mar 1999 14:04:33 -0800 (PST)
Received: from ietf.org (odin.ietf.org [132.151.1.176]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id OAA14352 for <[e-mail]>; Tue, 23 Mar 1999 14:04:32 -0800 (PST)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA27847; Tue, 23 Mar 1999 17:11:06 -0500 (EST)
Message-Id: <[e-mail]>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: [e-mail]
From: [e-mail]
Reply-to: [e-mail]
Subject: I-D ACTION:draft-ietf-smime-x942-06.txt
Date: Tue, 23 Mar 1999 17:11:05 -0500
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?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.

Note: This revision reflects comments received during the last call period.

	Title		: Diffie-Hellman Key Agreement Method
	Author(s)	: E. Rescorla
	Filename	: draft-ietf-smime-x942-06.txt
	Pages		: 13
	Date		: 22-Mar-99
	
   This document standardizes one particular Diffie-Hellman variant,
   based on the ANSI X9.42 draft, developed by the ANSI X9F1 working
   group. Diffie-Hellman is a key agreement algorithm used by two par-
   ties to agree on a shared secret. An algorithm for converting the
   shared secret into an arbitrary amount of keying material is pro-
   vided. The resulting keying material is used as a symmetric encryp-
   tion key.  The D-H variant described requires the recipient to have a
   certificate, but the originator may have a static key pair (with the
   public key placed in a certificate) or an ephemeral key pair.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-smime-x942-06.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-x942-06.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:
	[e-mail].
In the body type:
	"FILE /internet-drafts/draft-ietf-smime-x942-06.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="[e-mail]"

Content-Type: text/plain
Content-ID:	<[e-mail]>

ENCODING mime
FILE /internet-drafts/draft-ietf-smime-x942-06.txt

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

Content-Type: text/plain
Content-ID:	<[e-mail]>

--OtherAccess--

--NextPart--




Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id LAA12957 for ietf-smime-bks; Tue, 23 Mar 1999 11:36:34 -0800 (PST)
Received: from dylithium.adga.ca (dylithium.adga.ca [207.112.67.34]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id LAA12952; Tue, 23 Mar 1999 11:36:32 -0800 (PST)
Received: from xfile ([207.112.70.165]) by dylithium.adga.ca (980427.SGI.8.8.8/8.8.8-ajr) with SMTP id OAA00061; Tue, 23 Mar 1999 14:42:03 -0500 (EST)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: Windows Eudora Pro Version 3.0.1 (32)
Date: Tue, 23 Mar 1999 14:42:54 -0500
To: Paul Hoffman / IMC <[e-mail]>
From: Francois Rousseau <[e-mail]>
Subject: Re: Proposed changes to the -msg draft
Cc: [e-mail]
In-Reply-To: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Paul,

I concur with the proposed changes, but I would suggest that the two
statements be made consistent with the terminology currently used in the
-MSG draft. See below.

Francois Rousseau
AEPOS Technologies

At 09:28 AM 23/03/99 -0800, Paul Hoffman / IMC wrote:
>Greetings again. As was discussed in Minneapolis, I propose two small but 
>significant changes to the -msg draft. There was pretty strong agreement in 
>the room at the time, but I'm open to feedback from the list.
>
>I propose that the following statement should be added to Section 2.2:
>
>Note that S/MIME v2 clients are only capable of verifying digital 
>signatures using the rsaEncryption algorithm.
>

I suggest it should read:

Note that S/MIME version 2 receiving agents are only capable of verifying
digital signatures using the rsaEncryption algorithm.

>I also propose that the following statement should be added to Sec 2.3:
>
>Note that S/MIME v2 clients are only capable of decrypting content 
>encryption keys using the rsaEncryption algorithm.
>

I suggest it should read:

Note that S/MIME version 2 receiving agents are only capable of decrypting
content encryption keys using the rsaEncryption algorithm.

>Both sentences reflect reality, not politics. However, I think it's 
>important to add them because a naive developer who picks up the S/MIME v3 
>spec might miss the fact that their implementation won't interoperate with 
>v2 implementations unless they add (if they can) rsaEncryption.
>
>--Paul Hoffman, Director
>--Internet Mail Consortium
>
>


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id KAA12521 for ietf-smime-bks; Tue, 23 Mar 1999 10:42:21 -0800 (PST)
Received: from apollo.jgvandyke.com (apollo.jgvandyke.com [158.189.10.100]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id KAA12516 for <[e-mail]>; Tue, 23 Mar 1999 10:42:14 -0800 (PST)
Received: from ajsn101.jgvandyke.com (ajsn101.jgvandyke.com [158.189.2.101]) by apollo.jgvandyke.com (8.8.8/8.8.8) with SMTP id NAA20509 for <[e-mail]>; Tue, 23 Mar 1999 13:55:17 -0500 (EST)
Received: from ajpc81 by ajsn101.jgvandyke.com (SMI-8.6/SMI-SVR4) id NAA06673; Tue, 23 Mar 1999 13:52:30 -0500
Date: Tue, 23 Mar 1999 13:52:30 -0500
Message-Id: <[e-mail]>
X-Sender: jsp@ajsn101
X-Mailer: Windows Eudora Version 1.4.4
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
To: [e-mail]
From: [e-mail] (John Pawling)
Subject: Re: Proposed changes to the -msg draft
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

All,
I concur with Paul's proposed text.
- John Pawling



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id JAA11661 for ietf-smime-bks; Tue, 23 Mar 1999 09:23:12 -0800 (PST)
Received: from aum (ip11.proper.com [165.227.249.11]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id JAA11657 for <[e-mail]>; Tue, 23 Mar 1999 09:23:10 -0800 (PST)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.32 (Beta)
Date: Tue, 23 Mar 1999 09:28:38 -0800
To: [e-mail]
From: Paul Hoffman / IMC <[e-mail]>
Subject: Proposed changes to the -msg draft
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Greetings again. As was discussed in Minneapolis, I propose two small but 
significant changes to the -msg draft. There was pretty strong agreement in 
the room at the time, but I'm open to feedback from the list.

I propose that the following statement should be added to Section 2.2:

Note that S/MIME v2 clients are only capable of verifying digital 
signatures using the rsaEncryption algorithm.

I also propose that the following statement should be added to Sec 2.3:

Note that S/MIME v2 clients are only capable of decrypting content 
encryption keys using the rsaEncryption algorithm.

Both sentences reflect reality, not politics. However, I think it's 
important to add them because a naive developer who picks up the S/MIME v3 
spec might miss the fact that their implementation won't interoperate with 
v2 implementations unless they add (if they can) rsaEncryption.

--Paul Hoffman, Director
--Internet Mail Consortium


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id LAA03424 for ietf-smime-bks; Mon, 22 Mar 1999 11:21:47 -0800 (PST)
Received: from spyrus.com (mail.spyrus.com [207.212.34.30]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id LAA03420 for <[e-mail]>; Mon, 22 Mar 1999 11:21:46 -0800 (PST)
Received: from rhousley_laptop.spyrus.com ([209.172.119.101]) by spyrus.com (8.7.6/8.7.3/arc) with SMTP id LAA20235; Mon, 22 Mar 1999 11:28:16 -0800 (PST)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 
Date: Mon, 22 Mar 1999 00:16:56 -0500
To: Eric Rescorla <[e-mail]>
From: Russ Housley <[e-mail]>
Subject: Re: Updated draft
Cc: [e-mail]
In-Reply-To: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Eric:

I have a few comments.  Most are nit-picks.

Russ


= = = = = = = = = = 


>Abstract
>
>   This document standardizes one particular Diffie-Hellman variant,
>   based on the ANSI X9.42 draft, developed by the ANSI X9F1 working
>   group. Diffie-Hellman is a key agreement algorithm used by two par-
>   ties to agree on a shared secret. An algorithm for converting the
>   shared secret into an arbitrary amount of keying material is pro-
>   vided. The resulting keying material is used as a symmetric encryp-
>   tion key.  The D-H variant described requires the recipient to have a
>   certificate, but the originator may have a static key pair (with the
>   public key placed in a certificate) or an ephemeral key pair.

This is the only place you use the D-H abbreviation.  Please spell it out.

>2.1.  Key Agreement
>
>   The first stage of the key agreement process is to compute a shared
>   secret number, called ZZ.  When the same originator and recipient
>   public/private key pairs are used, the same ZZ value will result.
>   The ZZ value is then converted into a shared symmetric cryptographic
>   key. When the originator employs a static private/public key pair,
>   the introduction of public random values are used to ensure that the
>   resulting symmetric key will be different for each key agreement.

Please replace the last sentence.  Since onlt partyAInfo is supported, only
one public random can be used:
	When the originator employs a static private/public key pair,
	the introduction of a public random value ensures that the
	resulting symmetric key will be different for each key agreement.


>2.1.1.  Generation of ZZ
>
>   X9.42 defines that the shared secret ZZ is generated as follows:
>
>           ZZ = g ^ (xb * xa) mod p
>
>   Note that the individual parties actually perform the computations:
>
>           ZZ = yb ^ xa    (mod p) = ya ^ xb  mod p

Please pick one notation.  I think this is the only place "(mod p)" is
used.  My preference is:
	ZZ = (yb ^ xa) mod p = (ya ^ xb) mod p

>
>   where ^ denotes exponentiation
>         ya is party a's public key; ya = g ^ xa mod p
>         yb is party b's public key; yb = g ^ xb mod p
>         xa is party a's private key
>         xb is party b's private key
>         p is a large prime
>         q is a large prime
>         g = h^{(p-1)/q} mod p, where
>         h is any integer with 1 < h < p-1 such that h{(p-1)/q} mod p > 1
>           (g has order q mod p; i.e. g^q mod p = 1 if g!=1)
>         j a large integer such that p=qj + 1
>         (See Section 2.2 for criteria for keys and parameters)
>
>   In [CMS], the recipient's key is identified by the CMS RecipientIden-
>   tifier, which points to the recipient's certificate.  The sender's
>   key is identified using the OriginatorIdentifierOrKey field, either
>   by reference to the sender's certificate or by inline inclusion of a
>   key.

Please change "key" to "public key" in the last sentence.


>2.1.2.  Generation of Keying Material
>
>   [snip]
>   Note that these ASN.1 definitions use EXPLICIT tagging. (In ASN.1,
>   EXPLICIT tagging is implicit unless IMPLICIT is explicitly speci-
>   fied.)

Please move this note right before or right after the ASN.1.

>   To generate a KEK, one generates one or more KM blocks (incrementing
>   counter appropriately) until enough material has been generated.  The
>   KM blocks are concatenated left to right in the obvious order.  I.e.
>   KM(counter=1) || KM(counter=2)...

I think that "obvious order" is asking for trouble.  You are better off
deleting the phrase if you cannot think of a better way to say it.

>2.1.4.  Keylengths for common algorithms
>
>   Some common key encryption algorithms have KEKs of the following
>   lengths.
>
>           3DES-EDE-ECB    192 bits
>           RC2-128         128 bits
>           RC2-40          40 bits

Please change "3DES-EDE-ECB" to "3-key 3DES".  The mode does not determine
key lenght, but the number of keys does.  You might want to include "2-key
3DES" to make this clear.

>2.1.6.  Example 1
>
>
>   ZZ is the 20 bytes 00 01 02 03 04 05 06 07 08 09
>                      0a 0b 0c 0d 0e 0f 10 11 12 13
>
>   The key wrap algorithm is 3DES-EDE wrap.
>
>   No partyAInfo is used

Please add missing period.

>Acknowledgements
>
>   The Key Agreement method described in this document is based on work
>   done by the ANSI X9F1 working group. The author wishes to extend his
>   thanks for their assistance.
>
>   The author also wishes to thank Burt Kaliski, Paul Hoffman, Stephen
>   Henson, Russ Housley, Brian Korver, John Linn, Jim Schaad, Mark
>   Schertler, Peter Yee, and Robert Zuccherato for their expert advice
>   and review.

You may wish to use alphabetical order here.

>   [PKIX] Housley, R., Ford, W., Polk, W., Solo, D., "Internet X.509 Public
>       Key Infrastructure Certificate and CRL Profile", RFC-XXXX.

RFC 2459.  Also, add date.




Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id JAA18938 for ietf-smime-bks; Sun, 21 Mar 1999 09:03:58 -0800 (PST)
Received: from bradley.bradley.edu ([e-mail] [136.176.5.10]) by mail.proper.com (8.8.8/8.8.5) with SMTP id JAA18905; Sun, 21 Mar 1999 09:03:09 -0800 (PST)
Received: from Sports (npuntarenas1-a25.racsa.co.cr [196.40.11.154]) by bradley.bradley.edu (8.6.12/8.6.12) with SMTP id KAA16175; Sun, 21 Mar 1999 10:56:07 -0600
Message-Id: <[e-mail]>
Date: Sun, 21 Mar 99 10:50:43 EST
From: "Sports" <[e-mail]>
To: [e-mail]
Subject: Sports
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

BASEBALL & BASKETBALL SEASON PROMOTIONS

We give you a 10% bonus on your initial deposit (minimum $500 deposit -
$50 minimum bet - no maximum.) Though Western Union cash only.

We give you a FREE SPORTS PAGER
(It has injury reports, scores, weather and everything you need to know)
with $1000 or more or get the 10% bonus.

15% Match play for Friend Referral.

20% Match play on your losses every 6 months!

THAT'S 45% BONUSES JUST FOR YOU !!

1-800-973-1514 ext. 7373

Great off shore sports book that really pays out if you win!



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id SAA13592 for ietf-smime-bks; Thu, 18 Mar 1999 18:45:12 -0800 (PST)
Received: from aum (host204.44IETF.MR.Net [209.32.92.204]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id SAA13587; Thu, 18 Mar 1999 18:45:09 -0800 (PST)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.25 (Beta)
Date: Thu, 18 Mar 1999 20:51:51 -0600
To: Russ Housley <[e-mail]>, [e-mail]
From: Paul Hoffman / IMC <[e-mail]>
Subject: Re: Reminder to presentors
In-Reply-To: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

At 01:18 AM 3/18/99 -0500, Russ Housley wrote:
>Presentors:
>
>Please send me powerpoint files containing your slides for the IETF minutes.

Unfortunately, I think Blake walked off with my slide. Or maybe Russ did....

--Paul Hoffman, Director
--Internet Mail Consortium


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id NAA10400 for ietf-smime-bks; Thu, 18 Mar 1999 13:33:07 -0800 (PST)
Received: from spyrus.com (mail.spyrus.com [207.212.34.30]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id NAA10396 for <[e-mail]>; Thu, 18 Mar 1999 13:33:06 -0800 (PST)
Received: from rhousley_laptop.spyrus.com (host113.44IETF.MR.Net [209.32.92.113]) by spyrus.com (8.7.6/8.7.3/arc) with SMTP id NAA03520 for <[e-mail]>; Thu, 18 Mar 1999 13:39:30 -0800 (PST)
Message-Id: <[e-mail]>
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 
Date: Thu, 18 Mar 1999 01:18:49 -0500
To: [e-mail]
From: Russ Housley <[e-mail]>
Subject: Reminder to presentors
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Presentors:

Please send me powerpoint files containing your slides for the IETF minutes.

Russ


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id PAA01722 for ietf-smime-bks; Wed, 17 Mar 1999 15:50:12 -0800 (PST)
Received: from spyrus.com (mail.spyrus.com [207.212.34.30]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id PAA01718 for <[e-mail]>; Wed, 17 Mar 1999 15:50:11 -0800 (PST)
Received: from rhousley_laptop.spyrus.com (dial01.spyrus.com [207.212.34.121]) by spyrus.com (8.7.6/8.7.3/arc) with SMTP id PAA12768; Wed, 17 Mar 1999 15:55:28 -0800 (PST)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 
Date: Wed, 17 Mar 1999 04:45:42 -0500
To: "ross@secstan" <[e-mail]>
From: Russ Housley <[e-mail]>
Subject: Re: More on KEKIdentifiers, and a suggested addition to CMS
Cc: [e-mail]
In-Reply-To: <002a01be70a1$259945c0$1500000a@jrprotable2>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

No.  CMS will not be modified at this time to support additional
RecipiontInfo CHOICES.  This will be addressed as a separate charter item
once the current charter is fulfilled.

Russ

At 06:08 PM 3/17/99 +0000, you wrote:
>Does this mean that we have come to closure on this? i.e using:
>RecipientInfo ::= CHOICE {
>>>        ktri KeyTransRecipientInfo,
>>>        kari [1] KeyAgreeRecipientInfo,
>>>        kekri [2] KEKRecipientInfo,
>>>        kext [3] ExternalyDefinedKeyAgreement --for future or private key
>management schemes }
>>>
>>>ExternalyDefinedKeyAgreement :: = SEQUENCE {
>>>    keyTypeIdentifier ObjectIdentier,
>>>    keyTypeInfo OCTECT STRING --any defined by OID}
>>
>
>
>-----Original Message-----
>From: John Pawling <[e-mail]>
>To: ross@secstan <[e-mail]>; [e-mail] <[e-mail]>
>Date: 16 March 1999 19:50
>Subject: Re: More on KEKIdentifiers, and a suggested addition to CMS
>
>
>>John,
>>
>>Upon further investigation, your proposal (excerpted below) does not cause
>>the ASN.1 decoding problems that I thought that it would.  Contrary to what
>>I stated in yesterday's message, I agree that your proposal would allow
>>general purpose ASN.1 libraries (such as SNACC) to be able to successfully
>>decode the RecipientInfo kext CHOICE down to the keyTypeIdentifier OID and
>>keyTypeInfo OCTET STRING on the first pass.  The receiving software could
>>then examine the keyTypeIdentifier OID to determine if it is able to decode
>>the data within the keyTypeInfo OCTET STRING.  If it does not recognize the
>>OID, then it could skip the processing of this instance of RecipientInfo
>and
>>attempt to find another instance that it recognizes.  If it does not find a
>>recognized RecipientInfo CHOICE syntax that includes the recipient's
>>protected CEK, then the software would return an error.
>>
>>Also, Darren Harter's comment to change keyTypeInfo to an ANY will allow
>>general purpose ASN.1 decode libraries to be able to successfully decode
>the
>>RecipientInfo kext CHOICE down to the keyTypeIdentifier OID and keyTypeInfo
>>ANY on the first pass.  I agree with Darren's comment that the receiving
>>software could completely decode the keyTypeInfo ANY as part of the first
>>pass if it recognizes the keyTypeIdentifier OID.
>>
>>> RecipientInfo ::= CHOICE {
>>>        ktri KeyTransRecipientInfo,
>>>        kari [1] KeyAgreeRecipientInfo,
>>>        kekri [2] KEKRecipientInfo,
>>>        kext [3] ExternalyDefinedKeyAgreement --for future or private key
>>>management schemes }
>>>
>>>ExternalyDefinedKeyAgreement :: = SEQUENCE {
>>>    keyTypeIdentifier ObjectIdentier,
>>>    keyTypeInfo OCTECT STRING --any defined by OID}
>>
>>In summary, I agree that your proposal is technically feasible, but I am
>>still not sure that adding kext is the right thing to do.  This strategy
>>leads us to yet another S/MIME v3 spec that would define
>>ExternallyDefinedKeyAgreement syntaxes.  It seems that another strategy
>>would be to develop a new version of the base CMS document when the syntax
>>needs to be enhanced.
>>
>>- John Pawling
>>
>>
>>
>>At 05:11 PM 3/16/99 -0000, ross@secstan wrote:
>>>John,
>>>
>>>If the choice includes an OID extension with an OCTET STRING, then the one
>>>pass ASN.1 decoding strategy on the entire object works OK. Correct?
>>>
>>>If the implementation can support an OID extension will  it need to dig
>>>deeper into the OCTETSTRING.  Implementations that do not support any OID
>>>extension to the choice will just ignore it,  there should be no syntax or
>>>decoder failure.   The end result will be that envelopeData will decode
>>>correctly.
>>>
>>>So I favour adding the OID extension to the choice.
>>>
>>>Regards
>>>
>>>JR
>>>.
>>>
>>>
>>>
>>
>



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id KAA28960 for ietf-smime-bks; Wed, 17 Mar 1999 10:30:35 -0800 (PST)
Received: from gnasher.sol.co.uk (gnasher.sol.co.uk [194.247.64.2]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id KAA28956 for <[e-mail]>; Wed, 17 Mar 1999 10:30:23 -0800 (PST)
Received: from jrprotable2 (e1c10p1.scotland.net [148.176.234.65]) by gnasher.sol.co.uk (8.8.5/8.8.5) with SMTP id SAA22953; Wed, 17 Mar 1999 18:10:41 GMT
Message-ID: <002a01be70a1$259945c0$1500000a@jrprotable2>
From: "ross@secstan" <[e-mail]>
To: <[e-mail]>, "John Pawling" <[e-mail]>
Subject: Re: More on KEKIdentifiers, and a suggested addition to CMS
Date: Wed, 17 Mar 1999 18:08:09 -0000
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 4.72.2106.4
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Does this mean that we have come to closure on this? i.e using:
RecipientInfo ::= CHOICE {
>>        ktri KeyTransRecipientInfo,
>>        kari [1] KeyAgreeRecipientInfo,
>>        kekri [2] KEKRecipientInfo,
>>        kext [3] ExternalyDefinedKeyAgreement --for future or private key
management schemes }
>>
>>ExternalyDefinedKeyAgreement :: = SEQUENCE {
>>    keyTypeIdentifier ObjectIdentier,
>>    keyTypeInfo OCTECT STRING --any defined by OID}
>


-----Original Message-----
From: John Pawling <[e-mail]>
To: ross@secstan <[e-mail]>; [e-mail] <[e-mail]>
Date: 16 March 1999 19:50
Subject: Re: More on KEKIdentifiers, and a suggested addition to CMS


>John,
>
>Upon further investigation, your proposal (excerpted below) does not cause
>the ASN.1 decoding problems that I thought that it would.  Contrary to what
>I stated in yesterday's message, I agree that your proposal would allow
>general purpose ASN.1 libraries (such as SNACC) to be able to successfully
>decode the RecipientInfo kext CHOICE down to the keyTypeIdentifier OID and
>keyTypeInfo OCTET STRING on the first pass.  The receiving software could
>then examine the keyTypeIdentifier OID to determine if it is able to decode
>the data within the keyTypeInfo OCTET STRING.  If it does not recognize the
>OID, then it could skip the processing of this instance of RecipientInfo
and
>attempt to find another instance that it recognizes.  If it does not find a
>recognized RecipientInfo CHOICE syntax that includes the recipient's
>protected CEK, then the software would return an error.
>
>Also, Darren Harter's comment to change keyTypeInfo to an ANY will allow
>general purpose ASN.1 decode libraries to be able to successfully decode
the
>RecipientInfo kext CHOICE down to the keyTypeIdentifier OID and keyTypeInfo
>ANY on the first pass.  I agree with Darren's comment that the receiving
>software could completely decode the keyTypeInfo ANY as part of the first
>pass if it recognizes the keyTypeIdentifier OID.
>
>> RecipientInfo ::= CHOICE {
>>        ktri KeyTransRecipientInfo,
>>        kari [1] KeyAgreeRecipientInfo,
>>        kekri [2] KEKRecipientInfo,
>>        kext [3] ExternalyDefinedKeyAgreement --for future or private key
>>management schemes }
>>
>>ExternalyDefinedKeyAgreement :: = SEQUENCE {
>>    keyTypeIdentifier ObjectIdentier,
>>    keyTypeInfo OCTECT STRING --any defined by OID}
>
>In summary, I agree that your proposal is technically feasible, but I am
>still not sure that adding kext is the right thing to do.  This strategy
>leads us to yet another S/MIME v3 spec that would define
>ExternallyDefinedKeyAgreement syntaxes.  It seems that another strategy
>would be to develop a new version of the base CMS document when the syntax
>needs to be enhanced.
>
>- John Pawling
>
>
>
>At 05:11 PM 3/16/99 -0000, ross@secstan wrote:
>>John,
>>
>>If the choice includes an OID extension with an OCTET STRING, then the one
>>pass ASN.1 decoding strategy on the entire object works OK. Correct?
>>
>>If the implementation can support an OID extension will  it need to dig
>>deeper into the OCTETSTRING.  Implementations that do not support any OID
>>extension to the choice will just ignore it,  there should be no syntax or
>>decoder failure.   The end result will be that envelopeData will decode
>>correctly.
>>
>>So I favour adding the OID extension to the choice.
>>
>>Regards
>>
>>JR
>>.
>>
>>
>>
>



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id KAA28820 for ietf-smime-bks; Wed, 17 Mar 1999 10:14:46 -0800 (PST)
Received: from postoffice.mr.net (dialup.MR.Net [137.192.180.6]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id KAA28816 for <[e-mail]>; Wed, 17 Mar 1999 10:14:36 -0800 (PST)
Received: by postoffice.mr.net (8.8.8/8.8.8) with SMTP id MAA04098 at Wed, 17 Mar 1999 12:21:02 -0600 (CST) SMTP "HELO" = balenson.44ietf.mr.net But _really_ from host167.44IETF.MR.Net [209.32.92.167] SMTP "MAIL FROM" = [e-mail] SMTP "RCPT TO" = 
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0
Date: Wed, 17 Mar 1999 13:20:14 -0500
To: [e-mail]
From: "David M. Balenson" <[e-mail]>
Subject: CFP: ISOC Year 2000 Network & Distr. System Security (NDSS 2000)
Cc: [e-mail]
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

            C  A  L  L       F  O  R       P  A  P  E  R  S


                          The Internet Society
           Year 2000 Network and Distributed System Security 
                         Symposium (NDSS 2000)

             Catamaran Resort Hotel, San Diego, California
                           February 2-4, 2000


IMPORTANT DATES:

  Paper and panel submissions due: June 16, 1999
  Author notification: August 17, 1999
  Final versions of papers and panels due: October 15, 1999

GOAL: 

  This symposium aims to foster information exchange among researchers
  and practitioners of network and distributed system security
  services.  The intended audience includes those who are interested
  in practical aspects of network and distributed system security,
  with the focus on actual system design and implementation, rather
  than theory. A major goal of the symposium is to encourage and
  enable the Internet community to apply, deploy, and advance the
  state of available security technology.  The proceedings of the
  symposium will be published by the Internet Society.

  Submissions are solicited for, but are not limited to, the
  following topics:

  * Secure Electronic Commerce, e.g., payment, barter, EDI,
    notarization/timestamping, endorsement and licensing.
  * Intellectual Property Protection: protocols, schemas,
    implementations, metering, watermarking, other forms of rights
    management.
  * Implementation, deployment and management of network security
    policies.
  * Integrating Security in Internet protocols: routing, naming,
    TCP/IP, multicast, network management, and, of course, the Web.
  * Attack-resistant protocols and services.
  * Special problems and case studies: e.g. interplay and tradeoffs
    between security and efficiency, usability, reliability and cost.
  * Security for collaborative applications and services: tele- and
    video-conferencing, groupwork, etc.
  * Fundamental services: authentication, data integrity,
    confidentiality, authorization, non-repudiation, and availability.
  * Supporting mechanisms and APIs: key management and certification,
    revocation, audit trails and accountability.
  * Integrating security services with system and application security
    facilities and protocols, e.g., message handling, file
    transport/access, directories, time synchronization, data base

    management, boot services, mobile computing.
  * Security for emerging technologies -- sensor networks, specialized
    testbeds, wireless/mobile (and ad hoc) networks, personal
    communication systems, and large heterogeneous distributed systems.
  * Intrusion Avoidance, Detection, and Response: systems, experiences
    and architectures
  * Network Perimeter Controls: firewalls, packet filters, application
    gateways.

BEST PAPER AWARD:

  A best paper award will be introduced at NDSS 2000. This award will
  be presented at the symposium to the authors of the best paper to
  be selected by the program committee.

GENERAL CHAIR:
  Stephen Welke, Trusted Computer Solutions

PROGRAM CO-CHAIRS:
  Gene Tsudik, USC / Information Sciences Institute
  Avi Rubin, AT&T Labs - Research

TUTORIAL CHAIR:
  Doug Maughan, NSA / DARPA

PROGRAM COMMITTEE:
  Bill Cheswick, Lucent Bell Labs  
  Marc Dacier, IBM Research Zurich 
  Jim Ellis, CMU / CERT
  Carl Ellison, Intel   
  Ed Felten, Princeton  
  Virgil Gligor, UMD College Park 
  Thomas Hardjono, Bay Networks/Nortel
  Cynthia Irvine, Naval Postgraduate School
  Charlie Kaufman,  Iris Associates
  Dave Kormann, AT&T Labs - Research 
  Hugo Krawczyk, Technion and IBM
  Carl Landwehr, Naval Research Lab
  Doug Maughan, NSA / DARPA   
  Gary McGraw, Reliable Software Technologies  
  Sandra Murphy, TIS Labs at Network Associates   
  Clifford Neuman, USC / Information Sciences Institute
  Paul Van Oorschot, Entrust
  Sami Saydjari, DARPA ISO 
  David Wagner, UC Berkeley   
  Bennet Yee, UC San Diego

LOCAL ARRANGEMENTS CHAIR:
  Thomas Hutton, San Diego Supercomputer Center

PUBLICATIONS CHAIR:
  John Kochmar, SEI

PUBLICITY CHAIR:
  David Balenson, TIS Labs at Network Associates   

LOGISTICS CHAIR:
  Carla Rosenfeld, Internet Society

REGISTRATIONS CHAIR
  Beth Strait, Internet Society

SUBMISSIONS: 

  The committee invites both technical papers and panel proposals.
  Technical papers should be at most 20 pages long. Panel proposals
  should be at most two pages and should describe the topic, identify
  the panel chair, explain the format of the panel, and list three
  to four potential panelists.  Technical papers will appear in
  the proceedings. A description of each panel will appear in the
  proceedings, and may -- at the discretion of the panel chair --
  include written position statements from the panelists.

  Each submission must contain a separate title page with the type
  of submission (paper or panel), the title or topic, the names of
  the author(s), organizational affiliation(s), telephone and FAX
  numbers, postal addresses, e-mail addresses, and must specify
  the contact author in case of multi-author submissions. The names
  of authors, affiliations, and other identifying information should
  appear only on the separate title page.

  Submissions must be received by June 16, 1999, and must be made
  via electronic mail in either PostScript or ASCII format.  If
  the committee is unable to print a PostScript submission, a
  hardcopy will be requested. Therefore, PostScript submissions
  must arrive well before the deadline.

  All submissions and program related correspondence (only) should
  be directed to the program chair:

        Gene Tsudik     
        USC Information Sciences Institute      
        4676 Admiralty Way      
        Marina Del Rey, CA 90292        
        Email: [e-mail]
        TEL: [phone] ext 329
        FAX: [phone] 

  Dates, final call for papers, advance program, and registration
  information will be available soon at the URL: httl//www.isoc.org/ndss2000.

  Each submission will be acknowledged by e-mail.  If acknowledgment
  is not received within seven days, please contact the program
  chair as indicated above.  Authors and panelists will be notified

  of acceptance by August 17, 1999.  Instructions for preparing
  camera-ready copy for the proceedings will be sent at that time.
  The camera-ready copy must be received by October 15, 1999.


----------------------------------------------------------------------
David M. Balenson, Cryptographic Technologies Group
TIS Labs at Network Associates, Inc.
3060 Washington Road, Suite 100, Glenwood, MD 21738  USA
[e-mail]; 443-259-2358; fax [phone]
pgp fingerprints FD53 918E 097A 2579 C1A8  34F8 E05D E74F AC1D E184 (DSS/DH)
                 D43B 565B 2C0E 90F4  38BB D9EA 1454 3264 (RSA)



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id AAA21269 for ietf-smime-bks; Wed, 17 Mar 1999 00:34:36 -0800 (PST)
Received: from barbar.esat.kuleuven.ac.be ([e-mail] [134.58.56.153]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id AAA21263; Wed, 17 Mar 1999 00:34:31 -0800 (PST)
Received: from domus.esat.kuleuven.ac.be (domus.esat.kuleuven.ac.be [134.58.189.68]) by barbar (version 8.8.5)  with ESMTP id JAA17405; Wed, 17 Mar 1999 09:40:04 +0100 (MET)
Organization: ESAT, K.U.Leuven, Belgium
Date: Wed, 17 Mar 1999 09:40:04 +0100 (MET)
From: "CMS'99" <[e-mail]>
To: [e-mail]
Subject: Communications and Multimedia Security '99
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

[Apologies if you receive this more than once]

NEW DEADLINE FOR THE CMS'99 CONFERENCE: 

April 2nd, 1999

The call for papers can be found at 
http://www.esat.kuleuven.ac.be/cosic/cms99/





Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id VAA15701 for ietf-smime-bks; Tue, 16 Mar 1999 21:19:15 -0800 (PST)
Received: from ns2.walltech.com (ns2.walltech.com [208.195.156.18]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id VAA15694 for <[e-mail]>; Tue, 16 Mar 1999 21:19:14 -0800 (PST)
Received: from iris (user47.sj.dialup.innetix.com [209.172.68.110]) by ns2.walltech.com (8.8.7/8.8.7/walltech-1.28h) with SMTP id VAA01258; Tue, 16 Mar 1999 21:25:34 -0800 (PST)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Light Version 3.0.6 (32)
Date: Tue, 16 Mar 1999 21:24:54 -0800
To: Russ Housley <[e-mail]>
From: Bruce Greenblatt <[e-mail]>
Subject: Re: More on KEKIdentifiers, and a suggested addition to CMS
Cc: [e-mail]
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <00e901be6c2a$ded01e40$0400000a@jrwork>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

At 12:07 AM 3/17/99 -0500, Russ Housley wrote:
>No.  The current document meets all of the original requirements.  We are
>considering an enhancement that is beyond the original charter.
>
>Russ
>

Thanks for the clarification.  As long as the enhancement to the protocol
doesn't "break" conformant implementations, I think that you and Paul are
right that the process won't be held up.  I thought that I read that an
extension mechanism was going to be put in between PS and DS that would
change the protocol in such a way that implementations that conformed to
the PS version of CMS might get confused by the DS version of the protocol.
 Obviously, this would be a bad thing.

Bruce
================================================
Bruce Greenblatt             
[e-mail]
http://www.directory-applications.com
================================================


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id VAA14548 for ietf-smime-bks; Tue, 16 Mar 1999 21:08:46 -0800 (PST)
Received: from spyrus.com (mail.spyrus.com [207.212.34.30]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id VAA14542 for <[e-mail]>; Tue, 16 Mar 1999 21:08:45 -0800 (PST)
Received: from rhousley_laptop.spyrus.com (dial03.spyrus.com [207.212.34.123]) by spyrus.com (8.7.6/8.7.3/arc) with SMTP id VAA23610; Tue, 16 Mar 1999 21:14:10 -0800 (PST)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 
Date: Wed, 17 Mar 1999 00:07:30 -0500
To: Bruce Greenblatt <[e-mail]>
From: Russ Housley <[e-mail]>
Subject: Re: More on KEKIdentifiers, and a suggested addition to CMS
Cc: [e-mail]
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]> <00e901be6c2a$ded01e40$0400000a@jrwork>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

No.  The current document meets all of the original requirements.  We are
considering an enhancement that is beyond the original charter.

Russ

At 09:49 AM 3/16/99 -0800, Bruce Greenblatt wrote:
>At 05:22 PM 3/13/99 -0500, Russ Housley wrote:
>>All:
>>
>>I agree with Paul Hoffman.  We should proceed with CMS so that the S/MIME
>>v3 set of documents can become Proposed Standards.  Using the list, we can
>>discuss the best way to handle password-based key management.  We can do as
>>many Internet-Drafts as necessary to sort this out.  Once we reach
>>concensus, we can add the that technique to CMS when the document
>>progresses from Proposed Standard to Draft Standard.
>>
>
>I have a question about this.  Are you producing a document with a known
>deficiency that you intend to correct later in the standards process?  It
>appears to me that making the change that has been suggested using the
>extension mechanism after it has been released as PS would likely cause CMS
>to move backwards in the standards process, and not forwards.  Thus, the
>whole process would be substantially delayed.  You're better off correcting
>the problem now with the "..." or extension mechanism or whatever as part
>of WG last call, and moving on rather than attempting to correct it later,
>and then being shifted back in the standardization process...
>
>Bruce
>================================================
>Bruce Greenblatt             
>[e-mail]
>http://www.directory-applications.com
>================================================



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id MAA25519 for ietf-smime-bks; Tue, 16 Mar 1999 12:12:40 -0800 (PST)
Received: from aum (ts010d12.min-mn.concentric.net [209.31.113.216]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id MAA25514; Tue, 16 Mar 1999 12:12:30 -0800 (PST)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.25 (Beta)
Date: Tue, 16 Mar 1999 12:56:40 -0600
To: Bruce Greenblatt <[e-mail]>, Russ Housley <[e-mail]>, [e-mail]
From: Paul Hoffman / IMC <[e-mail]>
Subject: Re: More on KEKIdentifiers, and a suggested addition to CMS
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]> <00e901be6c2a$ded01e40$0400000a@jrwork>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

>I have a question about this.  Are you producing a document with a known
>deficiency that you intend to correct later in the standards process?

There is a difference between a deficiency and a security flaw. The desire 
for passwords was brought up very late in the process, an indication that 
there are not pressing market needs for it. It would be nice to have, but 
there are significant technical issues, and thus Peter is proposing an 
extension to CMS.

>  It
>appears to me that making the change that has been suggested using the
>extension mechanism after it has been released as PS would likely cause CMS
>to move backwards in the standards process, and not forwards.

I don't understand why. The separate proposal does not have to be bound to 
CMS. If we want to later bind it to CMS, we can postpone going from 
Proposed Standard to Draft Standard by enough months to let the extension 
catch up. Otherwise, they can independently move to Draft Standard. Both 
are quite common in the IETF.

>  Thus, the
>whole process would be substantially delayed.

Just the opposite: there is no delay at all.

>  You're better off correcting
>the problem now with the "..." or extension mechanism or whatever as part
>of WG last call, and moving on rather than attempting to correct it later,
>and then being shifted back in the standardization process...

I respectfully disagree.


--Paul Hoffman, Director
--Internet Mail Consortium


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id LAA25138 for ietf-smime-bks; Tue, 16 Mar 1999 11:29:08 -0800 (PST)
Received: from apollo.jgvandyke.com (apollo.jgvandyke.com [158.189.10.100]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id LAA25134 for <[e-mail]>; Tue, 16 Mar 1999 11:29:07 -0800 (PST)
Received: from ajsn101.jgvandyke.com (ajsn101.jgvandyke.com [158.189.2.101]) by apollo.jgvandyke.com (8.8.8/8.8.8) with SMTP id OAA10530; Tue, 16 Mar 1999 14:41:30 -0500 (EST)
Received: from ajpc81 by ajsn101.jgvandyke.com (SMI-8.6/SMI-SVR4) id OAA13129; Tue, 16 Mar 1999 14:38:49 -0500
Date: Tue, 16 Mar 1999 14:38:49 -0500
Message-Id: <[e-mail]>
X-Sender: jsp@ajsn101
X-Mailer: Windows Eudora Version 1.4.4
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
To: "ross@secstan" <[e-mail]>, <[e-mail]>
From: [e-mail] (John Pawling)
Subject: Re: More on KEKIdentifiers, and a suggested addition to CMS
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

John,

Upon further investigation, your proposal (excerpted below) does not cause
the ASN.1 decoding problems that I thought that it would.  Contrary to what
I stated in yesterday's message, I agree that your proposal would allow
general purpose ASN.1 libraries (such as SNACC) to be able to successfully
decode the RecipientInfo kext CHOICE down to the keyTypeIdentifier OID and
keyTypeInfo OCTET STRING on the first pass.  The receiving software could
then examine the keyTypeIdentifier OID to determine if it is able to decode
the data within the keyTypeInfo OCTET STRING.  If it does not recognize the
OID, then it could skip the processing of this instance of RecipientInfo and
attempt to find another instance that it recognizes.  If it does not find a
recognized RecipientInfo CHOICE syntax that includes the recipient's
protected CEK, then the software would return an error.  

Also, Darren Harter's comment to change keyTypeInfo to an ANY will allow
general purpose ASN.1 decode libraries to be able to successfully decode the
RecipientInfo kext CHOICE down to the keyTypeIdentifier OID and keyTypeInfo
ANY on the first pass.  I agree with Darren's comment that the receiving
software could completely decode the keyTypeInfo ANY as part of the first
pass if it recognizes the keyTypeIdentifier OID. 

> RecipientInfo ::= CHOICE {
>        ktri KeyTransRecipientInfo,
>        kari [1] KeyAgreeRecipientInfo,
>        kekri [2] KEKRecipientInfo,
>        kext [3] ExternalyDefinedKeyAgreement --for future or private key
>management schemes }
>
>ExternalyDefinedKeyAgreement :: = SEQUENCE {
>    keyTypeIdentifier ObjectIdentier,
>    keyTypeInfo OCTECT STRING --any defined by OID}

In summary, I agree that your proposal is technically feasible, but I am
still not sure that adding kext is the right thing to do.  This strategy
leads us to yet another S/MIME v3 spec that would define
ExternallyDefinedKeyAgreement syntaxes.  It seems that another strategy
would be to develop a new version of the base CMS document when the syntax
needs to be enhanced.  

- John Pawling



At 05:11 PM 3/16/99 -0000, ross@secstan wrote:
>John,
>
>If the choice includes an OID extension with an OCTET STRING, then the one
>pass ASN.1 decoding strategy on the entire object works OK. Correct?
>
>If the implementation can support an OID extension will  it need to dig
>deeper into the OCTETSTRING.  Implementations that do not support any OID
>extension to the choice will just ignore it,  there should be no syntax or
>decoder failure.   The end result will be that envelopeData will decode
>correctly.
>
>So I favour adding the OID extension to the choice.
>
>Regards
>
>JR
>.
>
>
>



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id KAA24761 for ietf-smime-bks; Tue, 16 Mar 1999 10:57:33 -0800 (PST)
Received: from smtp2.erols.com (smtp2.erols.com [207.172.3.235]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id KAA24756 for <[e-mail]>; Tue, 16 Mar 1999 10:57:24 -0800 (PST)
Received: from fujitsu1.ny.certco.com (207-172-111-51.s51.tnt1.ann.va.dialup.rcn.com [207.172.111.51]) by smtp2.erols.com (8.8.8/8.8.5) with ESMTP id OAA07595; Tue, 16 Mar 1999 14:08:13 -0500 (EST)
Message-Id: <[e-mail]>
Reply-To: <[e-mail]>
From: "Rich Ankney" <[e-mail]>
To: "ross@secstan" <[e-mail]>, <[e-mail]>, "John Pawling" <[e-mail]>
Subject: Re: More on KEKIdentifiers, and a suggested addition to CMS
Date: Tue, 16 Mar 1999 14:03:58 -0500
X-MSMail-Priority: Normal
X-Priority: 3
X-Mailer: Microsoft Internet Mail 4.70.1161
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

I agree with this approach.  Otherwise I'd like to reserve the version
number 73, for X9.73 with CKM key management :-)

/ Rich

----------
> From: ross@secstan <[e-mail]>
> To: [e-mail]; John Pawling <[e-mail]>
> Subject: Re: More on KEKIdentifiers, and a suggested addition to CMS
> Date: Tuesday, March 16, 1999 12:11 PM
> 
> John,
> 
> If the choice includes an OID extension with an OCTET STRING, then the
one
> pass ASN.1 decoding strategy on the entire object works OK. Correct?
> 
> If the implementation can support an OID extension will  it need to dig
> deeper into the OCTETSTRING.  Implementations that do not support any OID
> extension to the choice will just ignore it,  there should be no syntax
or
> decoder failure.   The end result will be that envelopeData will decode
> correctly.
> 
> So I favour adding the OID extension to the choice.
> 
> Regards
> 
> JR
> .
> 
> 
> 
> -----Original Message-----
> From: John Pawling <[e-mail]>
> To: [e-mail] <[e-mail]>
> Date: 15 March 1999 16:21
> Subject: Re: More on KEKIdentifiers, and a suggested addition to CMS
> 
> 
> >John,
> >
> >You stated:
> >>I agree with Peter, CMS should allow the extension of the Choice syntax
> >> i.e. in text using  the old ASN.1 rules), which gives a good pointer
to
> the
> >>implementors that they should not object if the they receive an
extended
> >>choice.
> >
> >I agree that the CMS RecipientInfo CHOICE syntax could be modified in
> future
> >versions of CMS through the addition of well-defined ASN.1 syntaxes, but
I
> >disagree that adding "..." in the current CMS RecipientInfo syntax adds
any
> >value.  If your use of "extended choice" refers to a RecipientInfo
> including
> >a CHOICE alternative not specified in the CMS document, then I object to
> >your statement that implementors "should not object if the they receive
an
> >extended choice."  Please see my previous message for the explanation of
> why
> >I object to the premise that it is straightforward for recipient
software
> to
> >ignore undefined CHOICE alternatives.
> >
> >- John Pawling
> >


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id JAA23668 for ietf-smime-bks; Tue, 16 Mar 1999 09:43:43 -0800 (PST)
Received: from ns2.walltech.com (ns2.walltech.com [208.195.156.18]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id JAA23664 for <[e-mail]>; Tue, 16 Mar 1999 09:43:42 -0800 (PST)
Received: from iris (user51.sj.dialup.innetix.com [209.172.68.114]) by ns2.walltech.com (8.8.7/8.8.7/walltech-1.28h) with SMTP id JAA12013; Tue, 16 Mar 1999 09:49:55 -0800 (PST)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Light Version 3.0.6 (32)
Date: Tue, 16 Mar 1999 09:49:10 -0800
To: Russ Housley <[e-mail]>, [e-mail]
From: Bruce Greenblatt <[e-mail]>
Subject: Re: More on KEKIdentifiers, and a suggested addition to CMS
In-Reply-To: <[e-mail]>
References: <[e-mail]> <00e901be6c2a$ded01e40$0400000a@jrwork>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

At 05:22 PM 3/13/99 -0500, Russ Housley wrote:
>All:
>
>I agree with Paul Hoffman.  We should proceed with CMS so that the S/MIME
>v3 set of documents can become Proposed Standards.  Using the list, we can
>discuss the best way to handle password-based key management.  We can do as
>many Internet-Drafts as necessary to sort this out.  Once we reach
>concensus, we can add the that technique to CMS when the document
>progresses from Proposed Standard to Draft Standard.
>

I have a question about this.  Are you producing a document with a known
deficiency that you intend to correct later in the standards process?  It
appears to me that making the change that has been suggested using the
extension mechanism after it has been released as PS would likely cause CMS
to move backwards in the standards process, and not forwards.  Thus, the
whole process would be substantially delayed.  You're better off correcting
the problem now with the "..." or extension mechanism or whatever as part
of WG last call, and moving on rather than attempting to correct it later,
and then being shifted back in the standardization process...

Bruce
================================================
Bruce Greenblatt             
[e-mail]
http://www.directory-applications.com
================================================


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id JAA23234 for ietf-smime-bks; Tue, 16 Mar 1999 09:07:32 -0800 (PST)
Received: from gnasher.sol.co.uk (gnasher.sol.co.uk [194.247.65.2]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id JAA23230 for <[e-mail]>; Tue, 16 Mar 1999 09:07:30 -0800 (PST)
Received: from jrprotable2 (e1c6p55.scotland.net [148.176.233.119]) by gnasher.sol.co.uk (8.8.5/8.8.5) with SMTP id RAA15391; Tue, 16 Mar 1999 17:13:55 GMT
Message-ID: <000c01be6fd0$0e86f980$1500000a@jrprotable2>
From: "ross@secstan" <[e-mail]>
To: <[e-mail]>, "John Pawling" <[e-mail]>
Subject: Re: More on KEKIdentifiers, and a suggested addition to CMS
Date: Tue, 16 Mar 1999 17:11:34 -0000
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 4.72.2106.4
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

John,

If the choice includes an OID extension with an OCTET STRING, then the one
pass ASN.1 decoding strategy on the entire object works OK. Correct?

If the implementation can support an OID extension will  it need to dig
deeper into the OCTETSTRING.  Implementations that do not support any OID
extension to the choice will just ignore it,  there should be no syntax or
decoder failure.   The end result will be that envelopeData will decode
correctly.

So I favour adding the OID extension to the choice.

Regards

JR
.



-----Original Message-----
From: John Pawling <[e-mail]>
To: [e-mail] <[e-mail]>
Date: 15 March 1999 16:21
Subject: Re: More on KEKIdentifiers, and a suggested addition to CMS


>John,
>
>You stated:
>>I agree with Peter, CMS should allow the extension of the Choice syntax
>> i.e. in text using  the old ASN.1 rules), which gives a good pointer to
the
>>implementors that they should not object if the they receive an extended
>>choice.
>
>I agree that the CMS RecipientInfo CHOICE syntax could be modified in
future
>versions of CMS through the addition of well-defined ASN.1 syntaxes, but I
>disagree that adding "..." in the current CMS RecipientInfo syntax adds any
>value.  If your use of "extended choice" refers to a RecipientInfo
including
>a CHOICE alternative not specified in the CMS document, then I object to
>your statement that implementors "should not object if the they receive an
>extended choice."  Please see my previous message for the explanation of
why
>I object to the premise that it is straightforward for recipient software
to
>ignore undefined CHOICE alternatives.
>
>- John Pawling
>



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id HAA22280 for ietf-smime-bks; Tue, 16 Mar 1999 07:28:53 -0800 (PST)
Received: from spyrus.com (mail.spyrus.com [207.212.34.30]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id HAA22276 for <[e-mail]>; Tue, 16 Mar 1999 07:28:51 -0800 (PST)
Received: from rhousley_laptop.spyrus.com (dial01.spyrus.com [207.212.34.121]) by spyrus.com (8.7.6/8.7.3/arc) with SMTP id HAA06021 for <[e-mail]>; Tue, 16 Mar 1999 07:34:47 -0800 (PST)
Message-Id: <[e-mail]>
Message-Id: <[e-mail]>
X-Sender: [e-mail] (Unverified)
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 
Date: Sat, 13 Mar 1999 17:22:21 -0500
To: [e-mail]
From: Russ Housley <[e-mail]>
Subject: Re: More on KEKIdentifiers, and a suggested addition to CMS
In-Reply-To: <[e-mail]>
References: <00e901be6c2a$ded01e40$0400000a@jrwork>
Mime-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

All:

I agree with Paul Hoffman.  We should proceed with CMS so that the S/MIME
v3 set of documents can become Proposed Standards.  Using the list, we can
discuss the best way to handle password-based key management.  We can do as
many Internet-Drafts as necessary to sort this out.  Once we reach
concensus, we can add the that technique to CMS when the document
progresses from Proposed Standard to Draft Standard.

Of the suggestions discussed so far, I am leaning toward the one made by
Magnus Nyström.  This seems to provide all of the capability needed for
PKCS#15.

On the other hand, the proposal made by Rich Ankney (and seconded by John
Ross) provides a open solution for new techniques are they are needed.  I
have concerns that this may not be the best solution for interoperability.
Rich can you post the ANSI X9F3 requirements for CKM?  Please start a new
thread for that topic.

Russ


At 01:53 PM 3/11/99 -0800, Paul Hoffman / IMC wrote:
>Folks:
>
>Peter has posted an Internet Draft for an addition to CMS. I think it is 
>very late for us to be adding things for which there is disagreement on how 
>to put it in. We can discuss Peter's draft and decide if we want to pass it 
>out of the working group. If we do, it can be a stand-alone RFC. If it gets 
>two independent implementations, we might fold it into the CMS RFC (if we 
>ever get there.....) when we move from Proposed Standard to Draft Standard.
>
>--Paul Hoffman, Director
>--Internet Mail Consortium


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id UAA23531 for ietf-smime-bks; Mon, 15 Mar 1999 20:20:49 -0800 (PST)
Received: from mail.student.auckland.ac.nz (mail.student.auckland.ac.nz [130.216.35.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id UAA23522 for <[e-mail]>; Mon, 15 Mar 1999 20:20:46 -0800 (PST)
Received: from cs26.cs.auckland.ac.nz ([e-mail] [130.216.36.9]) by mail.student.auckland.ac.nz (8.8.6/8.8.6/cs-master) with SMTP id RAA32147; Tue, 16 Mar 1999 17:27:07 +1300 (NZDT) (sender [e-mail])
Received: by cs26.cs.auckland.ac.nz (relaymail v0.9) id <92155842632353>; Tue, 16 Mar 1999 17:27:06 (NZDT)
From: [e-mail] (Peter Gutmann)
To: [e-mail], [e-mail]
Subject: Re: More on KEKIdentifiers, and a suggested addition to CMS
Reply-To: [e-mail]
X-Charge-To: pgut001
X-Authenticated: relaymail v0.9 on cs26.cs.auckland.ac.nz
Date: Tue, 16 Mar 1999 17:27:06 (NZDT)
Message-ID: <[e-mail]>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

"John Ross" <[e-mail]> writes:
 
>I also agree with John Pawling, that any extension must be controlled and
>should only be done when there is a requirement not met by the current syntax.
>As per Peter's comment, control of the choice can be achieved by the normal
>RFC process.  Also, if more control is required on S/MIME for interoperability
>reasons, the S/MIME specification (not the CMS spec) could prohibit the
>expansion of the choice unless a new version number is agreed.
 
This sounds like a good way to handle it, that way MSG can profile the stuff
specifically required for S/MIME leaving CMS able to be extended to handle
things which aren't necessarily useful for S/MIME, but are useful for other
applications (things like protection of stored data, of which PKCS #15 is a
prime example).
 
Peter.
 



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id HAA13690 for ietf-smime-bks; Mon, 15 Mar 1999 07:45:58 -0800 (PST)
Received: from apollo.jgvandyke.com (apollo.jgvandyke.com [158.189.10.100]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id HAA13686 for <[e-mail]>; Mon, 15 Mar 1999 07:45:57 -0800 (PST)
Received: from ajsn101.jgvandyke.com (ajsn101.jgvandyke.com [158.189.2.101]) by apollo.jgvandyke.com (8.8.8/8.8.8) with SMTP id KAA03684 for <[e-mail]>; Mon, 15 Mar 1999 10:58:17 -0500 (EST)
Received: from ajpc81 by ajsn101.jgvandyke.com (SMI-8.6/SMI-SVR4) id KAA27654; Mon, 15 Mar 1999 10:55:37 -0500
Date: Mon, 15 Mar 1999 10:55:37 -0500
Message-Id: <[e-mail]>
X-Sender: jsp@ajsn101
X-Mailer: Windows Eudora Version 1.4.4
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
To: <[e-mail]>
From: [e-mail] (John Pawling)
Subject: Re: More on KEKIdentifiers, and a suggested addition to CMS
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

John,

You stated:
>I agree with Peter, CMS should allow the extension of the Choice syntax
> i.e. in text using  the old ASN.1 rules), which gives a good pointer to the
>implementors that they should not object if the they receive an extended
>choice.

I agree that the CMS RecipientInfo CHOICE syntax could be modified in future
versions of CMS through the addition of well-defined ASN.1 syntaxes, but I
disagree that adding "..." in the current CMS RecipientInfo syntax adds any
value.  If your use of "extended choice" refers to a RecipientInfo including
a CHOICE alternative not specified in the CMS document, then I object to
your statement that implementors "should not object if the they receive an
extended choice."  Please see my previous message for the explanation of why
I object to the premise that it is straightforward for recipient software to
ignore undefined CHOICE alternatives. 

- John Pawling



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id HAA13603 for ietf-smime-bks; Mon, 15 Mar 1999 07:32:29 -0800 (PST)
Received: from apollo.jgvandyke.com (apollo.jgvandyke.com [158.189.10.100]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id HAA13599 for <[e-mail]>; Mon, 15 Mar 1999 07:32:27 -0800 (PST)
Received: from ajsn101.jgvandyke.com (ajsn101.jgvandyke.com [158.189.2.101]) by apollo.jgvandyke.com (8.8.8/8.8.8) with SMTP id KAA03353 for <[e-mail]>; Mon, 15 Mar 1999 10:44:48 -0500 (EST)
Received: from ajpc81 by ajsn101.jgvandyke.com (SMI-8.6/SMI-SVR4) id KAA27413; Mon, 15 Mar 1999 10:42:07 -0500
Date: Mon, 15 Mar 1999 10:42:07 -0500
Message-Id: <[e-mail]>
X-Sender: jsp@ajsn101
X-Mailer: Windows Eudora Version 1.4.4
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
To: [e-mail]
From: [e-mail] (John Pawling)
Subject: Re: More on KEKIdentifiers, and a suggested addition to CMS
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Peter,

I still oppose the addition of "..." to the CMS RecipientInfo syntax.  IMHO,
"..." does not add any value to the document.  Implementors realize that the
S/MIME v3 documents are subject to enhancements.  If people need to add a
CHOICE to the CMS RecipientInfo syntax, then they need to propose a specific
syntax and accompanying text for inclusion in CMS.  


You stated: "- if you don't recognise a CHOICE alternative, you skip it and
continue." 

If you were talking about v3 cert extensions or signedAttributes, I would
agree with your "skip it and continue" strategy for unrecognized syntaxes.
In the case of a CHOICE syntax, I disagree that it is straightforward to
"skip" an unrecognized CHOICE alternative.  Most S/MIME implementations use
an ASN.1 decoding strategy by which the entire object (i.e. envelopedData,
signedData, etc) is decoded via a single call to an ASN.1 library that
implements general purpose ASN.1 decoding rules.  In this case, there is no
easy way to "skip" an unrecognized CHOICE syntax.  That is an error
condition.  For example, if a RecipientInfo includes a CHOICE alternative
not defined in the CMS standard, then the decoding software returns an error
when attempting to decode the object.  I believe that you will find that the
vast majority of S/MIME implementations work in this fashion.  For example,
the S/MIME Freeware Library calls the freeware SNACC ASN.1 library to decode
objects.  The SNACC ASN.1 library is capable of using general purpose ASN.1
rules to decode the ASN.1 syntaxes included in the ASN.1 modules provided at
compile time (ex: CMS ASN.1 module).  If the SNACC library encounters an
unrecognized CHOICE alternative, it returns an error.  There is no easy way
to add code to handle a special case like "skip an unrecognized CHOICE
alternative in recipientInfo".  


>This is why I asked for '...' (or text to that effect for those still stuck
>with ASN.1:1988) be added to CMS, it means it'll be possible to extend the
>CHOICE in the future with further RFC's without requiring an update to CMS
>itself (I believe this was the same rationale behind X.500's Name CHOICE).

I don't like the idea of splitting a CHOICE syntax definition between
multiple documents.  IMHO, that is OK for defining attributes and
extensions, but not CHOICEs.    

=========================================================
John Pawling,  Director - Systems Engineering
J.G. Van Dyke & Associates, Inc., a Wang Global Company
=========================================================




Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id BAA08771 for ietf-smime-bks; Mon, 15 Mar 1999 01:16:13 -0800 (PST)
Received: from gnasher.sol.co.uk (gnasher.sol.co.uk [194.247.64.2]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id BAA08767 for <[e-mail]>; Mon, 15 Mar 1999 01:16:11 -0800 (PST)
Received: from jrwork (e2c9p51.scotland.net [148.176.238.51]) by gnasher.sol.co.uk (8.8.5/8.8.5) with SMTP id JAA06531; Mon, 15 Mar 1999 09:22:11 GMT
Message-ID: <002c01be6f07$c0709350$0400000a@jrwork>
From: "John Ross" <[e-mail]>
To: <[e-mail]>, <[e-mail]>
Subject: Re: More on KEKIdentifiers, and a suggested addition to CMS
Date: Mon, 15 Mar 1999 09:17:38 -0800
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 4.72.3110.5
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

I agree with Peter, CMS should allow the extension of the Choice syntax
 i.e. in text using  the old ASN.1 rules), which gives a good pointer to the
implementors that they should not object if the they receive an extended
choice.

I also agree with John Pawling, that any extension must be controlled and
should only be done when there is a requirement not met by the current
syntax. As per Peter's comment, control of the choice can be achieved by the
normal RFC process.  Also, if more control is required on S/MIME for
interoperability reasons, the S/MIME specification  (not the CMS spec) could
prohibit the expansion of the choice unless a new version number is agreed.


Regards
JR




Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id JAA27589 for ietf-smime-bks; Sun, 14 Mar 1999 09:18:17 -0800 (PST)
Received: from darius.concentric.net (darius.concentric.net [207.155.198.79]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id JAA27583 for <[e-mail]>; Sun, 14 Mar 1999 09:18:15 -0800 (PST)
Received: from newman.concentric.net (newman [207.155.198.71]) by darius.concentric.net (8.9.1a/(98/12/15 5.12)) id MAA25207; Sun, 14 Mar 1999 12:24:36 -0500 (EST) [1-800-745-2747 The Concentric Network]
Received: from aum (ts007d12.min-mn.concentric.net [209.31.113.72]) by newman.concentric.net (8.9.1a) id MAA28927; Sun, 14 Mar 1999 12:24:35 -0500 (EST)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.25 (Beta)
Date: Sun, 14 Mar 1999 11:24:13 -0600
To: [e-mail]
From: Paul Hoffman / IMC <[e-mail]>
Subject: Temporary version of CMS KEA and SKIPJACK conventions
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

I've posted a temporary copy of the first draft of the "CMS KEA and 
SKIPJACK Conventions"
Internet-Draft at <http://www.imc.org/ietf-smime/temp-cmskea.txt>. John 
Pawling passes along this information:

This document describes the
conventions for using the CMS EnvelopedData and EncryptedData content types
with the Key Exchange Algorithm (KEA) and SKIPJACK encryption algorithm.
The intent of this document is to promote interoperability between
implementations using the FORTEZZA suite of algorithms with CMS.

This document may be discussed at the IETF meeting this week.

--Paul Hoffman, Director
--Internet Mail Consortium


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id HAA21492 for ietf-smime-bks; Sat, 13 Mar 1999 07:54:40 -0800 (PST)
Received: from mail.student.auckland.ac.nz (mail.student.auckland.ac.nz [130.216.35.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id HAA21488 for <[e-mail]>; Sat, 13 Mar 1999 07:54:37 -0800 (PST)
Received: from cs26.cs.auckland.ac.nz ([e-mail] [130.216.36.9]) by mail.student.auckland.ac.nz (8.8.6/8.8.6/cs-master) with SMTP id FAA15506 for <[e-mail]>; Sun, 14 Mar 1999 05:00:49 +1300 (NZDT) (sender [e-mail])
Received: by cs26.cs.auckland.ac.nz (relaymail v0.9) id <92134084901635>; Sun, 14 Mar 1999 05:00:49 (NZDT)
From: [e-mail] (Peter Gutmann)
To: [e-mail]
Subject: Re: More on KEKIdentifiers, and a suggested addition to CMS
Reply-To: [e-mail]
X-Charge-To: pgut001
X-Authenticated: relaymail v0.9 on cs26.cs.auckland.ac.nz
Date: Sun, 14 Mar 1999 05:00:49 (NZDT)
Message-ID: <[e-mail]>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

>I disagree with adding "..." to the RecipientInfo CHOICE because I believe
>that leads to non-interoperable S/MIME implementations.
 
>Personally I think a new version number is advisable every time the choice is
>extended, as that would make the handing of any extended choice easier to
>handle on reception. But I am happy to follow the general consensus on that
>issue.
 
<grumble>
Why are people trying to manufacture all this unnecessary complexity for 
something so simple?  X.500 has had this capability (the Name CHOICE) for over 
10 years and it's never lead to any problems because the only way to extend it 
is via changes to X.500 (that is, you need to extend the standard to extend 
the CHOICE).  Similarly, someone can't just drop in a new CHOICE option for 
CMS, it'd have to be done via the usual CMS standards process, so that 
resulting implementations would be just as interoperable as, say, ESS 
implementations.
 
Similarly, I don't see why it's necessary to change the version number every 
time the CHOICE is extended - if you don't recognise a CHOICE alternative, you 
skip it and continue.  Since CMS already requires changes from S/MIME v2/PKCS 
#7 (by adding the CHOICE) adding an extra line or two of code to 
implementations to skip unrecognised choices can't be that hard.
</grumble>
 
This is why I asked for '...' (or text to that effect for those still stuck
with ASN.1:1988) be added to CMS, it means it'll be possible to extend the
CHOICE in the future with further RFC's without requiring an update to CMS
itself (I believe this was the same rationale behind X.500's Name CHOICE).
There won't be an uncontrolled explosion of choices since the only way to
extend it would be as a full RFC, which would have to go through the usual
carefully-controlled standards process.
 
Peter.



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id LAA17710 for ietf-smime-bks; Fri, 12 Mar 1999 11:02:53 -0800 (PST)
Received: from apollo.jgvandyke.com (apollo.jgvandyke.com [158.189.10.100]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id LAA17706 for <[e-mail]>; Fri, 12 Mar 1999 11:02:52 -0800 (PST)
Received: from ajsn101.jgvandyke.com (ajsn101.jgvandyke.com [158.189.2.101]) by apollo.jgvandyke.com (8.8.8/8.8.8) with SMTP id OAA28707; Fri, 12 Mar 1999 14:14:54 -0500 (EST)
Received: from ajpc81 by ajsn101.jgvandyke.com (SMI-8.6/SMI-SVR4) id OAA11293; Fri, 12 Mar 1999 14:12:12 -0500
Date: Fri, 12 Mar 1999 14:12:12 -0500
Message-Id: <[e-mail]>
X-Sender: jsp@ajsn101
X-Mailer: Windows Eudora Version 1.4.4
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
To: "ross@secstan" <[e-mail]>, <[e-mail]>, <[e-mail]>
From: [e-mail] (John Pawling)
Subject: Re: More on KEKIdentifiers, and a suggested addition to CMS
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

All,

I disagree with adding "..." to the RecipientInfo CHOICE because I believe
that leads to non-interoperable S/MIME implementations.  I believe that the
CMS RecipientInfo syntax should not be changed until it is proven that it does
not meet a valid requirement ("valid" as defined by consensus of the S/MIME
WG).  If that occurs, then we should consider adding a well-defined syntax
as a ReceipientInfo CHOICE (not a wild card).

=========================================================
John Pawling,  Director - Systems Engineering
J.G. Van Dyke & Associates, Inc., a Wang Global Company
=========================================================


At 06:52 PM 3/12/99 -0000, ross@secstan wrote:
>I am happy to use '...' in the choice syntax, but unfortunately that is not
>available when using 1988 ASN.1.  So that option is not available.
>
>If there is strong objection to having a "controlled" way of extending the
>choice (i.e the OID route), but there is agreement to specifically allow the
>equivalent of '...' in 88 syntax (i.e. extend the choice), then there is a
>need to add a comment in the ASN.1.   Also it would be a advisable to say
>under what condition the CMSversion needs to change (if any).  Rule are
>needed so that there is no misunderstanding on how to  expansion the choice
>in the future.
>
>Personally I think a new  version number is advisable every time the choice
>is extended, as that  would make the handing of any extended choice easier
>to handle on reception. But I am happy to follow the general consensus on
>that issue.



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id KAA17638 for ietf-smime-bks; Fri, 12 Mar 1999 10:48:46 -0800 (PST)
Received: from gnasher.sol.co.uk (gnasher.sol.co.uk [194.247.64.2]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id KAA17634 for <[e-mail]>; Fri, 12 Mar 1999 10:48:44 -0800 (PST)
Received: from jrprotable2 (e1c10p28.scotland.net [148.176.234.92]) by gnasher.sol.co.uk (8.8.5/8.8.5) with SMTP id SAA18554; Fri, 12 Mar 1999 18:54:45 GMT
Message-ID: <002701be6cb9$7c6f4890$1500000a@jrprotable2>
From: "ross@secstan" <[e-mail]>
To: <[e-mail]>, <[e-mail]>
Subject: Re: More on KEKIdentifiers, and a suggested addition to CMS
Date: Fri, 12 Mar 1999 18:52:21 -0000
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 4.72.2106.4
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

I am happy to use '...' in the choice syntax, but unfortunately that is not
available when using 1988 ASN.1.  So that option is not available.

If there is strong objection to having a "controlled" way of extending the
choice (i.e the OID route), but there is agreement to specifically allow the
equivalent of '...' in 88 syntax (i.e. extend the choice), then there is a
need to add a comment in the ASN.1.   Also it would be a advisable to say
under what condition the CMSversion needs to change (if any).  Rule are
needed so that there is no misunderstanding on how to  expansion the choice
in the future.

Personally I think a new  version number is advisable every time the choice
is extended, as that  would make the handing of any extended choice easier
to handle on reception. But I am happy to follow the general consensus on
that issue.
-----Original Message-----
From: Peter Gutmann <[e-mail]>
To: [e-mail] <[e-mail]>
Date: 12 March 1999 16:38
Subject: Re: More on KEKIdentifiers, and a suggested addition to CMS


>Paul Hoffman / IMC <[e-mail]> writes:
>
>>Peter has posted an Internet Draft for an addition to CMS. I think it is
very
>>late for us to be adding things for which there is disagreement on how to
put
>>it in. We can discuss Peter's draft and decide if we want to pass it out
of
>>the working group. If we do, it can be a stand-alone RFC. If it gets two
>>independent implementations, we might fold it into the CMS RFC (if we ever
>>get there.....) when we move from Proposed Standard to Draft Standard.
>
>The point of making it an independent RFC was that it wouldn't hold up the
CMS
>RFC - that can proceed as usual, and the PWRI RFC could be developed at its
>own pace.
>
>>As an alternative, if the current CMS draft would allow for the 'PBES2'
>>algorithm identifier defined in PKCS #5 v2 in the set of
>>KeyEncryptionAlgorithms, there would be no need for changing the ASN.1 in
>>CMS. Another advantage with this is that it would enable an easy way to
send
>>encrypted email where the key is derived from a previously agreed-upon
>>password.
>
>I don't think this is such a good idea, it's a significant change to the
CMS
>RFC at a late stage (which I was trying to avoid by having an independent
PWRI
>RFC), and it's rather a kludge.  I think it'd be better to leave KEKRI for
>what it was intended for and have a dedicated PWRI which specifically
>addresses the requirements of password-based encryption.
>
>"John Ross" <[e-mail]> writes:
>
>>Also, if every extension to the choice needs a new CMSversion number
>>assigned, that may be a lot of CMSversion around in the future.
>
>You don't need to do this though, if you use '...' as I suggested in a
>previous message then implementations will know that there could be further
>types added there and skip any new ones they don't recognise.  Once this is
>done, there's no need to change the version number whenever a new choice is
>added.
>
>Peter.
>
>



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id JAA17242 for ietf-smime-bks; Fri, 12 Mar 1999 09:55:35 -0800 (PST)
Received: from doggate.exchange.microsoft.com (doggate.exchange.microsoft.com [131.107.88.55]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id JAA17235 for <[e-mail]>; Fri, 12 Mar 1999 09:55:26 -0800 (PST)
Received: by doggate.exchange.microsoft.com with Internet Mail Service (5.5.2232.9) id <GFNX11MN>; Fri, 12 Mar 1999 10:01:03 -0800
Message-ID: <2FBF98FC7852CF11912A0000000000010ECB5DB0@DINO>
From: "Jim Schaad (Exchange)" <[e-mail]>
To: "'Russ Housley'" <[e-mail]>, [e-mail], [e-mail], [e-mail], [e-mail], [e-mail], [e-mail], [e-mail], [e-mail], [e-mail], [e-mail], [e-mail], [e-mail], [e-mail], [e-mail], [e-mail], [e-mail], [e-mail], Josh Benaloh <[e-mail]>, "Barb Fox (Exchange)" <[e-mail]>, [e-mail], [e-mail], [e-mail], [e-mail], [e-mail], [e-mail], [e-mail], [e-mail], [e-mail], [e-mail], [e-mail], [e-mail], [e-mail], [e-mail], [e-mail], [e-mail], [e-mail]
Subject: RE: New Triple-DES Key Wrap Algorithm Section
Date: Fri, 12 Mar 1999 10:00:21 -0800
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2232.9)
Content-Type: text/plain; charset="windows-1252"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Russ,

I would like to see some changes to the RC2 key wrap algorithm to make it
easier to implement both the RC2 and 3DES wrapping using the same code.  The
core change is that the formatting and padding are done PRIOR to computing
the ICV value and thus all the code from step 4 on is the same for both the
RC2 Key wrap and the 3DES key wrap.

1.  LENGTH = sizeof(CEK)
2.  PAD = random(8 - (LENGTH + 1) % 8)
3.  TMP1 = LENGHT || CEK || PAD
4.  ICV = SHA_8(TMP1)
5.  TMP2 = ENC(TMP1 || ICV, IV)
6.  TMP3 = IV || TMP2
7.  TMP4 = REVERSE(TMP3)
8.  TMP5 = ENC(TMP4, constantIV)

This means that the KEK wrap routine is on constant data and the padding
also happens to be protected.  I suppose there is a possible attack with the
padding, but if the verification routine checks the pad length I doubt it is
possible.  However this means that I have one method of doing KEK rather
than 2.

jim

-----Original Message-----
From: Russ Housley [mailto:[e-mail]]
Sent: Thursday, March 04, 1999 8:52 AM
To: [e-mail]; [e-mail]; [e-mail];
[e-mail]; [e-mail]; [e-mail]; [e-mail];
[e-mail]; [e-mail]; [e-mail];
[e-mail]; [e-mail];
[e-mail]; [e-mail];
[e-mail]; [e-mail];
[e-mail]; Josh Benaloh; Barb Fox (Exchange);
[e-mail]; [e-mail]; [e-mail];
[e-mail]; [e-mail]; [e-mail];
[e-mail]; [e-mail]; [e-mail];
[e-mail]; [e-mail]; [e-mail];
[e-mail]; [e-mail]; [e-mail];
[e-mail]; [e-mail]
Subject: New Triple-DES Key Wrap Algorithm Section


All:

I greatly appreciate the work that everyone has put into the open debate on
key wrapping.

The 44th IETF meeting is coming up rapidly, and I would like to close this
debate prior to the meeting.  To that end, I selected the double-encryption
algorithm.  An updated CMS document has not been posted yet, so I have
attached the text associated with key wrapping.

Based on the discussion on this list, I believe that the double-encryption
algorithm meet the security requirements, and it is easily implemented with
building blocks that are otherwise needed to implement CMS.

I will gladly facilitate the further discussion of the general wrapping
algorithm if the participants are interested.  I do not think that
discussion should occur on the IETF S/MIME Working Group mail list, but I
will arrange for a separate list to be created if you want to pursue the
general wrap algorithm.

Russ


= = = = = = = = = =

12.6  Triple-DES and RC2 Key Wrap Algorithms

   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.  Triple-DES and RC2 content-encryption
   keys are encrypted in Cipher Block Chaining (CBC) mode [MODES].

   Key Transport algorithms allow for the content-encryption key to be
   directly encrypted; however, key agreement and symmetric key-
   encryption key algorithms encrypt the content-encryption key with a
   second symmetric encryption algorithm.  This section describes how
   the Triple-DES or RC2 content-encryption key is formatted and
   encrypted.

   Key agreement algorithms generate a pairwise key-encryption key, and
   a key wrap algorithm is used to encrypt the content-encryption key
   with the pairwise key-encryption key.  Similarly, a key wrap
   algorithm is used to encrypt the content-encryption key in a
   previously distributed key-encryption key.

   The key-encryption key is generated by the key agreement algorithm or
   distributed out of band.  For key agreement of RC2 key-encryption
   keys, 128 bits must be generated as input to the key expansion
   process used to compute the RC2 effective key [RC2].

   The same algorithm identifier is used for both 2-key and 3-key
   Triple-DES.  When the length of the content-encryption key to be
   wrapped is a 2-key Triple-DES key, a third key with the same value as
   the first key is created.  Thus, all Triple-DES content-encryption
   keys are wrapped like 3-key Triple-DES keys.

12.6.1  Key Checksum

   The CMS Checksum Algorithm is used to provide a content-encryption
   key integrity check value.  The algorithm is:

   1.  Compute a 20 octet SHA-1 [SHA1] message digest on the
       content-encryption key.
   2.  Use the most significant (first) eight octets of the message
       digest value as the checksum value.

12.6.2  Triple-DES Key Wrap

   The Triple-DES key wrap algorithm encrypts a Triple-DES content-
   encryption key with a Triple-DES key-encryption key.  The Triple-DES
   key wrap algorithm is:

   1.  Set odd parity for each of the DES key octets comprising
       the content-encryption key, call the result CEK.
   2.  Compute an 8 octet key checksum value on CEK as described above
       in Section 12.6.1, call the result ICV.
   3.  Let CEKICV = CEK || ICV.
   4.  Generate 8 octets at random, call the result IV.
   5.  Encrypt CEKICV in CBC mode using the key-encryption key.  Use
       the random value generated in the previous step as the
       initialization vector (IV).  Call the ciphertext TEMP1.
   6.  Let TEMP2 = IV || TEMP1.
   7.  Reverse the order of the octets in TEMP2.  That is, the most
       significant (first) octet is swapped with the least significant
       (last) octet, and so on.  Call the result TEMP3.
   8.  Encrypt TEMP3 in CBC mode using the key-encryption key.  Use
       an initialization vector (IV) of 0x4adda22c79e82105.
       The ciphertext is 40 octets long.

   Note:  When the same content-encryption key is wrapped in different
   key-encryption keys, a fresh initialization vector (IV) must be
   generated for each invocation of the key wrap algorithm.

12.6.3  Triple-DES Key Unwrap

   The Triple-DES key unwrap algorithm decrypts a Triple-DES content-
   encryption key using a Triple-DES key-encryption key.  The Triple-DES
   key unwrap algorithm is:

   1.  If the wrapped content-encryption key is not 40 octets, then
       error.
   2.  Decrypt the wrapped content-encryption key in CBC mode using
       the key-encryption key.  Use an initialization vector (IV)
       of 0x4adda22c79e82105.  Call the output TEMP3.
   3.  Reverse the order of the octets in TEMP3.  That is, the most
       significant (first) octet is swapped with the least significant
       (last) octet, and so on.  Call the result TEMP2.
   4.  Decompose the TEMP2 into IV and TEMP1.  IV is the most
       significant (first) 8 octets, and TEMP1 is the least significant
       (last) 32 octets.
   5.  Decrypt TEMP1 in CBC mode using the key-encryption key.  Use
       the IV value from the previous step as the initialization vector.
       Call the ciphertext CEKICV.
   6.  Decompose the CEKICV into CEK and ICV. CEK is the most significant
       (first) 24 octets, and ICV is the least significant (last) 8 octets.
   7.  Compute an 8 octet key checksum value on CEK as described above
       in Section 12.6.1.  If the computed key checksum value does not
       match the decrypted key checksum value, ICV, then error.
   8.  Check for odd parity each of the DES key octets comprising CEK.
       If parity is incorrect, then there is an error.
   9. Use CEK as the content-encryption key.

12.6.4  RC2 Key Wrap

   The RC2 key wrap algorithm encrypts a RC2 content-encryption key with a 
   RC2 key-encryption key.  The RC2 key wrap algorithm is:

   1.  Let the content-encryption key be called CEK, and let the length
       of the content-encryption key in octets be called LENGTH.
   2.  Compute an 8 octet key checksum value on CEK as described above
       in Section 12.6.1, call the result ICV.
   3.  Let CEKICV = LENGTH || CEK || ICV.  LENGTH is a single octet.
   4.  Let CEKICVPAD = CEKICV || PAD.  If the length of CEKICV is a
       multiple of 8, the PAD has a length of zero.  If the length of
       CEKICV is not a multiple of 8, then PAD contains the fewest
       number of random octets to make CEKICVPAD a multiple of 8.
   5.  Generate 8 octets at random, call the result IV.
   5.  Encrypt CEKICVPAD in CBC mode using the key-encryption key.
       Use the random value generated in the previous step as the
       initialization vector (IV).  Call the ciphertext TEMP1.
   6.  Let TEMP2 = IV || TEMP1.
   7.  Reverse the order of the octets in TEMP2.  That is, the most
       significant (first) octet is swapped with the least significant
       (last) octet, and so on.  Call the result TEMP3.
   8.  Encrypt TEMP3 in CBC mode using the key-encryption key.  Use
       an initialization vector (IV) of 0x4adda22c79e82105.

   Note:  When the same content-encryption key is wrapped in different
   key-encryption keys, a fresh initialization vector (IV) must be
   generated for each invocation of the key wrap algorithm.

12.6.5  RC2 Key Unwrap

   The RC2 key unwrap algorithm decrypts a RC2 content-encryption key
   using a RC2 key-encryption key.  The RC2 key unwrap algorithm is:

   1.  If the wrapped content-encryption key is not a multiple of 8
       octets, then error.
   2.  Decrypt the wrapped content-encryption key in CBC mode using
       the key-encryption key.  Use an initialization vector (IV)
       of 0x4adda22c79e82105.  Call the output TEMP3.
   3.  Reverse the order of the octets in TEMP3.  That is, the most
       significant (first) octet is swapped with the least significant
       (last) octet, and so on.  Call the result TEMP2.
   4.  Decompose the TEMP2 into IV and TEMP1.  IV is the most
       significant (first) 8 octets, and TEMP1 is the remaining octets.
   5.  Decrypt TEMP1 in CBC mode using the key-encryption key.  Use
       the IV value from the previous step as the initialization vector.
       Call the ciphertext CEKICVPAD.
   6.  Decompose the CEKICVPAD into LENGTH, CEK, ICV, and PAD.  LENGTH is
       the most significant (first) octet.  CEK is the following LENGTH
       octets.  ICV is the following 8 octets.  PAD is the remaining
       octets, if any.
   7.  If PAD is more than 7 octets, then error.
   8.  Compute an 8 octet key checksum value on CEK as described above
       in Section 12.6.1.  If the computed key checksum value does not
       match the decrypted key checksum value, ICV, then error.
   9.  Use CEK as the content-encryption key.

Security Considerations

   Section 12.6 specifies key wrap algorithms used to encrypt a Triple-
   DES [3DES] content-encryption key with a Triple-DES key-encryption
   key or to encrypt a RC2 [RC2] content-encryption key with a RC2 key-
   encryption key.  The key wrap algorithms make use of CBC mode
   [MODES].  These key wrap algorithms have been reviewed for use with
   Triple and RC2.  They have not been reviewed for use with other
   cryptographic modes or other encryption algorithms.  Therefore, if a
   CMS implementation wishes to support ciphers in addition to Triple-
   DES or RC2, then additional key wrap algorithms need to be defined to
   support the additional ciphers.



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id IAA16501 for ietf-smime-bks; Fri, 12 Mar 1999 08:10:21 -0800 (PST)
Received: from mail.student.auckland.ac.nz (mail.student.auckland.ac.nz [130.216.35.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id IAA16497 for <[e-mail]>; Fri, 12 Mar 1999 08:10:18 -0800 (PST)
Received: from cs26.cs.auckland.ac.nz ([e-mail] [130.216.36.9]) by mail.student.auckland.ac.nz (8.8.6/8.8.6/cs-master) with SMTP id FAA23514 for <[e-mail]>; Sat, 13 Mar 1999 05:16:24 +1300 (NZDT) (sender [e-mail])
Received: by cs26.cs.auckland.ac.nz (relaymail v0.9) id <92125538404998>; Sat, 13 Mar 1999 05:16:24 (NZDT)
From: [e-mail] (Peter Gutmann)
To: [e-mail]
Subject: Re: More on KEKIdentifiers, and a suggested addition to CMS
Reply-To: [e-mail]
X-Charge-To: pgut001
X-Authenticated: relaymail v0.9 on cs26.cs.auckland.ac.nz
Date: Sat, 13 Mar 1999 05:16:24 (NZDT)
Message-ID: <[e-mail]>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Paul Hoffman / IMC <[e-mail]> writes:
 
>Peter has posted an Internet Draft for an addition to CMS. I think it is very 
>late for us to be adding things for which there is disagreement on how to put 
>it in. We can discuss Peter's draft and decide if we want to pass it out of 
>the working group. If we do, it can be a stand-alone RFC. If it gets two 
>independent implementations, we might fold it into the CMS RFC (if we ever 
>get there.....) when we move from Proposed Standard to Draft Standard.
 
The point of making it an independent RFC was that it wouldn't hold up the CMS 
RFC - that can proceed as usual, and the PWRI RFC could be developed at its 
own pace.
 
>As an alternative, if the current CMS draft would allow for the 'PBES2' 
>algorithm identifier defined in PKCS #5 v2 in the set of 
>KeyEncryptionAlgorithms, there would be no need for changing the ASN.1 in 
>CMS. Another advantage with this is that it would enable an easy way to send 
>encrypted email where the key is derived from a previously agreed-upon 
>password.
 
I don't think this is such a good idea, it's a significant change to the CMS 
RFC at a late stage (which I was trying to avoid by having an independent PWRI 
RFC), and it's rather a kludge.  I think it'd be better to leave KEKRI for 
what it was intended for and have a dedicated PWRI which specifically 
addresses the requirements of password-based encryption.
 
"John Ross" <[e-mail]> writes:
 
>Also, if every extension to the choice needs a new CMSversion number 
>assigned, that may be a lot of CMSversion around in the future.
 
You don't need to do this though, if you use '...' as I suggested in a 
previous message then implementations will know that there could be further 
types added there and skip any new ones they don't recognise.  Once this is 
done, there's no need to change the version number whenever a new choice is 
added.
 
Peter.
 



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id GAA15863 for ietf-smime-bks; Fri, 12 Mar 1999 06:54:31 -0800 (PST)
Received: from apollo.jgvandyke.com (apollo.jgvandyke.com [158.189.10.100]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id GAA15859 for <[e-mail]>; Fri, 12 Mar 1999 06:54:30 -0800 (PST)
Received: from ajsn101.jgvandyke.com (ajsn101.jgvandyke.com [158.189.2.101]) by apollo.jgvandyke.com (8.8.8/8.8.8) with SMTP id KAA22703; Fri, 12 Mar 1999 10:06:32 -0500 (EST)
Received: from ajpc81 by ajsn101.jgvandyke.com (SMI-8.6/SMI-SVR4) id KAA07921; Fri, 12 Mar 1999 10:03:48 -0500
Date: Fri, 12 Mar 1999 10:03:48 -0500
Message-Id: <[e-mail]>
X-Sender: jsp@ajsn101
X-Mailer: Windows Eudora Version 1.4.4
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
To: "John Ross" <[e-mail]>, <[e-mail]>, <[e-mail]>, "Russ Housley" <[e-mail]>
From: [e-mail] (John Pawling)
Subject: Re: More on KEKIdentifiers, and a suggested addition to CMS
Cc: <[e-mail]>, <[e-mail]>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

All,

I believe that this proposal leads to non-interoperable S/MIME
implementations, so I oppose it.  If the originator chooses a kext syntax
that the recipient's software does not understand, then the recipient will
not be able to decrypt the EnvelopedData content.  I believe that the CMS
RecipientInfo syntax should not be changed until it is proven that it does
not meet a valid requirement ("valid" as defined by consensus of the S/MIME
WG).  If that occurs, then we should consider adding a well-defined syntax
as a ReceipientInfo CHOICE (not a wild card).

=========================================================
John Pawling,  Director - Systems Engineering
J.G. Van Dyke & Associates, Inc., a Wang Global Company
=========================================================


At 05:51 PM 3/11/99 -0800, John Ross wrote:
>If you are going to allow the choice to be extended, I agree with Rick that
>it should be controlled.  Just extending the choice with a new tag (and by
>the way it also then needs a new version number), will give problems in the
>future, as it is not a unique identifier.  What if a private extensions has
>been defined already and used tag 3?  Also, if every extension to the choice
>needs a new CMSversion number assigned, that may be a lot of CMSversion
>around in the future. A while back I proposed to have an extensible "choice"
>using octet string, it would be better using OID and any defined by as
>follows:.
>
>
> The following is an example ASN.1:
>
> RecipientInfo ::= CHOICE {
>        ktri KeyTransRecipientInfo,
>        kari [1] KeyAgreeRecipientInfo,
>        kekri [2] KEKRecipientInfo,
>        kext [3] ExternalyDefinedKeyAgreement --for future or private key
>management schemes }
>
>
>
>ExternalyDefinedKeyAgreement :: = SEQUENCE {
>    keyTypeIdentifier ObjectIdentier,
>    keyTypeInfo OCTECT STRING --any defined by OID}
>
>This will at lease make sure that there is unique identifiers for all the
>extensions to recipient info.
>
>Regards
>
>John Ross
>



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id GAA15718 for ietf-smime-bks; Fri, 12 Mar 1999 06:40:51 -0800 (PST)
Received: from apollo.jgvandyke.com (apollo.jgvandyke.com [158.189.10.100]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id GAA15714 for <[e-mail]>; Fri, 12 Mar 1999 06:40:50 -0800 (PST)
Received: from ajsn101.jgvandyke.com (ajsn101.jgvandyke.com [158.189.2.101]) by apollo.jgvandyke.com (8.8.8/8.8.8) with SMTP id JAA22316; Fri, 12 Mar 1999 09:52:52 -0500 (EST)
Received: from ajpc81 by ajsn101.jgvandyke.com (SMI-8.6/SMI-SVR4) id JAA07743; Fri, 12 Mar 1999 09:50:11 -0500
Date: Fri, 12 Mar 1999 09:50:11 -0500
Message-Id: <[e-mail]>
X-Sender: jsp@ajsn101
X-Mailer: Windows Eudora Version 1.4.4
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
To: [e-mail]
From: [e-mail] (John Pawling)
Subject: RE: More on KEKIdentifiers, and a suggested addition to CMS
Cc: [e-mail]
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Jim and Friends,

I agree with Jim's message.  When I expressed support for Peter's proposal
to enhance the CMS RecipientInfo syntax, I assumed that there was consensus
in the PKCS-15 community regarding the proposal.  Based on subsequent e-mail
traffic, that assumption has been proved to be false.  Therefore, I agree
with Jim that the CMS RecipientInfo syntax should remain unchanged.

- John Pawling 


At 10:20 AM 3/10/99 -0800, Jim Schaad (Exchange) wrote:
>John & Peter,
>
>At this point in time I am not willing to support this. I have two reasons
>for this
>
>1.  I want to get CMS approved, and there are other options for how to
>approach this (such as a new I-D) and we know a new version of CMS is coming
>soon to deal with OEAP
>
>2.  I don't think this is the correct set of items that are needed.  You
>have not proposed an appropriate set of text for section 12.  I don't
>understand why the Content Encrytion Alg should be encoded twice.  I don't
>understand why the KEK Wrap algorithm is not specified.  I just don't think
>this is complete yet.
>
>jim
>
>



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id DAA14702 for ietf-smime-bks; Fri, 12 Mar 1999 03:59:51 -0800 (PST)
Received: from hinge.mistral.co.uk (hinge.mistral.co.uk [195.184.228.15]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id DAA14698 for <[e-mail]>; Fri, 12 Mar 1999 03:59:49 -0800 (PST)
Received: from d3-s5-161-telehouse.mistral.co.uk (d3-s5-161-telehouse.mistral.co.uk [195.184.228.161]) by hinge.mistral.co.uk (8.8.5/8.6.9) with SMTP id MAA17608; Fri, 12 Mar 1999 12:05:53 GMT
Received: by d3-s5-161-telehouse.mistral.co.uk with Microsoft Mail id <[e-mail]>; Fri, 12 Mar 1999 12:02:56 -0000
Message-ID: <[e-mail]>
From: Darren Harter <[e-mail]>
To: "'John Ross'" <[e-mail]>, "[e-mail]" <[e-mail]>, "[e-mail]" <[e-mail]>, Russ Housley <[e-mail]>
Cc: "[e-mail]" <[e-mail]>, "[e-mail]" <[e-mail]>
Subject: RE: More on KEKIdentifiers, and a suggested addition to CMS
Date: Fri, 12 Mar 1999 09:16:54 -0000
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by mail.proper.com id DAA14699
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

John,

I agree in general with what you propose.  I understand the benefit of using an OCTET STRING to ensure easy decoding for recipients that do not understand the syntax of the data associated with keyTypeIdentifier.  However, I believe that a true ANY would be better than an OCTET STRING in this case.

Applications that support CMS already have to deal with a lot of ANY's, so one more is not going to add much complexity.  Also, using an ANY rather than an OCTET STRING allows for a single pass decode process, which an embedded OCTET STRING encoding does not.

The amended part of your syntax would be:

ExternalyDefinedKeyAgreement :: = SEQUENCE {
    keyTypeIdentifier OBJECT IDENTIFIER,
    keyTypeInfo ANY DEFINED BY keyTypeIdentifier }


Regards,

Darren

------------------------------------------------------------------------
Darren Harter BSc (Hons) CEng MBCS
Entegrity Solutions Corp
http://www.entegrity.co.uk
[phone]
Email: mailto:[e-mail]



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id BAA08307 for ietf-smime-bks; Fri, 12 Mar 1999 01:20:42 -0800 (PST)
Received: from spyrus.com (mail.spyrus.com [207.212.34.30]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id BAA08299 for <[e-mail]>; Fri, 12 Mar 1999 01:20:38 -0800 (PST)
Received: from rhousley_laptop.spyrus.com (hil-qbu-ppu-vty45.as.wcom.net [209.154.55.45]) by spyrus.com (8.7.6/8.7.3/arc) with SMTP id BAA11224; Fri, 12 Mar 1999 01:26:01 -0800 (PST)
Message-Id: <[e-mail]>
Message-Id: <[e-mail]>
X-Sender: [e-mail] (Unverified)
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 
Date: Thu, 11 Mar 1999 16:19:48 -0500
To: Burt Kaliski <[e-mail]>
From: Russ Housley <[e-mail]>
Subject: RE: Comments on x942-05 draft 
Cc: [e-mail], [e-mail], [e-mail]
In-Reply-To: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Burt:

You are correct.  The corrent write-up does specify the content-encryption
algorithm OID.  I agree that we should replace the content-encryption
algorithm OID with the key-wrap algorithm OID.

Russ


At 01:07 PM 3/10/99 -0800, Burt Kaliski wrote:
>Dear Russ --
>
>Thanks for the CMS excerpt.
>
>My question is about the parameters to the X9.42 KDF, specifically the OID
>associated with the derived key. The field is defined as follows:
>
>	algorithm is the ASN.1 algorithm OID of the symmetric algorithm with
>which
>	     this KEK will be used. 
>
>I'm assuming that within CMS, the OID would be id-alg-CMS3DESwrap or
>id-alg-CMSRC2wrap.
>
>x942-05 is unclear about this, as "symmetric algorithm" might be interpreted
>as the OID for RC2 or triple-DES, not the key wrapping mechanism. I think
>it's better to identify the key wrapping mechanism, in case there's more
>than one with the same underlying symmetric algorithm. One risk, of course,
>is that the OID for the key wrapping mechansim might be too generic -- so
>there should be some way to include parameters (if any) to the key wrapping
>OID as input to the KDF.
>
>-- Burt
>
>
>> ----------
>> From: 	Russ Housley[SMTP:[e-mail]]
>> Sent: 	Friday, March 05, 1999 10:05 AM
>> To: 	Burt Kaliski
>> Cc: 	Eric Rescorla; [e-mail]
>> Subject: 	RE: Comments on x942-05 draft 
>> 
>> Burt:
>> 
>> Please take a look at CMS for this answer.  The AlgorithmIdentifier used
>> to
>> name Ephemeral-Static Diffie-Hellman has a parameter, and that parameter
>> specifies the key wrap algorithm.
>> 
>> Russ
>> 


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id NAA13568 for ietf-smime-bks; Thu, 11 Mar 1999 13:48:00 -0800 (PST)
Received: from aum (ip11.proper.com [165.227.249.11]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id NAA13564 for <[e-mail]>; Thu, 11 Mar 1999 13:47:59 -0800 (PST)
Message-Id: <[e-mail]>
X-Sender: [e-mail] (Unverified)
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.29 (Beta)
Date: Thu, 11 Mar 1999 13:53:03 -0800
To: [e-mail]
From: Paul Hoffman / IMC <[e-mail]>
Subject: Re: More on KEKIdentifiers, and a suggested addition to CMS
In-Reply-To: <00e901be6c2a$ded01e40$0400000a@jrwork>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Folks:

Peter has posted an Internet Draft for an addition to CMS. I think it is 
very late for us to be adding things for which there is disagreement on how 
to put it in. We can discuss Peter's draft and decide if we want to pass it 
out of the working group. If we do, it can be a stand-alone RFC. If it gets 
two independent implementations, we might fold it into the CMS RFC (if we 
ever get there.....) when we move from Proposed Standard to Draft Standard.

--Paul Hoffman, Director
--Internet Mail Consortium


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id JAA11182 for ietf-smime-bks; Thu, 11 Mar 1999 09:50:24 -0800 (PST)
Received: from gnasher.sol.co.uk (gnasher.sol.co.uk [194.247.64.2]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id JAA11178 for <[e-mail]>; Thu, 11 Mar 1999 09:50:22 -0800 (PST)
Received: from jrwork (e1c6p45.scotland.net [148.176.233.109]) by gnasher.sol.co.uk (8.8.5/8.8.5) with SMTP id RAA14355; Thu, 11 Mar 1999 17:55:57 GMT
Message-ID: <00e901be6c2a$ded01e40$0400000a@jrwork>
From: "John Ross" <[e-mail]>
To: <[e-mail]>, <[e-mail]>, "Russ Housley" <[e-mail]>
Cc: <[e-mail]>, <[e-mail]>
Subject: Re: More on KEKIdentifiers, and a suggested addition to CMS
Date: Thu, 11 Mar 1999 17:51:28 -0800
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 4.72.3110.5
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

If you are going to allow the choice to be extended, I agree with Rick that
it should be controlled.  Just extending the choice with a new tag (and by
the way it also then needs a new version number), will give problems in the
future, as it is not a unique identifier.  What if a private extensions has
been defined already and used tag 3?  Also, if every extension to the choice
needs a new CMSversion number assigned, that may be a lot of CMSversion
around in the future. A while back I proposed to have an extensible "choice"
using octet string, it would be better using OID and any defined by as
follows:.


 The following is an example ASN.1:

 RecipientInfo ::= CHOICE {
        ktri KeyTransRecipientInfo,
        kari [1] KeyAgreeRecipientInfo,
        kekri [2] KEKRecipientInfo,
        kext [3] ExternalyDefinedKeyAgreement --for future or private key
management schemes }



ExternalyDefinedKeyAgreement :: = SEQUENCE {
    keyTypeIdentifier ObjectIdentier,
    keyTypeInfo OCTECT STRING --any defined by OID}

This will at lease make sure that there is unique identifiers for all the
extensions to recipient info.

Regards

John Ross

-----Original Message-----
From: Rich Ankney <[e-mail]>
To: [e-mail] <[e-mail]>; Russ Housley
<[e-mail]>
Cc: [e-mail] <[e-mail]>; [e-mail] <[e-mail]>
Date: Wednesday, March 10, 1999 10:39 AM
Subject: Re: More on KEKIdentifiers, and a suggested addition to CMS


>If we're going to add another recipient type, I'd like to see it be an
>open type (OID and ANY DEFINED BY), of which this would be
>the first case.  ANSI X9F3 would like to add another recipient type,
>as well (the Tecsec CKM stuff from X9.69).  So we would have:
>
>Key transport
>KEK
>Key agreement
>Other
> Password-based
> CKM
>
>Regards,
>Rich
>
>----------
>> From: Russ Housley <[e-mail]>
>> To: [e-mail]
>> Cc: [e-mail]; [e-mail]
>> Subject: Re: More on KEKIdentifiers, and a suggested addition to CMS
>> Date: Monday, March 08, 1999 4:43 AM
>>
>> Peter:
>>
>> I stayed silent to see if anyone would support your suggestion.  No one
>> spoke for it, but no one spke against it either.  I would like to heard
>> from the list members regarding this suggestion.  I do not consider
>silence
>> a reason to make an additional recipient type....
>>
>> Russ
>>
>> At 04:19 AM 2/21/99 +0000, Peter Gutmann wrote:
>> >I don't know what the final resolution on optional vs mandatory
>> KEKIdentifiers
>> >was, but I note that PKCS #15, which AFAIK is the first non-S/MIME use
>of CMS
>> >KEK encryption, already has to explicitly state that KEKIdentifiers are
>null
>> >strings wherever they occur because they're not useful for anything
>(actually
>> >there's a "not recommended" special-case use for them, see below).  I
>think
>> >this proves my earlier point that there's going to be very little use
>for a
>> >KEKIdentifier outside S/MIME, so that making it optional would be a good
>idea.
>> >
>> >Looking at the way KEKRecipientInfo is being used in PKCS #15, there's a
>
>> >rather obvious recipient type missing from CMS: Password-based
>encryption.
>> >PKCS #15 has a hack for this which puts the key derivation information
>into
>> >the KEKIdentifier (this being the special-case use mentioned above), but
>I'm
>> >sure this isn't what it was intended for because it isn't a key
>identifier at
>> >all but contains the AlgorithmIdentifier for the password processing.
>What's
>> >really needed is a new recipient type, PasswordRecipientInfo.  Included
>below
>> >is a suggestion for this which could drop directly into the CMS draft.
>> >
>> >Peter.
>> >
>> >-- Snip --
>> >
>> >6.2.4  PasswordRecipientInfo Type
>> >
>> >   Recipient information using a user-supplied password is represented
>in the
>> >   type PasswordRecipientInfo.  Each instance of PasswordRecipientInfo
>will
>> >   transfer the content-encryption key to one or more recipients who
>have the
>> >   previously agreed-upon password.
>> >
>> >      PasswordRecipientInfo ::= SEQUENCE {
>> >        version CMSVersion,  -- always set to 0
>> >        keyDerivationAlgorithm KeyDerivationAlgorithmIdentifier,
>> >        keyEncryptionAlgorithm ContentEncryptionAlgorithmIdentifier,
>> >        encryptedKey EncryptedKey }
>> >
>> >   The fields of type PasswordRecipientInfo have the following meanings:
>> >
>> >      version is the syntax version number.  It shall always be 0.
>> >
>> >      keyDerivationAlgorithm identifies the key-derivation algorithm,
>and any
>> >      associated parameters, used to derive the key-encryption key from
>the
>> >      user-supplied password.
>> >
>> >      keyEncryptionAlgorithm identifies the content-encryption
>algorithm, and
>> >      any associated parameters, used to encrypt the content-encryption
>key
>> >      with the password-derived key-encryption key.
>> >
>> >      encryptedKey is the result of encrypting the content-encryption
>key with
>> >      the password-derived key-encryption key.
>> >
>> >   The key derivation algorithms are:
>> >
>> >      KeyDerivationAlgorithmIdentifer ALGORITHM-IDENTIFIER ::= {
>> >        { IDENTIFIED BY id-PBKDF2 },
>> >        ...
>> >        }
>> >
>> >    For key derivation, CMS implementations must include PBKDF2
>[PKCS5v2].
>> >
>> >    For content (= key) encryption, CMS implementations must include
>> >Triple-DES
>> >    in CBC mode, should include RC2 in CBC mode, and may include other
>> >    algorithms (CAST-128, RC5, IDEA, Skipjack) and modes as required.
>CMS
>> >    implementations should not include any KSG ciphers such as RC4.
>> >
>> >-- Snip --
>> >
>> >Comments:
>> >
>> >The ContentEncryptionAlgorithmIdentifier is something like:
>> >
>> >      ContentEncryptionAlgorithmIdentifier ::= {
>> >        { IDENTIFIED BY des-ede3-cbc },
>> >        { IDENTIFIED BY rc2CBC },
>> >        { IDENTIFIED BY cast5CBC },
>> >        { IDENTIFIED BY rc5CBC },
>> >        { IDENTIFIED BY ideaCBC },
>> >        { IDENTIFIED BY desCBC },
>> >        ... -- ... and anything else you can think of, eg Skipjack
>> >        }
>> >
>> >but enumerating every possible one is superfluous as they're specified
>> >elsewhere.
>> >
>> >The content is encrypted is as per the KEK algorithm, but using the IV
>given
>> >in the ContentEncryptionAlgorithmIdentifier instead of a fixed IV - this
>is
>> >just standard CMS content encryption.  The advantage of using standard
>> OIDs is
>> >that it doesn't require defining a completely new set of OIDs which
>parallel
>> >all of the existing ones just to show that you're encrypting a key.
>Another
>> >way to handle this is as EncryptedContentInfo (which just adds an extra
>> >SEQUENCE around the existing ContentEncryptionAlgorithmIdentifier +
>> >EncryptedContent (=EncryptedKey)), but this is probably going overboard.
>> >
>> >(I'm prepared to accept a 'kekid [0] KEKIdentifier OPTIONAL' after the
>> version
>> > number if that's what's required to get people's grunt of approval for
>the
>> > thing).
>> >
>> >(Before people complain that you can't change the key wrap algorithm, if
>it
>> > ever does become necessary to change it (and I thought the point of the
>
>> > current key wrap design process was to build a solution once and for
>all),
>> > all you need to do is increment the RecipientInfo version number and
>add
>> > whatever you feel like).
>> >
>> >Peter.
>> >
>> >



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id FAA08661 for ietf-smime-bks; Thu, 11 Mar 1999 05:24:31 -0800 (PST)
Received: from karon.dynas.se (karon.dynas.se [192.71.43.4]) by mail.proper.com (8.8.8/8.8.5) with SMTP id FAA08657 for <[e-mail]>; Thu, 11 Mar 1999 05:24:28 -0800 (PST)
Received: (qmail 1572 invoked from network); 11 Mar 1999 13:30:26 -0000
Received: from spirit.sto.dynas.se (HELO spirit.dynas.se) (172.16.1.10) by karon.dynas.se with SMTP; 11 Mar 1999 13:30:26 -0000
Received: from reyzin_pc.securitydynamics.com by spirit.dynas.se with smtp (Smail3.1.28.1 #32) id m10L5Xd-000iSCC; Thu, 11 Mar 99 14:30:25 +0100
Date: Thu, 11 Mar 1999 08:29:47 -0500 (Eastern Standard Time)
From: Magnus Nystrom <[e-mail]>
To: Peter Gutmann <[e-mail]>
cc: [e-mail]
Subject: Re: More on KEKIdentifiers, and a suggested addition to CMS
In-Reply-To: <[e-mail]>
Message-ID: <Pine.WNT.4.05.9903110813320.236-100000@reyzin_pc.securitydynamics.com>
X-X-Sender: [e-mail]
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from QUOTED-PRINTABLE to 8bit by mail.proper.com id FAA08658
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

As an alternative, if the current CMS draft would allow for the 'PBES2'
algorithm identifier defined in PKCS #5 v2 in the set of
KeyEncryptionAlgorithms, there would be no need for changing the ASN.1 in
CMS. Another advantage with this is that it would enable an easy way to
send encrypted email where the key is derived from a previously
agreed-upon password.

I realize that this may require PKCS #5 v2 to be published as an
informational RFC.

-- Magnus

Magnus Nyström            Email: [e-mail]
RSA Laboratories          Phone: [phone]

On Thu, 11 Mar 1999, Peter Gutmann wrote:

> I think the way to avoid the "too late for CMS" problem is to publish
> PasswordRecipientInfo as its own draft which can follow on to CMS at a
> later date.  To handle this all you need to do is add a '...' at the 
> end of the RecipientInfo types in CMS (I think the '...' is implied 
> anyway, since presumably there'll be more than three different types 
> defined at some point).  I submitted a proposed draft covering this a 
> few days ago, I guess I'll jump the gun a bit and post it here (it's 
> fairly short) to give people a better idea of what it could look like.
> 
> Peter
> 
> -- Snip --
> 
> Internet Draft                                      Editor: Peter Gutmann
> draft-ietf-smime-password-00.txt                    University of Auckland
> February 26, 1999
> Expires in six months
> 
>                     Password-based Encryption for S/MIME
> 
> 1. Introduction
> 
> This document describes a password-based content encryption mechanism for
> S/MIME.  This is implemented as a new RecipientInfo type and is an extension to
> the RecipientInfo types currently defined in CMS [CMS].
> 
> The format of the messages are described in ASN.1:1994 [ASN1].
> 
> The key words "MUST", "MUST NOT", "REQUIRED", "SHOULD", "SHOULD NOT",
> "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as
> described in [RFC2119].
> 
> This draft is being discussed on the 'ietf-smime' mailing list.  To
> subscribe, send a message to:
>      [e-mail]
> with the single word
>      subscribe
> in the body of the message. There is a Web site for the mailing list at
> <http://www.imc.org/ietf-smime/>.
> 
> 1.1 Password-based Content Encryption
> 
> CMS currently defineds three recipient information types for public-key key
> wrapping (KeyTransRecipientInfo), conventional key wrapping (KEKRecipientInfo),
> and key agreement (KeyAgreeRecipientInfo).  The recipient information described
> here adds a fourth type, PasswordRecipientInfo, which provides for
> password-based key wrapping.
> 
> 1.2 RecipientInfo Types
> 
> The new recipient information type is an extension to the RecipientInfo type
> defined in section 6.2 of CMS, extending the types to:
> 
>     RecipientInfo ::= CHOICE {
>       ktri KeyTransRecipientInfo,
>       kari [1] KeyAgreeRecipientInfo,
>       kekri [2] KEKRecipientInfo,
>       pwri [3] PasswordRecipientinfo   -- New RecipientInfo type
>       }
> 
> Although the recipient information generation process is described in terms of
> a password-based operation (since this will be its most common use), the
> transformation employed is a general-purpose key derivation one which allows
> any type of keying material to be converted into a key specific to a particular
> content-encryption algorithm.
> 
> 1.2.1  PasswordRecipientInfo Type
> 
> Recipient information using a user-supplied password is represented in the type
> PasswordRecipientInfo.  Each instance of PasswordRecipientInfo will transfer
> the content-encryption key to one or more recipients who have the previously
> agreed-upon password.
> 
>     PasswordRecipientInfo ::= SEQUENCE {
>       version CMSVersion,  -- always set to 0
>       keyDerivationAlgorithm KeyDerivationAlgorithmIdentifier,
>       keyEncryptionAlgorithm KeyEncryptionAlgorithmIdentifier,
>       encryptedKey EncryptedKey }
> 
> The fields of type PasswordRecipientInfo have the following meanings:
> 
>   version is the syntax version number.  It shall always be 0.
> 
>   keyDerivationAlgorithm identifies the key-derivation algorithm, and any
>   associated parameters, used to derive the key-encryption key (KEK) from the
>   user-supplied password.
> 
>   keyEncryptionAlgorithm identifies the content-encryption algorithm, and any
>   associated parameters, used to encrypt the content-encryption key with the
>   password-derived KEK.
> 
>   encryptedKey is the result of encrypting the content-encryption key with the
>   password-derived KEK.
> 
> 1.2.2 Rationale
> 
> Password-based key wrapping is a two-stage process, a first stage in which the
> user-supplied password is converted into a KEK, and a second stage in which the
> KEK is used to encrypt a content-encryption key.  These two stages are
> identified by the two algorithm identifiers.  Although the PKCS #5 standard
> wraps these up into a single AlgorithmIdentifier, this design is particular to
> that standard and may not be applicable for other password-based key wrapping
> standards.  For this reason the two steps are specified separately.
> 
> 2 Supported Algorithms
> 
> This section lists the algorithms that must be implemented.  Additional
> algorithms that should be implemented are also included.
> 
> 2.1 Key Derivation Algorithms
> 
> These algorithms are used to convert the password into a KEK.  The key
> derivation algorithms are:
> 
>     KeyDerivationAlgorithmIdentifer ALGORITHM-IDENTIFIER ::= {
>       { SYNTAX PBKDF2-params IDENTIFIED BY id-PBKDF2 },
>       ...
>       }
> 
> CMS implementations must include PBKDF2 [PKCS5v2].
> 
> 2.2 Key Encryption Algorithms
> 
> These algorithms are used to encrypt the content (the key) using the derived
> KEK.  The content encryption algorithms are:
> 
>     KeyEncryptionAlgorithmIdentifer ALGORITHM-IDENTIFIER ::= PBES2-Encs
> 
> CMS implementations must include Triple-DES in CBC mode, should include RC2 in
> CBC mode, and may include other algorithms (CAST-128, RC5, IDEA, Skipjack) and
> modes as required.  CMS implementations should not include any KSG ciphers such
> as RC4.
> 
> 2.3 Symmetric Key Encryption Algorithms
> 
> <<Align with CMS KEK algorithm when it's stable.  The content is encrypted is
>   as per the KEK algorithm, but using the IV given in the
>   KeyEncryptionAlgorithmIdentifier instead of a fixed IV - this is just
>   standard CMS content encryption.  The latest CMS KEK stuff looked like it was
>   moving in this direction anyway>>
> 
> 3. Security Considerations
> 
> The security of this recipient information type rests on the security of the
> underlying mechanisms employed, for which further information can be found in
> CMS and PKCS5v2.
> 
> Appendix A: ASN.1 Module
> 
> PasswordRecipientInfo
>     { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16)
>       modules(0) pwri(n+1) }
> 
> DEFINITIONS IMPLICIT TAGS ::=
> BEGIN
> 
> IMPORTS
> 
>   FROM PKCS5 { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-5(5) }
>        PBKDF2-params, PBES2-Encs;
> 
> PasswordRecipientInfo ::= SEQUENCE {
>   version CMSVersion,  -- always set to 0
>   keyDerivationAlgorithm KeyDerivationAlgorithmIdentifier,
>   keyEncryptionAlgorithm KeyEncryptionAlgorithmIdentifier,
>   encryptedKey EncryptedKey }
> 
> KeyDerivationAlgorithmIdentifer ALGORITHM-IDENTIFIER ::= {
>   { SYNTAX PBKDF2-params IDENTIFIED BY id-PBKDF2 },
>   ...
>   }
> 
> KeyEncryptionAlgorithmIdentifer ALGORITHM-IDENTIFIER ::= PBES2-Encs
> 
> END
> 
> References
> 
>   ASN1  Recommendation X.680: Specification of Abstract Syntax Notation One
>         (ASN.1), 1994.
> 
>   CMS   Cryptographic Message Syntax, draft-ietf-smime-cms-10.txt, Russ
>         Housley, December 1998.
> 
>   PKCS5v2 PKCS #5 v2.0: Password-Based Cryptography Standard, Third Draft, RSA
>         Laboratories, February 1999.
>         <<Presumably this will become an RFC as soon as it's finalised, include
>           this as the actual reference>>
> 
>   RFC2119 Key Words for Use in RFC's to Indicate Requirement Levels, S.Bradner,
>         March 1997.
> 
> 



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id BAA02611 for ietf-smime-bks; Thu, 11 Mar 1999 01:12:55 -0800 (PST)
Received: from mail.student.auckland.ac.nz (mail.student.auckland.ac.nz [130.216.35.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id BAA02607 for <[e-mail]>; Thu, 11 Mar 1999 01:12:52 -0800 (PST)
Received: from cs26.cs.auckland.ac.nz ([e-mail] [130.216.36.9]) by mail.student.auckland.ac.nz (8.8.6/8.8.6/cs-master) with SMTP id WAA16095 for <[e-mail]>; Thu, 11 Mar 1999 22:18:52 +1300 (NZDT) (sender [e-mail])
Received: by cs26.cs.auckland.ac.nz (relaymail v0.9) id <92114393229012>; Thu, 11 Mar 1999 22:18:52 (NZDT)
From: [e-mail] (Peter Gutmann)
To: [e-mail]
Subject: Re: More on KEKIdentifiers, and a suggested addition to CMS
Reply-To: [e-mail]
X-Charge-To: pgut001
X-Authenticated: relaymail v0.9 on cs26.cs.auckland.ac.nz
Date: Thu, 11 Mar 1999 22:18:52 (NZDT)
Message-ID: <[e-mail]>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

I think the way to avoid the "too late for CMS" problem is to publish
PasswordRecipientInfo as its own draft which can follow on to CMS at a
later date.  To handle this all you need to do is add a '...' at the 
end of the RecipientInfo types in CMS (I think the '...' is implied 
anyway, since presumably there'll be more than three different types 
defined at some point).  I submitted a proposed draft covering this a 
few days ago, I guess I'll jump the gun a bit and post it here (it's 
fairly short) to give people a better idea of what it could look like.

Peter

-- Snip --

Internet Draft                                      Editor: Peter Gutmann
draft-ietf-smime-password-00.txt                    University of Auckland
February 26, 1999
Expires in six months

                    Password-based Encryption for S/MIME

1. Introduction

This document describes a password-based content encryption mechanism for
S/MIME.  This is implemented as a new RecipientInfo type and is an extension to
the RecipientInfo types currently defined in CMS [CMS].

The format of the messages are described in ASN.1:1994 [ASN1].

The key words "MUST", "MUST NOT", "REQUIRED", "SHOULD", "SHOULD NOT",
"RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as
described in [RFC2119].

This draft is being discussed on the 'ietf-smime' mailing list.  To
subscribe, send a message to:
     [e-mail]
with the single word
     subscribe
in the body of the message. There is a Web site for the mailing list at
<http://www.imc.org/ietf-smime/>.

1.1 Password-based Content Encryption

CMS currently defineds three recipient information types for public-key key
wrapping (KeyTransRecipientInfo), conventional key wrapping (KEKRecipientInfo),
and key agreement (KeyAgreeRecipientInfo).  The recipient information described
here adds a fourth type, PasswordRecipientInfo, which provides for
password-based key wrapping.

1.2 RecipientInfo Types

The new recipient information type is an extension to the RecipientInfo type
defined in section 6.2 of CMS, extending the types to:

    RecipientInfo ::= CHOICE {
      ktri KeyTransRecipientInfo,
      kari [1] KeyAgreeRecipientInfo,
      kekri [2] KEKRecipientInfo,
      pwri [3] PasswordRecipientinfo   -- New RecipientInfo type
      }

Although the recipient information generation process is described in terms of
a password-based operation (since this will be its most common use), the
transformation employed is a general-purpose key derivation one which allows
any type of keying material to be converted into a key specific to a particular
content-encryption algorithm.

1.2.1  PasswordRecipientInfo Type

Recipient information using a user-supplied password is represented in the type
PasswordRecipientInfo.  Each instance of PasswordRecipientInfo will transfer
the content-encryption key to one or more recipients who have the previously
agreed-upon password.

    PasswordRecipientInfo ::= SEQUENCE {
      version CMSVersion,  -- always set to 0
      keyDerivationAlgorithm KeyDerivationAlgorithmIdentifier,
      keyEncryptionAlgorithm KeyEncryptionAlgorithmIdentifier,
      encryptedKey EncryptedKey }

The fields of type PasswordRecipientInfo have the following meanings:

  version is the syntax version number.  It shall always be 0.

  keyDerivationAlgorithm identifies the key-derivation algorithm, and any
  associated parameters, used to derive the key-encryption key (KEK) from the
  user-supplied password.

  keyEncryptionAlgorithm identifies the content-encryption algorithm, and any
  associated parameters, used to encrypt the content-encryption key with the
  password-derived KEK.

  encryptedKey is the result of encrypting the content-encryption key with the
  password-derived KEK.

1.2.2 Rationale

Password-based key wrapping is a two-stage process, a first stage in which the
user-supplied password is converted into a KEK, and a second stage in which the
KEK is used to encrypt a content-encryption key.  These two stages are
identified by the two algorithm identifiers.  Although the PKCS #5 standard
wraps these up into a single AlgorithmIdentifier, this design is particular to
that standard and may not be applicable for other password-based key wrapping
standards.  For this reason the two steps are specified separately.

2 Supported Algorithms

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

2.1 Key Derivation Algorithms

These algorithms are used to convert the password into a KEK.  The key
derivation algorithms are:

    KeyDerivationAlgorithmIdentifer ALGORITHM-IDENTIFIER ::= {
      { SYNTAX PBKDF2-params IDENTIFIED BY id-PBKDF2 },
      ...
      }

CMS implementations must include PBKDF2 [PKCS5v2].

2.2 Key Encryption Algorithms

These algorithms are used to encrypt the content (the key) using the derived
KEK.  The content encryption algorithms are:

    KeyEncryptionAlgorithmIdentifer ALGORITHM-IDENTIFIER ::= PBES2-Encs

CMS implementations must include Triple-DES in CBC mode, should include RC2 in
CBC mode, and may include other algorithms (CAST-128, RC5, IDEA, Skipjack) and
modes as required.  CMS implementations should not include any KSG ciphers such
as RC4.

2.3 Symmetric Key Encryption Algorithms

<<Align with CMS KEK algorithm when it's stable.  The content is encrypted is
  as per the KEK algorithm, but using the IV given in the
  KeyEncryptionAlgorithmIdentifier instead of a fixed IV - this is just
  standard CMS content encryption.  The latest CMS KEK stuff looked like it was
  moving in this direction anyway>>

3. Security Considerations

The security of this recipient information type rests on the security of the
underlying mechanisms employed, for which further information can be found in
CMS and PKCS5v2.

Appendix A: ASN.1 Module

PasswordRecipientInfo
    { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16)
      modules(0) pwri(n+1) }

DEFINITIONS IMPLICIT TAGS ::=
BEGIN

IMPORTS

  FROM PKCS5 { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-5(5) }
       PBKDF2-params, PBES2-Encs;

PasswordRecipientInfo ::= SEQUENCE {
  version CMSVersion,  -- always set to 0
  keyDerivationAlgorithm KeyDerivationAlgorithmIdentifier,
  keyEncryptionAlgorithm KeyEncryptionAlgorithmIdentifier,
  encryptedKey EncryptedKey }

KeyDerivationAlgorithmIdentifer ALGORITHM-IDENTIFIER ::= {
  { SYNTAX PBKDF2-params IDENTIFIED BY id-PBKDF2 },
  ...
  }

KeyEncryptionAlgorithmIdentifer ALGORITHM-IDENTIFIER ::= PBES2-Encs

END

References

  ASN1  Recommendation X.680: Specification of Abstract Syntax Notation One
        (ASN.1), 1994.

  CMS   Cryptographic Message Syntax, draft-ietf-smime-cms-10.txt, Russ
        Housley, December 1998.

  PKCS5v2 PKCS #5 v2.0: Password-Based Cryptography Standard, Third Draft, RSA
        Laboratories, February 1999.
        <<Presumably this will become an RFC as soon as it's finalised, include
          this as the actual reference>>

  RFC2119 Key Words for Use in RFC's to Indicate Requirement Levels, S.Bradner,
        March 1997.



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id UAA07449 for ietf-smime-bks; Wed, 10 Mar 1999 20:13:27 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id UAA07444; Wed, 10 Mar 1999 20:13:26 -0800 (PST)
Received: from cayman-islands.isi.edu (cayman-islands.isi.edu [128.9.160.140]) by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id UAA27909; Wed, 10 Mar 1999 20:18:56 -0800 (PST)
Received: (from bcn@localhost) by cayman-islands.isi.edu (8.8.7/8.8.6) id UAA15042; Wed, 10 Mar 1999 20:18:55 -0800 (PST)
Date: Wed, 10 Mar 1999 20:18:55 -0800 (PST)
Message-Id: <[e-mail]>
From: Clifford Neuman <[e-mail]>
To: [e-mail]
Subject: Workshop on Countering Cyber-Terrorism
Reply-to: [e-mail]
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

		      Countering Cyber-Terrorism
			      June 22-23
		      Marina del Rey, California
      A workshop sponsored by the Information Sciences Institute
	       of the University of Southern California

			Call for Participation

Recent studies warn of Cyber-Terrorism and the vulnerability of our
computer systems and infrastructure to attack. These reports identify
damage that determined, knowledgeable, and well-financed adversaries
could inflict on commercial, government, and military systems.  Such
attacks would have severe consequences for the public, and in
particular the economy, which has become dependant on computers and
communications infrastructure.

The objective of this workshop is to identify things that should be
done to improve our ability to detect, protect against, contain,
neutralize, mitigate the effects of, and recover from cyber-terrorist
attacks.  Participants are sought from the computer security,
electronic commerce and banking, network infrastructure, military, and
counter-terrorism communities, as well as those with experience of
cyber-terrorist attacks.  Recommendations may suggest research and
development or operational measures that can be taken.  The workshop
is NOT a forum for presentation of the latest security systems,
protocols or algorithms.  The workshop will address the strategies,
framework, and infrastructure required to combine and incrementally
deploy such technologies to counter the cyber-terrorist threat.

Attendance will be limited to approximately 25 participants.
Participants will be selected on the basis of submitted position
papers that raise issues for the workshop to discuss, identify threats
or countermeasures, or propose strategies or infrastructure to counter
the threat of cyber-terrorism. Position papers should be four pages or
less in length.  Submissions should be sent in e-mail in Word or PDF
format, or as ASCII text to [e-mail].

Please check the web page http://www.isi.edu/cctws for more
information, including a position paper from the organizers which will
be available two weeks prior to the submission deadline.

Important Dates:

  Organizer's Paper Available              April  5, 1999
  Position Papers Due                      April 19, 1999
  Notification of Acceptance               May 1, 1999
  Revised Position Papers Due              May 28, 1999
  Position Papers Available on Web         June 9
  Workshop Dates                           June 22-23

Organizing Committee:

   Bob Balzer, Information Sciences Institute, [e-mail]
   Thomas Longstaff, CERT Coordination Center, [e-mail]
   Don Faatz, the MITRE Corporation, [e-mail] 
   Clifford Neuman, Information Sciences Institute, [e-mail]


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id KAA03547 for ietf-smime-bks; Wed, 10 Mar 1999 10:20:04 -0800 (PST)
Received: from dylithium.adga.ca (dylithium.adga.ca [207.112.67.34]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id KAA03543 for <[e-mail]>; Wed, 10 Mar 1999 10:20:03 -0800 (PST)
Received: from xfile ([207.112.70.165]) by dylithium.adga.ca (980427.SGI.8.8.8/8.8.8-ajr) with SMTP id NAA25572; Wed, 10 Mar 1999 13:24:15 -0500 (EST)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: Windows Eudora Pro Version 3.0.1 (32)
Date: Wed, 10 Mar 1999 13:25:38 -0500
To: Russ Housley <[e-mail]>
From: Francois Rousseau <[e-mail]>
Subject: Comment on CMS-11 (Temporary Version)
Cc: [e-mail]
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Russ,

I had not noticed this one before but throughout Sections 12.3 various
things (e.g. key agreement algorithm identifiers, key transport algorithm
identifiers, key wrap algorithm identifiers, etc.) are referred as being
located or used from the "EnvelopedData RecipientInfo...", however they
could also be located or used from the "AuthenticatedData RecipientInfo..."

Francois Rousseau
AEPOS Technologies


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id KAA03499 for ietf-smime-bks; Wed, 10 Mar 1999 10:15:17 -0800 (PST)
Received: from dfssl.exchange.microsoft.com (dfssl.exchange.microsoft.com [131.107.88.59]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id KAA03495 for <[e-mail]>; Wed, 10 Mar 1999 10:15:16 -0800 (PST)
Received: by dfssl.dns.microsoft.com with Internet Mail Service (5.5.2448.0) id <GM1BP88Q>; Wed, 10 Mar 1999 10:20:47 -0800
Message-ID: <2FBF98FC7852CF11912A0000000000010ECB5D9E@DINO>
From: "Jim Schaad (Exchange)" <[e-mail]>
To: "'[e-mail]'" <[e-mail]>, [e-mail]
Cc: [e-mail]
Subject: RE: More on KEKIdentifiers, and a suggested addition to CMS
Date: Wed, 10 Mar 1999 10:20:40 -0800
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
Content-Type: text/plain; charset="windows-1252"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

John & Peter,

At this point in time I am not willing to support this. I have two reasons
for this

1.  I want to get CMS approved, and there are other options for how to
approach this (such as a new I-D) and we know a new version of CMS is coming
soon to deal with OEAP

2.  I don't think this is the correct set of items that are needed.  You
have not proposed an appropriate set of text for section 12.  I don't
understand why the Content Encrytion Alg should be encoded twice.  I don't
understand why the KEK Wrap algorithm is not specified.  I just don't think
this is complete yet.

jim


-----Original Message-----
From: [e-mail] [mailto:[e-mail]]
Sent: Wednesday, March 10, 1999 6:34 AM
To: [e-mail]
Cc: [e-mail]
Subject: Re: More on KEKIdentifiers, and a suggested addition to CMS


Peter, Russ and friends,

Initially, I was opposed to this proposal because it adds yet more
complexity to CMS.  However, I agree with Peter that it is better to have a
clearly defined, meaningful ASN.1 syntax rather than to kludge data into an
existing syntax.  I assume that PKCS #15 is going to be widely used, so it
is worthwhile to enhance the CMS RecipientInfo syntax to include Peter's
proposed PasswordRecipientInfo CHOICE.   

I have a few comments to Peter's proposed additions to CMS:

1) Peter's proposal uses the ALGORITHM-IDENTIFIER syntax which is not part
of the 1988 ASN.1 grammar.  Many moons ago the S/MIME WG decided that the
S/MIME v3 set of specs will only use the 1988 ASN.1 grammar, so I believe
that Peter's proposal should be re-worded to eliminate use of the
ALGORITHM-IDENTIFIER syntax.

2) Recommend that "KSG" be spelled.  

3) Also, please reword the following to use 1988 ASN.1 syntax:
>>The ContentEncryptionAlgorithmIdentifier is something like:
>> 
>>      ContentEncryptionAlgorithmIdentifier ::= {
>>        { IDENTIFIED BY des-ede3-cbc },
>>        { IDENTIFIED BY rc2CBC },
>>        { IDENTIFIED BY cast5CBC },
>>        { IDENTIFIED BY rc5CBC },
>>        { IDENTIFIED BY ideaCBC },
>>        { IDENTIFIED BY desCBC },
>>        ... -- ... and anything else you can think of, eg Skipjack
>>        }


Assuming that CMS is changed to include PasswordRecipientInfo, I don't
believe that the KEKRecipientInfo kekid needs to be changed to be OPTIONAL
(as Peter also proposed) because PKCS #15 will no longer use the
KEKRecipientInfo syntax.

=========================================================
John Pawling,  Director - Systems Engineering
J.G. Van Dyke & Associates, Inc., a Wang Global Company
========================================================


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id KAA03489 for ietf-smime-bks; Wed, 10 Mar 1999 10:14:17 -0800 (PST)
Received: from smtp3.erols.com (smtp3.erols.com [207.172.3.236]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id KAA03485 for <[e-mail]>; Wed, 10 Mar 1999 10:14:12 -0800 (PST)
Received: from fujitsu1.ny.certco.com (207-172-46-41.s41.tnt9.ann.va.dialup.rcn.com [207.172.46.41]) by smtp3.erols.com (8.8.8/8.8.5) with ESMTP id NAA08982; Wed, 10 Mar 1999 13:19:30 -0500 (EST)
Message-Id: <[e-mail]>
Reply-To: <[e-mail]>
From: "Rich Ankney" <[e-mail]>
To: <[e-mail]>, "Russ Housley" <[e-mail]>
Cc: <[e-mail]>, <[e-mail]>
Subject: Re: More on KEKIdentifiers, and a suggested addition to CMS
Date: Wed, 10 Mar 1999 13:16:52 -0500
X-MSMail-Priority: Normal
X-Priority: 3
X-Mailer: Microsoft Internet Mail 4.70.1161
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

If we're going to add another recipient type, I'd like to see it be an
open type (OID and ANY DEFINED BY), of which this would be
the first case.  ANSI X9F3 would like to add another recipient type,
as well (the Tecsec CKM stuff from X9.69).  So we would have:

Key transport
KEK
Key agreement
Other
	Password-based
	CKM

Regards,
Rich

----------
> From: Russ Housley <[e-mail]>
> To: [e-mail]
> Cc: [e-mail]; [e-mail]
> Subject: Re: More on KEKIdentifiers, and a suggested addition to CMS
> Date: Monday, March 08, 1999 4:43 AM
> 
> Peter:
> 
> I stayed silent to see if anyone would support your suggestion.  No one
> spoke for it, but no one spke against it either.  I would like to heard
> from the list members regarding this suggestion.  I do not consider
silence
> a reason to make an additional recipient type....
> 
> Russ
> 
> At 04:19 AM 2/21/99 +0000, Peter Gutmann wrote:
> >I don't know what the final resolution on optional vs mandatory
> KEKIdentifiers 
> >was, but I note that PKCS #15, which AFAIK is the first non-S/MIME use
of CMS 
> >KEK encryption, already has to explicitly state that KEKIdentifiers are
null 
> >strings wherever they occur because they're not useful for anything
(actually 
> >there's a "not recommended" special-case use for them, see below).  I
think 
> >this proves my earlier point that there's going to be very little use
for a 
> >KEKIdentifier outside S/MIME, so that making it optional would be a good
idea.
> > 
> >Looking at the way KEKRecipientInfo is being used in PKCS #15, there's a

> >rather obvious recipient type missing from CMS: Password-based
encryption.  
> >PKCS #15 has a hack for this which puts the key derivation information
into 
> >the KEKIdentifier (this being the special-case use mentioned above), but
I'm 
> >sure this isn't what it was intended for because it isn't a key
identifier at 
> >all but contains the AlgorithmIdentifier for the password processing. 
What's 
> >really needed is a new recipient type, PasswordRecipientInfo.  Included
below 
> >is a suggestion for this which could drop directly into the CMS draft.
> > 
> >Peter.
> > 
> >-- Snip --
> > 
> >6.2.4  PasswordRecipientInfo Type
> > 
> >   Recipient information using a user-supplied password is represented
in the
> >   type PasswordRecipientInfo.  Each instance of PasswordRecipientInfo
will
> >   transfer the content-encryption key to one or more recipients who
have the
> >   previously agreed-upon password.
> > 
> >      PasswordRecipientInfo ::= SEQUENCE {
> >        version CMSVersion,  -- always set to 0
> >        keyDerivationAlgorithm KeyDerivationAlgorithmIdentifier,
> >        keyEncryptionAlgorithm ContentEncryptionAlgorithmIdentifier,
> >        encryptedKey EncryptedKey }
> > 
> >   The fields of type PasswordRecipientInfo have the following meanings:
> > 
> >      version is the syntax version number.  It shall always be 0.
> > 
> >      keyDerivationAlgorithm identifies the key-derivation algorithm,
and any
> >      associated parameters, used to derive the key-encryption key from
the
> >      user-supplied password.
> > 
> >      keyEncryptionAlgorithm identifies the content-encryption
algorithm, and
> >      any associated parameters, used to encrypt the content-encryption
key
> >      with the password-derived key-encryption key.
> > 
> >      encryptedKey is the result of encrypting the content-encryption
key with
> >      the password-derived key-encryption key.
> > 
> >   The key derivation algorithms are:
> > 
> >      KeyDerivationAlgorithmIdentifer ALGORITHM-IDENTIFIER ::= {
> >        { IDENTIFIED BY id-PBKDF2 },
> >        ...
> >        }
> > 
> >    For key derivation, CMS implementations must include PBKDF2
[PKCS5v2].
> >                        
> >    For content (= key) encryption, CMS implementations must include 
> >Triple-DES 
> >    in CBC mode, should include RC2 in CBC mode, and may include other 
> >    algorithms (CAST-128, RC5, IDEA, Skipjack) and modes as required. 
CMS 
> >    implementations should not include any KSG ciphers such as RC4.
> > 
> >-- Snip --
> > 
> >Comments:
> > 
> >The ContentEncryptionAlgorithmIdentifier is something like:
> > 
> >      ContentEncryptionAlgorithmIdentifier ::= {
> >        { IDENTIFIED BY des-ede3-cbc },
> >        { IDENTIFIED BY rc2CBC },
> >        { IDENTIFIED BY cast5CBC },
> >        { IDENTIFIED BY rc5CBC },
> >        { IDENTIFIED BY ideaCBC },
> >        { IDENTIFIED BY desCBC },
> >        ... -- ... and anything else you can think of, eg Skipjack
> >        }
> > 
> >but enumerating every possible one is superfluous as they're specified 
> >elsewhere.
> > 
> >The content is encrypted is as per the KEK algorithm, but using the IV
given 
> >in the ContentEncryptionAlgorithmIdentifier instead of a fixed IV - this
is 
> >just standard CMS content encryption.  The advantage of using standard
> OIDs is 
> >that it doesn't require defining a completely new set of OIDs which
parallel 
> >all of the existing ones just to show that you're encrypting a key. 
Another 
> >way to handle this is as EncryptedContentInfo (which just adds an extra 
> >SEQUENCE around the existing ContentEncryptionAlgorithmIdentifier + 
> >EncryptedContent (=EncryptedKey)), but this is probably going overboard.
> > 
> >(I'm prepared to accept a 'kekid [0] KEKIdentifier OPTIONAL' after the
> version 
> > number if that's what's required to get people's grunt of approval for
the 
> > thing).
> > 
> >(Before people complain that you can't change the key wrap algorithm, if
it 
> > ever does become necessary to change it (and I thought the point of the

> > current key wrap design process was to build a solution once and for
all), 
> > all you need to do is increment the RecipientInfo version number and
add 
> > whatever you feel like).
> > 
> >Peter.
> > 
> >


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id IAA02236 for ietf-smime-bks; Wed, 10 Mar 1999 08:15:37 -0800 (PST)
Received: from dylithium.adga.ca (dylithium.adga.ca [207.112.67.34]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id IAA02231; Wed, 10 Mar 1999 08:15:34 -0800 (PST)
Received: from xfile ([207.112.70.165]) by dylithium.adga.ca (980427.SGI.8.8.8/8.8.8-ajr) with SMTP id LAA23921; Wed, 10 Mar 1999 11:19:56 -0500 (EST)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: Windows Eudora Pro Version 3.0.1 (32)
Date: Wed, 10 Mar 1999 11:21:12 -0500
To: [e-mail]
From: Francois Rousseau <[e-mail]>
Subject: Re: I-D ACTION:draft-ietf-smime-ess-11.txt
Cc: [e-mail], [e-mail]
In-Reply-To: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Paul,

After reviewing version 11 of ESS I have noticed that you did include Jim's
proposal to expand the use of the signingCertificate attribute in Section
5.4 such that authorization certificates can be either attribute
certificates or normal certificates (e.g. encryption certificate).

However, you did not include the related comments that I had made on 05 Feb
1999 about Jim's proposal that were also supported by John Pawling.

Francois Rousseau
AEPOS Technologies 




Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id GAA01507 for ietf-smime-bks; Wed, 10 Mar 1999 06:57:05 -0800 (PST)
Received: from apollo.jgvandyke.com (apollo.jgvandyke.com [158.189.10.100]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id GAA01501 for <[e-mail]>; Wed, 10 Mar 1999 06:57:03 -0800 (PST)
Received: from ajsn101.jgvandyke.com (ajsn101.jgvandyke.com [158.189.2.101]) by apollo.jgvandyke.com (8.8.8/8.8.8) with SMTP id KAA06957 for <[e-mail]>; Wed, 10 Mar 1999 10:08:55 -0500 (EST)
Received: from ajpc81 by ajsn101.jgvandyke.com (SMI-8.6/SMI-SVR4) id KAA14766; Wed, 10 Mar 1999 10:06:15 -0500
Date: Wed, 10 Mar 1999 10:06:15 -0500
Message-Id: <[e-mail]>
X-Sender: jsp@ajsn101
X-Mailer: Windows Eudora Version 1.4.4
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
To: [e-mail]
From: [e-mail] (John Pawling)
Subject: Re: Whither SignerInfo content-type?
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Peter,

I agree with your proposal, but "contentInfo" msut be changed to
"encapContentInfo".

- John Pawling



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id GAA01336 for ietf-smime-bks; Wed, 10 Mar 1999 06:35:08 -0800 (PST)
Received: from mail.student.auckland.ac.nz (mail.student.auckland.ac.nz [130.216.35.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id GAA01331 for <[e-mail]>; Wed, 10 Mar 1999 06:35:05 -0800 (PST)
Received: from cs26.cs.auckland.ac.nz ([e-mail] [130.216.36.9]) by mail.student.auckland.ac.nz (8.8.6/8.8.6/cs-master) with SMTP id DAA31315 for <[e-mail]>; Thu, 11 Mar 1999 03:41:01 +1300 (NZDT) (sender [e-mail])
Received: by cs26.cs.auckland.ac.nz (relaymail v0.9) id <92107686005906>; Thu, 11 Mar 1999 03:41:00 (NZDT)
From: [e-mail] (Peter Gutmann)
To: [e-mail]
Subject: Whither SignerInfo content-type?
Reply-To: [e-mail]
X-Charge-To: pgut001
X-Authenticated: relaymail v0.9 on cs26.cs.auckland.ac.nz
Date: Thu, 11 Mar 1999 03:41:00 (NZDT)
Message-ID: <[e-mail]>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

I've just noticed that there doesn't appear to be anything in CMS which says
what you're supposed to do with the content-type attribute when it's present in
the signedAttributes.  11.1 says "The content-type attribute specifies the
content type of the ContentInfo value being signed in signed-data", but there
doesn't appear to be any clear indication of how to apply this when you verify
the signature.  I know it's obvious, but it'd be a good idea to mention it
explicitly, perhaps add to the content-type description or maybe 11.1 something
like "Where this field is present, implementations must verify during the
signature validation process that it matches the type of the ContentInfo being
signed".
 
Peter.
 



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id GAA01265 for ietf-smime-bks; Wed, 10 Mar 1999 06:25:16 -0800 (PST)
Received: from apollo.jgvandyke.com (apollo.jgvandyke.com [158.189.10.100]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id GAA01261 for <[e-mail]>; Wed, 10 Mar 1999 06:25:15 -0800 (PST)
Received: from ajsn101.jgvandyke.com (ajsn101.jgvandyke.com [158.189.2.101]) by apollo.jgvandyke.com (8.8.8/8.8.8) with SMTP id JAA06051; Wed, 10 Mar 1999 09:37:05 -0500 (EST)
Received: from ajpc81 by ajsn101.jgvandyke.com (SMI-8.6/SMI-SVR4) id JAA14386; Wed, 10 Mar 1999 09:34:25 -0500
Date: Wed, 10 Mar 1999 09:34:25 -0500
Message-Id: <[e-mail]>
X-Sender: jsp@ajsn101
X-Mailer: Windows Eudora Version 1.4.4
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
To: [e-mail]
From: [e-mail] (John Pawling)
Subject: Re: More on KEKIdentifiers, and a suggested addition to CMS
Cc: [e-mail]
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Peter, Russ and friends,

Initially, I was opposed to this proposal because it adds yet more
complexity to CMS.  However, I agree with Peter that it is better to have a
clearly defined, meaningful ASN.1 syntax rather than to kludge data into an
existing syntax.  I assume that PKCS #15 is going to be widely used, so it
is worthwhile to enhance the CMS RecipientInfo syntax to include Peter's
proposed PasswordRecipientInfo CHOICE.   

I have a few comments to Peter's proposed additions to CMS:

1) Peter's proposal uses the ALGORITHM-IDENTIFIER syntax which is not part
of the 1988 ASN.1 grammar.  Many moons ago the S/MIME WG decided that the
S/MIME v3 set of specs will only use the 1988 ASN.1 grammar, so I believe
that Peter's proposal should be re-worded to eliminate use of the
ALGORITHM-IDENTIFIER syntax.

2) Recommend that "KSG" be spelled.  

3) Also, please reword the following to use 1988 ASN.1 syntax:
>>The ContentEncryptionAlgorithmIdentifier is something like:
>> 
>>      ContentEncryptionAlgorithmIdentifier ::= {
>>        { IDENTIFIED BY des-ede3-cbc },
>>        { IDENTIFIED BY rc2CBC },
>>        { IDENTIFIED BY cast5CBC },
>>        { IDENTIFIED BY rc5CBC },
>>        { IDENTIFIED BY ideaCBC },
>>        { IDENTIFIED BY desCBC },
>>        ... -- ... and anything else you can think of, eg Skipjack
>>        }


Assuming that CMS is changed to include PasswordRecipientInfo, I don't
believe that the KEKRecipientInfo kekid needs to be changed to be OPTIONAL
(as Peter also proposed) because PKCS #15 will no longer use the
KEKRecipientInfo syntax.

=========================================================
John Pawling,  Director - Systems Engineering
J.G. Van Dyke & Associates, Inc., a Wang Global Company
========================================================



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id UAA10423 for ietf-smime-bks; Tue, 9 Mar 1999 20:29:27 -0800 (PST)
Received: from mail.student.auckland.ac.nz (mail.student.auckland.ac.nz [130.216.35.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id UAA10418 for <[e-mail]>; Tue, 9 Mar 1999 20:29:24 -0800 (PST)
Received: from cs26.cs.auckland.ac.nz ([e-mail] [130.216.36.9]) by mail.student.auckland.ac.nz (8.8.6/8.8.6/cs-master) with SMTP id RAA14290; Wed, 10 Mar 1999 17:35:07 +1300 (NZDT) (sender [e-mail])
Received: by cs26.cs.auckland.ac.nz (relaymail v0.9) id <92104050600771>; Wed, 10 Mar 1999 17:35:06 (NZDT)
From: [e-mail] (Peter Gutmann)
To: [e-mail]
Subject: Re: More on KEKIdentifiers, and a suggested addition to CMS
Cc: [e-mail]
Reply-To: [e-mail]
X-Charge-To: pgut001
X-Authenticated: relaymail v0.9 on cs26.cs.auckland.ac.nz
Date: Wed, 10 Mar 1999 17:35:06 (NZDT)
Message-ID: <[e-mail]>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

 
>I stayed silent to see if anyone would support your suggestion.  No one spoke
>for it, but no one spke against it either.  I would like to heard from the
>list members regarding this suggestion.  I do not consider silence a reason to
>make an additional recipient type....
 
The maxim of the law is that silence gives consent.  Obviously everyone agrees
with me :-).
 
Peter.
 
>I stayed silent to see if anyone would support your suggestion.  No one spoke
>for it, but no one spke against it either.  I would like to heard from the
>list members regarding this suggestion.  I do not consider silence a reason to
>make an additional recipient type....
 
The maxim of the law is that silence gives consent.  Obviously everyone agrees
with me :-).
 
Peter.
 



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id UAA08544 for ietf-smime-bks; Tue, 9 Mar 1999 20:03:25 -0800 (PST)
Received: from spyrus.com (mail.spyrus.com [207.212.34.30]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id UAA08537 for <[e-mail]>; Tue, 9 Mar 1999 20:03:24 -0800 (PST)
Received: from rhousley_laptop.spyrus.com (hil-qbu-ppu-vty35.as.wcom.net [209.154.55.35]) by spyrus.com (8.7.6/8.7.3/arc) with SMTP id UAA22751; Tue, 9 Mar 1999 20:08:14 -0800 (PST)
Message-Id: <4.1.19990308045615.009c0100@209.172.119.123>
Message-Id: <4.1.19990308045615.009c0100@209.172.119.123>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 
Date: Mon, 08 Mar 1999 04:58:27 -0500
To: [e-mail], [e-mail]
From: Russ Housley <[e-mail]>
Subject: 44th IETF - S/MIME Working Group Agenda
In-Reply-To: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

      S/MIME Mail Security WG Agenda

Introductions                   Russ Housley
CMS Draft Discussion            Russ Housley
X9.42 Draft Discussion          Eric Rescorla
Avoiding Small Subgroups        Robert Zuccherato
MSG Draft Discussion            Blake Ramsdell
CERT Draft Discussion           Blake Ramsdell
ESS Draft Discussion            Paul Hoffman
CERTDIST Draft Discussion       Jim Schaad
DOMSEC Draft Discussion         Bill Ottaway
S/MIME v3 Examples              Paul Hoffman
Security Policies and Labels    Russ Housley
Wrap up                         Russ Housley



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id UAA08462 for ietf-smime-bks; Tue, 9 Mar 1999 20:02:46 -0800 (PST)
Received: from spyrus.com (mail.spyrus.com [207.212.34.30]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id UAA08456 for <[e-mail]>; Tue, 9 Mar 1999 20:02:45 -0800 (PST)
Received: from rhousley_laptop.spyrus.com (hil-qbu-ppu-vty35.as.wcom.net [209.154.55.35]) by spyrus.com (8.7.6/8.7.3/arc) with SMTP id UAA22724; Tue, 9 Mar 1999 20:07:51 -0800 (PST)
Message-Id: <4.1.19990308044018.009c2e60@209.172.119.123>
Message-Id: <4.1.19990308044018.009c2e60@209.172.119.123>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 
Date: Mon, 08 Mar 1999 04:43:31 -0500
To: [e-mail]
From: Russ Housley <[e-mail]>
Subject: Re: More on KEKIdentifiers, and a suggested addition to CMS
Cc: [e-mail], [e-mail]
In-Reply-To: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Peter:

I stayed silent to see if anyone would support your suggestion.  No one
spoke for it, but no one spke against it either.  I would like to heard
from the list members regarding this suggestion.  I do not consider silence
a reason to make an additional recipient type....

Russ

At 04:19 AM 2/21/99 +0000, Peter Gutmann wrote:
>I don't know what the final resolution on optional vs mandatory
KEKIdentifiers 
>was, but I note that PKCS #15, which AFAIK is the first non-S/MIME use of CMS 
>KEK encryption, already has to explicitly state that KEKIdentifiers are null 
>strings wherever they occur because they're not useful for anything (actually 
>there's a "not recommended" special-case use for them, see below).  I think 
>this proves my earlier point that there's going to be very little use for a 
>KEKIdentifier outside S/MIME, so that making it optional would be a good idea.
> 
>Looking at the way KEKRecipientInfo is being used in PKCS #15, there's a 
>rather obvious recipient type missing from CMS: Password-based encryption.  
>PKCS #15 has a hack for this which puts the key derivation information into 
>the KEKIdentifier (this being the special-case use mentioned above), but I'm 
>sure this isn't what it was intended for because it isn't a key identifier at 
>all but contains the AlgorithmIdentifier for the password processing.  What's 
>really needed is a new recipient type, PasswordRecipientInfo.  Included below 
>is a suggestion for this which could drop directly into the CMS draft.
> 
>Peter.
> 
>-- Snip --
> 
>6.2.4  PasswordRecipientInfo Type
> 
>   Recipient information using a user-supplied password is represented in the
>   type PasswordRecipientInfo.  Each instance of PasswordRecipientInfo will
>   transfer the content-encryption key to one or more recipients who have the
>   previously agreed-upon password.
> 
>      PasswordRecipientInfo ::= SEQUENCE {
>        version CMSVersion,  -- always set to 0
>        keyDerivationAlgorithm KeyDerivationAlgorithmIdentifier,
>        keyEncryptionAlgorithm ContentEncryptionAlgorithmIdentifier,
>        encryptedKey EncryptedKey }
> 
>   The fields of type PasswordRecipientInfo have the following meanings:
> 
>      version is the syntax version number.  It shall always be 0.
> 
>      keyDerivationAlgorithm identifies the key-derivation algorithm, and any
>      associated parameters, used to derive the key-encryption key from the
>      user-supplied password.
> 
>      keyEncryptionAlgorithm identifies the content-encryption algorithm, and
>      any associated parameters, used to encrypt the content-encryption key
>      with the password-derived key-encryption key.
> 
>      encryptedKey is the result of encrypting the content-encryption key with
>      the password-derived key-encryption key.
> 
>   The key derivation algorithms are:
> 
>      KeyDerivationAlgorithmIdentifer ALGORITHM-IDENTIFIER ::= {
>        { IDENTIFIED BY id-PBKDF2 },
>        ...
>        }
> 
>    For key derivation, CMS implementations must include PBKDF2 [PKCS5v2].
>                        
>    For content (= key) encryption, CMS implementations must include 
>Triple-DES 
>    in CBC mode, should include RC2 in CBC mode, and may include other 
>    algorithms (CAST-128, RC5, IDEA, Skipjack) and modes as required.  CMS 
>    implementations should not include any KSG ciphers such as RC4.
> 
>-- Snip --
> 
>Comments:
> 
>The ContentEncryptionAlgorithmIdentifier is something like:
> 
>      ContentEncryptionAlgorithmIdentifier ::= {
>        { IDENTIFIED BY des-ede3-cbc },
>        { IDENTIFIED BY rc2CBC },
>        { IDENTIFIED BY cast5CBC },
>        { IDENTIFIED BY rc5CBC },
>        { IDENTIFIED BY ideaCBC },
>        { IDENTIFIED BY desCBC },
>        ... -- ... and anything else you can think of, eg Skipjack
>        }
> 
>but enumerating every possible one is superfluous as they're specified 
>elsewhere.
> 
>The content is encrypted is as per the KEK algorithm, but using the IV given 
>in the ContentEncryptionAlgorithmIdentifier instead of a fixed IV - this is 
>just standard CMS content encryption.  The advantage of using standard
OIDs is 
>that it doesn't require defining a completely new set of OIDs which parallel 
>all of the existing ones just to show that you're encrypting a key.  Another 
>way to handle this is as EncryptedContentInfo (which just adds an extra 
>SEQUENCE around the existing ContentEncryptionAlgorithmIdentifier + 
>EncryptedContent (=EncryptedKey)), but this is probably going overboard.
> 
>(I'm prepared to accept a 'kekid [0] KEKIdentifier OPTIONAL' after the
version 
> number if that's what's required to get people's grunt of approval for the 
> thing).
> 
>(Before people complain that you can't change the key wrap algorithm, if it 
> ever does become necessary to change it (and I thought the point of the 
> current key wrap design process was to build a solution once and for all), 
> all you need to do is increment the RecipientInfo version number and add 
> whatever you feel like).
> 
>Peter.
> 
>


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id UAA08422 for ietf-smime-bks; Tue, 9 Mar 1999 20:02:30 -0800 (PST)
Received: from spyrus.com (mail.spyrus.com [207.212.34.30]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id UAA08415 for <[e-mail]>; Tue, 9 Mar 1999 20:02:29 -0800 (PST)
Received: from rhousley_laptop.spyrus.com (hil-qbu-ppu-vty35.as.wcom.net [209.154.55.35]) by spyrus.com (8.7.6/8.7.3/arc) with SMTP id UAA22701; Tue, 9 Mar 1999 20:07:32 -0800 (PST)
Message-Id: <4.1.19990308043637.009ade70@209.172.119.123>
Message-Id: <4.1.19990308043637.009ade70@209.172.119.123>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 
Date: Mon, 08 Mar 1999 04:37:29 -0500
To: [e-mail]
From: Russ Housley <[e-mail]>
Subject: Re: Correct definition of ContentInfo in CMS-10
Cc: [e-mail], [e-mail]
In-Reply-To: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Peter:

Thanks for pointing out the error in the Appendix.  You are correct,
content is NOT OPTIONAL.

Russ


At 03:46 AM 2/23/99 +0000, Peter Gutmann wrote:
>>>Within the body of CMS 10 ContentInfo is defined as : -
>>>
>>>ContentInfo ::= SEQUENCE {
>>>        contentType ContentType,
>>>        content [0] EXPLICIT ANY DEFINED BY contentType }
>>>
>>>However, in the appendix ContentInfo is defined as : -
>>>
>>>ContentInfo ::= SEQUENCE {
>>>     contentType ContentType,
>>>     content [0] EXPLICIT ANY DEFINED BY contentType OPTIONAL }
>>>
>>>I assume the one within the body (i.e. content not optional) is correct.
> 
>>I assume that content is not optional
> 
>The content is optional.  Think about how detached sigs work.
> 
>Peter.
>


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id UAA27010 for ietf-smime-bks; Sat, 6 Mar 1999 20:09:21 -0800 (PST)
Received: from aum (ip11.proper.com [165.227.249.11]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id UAA27003 for <[e-mail]>; Sat, 6 Mar 1999 20:09:19 -0800 (PST)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.25 (Beta)
Date: Sat, 06 Mar 1999 20:07:17 -0800
To: [e-mail]
From: Paul Hoffman / IMC <[e-mail]>
Subject: Temporary versions of new drafts
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Greetings. Blake and Russ missed the cutoff for turning in draft by a tiny 
bit and were not able to get them into the drafts directory. I've posted 
the -msg, -cert, and -cms drafts on the WG's web site at 
<http://www.imc.org/ietf-smime/>. That site also has the recent versions of 
the -ess and -certdist drafts.

--Paul Hoffman, Director
--Internet Mail Consortium


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id KAA06453 for ietf-smime-bks; Fri, 5 Mar 1999 10:37:04 -0800 (PST)
Received: from thehub.knight-hub.com ([e-mail] [205.177.16.3]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id KAA06449 for <[e-mail]>; Fri, 5 Mar 1999 10:37:00 -0800 (PST)
Received: from rhousley_laptop.spyrus.com ([205.177.169.194]) by thehub.knight-hub.com (8.8.8/8.8.8) with SMTP id NAA26228; Fri, 5 Mar 1999 13:38:59 -0500
Message-Id: <4.1.19990305132922.009ea680@209.172.119.123>
X-Sender: rhousley#207.212.34.30@209.172.119.123
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 
Date: Fri, 05 Mar 1999 13:38:45 -0500
To: Paul Van Oorschot <[e-mail]>
From: Russ Housley <[e-mail]>
Subject: RE: New Triple-DES Key Wrap Algorithm Section
Cc: [e-mail], [e-mail], [e-mail], [e-mail], [e-mail], [e-mail], [e-mail], [e-mail], [e-mail], [e-mail], [e-mail], [e-mail], [e-mail], [e-mail], [e-mail], [e-mail], [e-mail], [e-mail], [e-mail], [e-mail], [e-mail], [e-mail], [e-mail], [e-mail], [e-mail], [e-mail], [e-mail], [e-mail], [e-mail], [e-mail], [e-mail], [e-mail], [e-mail], [e-mail], [e-mail], [e-mail]
In-Reply-To: <[e-mail].c om>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Paul:

I would not be going through this effort at all if there was a standard way
to encrypt one Triple-DES key with another.  This effort is defining the
standard....

Russ

At 10:50 AM 3/5/99 -0500, Paul Van Oorschot wrote:
>Russ - does this mean that you have chosen a new, non-standard algorithm?
>
>Paul.



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id IAA05191 for ietf-smime-bks; Fri, 5 Mar 1999 08:00:33 -0800 (PST)
Received: from gatekeeper.entrust.com (gatekeeper.entrust.com [204.101.128.170]) by mail.proper.com (8.8.8/8.8.5) with SMTP id HAA05171 for <[e-mail]>; Fri, 5 Mar 1999 07:57:48 -0800 (PST)
Received: 	id KAA01606; Fri, 5 Mar 1999 10:53:28 -0500
Received: by gateway id <FR0Z4CNN>; Fri, 5 Mar 1999 10:55:38 -0500
Message-ID: <[e-mail]>
From: Paul Van Oorschot <[e-mail]>
To: [e-mail], [e-mail], [e-mail], [e-mail], [e-mail], [e-mail], [e-mail], [e-mail], [e-mail], [e-mail], [e-mail], [e-mail], [e-mail], [e-mail], [e-mail], [e-mail], [e-mail], [e-mail], [e-mail], [e-mail], [e-mail], [e-mail], [e-mail], [e-mail], [e-mail], [e-mail], [e-mail], [e-mail], [e-mail], [e-mail], [e-mail], [e-mail], [e-mail], [e-mail], [e-mail], [e-mail], "'Russ Housley'" <[e-mail]>
Subject: RE: New Triple-DES Key Wrap Algorithm Section
Date: Fri, 5 Mar 1999 10:50:48 -0500 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.1960.3)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Russ - does this mean that you have chosen a new, non-standard algorithm?

Paul.

> ----------
> From: 	Russ Housley[SMTP:[e-mail]]
> Sent: 	Thursday, March 04, 1999 11:51 AM
> To: 	[e-mail]; [e-mail]; [e-mail];
> [e-mail]; [e-mail]; [e-mail]; [e-mail];
> [e-mail]; [e-mail]; [e-mail];
> [e-mail]; [e-mail];
> [e-mail]; [e-mail];
> [e-mail]; [e-mail];
> [e-mail]; [e-mail]; [e-mail];
> [e-mail]; [e-mail]; [e-mail];
> [e-mail]; [e-mail]; [e-mail]; [e-mail];
> [e-mail]; [e-mail]; [e-mail];
> [e-mail]; [e-mail]; [e-mail]; [e-mail];
> [e-mail]; [e-mail]; [e-mail]
> Subject: 	New Triple-DES Key Wrap Algorithm Section
> 
> All:
> 
> I greatly appreciate the work that everyone has put into the open debate
> on
> key wrapping.
> 
> The 44th IETF meeting is coming up rapidly, and I would like to close this
> debate prior to the meeting.  To that end, I selected the
> double-encryption
> algorithm.  An updated CMS document has not been posted yet, so I have
> attached the text associated with key wrapping.
> 
> Based on the discussion on this list, I believe that the double-encryption
> algorithm meet the security requirements, and it is easily implemented
> with
> building blocks that are otherwise needed to implement CMS.
> 
> I will gladly facilitate the further discussion of the general wrapping
> algorithm if the participants are interested.  I do not think that
> discussion should occur on the IETF S/MIME Working Group mail list, but I
> will arrange for a separate list to be created if you want to pursue the
> general wrap algorithm.
> 
> Russ
> 
> 
> = = = = = = = = = =
> 
> 12.6  Triple-DES and RC2 Key Wrap Algorithms
> 
>    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.  Triple-DES and RC2 content-encryption
>    keys are encrypted in Cipher Block Chaining (CBC) mode [MODES].
> 
>    Key Transport algorithms allow for the content-encryption key to be
>    directly encrypted; however, key agreement and symmetric key-
>    encryption key algorithms encrypt the content-encryption key with a
>    second symmetric encryption algorithm.  This section describes how
>    the Triple-DES or RC2 content-encryption key is formatted and
>    encrypted.
> 
>    Key agreement algorithms generate a pairwise key-encryption key, and
>    a key wrap algorithm is used to encrypt the content-encryption key
>    with the pairwise key-encryption key.  Similarly, a key wrap
>    algorithm is used to encrypt the content-encryption key in a
>    previously distributed key-encryption key.
> 
>    The key-encryption key is generated by the key agreement algorithm or
>    distributed out of band.  For key agreement of RC2 key-encryption
>    keys, 128 bits must be generated as input to the key expansion
>    process used to compute the RC2 effective key [RC2].
> 
>    The same algorithm identifier is used for both 2-key and 3-key
>    Triple-DES.  When the length of the content-encryption key to be
>    wrapped is a 2-key Triple-DES key, a third key with the same value as
>    the first key is created.  Thus, all Triple-DES content-encryption
>    keys are wrapped like 3-key Triple-DES keys.
> 
> 12.6.1  Key Checksum
> 
>    The CMS Checksum Algorithm is used to provide a content-encryption
>    key integrity check value.  The algorithm is:
> 
>    1.  Compute a 20 octet SHA-1 [SHA1] message digest on the
>        content-encryption key.
>    2.  Use the most significant (first) eight octets of the message
>        digest value as the checksum value.
> 
> 12.6.2  Triple-DES Key Wrap
> 
>    The Triple-DES key wrap algorithm encrypts a Triple-DES content-
>    encryption key with a Triple-DES key-encryption key.  The Triple-DES
>    key wrap algorithm is:
> 
>    1.  Set odd parity for each of the DES key octets comprising
>        the content-encryption key, call the result CEK.
>    2.  Compute an 8 octet key checksum value on CEK as described above
>        in Section 12.6.1, call the result ICV.
>    3.  Let CEKICV = CEK || ICV.
>    4.  Generate 8 octets at random, call the result IV.
>    5.  Encrypt CEKICV in CBC mode using the key-encryption key.  Use
>        the random value generated in the previous step as the
>        initialization vector (IV).  Call the ciphertext TEMP1.
>    6.  Let TEMP2 = IV || TEMP1.
>    7.  Reverse the order of the octets in TEMP2.  That is, the most
>        significant (first) octet is swapped with the least significant
>        (last) octet, and so on.  Call the result TEMP3.
>    8.  Encrypt TEMP3 in CBC mode using the key-encryption key.  Use
>        an initialization vector (IV) of 0x4adda22c79e82105.
>        The ciphertext is 40 octets long.
> 
>    Note:  When the same content-encryption key is wrapped in different
>    key-encryption keys, a fresh initialization vector (IV) must be
>    generated for each invocation of the key wrap algorithm.
> 
> 12.6.3  Triple-DES Key Unwrap
> 
>    The Triple-DES key unwrap algorithm decrypts a Triple-DES content-
>    encryption key using a Triple-DES key-encryption key.  The Triple-DES
>    key unwrap algorithm is:
> 
>    1.  If the wrapped content-encryption key is not 40 octets, then
>        error.
>    2.  Decrypt the wrapped content-encryption key in CBC mode using
>        the key-encryption key.  Use an initialization vector (IV)
>        of 0x4adda22c79e82105.  Call the output TEMP3.
>    3.  Reverse the order of the octets in TEMP3.  That is, the most
>        significant (first) octet is swapped with the least significant
>        (last) octet, and so on.  Call the result TEMP2.
>    4.  Decompose the TEMP2 into IV and TEMP1.  IV is the most
>        significant (first) 8 octets, and TEMP1 is the least significant
>        (last) 32 octets.
>    5.  Decrypt TEMP1 in CBC mode using the key-encryption key.  Use
>        the IV value from the previous step as the initialization vector.
>        Call the ciphertext CEKICV.
>    6.  Decompose the CEKICV into CEK and ICV. CEK is the most significant
>        (first) 24 octets, and ICV is the least significant (last) 8
> octets.
>    7.  Compute an 8 octet key checksum value on CEK as described above
>        in Section 12.6.1.  If the computed key checksum value does not
>        match the decrypted key checksum value, ICV, then error.
>    8.  Check for odd parity each of the DES key octets comprising CEK.
>        If parity is incorrect, then there is an error.
>    9. Use CEK as the content-encryption key.
> 
> 12.6.4  RC2 Key Wrap
> 
>    The RC2 key wrap algorithm encrypts a RC2 content-encryption key with a
> 
>    RC2 key-encryption key.  The RC2 key wrap algorithm is:
> 
>    1.  Let the content-encryption key be called CEK, and let the length
>        of the content-encryption key in octets be called LENGTH.
>    2.  Compute an 8 octet key checksum value on CEK as described above
>        in Section 12.6.1, call the result ICV.
>    3.  Let CEKICV = LENGTH || CEK || ICV.  LENGTH is a single octet.
>    4.  Let CEKICVPAD = CEKICV || PAD.  If the length of CEKICV is a
>        multiple of 8, the PAD has a length of zero.  If the length of
>        CEKICV is not a multiple of 8, then PAD contains the fewest
>        number of random octets to make CEKICVPAD a multiple of 8.
>    5.  Generate 8 octets at random, call the result IV.
>    5.  Encrypt CEKICVPAD in CBC mode using the key-encryption key.
>        Use the random value generated in the previous step as the
>        initialization vector (IV).  Call the ciphertext TEMP1.
>    6.  Let TEMP2 = IV || TEMP1.
>    7.  Reverse the order of the octets in TEMP2.  That is, the most
>        significant (first) octet is swapped with the least significant
>        (last) octet, and so on.  Call the result TEMP3.
>    8.  Encrypt TEMP3 in CBC mode using the key-encryption key.  Use
>        an initialization vector (IV) of 0x4adda22c79e82105.
> 
>    Note:  When the same content-encryption key is wrapped in different
>    key-encryption keys, a fresh initialization vector (IV) must be
>    generated for each invocation of the key wrap algorithm.
> 
> 12.6.5  RC2 Key Unwrap
> 
>    The RC2 key unwrap algorithm decrypts a RC2 content-encryption key
>    using a RC2 key-encryption key.  The RC2 key unwrap algorithm is:
> 
>    1.  If the wrapped content-encryption key is not a multiple of 8
>        octets, then error.
>    2.  Decrypt the wrapped content-encryption key in CBC mode using
>        the key-encryption key.  Use an initialization vector (IV)
>        of 0x4adda22c79e82105.  Call the output TEMP3.
>    3.  Reverse the order of the octets in TEMP3.  That is, the most
>        significant (first) octet is swapped with the least significant
>        (last) octet, and so on.  Call the result TEMP2.
>    4.  Decompose the TEMP2 into IV and TEMP1.  IV is the most
>        significant (first) 8 octets, and TEMP1 is the remaining octets.
>    5.  Decrypt TEMP1 in CBC mode using the key-encryption key.  Use
>        the IV value from the previous step as the initialization vector.
>        Call the ciphertext CEKICVPAD.
>    6.  Decompose the CEKICVPAD into LENGTH, CEK, ICV, and PAD.  LENGTH is
>        the most significant (first) octet.  CEK is the following LENGTH
>        octets.  ICV is the following 8 octets.  PAD is the remaining
>        octets, if any.
>    7.  If PAD is more than 7 octets, then error.
>    8.  Compute an 8 octet key checksum value on CEK as described above
>        in Section 12.6.1.  If the computed key checksum value does not
>        match the decrypted key checksum value, ICV, then error.
>    9.  Use CEK as the content-encryption key.
> 
> Security Considerations
> 
>    Section 12.6 specifies key wrap algorithms used to encrypt a Triple-
>    DES [3DES] content-encryption key with a Triple-DES key-encryption
>    key or to encrypt a RC2 [RC2] content-encryption key with a RC2 key-
>    encryption key.  The key wrap algorithms make use of CBC mode
>    [MODES].  These key wrap algorithms have been reviewed for use with
>    Triple and RC2.  They have not been reviewed for use with other
>    cryptographic modes or other encryption algorithms.  Therefore, if a
>    CMS implementation wishes to support ciphers in addition to Triple-
>    DES or RC2, then additional key wrap algorithms need to be defined to
>    support the additional ciphers.
> 
> 


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id RAA20384 for ietf-smime-bks; Thu, 4 Mar 1999 17:34:31 -0800 (PST)
Received: from ietf.org (odin.ietf.org [132.151.1.176]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id RAA20380 for <[e-mail]>; Thu, 4 Mar 1999 17:34:30 -0800 (PST)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA20829; Thu, 4 Mar 1999 20:39:30 -0500 (EST)
Message-Id: <[e-mail]>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: [e-mail]
From: [e-mail]
Reply-to: [e-mail]
Subject: I-D ACTION:draft-ietf-smime-ess-11.txt
Date: Thu, 04 Mar 1999 20:39:29 -0500
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?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.

Note: This revision reflects comments received during the last call period.

	Title		: Enhanced Security Services for S/MIME
	Author(s)	: P. Hoffman
	Filename	: draft-ietf-smime-ess-11.txt
	Pages		: 37
	Date		: 03-Mar-99
	
This document describes four optional security service extensions for
S/MIME. The services are:
 - signed receipts
 - security labels
 - secure mailing lists
 - signing certificates
The first three of these services provide functionality that is similar to
the Message Security Protocol [MSP4], but are useful in many other
environments, particularly business and finance. Signing certificates are
useful in any environment where certificates might be transmitted with
signed messages.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-smime-ess-11.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-ess-11.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:
	[e-mail].
In the body type:
	"FILE /internet-drafts/draft-ietf-smime-ess-11.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="[e-mail]"

Content-Type: text/plain
Content-ID:	<[e-mail]>

ENCODING mime
FILE /internet-drafts/draft-ietf-smime-ess-11.txt

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

Content-Type: text/plain
Content-ID:	<[e-mail]>

--OtherAccess--

--NextPart--




Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id LAA17270 for ietf-smime-bks; Thu, 4 Mar 1999 11:48:49 -0800 (PST)
Received: from thehub.knight-hub.com ([e-mail] [205.177.16.3]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id LAA17266 for <[e-mail]>; Thu, 4 Mar 1999 11:48:48 -0800 (PST)
Received: from rhousley_laptop.spyrus.com ([205.177.169.194]) by thehub.knight-hub.com (8.8.8/8.8.8) with SMTP id OAA21876; Thu, 4 Mar 1999 14:54:14 -0500
Message-Id: <4.1.19990304125831.00924540@209.172.119.123>
Message-Id: <4.1.19990304125831.00924540@209.172.119.123>
X-Sender: rhousley#207.212.34.30@209.172.119.123 (Unverified)
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 
Date: Thu, 04 Mar 1999 13:07:45 -0500
To: "Bonatti, Chris" <[e-mail]>
From: Russ Housley <[e-mail]>
Subject: Re: Correct definition of ContentInfo in CMS-10
Cc: William Ottaway <[e-mail]>, "'[e-mail]'" <[e-mail]>
In-Reply-To: <[e-mail]>
References: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Agree.  The OID in ContentInfo should not be OPTIONAL.


At 09:42 AM 2/22/99 -0500, Bonatti, Chris wrote:
>    I would submit that the 'content' field in the General Syntax section is
>correct.  The instance of OPTIONAL in the appendix must be a copy artifact
>from the 'EncapsulatedContentInfo', in which the 'content' field is
>correctly optional.  I can see no legitimate use of CMS in which you would
>send only a 'contentType' OID.  Even if someone were sending a "detached
>content" in a separate body part, either MIME or X.400 mail systems are
>perfectly capable of attaching a content types for that information without
>utilizing this structure.
>
>Russ,
>
>    Browsing through my historical archive of now "non-existent" I-Ds, I see
>that the OPTIONAL tag seems to have fallen out of the General Syntax
>starting in version 3 of CMS.  Do you remember the reasoning behind the
>change?
>
>Chris
>
>
>
> ---------------------------------------------------------------
> |  International Electronic Communication Analysts, Inc.      |
> |  Christopher D. Bonatti             15309 Turkey Foot Road  |
> |  Principal Engineer              Darnestown, Md 20878-3640  |
> |  [e-mail]   Tel: [phone]   Fax: [phone]  |
> ---------------------------------------------------------------
>
>
>
>____________________
>
>William Ottaway wrote:
>
>> Within the body of CMS 10 ContentInfo is defined as : -
>>
>> ContentInfo ::= SEQUENCE {
>>         contentType ContentType,
>>         content [0] EXPLICIT ANY DEFINED BY contentType }
>>
>> However, in the appendix ContentInfo is defined as : -
>>
>> ContentInfo ::= SEQUENCE {
>>      contentType ContentType,
>>      content [0] EXPLICIT ANY DEFINED BY contentType OPTIONAL }
>>
>> I assume the one within the body (i.e. content not optional) is correct.
>>
>> Bill.
>>
>> "The Information contained in this E-Mail and any subsequent
>> correspondence is private and is intended solely for the intended
>> recipient(s).  For those other than the intended recipient any
>> disclosure, copying, distribution, or any action taken or omitted to
>> be taken in reliance on such information is prohibited and may be
>> unlawful."
>> ____________________________________________________
>> William Ottaway BSc Hons CEng MBCS,
>> L323,                        Tel: [phone]
>> DERA Malvern,                Fax: [phone]
>> St. Andrews Road,            email: [e-mail]
>> Malvern,
>> Worcs,
>> WR14 3PS
>>
>> All opinions are my own.
>
>
>


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id LAA17260 for ietf-smime-bks; Thu, 4 Mar 1999 11:48:45 -0800 (PST)
Received: from thehub.knight-hub.com ([e-mail] [205.177.16.3]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id LAA17256 for <[e-mail]>; Thu, 4 Mar 1999 11:48:44 -0800 (PST)
Received: from rhousley_laptop.spyrus.com ([205.177.169.194]) by thehub.knight-hub.com (8.8.8/8.8.8) with SMTP id OAA21872; Thu, 4 Mar 1999 14:54:12 -0500
Message-Id: <4.1.19990304124721.00985440@209.172.119.123>
Message-Id: <4.1.19990304124721.00985440@209.172.119.123>
X-Sender: rhousley#207.212.34.30@209.172.119.123 (Unverified)
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 
Date: Thu, 04 Mar 1999 12:57:26 -0500
To: Eric Rescorla <[e-mail]>
From: Russ Housley <[e-mail]>
Subject: Re: Comments on x942-05 draft 
Cc: [e-mail], [e-mail], [e-mail]
In-Reply-To: <[e-mail]>
References: <Your message of "Fri, 19 Feb 1999 08:50:30 EST."             <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Eric:

I am comfortable mandating the effective and real key lengths are the same
for the calculation of the key-encrypting key.  If some policy wants to use
a reduced effective key length for the content-encryption key, thsi can
still be accomodated.

Russ


At 09:14 AM 2/22/99 -0800, Eric Rescorla wrote:
>> Here's some analysis on the RC2 effective key issue, thanks to Burt Kaliski.
>[...]
>Clearly we do have to defend against the partition attack on effective
>key lengths. 
>
>As John suggests, I propose that we place the RC2 effective key 
>length into the the suppPubInfo. However, this leaves us with
>an unfortunate inconsistency, in that for some algorithms it's
>the length and some it's the effective length. One solution
>to this would be to revert to what Stephen Henson has termed
>the X/8 strategy. I.e. make the effective and real lengths
>the same for RC2. This is slightly more tasteful than having
>a bunch of special case language.
>
>Comments? I'd like to get this settled quickly.
>
>-Ekr
>[Eric Rescorla                                   [e-mail]]
>


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id JAA16064 for ietf-smime-bks; Thu, 4 Mar 1999 09:39:39 -0800 (PST)
Received: from thehub.knight-hub.com ([e-mail] [205.177.16.3]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id JAA16060 for <[e-mail]>; Thu, 4 Mar 1999 09:39:38 -0800 (PST)
Received: from rhousley_laptop.spyrus.com ([205.177.169.194]) by thehub.knight-hub.com (8.8.8/8.8.8) with SMTP id MAA16283 for <[e-mail]>; Thu, 4 Mar 1999 12:45:09 -0500
Message-Id: <4.1.19990304115333.00980100@209.172.119.123>
X-Sender: rhousley#207.212.34.30@209.172.119.123
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 
Date: Thu, 04 Mar 1999 11:54:50 -0500
To: [e-mail]
From: Russ Housley <[e-mail]>
Subject: I-D ACTION:draft-ietf-pkix-dhpop-00.txt
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Since Ephemeral-Static Diffie-Hemman is a mandatory to implement CMS
algorithm, this document may be of interest to S/MIME WG members.

Russ


>To: IETF-Announce: ;
>Cc: [e-mail]
>From: [e-mail]
>Reply-to: [e-mail]
>Subject: I-D ACTION:draft-ietf-pkix-dhpop-00.txt
>Date: Tue, 02 Mar 1999 18:15:32 -0500
>Sender: [e-mail]
>List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
>List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
>
>A New Internet-Draft is available from the on-line Internet-Drafts
directories.
>This draft is a work item of the Public-Key Infrastructure (X.509) Working 
>Group 
>of the IETF.
>
>	Title		: Diffie-Hellman Proof-of-Possession Algorithms
>	Author(s)	: H. Prafullchandra, J. Schaad
>	Filename	: draft-ietf-pkix-dhpop-00.txt
>	Pages		: 9
>	Date		: 01-Mar-99
>	
>  This document describes two methods for producing a signature from a
>  Diffie-Hellman key pair.  This behavior is needed for such operations
>  as creating a signature of a PKCS #10 certification request.  These
>  algorithms are designed to provide a proof-of-possession rather than
>  general purpose signing.
>
>
>A URL for this Internet-Draft is:
>http://www.ietf.org/internet-drafts/draft-ietf-pkix-dhpop-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-pkix-dhpop-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:
>	[e-mail].
>In the body type:
>	"FILE /internet-drafts/draft-ietf-pkix-dhpop-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.
>Content-Type: text/plain
>Content-ID:	<[e-mail]>
>
>ENCODING mime
>FILE /internet-drafts/draft-ietf-pkix-dhpop-00.txt
>
><ftp://ftp.ietf.org/internet-drafts/draft-ietf-pkix-dhpop-00.txt>



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id JAA15642 for ietf-smime-bks; Thu, 4 Mar 1999 09:01:06 -0800 (PST)
Received: from thehub.knight-hub.com ([e-mail] [205.177.16.3]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id JAA15638 for <[e-mail]>; Thu, 4 Mar 1999 09:01:05 -0800 (PST)
Received: from rhousley_laptop.spyrus.com ([205.177.169.194]) by thehub.knight-hub.com (8.8.8/8.8.8) with SMTP id LAA14187; Thu, 4 Mar 1999 11:52:06 -0500
Message-Id: <4.1.19990304110718.009ac2a0@209.172.119.123>
X-Sender: rhousley#207.212.34.30@209.172.119.123
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 
Date: Thu, 04 Mar 1999 11:51:57 -0500
To: <[e-mail]>, <[e-mail]>, <[e-mail]>, <[e-mail]>, <[e-mail]>, <[e-mail]>, <[e-mail]>, <[e-mail]>, <[e-mail]>, <[e-mail]>, <[e-mail]>, <[e-mail]>, <[e-mail]>, <[e-mail]>, <[e-mail]>, <[e-mail]>, <[e-mail]>, <[e-mail]>, <[e-mail]>, <[e-mail]>, <[e-mail]>, <[e-mail]>, <[e-mail]>, <[e-mail]>, <[e-mail]>, <[e-mail]>, <[e-mail]>, <[e-mail]>, <[e-mail]>, <[e-mail]>, <[e-mail]>, <[e-mail]>, <[e-mail]>, <[e-mail]>, <[e-mail]>, [e-mail]
From: Russ Housley <[e-mail]>
Subject: New Triple-DES Key Wrap Algorithm Section
In-Reply-To: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

All:

I greatly appreciate the work that everyone has put into the open debate on
key wrapping.

The 44th IETF meeting is coming up rapidly, and I would like to close this
debate prior to the meeting.  To that end, I selected the double-encryption
algorithm.  An updated CMS document has not been posted yet, so I have
attached the text associated with key wrapping.

Based on the discussion on this list, I believe that the double-encryption
algorithm meet the security requirements, and it is easily implemented with
building blocks that are otherwise needed to implement CMS.

I will gladly facilitate the further discussion of the general wrapping
algorithm if the participants are interested.  I do not think that
discussion should occur on the IETF S/MIME Working Group mail list, but I
will arrange for a separate list to be created if you want to pursue the
general wrap algorithm.

Russ


= = = = = = = = = =

12.6  Triple-DES and RC2 Key Wrap Algorithms

   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.  Triple-DES and RC2 content-encryption
   keys are encrypted in Cipher Block Chaining (CBC) mode [MODES].

   Key Transport algorithms allow for the content-encryption key to be
   directly encrypted; however, key agreement and symmetric key-
   encryption key algorithms encrypt the content-encryption key with a
   second symmetric encryption algorithm.  This section describes how
   the Triple-DES or RC2 content-encryption key is formatted and
   encrypted.

   Key agreement algorithms generate a pairwise key-encryption key, and
   a key wrap algorithm is used to encrypt the content-encryption key
   with the pairwise key-encryption key.  Similarly, a key wrap
   algorithm is used to encrypt the content-encryption key in a
   previously distributed key-encryption key.

   The key-encryption key is generated by the key agreement algorithm or
   distributed out of band.  For key agreement of RC2 key-encryption
   keys, 128 bits must be generated as input to the key expansion
   process used to compute the RC2 effective key [RC2].

   The same algorithm identifier is used for both 2-key and 3-key
   Triple-DES.  When the length of the content-encryption key to be
   wrapped is a 2-key Triple-DES key, a third key with the same value as
   the first key is created.  Thus, all Triple-DES content-encryption
   keys are wrapped like 3-key Triple-DES keys.

12.6.1  Key Checksum

   The CMS Checksum Algorithm is used to provide a content-encryption
   key integrity check value.  The algorithm is:

   1.  Compute a 20 octet SHA-1 [SHA1] message digest on the
       content-encryption key.
   2.  Use the most significant (first) eight octets of the message
       digest value as the checksum value.

12.6.2  Triple-DES Key Wrap

   The Triple-DES key wrap algorithm encrypts a Triple-DES content-
   encryption key with a Triple-DES key-encryption key.  The Triple-DES
   key wrap algorithm is:

   1.  Set odd parity for each of the DES key octets comprising
       the content-encryption key, call the result CEK.
   2.  Compute an 8 octet key checksum value on CEK as described above
       in Section 12.6.1, call the result ICV.
   3.  Let CEKICV = CEK || ICV.
   4.  Generate 8 octets at random, call the result IV.
   5.  Encrypt CEKICV in CBC mode using the key-encryption key.  Use
       the random value generated in the previous step as the
       initialization vector (IV).  Call the ciphertext TEMP1.
   6.  Let TEMP2 = IV || TEMP1.
   7.  Reverse the order of the octets in TEMP2.  That is, the most
       significant (first) octet is swapped with the least significant
       (last) octet, and so on.  Call the result TEMP3.
   8.  Encrypt TEMP3 in CBC mode using the key-encryption key.  Use
       an initialization vector (IV) of 0x4adda22c79e82105.
       The ciphertext is 40 octets long.

   Note:  When the same content-encryption key is wrapped in different
   key-encryption keys, a fresh initialization vector (IV) must be
   generated for each invocation of the key wrap algorithm.

12.6.3  Triple-DES Key Unwrap

   The Triple-DES key unwrap algorithm decrypts a Triple-DES content-
   encryption key using a Triple-DES key-encryption key.  The Triple-DES
   key unwrap algorithm is:

   1.  If the wrapped content-encryption key is not 40 octets, then
       error.
   2.  Decrypt the wrapped content-encryption key in CBC mode using
       the key-encryption key.  Use an initialization vector (IV)
       of 0x4adda22c79e82105.  Call the output TEMP3.
   3.  Reverse the order of the octets in TEMP3.  That is, the most
       significant (first) octet is swapped with the least significant
       (last) octet, and so on.  Call the result TEMP2.
   4.  Decompose the TEMP2 into IV and TEMP1.  IV is the most
       significant (first) 8 octets, and TEMP1 is the least significant
       (last) 32 octets.
   5.  Decrypt TEMP1 in CBC mode using the key-encryption key.  Use
       the IV value from the previous step as the initialization vector.
       Call the ciphertext CEKICV.
   6.  Decompose the CEKICV into CEK and ICV. CEK is the most significant
       (first) 24 octets, and ICV is the least significant (last) 8 octets.
   7.  Compute an 8 octet key checksum value on CEK as described above
       in Section 12.6.1.  If the computed key checksum value does not
       match the decrypted key checksum value, ICV, then error.
   8.  Check for odd parity each of the DES key octets comprising CEK.
       If parity is incorrect, then there is an error.
   9. Use CEK as the content-encryption key.

12.6.4  RC2 Key Wrap

   The RC2 key wrap algorithm encrypts a RC2 content-encryption key with a 
   RC2 key-encryption key.  The RC2 key wrap algorithm is:

   1.  Let the content-encryption key be called CEK, and let the length
       of the content-encryption key in octets be called LENGTH.
   2.  Compute an 8 octet key checksum value on CEK as described above
       in Section 12.6.1, call the result ICV.
   3.  Let CEKICV = LENGTH || CEK || ICV.  LENGTH is a single octet.
   4.  Let CEKICVPAD = CEKICV || PAD.  If the length of CEKICV is a
       multiple of 8, the PAD has a length of zero.  If the length of
       CEKICV is not a multiple of 8, then PAD contains the fewest
       number of random octets to make CEKICVPAD a multiple of 8.
   5.  Generate 8 octets at random, call the result IV.
   5.  Encrypt CEKICVPAD in CBC mode using the key-encryption key.
       Use the random value generated in the previous step as the
       initialization vector (IV).  Call the ciphertext TEMP1.
   6.  Let TEMP2 = IV || TEMP1.
   7.  Reverse the order of the octets in TEMP2.  That is, the most
       significant (first) octet is swapped with the least significant
       (last) octet, and so on.  Call the result TEMP3.
   8.  Encrypt TEMP3 in CBC mode using the key-encryption key.  Use
       an initialization vector (IV) of 0x4adda22c79e82105.

   Note:  When the same content-encryption key is wrapped in different
   key-encryption keys, a fresh initialization vector (IV) must be
   generated for each invocation of the key wrap algorithm.

12.6.5  RC2 Key Unwrap

   The RC2 key unwrap algorithm decrypts a RC2 content-encryption key
   using a RC2 key-encryption key.  The RC2 key unwrap algorithm is:

   1.  If the wrapped content-encryption key is not a multiple of 8
       octets, then error.
   2.  Decrypt the wrapped content-encryption key in CBC mode using
       the key-encryption key.  Use an initialization vector (IV)
       of 0x4adda22c79e82105.  Call the output TEMP3.
   3.  Reverse the order of the octets in TEMP3.  That is, the most
       significant (first) octet is swapped with the least significant
       (last) octet, and so on.  Call the result TEMP2.
   4.  Decompose the TEMP2 into IV and TEMP1.  IV is the most
       significant (first) 8 octets, and TEMP1 is the remaining octets.
   5.  Decrypt TEMP1 in CBC mode using the key-encryption key.  Use
       the IV value from the previous step as the initialization vector.
       Call the ciphertext CEKICVPAD.
   6.  Decompose the CEKICVPAD into LENGTH, CEK, ICV, and PAD.  LENGTH is
       the most significant (first) octet.  CEK is the following LENGTH
       octets.  ICV is the following 8 octets.  PAD is the remaining
       octets, if any.
   7.  If PAD is more than 7 octets, then error.
   8.  Compute an 8 octet key checksum value on CEK as described above
       in Section 12.6.1.  If the computed key checksum value does not
       match the decrypted key checksum value, ICV, then error.
   9.  Use CEK as the content-encryption key.

Security Considerations

   Section 12.6 specifies key wrap algorithms used to encrypt a Triple-
   DES [3DES] content-encryption key with a Triple-DES key-encryption
   key or to encrypt a RC2 [RC2] content-encryption key with a RC2 key-
   encryption key.  The key wrap algorithms make use of CBC mode
   [MODES].  These key wrap algorithms have been reviewed for use with
   Triple and RC2.  They have not been reviewed for use with other
   cryptographic modes or other encryption algorithms.  Therefore, if a
   CMS implementation wishes to support ciphers in addition to Triple-
   DES or RC2, then additional key wrap algorithms need to be defined to
   support the additional ciphers.




Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id IAA15076 for ietf-smime-bks; Thu, 4 Mar 1999 08:01:23 -0800 (PST)
Received: from thehub.knight-hub.com ([e-mail] [205.177.16.3]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id IAA15071 for <[e-mail]>; Thu, 4 Mar 1999 08:01:22 -0800 (PST)
Received: from rhousley_laptop.spyrus.com ([205.177.169.194]) by thehub.knight-hub.com (8.8.8/8.8.8) with SMTP id LAA12181; Thu, 4 Mar 1999 11:06:52 -0500
Message-Id: <4.1.19990304110332.009dca80@209.172.119.123>
X-Sender: rhousley#207.212.34.30@209.172.119.123
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 
Date: Thu, 04 Mar 1999 11:03:52 -0500
To: "Blake Ramsdell" <[e-mail]>
From: Russ Housley <[e-mail]>
Subject: RE: CERT changes in IETF last call -- please review
Cc: "'[e-mail]'" <[e-mail]>
In-Reply-To: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Ooops.  I still do not see CERT-07 on the server.....

Russ


At 04:27 PM 1/28/99 -0800, Blake Ramsdell wrote:
>> -----Original Message-----
>> From: Blake Ramsdell 
>> Sent: Thursday, January 28, 1999 3:59 PM
>> To: '[e-mail]'
>> Subject: CERT changes in IETF last call -- please review
>> 
>> These are the changes that I am making in MSG-07 that were 
>> requested during
>> IETF last call.
>
>Uh, I mean CERT-07 if you didn't already figure that out.
>
>Blake
>--
>Blake C. Ramsdell
>Worldtalk Corporation
>For current info, check http://www.deming.com/users/blaker
>Voice [phone] x103  Fax [phone]
>



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id GAA14088 for ietf-smime-bks; Thu, 4 Mar 1999 06:04:10 -0800 (PST)
Received: from thehub.knight-hub.com ([e-mail] [205.177.16.3]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id GAA14081 for <[e-mail]>; Thu, 4 Mar 1999 06:03:57 -0800 (PST)
Received: from rhousley_laptop.spyrus.com ([205.177.169.194]) by thehub.knight-hub.com (8.8.8/8.8.8) with SMTP id JAA07342; Thu, 4 Mar 1999 09:08:41 -0500
Message-Id: <4.1.19990304085554.009f7930@209.172.119.123>
X-Sender: rhousley#207.212.34.30@209.172.119.123
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 
Date: Thu, 04 Mar 1999 09:08:40 -0500
To: "Bob Jueneman" <[e-mail]>
From: Russ Housley <[e-mail]>
Subject: Re: A New Triple-DES Key Wrap Algorithm
Cc: <[e-mail]>, <[e-mail]>, <[e-mail]>, <[e-mail]>, <[e-mail]>, <[e-mail]>, <[e-mail]>, <[e-mail]>, <[e-mail]>, <[e-mail]>, <[e-mail]>, <[e-mail]>, <[e-mail]>, <[e-mail]>, <[e-mail]>, <[e-mail]>, <[e-mail]>, <[e-mail]>, <[e-mail]>, <[e-mail]>, <[e-mail]>, <[e-mail]>, "Tolga Acar" <[e-mail]>, <[e-mail]>, <[e-mail]>, <[e-mail]>, <[e-mail]>, <[e-mail]>, <[e-mail]>, <[e-mail]>, <[e-mail]>, <[e-mail]>, <[e-mail]>, <[e-mail]>, <[e-mail]>, <[e-mail]>
In-Reply-To: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Bob:

>You are correct, of course.  The question, then, is whether
>we should just go to the OAEP-type wrapping and not have
>to worry about changing IV's and how to convey them.
>That would be my recommendation.

I think that OAEP has the same issue.  Each time a key is wrapped, a
different random number must be used.  This is the same a generating a new
IV for the first encryption.


>On a slightly different issue, several times I have strongly urged
>that in order to avoid the problem of having N-squared algorithm
>IDs for all of the various combinations of CEK and KEK algorithms,
>key lengths, and other miscellaneous data, that we first wrap
>the CEK in a descriptive ASN.1 structure that describes the 
>the CEK algorithm/key, and then do the wrapping operation.
>
>However, although I've raised this issue several times and indicated
>our strong desire to solve the key wrapping issue once and for all,
>you have neither incorporated the idea or argued against it,
>so I don't know where you stand.

I think I was clear on this point in an earlier posting.  My first priority
is to finish S/MIME v3.  If the general key wrapping problem is solved at
the same time, fine.  The S/MIME v3 structure includes an
AlgorithmIdentifier for the key wrapping algorithm, so if a secure solution
is included in the documents today, it can be aougmented with a general
solution when it is fully vetted.


>Obviously anyone who is processing certificates is going to have to 
>have an ASN.1 decoder, and Dr. Acar, who wrote ours, assures 
>me that the performance implications would be negligible compared to
>almost any encryption operation.
>
>Assuming that is the case, the only reason I could see for not doing 
>it would be concern about the increase in wrapped key size,
>or some lingering not-invented-here bias against ISO/ITU/X.500
>mechanisms.  I certainly hope it isn't the later.

In general, ASN.1 is a good tool.  However, Burt Kaliski's attack against
the original key wrap algorithm was due to known structure in the
plaintext.  ASN.1 intruduces significant structure.  While ASN.1 or some
other encoding might be part of the general key wrap solution, I am will
avoid it in the near term.


>Is there anything in the existing protocol that is rigidly sensitive to 
>the size of the wrapped key?  If so, then that is a problem that 
>probably ought to be addressed.

No.  However, every user is concerned with overhead.  Since the
content-encryption key is wrapped once for each recipient, I am sensitive
to the multiplier.


Russ


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id HAA07232 for ietf-smime-bks; Wed, 3 Mar 1999 07:09:25 -0800 (PST)
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by mail.proper.com (8.8.8/8.8.5) with SMTP id HAA07228; Wed, 3 Mar 1999 07:09:24 -0800 (PST)
Received: from Eng.Sun.COM (engmail4 [129.144.134.6]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id HAB19668; Wed, 3 Mar 1999 07:14:20 -0800
Received: from basilisk.Eng.Sun.COM (basilisk.Eng.Sun.COM [129.144.153.121]) by Eng.Sun.COM (8.8.8+Sun/SMI-5.3) with SMTP id HAA13412; Wed, 3 Mar 1999 07:14:18 -0800 (PST)
Received: from JaffaGate by basilisk.Eng.Sun.COM (SMI-8.6/SMI-SVR4) id HAA03755; Wed, 3 Mar 1999 07:14:06 -0800
Message-ID: <003301be6589$67bb36c0$e83c9c81@JaffaGate>
Reply-To: "Yahya Al-Salqan" <[e-mail]>
From: "Yahya Al-Salqan" <[e-mail]>
To: <[e-mail]>, <[e-mail]>, <[e-mail]>, <[e-mail]>
Cc: <[e-mail]>
Subject: Fw: 1999 WET-ICE Enterprise Security Workshop
Date: Wed, 3 Mar 1999 07:20:34 -0800
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.00.0518.4
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.0518.4
X-MIME-Autoconverted: from 8bit to quoted-printable by Eng.Sun.COM id HAA13412
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by mail.proper.com id HAB07229
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Dear Colleague,

This mail is to remind you of the upcomming deadline for submissions
the Fourth International Workshop on Enterprise Security, to be held
as a part of IEEE WET-ICE '99 on June 16-18, 1999 at Stanford
University, California, USA. Deadline for paper submissions is March
22, 1999.

Electronic submissions are accepted. Please see the workshop web
page http://www.ida.liu.se/conferences/WETICE/SECWK/ for more
details.

Please accept my apologies if you receive this message more than once.

Enclosed is the Call For Papers. Your help in distributing the
CFP to interested parties would be greatly appreciated.


Sincerely,

Nahid Shahmehri
Program Co-Chair

Dept. of Computer and Information Science
Linköping University
SE-581 83 Linköping
Sweden

-Cut here--------------------------------------------------------------

     FINAL CALL FOR  PAPERS

      Submission deadline: March 22, 1999

      Fourth International Workshop on Enterprise Security
     a WET-ICE '99 workshop
June 16-18, 1999
      Stanford University, California, USA

    Sponsored by the IEEE Computer Society and CERC at West
Virginia University. Hosted by the Center for Design Research,
      Stanford University.


    This document is also available in HTML,
PostScript and PDF formats from

http://www.ida.liu.se/conferences/WETICE/SECWK/




Enterprises are becoming increasingly dependent on their information
systems to support their business and workflow activities.  There is a
need for universal electronic connectivity to support interaction and
cooperation between multiple organizations. This makes enterprise
security and confidentiality more important but at the same time more
difficult to achieve, as the multiple organizations may have
differences in their security policies and may have to interact via an
insecure Internet.

These inter-organizational enterprise systems may be very large.
Efficient tools, techniques and methodologies are therefore needed to
support the specification, analysis and implementation of security.

This workshop will focus on the problems and challenges relating to
enterprise security in inter-organizational systems. We aim to bring
together principal players from both the internetwork and the
enterprise security community and will provide plenty of time for
discussion.

Topics to be discussed include:
-------------------------------
Internet security:
* Security protocols for the Internet
* The work and efforts of IETF security groups
* Global key infrastructures

Distribution:
* Distributed database security
* Secure transactions
* Inter- and intra-organizational security
* Security of collaborative applications

Secure infrastructures:
* Secure applications and environments
* Object-oriented and CORBA Security
* Secure enterprise infrastructures
* Security algorithms
* Public key infrastructures

Security management:
* Role-based access control
* Enterprise security policies
* Security in workflow processes

The program committee welcomes both papers and panel proposals
covering these topics.


SUBMISSIONS
-----------

Authors should submit six copies of an original paper (not submitted
or published elsewhere) to one of the Program Co-Chairs. Electronic
submissions are also accepted via the World Wide Web. Instructions
and forms are available at http://mir7.ida.liu.se:8080/SECWK/ .

Submissions should include the title of the paper, the name and
affiliation of each author, a 150-word abstract, and no more than 8
keywords. Submissions should not exceed 3000 words in length.  The
name, position, address, telephone number, and if possible, fax number
and e-mail address of the author responsible for correspondence must
be included.

A representative selection of accepted papers will published in the
workshop post-proceedings. Papers accepted for publication in the
proceedings are limited to six pages (about 2000-2500 words) in IEEE
format (two columns, single spaced, 10pt Times). Authors are strongly
encouraged to adhere to this format also when submitting
papers. Detailed information on the IEEE format (together with some
templates) is available at http://www.computer.org/cspress/instruct.htm


PANEL PROPOSALS
---------------

Send six copies of panel proposals to the General Chair. Include a
title, a 150-word scope statement, proposed session chair and
panelists and their affiliations, the organizer's affiliation,
address, telephone and fax number, and e-mail address.


GENERAL CHAIR
-------------

Yahya Al-Salqan
Sun Microsystems
901 San Antonio Rd
Palo Alto, CA 94303
USA
E-mail: [e-mail]


PROGRAM CO-CHAIRS
-----------------

Nahid Shahmehri
Dept. of Computer Science
Linköping University
S-581 83 Linköping
SWEDEN
E-mail: [e-mail]

Mourad Debbabi
Computer Science Department
Laval University
Ste-Foy, Quebec, G1K 7P4
CANADA
E-mail: [e-mail]




WORKSHOP PROGRAM COMMITTEE
--------------------------

Dominique Bolignano, INRIA, France
Germano Caronni, ETH-Zentrum, Switzerland
Michael Geva, Java Security Group, USA
Jean Goubault, Gie Dyade, France
Dima Hamad, Birzeit University, West Bank
Douglas Maughan, National Security Agency, USA
Steve Lloyd, Entrust, Canada
Gary McGraw, Reliable Software Technologies Inc., USA
Aravindan Ranganathan, Sun Microsystems, USA
Sumitra Reddy, CERC, West Virginia University, USA
Vipin Samar, Oracle, USA
Bill Soley, Sun Microsystems, USA
Robert Thomys, BSI, Germany
Mark Vandenwauver, K.U. Leuven, Belgium
Wu Wen, NASA Ames Research Center, USA
Tatu Ylönen, SSH Communications Security, Finland
Nick Zhang, Trans Enterprise Technologies Inc., USA
Qun Zhong, HP Extend Enterprise Lab, USA



IMPORTANT DATES
---------------

Papers and panel proposals due  March 22, 1999
Authors notified of acceptance  April 26, 1999
Workshop                        June 16-18, 1999
Camera ready manuscripts due    June 30, 1999



INQUIRIES
---------

For further information, please contact one of the Chairs,
or visit the workshop web pages:
  http://www.ida.liu.se/conferences/WETICE/SECWK/

For inquires regarding WET ICE in general, contact
[e-mail] or call (U.S.) [phone], or
visit
  http://www.ida.liu.se/conferences/WETICE/










Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id VAA01691 for ietf-smime-bks; Tue, 2 Mar 1999 21:23:45 -0800 (PST)
Received: from mailserver ([202.54.106.237]) by mail.proper.com (8.8.8/8.8.5) with SMTP id VAA01687 for <[e-mail]>; Tue, 2 Mar 1999 21:23:39 -0800 (PST)
Received: by mailserver with XtraMail-SMTP/POP3-Server (v1.10 58210006074) for <[e-mail]> at Wed, 3 Mar 99  10:49:12 +0530
Received: from proxy1.ba.best.com ([e-mail] [206.184.139.12]) by fpage1.ba.best.com (8.9.2/8.9.2/best.sh) with ESMTP id TAA18218 for <[e-mail]>; Tue, 2 Mar 1999 19:41:52 -0800 (PST)
Received: from ietf.org (odin.ietf.org [132.151.1.176]) by proxy1.ba.best.com (8.9.3/8.9.2/best.in) with ESMTP id TAA25615; Tue, 2 Mar 1999 19:39:26 -0800 (PST)
Received: by ietf.org (8.9.1a/8.9.1a) id WAA03090 for [e-mail]; Tue, 2 Mar 1999 22:35:19 -0500 (EST)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA16442; Tue, 2 Mar 1999 18:17:31 -0500 (EST)
Message-Id: <[e-mail]>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: [e-mail]
From: [e-mail]
Reply-to: [e-mail]
Subject: I-D ACTION:draft-ietf-smime-certdist-03.txt
Date: Tue, 02 Mar 1999 18:17:30 -0500
X-Rcpt-To: [e-mail]
X-UIDL: cad93a4638e297b36b10f1e656580a47
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?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		: Certificate Distribution Specification
	Author(s)	: J. Schaad
	Filename	: draft-ietf-smime-certdist-03.txt
	Pages		: 7
	Date		: 01-Mar-99
	
  Current methods of publishing certificates in directory services are
  restricted to just certificates.  This document provides a method of
  publishing certificates with secondary support information such as the
  SMimeCapabilities attribute (containing bulk algorithm support) in a
  way that is both authenticated and bound to a given certificate.
 
  This draft is being discussed on the 'ietf-smime' mailing list.  To
  join the list, send a message to <[e-mail]> with the
  single word 'subscribe' in the body of the message.  Also, there is a
  Web site for the mailing list at <http://www.imc.org/ietf-smime>.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-smime-certdist-03.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-certdist-03.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:
	[e-mail].
In the body type:
	"FILE /internet-drafts/draft-ietf-smime-certdist-03.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="[e-mail]"

Content-Type: text/plain
Content-ID:	<[e-mail]>

ENCODING mime
FILE /internet-drafts/draft-ietf-smime-certdist-03.txt

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

Content-Type: text/plain
Content-ID:	<[e-mail]>

--OtherAccess--

--NextPart--






Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id VAA01490 for ietf-smime-bks; Tue, 2 Mar 1999 21:08:05 -0800 (PST)
Received: from mailserver ([202.54.106.237]) by mail.proper.com (8.8.8/8.8.5) with SMTP id VAA01484 for <[e-mail]>; Tue, 2 Mar 1999 21:08:00 -0800 (PST)
Received: by mailserver with XtraMail-SMTP/POP3-Server (v1.10 58210006074) for <[e-mail]> at Wed, 3 Mar 99  10:29:09 +0570
Received: from proxy1.ba.best.com ([e-mail] [206.184.139.12]) by fpage1.ba.best.com (8.9.2/8.9.2/best.sh) with ESMTP id VAA14793 for <[e-mail]>; Mon, 1 Mar 1999 21:43:54 -0800 (PST)
Received: from ietf.org (odin.ietf.org [132.151.1.176]) by proxy1.ba.best.com (8.9.3/8.9.2/best.in) with ESMTP id VAA12273; Mon, 1 Mar 1999 21:42:33 -0800 (PST)
Received: by ietf.org (8.9.1a/8.9.1a) id AAA28518 for [e-mail]; Tue, 2 Mar 1999 00:35:03 -0500 (EST)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA06772; Mon, 1 Mar 1999 19:21:07 -0500 (EST)
Message-Id: <[e-mail]>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: [e-mail]
From: [e-mail]
Reply-to: [e-mail]
Subject: I-D ACTION:draft-ietf-smime-examples-00.txt
Date: Mon, 01 Mar 1999 19:21:06 -0500
X-Rcpt-To: [e-mail]
X-UIDL: 2d2549e84e07656204c94359c570d331
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?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		: Examples of CMS Message Bodies
	Author(s)	: P. Hoffman
	Filename	: draft-ietf-smime-examples-00.txt
	Pages		: 8
	Date		: 26-Feb-99
	
This document gives examples of message bodies formatted using the
Cryptographic Message Syntax (CMS). It includes examples of most or all
common formats; in addition, it gives examples that show common pitfalls in
implementing CMS. The purpose of this document is to help increase
interoperability for S/MIME and other protocols that rely on CMS.
 
This draft is being discussed on the 'ietf-smime' mailing list.  To join
the list, send a message to <[e-mail]> with the single
word 'subscribe' in the body of the message.  Also, there is a Web site for
the mailing list at <http://www.imc.org/ietf-smime/>.


A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-smime-examples-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-examples-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:
	[e-mail].
In the body type:
	"FILE /internet-drafts/draft-ietf-smime-examples-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="[e-mail]"

Content-Type: text/plain
Content-ID:	<[e-mail]>

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

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

Content-Type: text/plain
Content-ID:	<[e-mail]>

--OtherAccess--

--NextPart--






Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id PAA24956 for ietf-smime-bks; Tue, 2 Mar 1999 15:12:43 -0800 (PST)
Received: from ietf.org (odin.ietf.org [132.151.1.176]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id PAA24952 for <[e-mail]>; Tue, 2 Mar 1999 15:12:42 -0800 (PST)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA16442; Tue, 2 Mar 1999 18:17:31 -0500 (EST)
Message-Id: <[e-mail]>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: [e-mail]
From: [e-mail]
Reply-to: [e-mail]
Subject: I-D ACTION:draft-ietf-smime-certdist-03.txt
Date: Tue, 02 Mar 1999 18:17:30 -0500
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?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		: Certificate Distribution Specification
	Author(s)	: J. Schaad
	Filename	: draft-ietf-smime-certdist-03.txt
	Pages		: 7
	Date		: 01-Mar-99
	
  Current methods of publishing certificates in directory services are
  restricted to just certificates.  This document provides a method of
  publishing certificates with secondary support information such as the
  SMimeCapabilities attribute (containing bulk algorithm support) in a
  way that is both authenticated and bound to a given certificate.
 
  This draft is being discussed on the 'ietf-smime' mailing list.  To
  join the list, send a message to <[e-mail]> with the
  single word 'subscribe' in the body of the message.  Also, there is a
  Web site for the mailing list at <http://www.imc.org/ietf-smime>.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-smime-certdist-03.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-certdist-03.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:
	[e-mail].
In the body type:
	"FILE /internet-drafts/draft-ietf-smime-certdist-03.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="[e-mail]"

Content-Type: text/plain
Content-ID:	<[e-mail]>

ENCODING mime
FILE /internet-drafts/draft-ietf-smime-certdist-03.txt

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

Content-Type: text/plain
Content-ID:	<[e-mail]>

--OtherAccess--

--NextPart--




Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id QAA15688 for ietf-smime-bks; Mon, 1 Mar 1999 16:16:22 -0800 (PST)
Received: from ietf.org (odin.ietf.org [132.151.1.176]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id QAA15684 for <[e-mail]>; Mon, 1 Mar 1999 16:16:20 -0800 (PST)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA06772; Mon, 1 Mar 1999 19:21:07 -0500 (EST)
Message-Id: <[e-mail]>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: [e-mail]
From: [e-mail]
Reply-to: [e-mail]
Subject: I-D ACTION:draft-ietf-smime-examples-00.txt
Date: Mon, 01 Mar 1999 19:21:06 -0500
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?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		: Examples of CMS Message Bodies
	Author(s)	: P. Hoffman
	Filename	: draft-ietf-smime-examples-00.txt
	Pages		: 8
	Date		: 26-Feb-99
	
This document gives examples of message bodies formatted using the
Cryptographic Message Syntax (CMS). It includes examples of most or all
common formats; in addition, it gives examples that show common pitfalls in
implementing CMS. The purpose of this document is to help increase
interoperability for S/MIME and other protocols that rely on CMS.
 
This draft is being discussed on the 'ietf-smime' mailing list.  To join
the list, send a message to <[e-mail]> with the single
word 'subscribe' in the body of the message.  Also, there is a Web site for
the mailing list at <http://www.imc.org/ietf-smime/>.


A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-smime-examples-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-examples-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:
	[e-mail].
In the body type:
	"FILE /internet-drafts/draft-ietf-smime-examples-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="[e-mail]"

Content-Type: text/plain
Content-ID:	<[e-mail]>

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

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

Content-Type: text/plain
Content-ID:	<[e-mail]>

--OtherAccess--

--NextPart--




Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id NAA14657 for ietf-smime-bks; Mon, 1 Mar 1999 13:44:31 -0800 (PST)
Received: from prv-mail20.provo.novell.com (prv-mail20.Provo.Novell.COM [137.65.40.4]) by mail.proper.com (8.8.8/8.8.5) with SMTP id NAA14651 for <[e-mail]>; Mon, 1 Mar 1999 13:44:29 -0800 (PST)
Received: from INET-PRV-Message_Server by prv-mail20.provo.novell.com with Novell_GroupWise; Mon, 01 Mar 1999 14:39:32 -0700
Message-Id: <[e-mail]>
X-Mailer: Novell GroupWise 5.5
Date: Mon, 01 Mar 1999 14:39:08 -0700
From: "Tolga Acar" <[e-mail]>
To: <[e-mail]>, <[e-mail]>, <[e-mail]>
Cc: <[e-mail]>, <[e-mail]>, <[e-mail]>, <[e-mail]>, <[e-mail]>, <[e-mail]>, <[e-mail]>, <[e-mail]>, <[e-mail]>, <[e-mail]>, <[e-mail]>, <[e-mail]>, <[e-mail]>, <[e-mail]>, <[e-mail]>, <[e-mail]>, <[e-mail]>, <[e-mail]>, <[e-mail]>, <[e-mail]>, <[e-mail]>, <[e-mail]>, "Bob Jueneman" <[e-mail]>, <[e-mail]>, <[e-mail]>, <[e-mail]>, <[e-mail]>, <[e-mail]>, <[e-mail]>, <[e-mail]>, <[e-mail]>, <[e-mail]>, <[e-mail]>, <[e-mail]>, <[e-mail]>, <[e-mail]>
Subject: RE: A New Triple-DES Key Wrap Algorithm
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by mail.proper.com id NAA14653
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

I don't see how a random/different IV suddenly makes it all work, because it is away from being a general solution to the problem. And the problem is twofold, and more general than encrypting a DES key with TripleDES.

1. Diffusion:
Transition of the known plaintext patterns to the ciphertext in block ciphers. A very similar problem exists in image processing where the image is processed block-by-block and then you see the so-called blocking effects. The known-plaintext and birthday attack utilizes this deficiency in block-ciphers. Thus, the analysis should be done on the whole message rather than on blocks; or do "overlapped" processing on block boundaries (which isn't suitable for encryption purpose).

Another way of looking at this aould be to consider the message as the input "block", not necessarily partitioned into sub-blocks to accomodate the requirements of the underlying cipher. Longer the input message (say, ASN.1 encoded key), harder the birthday attacks. So, simply isolate the underlying block cipher details from the key wrapping, i.e., make the input size = block size. 

OAEP is a solution to this problem: a variable block-size algorithm in which it is hard to find the input unless all of the output is known. It adds "integrity" to the message - like a digital signature with message recovery.

Besides, I don't see why the key encryption algorithm has to be a block cipher, let alone a cipher requiring an IV.


2. Block encryption:
Why are we concerned so much about the known plaintext patterns in key wrapping, and not in any (data) encryption where known patterns in the plaintext may be far more common. Isn't it prudent to use OAEP (maybe with different parameters) in regular encryption?

- Tolga


>>> Burt Kaliski <[e-mail]> 3/1/99 12:35:06 >>>
Recall that OAEP (in general) has two arguments: message and parameters.

OAEP provides confidentiality to the message and integrity to the
parameters. It also binds the parameters and the message cryptographically.
It the parameters are modified, the OAEP decoding operation will detect the
change.

The set of parameters can be null, or it may contain information about the
message such as key type in the case that the message is the key.

Thus the conflict between ASN.1 and confidentiality is easily resolved: let
the message be the secret key, and let the parameters specify the type of
key, length, usage, etc. with ASN.1. This is one of the nice features of
OAEP: it is easy to carry non-confidential attributes about a message.

-- Burt 

> ----------
> From: 	Don Johnson[SMTP:[e-mail]] 
> Sent: 	Friday, February 26, 1999 4:46 PM
> To: 	Kevin Kingdon
> Cc: 	Bob Jueneman; [e-mail]; [e-mail]; [e-mail];
> [e-mail]; [e-mail]; [e-mail];
> [e-mail]; [e-mail]; [e-mail];
> [e-mail]; [e-mail];
> [e-mail]; [e-mail];
> [e-mail]; [e-mail];
> [e-mail]; [e-mail];
> [e-mail]; [e-mail]; [e-mail];
> [e-mail]; [e-mail]; [e-mail]; Tolga Acar;
> [e-mail]; [e-mail]; Burt Kaliski; [e-mail];
> [e-mail]; [e-mail]; Ron Rivest; [e-mail];
> [e-mail]; [e-mail]; [e-mail]; [e-mail];
> [e-mail] 
> Subject: 	RE: A New Triple-DES Key Wrap Algorithm
> 
> Kevin,
> 
> Here is what I am saying, I do not think it is not controversial.
> 
> 1. For any confidentiality method, such as encryption, adding in known
> quantities: A) does not keep them confidential, as they are known, and B)
> may give an adversary a toehold he would not otherwise have, for example,
> with encryption he will know some plaintext and resulting ciphertext (in
> the worst case some blocks of known plaintext/ciphertext).
> 
> 2. For that reason, I resist adding in known data to data that is intended
> to be kept confidential.  It is not forbidden to add in known data, I just
> want to believe that the cost/benefit tradeoff makes it worthwhile.  And I
> try to keep down the amount of known data if possible.
> 
> Don Johnson
> 
> 
> 
> 
> 
> Kevin Kingdon <[e-mail]> on 02/26/99 02:57:22 PM
> 
> To:   Don Johnson/Certicom, Bob Jueneman <[e-mail]>
> cc:   [e-mail], [e-mail], [e-mail],
>       [e-mail], [e-mail], [e-mail],
>       [e-mail], [e-mail], [e-mail],
>       [e-mail], [e-mail],
>       [e-mail], [e-mail],
>       [e-mail], [e-mail],
>       [e-mail], [e-mail],
>       [e-mail], [e-mail],
>       [e-mail], [e-mail], [e-mail],
>       [e-mail], Tolga Acar <[e-mail]>,
>       [e-mail], [e-mail], Burt Kaliski
>       <[e-mail]>, [e-mail], [e-mail],
>       [e-mail], Ron Rivest <[e-mail]>,
>       [e-mail], [e-mail], [e-mail],
>       [e-mail], [e-mail], [e-mail] 
> Subject:  RE: A New Triple-DES Key Wrap Algorithm
> 
> 
> 
> 
> Don,
> 
> Are you saying that the input (plaintext) to an encryption operation must
> not be structured? I thought that was what encryption was all about -
> hiding
> the structure / information content of the plaintext. In any case, doesn't
> using OAEP as a part of an encryption scheme mask the plaintext structure
> just in case the encryption primitive is vulnerable to attacks that take
> advantage of that structure?
> 
> Kevin
>           -----Original Message-----
>           From:     Don Johnson [mailto:[e-mail]] 
>           Sent:     Friday, February 26, 1999 11:25 AM
>           To:  Bob Jueneman
>           Cc:  [e-mail]; [e-mail]; [e-mail];
> [e-mail]; [e-mail]; [e-mail];
> [e-mail]; [e-mail]; [e-mail];
> [e-mail]; [e-mail];
> [e-mail]; [e-mail];
> [e-mail];
> [e-mail]; [e-mail];
> [e-mail]; [e-mail]; [e-mail];
> [e-mail]; [e-mail]; [e-mail];
> [e-mail]; Tolga Acar; [e-mail]; [e-mail];
> Burt
> Kaliski; [e-mail]; [e-mail]; [e-mail]; Ron
> Rivest; [e-mail]; [e-mail]; [e-mail];
> [e-mail]; [e-mail]; [e-mail] 
>           Subject:  Re: A New Triple-DES Key Wrap Algorithm
> 
>           Bob, Russ,
> 
>           ASN.1 is very structured and can be considered to have many
> known values.
>           As such, strictly from an info theory viewpoint, use of
> ASN.1 and
>           confidentiality are are in opposition.  This does not mean
> it should be
>           forbidden, just that we would want to have very strong
> assurances about the
>           properties provided by the encryption to use ASN.1 or
> similar highly
>           structured formats.
> 
>           Don Johnson
> 
> 
> 
> 
> 
>           "Bob Jueneman" <[e-mail]> on 02/26/99 01:38:19
> PM
> 
>           To:   [e-mail] 
>           cc:   [e-mail], [e-mail],
> [e-mail],
>                 [e-mail], [e-mail], [e-mail],
>                 [e-mail], [e-mail],
> [e-mail],
>                 [e-mail], [e-mail],
>                 [e-mail], [e-mail],
>                 [e-mail],
> [e-mail],
>                 [e-mail], [e-mail],
> [e-mail],
>                 [e-mail], [e-mail],
> [e-mail],
>                 [e-mail], "Tolga Acar"
> <[e-mail]>,
>                 [e-mail], [e-mail],
> [e-mail],
>                 [e-mail], [e-mail],
> [e-mail],
>                 [e-mail], [e-mail],
> [e-mail],
>                 [e-mail], [e-mail],
> [e-mail],
>                 [e-mail] (bcc: Don Johnson/Certicom)
>           Subject:  Re: A New Triple-DES Key Wrap Algorithm
> 
> 
> 
> 
>           Russ:
> 
>           You are correct, of course.  The question, then, is whether
>           we should just go to the OAEP-type wrapping and not have
>           to worry about changing IV's and how to convey them.
>           That would be my recommendation.
> 
>           On a slightly different issue, several times I have strongly
> urged
>           that in order to avoid the problem of having N-squared
> algorithm
>           IDs for all of the various combinations of CEK and KEK
> algorithms,
>           key lengths, and other miscellaneous data, that we first
> wrap
>           the CEK in a descriptive ASN.1 structure that describes the
>           the CEK algorithm/key, and then do the wrapping operation.
> 
>           However, although I've raised this issue several times and
> indicated
>           our strong desire to solve the key wrapping issue once and
> for all,
>           you have neither incorporated the idea or argued against it,
>           so I don't know where you stand.
> 
>           Obviously anyone who is processing certificates is going to
> have to
>           have an ASN.1 decoder, and Dr. Acar, who wrote ours, assures
>           me that the performance implications would be negligible
> compared to
>           almost any encryption operation.
> 
>           Assuming that is the case, the only reason I could see for
> not doing
>           it would be concern about the increase in wrapped key size,
>           or some lingering not-invented-here bias against
> ISO/ITU/X.500
>           mechanisms.  I certainly hope it isn't the later.
> 
>           Is there anything in the existing protocol that is rigidly
> sensitive to
>           the size of the wrapped key?  If so, then that is a problem
> that
>           probably ought to be addressed.
> 
>           If not, then I believe the architectural benefits would far
> outweigh
>           any increase in the size of the wrapped key.
> 
>           Bob
> 
>           >>> Russ Housley <[e-mail]> 02/26/99 10:51AM >>>
>           Bob:
> 
>           You raise an interesting point, but I think it can be easily
> solved by a
>           random IV for the first encryption. Of course, this makes
> the result one
>           block longer.  And, we would need a different IV for each
> wrapping.
> 
>           Russ
> 
> 
>           At 10:50 AM 2/22/99 -0700, Bob Jueneman wrote:
>           >Russ,
>           >
>           >There is a possible attack on the double encryption wrap
> algorithm
>           >that is a result of the constant IV construction. For that
> reason, I would
>           >strongly prefer the OAEP construction. Although it may look
> complicated
>           >because there are more steps, the number of line of code is
> really of no
>           >consequence at all, but the execution time is important for
> performance.
>           >
>           >Also, I continue to insist that we should not invent
> n-squared algorithm
>           >IDs for every possible combination of CEK algorithm and key
> length
>           >plus KEK algorithm and key length. Instead, I would
> _greatly_ prefer to
>           >first wrap the CEK in a ASN.1 structure that defines the
> CEK algorithm
>           >and key length, then whiten that structure with OAEP,
> encrypt the
>           resulting
>           >string with the KEK algorithm, and then provide generic
> instructions as
>           >to how to decode the result, either by wrapping the entire
> wrapped key
>           >blob in ASN.1 (preferably) or some other way.
>           >
>           >Here's the attack on the double-encryption wrapping:
>           >
>           >Although most exhaustive search engines divide up the
> search process
>           >across multiple machines in order to find a single key as
> quickly as
>           possible
>           >(e.g., the series of RSA challenge ciphers), there is
> another approach
>           >based on the use of an associative memory that I wrote up
> back
>           >in the '70's but never published.  I call it my
> "vacuum-cleaner" attack.
>           >
>           >Assume for the sake or argument that there are lots and
> lots of keys
>           >that have been or will be used to encrypt a known plaintext
> or
>           >stereotyped message.  (This is a standard assumption in
> cryptanalysis.)
>           >Actually, the attack will succeed with a somewhat weaker
> condition --
>           >it isn't necessary to actually know the plaintext -- it is
> sufficient that
>           >the plaintext be unvarying.
>           >
>           >Let's also assume that each key is used for some
> interesting purpose --
>           >sufficiently interesting that it may not be necessary to
> crack each and
>           every
>           >key -- just a few would be useful.  For example, if I were
> trying to carry
>           on
>           >a credit card attack, I don't have to find the key for Bill
> Gates' or
>           >Donald Trump's credit card -- just about anyone's will do,
> and the more
>           >the merrier.
>           >
>           >So for every new key that I have the engine try, I contrive
> to compare
>           >the result of encrypting the known plaintext against
> millions of valid
>           >ciphertexts that have been intercepted, looking for a
> match.  Assuming
>           >an effectively inexhaustible supply of ciphertexts is
> available, this
>           attack
>           >multiplies the effectiveness of the key search engine by an
> order of a
>           million
>           >or more, depending on the size of the associative memory
> that is
>           available.
>           >
>           >(The use of an associative memory isn't essential -- it was
> just a
>           gedanken
>           >experiment to speed up the comparison process without
> requiring sorting.)
>           >
>           >Two things should be noted.  First, this attack is
> independent of the KEK
>           >encryption algorithm used, assuming a fixed block size.  In
> other words,
>           >this would apply to single-DES, triple-DES, umpty-DES,
> 2048-bit RSA,
>           >or whatever, assuming a constant session key and constant
> padding.
>           >
>           >Second, the attack is also independent of the length or
> type of session
>           >key that is used, except that the yield is a Birthday
> Problem function of
>           the
>           >length of the key.  But given a fixed input, i.e., no
> random whitening or
>           >changing IV, then two or more matching outputs must imply a
> matching
>           >session key.
>           >
>           >This leads to a rather surprising result -- even if the KEK
> performs
>           double
>           >encryption using triple-DES (or any other algorithm without
> whitening)
>           >to wrap a 40 bit key, two matching session keys can be
> found with
>           >approximately 50% probability after only 2^20 or a million
> or so session
>           >keys have been generated.
>           >
>           >Perhaps more surprisingly, at least to people who haven't
> been down this
>           path,
>           >changing session keys more rapidly may hurt more than it
> helps -- it just
>           >exposes that many more keys to attack. Changing the session
> key often
>           >in the middle of a session may help limit the ability of
> the attacker to
>           >access the entire message, and hence limits the attacker's
> "take," but it
>           >increases the chances that a potentially interesting
> fragment of text
>           >may be exposed.
>           >
>           >I'm sure that someone would observe that sending even a
> million content
>           >encryption key encrypted in a constant KEK would be
> extremely unlikely
>           >in an S/MIME context, but whether that would really be true
> would require
>           >a more subtle, protocol-dependent analysis than I would
> care to make,
>           >and in addition I very much want to standardize on one key
> wrapping
>           >algorithm that is protocol independent, and not just for
> S/MIME.
>           >
>           >Obviously the above attack can be defeated by prepending
> some
>           >additional randomness or by changing the IV. But is also
> what the OAEP
>           >approach does, and rather more elegantly.  By the time we
> have to add
>           >either a changing IV or some additional randomness (how
> much would be
>           >required would have to be decided) the length would
> probably be close
>           >to that required for OAEP, which is a much more general
> solution.
>           >
>           >In my mind, at least, some extra bytes in the wrapped key
> is no big deal,
>           >but I would like the efficiency to be a good as possible.
> Triple-DES is
>           >expensive enough in terms of computational efficiency in
> software,
>           >especially in terms of the initial key expansion, and doing
> it twice
>           >would be worse yet.
>           >
>           >Because the new export regulations permit the use of double
> the key length
>           >used for data encryption to be used for key encryption, we
> are going to be
>           >using triple-DES in encrypt-decrypt-encrypt mode with only
> two keys
>           (A-B-A) for
>           >key wrapping of all export-grade CEK keys.
>           >
>           >This can be optimized by saving the key expansion of the
> first encryption,
>           and
>           >then reusing it for the final encryption.  This technique
> could
>           potentially be
>           >extended to the double encryption wrapping algorithm, by
> saving the key
>           >expansion used for all three steps, but in order to do that
> the
>           >"double-triple-DES"
>           >algorithm would probably have to be a single algorithm that
> is invoked --
>           >it would be quite difficult to securely save state across
> two separate
>           >encryption
>           >operations.
>           >
>           >So my preference, as I said earlier, would be to wrap the
> CEK in ASN.1,
>           >whiten with OAEP, and then encrypt using whatever KEK
> algorithm and
>           >key length is required, so we don't have to keep
> re-analyzing this problem
>           >for every new CEK or KEK algorithm or key length.
>           >
>           >If we can define appropriate algorithm IDs, I'm willing and
> eager to adopt
>           such
>           >a standard for  _all_ wrapped keys generated and used
> within our Novell
>           >International Cryptographic Infrastructure (NICI), even
> before S/MIME v3
>           >progresses to a full standard.  I'd be willing to assign an
> algorithm OID
>           >from the
>           >Novell tree, or we could probably get one from PKCS if
> there would be any
>           >problem getting one assigned by the IANA.
>           >
>           >Regards,
>           >
>           >Bob
>           >
>           >
>           >> Russ Housley <[e-mail]> 02/20/99 02:17PM >>>
>           >All:
>           >
>           >Right now, I am leaning toward the double encryption wrap
> algorithm.  I
>           >think it will be easy to implement, and it yeilds a shorter
> result that
>           the
>           >OAEP method.  To convince myself that it was easy to
> implement, I did an
>           >implementation.  It took me about two hours while watching
> an old Jimmy
>           >Stewart movie.  Of course, I already have SHA-1 and
> Triple-DES CBC
>           >routines.  S/MIME v3 will require these algorithms for
> other capabilities
>           >besides key wrapping.
>           >
>           >If someone else is willing to do an implementation, I would
> like to
>           compare
>           >results.  This will allow a test vector to be included with
> the algorithm
>           >description.
>           >
>           >Does anyone have any strong objections to the double
> encryption wrap
>           >algorithm being selected?
>           >
>           >Russ
>           >
>           >
>           >>WRAP ALOGRITHM #1:  DOUBLE ENCRYPTION
>           >>
>           >>Key Checksum
>           >>
>           >>The CMS Checksum Algorithm is used to provide an
> content-encryption key
>           >>integrity check value.  The algorithm is:
>           >>
>           >>1.  Compute a 20 octet SHA-1 message digest on the
>           >>    content-encryption key.
>           >>2.  Use the most significant (first) eight octets of the
>           >>    message digest value as the checksum value.
>           >>
>           >>Triple-DES Key Wrap
>           >>
>           >>1.  Set odd parity for each of the DES key octets
> comprising
>           >>    the content-encryption key, call the result CEK.
>           >>2.  Compute a 8 octet key checksum value on CEK as
> described above,
>           >>    call the result ICV.
>           >>3.  Let CEKICV = CEK || ICV.
>           >>4.  Encrypt CEKICV in CBC mode using the key-encryption
> key.  Use
>           >>    an IV of 0xc302e3c1ad8bb738.
>           >>5.  Reverse the order of the ciphertext octets.  That is,
> the most
>           >>    significant (first) octet is swapped with the least
> significant
>           >>    (last) octet, and so on.  Call the result TEMP.
>           >>6.  Encrypt TEMP in CBC mode using the key-encryption key.
> Use
>           >>    an IV of 0x61a197e5b132e196.  The ciphertext is 32
> octets long.
>           >
>           >Robert R. Jueneman
>           >Security Architect
>           >Network Security Development
>           >Novell, Inc.
>           >122 East 1700 South
>           >Provo, UT 84606
>           >[e-mail] 
>           >1-801-861-7387
> 
> 
> 
> 
> 
> 
> 
> 


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id LAA13275 for ietf-smime-bks; Mon, 1 Mar 1999 11:30:57 -0800 (PST)
Received: from eagle.rsa.com (eagle.rsa.com [192.80.211.35] (may be forged)) by mail.proper.com (8.8.8/8.8.5) with SMTP id LAA13271 for <[e-mail]>; Mon, 1 Mar 1999 11:30:49 -0800 (PST)
Received: from [10.81.217.217] by eagle.rsa.com via smtpd (for imc.org [206.184.129.134]) with SMTP; 1 Mar 1999 19:55:22 UT
Received: by lobester.rsa.com with Internet Mail Service (5.5.2232.9) id <ZNLARGRH>; Mon, 1 Mar 1999 11:40:30 -0800
Message-ID: <[e-mail]>
From: Burt Kaliski <[e-mail]>
To: Kevin Kingdon <[e-mail]>, "'Don Johnson'" <[e-mail]>
Cc: Bob Jueneman <[e-mail]>, [e-mail], [e-mail], [e-mail], [e-mail], [e-mail], [e-mail], [e-mail], [e-mail], [e-mail], [e-mail], [e-mail], [e-mail], [e-mail], [e-mail], [e-mail], [e-mail], [e-mail], [e-mail], [e-mail], [e-mail], [e-mail], [e-mail], [e-mail], Tolga Acar <[e-mail]>, [e-mail], [e-mail], [e-mail], [e-mail], [e-mail], Ron Rivest <[e-mail]>, [e-mail], [e-mail], [e-mail], [e-mail], [e-mail], [e-mail]
Subject: RE: A New Triple-DES Key Wrap Algorithm
Date: Mon, 1 Mar 1999 11:35:06 -0800 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2232.9)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Recall that OAEP (in general) has two arguments: message and parameters.

OAEP provides confidentiality to the message and integrity to the
parameters. It also binds the parameters and the message cryptographically.
It the parameters are modified, the OAEP decoding operation will detect the
change.

The set of parameters can be null, or it may contain information about the
message such as key type in the case that the message is the key.

Thus the conflict between ASN.1 and confidentiality is easily resolved: let
the message be the secret key, and let the parameters specify the type of
key, length, usage, etc. with ASN.1. This is one of the nice features of
OAEP: it is easy to carry non-confidential attributes about a message.

-- Burt 

> ----------
> From: 	Don Johnson[SMTP:[e-mail]]
> Sent: 	Friday, February 26, 1999 4:46 PM
> To: 	Kevin Kingdon
> Cc: 	Bob Jueneman; [e-mail]; [e-mail]; [e-mail];
> [e-mail]; [e-mail]; [e-mail];
> [e-mail]; [e-mail]; [e-mail];
> [e-mail]; [e-mail];
> [e-mail]; [e-mail];
> [e-mail]; [e-mail];
> [e-mail]; [e-mail];
> [e-mail]; [e-mail]; [e-mail];
> [e-mail]; [e-mail]; [e-mail]; Tolga Acar;
> [e-mail]; [e-mail]; Burt Kaliski; [e-mail];
> [e-mail]; [e-mail]; Ron Rivest; [e-mail];
> [e-mail]; [e-mail]; [e-mail]; [e-mail];
> [e-mail]
> Subject: 	RE: A New Triple-DES Key Wrap Algorithm
> 
> Kevin,
> 
> Here is what I am saying, I do not think it is not controversial.
> 
> 1. For any confidentiality method, such as encryption, adding in known
> quantities: A) does not keep them confidential, as they are known, and B)
> may give an adversary a toehold he would not otherwise have, for example,
> with encryption he will know some plaintext and resulting ciphertext (in
> the worst case some blocks of known plaintext/ciphertext).
> 
> 2. For that reason, I resist adding in known data to data that is intended
> to be kept confidential.  It is not forbidden to add in known data, I just
> want to believe that the cost/benefit tradeoff makes it worthwhile.  And I
> try to keep down the amount of known data if possible.
> 
> Don Johnson
> 
> 
> 
> 
> 
> Kevin Kingdon <[e-mail]> on 02/26/99 02:57:22 PM
> 
> To:   Don Johnson/Certicom, Bob Jueneman <[e-mail]>
> cc:   [e-mail], [e-mail], [e-mail],
>       [e-mail], [e-mail], [e-mail],
>       [e-mail], [e-mail], [e-mail],
>       [e-mail], [e-mail],
>       [e-mail], [e-mail],
>       [e-mail], [e-mail],
>       [e-mail], [e-mail],
>       [e-mail], [e-mail],
>       [e-mail], [e-mail], [e-mail],
>       [e-mail], Tolga Acar <[e-mail]>,
>       [e-mail], [e-mail], Burt Kaliski
>       <[e-mail]>, [e-mail], [e-mail],
>       [e-mail], Ron Rivest <[e-mail]>,
>       [e-mail], [e-mail], [e-mail],
>       [e-mail], [e-mail], [e-mail]
> Subject:  RE: A New Triple-DES Key Wrap Algorithm
> 
> 
> 
> 
> Don,
> 
> Are you saying that the input (plaintext) to an encryption operation must
> not be structured? I thought that was what encryption was all about -
> hiding
> the structure / information content of the plaintext. In any case, doesn't
> using OAEP as a part of an encryption scheme mask the plaintext structure
> just in case the encryption primitive is vulnerable to attacks that take
> advantage of that structure?
> 
> Kevin
>           -----Original Message-----
>           From:     Don Johnson [mailto:[e-mail]]
>           Sent:     Friday, February 26, 1999 11:25 AM
>           To:  Bob Jueneman
>           Cc:  [e-mail]; [e-mail]; [e-mail];
> [e-mail]; [e-mail]; [e-mail];
> [e-mail]; [e-mail]; [e-mail];
> [e-mail]; [e-mail];
> [e-mail]; [e-mail];
> [e-mail];
> [e-mail]; [e-mail];
> [e-mail]; [e-mail]; [e-mail];
> [e-mail]; [e-mail]; [e-mail];
> [e-mail]; Tolga Acar; [e-mail]; [e-mail];
> Burt
> Kaliski; [e-mail]; [e-mail]; [e-mail]; Ron
> Rivest; [e-mail]; [e-mail]; [e-mail];
> [e-mail]; [e-mail]; [e-mail]
>           Subject:  Re: A New Triple-DES Key Wrap Algorithm
> 
>           Bob, Russ,
> 
>           ASN.1 is very structured and can be considered to have many
> known values.
>           As such, strictly from an info theory viewpoint, use of
> ASN.1 and
>           confidentiality are are in opposition.  This does not mean
> it should be
>           forbidden, just that we would want to have very strong
> assurances about the
>           properties provided by the encryption to use ASN.1 or
> similar highly
>           structured formats.
> 
>           Don Johnson
> 
> 
> 
> 
> 
>           "Bob Jueneman" <[e-mail]> on 02/26/99 01:38:19
> PM
> 
>           To:   [e-mail]
>           cc:   [e-mail], [e-mail],
> [e-mail],
>                 [e-mail], [e-mail], [e-mail],
>                 [e-mail], [e-mail],
> [e-mail],
>                 [e-mail], [e-mail],
>                 [e-mail], [e-mail],
>                 [e-mail],
> [e-mail],
>                 [e-mail], [e-mail],
> [e-mail],
>                 [e-mail], [e-mail],
> [e-mail],
>                 [e-mail], "Tolga Acar"
> <[e-mail]>,
>                 [e-mail], [e-mail],
> [e-mail],
>                 [e-mail], [e-mail],
> [e-mail],
>                 [e-mail], [e-mail],
> [e-mail],
>                 [e-mail], [e-mail],
> [e-mail],
>                 [e-mail] (bcc: Don Johnson/Certicom)
>           Subject:  Re: A New Triple-DES Key Wrap Algorithm
> 
> 
> 
> 
>           Russ:
> 
>           You are correct, of course.  The question, then, is whether
>           we should just go to the OAEP-type wrapping and not have
>           to worry about changing IV's and how to convey them.
>           That would be my recommendation.
> 
>           On a slightly different issue, several times I have strongly
> urged
>           that in order to avoid the problem of having N-squared
> algorithm
>           IDs for all of the various combinations of CEK and KEK
> algorithms,
>           key lengths, and other miscellaneous data, that we first
> wrap
>           the CEK in a descriptive ASN.1 structure that describes the
>           the CEK algorithm/key, and then do the wrapping operation.
> 
>           However, although I've raised this issue several times and
> indicated
>           our strong desire to solve the key wrapping issue once and
> for all,
>           you have neither incorporated the idea or argued against it,
>           so I don't know where you stand.
> 
>           Obviously anyone who is processing certificates is going to
> have to
>           have an ASN.1 decoder, and Dr. Acar, who wrote ours, assures
>           me that the performance implications would be negligible
> compared to
>           almost any encryption operation.
> 
>           Assuming that is the case, the only reason I could see for
> not doing
>           it would be concern about the increase in wrapped key size,
>           or some lingering not-invented-here bias against
> ISO/ITU/X.500
>           mechanisms.  I certainly hope it isn't the later.
> 
>           Is there anything in the existing protocol that is rigidly
> sensitive to
>           the size of the wrapped key?  If so, then that is a problem
> that
>           probably ought to be addressed.
> 
>           If not, then I believe the architectural benefits would far
> outweigh
>           any increase in the size of the wrapped key.
> 
>           Bob
> 
>           >>> Russ Housley <[e-mail]> 02/26/99 10:51AM >>>
>           Bob:
> 
>           You raise an interesting point, but I think it can be easily
> solved by a
>           random IV for the first encryption. Of course, this makes
> the result one
>           block longer.  And, we would need a different IV for each
> wrapping.
> 
>           Russ
> 
> 
>           At 10:50 AM 2/22/99 -0700, Bob Jueneman wrote:
>           >Russ,
>           >
>           >There is a possible attack on the double encryption wrap
> algorithm
>           >that is a result of the constant IV construction. For that
> reason, I would
>           >strongly prefer the OAEP construction. Although it may look
> complicated
>           >because there are more steps, the number of line of code is
> really of no
>           >consequence at all, but the execution time is important for
> performance.
>           >
>           >Also, I continue to insist that we should not invent
> n-squared algorithm
>           >IDs for every possible combination of CEK algorithm and key
> length
>           >plus KEK algorithm and key length. Instead, I would
> _greatly_ prefer to
>           >first wrap the CEK in a ASN.1 structure that defines the
> CEK algorithm
>           >and key length, then whiten that structure with OAEP,
> encrypt the
>           resulting
>           >string with the KEK algorithm, and then provide generic
> instructions as
>           >to how to decode the result, either by wrapping the entire
> wrapped key
>           >blob in ASN.1 (preferably) or some other way.
>           >
>           >Here's the attack on the double-encryption wrapping:
>           >
>           >Although most exhaustive search engines divide up the
> search process
>           >across multiple machines in order to find a single key as
> quickly as
>           possible
>           >(e.g., the series of RSA challenge ciphers), there is
> another approach
>           >based on the use of an associative memory that I wrote up
> back
>           >in the '70's but never published.  I call it my
> "vacuum-cleaner" attack.
>           >
>           >Assume for the sake or argument that there are lots and
> lots of keys
>           >that have been or will be used to encrypt a known plaintext
> or
>           >stereotyped message.  (This is a standard assumption in
> cryptanalysis.)
>           >Actually, the attack will succeed with a somewhat weaker
> condition --
>           >it isn't necessary to actually know the plaintext -- it is
> sufficient that
>           >the plaintext be unvarying.
>           >
>           >Let's also assume that each key is used for some
> interesting purpose --
>           >sufficiently interesting that it may not be necessary to
> crack each and
>           every
>           >key -- just a few would be useful.  For example, if I were
> trying to carry
>           on
>           >a credit card attack, I don't have to find the key for Bill
> Gates' or
>           >Donald Trump's credit card -- just about anyone's will do,
> and the more
>           >the merrier.
>           >
>           >So for every new key that I have the engine try, I contrive
> to compare
>           >the result of encrypting the known plaintext against
> millions of valid
>           >ciphertexts that have been intercepted, looking for a
> match.  Assuming
>           >an effectively inexhaustible supply of ciphertexts is
> available, this
>           attack
>           >multiplies the effectiveness of the key search engine by an
> order of a
>           million
>           >or more, depending on the size of the associative memory
> that is
>           available.
>           >
>           >(The use of an associative memory isn't essential -- it was
> just a
>           gedanken
>           >experiment to speed up the comparison process without
> requiring sorting.)
>           >
>           >Two things should be noted.  First, this attack is
> independent of the KEK
>           >encryption algorithm used, assuming a fixed block size.  In
> other words,
>           >this would apply to single-DES, triple-DES, umpty-DES,
> 2048-bit RSA,
>           >or whatever, assuming a constant session key and constant
> padding.
>           >
>           >Second, the attack is also independent of the length or
> type of session
>           >key that is used, except that the yield is a Birthday
> Problem function of
>           the
>           >length of the key.  But given a fixed input, i.e., no
> random whitening or
>           >changing IV, then two or more matching outputs must imply a
> matching
>           >session key.
>           >
>           >This leads to a rather surprising result -- even if the KEK
> performs
>           double
>           >encryption using triple-DES (or any other algorithm without
> whitening)
>           >to wrap a 40 bit key, two matching session keys can be
> found with
>           >approximately 50% probability after only 2^20 or a million
> or so session
>           >keys have been generated.
>           >
>           >Perhaps more surprisingly, at least to people who haven't
> been down this
>           path,
>           >changing session keys more rapidly may hurt more than it
> helps -- it just
>           >exposes that many more keys to attack. Changing the session
> key often
>           >in the middle of a session may help limit the ability of
> the attacker to
>           >access the entire message, and hence limits the attacker's
> "take," but it
>           >increases the chances that a potentially interesting
> fragment of text
>           >may be exposed.
>           >
>           >I'm sure that someone would observe that sending even a
> million content
>           >encryption key encrypted in a constant KEK would be
> extremely unlikely
>           >in an S/MIME context, but whether that would really be true
> would require
>           >a more subtle, protocol-dependent analysis than I would
> care to make,
>           >and in addition I very much want to standardize on one key
> wrapping
>           >algorithm that is protocol independent, and not just for
> S/MIME.
>           >
>           >Obviously the above attack can be defeated by prepending
> some
>           >additional randomness or by changing the IV. But is also
> what the OAEP
>           >approach does, and rather more elegantly.  By the time we
> have to add
>           >either a changing IV or some additional randomness (how
> much would be
>           >required would have to be decided) the length would
> probably be close
>           >to that required for OAEP, which is a much more general
> solution.
>           >
>           >In my mind, at least, some extra bytes in the wrapped key
> is no big deal,
>           >but I would like the efficiency to be a good as possible.
> Triple-DES is
>           >expensive enough in terms of computational efficiency in
> software,
>           >especially in terms of the initial key expansion, and doing
> it twice
>           >would be worse yet.
>           >
>           >Because the new export regulations permit the use of double
> the key length
>           >used for data encryption to be used for key encryption, we
> are going to be
>           >using triple-DES in encrypt-decrypt-encrypt mode with only
> two keys
>           (A-B-A) for
>           >key wrapping of all export-grade CEK keys.
>           >
>           >This can be optimized by saving the key expansion of the
> first encryption,
>           and
>           >then reusing it for the final encryption.  This technique
> could
>           potentially be
>           >extended to the double encryption wrapping algorithm, by
> saving the key
>           >expansion used for all three steps, but in order to do that
> the
>           >"double-triple-DES"
>           >algorithm would probably have to be a single algorithm that
> is invoked --
>           >it would be quite difficult to securely save state across
> two separate
>           >encryption
>           >operations.
>           >
>           >So my preference, as I said earlier, would be to wrap the
> CEK in ASN.1,
>           >whiten with OAEP, and then encrypt using whatever KEK
> algorithm and
>           >key length is required, so we don't have to keep
> re-analyzing this problem
>           >for every new CEK or KEK algorithm or key length.
>           >
>           >If we can define appropriate algorithm IDs, I'm willing and
> eager to adopt
>           such
>           >a standard for  _all_ wrapped keys generated and used
> within our Novell
>           >International Cryptographic Infrastructure (NICI), even
> before S/MIME v3
>           >progresses to a full standard.  I'd be willing to assign an
> algorithm OID
>           >from the
>           >Novell tree, or we could probably get one from PKCS if
> there would be any
>           >problem getting one assigned by the IANA.
>           >
>           >Regards,
>           >
>           >Bob
>           >
>           >
>           >> Russ Housley <[e-mail]> 02/20/99 02:17PM >>>
>           >All:
>           >
>           >Right now, I am leaning toward the double encryption wrap
> algorithm.  I
>           >think it will be easy to implement, and it yeilds a shorter
> result that
>           the
>           >OAEP method.  To convince myself that it was easy to
> implement, I did an
>           >implementation.  It took me about two hours while watching
> an old Jimmy
>           >Stewart movie.  Of course, I already have SHA-1 and
> Triple-DES CBC
>           >routines.  S/MIME v3 will require these algorithms for
> other capabilities
>           >besides key wrapping.
>           >
>           >If someone else is willing to do an implementation, I would
> like to
>           compare
>           >results.  This will allow a test vector to be included with
> the algorithm
>           >description.
>           >
>           >Does anyone have any strong objections to the double
> encryption wrap
>           >algorithm being selected?
>           >
>           >Russ
>           >
>           >
>           >>WRAP ALOGRITHM #1:  DOUBLE ENCRYPTION
>           >>
>           >>Key Checksum
>           >>
>           >>The CMS Checksum Algorithm is used to provide an
> content-encryption key
>           >>integrity check value.  The algorithm is:
>           >>
>           >>1.  Compute a 20 octet SHA-1 message digest on the
>           >>    content-encryption key.
>           >>2.  Use the most significant (first) eight octets of the
>           >>    message digest value as the checksum value.
>           >>
>           >>Triple-DES Key Wrap
>           >>
>           >>1.  Set odd parity for each of the DES key octets
> comprising
>           >>    the content-encryption key, call the result CEK.
>           >>2.  Compute a 8 octet key checksum value on CEK as
> described above,
>           >>    call the result ICV.
>           >>3.  Let CEKICV = CEK || ICV.
>           >>4.  Encrypt CEKICV in CBC mode using the key-encryption
> key.  Use
>           >>    an IV of 0xc302e3c1ad8bb738.
>           >>5.  Reverse the order of the ciphertext octets.  That is,
> the most
>           >>    significant (first) octet is swapped with the least
> significant
>           >>    (last) octet, and so on.  Call the result TEMP.
>           >>6.  Encrypt TEMP in CBC mode using the key-encryption key.
> Use
>           >>    an IV of 0x61a197e5b132e196.  The ciphertext is 32
> octets long.
>           >
>           >Robert R. Jueneman
>           >Security Architect
>           >Network Security Development
>           >Novell, Inc.
>           >122 East 1700 South
>           >Provo, UT 84606
>           >[e-mail]
>           >1-801-861-7387
> 
> 
> 
> 
> 
> 
> 
>