Protocol Action: Cryptographic Message Syntax to Proposed Standard

[The IESG <[e-mail]>]

The IESG has approved publication of the following Internet-Drafts as
Proposed Standards:

 o Cryptographic Message Syntax
	<draft-ietf-smime-rfc2630bis-08.txt>
 o Cryptographic Message Syntax (CMS) Algorithms
	<draft-ietf-smime-cmsalg-08.txt>

These documents are the product of the S/MIME Mail Security Working
Group.  The IESG contact persons are Jeffrey Schiller and Steve
Bellovin.

 
Technical Summary
 
  These documents constitute a revision to an existing RFC, RFC2630.
  These documents obsolate RFC3211, by merging it in to the main
  specification.  Specific algorithms that were previously specified in the
  main CMS document are now moved to a separate CMSALG document.

Working Group Summary

 There was concensus on this document set.  Minor issues arose during
 LAST CALL, which caused both RFC2630bis and CMSALG to be updated
 slightly.

Protocol Quality

 The documents have been reviewed for the IESG by Marcus Leech.



Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g5QJLW026215 for ietf-smime-bks; Wed, 26 Jun 2002 12:21:32 -0700 (PDT)
Received: from ietf.org (odin.ietf.org [132.151.1.176]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g5QJLVw26211 for <[e-mail]>; Wed, 26 Jun 2002 12:21:31 -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 PAA06591; Wed, 26 Jun 2002 15:20:41 -0400 (EDT)
Message-Id: <[e-mail]>
To: IETF-Announce: ;
Cc: RFC Editor <[e-mail]>, Internet Architecture Board <[e-mail]>, [e-mail]
From: The IESG <[e-mail]>
Subject: Protocol Action: Cryptographic Message Syntax to Proposed Standard
Date: Wed, 26 Jun 2002 15:20:41 -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>

The IESG has approved publication of the following Internet-Drafts as
Proposed Standards:

 o Cryptographic Message Syntax
	<draft-ietf-smime-rfc2630bis-08.txt>
 o Cryptographic Message Syntax (CMS) Algorithms
	<draft-ietf-smime-cmsalg-08.txt>

These documents are the product of the S/MIME Mail Security Working
Group.  The IESG contact persons are Jeffrey Schiller and Steve
Bellovin.

 
Technical Summary
 
  These documents constitute a revision to an existing RFC, RFC2630.
  These documents obsolate RFC3211, by merging it in to the main
  specification.  Specific algorithms that were previously specified in the
  main CMS document are now moved to a separate CMSALG document.

Working Group Summary

 There was concensus on this document set.  Minor issues arose during
 LAST CALL, which caused both RFC2630bis and CMSALG to be updated
 slightly.

Protocol Quality

 The documents have been reviewed for the IESG by Marcus Leech.


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g5OFhDT10797 for ietf-smime-bks; Mon, 24 Jun 2002 08:43:13 -0700 (PDT)
Received: from vulcan.rsasecurity.com (mail.rsasecurity.com [204.167.114.123]) by above.proper.com (8.11.6/8.11.3) with SMTP id g5OFhBw10790 for <[e-mail]>; Mon, 24 Jun 2002 08:43:12 -0700 (PDT)
Received: from no.name.available by vulcan.rsasecurity.com via smtpd (for mail.imc.org [208.184.76.43]) with SMTP; 24 Jun 2002 15:42:52 UT
Received: from ebola.securitydynamics.com (ebola.securid.com [192.80.211.4]) by sdtihq24.securid.com (Pro-8.9.3/Pro-8.9.3) with ESMTP id LAA14977 for <[e-mail]>; Mon, 24 Jun 2002 11:43:12 -0400 (EDT)
Received: from exno02.dynas.se (localhost [127.0.0.1]) by ebola.securitydynamics.com (8.10.2+Sun/8.10.2) with ESMTP id g5OFfCl11325 for <[e-mail]>; Mon, 24 Jun 2002 11:41:13 -0400 (EDT)
Received: by exno02.eu.rsa.net with Internet Mail Service (5.5.2653.19) id <K6L0CKZR>; Mon, 24 Jun 2002 17:42:11 +0200
Received: from HOUSLEY-LAP.rsasecurity.com (HOUSLEY-LAP [10.3.9.31]) by exna00.securitydynamics.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id M28ZR01L; Mon, 24 Jun 2002 11:43:02 -0400
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 5.1
Date: Mon, 24 Jun 2002 11:42:59 -0400
To: [e-mail]
From: "Housley, Russ" <[e-mail]>
Subject: S/MIME WG Agenda for Yokohama
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>

Here is the agenda that I have put together.  Please let me know if 
corrections are needed.  In some cases, individuals listed will not be able 
to attend, but they will provide slides for someone else to present.

Russ

= = = = = = = = =

           S/MIME Mail Security WG Agenda


Introductions				Russ Housley
Working Group Status			Russ Housley
CMSbis Status			Russ Housley
MSGbis Update			Blake Ramsdell
CERTbis Update			Blake Ramsdell
X400wrap & X400transport Update 	Chris Bonatti
CMS and ESS Examples Update	Paul Hoffman
Interoperability Matrix Update		Jim Schaad
AES Update				Jim Schaad
RSA-OAEP Update 			Russ Housley
Wrap up				Russ Housley


Received: by above.proper.com (8.11.6/8.11.3) id g5IITYA08874 for ietf-smime-bks; Tue, 18 Jun 2002 11:29:34 -0700 (PDT)
Received: from ietf.org (odin.ietf.org [132.151.1.176]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g5IITXn08868 for <[e-mail]>; Tue, 18 Jun 2002 11:29:33 -0700 (PDT)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA29684; Tue, 18 Jun 2002 14:28:56 -0400 (EDT)
Message-Id: <[e-mail]>
To: IETF-Announce: ;
Cc: [e-mail]
From: The IESG <[e-mail]>
SUBJECT: Last Call: CMS Symmetric Key Management and Distribution to  Proposed Standard
Reply-to: [e-mail]
Date: Tue, 18 Jun 2002 14:28:56 -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>

The IESG has received a request from the S/MIME Mail Security Working 
Group to consider CMS Symmetric Key Management and Distribution 
<draft-ietf-smime-symkeydist-07.txt> as a Proposed Standard.  

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action.  Please send any comments to the 
[e-mail] or [e-mail] mailing lists by July 2, 2002.

Files can be obtained via 
http://www.ietf.org/internet-drafts/draft-ietf-smime-symkeydist-07.txt





Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g5EBVds00584 for ietf-smime-bks; Fri, 14 Jun 2002 04:31:39 -0700 (PDT)
Received: from ietf.org (odin.ietf.org [132.151.1.176]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g5EBVbn00580 for <[e-mail]>; Fri, 14 Jun 2002 04:31:38 -0700 (PDT)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA25008; Fri, 14 Jun 2002 07:31:02 -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-cms-rsaes-oaep-03.txt
Date: Fri, 14 Jun 2002 07:31:02 -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 RSAES-OAEP Transport Algorithm in CMS
	Author(s)	: R. Housley
	Filename	: draft-ietf-smime-cms-rsaes-oaep-03.txt
	Pages		: 8
	Date		: 13-Jun-02
	
This document describes the use of the RSAES-OAEP key transport
method of key management within the Cryptographic Message Syntax.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-smime-cms-rsaes-oaep-03.txt

To remove yourself from the IETF Announcement list, send a message to 
ietf-announce-request with the word unsubscribe in the body of the message.

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

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


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

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

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

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="[e-mail]"

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

ENCODING mime
FILE /internet-drafts/draft-ietf-smime-cms-rsaes-oaep-03.txt

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

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

--OtherAccess--

--NextPart--




Received: by above.proper.com (8.11.6/8.11.3) id g5DNHNO12974 for ietf-smime-bks; Thu, 13 Jun 2002 16:17:23 -0700 (PDT)
Received: from Obsidian (pcp01965971pcs.nrockv01.md.comcast.net [68.48.109.11]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g5DNHLn12969 for <[e-mail]>; Thu, 13 Jun 2002 16:17:21 -0700 (PDT)
Received: from [192.168.0.3] by Obsidian (ArGoSoft Mail Server, Version 1.61 (1.6.1.9)); Thu, 13 Jun 2002 19:17:24 -0400
From: "Bonatti, Chris" <[e-mail]>
To: <[e-mail]>
Cc: "'SMIME, IETF'" <[e-mail]>
Subject: RE: Way of saying - 2.
Date: Thu, 13 Jun 2002 19:17:23 -0400
Message-ID: <[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 IMO, Build 9.0.2416 (9.0.2911.0)
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700
Importance: Normal
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>

Muzumdar, Hari <[e-mail]> wrote:
>
> Two very basic questions, but I need confirmation.
>
> In the context of X.400-transport and X.400-wrap:
>
> 1) When an X.400 UA receives a message, the CMS object
> in the message can
>    yield either a canonical MIME message or an X.400
> Content (IPM/EDI/etc).
>    Is this correct?

Yes, that's possible.  A more useful scenario is that the X.400
UA communicates with other X.400 UAs that use S/MIME with WRAP
and TRANSPORT.  Other UAs that are MIME-aware may share the same
X.400 transport infrastructure and support both X.400 and MIME
content.  This allows use of S/MIME in pure X.400 environments,
and provides a migration path to MIME content.

>
> 2) By the same token, when an Internet MIME UA
> receives an S/MIME message,
>    the CMS object in the message can yield either a
> canonical MIME message
>    or an X.400 Content.
>    Is this correct?

Again correct.

>
> Best Regards,
> 		Hari.

Chris





Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g5BLJ0q28322 for ietf-smime-bks; Tue, 11 Jun 2002 14:19:00 -0700 (PDT)
Received: from gamma.isi.edu (gamma.isi.edu [128.9.144.145]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g5BLIxn28318 for <[e-mail]>; Tue, 11 Jun 2002 14:18:59 -0700 (PDT)
Received: from ISI.EDU (jet.isi.edu [128.9.160.87]) by gamma.isi.edu (8.11.6/8.11.2) with ESMTP id g5BLIpE02017; Tue, 11 Jun 2002 14:18:51 -0700 (PDT)
Message-Id: <[e-mail]>
To: IETF-Announce: ;
Subject: RFC 3274 on Compressed Data Content Type for Cryptographic Message Syntax (CMS)
Cc: [e-mail], [e-mail]
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary=NextPart
Date: Tue, 11 Jun 2002 14:18:50 -0700
From: RFC Editor <[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>

--NextPart


A new Request for Comments is now available in online RFC libraries.


        RFC 3274

        Title:	    Compressed Data Content Type for
                    Cryptographic Message Syntax (CMS)
        Author(s):  P. Gutmann
        Status:	    Standards Track
	Date:       June 2002
        Mailbox:    [e-mail]
        Pages:      6
        Characters: 11276
        Updates/Obsoletes/SeeAlso:  None

        I-D Tag:    draft-ietf-smime-compression-07.txt

        URL:        ftp://ftp.rfc-editor.org/in-notes/rfc3274.txt


This document defines a format for using compressed data as a
Cryptographic Message Syntax (CMS) content type.  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 is a product of the S/MIME Mail Security Working Group
of the IETF.

This is now a Proposed Standard Protocol.

This document specifies an Internet standards track protocol for
the Internet community, and requests discussion and suggestions
for improvements.  Please refer to the current edition of the
"Internet Official Protocol Standards" (STD 1) for the
standardization state and status of this protocol.  Distribution
of this memo is unlimited.

This announcement is sent to the IETF list and the RFC-DIST list.
Requests to be added to or deleted from the IETF distribution list
should be sent to [e-mail].  Requests to be
added to or deleted from the RFC-DIST distribution list should
be sent to [e-mail].

Details on obtaining RFCs via FTP or EMAIL may be obtained by sending
an EMAIL message to [e-mail] with the message body 
help: ways_to_get_rfcs.  For example:

        To: [e-mail]
        Subject: getting rfcs

        help: ways_to_get_rfcs

Requests for special distribution should be addressed to either the
author of the RFC in question, or to [e-mail].  Unless
specifically noted otherwise on the RFC itself, all RFCs are for
unlimited distribution.echo 
Submissions for Requests for Comments should be sent to
[e-mail].  Please consult RFC 2223, Instructions to RFC
Authors, for further information.


Joyce K. Reynolds and Sandy Ginoza
USC/Information Sciences Institute

...

Below is the data which will enable a MIME compliant Mail Reader 
implementation to automatically retrieve the ASCII version
of the RFCs.

--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]>

RETRIEVE: rfc
DOC-ID: rfc3274

--OtherAccess
Content-Type:   Message/External-body;
        name="rfc3274.txt";
        site="ftp.isi.edu";
        access-type="anon-ftp";
        directory="in-notes"

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

--OtherAccess--
--NextPart--


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g582ZPF26615 for ietf-smime-bks; Fri, 7 Jun 2002 19:35:25 -0700 (PDT)
Received: from hermes.cs.auckland.ac.nz (hermes.cs.auckland.ac.nz [130.216.35.151]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g582UMn26526; Fri, 7 Jun 2002 19:30:22 -0700 (PDT)
Received: from ruru.cs.auckland.ac.nz (ruru-nfs.cs.auckland.ac.nz [130.216.35.12]) by hermes.cs.auckland.ac.nz (8.12.3/8.12.3) with ESMTP id g582UKqf019497; Sat, 8 Jun 2002 14:30:20 +1200
Received: (from pgut001@localhost) by ruru.cs.auckland.ac.nz (8.9.3/8.8.6/cs-slave) id OAA501972; Sat, 8 Jun 2002 14:30:19 +1200 (NZST) (sender [e-mail])
Date: Sat, 8 Jun 2002 14:30:19 +1200 (NZST)
Message-ID: <[e-mail]>
From: [e-mail] (Peter Gutmann)
To: [e-mail], [e-mail]
Subject: Updated version of dumpasn1 available
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 the aperiodic announcement of a newer version of dumpasn1, my ASN.1
printing and diagnostic tool.  Recent updates include automated handling of
encapsulated data (if you're still using a version that uses -b and -o then you
really need to get this update), indication of bit positions in bitflags when
there's a single bitflag set, proper formatting of dates rather than just
dumping the ISO 8601 strings, and some other odds and ends.  It's available
from the usual location, http://www.cs.auckland.ac.nz/~pgut001/dumpasn1.c.

Peter.


Received: by above.proper.com (8.11.6/8.11.3) id g57AUiK21811 for ietf-smime-bks; Fri, 7 Jun 2002 03:30:44 -0700 (PDT)
Received: from zmamail04.zma.compaq.com (zmamail04.zma.compaq.com [161.114.64.104]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g57AUhn21807 for <[e-mail]>; Fri, 7 Jun 2002 03:30:43 -0700 (PDT)
Received: from taynzmail03.nz-tay.cpqcorp.net (taynzmail03.nz-tay.cpqcorp.net [16.47.4.103]) by zmamail04.zma.compaq.com (Postfix) with ESMTP id F163D3B41 for <[e-mail]>; Fri,  7 Jun 2002 06:30:41 -0400 (EDT)
Received: from diexch01.xko.dec.com (diexch01.xko.dec.com [16.138.244.57]) by taynzmail03.nz-tay.cpqcorp.net (Postfix) with ESMTP id EA3C21678 for <[e-mail]>; Fri,  7 Jun 2002 06:30:34 -0400 (EDT)
Received: by diexch01.xko.dec.com with Internet Mail Service (5.5.2650.21) id <MMVSG7VY>; Fri, 7 Jun 2002 15:52:15 +0530
Message-ID: <[e-mail]>
From: "Muzumdar, Hari" <[e-mail]>
To: "'SMIME, IETF'" <[e-mail]>
Subject: Way of saying - 2.
Date: Fri, 7 Jun 2002 15:52:14 +0530 
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>

Two very basic questions, but I need confirmation.

In the context of X.400-transport and X.400-wrap:

1) When an X.400 UA receives a message, the CMS object in the message can 
   yield either a canonical MIME message or an X.400 Content (IPM/EDI/etc). 
   Is this correct?

2) By the same token, when an Internet MIME UA receives an S/MIME message, 
   the CMS object in the message can yield either a canonical MIME message 
   or an X.400 Content. 
   Is this correct?

Best Regards,
		Hari.


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g55KU3x03859 for ietf-smime-bks; Wed, 5 Jun 2002 13:30:03 -0700 (PDT)
Received: from nebula.x509.com ([199.175.150.19]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g55KU1n03854 for <[e-mail]>; Wed, 5 Jun 2002 13:30:01 -0700 (PDT)
Received: from crack.x509.com (mail.x509.com [199.175.150.1]) by nebula.x509.com (8.11.6/XCERT) with ESMTP id g55KTrg21510 for <[e-mail]>; Wed, 5 Jun 2002 13:29:53 -0700 (PDT)
Received: from exvan01.x509.com (exvan01.x509.com [10.9.22.50]) by crack.x509.com (8.11.6/XCERT) with ESMTP id g55KTq410387 for <[e-mail]>; Wed, 5 Jun 2002 13:29:53 -0700 (PDT)
Received: by exvan01.x509.com with Internet Mail Service (5.5.2653.19) id <MGZSLZHF>; Wed, 5 Jun 2002 13:33:42 -0700
Received: from HOUSLEY-LAP.rsasecurity.com (housley-lap.securitydynamics.com [10.100.79.199]) by exna00.securitydynamics.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id M28ZLHB1; Wed, 5 Jun 2002 16:29:42 -0400
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 5.1
Date: Wed, 05 Jun 2002 16:29:11 -0400
To: [e-mail]
From: "Housley, Russ" <[e-mail]>
Subject: 54th IETF Agenda
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 am in the process of putting together the agenda for the upcoming S/MIME 
WG session in Yokohama.  Please send me a note it you want a time 
slot.  The S/MIME WG has a two hour slot.

Russ


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g54IRWd04074 for ietf-smime-bks; Tue, 4 Jun 2002 11:27:32 -0700 (PDT)
Received: from motgate2.mot.com (motgate2.mot.com [136.182.1.10]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g54IRUg04068 for <[e-mail]>; Tue, 4 Jun 2002 11:27:30 -0700 (PDT)
Received: [from pobox4.mot.com ([10.64.251.243]) by motgate2.mot.com (motgate2 2.1) with ESMTP id LAA01616 for <[e-mail]>; Tue, 4 Jun 2002 11:27:33 -0700 (MST)]
Received: [from az33exm03.corp.mot.com (az33exm03.corp.mot.com [199.2.84.23]) by pobox4.mot.com (MOT-pobox4 2.0) with ESMTP id LAA13597 for <[e-mail]>; Tue, 4 Jun 2002 11:27:31 -0700 (MST)]
Received: by az33exm03.corp.mot.com with Internet Mail Service (5.5.2654.52) id <L8ANCP2W>; Tue, 4 Jun 2002 11:27:31 -0700
Message-ID: <[e-mail]>
From: Woodward Tim-P27399 <[e-mail]>
To: [e-mail]
Cc: Cuyugan Angelo-P29460 <[e-mail]>
Subject: S/MIME client
Date: Tue, 4 Jun 2002 11:27:30 -0700 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2654.52)
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>

Does anyone out there know of a good third-party S/MIME v2 or v3 compatible application that I can use off the shelf?  I just want to plug it in and go.

Thanks in advance!

Tim


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g54FJkJ23263 for ietf-smime-bks; Tue, 4 Jun 2002 08:19:46 -0700 (PDT)
Received: from vulcan.rsasecurity.com (mail.rsasecurity.com [204.167.114.123]) by above.proper.com (8.11.6/8.11.3) with SMTP id g54FJhg23257 for <[e-mail]>; Tue, 4 Jun 2002 08:19:43 -0700 (PDT)
Received: from no.name.available by vulcan.rsasecurity.com via smtpd (for mail.imc.org [208.184.76.43]) with SMTP; 4 Jun 2002 15:17:42 UT
Received: from ebola.securitydynamics.com (ebola.securid.com [192.80.211.4]) by sdtihq24.securid.com (Pro-8.9.3/Pro-8.9.3) with ESMTP id LAA21124 for <[e-mail]>; Tue, 4 Jun 2002 11:19:44 -0400 (EDT)
Received: from exna00.securitydynamics.com (localhost [127.0.0.1]) by ebola.securitydynamics.com (8.10.2+Sun/8.10.2) with ESMTP id g54FHmW07720 for <[e-mail]>; Tue, 4 Jun 2002 11:17:48 -0400 (EDT)
Received: by exna00.securitydynamics.com with Internet Mail Service (5.5.2653.19) id <M2T4ALTK>; Tue, 4 Jun 2002 11:19:41 -0400
Received: from HOUSLEY-LAP.rsasecurity.com (HOUSLEY-LAP [10.3.9.29]) by exna00.securitydynamics.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id M2T4ALT2; Tue, 4 Jun 2002 11:19:39 -0400
From: "Housley, Russ" <[e-mail]>
To: [e-mail]
Cc: [e-mail]
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 5.1
Date: Tue, 04 Jun 2002 09:56:01 -0400
Subject: Re: Compatibility between S/MIME v2 & v3 signatures
In-Reply-To: <[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>

Gwangsoo:

If you review the details of PKCS#1 v1.5, I think that you will see that 
the same structure as DigestInfo is used there.  This structure is not used 
by other digital signature techniques.

Russ

At 10:42 PM 6/4/2002 +0900, Gwangsoo Rhee wrote:
>Russ:
>
>Thanks for your answer.
>But, my question wasn't about the algorithm, but about
>what is to be encrypted by the signature algorithm like RSA.
>Does the RSA in S/MIME v3 (or RFC 2630) encrypt the DigestInfo
>which includes the digestAlgorithm, too?
>If so, why didn't RFC 2630 mention about it, or
>why did RFC 2630 leave out the DigestInfo structure?
>
>Thanks again.
>
>"Housley, Russ" wrote:
>
> > Gwangsoo:
> >
> > RFC 2315 only supports PKCS#1 v1.5 RSA signatures.  RFC 2630 and rfc2630bis
> > support any signature algorithm.  So, the more correct backward
> > compatibility statement is: RFC 2630 is backwards compatible with RFC 2315
> > when PKCS#1 v1.5 RSA signatures are used.
> >
> > Russ
> >
> > At 10:08 AM 6/4/2002 +0900, Gwangsoo Rhee wrote:
> >
> > >Hello, everybody.
> > >
> > >Many documents including draft-ietf-smime-rfc2630bis-08.txt
> > >claim that S/MIME v2 & v3 signatures are compatible, BUT:
> > >
> > >Sec. 9.4 of RFC 2315 (PKCS #7 v1.5) states about the signature
> > >generation:
> > >
> > >    The result of the
> > >    digest-encryption process is the encryption with the signer's private
> > >
> > >    key of the BER encoding of a value of type DigestInfo:
> > >
> > >    DigestInfo ::= SEQUENCE {
> > >      digestAlgorithm DigestAlgorithmIdentifier,
> > >      digest Digest }
> > >
> > >And sec. 5.5 of RFC 2630 (CMS) states:
> > >
> > >    The input to the signature generation process includes the result of
> > >    the message digest calculation process and the signer's private key.
> > >
> > >This RFC has no mention of DigestInfo structure.
> > >It seems to me that DigestAlgorithmIdentifier doesn't
> > >contribute to the signature generation, and in that case
> > >those two signatures cannot be compatible.
> > >
> > >Can anyone please point out where I got this wrong?
> > >
> > >Thanks.
> > >
> > >--
> > >
> > >---------------------------------------
> > >Gwangsoo Rhee <[e-mail]>
> > >tel: [phone]  fax: [phone]
> > >HP: 011-9691-9541
> > >---------------------------------------
>
>--
>
>---------------------------------------
>Gwangsoo Rhee <[e-mail]>
>tel: [phone]  fax: [phone]
>HP: 011-9691-9541
>---------------------------------------


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g54DhsC18670 for ietf-smime-bks; Tue, 4 Jun 2002 06:43:54 -0700 (PDT)
Received: from sookmyung.ac.kr ([203.252.201.133]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g54Dhqg18665 for <[e-mail]>; Tue, 4 Jun 2002 06:43:52 -0700 (PDT)
Received: from sookmyung.ac.kr (pc-rhee.sookmyung.ac.kr [203.252.195.65]) by cc.sookmyung.ac.kr (8.9.3/8.9.3) with ESMTP id WAA28259; Tue, 4 Jun 2002 22:39:06 +0900 (KST)
Message-ID: <[e-mail]>
Date: Tue, 04 Jun 2002 22:42:22 +0900
From: Gwangsoo Rhee <[e-mail]>
Reply-To: [e-mail]
X-Mailer: Mozilla 4.72 [en] (Win98; U)
X-Accept-Language: en
MIME-Version: 1.0
To: "Housley, Russ" <[e-mail]>
CC: [e-mail]
Subject: Re: Compatibility between S/MIME v2 & v3 signatures
References: <[e-mail]>
Content-Type: text/plain; charset=EUC-KR
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:

Thanks for your answer.
But, my question wasn't about the algorithm, but about
what is to be encrypted by the signature algorithm like RSA.
Does the RSA in S/MIME v3 (or RFC 2630) encrypt the DigestInfo
which includes the digestAlgorithm, too?
If so, why didn't RFC 2630 mention about it, or
why did RFC 2630 leave out the DigestInfo structure?

Thanks again.

"Housley, Russ" wrote:

> Gwangsoo:
>
> RFC 2315 only supports PKCS#1 v1.5 RSA signatures.  RFC 2630 and rfc2630bis
> support any signature algorithm.  So, the more correct backward
> compatibility statement is: RFC 2630 is backwards compatible with RFC 2315
> when PKCS#1 v1.5 RSA signatures are used.
>
> Russ
>
> At 10:08 AM 6/4/2002 +0900, Gwangsoo Rhee wrote:
>
> >Hello, everybody.
> >
> >Many documents including draft-ietf-smime-rfc2630bis-08.txt
> >claim that S/MIME v2 & v3 signatures are compatible, BUT:
> >
> >Sec. 9.4 of RFC 2315 (PKCS #7 v1.5) states about the signature
> >generation:
> >
> >    The result of the
> >    digest-encryption process is the encryption with the signer's private
> >
> >    key of the BER encoding of a value of type DigestInfo:
> >
> >    DigestInfo ::= SEQUENCE {
> >      digestAlgorithm DigestAlgorithmIdentifier,
> >      digest Digest }
> >
> >And sec. 5.5 of RFC 2630 (CMS) states:
> >
> >    The input to the signature generation process includes the result of
> >    the message digest calculation process and the signer's private key.
> >
> >This RFC has no mention of DigestInfo structure.
> >It seems to me that DigestAlgorithmIdentifier doesn't
> >contribute to the signature generation, and in that case
> >those two signatures cannot be compatible.
> >
> >Can anyone please point out where I got this wrong?
> >
> >Thanks.
> >
> >--
> >
> >---------------------------------------
> >Gwangsoo Rhee <[e-mail]>
> >tel: [phone]  fax: [phone]
> >HP: 011-9691-9541
> >---------------------------------------

--

---------------------------------------
Gwangsoo Rhee <[e-mail]>
tel: [phone]  fax: [phone]
HP: 011-9691-9541
---------------------------------------




Received: by above.proper.com (8.11.6/8.11.3) id g54CZ3j12851 for ietf-smime-bks; Tue, 4 Jun 2002 05:35:03 -0700 (PDT)
Received: from vulcan.rsasecurity.com (mail.rsasecurity.com [204.167.114.123]) by above.proper.com (8.11.6/8.11.3) with SMTP id g54CZ1g12847 for <[e-mail]>; Tue, 4 Jun 2002 05:35:01 -0700 (PDT)
Received: from no.name.available by vulcan.rsasecurity.com via smtpd (for mail.imc.org [208.184.76.43]) with SMTP; 4 Jun 2002 12:32:59 UT
Received: from ebola.securitydynamics.com (ebola.securid.com [192.80.211.4]) by sdtihq24.securid.com (Pro-8.9.3/Pro-8.9.3) with ESMTP id IAA12807 for <[e-mail]>; Tue, 4 Jun 2002 08:35:01 -0400 (EDT)
Received: from exna00.securitydynamics.com (localhost [127.0.0.1]) by ebola.securitydynamics.com (8.10.2+Sun/8.10.2) with ESMTP id g54CX5v25148 for <[e-mail]>; Tue, 4 Jun 2002 08:33:06 -0400 (EDT)
Received: by exna00.securitydynamics.com with Internet Mail Service (5.5.2653.19) id <MHPF6ZGH>; Tue, 4 Jun 2002 08:34:59 -0400
Received: from HOUSLEY-LAP.rsasecurity.com (HOUSLEY-LAP [10.3.9.13]) by exna00.securitydynamics.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id MHPF6ZGC; Tue, 4 Jun 2002 08:34:52 -0400
From: "Housley, Russ" <[e-mail]>
To: [e-mail]
Cc: [e-mail]
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 5.1
Date: Tue, 04 Jun 2002 08:30:43 -0400
Subject: Re: Compatibility between S/MIME v2 & v3 signatures
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>

Gwangsoo:

RFC 2315 only supports PKCS#1 v1.5 RSA signatures.  RFC 2630 and rfc2630bis 
support any signature algorithm.  So, the more correct backward 
compatibility statement is: RFC 2630 is backwards compatible with RFC 2315 
when PKCS#1 v1.5 RSA signatures are used.

Russ

At 10:08 AM 6/4/2002 +0900, Gwangsoo Rhee wrote:

>Hello, everybody.
>
>Many documents including draft-ietf-smime-rfc2630bis-08.txt
>claim that S/MIME v2 & v3 signatures are compatible, BUT:
>
>Sec. 9.4 of RFC 2315 (PKCS #7 v1.5) states about the signature
>generation:
>
>    The result of the
>    digest-encryption process is the encryption with the signer's private
>
>    key of the BER encoding of a value of type DigestInfo:
>
>    DigestInfo ::= SEQUENCE {
>      digestAlgorithm DigestAlgorithmIdentifier,
>      digest Digest }
>
>And sec. 5.5 of RFC 2630 (CMS) states:
>
>    The input to the signature generation process includes the result of
>    the message digest calculation process and the signer's private key.
>
>This RFC has no mention of DigestInfo structure.
>It seems to me that DigestAlgorithmIdentifier doesn't
>contribute to the signature generation, and in that case
>those two signatures cannot be compatible.
>
>Can anyone please point out where I got this wrong?
>
>Thanks.
>
>--
>
>---------------------------------------
>Gwangsoo Rhee <[e-mail]>
>tel: [phone]  fax: [phone]
>HP: 011-9691-9541
>---------------------------------------


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g541Beh22789 for ietf-smime-bks; Mon, 3 Jun 2002 18:11:40 -0700 (PDT)
Received: from sookmyung.ac.kr ([203.252.201.133]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g541Bag22774 for <[e-mail]>; Mon, 3 Jun 2002 18:11:36 -0700 (PDT)
Received: from sookmyung.ac.kr (pc-rhee.sookmyung.ac.kr [203.252.195.65]) by cc.sookmyung.ac.kr (8.9.3/8.9.3) with ESMTP id KAA13256 for <[e-mail]>; Tue, 4 Jun 2002 10:05:19 +0900 (KST)
Message-ID: <[e-mail]>
Date: Tue, 04 Jun 2002 10:08:37 +0900
From: Gwangsoo Rhee <[e-mail]>
Reply-To: [e-mail]
X-Mailer: Mozilla 4.72 [en] (Win98; U)
X-Accept-Language: en
MIME-Version: 1.0
To: [e-mail]
Subject: Compatibility between S/MIME v2 & v3 signatures
Content-Type: text/plain; charset=EUC-KR
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, everybody.

Many documents including draft-ietf-smime-rfc2630bis-08.txt
claim that S/MIME v2 & v3 signatures are compatible, BUT:

Sec. 9.4 of RFC 2315 (PKCS #7 v1.5) states about the signature
generation:

   The result of the
   digest-encryption process is the encryption with the signer's private

   key of the BER encoding of a value of type DigestInfo:

   DigestInfo ::= SEQUENCE {
     digestAlgorithm DigestAlgorithmIdentifier,
     digest Digest }

And sec. 5.5 of RFC 2630 (CMS) states:

   The input to the signature generation process includes the result of
   the message digest calculation process and the signer's private key.

This RFC has no mention of DigestInfo structure.
It seems to me that DigestAlgorithmIdentifier doesn't
contribute to the signature generation, and in that case
those two signatures cannot be compatible.

Can anyone please point out where I got this wrong?

Thanks.

--

---------------------------------------
Gwangsoo Rhee <[e-mail]>
tel: [phone]  fax: [phone]
HP: 011-9691-9541
---------------------------------------