Fixed: draft-ietf-smime-idea-07.txt

[Russ Housley <[e-mail]>]

Jeff and Marcus:

The draft-ietf-smime-idea-07.txt was submitted.  It should be posted today 
or tomorrow.

The error in the draft has been fixed.  So, the working group is finished 
with the document.  It is ready for the IESG and subsequent publication as 
an Informational RFC.

Russ


>From: "Teiwes, Stephan (iT_SEC)" <[e-mail]>
>To: "'Russ Housley'" <[e-mail]>
>Cc: "'[e-mail]'" <[e-mail]>,
>         "'[e-mail]'"
>         <[e-mail]>
>Subject: RE: URGENT: draft-ietf-smime-idea-06
>Date: Wed, 30 Aug 2000 16:56:33 +0200
>X-Mailer: Internet Mail Service (5.5.2448.0)
>
>Russ, Blake and Jim,
>
>I'd like to apologize for not having immediately considered your important
>comment on our draft. However, I didn't receive the your e-mails from IMC.
>The reason is not clear to me as I am on the mailing list. However, a
>collegue of mine also reported to me that he didn't receive e-mails from the
>SMIME WG for some weeks. Thus, I've to check what's going wrong.
>
>Your comment is correct! We've changed the encoding sequences and send a
>modified draft to the ietf.
>
>Thanks a lot for your help and your understanding.
>
>*Stephan
>
>
>
>-----Original Message-----
>From: Russ Housley [mailto:[e-mail]]
>Sent: Montag, 28. August 2000 19:05
>To: [e-mail]; [e-mail];
>[e-mail]
>Subject: URGENT: draft-ietf-smime-idea-06
>
>
>Obviously, I missed one of the changes in my summary.  How quickly can you
>generate one that repairs this problem?
>
>Russ
>
>
>At 08:30 AM 08/25/2000 -0700, you wrote:
> >Note that this problem is still present in the -06 draft (that has
>completed
> >WG last call), and it will potentially lead to interoperability problems.
> >Fortunately, I don't care since it isn't in the base S/MIME spec and I
>never
> >plan to use it.
> >
> >Blake
> >
> >-----Original Message-----
> >From: Blake Ramsdell
> >Sent: Thursday, June 15, 2000 2:35 PM
> >To: '[e-mail]'; [e-mail]
> >Subject: RE: draft-ietf-smime-idea-03
> >
> >
> >And just to be clear, this absolutely must be fixed (either the text must
>be
> >corrected to say that the parameters are encoded as ASN.1 NULL or the
> >examples must be corrected as I have pointed out).  The MUSTS in the
>current
> >draft are contradictory.
> >
> >Blake
> >
> >-----Original Message-----
> >From: Jim Schaad [mailto:[e-mail]]
> >Sent: Monday, June 12, 2000 1:22 AM
> >To: [e-mail]
> >Subject: RE: draft-ietf-smime-idea-03
> >
> >
> >This has not been taken care of in the -04 draft.
> >
> >jim
> >
> >-----Original Message-----
> >From: [e-mail]
> >[mailto:[e-mail]]On Behalf Of Blake Ramsdell
> >Sent: Friday, April 14, 2000 4:04 PM
> >To: '[e-mail]'; [e-mail]
> >Subject: RE: draft-ietf-smime-idea-03
> >
> >
> >Agree.  I think this should be 300D at the beginning, and trim the last two
> >bytes off of both examples.
> >
> >Blake
> >
> >-----Original Message-----
> >From: Jim Schaad [mailto:[e-mail]]
> >Sent: Friday, April 14, 2000 12:35 AM
> >To: [e-mail]
> >Subject: draft-ietf-smime-idea-03
> >
> >
> >The S/MIME Capability sequences appear to be wrong.  In section 4 paragraph
> >2,
> >the text states that the parameters field must be absent, however the
> >encoding
> >sequence given has the parameters encoded as NULL.  The same is true in
> >paragraph
> >3 of the same section.
> >
> >jim
> >http://www.nwlink.com




Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id NAA17402 for ietf-smime-bks; Thu, 31 Aug 2000 13:51:16 -0700 (PDT)
Received: from mail.spyrus.com (mail.spyrus.com [207.212.34.20]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id NAA17397 for <[e-mail]>; Thu, 31 Aug 2000 13:51:15 -0700 (PDT)
Received: from rhousley_laptop.spyrus.com ([209.172.119.205]) by mail.spyrus.com (8.9.3/8.9.3) with ESMTP id NAA13629; Thu, 31 Aug 2000 13:51:02 -0700 (PDT)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
Date: Thu, 31 Aug 2000 16:49:47 -0400
To: [e-mail], [e-mail]
From: Russ Housley <[e-mail]>
Subject: Fixed: draft-ietf-smime-idea-07.txt
Cc: [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-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Jeff and Marcus:

The draft-ietf-smime-idea-07.txt was submitted.  It should be posted today 
or tomorrow.

The error in the draft has been fixed.  So, the working group is finished 
with the document.  It is ready for the IESG and subsequent publication as 
an Informational RFC.

Russ


>From: "Teiwes, Stephan (iT_SEC)" <[e-mail]>
>To: "'Russ Housley'" <[e-mail]>
>Cc: "'[e-mail]'" <[e-mail]>,
>         "'[e-mail]'"
>         <[e-mail]>
>Subject: RE: URGENT: draft-ietf-smime-idea-06
>Date: Wed, 30 Aug 2000 16:56:33 +0200
>X-Mailer: Internet Mail Service (5.5.2448.0)
>
>Russ, Blake and Jim,
>
>I'd like to apologize for not having immediately considered your important
>comment on our draft. However, I didn't receive the your e-mails from IMC.
>The reason is not clear to me as I am on the mailing list. However, a
>collegue of mine also reported to me that he didn't receive e-mails from the
>SMIME WG for some weeks. Thus, I've to check what's going wrong.
>
>Your comment is correct! We've changed the encoding sequences and send a
>modified draft to the ietf.
>
>Thanks a lot for your help and your understanding.
>
>*Stephan
>
>
>
>-----Original Message-----
>From: Russ Housley [mailto:[e-mail]]
>Sent: Montag, 28. August 2000 19:05
>To: [e-mail]; [e-mail];
>[e-mail]
>Subject: URGENT: draft-ietf-smime-idea-06
>
>
>Obviously, I missed one of the changes in my summary.  How quickly can you
>generate one that repairs this problem?
>
>Russ
>
>
>At 08:30 AM 08/25/2000 -0700, you wrote:
> >Note that this problem is still present in the -06 draft (that has
>completed
> >WG last call), and it will potentially lead to interoperability problems.
> >Fortunately, I don't care since it isn't in the base S/MIME spec and I
>never
> >plan to use it.
> >
> >Blake
> >
> >-----Original Message-----
> >From: Blake Ramsdell
> >Sent: Thursday, June 15, 2000 2:35 PM
> >To: '[e-mail]'; [e-mail]
> >Subject: RE: draft-ietf-smime-idea-03
> >
> >
> >And just to be clear, this absolutely must be fixed (either the text must
>be
> >corrected to say that the parameters are encoded as ASN.1 NULL or the
> >examples must be corrected as I have pointed out).  The MUSTS in the
>current
> >draft are contradictory.
> >
> >Blake
> >
> >-----Original Message-----
> >From: Jim Schaad [mailto:[e-mail]]
> >Sent: Monday, June 12, 2000 1:22 AM
> >To: [e-mail]
> >Subject: RE: draft-ietf-smime-idea-03
> >
> >
> >This has not been taken care of in the -04 draft.
> >
> >jim
> >
> >-----Original Message-----
> >From: [e-mail]
> >[mailto:[e-mail]]On Behalf Of Blake Ramsdell
> >Sent: Friday, April 14, 2000 4:04 PM
> >To: '[e-mail]'; [e-mail]
> >Subject: RE: draft-ietf-smime-idea-03
> >
> >
> >Agree.  I think this should be 300D at the beginning, and trim the last two
> >bytes off of both examples.
> >
> >Blake
> >
> >-----Original Message-----
> >From: Jim Schaad [mailto:[e-mail]]
> >Sent: Friday, April 14, 2000 12:35 AM
> >To: [e-mail]
> >Subject: draft-ietf-smime-idea-03
> >
> >
> >The S/MIME Capability sequences appear to be wrong.  In section 4 paragraph
> >2,
> >the text states that the parameters field must be absent, however the
> >encoding
> >sequence given has the parameters encoded as NULL.  The same is true in
> >paragraph
> >3 of the same section.
> >
> >jim
> >http://www.nwlink.com



Received: by ns.secondary.com (8.9.3/8.9.3) id KAA16191 for ietf-smime-bks; Wed, 30 Aug 2000 10:42:26 -0700 (PDT)
Received: from mail.ec.auckland.ac.nz (mail.student.auckland.ac.nz [130.216.35.201]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id KAA16185; Wed, 30 Aug 2000 10:42:24 -0700 (PDT)
Received: from kahu.cs.auckland.ac.nz ([e-mail] [130.216.36.13]) by mail.ec.auckland.ac.nz (8.9.3/8.8.6/cs-master) with SMTP id FAA30825; Thu, 31 Aug 2000 05:43:24 +1200 (NZST) (sender [e-mail])
Received: by kahu.cs.auckland.ac.nz (relaymail v0.9) id <96765740416582>; Thu, 31 Aug 2000 05:43:24 (NZST)
From: [e-mail] (Peter Gutmann)
To: [e-mail]
Subject: Re:  WG LAST CALL: draft-ietf-smime-compression-01.txt
Cc: [e-mail]
Reply-To: [e-mail]
X-Charge-To: pgut001
X-Authenticated: relaymail v0.9 on kahu.cs.auckland.ac.nz
Date: Thu, 31 Aug 2000 05:43:24 (NZST)
Message-ID: <[e-mail]>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Paul Hoffman / IMC <[e-mail]> writes:

>I'm not sure I agree with that. If there is even one implementation of it
>(probably from you, Peter?), then it's appropriate to be Experimental. If
>there are two, then it might even go on standards track later.

At the moment there's only one because of long delays in getting it out as an
RFC, however judging by the number of people who have asked me about it
there'll be more than one fairly soon after it's finally published.

Peter.



Received: by ns.secondary.com (8.9.3/8.9.3) id JAA14098 for ietf-smime-bks; Wed, 30 Aug 2000 09:57:07 -0700 (PDT)
Received: from [165.227.249.17] (ip17.proper.com [165.227.249.17]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA14085; Wed, 30 Aug 2000 09:57:02 -0700 (PDT)
Mime-Version: 1.0
X-Sender: [e-mail]
Message-Id: <p05001118b5d2ed6c2f29@[165.227.249.17]>
In-Reply-To: <[e-mail]>
References: <[e-mail]>
Date: Wed, 30 Aug 2000 09:58:03 -0700
To: [e-mail], [e-mail]
From: Paul Hoffman / IMC <[e-mail]>
Subject: Re:  WG LAST CALL: draft-ietf-smime-compression-01.txt
Cc: [e-mail]
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-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

At 1:40 AM -0700 8/31/00, Peter Gutmann wrote:
>  >The compression content type definition, 
>draft-ietf-smime-compression-01.txt,
>>is ready for S/MIME WG Last Call.  This document is slated to become an
>>Experimental RFC.  Last Call will end on 15 September 2000.
>
>s/Experimental/Informational/

I'm not sure I agree with that. If there is even one implementation 
of it (probably from you, Peter?), then it's appropriate to be 
Experimental. If there are two, then it might even go on standards 
track later.

--Paul Hoffman, Director
--Internet Mail Consortium


Received: by ns.secondary.com (8.9.3/8.9.3) id GAA25349 for ietf-smime-bks; Wed, 30 Aug 2000 06:40:19 -0700 (PDT)
Received: from mail.ec.auckland.ac.nz (mail.student.auckland.ac.nz [130.216.35.201]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id GAA25343 for <[e-mail]>; Wed, 30 Aug 2000 06:40:17 -0700 (PDT)
Received: from kahu.cs.auckland.ac.nz ([e-mail] [130.216.36.13]) by mail.ec.auckland.ac.nz (8.9.3/8.8.6/cs-master) with SMTP id BAA05805; Thu, 31 Aug 2000 01:40:57 +1200 (NZST) (sender [e-mail])
Received: by kahu.cs.auckland.ac.nz (relaymail v0.9) id <96764285725320>; Thu, 31 Aug 2000 01:40:57 (NZST)
From: [e-mail] (Peter Gutmann)
To: [e-mail]
Subject: Re:  WG LAST CALL: draft-ietf-smime-compression-01.txt
Cc: [e-mail]
Reply-To: [e-mail]
X-Charge-To: pgut001
X-Authenticated: relaymail v0.9 on kahu.cs.auckland.ac.nz
Date: Thu, 31 Aug 2000 01:40:57 (NZST)
Message-ID: <[e-mail]>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

>The compression content type definition, draft-ietf-smime-compression-01.txt,
>is ready for S/MIME WG Last Call.  This document is slated to become an
>Experimental RFC.  Last Call will end on 15 September 2000.

s/Experimental/Informational/

Peter.



Received: by ns.secondary.com (8.9.3/8.9.3) id GAA24267 for ietf-smime-bks; Wed, 30 Aug 2000 06:09:54 -0700 (PDT)
Received: from mail.spyrus.com (mail.spyrus.com [207.212.34.20]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id GAA24262 for <[e-mail]>; Wed, 30 Aug 2000 06:09:53 -0700 (PDT)
Received: from rhousley_laptop.spyrus.com ([209.172.119.205]) by mail.spyrus.com (8.9.3/8.9.3) with ESMTP id GAA22835; Wed, 30 Aug 2000 06:10:21 -0700 (PDT)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
Date: Wed, 30 Aug 2000 09:08:44 -0400
To: [e-mail]
From: Russ Housley <[e-mail]>
Subject: WG LAST CALL: draft-ietf-smime-compression-01.txt
Cc: [e-mail], [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-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

The compression content type definition, 
draft-ietf-smime-compression-01.txt, is ready for S/MIME WG Last 
Call.  This document is slated to become an Experimental RFC.  Last Call 
will end on 15 September 2000.

	Title		: Compressed Data Content Type for S/MIME
	Author(s)	: P. Gutmann
	Filename	: draft-ietf-smime-compression-01.txt
	Pages		: 3
	Date		: 29-Aug-00

Happy reading,
    Russ



Received: by ns.secondary.com (8.9.3/8.9.3) id DAA16041 for ietf-smime-bks; Wed, 30 Aug 2000 03:49:24 -0700 (PDT)
Received: from ietf.org (odin.ietf.org [132.151.1.176]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id DAA16036 for <[e-mail]>; Wed, 30 Aug 2000 03:49:23 -0700 (PDT)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA23562; Wed, 30 Aug 2000 06:50:23 -0400 (EDT)
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-compression-01.txt
Date: Wed, 30 Aug 2000 06:50:23 -0400
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
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		: Compressed Data Content Type for S/MIME
	Author(s)	: P. Gutmann
	Filename	: draft-ietf-smime-compression-01.txt
	Pages		: 3
	Date		: 29-Aug-00
	
The Cryptographic Message Syntax data format doesn't currently contain
any provisions for compressing data before processing it.  Compressing
data before transmission provides a number of advantages including the
elimination of data redundancy which could help an attacker, speeding
up processing by reducing the amount of data to be processed by later
steps such as signing or encryption, and reducing overall message size.
Although there have been proposals for adding compression at other
levels (for example at the MIME or SSL level) these don't address the
problem of compression of CMS content unless the compression is
supplied by an external means (for example by intermixing MIME and
CMS).  This document defines a format for using compressed data as a
CMS content type.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-smime-compression-01.txt

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-smime-compression-01.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt


Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[e-mail].
In the body type:
	"FILE /internet-drafts/draft-ietf-smime-compression-01.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.
		
		
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--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-compression-01.txt

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

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

--OtherAccess--

--NextPart--




Received: by ns.secondary.com (8.9.3/8.9.3) id BAA02320 for ietf-smime-bks; Wed, 30 Aug 2000 01:05:44 -0700 (PDT)
Received: from sendflowersamerica.com ([206.168.43.194]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id BAA01619; Wed, 30 Aug 2000 01:00:02 -0700 (PDT)
From: [e-mail]
Subject: FlowerFunds - Fund Raising Program
Date: Wed, 30 Aug 2000 01:32:31
Message-Id: <[e-mail]>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

SendFlowersAmerica is proud to introduce FlowerFunds--

This unique new concept will provide an income flow for your 
organization for years to come.  Your organization is invited to 
explore the possibilities of participating in FlowerFunds. 
       

     $FlowerFunds is an individualized fund raising program for 
non-profit organizations and schools.

     $FlowerFunds are cash rebates that are paid to your 
organization each and every time an order is placed by your 
members and supporters.

     $The best part is that it costs your organization nothing to 
participate!!



How it works:

     1.   When your members and supporters order flowers or gifts 
through sendflowersamerica they determine the price they want to 
pay; be it $30, $40, $50 or $1000.  Since your members and 
supporters determine the price, they all can participate in this 
program.

     2.   Your organization receives 20% of the purchase price of 
the order.  Say a husband buys his wife a $50 bouquet.  Your 
organization will receive a $10 cash rebate. Nice.



This program never ends.  Each and every time there is an order 
placed by your memebers and supporters, your organization will 
receive the 20% cash rebate.  That's a lot of FlowerFunds, and 
your organization stands to benefit from a findraiser unlike any 
other fundraiser.


For more information call 1 800 SEND 123 or

http://www.sendflowersamerica.com


Imagine earning money for your organization by making someone 
smile  :-)
 
 
 
 
 
 
 
 
 
 
 
 
 


Received: by ns.secondary.com (8.9.3/8.9.3) id IAA27116 for ietf-smime-bks; Sat, 26 Aug 2000 08:57:36 -0700 (PDT)
Received: from smtp5s.retemail.es (smtp5s.iddeo.es [62.81.31.74] (may be forged)) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA27112 for <[e-mail]>; Sat, 26 Aug 2000 08:57:34 -0700 (PDT)
From: [e-mail]
Received: from [152.23.36.38] ([62.81.12.15]) by smtp5s.retemail.es (InterMail v4.01.01.00 201-229-111) with SMTP id <20000826155941.DUDH5778.smtp5s@[62.81.12.15]>; Sat, 26 Aug 2000 17:59:41 +0200
Message-ID: <000056ae172f$00002e79$000072ad@152.23.36.39>
To: <Undisclosed.Recipients>
Subject: Cyber-Biz Secrets
Date: Sat, 26 Aug 2000 10:48:06 -0400
X-Priority: 3
X-MSMail-Priority: Normal
Reply-To: [e-mail]
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

The Truth Is Finally Revealed....

  How Does The Richest Man In The World Use The Greatest Business
  Secrets Of All Time To Make Over 32.4 Million Dollars A Day?!!

  No matter who you are, where you live or what your sex, age or
  race is by the time you finish reading this special article, you
  will know:

  * How to start a proven money making business that requires no
    inventory, no shipping and no employees within 7 days, guaranteed!

  * How to get a $300 professionally designed Web Site for FREE!

  * How to increase your sales by more than 137% in 30 days regardless
    of your business!

  * How to get paid for a 1000-hour workweek, without going to work!

  * How to turn 50 cents into $50, with a simple click of a button!

  * How to get a $179 business-building CD-ROM for FREE!

  * If you ever wanted a business where you could hit the ground
    running.... a business where you could just open a box and
    start making immediate profits.... a business that's completely
    set up and ready to pull in maximum sales.... with a product that
    sells itself... then I've got some great news for you!

                              Act NOW 
      <<<<<< There is A DEADLINE!!! >>>>>>


  Instant Information Request Directions:

  **>NOTE: You may also just Click Below to send it through your normal
           e-mail program. mailto:[e-mail]?subject=send_info_on_infomax825

  It's much easier to do it this way, it will fill in the return e-mail
  and subject for you.

  2. You will receive the complete info on the reports via e-mail within 24 hours.

  P.S. Act NOW!-- Only the first 75 requests will be granted to receive
       this Special Web Site e-Report for *FREE* titled
       "The Greatest Business Secrets Of All Time"

  P.P.S. *FREE Download Bonus e-Manual*
         "Microsoft, Viagra & Your Business Success" given to the first
         35 people to respond within the next 24 hours, Your FREE reports
         will be fulfilled in the order in which they were received.

  Privacy Policy: We respect your privacy and your e-mail address/name will
  be kept strictly private it will never be sold, shared or given away for
  any reason.

  Simple Removal Instructions:

To Be Removed: mailto:[e-mail]?subject=remove825
  You will then be deleted from our e-mail database forever.
 
  NO FLAMES!! You will not be added to the remove database unless you do this.
  No Exceptions, anything but "remove" in the subject will generate an automatic
  response.   Thank You!!

  







Received: by ns.secondary.com (8.9.3/8.9.3) id IAA15204 for ietf-smime-bks; Fri, 25 Aug 2000 08:30:38 -0700 (PDT)
Received: from cane.deming.com (mail.deming.com [208.236.41.137]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id IAA15190 for <[e-mail]>; Fri, 25 Aug 2000 08:30:35 -0700 (PDT)
Received: from 208.236.41.137 by cane.deming.com with ESMTP (Tumbleweed MMS SMTP Relay (MMS v4.6)); Fri, 25 Aug 2000 08:30:40 -0700
X-Server-Uuid: 1a012586-24e9-11d1-adae-00a024bc53c5
Received: by mail.deming.com with Internet Mail Service (5.5.2650.21) id <Q2XX391Z>; Fri, 25 Aug 2000 08:30:40 -0700
Message-ID: <[e-mail]>
From: "Blake Ramsdell" <[e-mail]>
To: "'[e-mail]'" <[e-mail]>
Subject: FW: draft-ietf-smime-idea-03
Date: Fri, 25 Aug 2000 08:30:39 -0700
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
X-WSS-ID: 15B84EAA42929-01-01
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-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Note that this problem is still present in the -06 draft (that has completed
WG last call), and it will potentially lead to interoperability problems.
Fortunately, I don't care since it isn't in the base S/MIME spec and I never
plan to use it.

Blake

-----Original Message-----
From: Blake Ramsdell 
Sent: Thursday, June 15, 2000 2:35 PM
To: '[e-mail]'; [e-mail]
Subject: RE: draft-ietf-smime-idea-03


And just to be clear, this absolutely must be fixed (either the text must be
corrected to say that the parameters are encoded as ASN.1 NULL or the
examples must be corrected as I have pointed out).  The MUSTS in the current
draft are contradictory.

Blake

-----Original Message-----
From: Jim Schaad [mailto:[e-mail]]
Sent: Monday, June 12, 2000 1:22 AM
To: [e-mail]
Subject: RE: draft-ietf-smime-idea-03


This has not been taken care of in the -04 draft.

jim

-----Original Message-----
From: [e-mail]
[mailto:[e-mail]]On Behalf Of Blake Ramsdell
Sent: Friday, April 14, 2000 4:04 PM
To: '[e-mail]'; [e-mail]
Subject: RE: draft-ietf-smime-idea-03


Agree.  I think this should be 300D at the beginning, and trim the last two
bytes off of both examples.

Blake

-----Original Message-----
From: Jim Schaad [mailto:[e-mail]]
Sent: Friday, April 14, 2000 12:35 AM
To: [e-mail]
Subject: draft-ietf-smime-idea-03


The S/MIME Capability sequences appear to be wrong.  In section 4 paragraph
2,
the text states that the parameters field must be absent, however the
encoding
sequence given has the parameters encoded as NULL.  The same is true in
paragraph
3 of the same section.

jim
http://www.nwlink.com






Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id OAA05816 for ietf-smime-bks; Thu, 24 Aug 2000 14:20:28 -0700 (PDT)
Received: from wfhqex05.gfgsi.com (netva01.wangfed.com [206.137.100.2]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id OAA05812 for <[e-mail]>; Thu, 24 Aug 2000 14:20:27 -0700 (PDT)
Received: by wfhqex05.gfgsi.com with Internet Mail Service (5.5.2650.21) id <RLYR5QQT>; Thu, 24 Aug 2000 17:20:44 -0400
Message-ID: <[e-mail]>
From: "Pawling, John" <[e-mail]>
To: "SMIME WG (E-mail)" <[e-mail]>
Subject: 31 July 2000 S/MIME WG Minutes
Date: Thu, 24 Aug 2000 17:20:20 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

This message includes the minutes of the IETF S/MIME Working Group
meeting held on 31 July 2000 in Pittsburgh, Pennsylvania, U.S.A. 
Briefing slides are stored at: ftp://ftp.ietf.org/ietf/smime/.  
These minutes include comments from the briefing presenters.  
Reported by John Pawling.

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

Introductions - Russ Housley
 
Russ reviewed the agenda as follows.  Nobody commented on the agenda.

Introductions				Russ Housley
Working Group Status			Russ Housley
Interoperability Matrix 		Jim Schaad
CERTDIST Draft Discussion 		Jim Schaad
Symmetric Key Distribution		Sean Turner
Security Policies and Labels		Weston Nicolls
Message Compression		      Ned Freed
DOMSEC Draft Discussion 		Bill Ottaway
CMS/ESS Examples				Paul Hoffman
Crypto Algorithm Documents		Russ Housley
RSA as a MUST Implement	            Blake Ramsdell
Electronic Signature Formats		John Ross
Signature Policy Format	            Denis Pinkas
Wrap up					Russ Housley
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

S/MIME Working Group Status - Russ Housley

Russ outlined the strategy for advancing the following RFCs from
Internet Proposed Standards to Internet Draft Standards:
RFC 2630 Cryptographic Message Syntax, R. Housley, June 1999
RFC 2631 Diffie-Hellman Key Agreement Method, E. Rescorla, June 1999
RFC 2632 S/MIME Version 3 Certificate Handling, B. Ramsdell, June 1999
RFC 2633 S/MIME Version 3 Message Specification, B. Ramsdell, June 1999
RFC 2634 Enhanced Security Services for S/MIME, P. Hoffman, June 1999
RFC 2785 Methods for Avoiding the "Small-Subgroup" Attacks on the
          Diffie-Hellman Key Agreement Method for S/MIME, 
          R. Zuccherato, March 2000. [Informational]
RFC 2876 Use of the KEA and SKIPJACK Algorithms in CMS, J. Pawling,
          July 2000. [Informational]            


The aforementioned documents must meet the following requirements to
advance to Draft Standards:
1) Meet requirements documented in RFC 2026
2) Stable, mature, and useful specification
3) At least two independent and interoperable implementations
   from different code bases
4) Draft Standards cannot reference Proposed Standard RFCs or 
   Experimental RFCs, so the aforementioned RFCs are blocked
   until the PKIX Certificate and CRL Profile "Son-of-RFC 2459"
   Internet-Draft (I-D) (draft-ietf-pkix-new-part1-02.txt) 
   progresses to Draft Standard (last call was estimated to begin by
   7 August 2000). 

Russ stated that Jim Schaad has developed an interoperability matrix
for RFCs 2630 through 2634. The interoperability matrix is posted at
<http://www.imc.org/ietf-smime/interop-matrix.html>.  The matrix 
indicates which features have and have not been implemented.  So far,
Microsoft and Wang Government Services (WGS), A Getronics Company,
have provided input to the interoperability matrix.  WGS has provided
input regarding the capabilities of the S/MIME Freeware Library (SFL)
including interoperability testing conducted with Microsoft.  

Russ noted that Paul Hoffman (IMC) has offered to coordinate 
interoperability testing and to enhance the "Examples of S/MIME 
Messages" I-D.  He also noted that no other organizations have 
participated in the interoperability testing.  He asked that other
organizations that have developed S/MIME v3 capabilities should 
please participate.

There are some S/MIME v3 features for which interoperability testing 
has not been performed between at least two independent 
implementations.  For example, Russ pointed out that the 
EncryptedData, AuthenticatedData and DigestedData content types 
have not been tested between two parties.

Russ proposed that RFC 2630 should be changed to state that:
 - EnvelopedData and SignedData MUST be implemented; and
 - EncryptedData, DigestedData, and AuthenticatedData MAY be 
     implemented.

Russ said that he would submit that proposal to the IETF S/MIME
working group (WG) mail list.

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

Interoperability Matrix - Jim Schaad

Jim discussed the interoperability matrix for RFCs 2630 through 2634.
He has documented the successful completion of two-way interoperability
testing for the following number of clauses in each RFC.  He noted that 
he has not completely updated the results based on all interoperability
testing performed:

   RFC      Clauses Tested
   2630        45 of 96
   2631         0 of 13
   2632        16 of 21
   2633        17 of 61
   2634         0 of 81

Jim asked for others to submit input to him at [e-mail].

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

CERTDIST Draft Discussion - Jim Schaad

Jim discussed the Certificate Distribution Specification I-D 
<draft-ietf-smime-certdist-05.txt>, May 2000.  Based on discussions 
on the S/MIME WG mail list, Jim stated that there are three camps 
of thought regarding publishing certificates with secondary support
information such as the SMIMECapabilities attribute:
1) Use attribute certificates (AC)
2) Put user's certificates in the signed object (see certdist-05)
3) Omit user's certificates from the signed object


Jim stated that the advantage of the AC strategy is that it matches 
the X.500 schema.  The disadvantage is that ACs are "new" and are
not necessarily a good use of ACs.

Jim stated that the advantage of the strategy to include user 
certificates in the signed object is that there is a single location
from which to retrieve all of the required information.  The 
disadvantages of this strategy are that duplicate information is 
stored in the directory and there are potential consistency problems.

Jim stated that the advantages of the strategy to omit user 
certificates in the signed object are less data stored in the
directory and a single set of user certificates are used for all 
purposes.  The disadvantages of this strategy are that there are 
potential consistency problems and multiple elements to be retrieved
from the directory.

Jim conducted a straw poll of the meeting attendees to obtain their
opinion regarding the following options: 
1) Continue to try and get consensus
2) Adopt on standards track w/o consensus
3) Adopt on experimental track w/o consensus
The majority of the meeting attendees who voted chose option 1.

