Subject: Protocol Action: Cryptographic Message Syntax to Proposed Standard

From: The IESG <[email-masked]>
Date: Wed, 26 Jun 2002 15:20:41 -0400

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.

To: IETF-Announce: ;
Cc: RFC Editor <[email-masked]>, Internet Architecture Board <[email-masked]>, [email-masked]
From: The IESG <[email-masked]>
Subject: Protocol Action: Cryptographic Message Syntax to Proposed Standard
Date: Wed, 26 Jun 2002 15:20:41 -0400
Sender: [email-masked]

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.

Date: Mon, 24 Jun 2002 11:42:59 -0400
To: [email-masked]
From: "Housley, Russ" <[email-masked]>
Subject: S/MIME WG Agenda for Yokohama
Sender: [email-masked]

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

To: IETF-Announce: ;
Cc: [email-masked]
From: The IESG <[email-masked]>
SUBJECT: Last Call: CMS Symmetric Key Management and Distribution to  Proposed Standard
Reply-to: [email-masked]
Date: Tue, 18 Jun 2002 14:28:56 -0400
Sender: [email-masked]

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 
[email-masked] or [email-masked] mailing lists by July 2, 2002.

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

To: IETF-Announce: ;
Cc: [email-masked]
From: [email-masked]
Reply-to: [email-masked]
Subject: I-D ACTION:draft-ietf-smime-cms-rsaes-oaep-03.txt
Date: Fri, 14 Jun 2002 07:31:02 -0400
Sender: [email-masked]

--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:
	[email-masked].
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="[email-masked]"

Content-Type: text/plain
Content-ID:	<[email-masked]>

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:	<[email-masked]>

--OtherAccess--

--NextPart--

From: "Bonatti, Chris" <[email-masked]>
To: <[email-masked]>
Cc: "'SMIME, IETF'" <[email-masked]>
Subject: RE: Way of saying - 2.
Date: Thu, 13 Jun 2002 19:17:23 -0400
Importance: Normal
Sender: [email-masked]

Muzumdar, Hari <[email-masked]> 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

To: IETF-Announce: ;
Subject: RFC 3274 on Compressed Data Content Type for Cryptographic Message Syntax (CMS)
Cc: [email-masked], [email-masked]
Date: Tue, 11 Jun 2002 14:18:50 -0700
From: RFC Editor <[email-masked]>
Sender: [email-masked]

--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:    [email-masked]
        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 [email-masked].  Requests to be
added to or deleted from the RFC-DIST distribution list should
be sent to [email-masked].

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

        To: [email-masked]
        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 [email-masked].  Unless
specifically noted otherwise on the RFC itself, all RFCs are for
unlimited distribution.echo 
Submissions for Requests for Comments should be sent to
[email-masked].  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="[email-masked]"

Content-Type: text/plain
Content-ID: <[email-masked]>

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: <[email-masked]>

--OtherAccess--
--NextPart--

Date: Sat, 8 Jun 2002 14:30:19 +1200 (NZST)
From: [email-masked] (Peter Gutmann)
To: [email-masked], [email-masked]
Subject: Updated version of dumpasn1 available
Sender: [email-masked]

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.

From: "Muzumdar, Hari" <[email-masked]>
To: "'SMIME, IETF'" <[email-masked]>
Subject: Way of saying - 2.
Date: Fri, 7 Jun 2002 15:52:14 +0530 
Sender: [email-masked]

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.

Date: Wed, 05 Jun 2002 16:29:11 -0400
To: [email-masked]
From: "Housley, Russ" <[email-masked]>
Subject: 54th IETF Agenda
Sender: [email-masked]

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

From: Woodward Tim-P27399 <[email-masked]>
To: [email-masked]
Cc: Cuyugan Angelo-P29460 <[email-masked]>
Subject: S/MIME client
Date: Tue, 4 Jun 2002 11:27:30 -0700 
Sender: [email-masked]

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

From: "Housley, Russ" <[email-masked]>
To: [email-masked]
Cc: [email-masked]
Date: Tue, 04 Jun 2002 09:56:01 -0400
Subject: Re: Compatibility between S/MIME v2 & v3 signatures
Sender: [email-masked]

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 <[email-masked]>
> > >tel: +82-2-710-9429  fax: 710-9296
> > >HP: 011-9691-9541
> > >---------------------------------------
>
>--
>
>---------------------------------------
>Gwangsoo Rhee <[email-masked]>
>tel: +82-2-710-9429  fax: 710-9296
>HP: 011-9691-9541
>---------------------------------------

Date: Tue, 04 Jun 2002 22:42:22 +0900
From: Gwangsoo Rhee <[email-masked]>
Reply-To: [email-masked]
To: "Housley, Russ" <[email-masked]>
CC: [email-masked]
Subject: Re: Compatibility between S/MIME v2 & v3 signatures
Sender: [email-masked]

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 <[email-masked]>
> >tel: +82-2-710-9429  fax: 710-9296
> >HP: 011-9691-9541
> >---------------------------------------

--

---------------------------------------
Gwangsoo Rhee <[email-masked]>
tel: +82-2-710-9429  fax: 710-9296
HP: 011-9691-9541
---------------------------------------

From: "Housley, Russ" <[email-masked]>
To: [email-masked]
Cc: [email-masked]
Date: Tue, 04 Jun 2002 08:30:43 -0400
Subject: Re: Compatibility between S/MIME v2 & v3 signatures
Sender: [email-masked]

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 <[email-masked]>
>tel: +82-2-710-9429  fax: 710-9296
>HP: 011-9691-9541
>---------------------------------------

Date: Tue, 04 Jun 2002 10:08:37 +0900
From: Gwangsoo Rhee <[email-masked]>
Reply-To: [email-masked]
To: [email-masked]
Subject: Compatibility between S/MIME v2 & v3 signatures
Sender: [email-masked]

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 <[email-masked]>
tel: +82-2-710-9429  fax: 710-9296
HP: 011-9691-9541
---------------------------------------