Blake Ramsdell asked if these issues should be discussed on the IETF 
PKIX WG mail list in addition to the S/MIME WG mail list.  Russ 
stated his belief that the interested parties are subscribed to the
S/MIME mail list so it is not necessary to discuss the issues on the
PKIX mail list.

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

Symmetric Key Distribution - Jim Schaad for Sean Turner

Jim discussed the S/MIME Symmetric Key Distribution I-D, 
<draft-ietf-smime-symkeydist-01.txt>, July 2000.  Jim provided 
significant comments to the symkeydist-00 I-D that Sean incorporated
into the symkeydist-01 I-D.

Jim stated that major architecture changes were made to the symmetric
key distribution strategy.  The Key Management Agent (KMA) and Group 
Management Agent (GMA) were combined into one component called the 
Group Lists Agent (GLA).  This change removes duplicative KMA checks.
The change was made based on the assumption that the KMA and GMA 
will likely be implemented in the same box.  

Jim briefed that major protocol changes were made to the symmetric
key distribution strategy.  Instead of defining a new content type,
symkeydist-01 specifies that the exchange of data will use a protocol
based on RFC 2797, Certificate Management Messages over CMS (CMC).

There were many other changes made to the document as a result of 
changing the architecture and protocols.

Jim briefed the following implementation requirements for the 
control attributes:

Implementation	
 Requirement    Control Attribute
==================================
	MAY		glUseKEK
	MAY		glDelete
	MAY		glAddMembers
	MAY		glDeleteMembers
	MAY		glRekey 
	MAY		glAddOwners
	MAY		glRemoveOwners
	MAY		glkCompromise
	SHOULD	glkRefresh
	MAY		glSuccessInfo
	MAY		glFailInfo
	MAY		glAQueryRequest
	MAY		glAQueryResponse
	MUST		glKey

Jim noted that the protocol exchanges between the user and GLA will
be changed to "MUST implement" requirements.  He also noted that 
the protocol exchanges between the KMA and GLA will remain as
"MUST implement" requirements.  

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

Mapping Company Classification Policy to the S/MIME Security Label - 
Weston Nicolls

The "Implementing Company Classification Policy with the S/MIME 
Security Label" I-D, <draft-ietf-smime-seclabel-01.txt>, July 2000,
was authored by Weston Nicolls.  Weston planned to provide a briefing
at the meeting, but could not be present due to airline delays. 
There was no information presented regarding this topic.

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

Message Compression - Ned Freed

Ned Freed is proposing a MIME encoding to handle compression.  His
proposal is to compress the message using this MIME encoding before 
it is signed or encrypted.  Ned Freed could not be present at this
meeting, so there was no information presented regarding this topic.

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

DOMSEC Draft Discussion - Bill Ottaway

Bill presented a briefing regarding the "Domain Security Services Using
S/MIME" I-D <draft-ietf-smime-domsec-06.txt>, July 2000.  Bill stated 
that there have been two releases of the DOMSEC I-D since the last 
S/MIME WG meeting.  DOMSEC-05 included clarifications based on input
from Luis Barriga and included the object identifier for the 
signatureType attribute.  DOMSEC-06 included corrections and 
clarifications based on input from Jim Schaad, and included an ASN.1
module added.  

Bill then discussed some issues with some technical proposals from
Jim Schaad.  In an e-mail message, Jim Schaad stated: "Section 3.0
bullet 1: This concept bothers me. I think that there may be some 
programs out there that assume at least one signature in a signed 
data object except for cases such as degenerate certs only messages."
Blake Ramsdell reiterated that some applications interpret
a signedData with no signerInfos as being a certs-only message.
Bill's position is that CMS (section 5.1) states that there may be
zero signerInfos, so compliant implementations should be able to 
process a signedData with zero signerInfos.  He asked if any of the
other meeting attendees believed that DOMSEC should be changed to
omit the use of signedData objects without any signerInfos.  None
of the meeting attendees responded.

In an e-mail message, Jim Schaad also stated: "Section 4 Paragraph
Last-2 - How can I possibly enforce this?  For Key Transport the 
sender is anonymous, for Key Agreement the senders certificate is
often not examined.  Additionally the domain component could change
so that does match -- or it might be my domain component that did 
the re-enecryption and would therefore match my domain name and not
the senders domain name."  Bill's position is: "The only extra 
specification to those specified in CMS is that the naming 
convention and name mapping convention defined in DOMSEC is used.
This is specified to locate public keys. For example, if a domain
needs to locate the public key for the domain of the recipient 
[e-mail] then the public key belonging to
[e-mail] needs to be 
located, or if not present the public key of an ascendant of the 
domain name needs to be located."  Bill also stated that the 
DOMSEC messages are encrypted between the originator's domain 
and the recipient's domain, not the actual recipient user.  
He stated that the text is intended to explain how an 
originator domain agent can look up a recipient's name. 
He will clarify the text.
Bill stated that the he believes that the outstanding issues
should be resolved and then the DOMSEC I-D should be submitted 
for last call.



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

RSA As a Must Implement - Blake Ramsdell

Blake Ramsdell proposed that RFC 2630 be changed to require the
RSA public key algorithm as the "MUST implement" key management
algorithm since the RSA patent will expire on 20 September 2000.
He also raised the question of changing RFC 2630 to require the
RSA public key algorithm as the "MUST implement" signature algorithm.

John Pawling asked if anybody had applied for any patents related
to the RSA public key algorithm.  Russ Housley stated that was a
possibility, since patent filings are confidential until they are
published.  He noted as an example that an organization applied
for a patent regarding the methods for avoiding the "small-
subgroup" attacks on the Diffie-Hellman (D-H) key agreement method.
He stated that nobody had made any statements to him regarding any
patents related to the RSA public key algorithm.  John Linn stated
that RSA is not applying for any patents (that he knows of) related
to the RSA public key algorithm.

Pat Cain stated that he was concerned that this significant change 
would slow down the process of advancing the S/MIME v3 RFCs from
Internet Proposed Standards to Internet Draft Standards.  Jim Schaad
replied that this change would not slow down the process of 
implementing the S/MIME v3 standards.  Russ Housley stated that the
changes probably would reset the clock for advancing the S/MIME v3 
RFCs from Internet Proposed Standards to Internet Draft Standards.  

An attendee pointed out that PKCS #1 is not fully tested.  Another
attendee stated that the group needs to consider the quality of the
cryptographic algorithms in addition to patent concerns.

Jim Schaad stated that he believes that DSA should remain a "MUST
implement" signature algorithm because the signature value requires
less bytes, and because it is widely implemented and required.

Russ Housley stated that the RFC 2630 Security Considerations 
section recommends that the PKCS #1 v2.0 Optimal Asymmetric 
Encryption Padding (RSA with OAEP) technique should be employed
instead of the PKCS#1 v1.5 RSA key management algorithm.  Therefore,
if Ephemeral-Static Diffie-Hellman is no longer going to be the 
mandatory-to-implement algorithm, then he recommends the use of
RSA with OAEP as its replacement.

Jim Schaad asked if separating the algorithms-related text from RFC
2630 would mandate a new six-month waiting period.  Russ replied that
he did not believe that change alone mandated a new six-month 
waiting period because it does not impact the RFC 2630 core 
requirements.

Phillip Hallam-Baker stated his belief that the "S/MIME v3" mark 
on a product means that it is interoperable with all S/MIME
implementations, so he supports RSA with OAEP rather than D-H.

An attendee asked if RSA with OAEP breaks backward compatibility
with S/MIME products that implement PKCS#1 v1.5 RSA.  Russ
replied that it does break backward compatibility.

Blake Ramsdell pointed out that using RSA with OAEP was a better
option than using Ephemeral-Static (E-S) D-H because the same RSA
certificates can be used with both PKCS#1 v1.5 RSA and RSA with
OAEP.

Russ conducted a straw poll of the meeting attendees to obtain
their opinion regarding the following options for the "mandatory-
to-implement" key management algorithm: 
1) PKCS#1 v1.5 RSA
2) RSA with OAEP 
3) E-S D-H
The majority of the meeting attendees who voted chose option 1,

An attendee asked if anybody had submitted any patents regarding
RSA with OAEP.  Russ replied that the OAEP authors told him that
they have not submitted any patents relating to OAEP.

Dave Solo asked if the group could discuss separate sign and 
verify "mandatory-to-implement" signature algorithm requirements.
Russ conducted a straw poll of the meeting attendees to obtain
their opinion regarding Dave's request.  The majority of the
meeting attendees who voted indicated that there should not be
separate sign and verify "mandatory-to-implement" signature 
algorithm requirements.

Russ conducted a straw poll of the meeting attendees to obtain 
their opinion regarding the following options for the "mandatory-
to-implement" signature algorithm: 
1) PKCS#1 v1.5 RSA 
2) DSA
3) Both
The majority of the meeting attendees who voted chose "Both".

Russ stated that he would submit these proposals to the S/MIME WG 
mail list.  He noted that the earliest that the changes could be 
made would be September 2000.

An attendee asked how many organizations have implemented OAEP.
Russ replied that he did not know of any S/MIME implementations
that include OAEP.

An attendee stated that vendors are required to use NIST-approved
algorithms for federal procurement efforts.  Russ stated that 
both X9.42 D-H and X9.44 RSA are NIST-approved.

Russ noted that the NIST AES winner is supposed to be announced
in September 2000.  He suggested that the group should discuss 
whether AES should be the mandatory-to-implement symmetric 
encryption algorithm instead of Triple-DES.  Dave Solo noted 
that AES is still theoretical.  

Russ conducted a straw poll of the meeting attendees to obtain
their opinion regarding the following options for the "mandatory-
to-implement" symmetric encryption algorithm: 
1) Triple-DES 
2) AES
The vote was evenly split between the two options.

Pat Cain recommended that the S/MIME v3 standards should continue
to mandate Triple-DES for the immediate future, but that the group
could consider AES later.

Phillip Hallam-Baker suggested that the S/MIME v3 standards could
mandate both Triple-DES and AES.

Carlisle Adams stated his belief that AES must be the "mandatory-
to-implement" symmetric encryption algorithm.  Pat Cain replied 
that AES may not be implemented until the end of next year.  Jim
Schaad noted that RSA with OAEP also delays implementation. 

A meeting attendee stated that the AES has not been published yet,
but Carlisle Adams replied that the five AES candidates are 
well-known.  The implication being that people could begin 
implementing the five AES candidates now. 

Russ re-iterated that he would submit these proposals to the
S/MIME WG mail list.  

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

Examples of S/MIME Messages - Paul Hoffman

Paul Hoffman planned to participate in the meeting, but could not
be present because he was required to attend another meeting at
the same time as the S/MIME WG meeting. 

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

Electronic Signature Formats - John Ross

John briefed regarding the "Electronic Signature Formats for long term
electronic signatures" I-D, <draft-ietf-smime-esformats-01.txt>, July
2000.  The esformats-01 I-D is based on the ETSI Electronic Signature 
Infrastructure Standardisation.

John briefed that the esformats-00 I-D was split into two documents.
One covers Electronic Signature Formats and is proposed to be an 
informational RFC.  The other covers Signature Policy and is proposed
to be an experimental RFC.

John briefed that esformats-01 uses the following RFCs: 
-RFC 2630 Cryptographic Message Syntax (CMS)
-RFC 2459 PKIX Certificate and CRL Profile
-RFC (to be published) PKIX Timestamping protocol
-RFC on "Attribute Certificates".

He summarized that the esformats-01 I-D defines a process to
provide proof of validity of a signature to be used if 
repudiation is attempted.

John stated that the contents of the esformats-01 I-D is technically
equivalent to the ETSI ES 201 733 V.1.1 document.  ETSI owns the
Copyright (C) on this document.  John stated that individual copies
of the document can be downloaded from <http://www.etsi.org>.  He
noted that these are two new ETSI work items: long term Electronic 
Signature Formats that do not mandate timestamping and long term 
Electronic Signature Formats based on XML signatures syntax.



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

Signature Policy Format - Denis Pinkas

Denis briefed regarding the "Electronic Signature Policies" I-D,
<draft-ietf-smime-espolicies-00.txt>.  Denis briefed that the 

contents of the I-D is based on the signature policy defined in the
ETSI ES 201 733 V.1.1.3(2000-05) document.  ETSI owns the
Copyright (C) on this document.  Denis stated that the
I-D defines signature policies for electronic signatures. He defined
signature policy as a set of rules for the creation and validation 
of an electronic signature, under which the validity of signature can
be determined. He noted that a given legal/contractual context may
recognize a particular signature policy as meeting its requirements.
He stated that a signature policy has a globally unique reference, 
which is bound to an electronic signature by the signer as part of 
the signature calculation.  He said that the signature policy needs
to be available in human readable form so that it can be assessed 
to meet the requirements of the legal and contractual context in 
which it is being applied.  He briefed that to allow for the 
automatic processing of an electronic signature another part of the
signature policy specifies the electronic rules for the creation 
and validation of the electronic signature in a computer processable
form.  He noted that the current document defines the format of the
signature policy using ASN.1 and briefed the proposed syntax.  

Denis concluded with the statement that work on section 5 of the ID
continues 

to define the Conformance Requirements including:
5.1  Signature Policy definition -  Any signature policy issued by 
     a Signature Policy Issuer SHALL include ...
5.2  For signer systems - Signer systems MUST be able to process an
     electronic signature defined in accordance with [ES-FORMATS] 
     against the signer rules of a signature policy defined in 
     accordance with ...
5.3  For verifier systems - Verifier systems MUST be able to process 
     an electronic signature defined in accordance with [ES-FORMATS] 
     against the verifier rules of a signature policy defined in 
     accordance with ...

An attendee asked if there was an issue regarding the occurrence of
one or more time stamps associated with the signature.  Denis 
responded that the signature policy may mandate a single or 
multiple TSAs.  For example, separate TSAs may be specified for the
sender and recipient.

Carlisle Adams asked about the timeframe for ETSI.  Denis replied 
that the ASN.1 for the signature format is stable, but the signature
policy ASN.1 syntax is still being actively discussed.  He believes
that there will be a stable signature policy document by the end of
the year.  

John Ross invited comments to both documents.  



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

Wrap Up - Russ Housley

Russ asked if there were any other issues to discuss.  The meeting
attendees were silent.

Meeting adjourned.



Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id GAA17339 for ietf-smime-bks; Thu, 24 Aug 2000 06:25:37 -0700 (PDT)
Received: from public.szptt.net.cn (mail2-smtp.szptt.net.cn [202.96.136.222]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id GAA17332 for <[e-mail]>; Thu, 24 Aug 2000 06:25:25 -0700 (PDT)
Received: from public.szptt.net.cn([202.96.136.221]) by public.szptt.net.cn(JetMail 2.3.2.6) with SMTP id /m1/aimcque/jmail.rcv/0/jmb39a58f30; Thu, 24 Aug 2000 13:22:17 -0000
Received: from loki.ietf.org([132.151.1.177]) by public.szptt.net.cn(JetMail 2.3.2.6) with SMTP id /m0/aimcque/jmail.rcv/4/jmb399d5a43; Fri, 18 Aug 2000 14:44:08 -0000
Received: (from adm@localhost) by loki.ietf.org (8.9.1b+Sun/8.9.1) id JAA00526 for [e-mail]; Fri, 18 Aug 2000 09:05:01 -0400 (EDT)
Received: from ietf.org (odin.ietf.org [10.27.2.28]) by loki.ietf.org (8.9.1b+Sun/8.9.1) with ESMTP id JAA00514 for <[e-mail]>; Fri, 18 Aug 2000 09:04:50 -0400 (EDT)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA27275; Fri, 18 Aug 2000 09:04:49 -0400 (EDT)
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-06.txt
Date: Fri, 18 Aug 2000 09:04:49 -0400
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
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		: Use of the IDEA Encryption Algorithm in CMS
	Author(s)	: S. Teiwes, P. Hartmann, D. Kuenzi
	Filename	: draft-ietf-smime-idea-06.txt
	Pages		: 
	Date		: 17-Aug-00
	
This memo specifies how to incorporate IDEA (International Data
Encryption Algorithm) [IDEA] into S/MIME [SMIME2, SMIME3] as 
an additional strong algorithm for symmetric encryption. For 
organizations who make use of IDEA for data security purposes 
it is of high interest that IDEA is also available in S/MIME. 
The intention of this memo is to provide the OIDs and algorithms 
required that IDEA can be included in S/MIME for symmetric content
and key encryption.

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

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

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

--OtherAccess--

--NextPart--




Received: by ns.secondary.com (8.9.3/8.9.3) id PAA15090 for ietf-smime-bks; Tue, 22 Aug 2000 15:15:02 -0700 (PDT)
Received: from mail.spyrus.com (mail.spyrus.com [207.212.34.20]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id PAA15085 for <[e-mail]>; Tue, 22 Aug 2000 15:15:01 -0700 (PDT)
Received: from rhousley_laptop.spyrus.com (A32161.resnet.ucsb.edu [128.111.32.161]) by mail.spyrus.com (8.9.3/8.9.3) with ESMTP id PAA19230; Tue, 22 Aug 2000 15:14:38 -0700 (PDT)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
X-Priority: 2 (High)
Date: Tue, 22 Aug 2000 17:47:16 -0400
To: [e-mail], [e-mail]
From: Russ Housley <[e-mail]>
Subject: draft-ietf-smime-idea-06.txt
Cc: [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-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Jeff and Marcus:

The draft-ietf-smime-idea-06.txt document has completed S/MIME WG Last 
Call.  It is ready for IESG review and subsequent publication as an 
Informational RFC.

	Title		: Use of the IDEA Encryption Algorithm in CMS
	Author(s)	: S. Teiwes, P. Hartmann, D. Kuenzi
	Filename	: draft-ietf-smime-idea-06.txt
	Date		: 17-Aug-00
	
Russ 



Received: by ns.secondary.com (8.9.3/8.9.3) id NAA13787 for ietf-smime-bks; Tue, 22 Aug 2000 13:56:17 -0700 (PDT)
Received: from mail.spyrus.com (mail.spyrus.com [207.212.34.20]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id NAA13783 for <[e-mail]>; Tue, 22 Aug 2000 13:56:16 -0700 (PDT)
Received: from rhousley_laptop (A32161.resnet.ucsb.edu [128.111.32.161]) by mail.spyrus.com (8.9.3/8.9.3) with ESMTP id NAA18216; Tue, 22 Aug 2000 13:55:35 -0700 (PDT)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 
Date: Tue, 22 Aug 2000 14:23:41 -0400
To: "Jim Schaad" <[e-mail]>
From: Russ Housley <[e-mail]>
Subject: Re: Comments on the RSAES-OAEP draft
Cc: "Ietf-Smime" <[e-mail]>
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-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Jim:

>1.  Given that the question has been raised on at least one IETF mailing
>list, it might be advisable to state that the public key algorithm for rsa
>in a certificate is the same for v1.5 and v2.0.

Agree.  I updated the Introduction to include:

CMS supports variety of architectures for certificate-based key management, 
particularly the one defined by the PKIX working group [PROFILE].  PKCS #1 
Version 1.5 and PKCS #1 Version 2.0 require the same RSA public key 
information.  Thus, a certified RSA public key may be used with either RSA 
key transport technique.

>2.  You have consistantly gotten the RFC number for the v2.0 draft
>incorrect.  It is 2437 not 2347.

Ooops.  I now reference RFC 2437.

Russ


Received: by ns.secondary.com (8.9.3/8.9.3) id GAA00608 for ietf-smime-bks; Fri, 18 Aug 2000 06:04:52 -0700 (PDT)
Received: from ietf.org (odin.ietf.org [132.151.1.176]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id GAA00604 for <[e-mail]>; Fri, 18 Aug 2000 06:04:51 -0700 (PDT)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA27275; Fri, 18 Aug 2000 09:04:49 -0400 (EDT)
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-06.txt
Date: Fri, 18 Aug 2000 09:04:49 -0400
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
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		: Use of the IDEA Encryption Algorithm in CMS
	Author(s)	: S. Teiwes, P. Hartmann, D. Kuenzi
	Filename	: draft-ietf-smime-idea-06.txt
	Pages		: 
	Date		: 17-Aug-00
	
This memo specifies how to incorporate IDEA (International Data
Encryption Algorithm) [IDEA] into S/MIME [SMIME2, SMIME3] as 
an additional strong algorithm for symmetric encryption. For 
organizations who make use of IDEA for data security purposes 
it is of high interest that IDEA is also available in S/MIME. 
The intention of this memo is to provide the OIDs and algorithms 
required that IDEA can be included in S/MIME for symmetric content
and key encryption.

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

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

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

--OtherAccess--

--NextPart--




Received: by ns.secondary.com (8.9.3/8.9.3) id JAA26198 for ietf-smime-bks; Thu, 17 Aug 2000 09:59:58 -0700 (PDT)
Received: from mail.yourdomain.com (m319-mp1-cvx1a.man.ntl.com [62.252.197.63]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id JAA26173; Thu, 17 Aug 2000 09:58:55 -0700 (PDT)
From: [e-mail]
Message-Id: <[e-mail]>
Date: Thu, 17 Aug 2000 14:23:35
Subject: LeisureWebcams.com - See the World
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

LeisureWebcams.com is a recently launched website
specialising in providing free LIVE access to over
1,500 webcams and 2,000 Tourist Offices world wide.

Check it out:-

http://www.leisurewebcams.com/

This offers you the chance to check out live and
frequently updated images of your chosen location
through the webcams and get detailed local knowledge
through the Tourist Offices. Along with booking
holidays direct through our travel partner, there is
the opportunity to sell your unwanted clothes and
equipment through our free Swap Shop.

There is a lot to see, so if you have enjoyed your
trip through our site, do tell your friends and let
us know through 'Your Views'. If you have any
suggestions for the site, or queries, please feel
free to contact me at [e-mail].

I look forward to hearing from you.

Kind regards,

Charlie Yates
MARKETING DIRECTOR
LeisureWebcams.com
 
 
 
 
 
 
 
 
 
 
 
 
 


Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id OAA16134 for ietf-smime-bks; Thu, 10 Aug 2000 14:48:11 -0700 (PDT)
Received: from smtp-out1.bellatlantic.net (smtp-out1.bellatlantic.net [199.45.39.156]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id OAA16128 for <[e-mail]>; Thu, 10 Aug 2000 14:48:10 -0700 (PDT)
Received: from ieca.com (adsl-151-200-26-46.bellatlantic.net [151.200.26.46]) by smtp-out1.bellatlantic.net (8.9.1/8.9.1) with ESMTP id RAA12949 for <[e-mail]>; Thu, 10 Aug 2000 17:47:24 -0400 (EDT)
Message-ID: <[e-mail]>
Date: Thu, 10 Aug 2000 17:45:05 -0400
From: Sean Turner <[e-mail]>
Organization: IECA, Inc.
X-Mailer: Mozilla 4.73 [en] (Win98; U)
X-Accept-Language: en
MIME-Version: 1.0
To: SMIME <[e-mail]>
Subject: Comments on symkeydist-01
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-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

All,

Here are the comments I've received off-line on the symmetric key
distribution draft:

General:

- Remove distributionMethod from messages.  Whatever mechanism the GLA
supports is the mechanism the objects will be distributed to the GL
members.

- CMC expects a one-to-one relationship between control messages and
responses.  glAddMembers, glRemoveMembers, glAddOwners, glRemoveOwners
should only support adding/removing one member/owner at a time.
glSuccessInfo and glFailInfo will also need to be changed accordingly.

- In section 4, glIdentifier is optional determining whether the GL is
supported by the GLA.  Since the glName has to be unique for a given
GLA, the glName should be used to determine whether the GL is supported
by the GLA.  Remove glIdentifier from glDelete, glAddMembers,
glDeleteMembers, glAddOwner, glDeleteOwner, glKeyCompromise, and
glKeyRefresh.

- glDelete, glAddOwners, glRemoveOwners, glkCompromise, and glkRefresh
have an unneeded layer of indirection.  Please remove (e.g., GLDelete
::= GLNameAndIdentifier just make glDelete be GeneralName).

Para 1.1:

- Explicitly state that the the originator can use either the shared KEK
or the MLA's public key certificate to encrypt messages for the MLA.

Para 2 1st para below Figure 1

- The method of key archival would be a better way to differentiate
between multiple KMAs that support a single GLA.

Para 3.1

- A message to request old shared KEKs should be added.  This would
allow new GL members to access messages encrypted under old KEKs.  It
would support things such as list archives.

- A message for the GL member to indicate that they have a new PKC
should be added.  This would help in distribution of messages.

- A message for the GLO to ask GL members for new certificates should be
added.  This will help when the GL member's certificate has expired or
is revoked.

- Need to provide context for implementation column - what component
needs to implement what messages.

- Use lower case names to refer to the messages (i.e., glUseKEK vice
GLUseKEK).

para 3.1.1 - glUseKEK

- You defaulted everything but requestedAlgorithm - make default
algorithm 3DES.

- The default for glAdministration should be managed and accepts
requests.  It seems strange to default secure group lists to be "open."

para 3.1.3 & 3.1.4 glAddMembers and glDeleteMembers

- Indicate in the first paragraph that the message must be signed by the
GLO or GL member.

para 3.1.5 glRekey

- Remove glOwner from the message.  There should be one mechanism to
change the GL owner and that's glAddOwner.

- Not sure if the defaulting mechanism in

para 3.1.6 glAddOwner

- The gLAddOwner message is applicable to closed lists also.  There is
still one owner, but when a GLO leaves a company, for example, there has
to be a mechanism to replace the old GLO with a new GLO.

para 3.1.8 glKeyCompromise

- Somewhere in the draft there is a statement that only the GLO or the
GLA can generate rekey messages.  paragraph 4 indicates that if this
message is sent to the GLA by a GL member it initiates a rekey.  The
message should be redirected to the GLO to maintain this model.

3.1.10 & 3.1.11 glSucessInfo and glFailInfo

- Refering to the note - Don't think we want to distribute sucess/fail
info to all GLOs.  Just send the success/fail info to the requesting GLO
and let the other GLOs use the logs to figure out what happened.

3.1.12 & 3.1.13 glaQueryRequest & glaQueryResponse

- The mechansims should be extensible, as there are surely more things
the GLO would ask of the GLA than the supportedAlgorithms.  Make it an
ANY definded by.

3.1.14 glKey

- glIdentifier is the shared KEK's key identifier.  It should be an
OCTET STRING to match the keyIdentifier in RecipientInfo.kekri.

- Instead of the term Greenwich Mean Time use UTC.

3.2.2 Combining Request and Response

- Though the option to allow individual encryption of messages is
allowed, it is a bad practice.  Please remove the description of
individually encrypting the messages.

- The order of processing for glAddMembers and gLRekey should be
reversed.  Also, not sure why you;d care about processing glSucessInfo
before glKey.

4 Administrative Messages

- Clearly indicate that the eaxct procedures are not required only that
out must be supported.

4.1 Assign KEK to GL

- Make sure to add an error for the GLA to tell the GLO that it does not
have a certificate.

Cheers,

spt



Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id NAA15747 for ietf-smime-bks; Tue, 8 Aug 2000 13:37:15 -0700 (PDT)
Received: from tungsten.btinternet.com (tungsten.btinternet.com [194.73.73.81]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id NAA15743 for <[e-mail]>; Tue, 8 Aug 2000 13:37:12 -0700 (PDT)
Received: from [212.140.201.204] (helo=Jim) by tungsten.btinternet.com with smtp (Exim 3.03 #83) id 13MGBQ-00025B-00; Tue, 08 Aug 2000 21:41:08 +0100
Reply-To: <[e-mail]>
From: "Jim Davies" <[e-mail]>
To: "Russ Housley" <[e-mail]>
Cc: <[e-mail]>
Subject: RE: Way Forward
Date: Tue, 8 Aug 2000 21:05:27 +0100
Message-ID: <003c01c00173$ff62b660$[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0
Importance: Normal
In-Reply-To: <[e-mail]>
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Russ

Glad to get involved.  Unless I am missing a trick - Reflex MailSafe
implements both RSA and D-H - which enables it to be both backward
compatible if dealing with mail from S/MIME v2 users and forward compatible
for S/MIME v3.  My question was really - unless I am missing the point - why
therefore dilute the S/MIME v3 standard?

Best wishes

Jim

-----Original Message-----
From: Russ Housley [mailto:[e-mail]]
Sent: 08 August 2000 17:39
To: [e-mail]
Cc: [e-mail]
Subject: RE: Way Forward


Jim:

We encourage additional implementations to participate in the
interoperability testing.

I understand the concern that you raise about changes in the
mandatory-to-implement algorithms.  This is why we are having a discussion
before any action is taken.  Other implementors support RSA and do not
support D-H.  These folks would like to see S/MIME v2 and S/MIME v3 have an
interoperable mandatory-to-implement algorithm.

Russ

At 02:51 PM 08/08/2000 +0100, Jim Davies wrote:
>Hi Russ
>
>I am a recipient of the mailings in this group - as someone with limited
>technical knowledge but a business interest in PKI - and S/MIME 3 standards
>in particular.  Please make allowances therefore if any of my questions or
>comments are totally off beam!
>
>I have been following the discussions prompted by the proposals below on
RFC
>2630 - and also trying to tie them in with RFC 2632: S/MIME Version 3
>Certificate handling - and RFC 2633: S/MIME Version 3 Message
specification.
>
>My project is currently based around a mail product called Reflex MailSafe
>(http://www.reflex-magnetics.com).  It offers full S/MIME 3 compatibility
>and can use either DH or RSA for generating key pairs.  A "cut down" 56 bit
>version is available at the web site - other than key length it is fully
>functional.  At present there is only a mail client - in due course it is
>planned to offer various network features.
>
>To my mind - the use of DH keys is preferable to RSA.  I had assumed that -
>as a result of using DH keys - S/MIME 2 products would not be able to read
>S/MIME 3 encrypted - and DSA signed - messages.
>
>I am concerned that what appears to be happening is a downgrading or
>watering down of S/MIME 3 in order to enable interoperability with S/MIME 2
>products.  It seems particularly curious when there is a mail client
>available that - so far as I can tell - provides the previously stated
>functionality.  I need to be able to make sound business planning
>decisions - and this debate has thrown me into a bit of a spin.
>
>Am I mis-reading what appears to be going on - or do I have a genuine need
>to re-consider my planning?  Also - were you aware of Reflex MailSafe -
>which I believe to be the first product available that offers full S/MIME 3
>compatibility?  If not - does any of the above have any impact on the
>proposed changes to the standards?
>
>As I said at the outset - please disabuse me if I have missed the point
here
>completely - much of what is discussed quite frankly goes over my head!
>
>I look forward to hearing from you.
>
>Best wishes
>
>Jim
>
>Jim Davies
>Director - GPM Ltd.
>82 Dartmouth Park Hill
>London N19 5HU
>
>Tel.    [phone]
>Fax      [phone]
>Mobile  [phone]
>Email   [e-mail]
>
>
>This e-mail transmission (and any attachment) is strictly confidential
>and intended solely for the person or organisation to whom it is
>addressed.  It may contain privileged and confidential information and
>if you are not the intended recipient, you must not copy, distribute or
>take any action in reliance on it. If you have received this e-mail in
>error, please notify us as soon as possible and delete it.
>
>
>
>
>
>-----Original Message-----
>From: [e-mail]
>[mailto:[e-mail]]On Behalf Of Russ Housley
>Sent: 31 July 2000 22:05
>To: [e-mail]
>Subject: Way Forward
>
>
>At the face-to-face meeting today, we had a fair amount of discussion about
>the best way to proceed.  This message states each of the issues and the
>proposed way forward.  This message is intended to give everyone an
>opportunity to provide their input, even if they were unable to attend the
>meeting.
>
>RFC 2630 Interoperability Testing
>
>Issue:  Two implementations have been tested for EnvelopedData and
>SignedData.  These two data structures are required to implement S/MIME, so
>this is not surprising.  RFC 2630 includes other data structure that are
>MUST implement(EncryptedData, DigestedData, and AuthenticatedData).  We do
>not have two implementations for these data structures.
>
>Proposed way forward:  Change the implementation requirements so that:
>         - EnvelopedData and SignedData MUST be implemented; and
>         - EncryptedData, DigestedData, and AuthenticatedData MAY be
> implemented.
>
>Mandatory To Implement Algorithms
>
>Issue:  Since the RSA patent is about to expire, Blake Ramsdell suggested
>that the RSA algorithm become the mandatory to implement algorithm for key
>management and signature.  It was pointed out that the current RSA key
>management (PKCS#1 v1.5) has a known vulnerability, so the OAEP technique
>should be employed instead.  While we were discussing algorithms, it was
>suggested that AES should be the mandatory to implement symmetric cipher
>instead of Triple-DES.  About half of the people thought that this was a
>good idea.  The other half was concerned that the AES has not been
>published yet.
>
>Proposed way forward:  Change the mandatory to implement algorithm set to:
>         One-way Hash:   SHA-1 (no change)
>         Signature:      Both DSA and RSA (PKCS#1 v1.5)
>         Key Mgmt:       RSA (OAEP)
>         Eencryption:    Triple-DES in CBC mode
>
>All comments on either of these proposals is most welcome.
>
>Russ



Received: by ns.secondary.com (8.9.3/8.9.3) id KAA12002 for ietf-smime-bks; Tue, 8 Aug 2000 10:03:36 -0700 (PDT)
Received: from roadblock.missi.ncsc.mil (roadblock.missi.ncsc.mil [144.51.50.70]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id KAA11998 for <[e-mail]>; Tue, 8 Aug 2000 10:03:34 -0700 (PDT)
Received: from roadblock.missi.ncsc.mil (root@localhost) by roadblock.missi.ncsc.mil with ESMTP id MAA09876 for <[e-mail]>; Tue, 8 Aug 2000 12:54:04 -0400 (EDT)
Message-Id: <[e-mail]>
Date: Tue, 8 Aug 2000 13:03:17 -0400 (EDT)
From: "David P. Kemp" <[e-mail]>
Reply-To: "David P. Kemp" <[e-mail]>
Subject: Re: Way Forward
To: [e-mail]
MIME-Version: 1.0
Content-Type: TEXT/plain; charset=us-ascii
Content-MD5: ijlAkIyPVznwibtgOw2Uew==
X-Mailer: dtmail 1.3.0 CDE Version 1.3 SunOS 5.7 sun4u sparc 
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

I agree that the mandatory algorithms should not be specified in CMS,
for exactly this reason.  The message specification is a reasonable
place for S/MIME algorithm requirements.  Other CMS-using applications
will have their own requirements.

Dave



> From: Malte Borcherding <[e-mail]>
> 
> I second Simon's proposal, an additional reason being that some specifications
> reuse the CMS syntax without mandating the same algorithms as CMS does. It 
would
> be easier and clearer to reference one specific CMS syntax document instead of
> saying "CMS, but just the data structures". 
> 
> Malte
> 
> Simon Blake-Wilson wrote:
> > 
> > Hi Russ,
> > 
> > Several other groups within the IETF ... PKIX and TLS for example ... are
> > separating their specifications
> > into two documents ... one for data structures and one for algorithms. I 
think
> > this should also be
> > considered by the S/MIME group ... both because it is an elegant distinction
> > which allows algorithms
> > to be updated without affecting abstract structures, and because it may 
allow
> > the structures document
> > to proceed to standard more quickly in light of the mandatory algorithms 
issue.



Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id JAA11340 for ietf-smime-bks; Tue, 8 Aug 2000 09:36:24 -0700 (PDT)
Received: from mail.spyrus.com (mail.spyrus.com [207.212.34.20]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA11336 for <[e-mail]>; Tue, 8 Aug 2000 09:36:23 -0700 (PDT)
Received: from rhousley_laptop ([209.172.119.201]) by mail.spyrus.com (8.9.3/8.9.3) with ESMTP id JAA20231; Tue, 8 Aug 2000 09:40:02 -0700 (PDT)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 
Date: Tue, 08 Aug 2000 12:39:01 -0400
To: <[e-mail]>
From: Russ Housley <[e-mail]>
Subject: RE: Way Forward
Cc: [e-mail]
In-Reply-To: <003401c0013f$cefb0a60$[e-mail]>
References: <[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-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Jim:

We encourage additional implementations to participate in the 
interoperability testing.

I understand the concern that you raise about changes in the 
mandatory-to-implement algorithms.  This is why we are having a discussion 
before any action is taken.  Other implementors support RSA and do not 
support D-H.  These folks would like to see S/MIME v2 and S/MIME v3 have an 
interoperable mandatory-to-implement algorithm.

Russ

At 02:51 PM 08/08/2000 +0100, Jim Davies wrote:
>Hi Russ
>
>I am a recipient of the mailings in this group - as someone with limited
>technical knowledge but a business interest in PKI - and S/MIME 3 standards
>in particular.  Please make allowances therefore if any of my questions or
>comments are totally off beam!
>
>I have been following the discussions prompted by the proposals below on RFC
>2630 - and also trying to tie them in with RFC 2632: S/MIME Version 3
>Certificate handling - and RFC 2633: S/MIME Version 3 Message specification.
>
>My project is currently based around a mail product called Reflex MailSafe
>(http://www.reflex-magnetics.com).  It offers full S/MIME 3 compatibility
>and can use either DH or RSA for generating key pairs.  A "cut down" 56 bit
>version is available at the web site - other than key length it is fully
>functional.  At present there is only a mail client - in due course it is
>planned to offer various network features.
>
>To my mind - the use of DH keys is preferable to RSA.  I had assumed that -
>as a result of using DH keys - S/MIME 2 products would not be able to read
>S/MIME 3 encrypted - and DSA signed - messages.
>
>I am concerned that what appears to be happening is a downgrading or
>watering down of S/MIME 3 in order to enable interoperability with S/MIME 2
>products.  It seems particularly curious when there is a mail client
>available that - so far as I can tell - provides the previously stated
>functionality.  I need to be able to make sound business planning
>decisions - and this debate has thrown me into a bit of a spin.
>
>Am I mis-reading what appears to be going on - or do I have a genuine need
>to re-consider my planning?  Also - were you aware of Reflex MailSafe -
>which I believe to be the first product available that offers full S/MIME 3
>compatibility?  If not - does any of the above have any impact on the
>proposed changes to the standards?
>
>As I said at the outset - please disabuse me if I have missed the point here
>completely - much of what is discussed quite frankly goes over my head!
>
>I look forward to hearing from you.
>
>Best wishes
>
>Jim
>
>Jim Davies
>Director - GPM Ltd.
>82 Dartmouth Park Hill
>London N19 5HU
>
>Tel.    [phone]
>Fax      [phone]
>Mobile  [phone]
>Email   [e-mail]
>
>
>This e-mail transmission (and any attachment) is strictly confidential
>and intended solely for the person or organisation to whom it is
>addressed.  It may contain privileged and confidential information and
>if you are not the intended recipient, you must not copy, distribute or
>take any action in reliance on it. If you have received this e-mail in
>error, please notify us as soon as possible and delete it.
>
>
>
>
>
>-----Original Message-----
>From: [e-mail]
>[mailto:[e-mail]]On Behalf Of Russ Housley
>Sent: 31 July 2000 22:05
>To: [e-mail]
>Subject: Way Forward
>
>
>At the face-to-face meeting today, we had a fair amount of discussion about
>the best way to proceed.  This message states each of the issues and the
>proposed way forward.  This message is intended to give everyone an
>opportunity to provide their input, even if they were unable to attend the
>meeting.
>
>RFC 2630 Interoperability Testing
>
>Issue:  Two implementations have been tested for EnvelopedData and
>SignedData.  These two data structures are required to implement S/MIME, so
>this is not surprising.  RFC 2630 includes other data structure that are
>MUST implement(EncryptedData, DigestedData, and AuthenticatedData).  We do
>not have two implementations for these data structures.
>
>Proposed way forward:  Change the implementation requirements so that:
>         - EnvelopedData and SignedData MUST be implemented; and
>         - EncryptedData, DigestedData, and AuthenticatedData MAY be 
> implemented.
>
>Mandatory To Implement Algorithms
>
>Issue:  Since the RSA patent is about to expire, Blake Ramsdell suggested
>that the RSA algorithm become the mandatory to implement algorithm for key
>management and signature.  It was pointed out that the current RSA key
>management (PKCS#1 v1.5) has a known vulnerability, so the OAEP technique
>should be employed instead.  While we were discussing algorithms, it was
>suggested that AES should be the mandatory to implement symmetric cipher
>instead of Triple-DES.  About half of the people thought that this was a
>good idea.  The other half was concerned that the AES has not been
>published yet.
>
>Proposed way forward:  Change the mandatory to implement algorithm set to:
>         One-way Hash:   SHA-1 (no change)
>         Signature:      Both DSA and RSA (PKCS#1 v1.5)
>         Key Mgmt:       RSA (OAEP)
>         Eencryption:    Triple-DES in CBC mode
>
>All comments on either of these proposals is most welcome.
>
>Russ



Received: by ns.secondary.com (8.9.3/8.9.3) id MAA21391 for ietf-smime-bks; Fri, 4 Aug 2000 12:23:19 -0700 (PDT)
Received: from mail.spyrus.com (mail.spyrus.com [207.212.34.20]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id MAA21387 for <[e-mail]>; Fri, 4 Aug 2000 12:23:18 -0700 (PDT)
Received: from rhousley_laptop (216-164-131-174.s174.tnt2.lnhva.md.dialup.rcn.com [216.164.131.174]) by mail.spyrus.com (8.9.3/8.9.3) with ESMTP id MAA06250; Fri, 4 Aug 2000 12:26:31 -0700 (PDT)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 
Date: Fri, 04 Aug 2000 15:19:55 -0400
To: "Bonatti, Chris" <[e-mail]>
From: Russ Housley <[e-mail]>
Subject: Re: MUST vs. MAY in CMS specification
Cc: IETF S/MIME WG <[e-mail]>
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-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Chris:

I guess we had more foresight that I remembered....

Russ


At 01:23 PM 08/03/2000 -0400, Bonatti, Chris wrote:
>     I have to admit to some confusion over the claimed need to
>back the requirements for digested-data, encrypted-data, and
>authenticated-data from MUST to MAY.  My reading of RFC 2630
>suggests that they already are MAY, and neither are they used in
>the message spec (RFC 2633).  Clause 2 of CMS is pretty clear in
>stating the conformance requirement for CMS.  To wit:
>
>      An implementation that conforms to this specification
>      must implement the protection content, ContentInfo, and
>      must implement the data, signed-data, and
>      enveloped-data content types.  The other content types
>      may be implemented if desired.
>
>Can somebody explain where the supposed requirement to support
>these wrappers stems?
>
>Chris



Received: by ns.secondary.com (8.9.3/8.9.3) id GAA03281 for ietf-smime-bks; Fri, 4 Aug 2000 06:10:24 -0700 (PDT)
Received: from [147.73.132.180] (ts003d48.haz-mo.concentric.net [207.155.230.156]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id GAA03272 for <[e-mail]>; Fri, 4 Aug 2000 06:10:20 -0700 (PDT)
Mime-Version: 1.0
X-Sender: [e-mail]
Message-Id: <p04320418b5b0710f86c4@[147.73.132.180]>
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]>
Date: Fri, 4 Aug 2000 09:12:05 -0400
To: [e-mail]
From: Paul Hoffman / IMC <[e-mail]>
Subject: Re: Way Forward
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-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

At 5:59 PM -0400 8/3/00, Sean Turner wrote:
>My two cents:  I think it's likely that we'll switch to AES when 
>it's finalized, why
>don't we wait to change until then?  Then we only have to change once.

It sounds like we need to better define our goals for changing the 
current RFCs. My goal is to have it reflect the reality of today's 
deployed base of S/MIME MUAs. Because of that, mandating either OEAP 
or AES would be much worse than leaving the current RFCs alone.

--Paul Hoffman, Director
--Internet Mail Consortium


Received: by ns.secondary.com (8.9.3/8.9.3) id PAA03848 for ietf-smime-bks; Thu, 3 Aug 2000 15:59:02 -0700 (PDT)
Received: from anchor-post-31.mail.demon.net (anchor-post-31.mail.demon.net [194.217.242.89]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id PAA03844 for <[e-mail]>; Thu, 3 Aug 2000 15:58:59 -0700 (PDT)
Received: from drh-consultancy.demon.co.uk ([193.237.150.98] helo=celocom.com) by anchor-post-31.mail.demon.net with esmtp (Exim 2.12 #1) id 13KU0l-000LRS-0V for [e-mail]; Fri, 4 Aug 2000 00:02:48 +0100
Message-ID: <[e-mail]>
Date: Fri, 04 Aug 2000 00:04:14 +0100
From: Dr Stephen Henson <[e-mail]>
Organization: Dr S N Henson
X-Mailer: Mozilla 4.73 [en] (Win98; U)
X-Accept-Language: en
MIME-Version: 1.0
To: [e-mail]
Subject: Re: Way Forward
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-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Re RFC2631. 

I've only seen one example of the parameter generation technique RFC2631
2.2.1 which is part of the examples draft. However it doesn't agree with
my (experimental) version.

Despite queries in various groups I've so far been unable to locate
anyone who can supply alternative test vectors that are not equivalent
to the FIPS-186 (DSS) special case (the X9.42. spec itself only has DSS
compatible examples) Most people seem to be using alternative
techniques.

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: by ns.secondary.com (8.9.3/8.9.3) id OAA02307 for ietf-smime-bks; Thu, 3 Aug 2000 14:57:43 -0700 (PDT)
Received: from smtp-out1.bellatlantic.net (smtp-out1.bellatlantic.net [199.45.39.156]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id OAA02293 for <[e-mail]>; Thu, 3 Aug 2000 14:57:41 -0700 (PDT)
Received: from ieca.com (adsl-151-200-26-46.bellatlantic.net [151.200.26.46]) by smtp-out1.bellatlantic.net (8.9.1/8.9.1) with ESMTP id SAA22508; Thu, 3 Aug 2000 18:01:23 -0400 (EDT)
Message-ID: <[e-mail]>
Date: Thu, 03 Aug 2000 17:59:04 -0400
From: Sean Turner <[e-mail]>
Organization: IECA, Inc.
X-Mailer: Mozilla 4.73 [en] (Win98; U)
X-Accept-Language: en
MIME-Version: 1.0
To: [e-mail]
CC: Russ Housley <[e-mail]>
Subject: Re: Way Forward
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-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

My two cents:  I think it's likely that we'll switch to AES when it's finalized, why
don't we wait to change until then?  Then we only have to change once.

Cheers,

spt

Russ Housley wrote:

> At the face-to-face meeting today, we had a fair amount of discussion about
> the best way to proceed.  This message states each of the issues and the
> proposed way forward.  This message is intended to give everyone an
> opportunity to provide their input, even if they were unable to attend the
> meeting.
>
> RFC 2630 Interoperability Testing
>
> Issue:  Two implementations have been tested for EnvelopedData and
> SignedData.  These two data structures are required to implement S/MIME, so
> this is not surprising.  RFC 2630 includes other data structure that are
> MUST implement(EncryptedData, DigestedData, and AuthenticatedData).  We do
> not have two implementations for these data structures.
>
> Proposed way forward:  Change the implementation requirements so that:
>         - EnvelopedData and SignedData MUST be implemented; and
>         - EncryptedData, DigestedData, and AuthenticatedData MAY be implemented.
>
> Mandatory To Implement Algorithms
>
> Issue:  Since the RSA patent is about to expire, Blake Ramsdell suggested
> that the RSA algorithm become the mandatory to implement algorithm for key
> management and signature.  It was pointed out that the current RSA key
> management (PKCS#1 v1.5) has a known vulnerability, so the OAEP technique
> should be employed instead.  While we were discussing algorithms, it was
> suggested that AES should be the mandatory to implement symmetric cipher
> instead of Triple-DES.  About half of the people thought that this was a
> good idea.  The other half was concerned that the AES has not been
> published yet.
>
> Proposed way forward:  Change the mandatory to implement algorithm set to:
>         One-way Hash:   SHA-1 (no change)
>         Signature:      Both DSA and RSA (PKCS#1 v1.5)
>         Key Mgmt:       RSA (OAEP)
>         Eencryption:    Triple-DES in CBC mode
>
> All comments on either of these proposals is most welcome.
>
> Russ



Received: by ns.secondary.com (8.9.3/8.9.3) id NAA23819 for ietf-smime-bks; Thu, 3 Aug 2000 13:10:25 -0700 (PDT)
Received: from mail.ec.auckland.ac.nz (mail.student.auckland.ac.nz [130.216.35.201]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id NAA23814 for <[e-mail]>; Thu, 3 Aug 2000 13:10:23 -0700 (PDT)
Received: from kahu.cs.auckland.ac.nz ([e-mail] [130.216.36.13]) by mail.ec.auckland.ac.nz (8.9.3/8.8.6/cs-master) with SMTP id IAA28418; Fri, 4 Aug 2000 08:13:58 +1200 (NZST) (sender [e-mail])
Received: by kahu.cs.auckland.ac.nz (relaymail v0.9) id <96533363803094>; Fri, 4 Aug 2000 08:13:58 (NZST)
From: [e-mail] (Peter Gutmann)
To: [e-mail], [e-mail]
Subject: RE: Way Forward
Reply-To: [e-mail]
X-Charge-To: pgut001
X-Authenticated: relaymail v0.9 on kahu.cs.auckland.ac.nz
Date: Fri, 4 Aug 2000 08:13:58 (NZST)
Message-ID: <[e-mail]>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

"Pawling, John" <[e-mail]> writes:

>The S/MIME Freeware Library (SFL) implements the EncryptedData content type.
>Wang Government Services has not successfully performed interoperability
>testing of the EncryptedData content type between the SFL and any other
>implementations.  We did use the SFL to create an example EncryptedData object
>with unprotected attributes that we sent to Paul Hoffman for inclusion in the
>"Examples of S/MIME Messages" Internet-Draft. We are willing to participate in
>interop testing with anyone else who has implemented the EncryptedData content
>type.

I've done EncryptedData (it's a trivial subset of EnvelopedData), here's a
sample encrypted with CAST-128 using the key "0123456789ABCDEF":

begin 644 EncryptedData.der
M,$X&"2J&2(;W#0$'!J!!,#\"`0`P.@8)*H9(AO<-`0<!,!L&"2J&2(;V?0="
C"C`.!`A..0]OEA5:;`("`("`$.-2W!57JV98ERQYVJA:)]T
`
end
sum -r/size 37389/139 section (from "begin" to "end")
sum -r/size 15095/80 entire input file

>The SFL does not implement the DigestedData and AuthenticatedData content
>types.

Ditto.  My position on these is that I'll implement them as soon as someone
requests them.  OTOH I've only had the code out there for about two years, so
the stampede might start at any point :-).

Peter.




Received: by ns.secondary.com (8.9.3/8.9.3) id LAA22474 for ietf-smime-bks; Thu, 3 Aug 2000 11:42:29 -0700 (PDT)
Received: from wfhqex05.wangfed.com (netva01.wangfed.com [206.137.100.2]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA22469 for <[e-mail]>; Thu, 3 Aug 2000 11:42:28 -0700 (PDT)
Received: by wfhqex05.wangfed.com with Internet Mail Service (5.5.2650.21) id <PWGSP6AM>; Thu, 3 Aug 2000 14:51:54 -0400
Message-ID: <[e-mail]>
From: "Pawling, John" <[e-mail]>
To: [e-mail]
Subject: RE: Way Forward
Date: Thu, 3 Aug 2000 14:45:44 -0400 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Russ/Dave,

When used in conjunction with the Crypto++ freeware library, the S/MIME
Freeware Library (SFL) implements the RFC 2631 Diffie-Hellman (D-H) Key
Agreement Method specification.  Wang Government Services has successfully
performed interop testing of Ephemeral-Static (E-S) D-H-protected
envelopedData objects between the SFL and Microsoft.

============================================
John Pawling, [e-mail]
Wang Government Services, Inc.,
A Getronics Company
============================================ 



Received: by ns.secondary.com (8.9.3/8.9.3) id LAA22405 for ietf-smime-bks; Thu, 3 Aug 2000 11:37:58 -0700 (PDT)
Received: from wfhqex05.wangfed.com (netva01.wangfed.com [206.137.100.2]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA22400 for <[e-mail]>; Thu, 3 Aug 2000 11:37:57 -0700 (PDT)
Received: by wfhqex05.wangfed.com with Internet Mail Service (5.5.2650.21) id <PWGSP504>; Thu, 3 Aug 2000 14:47:23 -0400
Message-ID: <[e-mail]>
From: "Pawling, John" <[e-mail]>
To: [e-mail]
Subject: RE: Way Forward
Date: Thu, 3 Aug 2000 14:41:15 -0400 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Russ,

Your message stated: "RFC 2630 includes other data structure that are MUST
implement(EncryptedData, DigestedData, and AuthenticatedData).  We do not
have two implementations for these data structures."

RFC 2630, Section 2, General Overview, states: "An implementation that
conforms to this specification must implement the protection content,
ContentInfo, and must implement the data,   signed-data, and enveloped-data
content types.  The other content types may be implemented if desired."

Therefore, the EncryptedData, DigestedData and AuthenticatedData content
types are already "MAY implement" requirements (not "MUST implement"
requirements).

FYI.  The S/MIME Freeware Library (SFL) implements the EncryptedData content
type.  Wang Government Services has not successfully performed
interoperability testing of the EncryptedData content type between the SFL
and any other implementations.  We did use the SFL to create an example
EncryptedData object with unprotected attributes that we sent to Paul
Hoffman for inclusion in the "Examples of S/MIME Messages" Internet-Draft.
We are willing to participate in interop testing with anyone else who has
implemented the EncryptedData content type.

The SFL does not implement the DigestedData and AuthenticatedData content
types.

============================================
John Pawling, [e-mail]
Wang Government Services, Inc.,
A Getronics Company
============================================ 


Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id KAA20548 for ietf-smime-bks; Thu, 3 Aug 2000 10:20:22 -0700 (PDT)
Received: from printfile.ietf.marconi.com (printfile.ietf.marconi.com [147.73.128.4]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id KAA20544 for <[e-mail]>; Thu, 3 Aug 2000 10:20:20 -0700 (PDT)
Received: from dhcpdns.ietf.marconi.com (dhcpdns.ietf.marconi.com [147.73.128.3]) by printfile.ietf.marconi.com (8.9.3/8.9.3) with ESMTP id NAA09165 for <[e-mail]>; Thu, 3 Aug 2000 13:28:21 -0400 (EDT)
Received: from ieca.com (wireless-134-53 [147.73.134.53]) by dhcpdns.ietf.marconi.com (8.9.3+Sun/8.9.1) with ESMTP id NAA00510 for <[e-mail]>; Thu, 3 Aug 2000 13:27:38 -0400 (EDT)
Message-ID: <[e-mail]>
Date: Thu, 03 Aug 2000 13:23:58 -0400
From: "Bonatti, Chris" <[e-mail]>
Organization: IECA, Inc.
X-Mailer: Mozilla 4.73 [en] (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
To: IETF S/MIME WG <[e-mail]>
Subject: MUST vs. MAY in CMS specification
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------msAB9FABE777C1358ED6D419EA"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

This is a cryptographically signed message in MIME format.

--------------msAB9FABE777C1358ED6D419EA
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

    I have to admit to some confusion over the claimed need to
back the requirements for digested-data, encrypted-data, and
authenticated-data from MUST to MAY.  My reading of RFC 2630
suggests that they already are MAY, and neither are they used in
the message spec (RFC 2633).  Clause 2 of CMS is pretty clear in
stating the conformance requirement for CMS.  To wit:

     An implementation that conforms to this specification
     must implement the protection content, ContentInfo, and
     must implement the data, signed-data, and
     enveloped-data content types.  The other content types
     may be implemented if desired.

Can somebody explain where the supposed requirement to support
these wrappers stems?

Chris
--------------msAB9FABE777C1358ED6D419EA
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

MIIKIQYJKoZIhvcNAQcCoIIKEjCCCg4CAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC
B+4wggS4MIIEIaADAgECAhACOZkTH5mWlYOiMWNS0NA/MA0GCSqGSIb3DQEBBAUAMIHMMRcw
FQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29y
azFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5
IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRp
dmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMB4XDTk5MTIzMTAwMDAw
MFoXDTAwMTIzMDIzNTk1OVowggEXMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UE
CxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9y
ZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElBQi5MVEQoYyk5ODEeMBwGA1UECxMV
UGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYDVQQLEypEaWdpdGFsIElEIENsYXNzIDEgLSBO
ZXRzY2FwZSBGdWxsIFNlcnZpY2UxHDAaBgNVBAMUE0NocmlzdG9waGVyIEJvbmF0dGkxIDAe
BgkqhkiG9w0BCQEWEWJvbmF0dGljQGllY2EuY29tMFwwDQYJKoZIhvcNAQEBBQADSwAwSAJB
ANKXlrz4lCtsKxQPevEUJ59yPcZpDmBoZnivM/oJtD1bUq0uUPml8eaZThkLVb3lx5Y3bHMe
iZUT86EDSuHBp78CAwEAAaOCAY8wggGLMAkGA1UdEwQCMAAwgawGA1UdIASBpDCBoTCBngYL
YIZIAYb4RQEHAQEwgY4wKAYIKwYBBQUHAgEWHGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9D
UFMwYgYIKwYBBQUHAgIwVjAVFg5WZXJpU2lnbiwgSW5jLjADAgEBGj1WZXJpU2lnbidzIENQ
UyBpbmNvcnAuIGJ5IHJlZmVyZW5jZSBsaWFiLiBsdGQuIChjKTk3IFZlcmlTaWduMBEGCWCG
SAGG+EIBAQQEAwIHgDCBhgYKYIZIAYb4RQEGAwR4FnZkNDY1MmJkNjNmMjA0NzAyOTI5ODc2
M2M5ZDJmMjc1MDY5YzczNTliZWQxYjA1OWRhNzViYzRiYzk3MDE3NDdkYTVkM2YyMTQxYmVh
YzkzYmNhZmY4YTBiYWU2ZGY1ZDcxMTQ5OWJhMmI4NDRmOWYzZWE0NTA2MDMGA1UdHwQsMCow
KKAmoCSGImh0dHA6Ly9jcmwudmVyaXNpZ24uY29tL2NsYXNzMS5jcmwwDQYJKoZIhvcNAQEE
BQADgYEAPEGSRUMcSfb9eE0h/Bqqe0Q6h0YgoqFEL7MCsCFC3QOwvgNROksoF2+dJOCnOGum
vE3Pg6pyXJC02Qmt0qm2hmg3FLTNy0No9UnVld1NH0oejco+eeSfPO2xY0OFj1GojzeGZGfH
hmhB1V43k1Be90B9i/Vn4Tw6UsnhIjg9NgMwggMuMIICl6ADAgECAhEA0nYujRQMPX2yqCVd
r+4NdTANBgkqhkiG9w0BAQIFADBfMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24s
IEluYy4xNzA1BgNVBAsTLkNsYXNzIDEgUHVibGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBB
dXRob3JpdHkwHhcNOTgwNTEyMDAwMDAwWhcNMDgwNTEyMjM1OTU5WjCBzDEXMBUGA1UEChMO
VmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxRjBEBgNV
BAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEgSW5jb3JwLiBCeSBSZWYuLExJ
QUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWduIENsYXNzIDEgQ0EgSW5kaXZpZHVhbCBT
dWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRlZDCBnzANBgkqhkiG9w0BAQEFAAOBjQAw
gYkCgYEAu1pEigQWu1X9A3qKLZRPFXg2uA1Ksm+cVL+86HcqnbnwaLuV2TFBcHqBS7lIE1Yt
xwjhhEKrwKKSq0RcqkLwgg4C6S/7wju7vsknCl22sDZCM7VuVIhPh0q/Gdr5FegPh7Yc48zG
mo5/aiSS4/zgZbqnsX7vyds3ashKyAkG5JkCAwEAAaN8MHowEQYJYIZIAYb4QgEBBAQDAgEG
MEcGA1UdIARAMD4wPAYLYIZIAYb4RQEHAQEwLTArBggrBgEFBQcCARYfd3d3LnZlcmlzaWdu
LmNvbS9yZXBvc2l0b3J5L1JQQTAPBgNVHRMECDAGAQH/AgEAMAsGA1UdDwQEAwIBBjANBgkq
hkiG9w0BAQIFAAOBgQCIuDc73dqUNwCtqp/hgQFxHpJqbS/28Z3TymQ43BuYDAeGW4UVag+5
SYWklfEXfWe0fy0s3ZpCnsM+tI6q5QsG3vJWKvozx74Z11NMw73I4xe1pElCY+zCphcPXVga
STyQXFWjZSAA/Rgg5V+CprGoksVYasGNAzzrw80FopCubjGCAfswggH3AgEBMIHhMIHMMRcw
FQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29y
azFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5
IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRp
dmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkAhACOZkTH5mWlYOiMWNS
0NA/MAkGBSsOAwIaBQCggbEwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0B
CQUxDxcNMDAwODAzMTcyMzU4WjAjBgkqhkiG9w0BCQQxFgQU+Jc0stRgjoITBkh/di+KWZFJ
cvowUgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwBwYFKw4D
AgcwDQYIKoZIhvcNAwICAUAwDQYIKoZIhvcNAwICASgwDQYJKoZIhvcNAQEBBQAEQMSMBWNk
GkK0qBVOjIWxSKIqFnZGoYkSMbF8aJs0lQ2HuB7L8qfuQGCi0RNH80EhvI716d2C0wGaTlDg
8TBBYrY=
--------------msAB9FABE777C1358ED6D419EA--



Received: by ns.secondary.com (8.9.3/8.9.3) id JAA19540 for ietf-smime-bks; Thu, 3 Aug 2000 09:59:12 -0700 (PDT)
Received: from mail.spyrus.com (mail.spyrus.com [207.212.34.20]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA19536 for <[e-mail]>; Thu, 3 Aug 2000 09:59:11 -0700 (PDT)
Received: from rhousley_laptop (wireless-135-26.ietf.marconi.com [147.73.135.26]) by mail.spyrus.com (8.9.3/8.9.3) with ESMTP id KAA17245; Thu, 3 Aug 2000 10:02:21 -0700 (PDT)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 
Date: Thu, 03 Aug 2000 11:29:04 -0400
To: "David P. Kemp" <[e-mail]>
From: Russ Housley <[e-mail]>
Subject: Re: Way Forward
Cc: [e-mail]
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-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Dave:

>Regarding data structures, http://www.ietf.org/ID-nits.html says:
>
>   "For documents advancing in grade
>
>    At least two complete, independent implementations must be tested and
>    reported on, of each role (client/server/peer), and of each feature."
>
>I believe this implies that EncryptedData, DigestedData, and
>AuthenticatedData cannot be simply reduced to MAY status, but must be
>moved to a different document if RFC 2630 is to proceed to Draft.

I will discuss this with the Security ADs.

>And
>attractive as it might be to require AES instead of 3DES, this clause
>precludes that option at this time.

Given the flack associated with backward compatibility and OAEP, I will let 
you defend the AES.  However, I think that AES with RSA-OAEP will be very 
attractive.

>Regarding RSA, if OAEP is specified for RSA key transport, should not
>PSS be specified for signatures?  That said, I agree with Erik that
>PKCS#1 v1.5 is sufficient for key transport, and if there are not two
>independent implementations of X9.31, PKCS#1 is probably sufficient for
>signatures.

I am unaware of any security issues with PKCS#1 v1.5 RSA signatures.  I am 
aware of the alternative format, but I do not know of any security reason 
to make a switch.

>Regarding key establishment, I believe it would be good engineering to
>require a key agreement protocol such as DH, ECDH, a fully-public KEA,
>or a future FIPS key agreement algorithm in CMS-based systems, in
>addition to RSA key transport.  If someone proposed that both RSA and
>X9.42 be mandatory, I would support that proposal if there were two
>tested implementations of X9.42.  Are there?

I know of at least two Ephemeral-Static Diffie-Hellman implementations.  I 
am not sure if any interoperability testing has been done.

>Regarding terminology, I suggest that the term "Key Establishment" be
>used in lieu of "Key Management" in RFC 2630 section 12.3 and elsewhere.
>OAEP and DH have very little to do with "managing" keys; they are used
>to establish a shared session key.  See HAC Definition 12.2.

Probably a good idea.  I am not going to start a son-of-RFC2630 until we 
have a clear direction.  Please remind me when the direction is clear.

Russ




Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id JAA18748 for ietf-smime-bks; Thu, 3 Aug 2000 09:01:37 -0700 (PDT)
Received: from sothmxs01.entrust.com (gatekeeper.entrust.com [204.101.128.170]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA18744 for <[e-mail]>; Thu, 3 Aug 2000 09:01:36 -0700 (PDT)
Received: by sothmxs01.entrust.com with Internet Mail Service (5.5.2650.21) id <PHL2LNKS>; Thu, 3 Aug 2000 12:04:53 -0400
Message-ID: <[e-mail]>
From: Mike Just <[e-mail]>
To: "'David P. Kemp'" <[e-mail]>, [e-mail]
Subject: Terminology - Was RE: Way Forward
Date: Thu, 3 Aug 2000 12:02:33 -0400 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

I agree with David's suggestion below. I find it very confusing that the
term "key management" is used here when I believe "key establishment" (or
even "key agreement") would be more appropriate.  When I hear key
management, I think of updating keys in certificates.  Key establishment is
more closely related to what is actually occuring, and as David points out,
is how it is defined in the literature.

Mike J.

> -----Original Message-----
> From: David P. Kemp [mailto:[e-mail]]
> Sent: Tuesday, August 01, 2000 12:25 PM
> To: [e-mail]
> Subject: Re: Way Forward
> 

<...snip...>

> 
> Regarding terminology, I suggest that the term "Key Establishment" be
> used in lieu of "Key Management" in RFC 2630 section 12.3 and 
> elsewhere.
> OAEP and DH have very little to do with "managing" keys; they are used
> to establish a shared session key.  See HAC Definition 12.2.
> 
> Dave
> 
> 


Received: by ns.secondary.com (8.9.3/8.9.3) id AAA21046 for ietf-smime-bks; Thu, 3 Aug 2000 00:30:01 -0700 (PDT)
Received: from mail.brokat.de ([212.9.175.131]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id AAA21037 for <[e-mail]>; Thu, 3 Aug 2000 00:29:57 -0700 (PDT)
Received: by mail.brokat.de (Smail3.2.0.111/mail.brokat.de) via LF.net GmbH Internet Services via remoteip 172.17.6.61 via remotehost brokat.com with esmtp for mail.imc.org id m13KFWn-005lKdC; Thu, 3 Aug 2000 09:34:53 +0200 (CEST)
Message-ID: <[e-mail]>
Date: Thu, 03 Aug 2000 09:34:33 +0200
From: Malte Borcherding <[e-mail]>
Organization: Brokat AG
X-Mailer: Mozilla 4.73 [en] (WinNT; U)
X-Accept-Language: en,de
MIME-Version: 1.0
To: Russ Housley <[e-mail]>
CC: Simon Blake-Wilson <[e-mail]>, [e-mail]
Subject: Re: Way Forward
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-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

I second Simon's proposal, an additional reason being that some specifications
reuse the CMS syntax without mandating the same algorithms as CMS does. It would
be easier and clearer to reference one specific CMS syntax document instead of
saying "CMS, but just the data structures". 

Malte

Simon Blake-Wilson wrote:
> 
> Hi Russ,
> 
> Several other groups within the IETF ... PKIX and TLS for example ... are
> separating their specifications
> into two documents ... one for data structures and one for algorithms. I think
> this should also be
> considered by the S/MIME group ... both because it is an elegant distinction
> which allows algorithms
> to be updated without affecting abstract structures, and because it may allow
> the structures document
> to proceed to standard more quickly in light of the mandatory algorithms issue.
> 
> Best regards. Simon

-- 
Malte Borcherding
Brokat AG


Received: by ns.secondary.com (8.9.3/8.9.3) id RAA27462 for ietf-smime-bks; Wed, 2 Aug 2000 17:49:38 -0700 (PDT)
Received: from anchor-post-34.mail.demon.net (anchor-post-34.mail.demon.net [194.217.242.92]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id RAA27458 for <[e-mail]>; Wed, 2 Aug 2000 17:49:36 -0700 (PDT)
Received: from drh-consultancy.demon.co.uk ([193.237.150.98] helo=celocom.com) by anchor-post-34.mail.demon.net with esmtp (Exim 2.12 #1) id 13K9GC-0006CF-0Y for [e-mail]; Thu, 3 Aug 2000 01:53:20 +0100
Message-ID: <[e-mail]>
Date: Thu, 03 Aug 2000 01:56:19 +0100
From: Dr Stephen Henson <[e-mail]>
Organization: Dr S N Henson
X-Mailer: Mozilla 4.73 [en] (Win98; U)
X-Accept-Language: en
MIME-Version: 1.0
To: [e-mail]
Subject: Re: Way Forward
References: <Russ Housley's message of "Wed, 02 Aug 2000 11:20:39 -0400"> <Russ Housley's message of "Tue, 01 Aug 2000 16:11:00 -0400"> <Russ Housley's message of "Mon, 31 Jul 2000 17:04:52 -0400"> <[e-mail]> <[e-mail]> <[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-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Russ Housley wrote:
> 
> Eric:
> 
> One change or another is needed.  Either we need to adopt OAEP or we need
> to include the correct processing steps for use with PKCS#1 v1.5.
> 
> All:
> 
> As chairman, I am trying to figure out the consensus of the  work
> group.  If everyone has enough information from this thread, then I would
> like to hear from folks that have an opinion but have not spoken up yet.
> 

I'm in favour of keeping PKCS#1 v1.5 

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: by ns.secondary.com (8.9.3/8.9.3) id QAA26432 for ietf-smime-bks; Wed, 2 Aug 2000 16:39:01 -0700 (PDT)
Received: from smtp.email.msn.com ([207.46.181.60]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id QAA26427 for <[e-mail]>; Wed, 2 Aug 2000 16:39:00 -0700 (PDT)
Received: from SSCSERVER1 - 63.10.61.34 by email.msn.com with Microsoft SMTPSVC; Wed, 2 Aug 2000 16:41:42 -0700
From: "John G Ross" <[e-mail]>
To: <[e-mail]>
Subject: RE: Way Forward
Date: Thu, 3 Aug 2000 00:31:20 +0100
Message-ID: <000501bffcd9$c379deb0$a33f0a3f@SSCSERVER1>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600
In-Reply-To: <[e-mail]>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

As backward compatability is only an issue between versions of S/MIME. Would
a compromise be for CMS to keep to the existing mandatory algorithms as
specified in RFC 2630 (DH/DSA), but in the message specification RFC 2633
also mandate support for RSA, for backward compatinility reasons with S/MIME
v2.

I know this means that both sets of algorithms have to be implemented in
S/MIME, but is that really a big problem.

Regards
John Ross

> -----Original Message-----
> From: [e-mail]
> [mailto:[e-mail]]On Behalf Of Aram Perez
> Sent: Wednesday, August 02, 2000 10:12 PM
> To: [e-mail]
> Subject: Re: Way Forward
>
>
> Hi Russ,
>
> [snip]
> >
> > All:
> >
> > As chairman, I am trying to figure out the consensus of the  work
> > group.  If everyone has enough information from this thread,
> then I would
> > like to hear from folks that have an opinion but have not spoken up yet.
>
> My 2 centavos are: Keep PKCS#1.5 with appropriate notification on
> the known
> attack(s) and recommended procedures to minimize their effect. As you
> stated, there is already reference to OAEP for future versions.
>
> Regards,
> Aram Perez
>
> [snip]
>




Received: by ns.secondary.com (8.9.3/8.9.3) id OAA24126 for ietf-smime-bks; Wed, 2 Aug 2000 14:35:10 -0700 (PDT)
Received: from shell.tsoft.com ([e-mail] [198.144.192.5]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id OAA24122 for <[e-mail]>; Wed, 2 Aug 2000 14:35:09 -0700 (PDT)
Received: from romeo.rtfm.com (speedy.rtfm.com [198.144.199.192] (may be forged)) by shell.tsoft.com (8.8.7/8.8.7) with ESMTP id OAA00484; Wed, 2 Aug 2000 14:38:52 -0700 (PDT)
Received: (ekr@localhost) by romeo.rtfm.com (8.9.3/8.6.4) id OAA80155; Wed, 2 Aug 2000 14:41:45 -0700 (PDT)
To: Russ Housley <[e-mail]>
Cc: [e-mail]
Subject: Re: Way Forward
References: <Russ Housley's message of "Wed, 02 Aug 2000 11:20:39 -0400"> <Russ Housley's message of "Tue, 01 Aug 2000 16:11:00 -0400"> <Russ Housley's message of "Mon, 31 Jul 2000 17:04:52 -0400"> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Reply-to: EKR <[e-mail]>
Mime-Version: 1.0 (generated by tm-edit 7.108)
Content-Type: text/plain; charset=US-ASCII
From: Eric Rescorla <[e-mail]>
Date: 02 Aug 2000 14:41:45 -0700
In-Reply-To: Russ Housley's message of "Wed, 02 Aug 2000 16:04:14 -0400"
Message-ID: <[e-mail]>
Lines: 9
X-Mailer: Gnus v5.6.45/XEmacs 20.4 - "Emerald"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Russ Housley <[e-mail]> writes:
> One change or another is needed.  Either we need to adopt OAEP or we need 
> to include the correct processing steps for use with PKCS#1 v1.5.
Agreed. I'm in favor of the latter, since they don't have any effect
on compatibility.

-Ekr




Received: by ns.secondary.com (8.9.3/8.9.3) id OAA23706 for ietf-smime-bks; Wed, 2 Aug 2000 14:11:19 -0700 (PDT)
Received: from mta6.snfc21.pbi.net (mta6.snfc21.pbi.net [206.13.28.240]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id OAA23702 for <[e-mail]>; Wed, 2 Aug 2000 14:11:17 -0700 (PDT)
Received: from [192.168.1.86] ([208.233.228.110]) by mta6.snfc21.pbi.net (Sun Internet Mail Server sims.3.5.2000.01.05.12.18.p9) with ESMTP id <[e-mail]> for [e-mail]; Wed,  2 Aug 2000 14:11:59 -0700 (PDT)
Date: Wed, 02 Aug 2000 14:12:04 -0700
From: Aram Perez <[e-mail]>
Subject: Re: Way Forward
In-reply-to: <[e-mail]>
To: [e-mail]
Message-id: <[e-mail]>
MIME-version: 1.0
Content-type: text/plain; charset="US-ASCII"
Content-transfer-encoding: 7bit
User-Agent: Microsoft-Outlook-Express-Macintosh-Edition/5.02.2022
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Hi Russ,

[snip]
> 
> All:
> 
> As chairman, I am trying to figure out the consensus of the  work
> group.  If everyone has enough information from this thread, then I would
> like to hear from folks that have an opinion but have not spoken up yet.

My 2 centavos are: Keep PKCS#1.5 with appropriate notification on the known
attack(s) and recommended procedures to minimize their effect. As you
stated, there is already reference to OAEP for future versions.

Regards,
Aram Perez

[snip]



Received: by ns.secondary.com (8.9.3/8.9.3) id NAA22659 for ietf-smime-bks; Wed, 2 Aug 2000 13:15:49 -0700 (PDT)
Received: from mail.spyrus.com (mail.spyrus.com [207.212.34.20]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id NAA22652 for <[e-mail]>; Wed, 2 Aug 2000 13:15:48 -0700 (PDT)
Received: from rhousley_laptop (wireless-135-26.ietf.marconi.com [147.73.135.26]) by mail.spyrus.com (8.9.3/8.9.3) with ESMTP id NAA04642; Wed, 2 Aug 2000 13:18:47 -0700 (PDT)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 
Date: Wed, 02 Aug 2000 16:04:14 -0400
To: EKR <[e-mail]>, [e-mail]
From: Russ Housley <[e-mail]>
Subject: Re: Way Forward
In-Reply-To: <[e-mail]>
References: <Russ Housley's message of "Wed, 02 Aug 2000 11:20:39 -0400"> <Russ Housley's message of "Tue, 01 Aug 2000 16:11:00 -0400"> <Russ Housley's message of "Mon, 31 Jul 2000 17:04:52 -0400"> <[e-mail]> <[e-mail]> <[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-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Eric:

One change or another is needed.  Either we need to adopt OAEP or we need 
to include the correct processing steps for use with PKCS#1 v1.5.

All:

As chairman, I am trying to figure out the consensus of the  work 
group.  If everyone has enough information from this thread, then I would 
like to hear from folks that have an opinion but have not spoken up yet.

Russ


At 09:08 AM 08/02/2000 -0700, Eric Rescorla wrote:
>Russ Housley <[e-mail]> writes:
> > I do not think that we are being gratuitous.  I think that it is good
> > security practice to remove any toe-hold that an attacker has.  Further, I
> > do not believe that the CMS layer in current S/MIME implementations 
> exhibit
> > the behavior (or lack thereof) necessary to be immune from the attack
> > against RSA PKCS#1 v1.5.
>I'm sorry, Russ, but I don't understand your point. It's well known
>how to protect PKCS-1 implementations from this attack: If the PKCS-1
>padding is wrong, instead of throwing an error you randomize the key
>and then continue. In fact, this is what essentially all SSL
>implementations do. While it may be the case that current S/MIME or
>CMS implementations don't do this, it's a trivial change to make and
>introduces no incompatibilities.
>
>Since adding OAEP also requires changing the code _and_ introduces
>incompatibilities, ISTM that just fixing one's PKCS-1 implementation
>is the dominant option.
>
>-Ekr
>



Received: by ns.secondary.com (8.9.3/8.9.3) id LAA20932 for ietf-smime-bks; Wed, 2 Aug 2000 11:52:04 -0700 (PDT)
Received: from netscape.com (h-205-217-237-47.netscape.com [205.217.237.47]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA20924 for <[e-mail]>; Wed, 2 Aug 2000 11:52:01 -0700 (PDT)
Received: from dredd.mcom.com (dredd.mcom.com [205.217.237.54]) by netscape.com (8.10.0/8.10.0) with ESMTP id e72Inxj28226 for <[e-mail]>; Wed, 2 Aug 2000 11:49:59 -0700 (PDT)
Received: from netscape.com ([192.18.120.135]) by dredd.mcom.com (Netscape Messaging Server 4.15 dredd Jun 22 2000 16:29:39) with ESMTP id FYOHW000.85C; Wed, 2 Aug 2000 11:55:13 -0700 
Message-ID: <[e-mail]>
Date: Wed, 02 Aug 2000 11:55:05 -0700
From: [e-mail] (Bob Relyea)
X-Mailer: Mozilla 4.72 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Simon Blake-Wilson <[e-mail]>
CC: EKR <[e-mail]>, Russ Housley <[e-mail]>, [e-mail]
Subject: Re: Way Forward
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-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Simon Blake-Wilson wrote:

> Hi folks,
>
> As Russ points out, there are applications of S/MIME where the known chosen
> ciphertext attack
> on PKCS 1 encryption is applicable.
>
> However I believe the more significant threat is that academic cryptographers
> have largely
> stopped looking at PKCS 1 encryption because they view it as broken from a
> theoretical viewpoint.
> I think this means that the risk that someone will come up with an improved
> attack (or already knows
> a better attack but is not publicizing it) is significant.

Investigating other weaknesses in PKCS 1 is still of academic interest since
several secure protocols which are widely deployed still use it, namely TLS and
SSL.

bob




Received: by ns.secondary.com (8.9.3/8.9.3) id LAA20684 for ietf-smime-bks; Wed, 2 Aug 2000 11:40:58 -0700 (PDT)
Received: from mail.spyrus.com (mail.spyrus.com [207.212.34.20]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA20680 for <[e-mail]>; Wed, 2 Aug 2000 11:40:57 -0700 (PDT)
Received: from rhousley_laptop (wireless-135-26.ietf.marconi.com [147.73.135.26]) by mail.spyrus.com (8.9.3/8.9.3) with ESMTP id LAA02593 for <[e-mail]>; Wed, 2 Aug 2000 11:44:02 -0700 (PDT)
Message-Id: <[e-mail]>
X-Sender: [e-mail] (Unverified)
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 
Date: Wed, 02 Aug 2000 14:43:27 -0400
To: [e-mail]
From: Russ Housley <[e-mail]>
Subject: RE: Way Forward
In-Reply-To: <[e-mail] mics.com>
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-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

I would like to add that RFC 2630 states that future versions will support 
OAEP.  It says (in the security considerations section):

    An updated version of PKCS #1 has been published, PKCS #1 Version 2.0
    [NEWPKCS#1].  This new document will supersede RFC 2313.  PKCS #1
    Version 2.0 preserves support for the encryption padding format
    defined in PKCS #1 Version 1.5 [PKCS#1], and it also defines a new
    alternative.  To resolve the adaptive chosen ciphertext
    vulnerability, the PKCS #1 Version 2.0 specifies and recommends use
    of Optimal Asymmetric Encryption Padding (OAEP) when RSA encryption
    is used to provide confidentiality.  Designers of protocols and
    systems employing CMS for interactive environments should either
    consider usage of OAEP, or should ensure that information which could
    reveal the success or failure of attempted PKCS #1 Version 1.5
    decryption operations is not provided.  Support for OAEP will likely
    be added to a future version of the CMS specification.

Russ

At 08:45 AM 08/02/2000 -0400, Linn, John wrote:
>OAEP's incremental value is particularly applicable to interactive uses of
>CMS, many of which may not have S/MIME's established base concerns and which
>should take other protocol countermeasures (perhaps implying more
>security-relevant complexity and processing to be performed outside the
>bounds of the security encapsulation layer) if OAEP isn't applied. I'd like
>to recommend OAEP as at least a general SHOULD, making it the presumed mode
>unless an application has specific need to profile otherwise; if there's an
>S/MIME interoperability requirement for PKCS#1 v. 1.5, I'd suggest that the
>scope of that MUST's applicability be confined to the S/MIME application.
>
>--jl
>
>-----Original Message-----
>From: Paul Hoffman / IMC [mailto:[e-mail]]
>Sent: Tuesday, August 01, 2000 7:01 PM
>To: [e-mail]
>Subject: Re: Way Forward
>
>
>At 2:18 PM -0700 8/1/00, Eric Rescorla wrote:
> >  > OAEP have been available for years.  PKCS#1 v2.0 includes it.  I do not
> >>  think that it is immature.
> >That's not the issue that I am concerned with. Rather, I'm concerned
> >with introducing gratuitous incompatibilities.
>
>I'm with Eric on this one. We can add a note about how to avoid the
>problem *and* keep compatibility with the established S/MIME base.
>The proposal was prompted by S/MIME, not CMS.
>
>--Paul Hoffman, Director
>--Internet Mail Consortium



Received: by ns.secondary.com (8.9.3/8.9.3) id LAA20375 for ietf-smime-bks; Wed, 2 Aug 2000 11:24:26 -0700 (PDT)
Received: from mail.ec.auckland.ac.nz (mail.student.auckland.ac.nz [130.216.35.201]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA20371 for <[e-mail]>; Wed, 2 Aug 2000 11:24:24 -0700 (PDT)
Received: from kahu.cs.auckland.ac.nz ([e-mail] [130.216.36.13]) by mail.ec.auckland.ac.nz (8.9.3/8.8.6/cs-master) with SMTP id GAA00674; Thu, 3 Aug 2000 06:27:53 +1200 (NZST) (sender [e-mail])
Received: by kahu.cs.auckland.ac.nz (relaymail v0.9) id <96524087310105>; Thu, 3 Aug 2000 06:27:53 (NZST)
From: [e-mail] (Peter Gutmann)
To: [e-mail], [e-mail]
Subject: Re: Way Forward
Cc: [e-mail]
Reply-To: [e-mail]
X-Charge-To: pgut001
X-Authenticated: relaymail v0.9 on kahu.cs.auckland.ac.nz
Date: Thu, 3 Aug 2000 06:27:53 (NZST)
Message-ID: <[e-mail]>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Russ Housley <[e-mail]> writes:

>I do not think that we are being gratuitous.  I think that it is good security
>practice to remove any toe-hold that an attacker has.  Further, I do not
>believe that the CMS layer in current S/MIME implementations exhibit the
>behavior (or lack thereof) necessary to be immune from the attack against RSA
>PKCS#1 v1.5.

When this topic came up the last time I posted the following summary of the
situation:

  [...] this attack requires that an attacker send you around a million pieces
  of CMS encrypted email with attached receipt requests, that you respond with
  a million receipts indicating to the attacker the exact details of why the
  decrypt failed, that you reuse the same per-message key for each of those
  million messages.

  Now maybe I'm being a bit optimistic here, but I do think that claiming this
  is a weakness is a pretty silly.  First of all you need to assume that an
  attacker can somehow send you a million pieces of email without you noticing
  and without it getting stopped by spam blockers.  Your own software then has
  to try to decrypt each of the one million pieces of email, find that it
  can't, and send out a receipt to the sender containing an indication of
  exactly how the decryption failed (this isn't possible even if you wanted to
  do it, although who knows what the Receipt Notification WG have been working
  on recently).  Finally, the whole attack only works if you reuse
  cryptovariables.  This is why the CERT advisory on this problem specifically
  points out "This vulnerability does not affect S/MIME or SET".

  As a security threat, I'd say this rates somewhere down with "Router hit by
  meteorite", "Computer trampled by stampeding water buffalo", "Hard drive
  kidnapped by space aliens", and similar FUD.

Sure, it is in theory possible, if you try really, really hard and are willing
to bend over backwards to cooperate with an attacker, to allow this kind of
attack to occur.  However, abandoning a universally-implemented and used
standard mechanism for a different one on the basis of something like this just
doesn't make any sense.  You're more likely to get someone's key by asking them
for it (I've seen this happen a number of times, in some cases without even
needing to ask for it, by people who assume that "PKCS #12 == certificate" and
send out their "certificate" for others to use) than by using this kind of
attack.

Just because it's (theoretically) possible to break into Fort Knox with a can
opener doesn't mean that Kentucky is going to start screening people at the
border for possession of said item.

Peter.




Received: by ns.secondary.com (8.9.3/8.9.3) id KAA19086 for ietf-smime-bks; Wed, 2 Aug 2000 10:20:05 -0700 (PDT)
Received: from mail.ca.certicom.com ([209.121.99.6]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id KAA19080 for <[e-mail]>; Wed, 2 Aug 2000 10:20:00 -0700 (PDT)
Received: from smtpmail.certicom.com (domino2.certicom.com [10.0.1.25]) by mail.ca.certicom.com (8.9.3/8.9.3) with SMTP id NAA00760; Wed, 2 Aug 2000 13:17:35 -0400 (EDT)
Received: by smtpmail.certicom.com(Lotus SMTP MTA v4.6.4  (830.2 3-23-1999))  id 8525692F.005EC4EB ; Wed, 2 Aug 2000 13:15:07 -0400
X-Lotus-FromDomain: CERTICOM
From: "Simon Blake-Wilson" <[e-mail]>
To: EKR <[e-mail]>
cc: Russ Housley <[e-mail]>, [e-mail]
Message-ID: <[e-mail]>
Date: Wed, 2 Aug 2000 13:22:59 -0400
Subject: Re: Way Forward
Mime-Version: 1.0
Content-type: text/plain; charset=us-ascii
Content-Disposition: inline
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Hi folks,

As Russ points out, there are applications of S/MIME where the known chosen
ciphertext attack
on PKCS 1 encryption is applicable.

However I believe the more significant threat is that academic cryptographers
have largely
stopped looking at PKCS 1 encryption because they view it as broken from a
theoretical viewpoint.
I think this means that the risk that someone will come up with an improved
attack (or already knows
a better attack but is not publicizing it) is significant.

I'd like to raise the opinions above as an objection to increasing the
endorsement by the S/MIME
WG of PKCS 1 encryption and would prefer to see the use of OAEP encouraged.

Best regards. Simon





Eric Rescorla <[e-mail]> on 08/01/2000 05:18:45 PM

Please respond to EKR <[e-mail]>

To:   Russ Housley <[e-mail]>
cc:   [e-mail] (bcc: Simon Blake-Wilson/Certicom)
Subject:  Re: Way Forward




Russ Housley <[e-mail]> writes:
> The attack is probably impossible to mount using S/MIME against a
> human-operated mail agent; however, I am not convinced that a mail list
> agent (or other automated mail agent) would be immune.  Further, CMS is
> being used in many environments, not just S/MIME, and some of those
> environments may have issues.
Understood, but it's trivial to patch these S/MIME agents to
be completely immune to this attack without compromising compatibility.

> OAEP have been available for years.  PKCS#1 v2.0 includes it.  I do not
> think that it is immature.
That's not the issue that I am concerned with. Rather, I'm concerned
with introducing gratuitous incompatibilities.

-Ekr








Received: by ns.secondary.com (8.9.3/8.9.3) id KAA19070 for ietf-smime-bks; Wed, 2 Aug 2000 10:19:45 -0700 (PDT)
Received: from mail.ca.certicom.com ([209.121.99.6]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id KAA19066 for <[e-mail]>; Wed, 2 Aug 2000 10:19:37 -0700 (PDT)
Received: from smtpmail.certicom.com (domino2.certicom.com [10.0.1.25]) by mail.ca.certicom.com (8.9.3/8.9.3) with SMTP id NAA00763; Wed, 2 Aug 2000 13:17:36 -0400 (EDT)
Received: by smtpmail.certicom.com(Lotus SMTP MTA v4.6.4  (830.2 3-23-1999))  id 8525692F.005EC4BF ; Wed, 2 Aug 2000 13:15:07 -0400
X-Lotus-FromDomain: CERTICOM
From: "Simon Blake-Wilson" <[e-mail]>
To: Russ Housley <[e-mail]>
cc: [e-mail]
Message-ID: <[e-mail]>
Date: Wed, 2 Aug 2000 13:12:14 -0400
Subject: Re: Way Forward
Mime-Version: 1.0
Content-type: text/plain; charset=us-ascii
Content-Disposition: inline
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Hi Russ,

Several other groups within the IETF ... PKIX and TLS for example ... are
separating their specifications
into two documents ... one for data structures and one for algorithms. I think
this should also be
considered by the S/MIME group ... both because it is an elegant distinction
which allows algorithms
to be updated without affecting abstract structures, and because it may allow
the structures document
to proceed to standard more quickly in light of the mandatory algorithms issue.

Best regards. Simon





Russ Housley <[e-mail]> on 07/31/2000 05:04:52 PM

To:   [e-mail]
cc:    (bcc: Simon Blake-Wilson/Certicom)
Subject:  Way Forward




At the face-to-face meeting today, we had a fair amount of discussion about
the best way to proceed.  This message states each of the issues and the
proposed way forward.  This message is intended to give everyone an
opportunity to provide their input, even if they were unable to attend the
meeting.

RFC 2630 Interoperability Testing

Issue:  Two implementations have been tested for EnvelopedData and
SignedData.  These two data structures are required to implement S/MIME, so
this is not surprising.  RFC 2630 includes other data structure that are
MUST implement(EncryptedData, DigestedData, and AuthenticatedData).  We do
not have two implementations for these data structures.

Proposed way forward:  Change the implementation requirements so that:
     - EnvelopedData and SignedData MUST be implemented; and
     - EncryptedData, DigestedData, and AuthenticatedData MAY be implemented.

Mandatory To Implement Algorithms

Issue:  Since the RSA patent is about to expire, Blake Ramsdell suggested
that the RSA algorithm become the mandatory to implement algorithm for key
management and signature.  It was pointed out that the current RSA key
management (PKCS#1 v1.5) has a known vulnerability, so the OAEP technique
should be employed instead.  While we were discussing algorithms, it was
suggested that AES should be the mandatory to implement symmetric cipher
instead of Triple-DES.  About half of the people thought that this was a
good idea.  The other half was concerned that the AES has not been
published yet.

Proposed way forward:  Change the mandatory to implement algorithm set to:
     One-way Hash:  SHA-1 (no change)
     Signature:     Both DSA and RSA (PKCS#1 v1.5)
     Key Mgmt: RSA (OAEP)
     Eencryption:   Triple-DES in CBC mode

All comments on either of these proposals is most welcome.

Russ






Received: by ns.secondary.com (8.9.3/8.9.3) id JAA17378 for ietf-smime-bks; Wed, 2 Aug 2000 09:02:05 -0700 (PDT)
Received: from shell.tsoft.com ([e-mail] [198.144.192.5]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA17373 for <[e-mail]>; Wed, 2 Aug 2000 09:02:03 -0700 (PDT)
Received: from romeo.rtfm.com (speedy.rtfm.com [198.144.199.192] (may be forged)) by shell.tsoft.com (8.8.7/8.8.7) with ESMTP id JAA26361; Wed, 2 Aug 2000 09:05:44 -0700 (PDT)
Received: (ekr@localhost) by romeo.rtfm.com (8.9.3/8.6.4) id JAA48337; Wed, 2 Aug 2000 09:08:38 -0700 (PDT)
To: Russ Housley <[e-mail]>
Cc: [e-mail]
Subject: Re: Way Forward
References: <Russ Housley's message of "Tue, 01 Aug 2000 16:11:00 -0400"> <Russ Housley's message of "Mon, 31 Jul 2000 17:04:52 -0400"> <[e-mail]> <[e-mail]> <[e-mail]>
Reply-to: EKR <[e-mail]>
Mime-Version: 1.0 (generated by tm-edit 7.108)
Content-Type: text/plain; charset=US-ASCII
From: Eric Rescorla <[e-mail]>
Date: 02 Aug 2000 09:08:38 -0700
In-Reply-To: Russ Housley's message of "Wed, 02 Aug 2000 11:20:39 -0400"
Message-ID: <[e-mail]>
Lines: 21
X-Mailer: Gnus v5.6.45/XEmacs 20.4 - "Emerald"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Russ Housley <[e-mail]> writes:
> I do not think that we are being gratuitous.  I think that it is good 
> security practice to remove any toe-hold that an attacker has.  Further, I 
> do not believe that the CMS layer in current S/MIME implementations exhibit 
> the behavior (or lack thereof) necessary to be immune from the attack 
> against RSA PKCS#1 v1.5.
I'm sorry, Russ, but I don't understand your point. It's well known
how to protect PKCS-1 implementations from this attack: If the PKCS-1
padding is wrong, instead of throwing an error you randomize the key
and then continue. In fact, this is what essentially all SSL
implementations do. While it may be the case that current S/MIME or
CMS implementations don't do this, it's a trivial change to make and
introduces no incompatibilities.

Since adding OAEP also requires changing the code _and_ introduces
incompatibilities, ISTM that just fixing one's PKCS-1 implementation
is the dominant option.

-Ekr




Received: by ns.secondary.com (8.9.3/8.9.3) id IAA16784 for ietf-smime-bks; Wed, 2 Aug 2000 08:38:15 -0700 (PDT)
Received: from netscape.com (h-205-217-237-46.netscape.com [205.217.237.46]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA16780 for <[e-mail]>; Wed, 2 Aug 2000 08:38:14 -0700 (PDT)
Received: from dredd.mcom.com (dredd.mcom.com [205.217.237.54]) by netscape.com (8.10.0/8.10.0) with ESMTP id e72FWLA07342 for <[e-mail]>; Wed, 2 Aug 2000 08:32:21 -0700 (PDT)
Received: from netscape.com ([192.18.120.135]) by dredd.mcom.com (Netscape Messaging Server 4.15 dredd Jun 22 2000 16:29:39) with ESMTP id FYO8X100.KYY; Wed, 2 Aug 2000 08:41:25 -0700 
Message-ID: <[e-mail]>
Date: Wed, 02 Aug 2000 08:41:18 -0700
From: [e-mail] (Bob Relyea)
X-Mailer: Mozilla 4.72 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Russ Housley <[e-mail]>
CC: EKR <[e-mail]>, [e-mail]
Subject: Re: Way Forward
References: <Russ Housley's message of "Tue, 01 Aug 2000 16:11:00 -0400"> <Russ Housley's message of "Mon, 31 Jul 2000 17:04:52 -0400"> <[e-mail]> <[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-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Russ Housley wrote:

> Eric:
>
> I do not think that we are being gratuitous.  I think that it is good
> security practice to remove any toe-hold that an attacker has.  Further, I
> do not believe that the CMS layer in current S/MIME implementations exhibit
> the behavior (or lack thereof) necessary to be immune from the attack
> against RSA PKCS#1 v1.5.

I have to agree with Eric here. Protocols where are *MUCH* more vulnerable than
CMS or S/MIME were able to work around the attack. We know how to make out
toolkits  immune without sacrificing interoperability, we should do that.
Current implementations that don't exhibit the correct behavior to be immune,
still won't exhibit the correct behavior if you change the spec to OAEP.

If we were developing a new protocol from the ground up, then using OAEP would
be a no brainer. That is not the case here, though.

bob




Received: by ns.secondary.com (8.9.3/8.9.3) id IAA15836 for ietf-smime-bks; Wed, 2 Aug 2000 08:28:59 -0700 (PDT)
Received: from mail.spyrus.com (mail.spyrus.com [207.212.34.20]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA15826 for <[e-mail]>; Wed, 2 Aug 2000 08:28:57 -0700 (PDT)
Received: from rhousley_laptop (wireless-135-26.ietf.marconi.com [147.73.135.26]) by mail.spyrus.com (8.9.3/8.9.3) with ESMTP id IAA28980; Wed, 2 Aug 2000 08:32:04 -0700 (PDT)
Message-Id: <[e-mail]>
X-Sender: [e-mail] (Unverified)
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 
Date: Wed, 02 Aug 2000 11:20:39 -0400
To: EKR <[e-mail]>
From: Russ Housley <[e-mail]>
Subject: Re: Way Forward
Cc: [e-mail]
In-Reply-To: <[e-mail]>
References: <Russ Housley's message of "Tue, 01 Aug 2000 16:11:00 -0400"> <Russ Housley's message of "Mon, 31 Jul 2000 17:04:52 -0400"> <[e-mail]> <[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-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Eric:

I do not think that we are being gratuitous.  I think that it is good 
security practice to remove any toe-hold that an attacker has.  Further, I 
do not believe that the CMS layer in current S/MIME implementations exhibit 
the behavior (or lack thereof) necessary to be immune from the attack 
against RSA PKCS#1 v1.5.

Russ

At 02:18 PM 08/01/2000 -0700, Eric Rescorla wrote:
>Russ Housley <[e-mail]> writes:
> > The attack is probably impossible to mount using S/MIME against a
> > human-operated mail agent; however, I am not convinced that a mail list
> > agent (or other automated mail agent) would be immune.  Further, CMS is
> > being used in many environments, not just S/MIME, and some of those
> > environments may have issues.
>Understood, but it's trivial to patch these S/MIME agents to
>be completely immune to this attack without compromising compatibility.
>
> > OAEP have been available for years.  PKCS#1 v2.0 includes it.  I do not
> > think that it is immature.
>That's not the issue that I am concerned with. Rather, I'm concerned
>with introducing gratuitous incompatibilities.
>
>-Ekr



Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id IAA13524 for ietf-smime-bks; Wed, 2 Aug 2000 08:18:11 -0700 (PDT)
Received: from mail.telenisus.com (mail.tri-sage.com [204.248.55.99]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id IAA13516 for <[e-mail]>; Wed, 2 Aug 2000 08:18:10 -0700 (PDT)
From: [e-mail]
X-Server-Uuid: ecb72b56-2dc3-11d2-bc91-002094082d29
Message-ID: <03E29E2A5833D411A5AC00508BC98E53218714@MAIN>
To: [e-mail]
Subject: status of the Mapping Company Classification Policy to the S/MIME Security Label doc
Date: Wed, 2 Aug 2000 10:26:34 -0500
MIME-Version: 1.0
X-WSS-ID: 1596E25132621-01-02
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-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Sorry I was not at the meeting on Monday but airplane mechanical problems
were my demise.

Anyhow, please see the info below as this was my presentation material.  The
main area of work now is taking the security category syntax and working
examples for each tag.  But I am hoping to receive comments on the syntax
(or any other area of the doc) as it is based on other work but is
different.  

thanks,
Weston

Mapping Company Classification Policy to the S/MIME Security Label
July 31, 2000

Purpose
- Informational RFC
- Build on Security Label feature defined in ESS
- Show how Security Label can used to implement an organizational security
policy 

Have
- Classification Policies and OIDs for:
	Amoco Corporation
		General, Confidential, Highly Confidential
	Caterpillar Inc
		Public, Confidential Green, Confidential Yellow,
Confidential Red
	Whirlpool Corporation
		Public, Internal, Confidential
- Privacy Mark examples
- Security Category syntax

Need
- Comments on 2nd draft
- Generic S/MIME securityCategoryType OID    <= request made for a SMIME oid
for this
- Security Category examples

Security Category Syntax
 SecurityCategoryValues ::= SEQUENCE OF SecurityCategoryTagGroup
 
 SecurityCategoryTagGroup ::=  SEQUENCE {
  securityCategoryTagGroupName	OBJECT IDENTIFIER,                 <=
request made for test Whirlpool OID
  securityCategoryTagGroup	SEQUENCE OF SecurityCategoryTag}
	
 SecurityCategoryTag  ::= CHOICE {
  restrictiveBitMap		[0] BIT STRING,
  permissiveBitMap		[1] BIT STRING,
  noAccessControlBitMap	[2] BIT STRING,
  restrictiveEnumerated	  	[3] SEQUENCE OF INTEGER,
  permissiveEnumerated 	  	[4] SEQUENCE OF INTEGER,
  noAccessControlEnumerated 	[5] SEQUENCE OF INTEGER}

Restrictive Bit Map Tag
Access must be restricted to only those messages whose set of attributes is
a subset of the attributes for the message recipient. 
Security compartments and caveats are examples of restrictive security
attributes. 

Permissive Bit Map Tag 
A message can be accepted if the recipient belongs to any of the release
groups in the release permission list on the message label. 
For example, the label on entities to be available only to members of an
organization's Personnel Office.

No Access Control Bit Map Tag
Represent security category values for which no access control check is
required (e.g. originator controlled data) 

Restrictive Enumerated Tag 
Access must be restricted to only those messages whose set of attributes is
a subset of the attributes for the recipient.
An example of attributes enumerated by this tag are compartments. 

Permissive Enumerated Tag 
A message can be accepted if the recipient belongs to any of the release
groups in the release permission list on the message label. 
An example of attributes enumerated by this tag are release permissions.

No Access Control Enumerated Tag
Represents security category values for which no access control check is
required (e.g. list of country codes).

3rd Draft
- fix errors, clarify wording as necessary
- add examples as needed and marked now by << >>
- address comments
- September ?

Weston Nicolls, CISSP
Sr. Manager, Professional Services
E-Commerce and Cryptography
Telenisus Corporation - Managed Hosting, VPN, Authentication, Firewall and
IDS Services
[phone]




Received: by ns.secondary.com (8.9.3/8.9.3) id FAA03951 for ietf-smime-bks; Wed, 2 Aug 2000 05:42:15 -0700 (PDT)
Received: from tholian.securitydynamics.com (tholian.securid.com [204.167.112.129]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id FAA03946 for <[e-mail]>; Wed, 2 Aug 2000 05:42:14 -0700 (PDT)
Received: from sdtihq24.securitydynamics.com by tholian.securitydynamics.com via smtpd (for mail.imc.org [208.184.76.43]) with SMTP; 2 Aug 2000 12:45:34 UT
Received: from exna00.securitydynamics.com (ebola.securid.com [192.168.7.4]) by sdtihq24.securid.com (Pro-8.9.3/Pro-8.9.3) with ESMTP id IAA28149 for <[e-mail]>; Wed, 2 Aug 2000 08:44:27 -0400 (EDT)
Received: by exna00.securitydynamics.com with Internet Mail Service (5.5.2448.0) id <QCPW8NY7>; Wed, 2 Aug 2000 08:45:56 -0400
Message-ID: <[e-mail]>
From: "Linn, John" <[e-mail]>
To: [e-mail]
Subject: RE: Way Forward
Date: Wed, 2 Aug 2000 08:45:45 -0400 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

OAEP's incremental value is particularly applicable to interactive uses of
CMS, many of which may not have S/MIME's established base concerns and which
should take other protocol countermeasures (perhaps implying more
security-relevant complexity and processing to be performed outside the
bounds of the security encapsulation layer) if OAEP isn't applied. I'd like
to recommend OAEP as at least a general SHOULD, making it the presumed mode
unless an application has specific need to profile otherwise; if there's an
S/MIME interoperability requirement for PKCS#1 v. 1.5, I'd suggest that the
scope of that MUST's applicability be confined to the S/MIME application. 

--jl

-----Original Message-----
From: Paul Hoffman / IMC [mailto:[e-mail]]
Sent: Tuesday, August 01, 2000 7:01 PM
To: [e-mail]
Subject: Re: Way Forward


At 2:18 PM -0700 8/1/00, Eric Rescorla wrote:
>  > OAEP have been available for years.  PKCS#1 v2.0 includes it.  I do not
>>  think that it is immature.
>That's not the issue that I am concerned with. Rather, I'm concerned
>with introducing gratuitous incompatibilities.

I'm with Eric on this one. We can add a note about how to avoid the 
problem *and* keep compatibility with the established S/MIME base. 
The proposal was prompted by S/MIME, not CMS.

--Paul Hoffman, Director
--Internet Mail Consortium


Received: by ns.secondary.com (8.9.3/8.9.3) id PAA19622 for ietf-smime-bks; Tue, 1 Aug 2000 15:57:56 -0700 (PDT)
Received: from [207.155.230.112] (wireless-132-180.ietf.marconi.com [147.73.132.180]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id PAA19618 for <[e-mail]>; Tue, 1 Aug 2000 15:57:54 -0700 (PDT)
Mime-Version: 1.0
X-Sender: [e-mail]
Message-Id: <p0432041db5ad06c079fb@[207.155.230.112]>
In-Reply-To: <[e-mail]>
References: <Russ Housley's message of "Mon, 31 Jul 2000 17:04:52 -0400"> <[e-mail]> <[e-mail]> <[e-mail]>
Date: Tue, 1 Aug 2000 19:01:22 -0400
To: [e-mail]
From: Paul Hoffman / IMC <[e-mail]>
Subject: Re: Way Forward
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-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

At 2:18 PM -0700 8/1/00, Eric Rescorla wrote:
>  > OAEP have been available for years.  PKCS#1 v2.0 includes it.  I do not
>>  think that it is immature.
>That's not the issue that I am concerned with. Rather, I'm concerned
>with introducing gratuitous incompatibilities.

I'm with Eric on this one. We can add a note about how to avoid the 
problem *and* keep compatibility with the established S/MIME base. 
The proposal was prompted by S/MIME, not CMS.

--Paul Hoffman, Director
--Internet Mail Consortium


Received: by ns.secondary.com (8.9.3/8.9.3) id OAA18157 for ietf-smime-bks; Tue, 1 Aug 2000 14:45:49 -0700 (PDT)
Received: from mail.spyrus.com (mail.spyrus.com [207.212.34.20]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id OAA18153 for <[e-mail]>; Tue, 1 Aug 2000 14:45:48 -0700 (PDT)
Received: from rhousley_laptop (wireless-135-26.ietf.marconi.com [147.73.135.26]) by mail.spyrus.com (8.9.3/8.9.3) with ESMTP id OAA18365; Tue, 1 Aug 2000 14:48:44 -0700 (PDT)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 
Date: Tue, 01 Aug 2000 17:47:51 -0400
To: Maxim Masiutin <[e-mail]>
From: Russ Housley <[e-mail]>
Subject: Re[2]: Way Forward
Cc: [e-mail]
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[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-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

We would enjoy your participation.

Russ

At 11:50 PM 08/01/2000 +0300, Maxim Masiutin wrote:
>Hello Russ!
>
>   I'm an author of The Bat!
>   http://www.ritlabs.com/the_bat/
>
>   This email client for Win32
>
>   that has S/MIME implementation based on own codebase written from
>   scratch on Delphi as well as the rest of The Bat!
>
>   I would like The Bat! to pass interoperability testing while forum
>   continues. Your help would be appreciated.
>
>   The Bat! official releases do not have S/MIME support yet, but beta
>   versions of The Bat! are S/MIME enabled.
>
>   You may download The Bat! with S/MIME support from
>   http://www.ritlabs.com/the_bat/beta.html
>
>--
>Maxim Masiutin,
>Software Engineer
>RIT Research Labs  http://www.ritlabs.com/
>



Received: by ns.secondary.com (8.9.3/8.9.3) id OAA17228 for ietf-smime-bks; Tue, 1 Aug 2000 14:12:17 -0700 (PDT)
Received: from shell.tsoft.com ([e-mail] [198.144.192.5]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id OAA17224 for <[e-mail]>; Tue, 1 Aug 2000 14:12:14 -0700 (PDT)
Received: from romeo.rtfm.com (speedy.rtfm.com [198.144.199.192] (may be forged)) by shell.tsoft.com (8.8.7/8.8.7) with ESMTP id OAA28553; Tue, 1 Aug 2000 14:15:52 -0700 (PDT)
Received: (ekr@localhost) by romeo.rtfm.com (8.9.3/8.6.4) id OAA43065; Tue, 1 Aug 2000 14:18:46 -0700 (PDT)
To: Russ Housley <[e-mail]>
Cc: [e-mail]
Subject: Re: Way Forward
References: <Russ Housley's message of "Mon, 31 Jul 2000 17:04:52 -0400"> <[e-mail]> <[e-mail]>
Reply-to: EKR <[e-mail]>
Mime-Version: 1.0 (generated by tm-edit 7.108)
Content-Type: text/plain; charset=US-ASCII
From: Eric Rescorla <[e-mail]>
Date: 01 Aug 2000 14:18:45 -0700
In-Reply-To: Russ Housley's message of "Tue, 01 Aug 2000 16:11:00 -0400"
Message-ID: <[e-mail]>
Lines: 15
X-Mailer: Gnus v5.6.45/XEmacs 20.4 - "Emerald"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Russ Housley <[e-mail]> writes:
> The attack is probably impossible to mount using S/MIME against a 
> human-operated mail agent; however, I am not convinced that a mail list 
> agent (or other automated mail agent) would be immune.  Further, CMS is 
> being used in many environments, not just S/MIME, and some of those 
> environments may have issues.
Understood, but it's trivial to patch these S/MIME agents to
be completely immune to this attack without compromising compatibility.

> OAEP have been available for years.  PKCS#1 v2.0 includes it.  I do not 
> think that it is immature.
That's not the issue that I am concerned with. Rather, I'm concerned
with introducing gratuitous incompatibilities.

-Ekr


Received: by ns.secondary.com (8.9.3/8.9.3) id NAA16811 for ietf-smime-bks; Tue, 1 Aug 2000 13:48:20 -0700 (PDT)
Received: from mail.spyrus.com (mail.spyrus.com [207.212.34.20]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id NAA16807 for <[e-mail]>; Tue, 1 Aug 2000 13:48:19 -0700 (PDT)
Received: from rhousley_laptop (wireless-135-26.ietf.marconi.com [147.73.135.26]) by mail.spyrus.com (8.9.3/8.9.3) with ESMTP id NAA17112; Tue, 1 Aug 2000 13:50:51 -0700 (PDT)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 
Date: Tue, 01 Aug 2000 16:47:20 -0400
To: <[e-mail]>
From: Russ Housley <[e-mail]>
Subject: Re: Comments on draft-ietf-smime-cms-rsaes-oaep-01.txt
Cc: [e-mail]
In-Reply-To: <000001bffa69$4ef5b9a0$b2844993@revelation>
References: <[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-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Jim:

>Section 1 Paragraph 4:  Spelling error on interactibe.

Fixed.

>Section 2 Paragraph 2: Remove last instance of "[CMS]" as it is not
>necessary.

Agree.

>Section 2.1 Paragraph 3: Delete or reword this paragraph as it is not
>correct.  originatorInfo may be present due to other recipient infos.

Agree.  The originatorInfo may be present if some other recipient is using 
a different key management protocol.

>Section 3 Paragraph 5 (maskGenFunc): MFG1 should be changed to MFG1SHA1 or
>all references to it using SHA1 should be replaced with references to it
>using a OWF.
>
>Section 3 Paragraph 5: Is SHA1 to be the one and only OWF supported here or
>are others permitted.  Text is not clear on this issue.

Okay.

>Section 3 Paragaraph 5 and 6:  Why are you requiring that incorrectly
>encoded (i.e. the default value is supplied) be recognized? "... recognize
>both id-sha1 and absent..."

This was done for alignment with PKCS#1 v2.0.

>Section 4 Paragraph 1: Spelling error "SEQUNCEs"

Fixed.

>Please add ASN module to the end.  (I am just lazy.)

Will do.  Either this draft will be folded into an algorithms document, or 
I will add a module here.

Russ


Received: by ns.secondary.com (8.9.3/8.9.3) id NAA16782 for ietf-smime-bks; Tue, 1 Aug 2000 13:47:13 -0700 (PDT)
Received: from mdl.net (sfe02.mdl.net [195.22.225.34]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id NAA16778 for <[e-mail]>; Tue, 1 Aug 2000 13:47:10 -0700 (PDT)
Received: from 195.22.224.54 ([195.22.224.54]) by mdl.net  with Microsoft SMTPSVC(5.5.1877.197.19); Tue, 1 Aug 2000 23:50:09 +0300
Date: Tue, 1 Aug 2000 23:50:29 +0300
From: Maxim Masiutin <[e-mail]>
X-Mailer: The Bat! (v1.46 Beta/2)
Organization: RIT Research Labs
X-Priority: 3 (Normal)
Message-ID: <[e-mail]>
To: Russ Housley <[e-mail]>, EKR <[e-mail]>, [e-mail], Eric Rescorla <[e-mail]>
Subject: Re[2]: Way Forward
In-reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]>
Mime-Version: 1.0
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-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Hello Russ!

  I'm an author of The Bat!
  http://www.ritlabs.com/the_bat/

  This email client for Win32

  that has S/MIME implementation based on own codebase written from
  scratch on Delphi as well as the rest of The Bat!

  I would like The Bat! to pass interoperability testing while forum
  continues. Your help would be appreciated.

  The Bat! official releases do not have S/MIME support yet, but beta
  versions of The Bat! are S/MIME enabled.

  You may download The Bat! with S/MIME support from
  http://www.ritlabs.com/the_bat/beta.html

-- 
Maxim Masiutin,
Software Engineer
RIT Research Labs  http://www.ritlabs.com/




Received: by ns.secondary.com (8.9.3/8.9.3) id NAA16493 for ietf-smime-bks; Tue, 1 Aug 2000 13:29:55 -0700 (PDT)
Received: from mail.spyrus.com (mail.spyrus.com [207.212.34.20]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id NAA16489 for <[e-mail]>; Tue, 1 Aug 2000 13:29:54 -0700 (PDT)
Received: from rhousley_laptop (wireless-135-26.ietf.marconi.com [147.73.135.26]) by mail.spyrus.com (8.9.3/8.9.3) with ESMTP id NAA16726; Tue, 1 Aug 2000 13:32:59 -0700 (PDT)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 
Date: Tue, 01 Aug 2000 16:11:00 -0400
To: EKR <[e-mail]>
From: Russ Housley <[e-mail]>
Subject: Re: Way Forward
Cc: [e-mail]
In-Reply-To: <[e-mail]>
References: <Russ Housley's message of "Mon, 31 Jul 2000 17:04:52 -0400"> <[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-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Eric:

The attack is probably impossible to mount using S/MIME against a 
human-operated mail agent; however, I am not convinced that a mail list 
agent (or other automated mail agent) would be immune.  Further, CMS is 
being used in many environments, not just S/MIME, and some of those 
environments may have issues.

OAEP have been available for years.  PKCS#1 v2.0 includes it.  I do not 
think that it is immature.

Russ

At 08:11 AM 08/01/2000 -0700, Eric Rescorla wrote:
>Russ Housley <[e-mail]> writes:
> > Issue:  Since the RSA patent is about to expire, Blake Ramsdell suggested
> > that the RSA algorithm become the mandatory to implement algorithm for key
> > management and signature.  It was pointed out that the current RSA key
> > management (PKCS#1 v1.5) has a known vulnerability, so the OAEP technique
> > should be employed instead.
>I'm not sure what the rationale is for this and it seems to me to
>present even more opportunities for incompatibility.  The
>vulnerability in PKCS#1 1.5 is an adaptive chosen ciphertext attack
>that requires order 2^20 messages to be processed by the recipient
>with quite specific success or failure indications.  In most
>applications, this isn't practical at all. Moreover, the attack is
>easily countered with a simple set of checks.
>
>-Ekr
>
>[Eric Rescorla                                   [e-mail]]
>
>
>
>
>



Received: by ns.secondary.com (8.9.3/8.9.3) id KAA13082 for ietf-smime-bks; Tue, 1 Aug 2000 10:56:54 -0700 (PDT)
Received: from netscape.com (h-205-217-237-47.netscape.com [205.217.237.47]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id KAA13078 for <[e-mail]>; Tue, 1 Aug 2000 10:56:53 -0700 (PDT)
Received: from judge.mcom.com (judge.mcom.com [205.217.237.53]) by netscape.com (8.10.0/8.10.0) with ESMTP id e71Hslj27458 for <[e-mail]>; Tue, 1 Aug 2000 10:54:47 -0700 (PDT)
Received: from netscape.com ([205.217.229.189]) by judge.mcom.com (Netscape Messaging Server 4.15) with ESMTP id FYMKNZ00.CJK; Tue, 1 Aug 2000 10:59:59 -0700 
Message-ID: <[e-mail]>
Date: Tue, 01 Aug 2000 10:59:57 -0700
From: [e-mail] (Terry Hayes)
X-Mailer: Mozilla 4.73 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: EKR <[e-mail]>
CC: Russ Housley <[e-mail]>, [e-mail]
Subject: Re: Way Forward
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-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

I agree with Eric.  It would be better to maintain compatibility with the
existing S/MIME v2 deployments by using the PKCS #1.5 version of RSA key
management.

If the vulnerability is the one Eric mentions, then it is not really
significant.  It relies on receiving a very specific error message that
indicates that the PKCS #1.5 formatting was incorrect.  It can be countered by
including this error with other types of decryption errors (such as DES padding
errors) or by allowing the decryption to proceed (with the wrong key) and
signaling failures in the integrity (signature or authentication) portion of the
message.  Netscape's version of SSL does exactly this - the SSL handshake fails
later in the sequence when the MAC calculation fails.

In fact, in S/MIME it is not likely that the sender would any sort of response
(error or otherwise) at all, which makes this attack impossible.  In addition
the requirement for 2^20 messages in an email environment makes it impractical
as well.

Again, I would like to see PKCS #1.5 included as the mandatory algorithm to
allow compatibility with existing deployments.

Terry Hayes
[e-mail]

Eric Rescorla wrote:

> Russ Housley <[e-mail]> writes:
> > Issue:  Since the RSA patent is about to expire, Blake Ramsdell suggested
> > that the RSA algorithm become the mandatory to implement algorithm for key
> > management and signature.  It was pointed out that the current RSA key
> > management (PKCS#1 v1.5) has a known vulnerability, so the OAEP technique
> > should be employed instead.
> I'm not sure what the rationale is for this and it seems to me to
> present even more opportunities for incompatibility.  The
> vulnerability in PKCS#1 1.5 is an adaptive chosen ciphertext attack
> that requires order 2^20 messages to be processed by the recipient
> with quite specific success or failure indications.  In most
> applications, this isn't practical at all. Moreover, the attack is
> easily countered with a simple set of checks.
>
> -Ekr
>
> [Eric Rescorla                                   [e-mail]]



Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id JAA11246 for ietf-smime-bks; Tue, 1 Aug 2000 09:25:23 -0700 (PDT)
Received: from roadblock.missi.ncsc.mil (roadblock.missi.ncsc.mil [144.51.50.70]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA11241 for <[e-mail]>; Tue, 1 Aug 2000 09:25:22 -0700 (PDT)
Received: from roadblock.missi.ncsc.mil (root@localhost) by roadblock.missi.ncsc.mil with ESMTP id MAA08581 for <[e-mail]>; Tue, 1 Aug 2000 12:16:05 -0400 (EDT)
Message-Id: <[e-mail]>
Date: Tue, 1 Aug 2000 12:24:46 -0400 (EDT)
From: "David P. Kemp" <[e-mail]>
Reply-To: "David P. Kemp" <[e-mail]>
Subject: Re: Way Forward
To: [e-mail]
MIME-Version: 1.0
Content-Type: TEXT/plain; charset=us-ascii
Content-MD5: uIo6sf+qiG6koAAVm4xnoA==
X-Mailer: dtmail 1.3.0 CDE Version 1.3 SunOS 5.7 sun4u sparc 
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Russ,

Regarding data structures, http://www.ietf.org/ID-nits.html says:

  "For documents advancing in grade
  
   At least two complete, independent implementations must be tested and
   reported on, of each role (client/server/peer), and of each feature."

I believe this implies that EncryptedData, DigestedData, and
AuthenticatedData cannot be simply reduced to MAY status, but must be
moved to a different document if RFC 2630 is to proceed to Draft.  And
attractive as it might be to require AES instead of 3DES, this clause
precludes that option at this time.

Regarding RSA, if OAEP is specified for RSA key transport, should not
PSS be specified for signatures?  That said, I agree with Erik that
PKCS#1 v1.5 is sufficient for key transport, and if there are not two
independent implementations of X9.31, PKCS#1 is probably sufficient for
signatures.

Regarding key establishment, I believe it would be good engineering to
require a key agreement protocol such as DH, ECDH, a fully-public KEA,
or a future FIPS key agreement algorithm in CMS-based systems, in
addition to RSA key transport.  If someone proposed that both RSA and
X9.42 be mandatory, I would support that proposal if there were two
tested implementations of X9.42.  Are there?

Regarding terminology, I suggest that the term "Key Establishment" be
used in lieu of "Key Management" in RFC 2630 section 12.3 and elsewhere.
OAEP and DH have very little to do with "managing" keys; they are used
to establish a shared session key.  See HAC Definition 12.2.

Dave



> Date: Mon, 31 Jul 2000 17:04:52 -0400
> To: [e-mail]
> From: Russ Housley <[e-mail]>
> Subject: Way Forward
> 
> At the face-to-face meeting today, we had a fair amount of discussion about 
> the best way to proceed.  This message states each of the issues and the 
> proposed way forward.  This message is intended to give everyone an 
> opportunity to provide their input, even if they were unable to attend the 
> meeting.
> 
> RFC 2630 Interoperability Testing
> 
> Issue:  Two implementations have been tested for EnvelopedData and 
> SignedData.  These two data structures are required to implement S/MIME, so 
> this is not surprising.  RFC 2630 includes other data structure that are 
> MUST implement(EncryptedData, DigestedData, and AuthenticatedData).  We do 
> not have two implementations for these data structures.
> 
> Proposed way forward:  Change the implementation requirements so that:
> 	- EnvelopedData and SignedData MUST be implemented; and
> 	- EncryptedData, DigestedData, and AuthenticatedData MAY be implemented.
> 
> Mandatory To Implement Algorithms
> 
> Issue:  Since the RSA patent is about to expire, Blake Ramsdell suggested 
> that the RSA algorithm become the mandatory to implement algorithm for key 
> management and signature.  It was pointed out that the current RSA key 
> management (PKCS#1 v1.5) has a known vulnerability, so the OAEP technique 
> should be employed instead.  While we were discussing algorithms, it was 
> suggested that AES should be the mandatory to implement symmetric cipher 
> instead of Triple-DES.  About half of the people thought that this was a 
> good idea.  The other half was concerned that the AES has not been 
> published yet.
> 
> Proposed way forward:  Change the mandatory to implement algorithm set to:
> 	One-way Hash:	SHA-1 (no change)
> 	Signature:	Both DSA and RSA (PKCS#1 v1.5)
> 	Key Mgmt:	RSA (OAEP)
> 	Eencryption:	Triple-DES in CBC mode
> 
> All comments on either of these proposals is most welcome.
> 
> Russ



Received: by ns.secondary.com (8.9.3/8.9.3) id IAA03435 for ietf-smime-bks; Tue, 1 Aug 2000 08:05:05 -0700 (PDT)
Received: from shell.tsoft.com ([e-mail] [198.144.192.5]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA03431 for <[e-mail]>; Tue, 1 Aug 2000 08:05:04 -0700 (PDT)
Received: from romeo.rtfm.com (speedy.rtfm.com [198.144.199.192] (may be forged)) by shell.tsoft.com (8.8.7/8.8.7) with ESMTP id IAA11694; Tue, 1 Aug 2000 08:08:41 -0700 (PDT)
Received: (ekr@localhost) by romeo.rtfm.com (8.9.3/8.6.4) id IAA40722; Tue, 1 Aug 2000 08:11:34 -0700 (PDT)
To: Russ Housley <[e-mail]>
Cc: [e-mail]
Subject: Re: Way Forward
References: <[e-mail]>
Reply-to: EKR <[e-mail]>
Mime-Version: 1.0 (generated by tm-edit 7.108)
Content-Type: text/plain; charset=US-ASCII
From: Eric Rescorla <[e-mail]>
Date: 01 Aug 2000 08:11:34 -0700
In-Reply-To: Russ Housley's message of "Mon, 31 Jul 2000 17:04:52 -0400"
Message-ID: <[e-mail]>
Lines: 23
X-Mailer: Gnus v5.6.45/XEmacs 20.4 - "Emerald"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Russ Housley <[e-mail]> writes:
> Issue:  Since the RSA patent is about to expire, Blake Ramsdell suggested 
> that the RSA algorithm become the mandatory to implement algorithm for key 
> management and signature.  It was pointed out that the current RSA key 
> management (PKCS#1 v1.5) has a known vulnerability, so the OAEP technique 
> should be employed instead.
I'm not sure what the rationale is for this and it seems to me to
present even more opportunities for incompatibility.  The
vulnerability in PKCS#1 1.5 is an adaptive chosen ciphertext attack
that requires order 2^20 messages to be processed by the recipient
with quite specific success or failure indications.  In most
applications, this isn't practical at all. Moreover, the attack is
easily countered with a simple set of checks.

-Ekr

[Eric Rescorla                                   [e-mail]]








Received: by ns.secondary.com (8.9.3/8.9.3) id GAA27022 for ietf-smime-bks; Tue, 1 Aug 2000 06:02:56 -0700 (PDT)
Received: from mail.spyrus.com (mail.spyrus.com [207.212.34.20]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id GAA27012 for <[e-mail]>; Tue, 1 Aug 2000 06:02:54 -0700 (PDT)
Received: from rhousley_laptop (wireless-135-26.ietf.marconi.com [147.73.135.26]) by mail.spyrus.com (8.9.3/8.9.3) with ESMTP id GAA08365 for <[e-mail]>; Tue, 1 Aug 2000 06:05:58 -0700 (PDT)
Message-Id: <[e-mail]>
X-Sender: [e-mail] (Unverified)
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 
Date: Mon, 31 Jul 2000 17:04:52 -0400
To: [e-mail]
From: Russ Housley <[e-mail]>
Subject: Way Forward
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-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

At the face-to-face meeting today, we had a fair amount of discussion about 
the best way to proceed.  This message states each of the issues and the 
proposed way forward.  This message is intended to give everyone an 
opportunity to provide their input, even if they were unable to attend the 
meeting.

RFC 2630 Interoperability Testing

Issue:  Two implementations have been tested for EnvelopedData and 
SignedData.  These two data structures are required to implement S/MIME, so 
this is not surprising.  RFC 2630 includes other data structure that are 
MUST implement(EncryptedData, DigestedData, and AuthenticatedData).  We do 
not have two implementations for these data structures.

Proposed way forward:  Change the implementation requirements so that:
	- EnvelopedData and SignedData MUST be implemented; and
	- EncryptedData, DigestedData, and AuthenticatedData MAY be implemented.

Mandatory To Implement Algorithms

Issue:  Since the RSA patent is about to expire, Blake Ramsdell suggested 
that the RSA algorithm become the mandatory to implement algorithm for key 
management and signature.  It was pointed out that the current RSA key 
management (PKCS#1 v1.5) has a known vulnerability, so the OAEP technique 
should be employed instead.  While we were discussing algorithms, it was 
suggested that AES should be the mandatory to implement symmetric cipher 
instead of Triple-DES.  About half of the people thought that this was a 
good idea.  The other half was concerned that the AES has not been 
published yet.

Proposed way forward:  Change the mandatory to implement algorithm set to:
	One-way Hash:	SHA-1 (no change)
	Signature:	Both DSA and RSA (PKCS#1 v1.5)
	Key Mgmt:	RSA (OAEP)
	Eencryption:	Triple-DES in CBC mode

All comments on either of these proposals is most welcome.

Russ