Re: WG Last Call: rfc2630bis and cmsalg

["Housley, Russ" <[e-mail]>]

S/MIME WG:

I just sent in rfc2630bis-05 and cmsalg-06 to the Internet-Draft 
repository.  They should appear soon.  These incorporate all of the 
comments that were received during WG Last Call.  All of the comments were 
minor, so I am confident that these documents are finished.  As soon as 
they appear, I will send a note to the Security Area Directors letting them 
know that the working group is finished with them.

Thanks for all of the good work!

Russ



Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id f8SKZj727066 for ietf-smime-bks; Fri, 28 Sep 2001 13:35:45 -0700 (PDT)
Received: from nebula.x509.com (nebula.x509.com [199.175.150.19]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f8SKZhD27062 for <[e-mail]>; Fri, 28 Sep 2001 13:35:43 -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 f8SKZcW28015 for <[e-mail]>; Fri, 28 Sep 2001 13:35:38 -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 f8SKZc923574 for <[e-mail]>; Fri, 28 Sep 2001 13:35:38 -0700 (PDT)
Received: by exvan01.x509.com with Internet Mail Service (5.5.2653.19) id <TDHNTFRW>; Fri, 28 Sep 2001 13:37:07 -0700
Received: from HOUSLEY-LAP.rsasecurity.com (HOUSLEY-LAP [10.3.1.79]) by exna00.securitydynamics.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id T1DQR8H2; Fri, 28 Sep 2001 16:35:25 -0400
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 5.0.1
Date: Fri, 28 Sep 2001 16:35:22 -0400
To: [e-mail]
From: "Housley, Russ" <[e-mail]>
Subject: Re: WG Last Call: rfc2630bis and cmsalg
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>

S/MIME WG:

I just sent in rfc2630bis-05 and cmsalg-06 to the Internet-Draft 
repository.  They should appear soon.  These incorporate all of the 
comments that were received during WG Last Call.  All of the comments were 
minor, so I am confident that these documents are finished.  As soon as 
they appear, I will send a note to the Security Area Directors letting them 
know that the working group is finished with them.

Thanks for all of the good work!

Russ


Received: by above.proper.com (8.11.6/8.11.3) id f8RB0NC06961 for ietf-smime-bks; Thu, 27 Sep 2001 04:00:23 -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 f8RB0KD06947 for <[e-mail]>; Thu, 27 Sep 2001 04:00:20 -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 HAA25689; Thu, 27 Sep 2001 07:00:18 -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-ira-00.txt
Date: Thu, 27 Sep 2001 07:00:18 -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		: Intended Recipients Attribute for the Cryptographic 
                          Message Syntax (CMS)
	Author(s)	: R. Housley
	Filename	: draft-ietf-smime-ira-00.txt
	Pages		: 6
	Date		: 26-Sep-01
	
This document describes the intended recipients attribute for use
with the Cryptographic Message Syntax (CMS) [CMS].  The intended
recipients attribute can be used as a signed attribute or as an
authenticated attribute.
This draft is being discussed on the 'ietf-smime' mailing list.  To
join the list, send a message to <[e-mail]> with
the single word 'subscribe' in the body of the message.  Also, there
is a Web site for the mailing list at <http://www.imc.org/ietf-
smime/>.

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

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


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

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

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

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

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

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

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

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

--OtherAccess--

--NextPart--




Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id f8PECuT05898 for ietf-smime-bks; Tue, 25 Sep 2001 07:12:56 -0700 (PDT)
Received: from tholian.securitydynamics.com (mail.rsasecurity.com [204.167.112.129]) by above.proper.com (8.11.6/8.11.3) with SMTP id f8PECsD05894 for <[e-mail]>; Tue, 25 Sep 2001 07:12:54 -0700 (PDT)
Received: from sdtihq24.securid.com by tholian.securitydynamics.com via smtpd (for mail.imc.org [208.184.76.43]) with SMTP; 25 Sep 2001 14:09:57 UT
Received: from ebola.securitydynamics.com (ebola.securid.com [192.168.7.4]) by sdtihq24.securid.com (Pro-8.9.3/Pro-8.9.3) with ESMTP id KAA26017 for <[e-mail]>; Tue, 25 Sep 2001 10:12:55 -0400 (EDT)
Received: from exno02.dynas.se (localhost [127.0.0.1]) by ebola.securitydynamics.com (8.9.3+Sun/8.9.1) with ESMTP id KAA07238 for <[e-mail]>; Tue, 25 Sep 2001 10:12:54 -0400 (EDT)
Received: by exno02.dynas.se with Internet Mail Service (5.5.2653.19) id <TTNJSBQS>; Tue, 25 Sep 2001 16:13:22 +0200
Received: from HOUSLEY-LAP.rsasecurity.com (HOUSLEY-LAP [10.3.1.38]) by exna00.securitydynamics.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id T1DQP90P; Tue, 25 Sep 2001 10:12:49 -0400
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 5.0.1
Date: Tue, 25 Sep 2001 10:12:00 -0400
To: [e-mail]
From: "Housley, Russ" <[e-mail]>
Subject: WG Last Call: draft-ietf-smime-pkcs1-01.txt
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 document that describes countermeasures to the Million Message Attack 
(MMA) for CMS implementations that support PKCS #1 v1.5 is ready for WG 
Last Call.  We plan to publish this document as an Informational 
RFC.  Please post all comments to the S/MIME WG mail list by 10 October 2001.

	Title		: Preventing the Million Message Attack on CMS
	Author(s)	: E. Rescorla
	Filename	: draft-ietf-smime-pkcs1-01.txt
	Pages		: 5
	Date		: 24-Sep-01
	
A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-smime-pkcs1-01.txt

Russ 


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id f8PB1mW02299 for ietf-smime-bks; Tue, 25 Sep 2001 04:01:48 -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 f8PB1kD02294 for <[e-mail]>; Tue, 25 Sep 2001 04:01:46 -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 HAA27112; Tue, 25 Sep 2001 07:01:43 -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-pkcs1-01.txt
Date: Tue, 25 Sep 2001 07:01:42 -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		: Preventing the Million Message Attack on CMS
	Author(s)	: E. Rescorla
	Filename	: draft-ietf-smime-pkcs1-01.txt
	Pages		: 5
	Date		: 24-Sep-01
	
When data is encrypted using RSA it must be padded out to the length
of the modulus--typically 512 to 2048 bits.  The most popular tech-
nique for doing this is described in [PKCS-1-v1.5]. However, in 1998
Bleichenbacher described an adaptive chosen ciphertext attack on SSL
[MMA].

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

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

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 f8OHgdV13491 for ietf-smime-bks; Mon, 24 Sep 2001 10:42:39 -0700 (PDT)
Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f8OHgbD13485 for <[e-mail]>; Mon, 24 Sep 2001 10:42:37 -0700 (PDT)
Received: from ISI.EDU (jet.isi.edu [128.9.160.87]) by boreas.isi.edu (8.11.6/8.11.2) with ESMTP id f8OHgZC20677; Mon, 24 Sep 2001 10:42:35 -0700 (PDT)
Message-Id: <[e-mail]>
To: IETF-Announce: ;
Subject: RFC 3126 on Electronic Signature Formats
Cc: [e-mail], [e-mail]
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary=NextPart
Date: Mon, 24 Sep 2001 10:42:35 -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 3126

        Title:	    Electronic Signature Formats for long term
                    electronic signatures
        Author(s):  D. Pinkas, J. Ross, N. Pope
        Status:     Informational
	Date:       September 2001
        Mailbox:    [e-mail], Denis.Pinkas @bull.net,
                    [e-mail], [e-mail]
        Pages:      84
        Characters: 175886
        Updates/Obsoletes/SeeAlso:    None

        I-D Tag:    draft-ietf-smime-esformats-03.txt

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


This document defines the format of an electronic signature that can
remain valid over long periods.  This includes evidence as to its
validity even if the signer or verifying party later attempts to deny
(i.e., repudiates the validity of the signature).
 
The format can be considered as an extension to RFC 2630 and RFC 2634,
where, when appropriate additional signed and unsigned attributes have
been defined.
 
The contents of this Informational RFC is technically equivalent to
ETSI TS 101 733 V.1.2.2. The ETSI TS is under the ETSI Copyright (C).
Individual copies of this ETSI deliverable can be downloaded from
http://www.etsi.org

This document is a product of the S/MIME Mail Security Working Group
of the IETF.

This memo provides information for the Internet community.  It does
not specify an Internet standard of any kind.  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: rfc3126

--OtherAccess
Content-Type:   Message/External-body;
        name="rfc3126.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 f8OHNxf13196 for ietf-smime-bks; Mon, 24 Sep 2001 10:23:59 -0700 (PDT)
Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f8OHNwD13192 for <[e-mail]>; Mon, 24 Sep 2001 10:23:58 -0700 (PDT)
Received: from ISI.EDU (jet.isi.edu [128.9.160.87]) by boreas.isi.edu (8.11.6/8.11.2) with ESMTP id f8OHNrC15444; Mon, 24 Sep 2001 10:23:53 -0700 (PDT)
Message-Id: <[e-mail]>
To: IETF-Announce: ;
Subject: RFC 3125 on Electronic Signature Policies
Cc: [e-mail], [e-mail]
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary=NextPart
Date: Mon, 24 Sep 2001 10:23:52 -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 3125

        Title:	    Electronic Signature Policies
        Author(s):  J. Ross, D. Pinkas, N. Pope
        Status:     Experimental
	Date:       September 2001
        Mailbox:    [e-mail], [e-mail],
                    [e-mail] 
        Pages:      43
        Characters: 95505
        Updates/Obsoletes/SeeAlso:    None

        I-D Tag:    draft-ietf-smime-espolicies-00.txt

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


This document defines signature policies for electronic signatures.
A signature policy is a set of rules for the creation and validation
of an electronic signature, under which the validity of signature can
be determined.  A given legal/contractual context may recognize a
particular signature policy as meeting its requirements.
 
A signature policy has a globally unique reference, which is bound to
an electronic signature by the signer as part of the signature
calculation.
 
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.
 
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.  In the current document the format of
the signature policy is defined using ASN.1.
 
The contents of this document is based on the signature policy defined
in ETSI TS 101 733 V.1.2.2 (2000-12) Copyright (C).  Individual copies
of this ETSI deliverable can be downloaded from http://www.etsi.org.

This document is a product of the S/MIME Mail Security Working Group
of the IETF.

This memo defines an Experimental Protocol for the Internet community.
It does not specify an Internet standard of any kind.  Discussion and
suggestions for improvement are requested.  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: rfc3125

--OtherAccess
Content-Type:   Message/External-body;
        name="rfc3125.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 f8LDfq201196 for ietf-smime-bks; Fri, 21 Sep 2001 06:41:52 -0700 (PDT)
Received: from mail.eris.dera.gov.uk (ns0.eris.dera.gov.uk [128.98.1.1]) by above.proper.com (8.11.6/8.11.3) with SMTP id f8LDfoD01188 for <[e-mail]>; Fri, 21 Sep 2001 06:41:50 -0700 (PDT)
Received: (qmail 23990 invoked from network); 21 Sep 2001 13:41:30 -0000
Received: from cray.eris.dera.gov.uk (HELO mailhost.eris.dera.gov.uk) (128.98.2.7) by ens0.eris.dera.gov.uk with SMTP; 21 Sep 2001 13:41:30 -0000
Received: (qmail 32742 invoked from network); 21 Sep 2001 13:41:29 -0000
Received: from wottaway.eris.dera.gov.uk (HELO WOTTAWAY) (128.98.10.192) by mailhost.eris.dera.gov.uk with SMTP; 21 Sep 2001 13:41:29 -0000
From: "William Ottaway" <[e-mail]>
To: <[e-mail]>
Cc: <[e-mail]>
Subject: DOMSEC and S/MIME Gateway Protocol comparison
Date: Fri, 21 Sep 2001 14:41:59 +0100
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.00.2919.6600
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>

At the S/MIME WG meeting in London I was tasked to provide a comparison
between DOMSEC and the S/MIME Gateway Protocol
(draft-ramsdell-enc-smime-gateway-00.txt) in order to start a discussion on
whether the gateway draft should be progressed and if so how would it relate
to DOMSEC.


DOMSEC Summary: -

1) Encryption/Decryption and signing.

2) Defines naming conventions.

3) Defines signature types.

4) Defines membership of a domain.

5) Defines rules for domain signature generation and verification.

6) States how domain encryption/decryption is achieved.

7) Defines domain signature application rules when sending to mail list
agents.


Gateway Summary: -

1) Encryption/Decryption only.

2) Uses same notation of domain "membership" as DOMSEC.

3) Introduces its own naming convention for the encrypting entities domain
certificate,    smg_encryptor@domain. DOMSEC defines
domain-confidentiality-authority@domain.

4) Introduces a mechanism for identifying multiple domains handled by the
gateway. They can be listed in a single certificate or in multiple
certificates.

5) Introduces a rule for deciding which recipient domain certificate must be
used.

6) Introduces a rule on how the gateway recognises that a message requires
encryption (encrypt if have a certificate for the recipients domain).

7) Introduces a rule on when the gateway should decrypt a message (when the
gateways public key has been used to encrypt)


My view: -

DOMSEC defines mechanisms for domain signing and encrypting with out
specifying mechanisms or rules that are deemed local to the installation. It
is hoped that domain signing and encryption implementations will be
compliant with DOMSEC. It is expected that individual installations will
provide extra local mechanisms and rules in support of DOMSEC, for example
how to decide on which certificate to use, how to decide on whether
encryption is required, how certificates are retrieved, whether a domain
signature is stripped off before forwarding to the local recipient, whether
encryption between the domain boundary and the local recipient is required,
etc.

The Gateway draft defines mechanisms that are already defined in DOMSEC,
such as encryption and naming notation. It also defines mechanisms that may
differ between implementations, such as domains that are handled by the
gateway may be listed in a single or multiple certificate and rules on which
recipient certificate to use when encrypting.

I propose that the Gateway draft should be a profile of DOMSEC. Therefore,
it should support encryption/decryption as specified in DOMSEC and the
DOMSEC naming convention. The Gateway draft would contain those features
local to this implementation such as points 4 - 7 in the gateway summary.

Bill
____________________________________________________
 William Ottaway BSc Hons CEng MBCS,
 Woodward B009,
 QinetiQ                      Tel: [phone]
 Malvern Technology Centre,   Fax: [phone]
 St. Andrews Road,            email: [e-mail]
 Malvern,
 Worcs,
 WR14 3PS

 All opinions are my own.




Received: by above.proper.com (8.11.6/8.11.3) id f8KDCYC07345 for ietf-smime-bks; Thu, 20 Sep 2001 06:12:34 -0700 (PDT)
Received: from [203.46.112.10] (mail.rsasecurity.com.au [203.46.112.10]) by above.proper.com (8.11.6/8.11.3) with SMTP id f8KDCUD07336 for <[e-mail]>; Thu, 20 Sep 2001 06:12:30 -0700 (PDT)
Received: from [192.168.18.3] by [203.46.112.10] via smtpd (for [208.184.76.43]) with SMTP; 8 Mar 2001 08:13:32 UT
Received: from exaus01.local.aus.rsa.com (exaus01.local.aus.rsa.com [10.177.1.15]) by grover.local.aus.rsa.com (8.10.2/8.10.2) with ESMTP id f8KDFhq11312 for <[e-mail]>; Thu, 20 Sep 2001 23:15:43 +1000 (EST)
Received: by exaus01.local.aus.rsa.com with Internet Mail Service (5.5.2653.19) id <SJYJPYWG>; Thu, 20 Sep 2001 23:04:25 +1000
Received: from HOUSLEY-LAP.rsasecurity.com (HOUSLEY-LAP [10.3.1.114]) by exna00.securitydynamics.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id T1DQ3AX4; Thu, 20 Sep 2001 09:11:25 -0400
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 5.0.1
Date: Thu, 20 Sep 2001 09:10:36 -0400
To: [e-mail]
From: "Housley, Russ" <[e-mail]>
Subject: Re: WG Last Call: rfc2630bis and cmsalg
In-Reply-To: <[e-mail]. 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>

The CMS update has been in WG Last Call since Thursday, 16 August 
2001.  Many good comments have been raised, and the documents have been 
updated to resolve these issues.  I am extending WG Last Call to give 
everyone a chance to read and comment on these updates.  Please post all 
comments on both documents to the S/MIME WG mail list by Thursday, 27 
September 2001.

	Title		: Cryptographic Message Syntax
	Author(s)	: R. Housley
	Filename	: draft-ietf-smime-rfc2630bis-04.txt
	Pages		: 53
	Date		: 19-Sep-01

	Title		: Cryptographic Message Syntax (CMS) Algorithms
	Author(s)	: R. Housley
	Filename	: draft-ietf-smime-cmsalg-05.txt
	Pages		: 23
	Date		: 19-Sep-01

Russ


Received: by above.proper.com (8.11.6/8.11.3) id f8KB7jN29835 for ietf-smime-bks; Thu, 20 Sep 2001 04:07:45 -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 f8KB7iD29831 for <[e-mail]>; Thu, 20 Sep 2001 04:07:44 -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 HAA05426; Thu, 20 Sep 2001 07:08:22 -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-rfc2630bis-04.txt
Date: Thu, 20 Sep 2001 07:08:22 -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		: Cryptographic Message Syntax
	Author(s)	: R. Housley
	Filename	: draft-ietf-smime-rfc2630bis-04.txt
	Pages		: 53
	Date		: 19-Sep-01
	
This document describes the Cryptographic Message Syntax (CMS).  This
syntax is used to digitally sign, digest, authenticate, or encrypt
arbitrary messages.

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

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-smime-rfc2630bis-04.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 f8KB78C29825 for ietf-smime-bks; Thu, 20 Sep 2001 04:07:08 -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 f8KB77D29819 for <[e-mail]>; Thu, 20 Sep 2001 04:07:07 -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 HAA05343; Thu, 20 Sep 2001 07:07:45 -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-cmsalg-05.txt
Date: Thu, 20 Sep 2001 07:07:44 -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		: Cryptographic Message Syntax (CMS) Algorithms
	Author(s)	: R. Housley
	Filename	: draft-ietf-smime-cmsalg-05.txt
	Pages		: 23
	Date		: 19-Sep-01
	
This document describes several cryptographic algorithms for use with
the Cryptographic Message Syntax (CMS) [CMS].  CMS is used to
digitally sign, digest, authenticate, or encrypt arbitrary messages.

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

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

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 f8K3mSD21310 for ietf-smime-bks; Wed, 19 Sep 2001 20:48:28 -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 f8K3mRD21306 for <[e-mail]>; Wed, 19 Sep 2001 20:48:27 -0700 (PDT)
Received: by zmamail04.zma.compaq.com (Postfix, from userid 12345) id 0A180567E; Wed, 19 Sep 2001 23:48:26 -0400 (EDT)
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 5A715549E; Wed, 19 Sep 2001 23:48:24 -0400 (EDT)
Received: by taynzmail03.nz-tay.cpqcorp.net (Postfix, from userid 12345) id 1BC6714A3; Wed, 19 Sep 2001 23:48:24 -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 2E5DD16F2; Wed, 19 Sep 2001 23:48:21 -0400 (EDT)
Received: by diexch01.xko.dec.com with Internet Mail Service (5.5.2650.21) id <THN0Q1P8>; Thu, 20 Sep 2001 09:11:41 +0530
Message-ID: <[e-mail]>
From: "Hegde, Vijaykumar" <[e-mail]>
To: "Bonatti, Chris" <[e-mail]>, [e-mail]
Subject: FW: S/MIME and X.400
Date: Thu, 20 Sep 2001 09:11:40 +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>

Hi,

I currently use XAPI to build X.400 messages. How do I plug in a CMS object
in the  X.400 message using XAPI ?? ( i think its not possible at this
time).  I have listed the sequence of calls one would use to create an IPM
using XAPI. What could be the possible sequence of om_create,om_put calls
for creating s/mime messages ? 

|------------------------------------------------------------------------|
|            IPM                     |    	S/MIME Message           |
|------------------------------------|-----------------------------------|
|OM_CREATE (MH_C_SUBMITTED_MESSAGE)	 |OM_CREATE (MH_C_SUBMITTED_MESSAGE)
|           
|------------------------------------|-----------------------------------|
|OM_CREATE(IPM_CONTENT)	             |binary content ??                  |
|------------------------------------|-----------------------------------|
|OM_PUT(IM_BODY into CONTENT)        |how to plug-in CMS into content ?  |

|------------------------------------|-----------------------------------|
|OM_PUT(IM_C_CONTENT into MESSAGE)   |how to plug in binary content      |
|                                    | into message                      |
|------------------------------------------------------------------------|


Thanks,
Vijay Hegde

----------------------------------------------------------------------------



-----Original Message-----
From: Bonatti, Chris [mailto:[e-mail]]
Sent: Thursday, September 13, 2001 5:31 PM
To: Hegde, Vijaykumar
Cc: [e-mail]
Subject: RE: S/MIME and X.400



Hi Vijay,

	You should see the I-Ds draft-ietf-smime-x400wrap-04 and
draft-ietf-smime-x400transport-03.  In brief, x400wrap describes wrapping
X.400 content types inside a CMS object, and x400transport describes
conveying a CMS object over an X.400 transport system as an X.400 content
type itself.  Except in the case of a forwarded message, CMS objects are not
embedded in X.400 content.

	In ASN.1 terms, a CMS 'ContentInfo' object is plugged into the X.400
'content' field in X.411.  The content is identified in the 'content-type'
field by either of the following OID values depending upon whether or not it
is MIME encoded.

	id-data OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840)
	rsadsi(113549) pkcs(1) pkcs7(7) 1 }

	id-ct-contentInfo  OBJECT IDENTIFIER ::= { iso(1) member-body(2)
	us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16)
	content-types(1) 6}

The x400wrap draft mainly specifies some specific uses of options in CMS
appropriate to X.400 content.

	Plz let me know if I can answer any more questions.

Chris B.



 ---------------------------------------------------------------
 |  International Electronic Communication Analysts, Inc.      |
 |  Christopher D. Bonatti             15309 Turkey Foot Road  |
 |  Principal Engineer              Darnestown, Md 20878-3640  |
 |  [e-mail]   Tel: [phone]   Fax: [phone]  |
 ---------------------------------------------------------------

-----Original Message-----
From: [e-mail]
[mailto:[e-mail]]On Behalf Of Hegde, Vijaykumar
Sent: Tuesday, September 11, 2001 03:04
To: [e-mail]
Subject: S/MIME and X.400



Hello,
	
	I have an application where in I have to build an X.400 message. The
"Content" of the message would be a CMS object. How do I insert a CMS object
into the  X.400 Content ?
	alternatively,  How will such a message look like in ASN.1 form ? 


Thanks in advance,
Vijay Hegde


Received: by above.proper.com (8.11.6/8.11.3) id f8JKhqj10065 for ietf-smime-bks; Wed, 19 Sep 2001 13:43:52 -0700 (PDT)
Received: from wfhqex05.gfgsi.com (netva01.getronicsgov.com [206.137.100.2]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f8JKhpD10061 for <[e-mail]>; Wed, 19 Sep 2001 13:43:51 -0700 (PDT)
Received: by wfhqex05.gfgsi.com with Internet Mail Service (5.5.2653.19) id <R052Y4BL>; Wed, 19 Sep 2001 16:43:58 -0400
Message-ID: <[e-mail]>
From: "Pawling, John" <[e-mail]>
To: "'[e-mail]'" <[e-mail]>, "'Housley, Russ'" <[e-mail]>
Cc: [e-mail]
Subject: RE: Comments on draft-ietf-smime-rfc2630bis-03
Date: Wed, 19 Sep 2001 16:43:57 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
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>

Jim,

> However, if an
>     RFC 2634 signed receipt is encapsulated in the PKCS #7 signedData
>     type, then the Receipt SEQUENCE is DER encoded [X.509-88] in the
>     SignedData contentInfo content ANY field (a SEQUENCE, not an OCTET
>     STRING).  Therefore, the message digest is computed using only the
>     value octets of the Receipt SEQUENCE encoding.

[Jim wrote: I have a minor issue with the last sentence.  The digest must
include
the type and length bytes of the SEQUENCE and I don't believe that this
is correctly  stated in the text.  Suggest: "Therefore, the message
digest is computed using the entirety of the Receipt SEQUENCE encoding."]

I agree that when an RFC 2634 [ESS] signed receipt is encapsulated in the
CMS signedData type, then the message digest is computed using the entire
Receipt SEQUENCE encoding (as specified in RFC 2634 and RFC 2630).  However,
when a signed receipt is encapsulated in the PKCS #7 signedData type, then
RFC 2315 (PKCS #7), Section 9.3 (see below) specifies that the message
digest is computed using only the value octets (not the identifier octets or
the length octets) of the "content being signed" (i.e. Receipt SEQUENCE
encoding).  

When we performed signed receipt interoperability testing between the S/MIME
Freeware Library (SFL) and Microsoft, the Microsoft implementation was
initially encapsulating the signed receipt in a PKCS #7 signedData type.
When creating a PKCS #7 signed receipt, the Microsoft implementation encoded
the Receipt SEQUENCE in the SignedData contentInfo content ANY field (a
SEQUENCE, not an OCTET STRING) and calculated the message digest using only
the value octets of the Receipt SEQUENCE encoding.  Once we modified the SFL
to accept this format, then we were able to decode and verify the Microsoft
PKCS #7 signed receipt.  Please note that Microsoft later generated a
>>CMS<< signed receipt that we were able to decode and verify using the SFL
without any special modifications.

RFC 2315 (PKCS #7), Section 9.3:

  "9.3 Message-digesting process

   The message-digesting process computes a message digest on either the
   content being signed or the content together with the signer's
   authenticated attributes. In either case, the initial input to the
   message-digesting process is the "value" of the content being signed.
   Specifically, the initial input is the contents octets of the DER
   encoding of the content field of the ContentInfo value to which the
   signing process is applied. Only the contents octets of the DER
   encoding of that field are digested, not the identifier octets or the
   length octets."

===========================================
John Pawling, [e-mail]
Getronics Government Solutions, LLC
===========================================


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id f8JKS7k09528 for ietf-smime-bks; Wed, 19 Sep 2001 13:28:07 -0700 (PDT)
Received: from nebula.x509.com (nebula.x509.com [199.175.150.19]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f8JKS6D09524 for <[e-mail]>; Wed, 19 Sep 2001 13:28:06 -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 f8JKS1614195 for <[e-mail]>; Wed, 19 Sep 2001 13:28:01 -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 f8JKS1E21104 for <[e-mail]>; Wed, 19 Sep 2001 13:28:01 -0700 (PDT)
Received: by exvan01.x509.com with Internet Mail Service (5.5.2653.19) id <TDHNR6DV>; Wed, 19 Sep 2001 13:29:26 -0700
Received: from HOUSLEY-LAP.rsasecurity.com (HOUSLEY-LAP [10.3.1.73]) by exna00.securitydynamics.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id T1DQNZ1Z; Wed, 19 Sep 2001 16:27:41 -0400
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 5.0.1
Date: Wed, 19 Sep 2001 16:27:00 -0400
To: [e-mail]
From: "Housley, Russ" <[e-mail]>
Subject: WG Last Call: draft-ietf-smime-x400transport-03.txt
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 X.400 Transport document is ready for WG Last Call.  This document 
describes protocol options for conveying CMS-protected objects associated 
with S/MIME version 3 over an X.400 message transfer system.  Please post 
all comments to the S/MIME WG mail list by 4 October 2001.

	Title		: Transporting S/MIME Objects in X.400
	Author(s)	: P. Hoffman, C. Bonatti
	Filename	: draft-ietf-smime-x400transport-03.txt
	Date		: 23-Jul-01
	
Russ 


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id f8JIQeX05497 for ietf-smime-bks; Wed, 19 Sep 2001 11:26:40 -0700 (PDT)
Received: from femail27.sdc1.sfba.home.com ([24.254.60.17]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f8JIQcD05493 for <[e-mail]>; Wed, 19 Sep 2001 11:26:38 -0700 (PDT)
Received: from revelation ([65.4.166.11]) by femail27.sdc1.sfba.home.com (InterMail vM.4.01.03.20 201-229-121-120-20010223) with ESMTP id <20010919182635.HDQL559.femail27.sdc1.sfba.home.com@revelation>; Wed, 19 Sep 2001 11:26:35 -0700
Reply-To: <[e-mail]>
From: "Jim Schaad" <[e-mail]>
To: "'Housley, Russ'" <[e-mail]>, <[e-mail]>
Cc: <[e-mail]>
Subject: RE: Comments on draft-ietf-smime-rfc2630bis-03
Date: Wed, 19 Sep 2001 11:26:11 -0700
Message-ID: <000701c14138$8f116360$[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.2627
In-Reply-To: <[e-mail]>
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2526.0000
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:

Items of agreement have been removed.
> 
> 
> Jim:
> 
> 
> 
> This text was proposed by Peter Gutmann and improved upon by John 
> Pawling.  This is one place where backward comparability with 
> PKCS#7 has 
> not been preserved, and we are trying to warn implementors about the 
> potential dangers.
> 
> You make a good point about DER.  I have made a few changes 
> to the text to 
> highlight the DER issue.  Are these changes sufficient?  I propose:
> 
>     5.2.1  Compatibility with PKCS #7
> 
>     This section contains a word of warning to implementers 
> that wish to
>     support both the CMS and PKCS #7 [PKCS#7] SignedData 
> content types.
>     Both the CMS and PKCS #7 identify the type of the encapsulated
>     content with an object identifier, but the ASN.1 type of 
> the content
>     itself is variable in PKCS #7 SignedData content type.
> 
>     PKCS #7 defines content as:
> 
>        content [0] EXPLICIT ANY DEFINED BY contentType OPTIONAL
> 
>     The CMS defines eContent as:
> 
>        eContent [0] EXPLICIT OCTET STRING OPTIONAL
> 
>     The CMS definition is much easier to use in most 
> applications, and it
>     is compatible with both S/MIME v2 and S/MIME v3.  S/MIME signed
>     messages using the CMS and PKCS #7 are compatible because 
> identical
>     signed message formats are specified in RFC 2311 for S/MIME v2
>     [OLDMSG] and RFC 2633 for S/MIME v3 [MSG].  S/MIME v2 encapsulates
>     the MIME content in a Data type (that is, an OCTET 
> STRING) carried in
>     the SignedData contentInfo content ANY field, and S/MIME 
> v3 carries
>     the MIME content in the SignedData encapContentInfo eContent OCTET
>     STRING.  Therefore, in both S/MIME v2 and S/MIME v3, the 
> MIME content
>     is placed in an OCTET STRING and the message digest is 
> computed over
>     the identical portions of the content.  That is, the 
> message digest
>     is computed over the octets comprising the value of the 
> OCTET STRING,
>     neither the tag nor length octets are included.
> 
>     There are incompatibilities between the CMS and PKCS #7 signedData
>     types when the encapsulated content is not formatted 
> using the Data
>     type.  For example, when an RFC 2634 [ESS] signed receipt is
>     encapsulated in the CMS signedData type, then the Receipt 
> SEQUENCE is
>     encoded in the signedData encapContentInfo eContent OCTET 
> STRING and
>     the message digest is computed using the entire Receipt SEQUENCE
>     encoding (including tag, length and value octets).  However, if an
>     RFC 2634 signed receipt is encapsulated in the PKCS #7 signedData
>     type, then the Receipt SEQUENCE is DER encoded [X.509-88] in the
>     SignedData contentInfo content ANY field (a SEQUENCE, not an OCTET
>     STRING).  Therefore, the message digest is computed using only the
>     value octets of the Receipt SEQUENCE encoding.

I have a minor issue with the last sentence.  The digest must include
the type and length bytes of the SEQUENCE and I don't believe that this
is correctly  stated in the text.  Suggest: "Therefore, the message
digest is computed using the entirety of the Receipt SEQUENCE encoding."

> 
>     The following strategy can be used to achieve backward 
> compatibility
>     with PKCS #7 when processing SignedData content types.  If the
>     implementation is unable to ASN.1 decode the signedData type using
>     the CMS signedData encapContentInfo eContent OCTET STRING syntax,
>     then the implementation MAY attempt to decode the signedData type
>     using the PKCS #7 SignedData contentInfo content ANY syntax and
>     compute the message digest accordingly.
> 
>     The following strategy can be used to achieve backward 
> compatibility
>     with PKCS #7 when creating a SignedData content type in which the
>     encapsulated content is not formatted using the Data type.
>     Implementations MAY examine the value of the 
> eContentType, and then
>     adjust the expected DER encoding of eContent based on the object
>     identifier value.  For example, to support Microsoft AuthentiCode,
>     the following information MAY be included:
> 
>        eContentType Object Identifier is set to { 1 3 6 1 4 1 
> 311 2 1 4 }
>        eContent contains DER encoded AuthentiCode signing information
> 
> 
> 
> Russ
> 

Jim



Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id f8JIKLP05210 for ietf-smime-bks; Wed, 19 Sep 2001 11:20:21 -0700 (PDT)
Received: from femail43.sdc1.sfba.home.com ([24.254.60.37]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f8JIKKD05206 for <[e-mail]>; Wed, 19 Sep 2001 11:20:20 -0700 (PDT)
Received: from revelation ([65.4.166.11]) by femail43.sdc1.sfba.home.com (InterMail vM.4.01.03.20 201-229-121-120-20010223) with ESMTP id <20010919182017.EMIX10348.femail43.sdc1.sfba.home.com@revelation>; Wed, 19 Sep 2001 11:20:17 -0700
Reply-To: <[e-mail]>
From: "Jim Schaad" <[e-mail]>
To: "'Housley, Russ'" <[e-mail]>, <[e-mail]>
Subject: RE: Compression Content Type and RFC2630bis
Date: Wed, 19 Sep 2001 11:19:52 -0700
Message-ID: <000601c14137$ad74bc40$[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.2627
In-Reply-To: <[e-mail]>
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2526.0000
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,

I would prefer that this stay a separate draft.  Although I can see
benefits to including it, it does not cover the same topic as the CMS
draft - that is security - so I don't believe that it belongs together. 

jim

> -----Original Message-----
> From: [e-mail] 
> [mailto:[e-mail]] On Behalf Of Housley, Russ
> Sent: Wednesday, September 19, 2001 8:02 AM
> To: [e-mail]
> Subject: Compression Content Type and RFC2630bis
> 
> 
> 
> Dear S/MIME WG:
> 
> It has been suggested that since many of the other extensions 
> to the CMS 
> have been incorporated into RFC2630bis, and that the 
> compression content 
> type should be incorporated as well.  How does the working 
> group feel about 
> this suggestion?  Please let me know soon since this document 
> is in WG Last 
> Call.
> 
> Russ
> 



Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id f8JICXB04887 for ietf-smime-bks; Wed, 19 Sep 2001 11:12:33 -0700 (PDT)
Received: from tholian.securitydynamics.com (mail.rsasecurity.com [204.167.112.129]) by above.proper.com (8.11.6/8.11.3) with SMTP id f8JICVD04879 for <[e-mail]>; Wed, 19 Sep 2001 11:12:32 -0700 (PDT)
Received: from sdtihq24.securitydynamics.com by tholian.securitydynamics.com via smtpd (for mail.imc.org [208.184.76.43]) with SMTP; 19 Sep 2001 18:09:42 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 OAA15387 for <[e-mail]>; Wed, 19 Sep 2001 14:12:33 -0400 (EDT)
Received: by exna00.securitydynamics.com with Internet Mail Service (5.5.2653.19) id <T1DQNWD9>; Wed, 19 Sep 2001 14:12:32 -0400
Received: from HOUSLEY-LAP.rsasecurity.com (HOUSLEY-LAP [10.3.1.34]) by exna00.securitydynamics.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id T1DQNWD7; Wed, 19 Sep 2001 14:12:29 -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.0.1
Date: Wed, 19 Sep 2001 14:12:25 -0400
Subject: Re:  Compression Content Type and RFC2630bis
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>

Peter:

I was not suggesting that the current draft be stopped.  I would let the 
current document that is already with the IESG continue.  Then, simply 
consolidate in rfc2630bis.

Russ

At 05:29 AM 9/20/2001 +1200, you wrote:
>"Housley, Russ" <[e-mail]> writes:
>
> >It has been suggested that since many of the other extensions to the CMS 
> have
> >been incorporated into RFC2630bis, and that the compression content type
> >should be incorporated as well.  How does the working group feel about this
> >suggestion?  Please let me know soon since this document is in WG Last Call.
>
>Since this draft has been on tbe brink of being published as an RFC for over 1
>1/2 years, and since there are already several implementations out there which
>depend on it, I'd really like to see it finally published rather than reenter
>the treadmill again waiting on 2630bis.
>
>Peter.


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id f8JHU4i03415 for ietf-smime-bks; Wed, 19 Sep 2001 10:30:04 -0700 (PDT)
Received: from kakapo.cs.auckland.ac.nz (kakapo.cs.auckland.ac.nz [130.216.34.10]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f8JHU2D03411 for <[e-mail]>; Wed, 19 Sep 2001 10:30:02 -0700 (PDT)
Received: from ruru.cs.auckland.ac.nz (firebird.cs.auckland.ac.nz [130.216.34.12]) by kakapo.cs.auckland.ac.nz (8.8.6/8.8.6/cs-master) with ESMTP id FAA23298; Thu, 20 Sep 2001 05:29:47 +1200 (NZST) (sender [e-mail])
Received: (from pgut001@localhost) by ruru.cs.auckland.ac.nz (8.9.3/8.8.6/cs-slave) id FAA351966; Thu, 20 Sep 2001 05:29:46 +1200 (NZST) (sender [e-mail])
Date: Thu, 20 Sep 2001 05:29:46 +1200 (NZST)
Message-ID: <[e-mail]>
From: [e-mail] (Peter Gutmann)
To: [e-mail], [e-mail]
Subject: Re:  Compression Content Type and RFC2630bis
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>

"Housley, Russ" <[e-mail]> writes:

>It has been suggested that since many of the other extensions to the CMS have
>been incorporated into RFC2630bis, and that the compression content type
>should be incorporated as well.  How does the working group feel about this
>suggestion?  Please let me know soon since this document is in WG Last Call.

Since this draft has been on tbe brink of being published as an RFC for over 1
1/2 years, and since there are already several implementations out there which
depend on it, I'd really like to see it finally published rather than reenter
the treadmill again waiting on 2630bis.

Peter.



Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id f8JFplB26580 for ietf-smime-bks; Wed, 19 Sep 2001 08:51:47 -0700 (PDT)
Received: from tweety (pool-151-200-26-46.res.east.verizon.net [151.200.26.46]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f8JFpjD26569 for <[e-mail]>; Wed, 19 Sep 2001 08:51:45 -0700 (PDT)
Received: from [192.168.0.11] by tweety (ArGoSoft Mail Server, Version 1.61 (1.6.1.9)); Wed, 19 Sep 2001 11:33:46 -0400
Message-ID: <[e-mail]>
Date: Wed, 19 Sep 2001 11:33:41 -0400
From: "Sean P. Turner" <[e-mail]>
Organization: IECA, Inc.
X-Mailer: Mozilla 4.78 [en] (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
To: "Housley, Russ" <[e-mail]>
CC: [e-mail]
Subject: Re: Compression Content Type and RFC2630bis
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'd say include it.  The less documents one has to track down the better.

spt

"Housley, Russ" wrote:

> Dear S/MIME WG:
>
> It has been suggested that since many of the other extensions to the CMS
> have been incorporated into RFC2630bis, and that the compression content
> type should be incorporated as well.  How does the working group feel about
> this suggestion?  Please let me know soon since this document is in WG Last
> Call.
>
> Russ




Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id f8JFU6K23167 for ietf-smime-bks; Wed, 19 Sep 2001 08:30:06 -0700 (PDT)
Received: from tholian.securitydynamics.com (mail.rsasecurity.com [204.167.112.129]) by above.proper.com (8.11.6/8.11.3) with SMTP id f8JFU0D23135 for <[e-mail]>; Wed, 19 Sep 2001 08:30:00 -0700 (PDT)
Received: from sdtihq24.securitydynamics.com by tholian.securitydynamics.com via smtpd (for mail.imc.org [208.184.76.43]) with SMTP; 19 Sep 2001 15:27:10 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 LAA26496 for <[e-mail]>; Wed, 19 Sep 2001 11:25:13 -0400 (EDT)
Received: by exna00.securitydynamics.com with Internet Mail Service (5.5.2653.19) id <T1DQNSR4>; Wed, 19 Sep 2001 11:25:13 -0400
Received: from HOUSLEY-LAP.rsasecurity.com (HOUSLEY-LAP [10.3.1.51]) by exna00.securitydynamics.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id T1DQNSRP; Wed, 19 Sep 2001 11:25:08 -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.0.1
Date: Wed, 19 Sep 2001 10:26:32 -0400
Subject: Re: Comments on draft-ietf-smime-cmsalg-04
In-Reply-To: <001701c140bb$731ae910$[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:

RFC 2630 uses "the CMS."  It is the Cryptographic Message Syntax.

If this is the only unresolved issue, then the document is finished.

Russ


At 08:30 PM 9/18/2001 -0700, Jim Schaad wrote:
>Russ,
>
>1.  Section 1: I guess I just need to keep complaining about this issue.
>In the first paragraph please change "of the CMS" to "of CMS", I find
>the word "the" to be very difficult to say as I read the text.
>
>Jim


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id f8JFU3923155 for ietf-smime-bks; Wed, 19 Sep 2001 08:30:03 -0700 (PDT)
Received: from tholian.securitydynamics.com (mail.rsasecurity.com [204.167.112.129]) by above.proper.com (8.11.6/8.11.3) with SMTP id f8JFU1D23147 for <[e-mail]>; Wed, 19 Sep 2001 08:30:01 -0700 (PDT)
Received: from sdtihq24.securid.com by tholian.securitydynamics.com via smtpd (for mail.imc.org [208.184.76.43]) with SMTP; 19 Sep 2001 15:27:12 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 LAA27078 for <[e-mail]>; Wed, 19 Sep 2001 11:30:01 -0400 (EDT)
Received: by exna00.securitydynamics.com with Internet Mail Service (5.5.2653.19) id <T1DQNSRV>; Wed, 19 Sep 2001 11:25:13 -0400
Received: from HOUSLEY-LAP.rsasecurity.com (HOUSLEY-LAP [10.3.1.51]) by exna00.securitydynamics.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id T1DQNSRQ; Wed, 19 Sep 2001 11:25:08 -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.0.1
Date: Wed, 19 Sep 2001 10:49:07 -0400
Subject: Re: Comments on draft-ietf-smime-rfc2630bis-03
In-Reply-To: <001601c140b9$39f1cd40$[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.  The comment I had for section 3 was for
>
>id-ct-contentInfo  OBJECT IDENTIFIER ::= { iso(1) member-body(2)
>      us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16)
>      content-types(1) 6}
>
>Not for id-contentType.  (This has come to you privately but not on the
>list.)

I have already fixed it in the yet-to-be-published rfc2630bis-04.  I expect 
to release -04 later this week (hopefully this afternoon).

>2.  Section 5.2.1.  I don't follow the reasoning behind putting this
>section in the document.  If the issue is to allow for the processing of
>PKCS#7 item, then I think that information is lacking (specifically the
>fact that "content" MUST be DER encoded).  At present it only allows for
>parsing of the content, in some cases.  (Note that my guess is that the
>current MSFT code would fail if the OID corresponded to an OCTET STRING
>as it would not be able to guess which way to go.)  A better way of
>doing the guessing is really to say that you look to see if you have an
>OCTET STRING and assume you will have a CMS rather than a PKCS#7 object.
>The problem with your current method is there is nothing to stop
>somebody from creating a CMS signed data object using the same embedded
>content (but OCTET wrapped).

This text was proposed by Peter Gutmann and improved upon by John 
Pawling.  This is one place where backward comparability with PKCS#7 has 
not been preserved, and we are trying to warn implementors about the 
potential dangers.

You make a good point about DER.  I have made a few changes to the text to 
highlight the DER issue.  Are these changes sufficient?  I propose:

    5.2.1  Compatibility with PKCS #7

    This section contains a word of warning to implementers that wish to
    support both the CMS and PKCS #7 [PKCS#7] SignedData content types.
    Both the CMS and PKCS #7 identify the type of the encapsulated
    content with an object identifier, but the ASN.1 type of the content
    itself is variable in PKCS #7 SignedData content type.

    PKCS #7 defines content as:

       content [0] EXPLICIT ANY DEFINED BY contentType OPTIONAL

    The CMS defines eContent as:

       eContent [0] EXPLICIT OCTET STRING OPTIONAL

    The CMS definition is much easier to use in most applications, and it
    is compatible with both S/MIME v2 and S/MIME v3.  S/MIME signed
    messages using the CMS and PKCS #7 are compatible because identical
    signed message formats are specified in RFC 2311 for S/MIME v2
    [OLDMSG] and RFC 2633 for S/MIME v3 [MSG].  S/MIME v2 encapsulates
    the MIME content in a Data type (that is, an OCTET STRING) carried in
    the SignedData contentInfo content ANY field, and S/MIME v3 carries
    the MIME content in the SignedData encapContentInfo eContent OCTET
    STRING.  Therefore, in both S/MIME v2 and S/MIME v3, the MIME content
    is placed in an OCTET STRING and the message digest is computed over
    the identical portions of the content.  That is, the message digest
    is computed over the octets comprising the value of the OCTET STRING,
    neither the tag nor length octets are included.

    There are incompatibilities between the CMS and PKCS #7 signedData
    types when the encapsulated content is not formatted using the Data
    type.  For example, when an RFC 2634 [ESS] signed receipt is
    encapsulated in the CMS signedData type, then the Receipt SEQUENCE is
    encoded in the signedData encapContentInfo eContent OCTET STRING and
    the message digest is computed using the entire Receipt SEQUENCE
    encoding (including tag, length and value octets).  However, if an
    RFC 2634 signed receipt is encapsulated in the PKCS #7 signedData
    type, then the Receipt SEQUENCE is DER encoded [X.509-88] in the
    SignedData contentInfo content ANY field (a SEQUENCE, not an OCTET
    STRING).  Therefore, the message digest is computed using only the
    value octets of the Receipt SEQUENCE encoding.

    The following strategy can be used to achieve backward compatibility
    with PKCS #7 when processing SignedData content types.  If the
    implementation is unable to ASN.1 decode the signedData type using
    the CMS signedData encapContentInfo eContent OCTET STRING syntax,
    then the implementation MAY attempt to decode the signedData type
    using the PKCS #7 SignedData contentInfo content ANY syntax and
    compute the message digest accordingly.

    The following strategy can be used to achieve backward compatibility
    with PKCS #7 when creating a SignedData content type in which the
    encapsulated content is not formatted using the Data type.
    Implementations MAY examine the value of the eContentType, and then
    adjust the expected DER encoding of eContent based on the object
    identifier value.  For example, to support Microsoft AuthentiCode,
    the following information MAY be included:

       eContentType Object Identifier is set to { 1 3 6 1 4 1 311 2 1 4 }
       eContent contains DER encoded AuthentiCode signing information


>3.  I think it is time to remove the [** NEW **] and [** OLD **]
>comments so we can see a true draft for last call.

Okay.  I will do that before I publish -04.

The WG Last Call is already in progress.  I will expend the deadline once 
the -04 draft is published.  I would expect it to close next week.

Russ


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id f8JFPip22945 for ietf-smime-bks; Wed, 19 Sep 2001 08:25:44 -0700 (PDT)
Received: from [203.46.112.10] (mail.rsasecurity.com.au [203.46.112.10]) by above.proper.com (8.11.6/8.11.3) with SMTP id f8JFPfD22934 for <[e-mail]>; Wed, 19 Sep 2001 08:25:41 -0700 (PDT)
Received: from [192.168.18.3] by [203.46.112.10] via smtpd (for [208.184.76.43]) with SMTP; 7 Mar 2001 10:26:41 UT
Received: from exaus01.local.aus.rsa.com (exaus01.local.aus.rsa.com [10.177.1.15]) by grover.local.aus.rsa.com (8.10.2/8.10.2) with ESMTP id f8JFTXq05942 for <[e-mail]>; Thu, 20 Sep 2001 01:29:33 +1000 (EST)
Received: by exaus01.local.aus.rsa.com with Internet Mail Service (5.5.2653.19) id <SJYJPXGY>; Thu, 20 Sep 2001 01:18:39 +1000
Received: from HOUSLEY-LAP.rsasecurity.com (HOUSLEY-LAP [10.3.1.51]) by exna00.securitydynamics.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id T1DQNSRR; Wed, 19 Sep 2001 11:25:09 -0400
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 5.0.1
Date: Wed, 19 Sep 2001 11:01:50 -0400
To: [e-mail]
From: "Housley, Russ" <[e-mail]>
Subject: Compression Content Type and RFC2630bis
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>

Dear S/MIME WG:

It has been suggested that since many of the other extensions to the CMS 
have been incorporated into RFC2630bis, and that the compression content 
type should be incorporated as well.  How does the working group feel about 
this suggestion?  Please let me know soon since this document is in WG Last 
Call.

Russ


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id f8JFPaB22922 for ietf-smime-bks; Wed, 19 Sep 2001 08:25:36 -0700 (PDT)
Received: from tholian.securitydynamics.com (mail.rsasecurity.com [204.167.112.129]) by above.proper.com (8.11.6/8.11.3) with SMTP id f8JFPYD22913 for <[e-mail]>; Wed, 19 Sep 2001 08:25:34 -0700 (PDT)
Received: from sdtihq24.securid.com by tholian.securitydynamics.com via smtpd (for mail.imc.org [208.184.76.43]) with SMTP; 19 Sep 2001 15:22:44 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 LAA26487; Wed, 19 Sep 2001 11:25:10 -0400 (EDT)
Received: by exna00.securitydynamics.com with Internet Mail Service (5.5.2653.19) id <T1DQNSRS>; Wed, 19 Sep 2001 11:25:10 -0400
Received: from HOUSLEY-LAP.rsasecurity.com (HOUSLEY-LAP [10.3.1.51]) by exna00.securitydynamics.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id T1DQNSR3; Wed, 19 Sep 2001 11:25:07 -0400
From: "Housley, Russ" <[e-mail]>
To: [e-mail], [e-mail]
Cc: [e-mail], [e-mail]
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 5.0.1
Date: Wed, 19 Sep 2001 10:18:00 -0400
Subject: draft-ietf-smime-key-wrap-01.txt
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 & Marcus:

The S/MIME WG is finished with the Key Wrap document.  This document 
specifies the algorithm for wrapping one Triple-DES key with another 
Triple-DES key, and it specifies the algorithm for wrapping one RC2 key 
with another RC2 key.  These key wrap algorithms
were originally published in section 12.6 of RFC 2630.  We would like to 
see them republished an an Informational RFC since these key wrap 
algorithms have been found to be useful in contexts beyond those supported 
by RFC 2630.

	Title		: Triple-DES and RC2 Key Wrapping
	Author(s)	: R. Housley
	Filename	: draft-ietf-smime-key-wrap-01.txt
	Pages		: 9
	Date		: 18-Sep-01
	
Russ


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id f8JB6JH03816 for ietf-smime-bks; Wed, 19 Sep 2001 04:06:19 -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 f8JB6HD03812 for <[e-mail]>; Wed, 19 Sep 2001 04:06:17 -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 HAA28876; Wed, 19 Sep 2001 07:06:57 -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-key-wrap-01.txt
Date: Wed, 19 Sep 2001 07:06:57 -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		: Triple-DES and RC2 Key Wrapping
	Author(s)	: R. Housley
	Filename	: draft-ietf-smime-key-wrap-01.txt
	Pages		: 9
	Date		: 18-Sep-01
	
This document specifies the algorithm for wrapping one Triple-DES
[3DES] key with another Triple-DES key and the algorithm for wrapping
one RC2 [RC2] key with another RC2 key.  These key wrap algorithms
were originally published in section 12.6 of RFC 2630 [CMS].  They
are republished since these key wrap algorithms have been found to be
useful in contexts beyond those supported by RFC 2630.

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

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

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 f8J3V4322470 for ietf-smime-bks; Tue, 18 Sep 2001 20:31:04 -0700 (PDT)
Received: from femail39.sdc1.sfba.home.com ([24.254.60.33]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f8J3V2D22466 for <[e-mail]>; Tue, 18 Sep 2001 20:31:03 -0700 (PDT)
Received: from revelation ([65.4.166.11]) by femail39.sdc1.sfba.home.com (InterMail vM.4.01.03.20 201-229-121-120-20010223) with ESMTP id <20010919033100.JKY29420.femail39.sdc1.sfba.home.com@revelation>; Tue, 18 Sep 2001 20:31:00 -0700
Reply-To: <[e-mail]>
From: "Jim Schaad" <[e-mail]>
To: <[e-mail]>, "Russ Housley" <[e-mail]>
Subject: Comments on draft-ietf-smime-cmsalg-04
Date: Tue, 18 Sep 2001 20:30:37 -0700
Message-ID: <001701c140bb$731ae910$[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.2627
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2526.0000
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,

1.  Section 1: I guess I just need to keep complaining about this issue.
In the first paragraph please change "of the CMS" to "of CMS", I find
the word "the" to be very difficult to say as I read the text.

Jim



Received: by above.proper.com (8.11.6/8.11.3) id f8J3FDf22028 for ietf-smime-bks; Tue, 18 Sep 2001 20:15:13 -0700 (PDT)
Received: from femail35.sdc1.sfba.home.com ([24.254.60.25]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f8J3FBD22024 for <[e-mail]>; Tue, 18 Sep 2001 20:15:11 -0700 (PDT)
Received: from revelation ([65.4.166.11]) by femail35.sdc1.sfba.home.com (InterMail vM.4.01.03.20 201-229-121-120-20010223) with ESMTP id <20010919031505.CRIV12461.femail35.sdc1.sfba.home.com@revelation>; Tue, 18 Sep 2001 20:15:05 -0700
Reply-To: <[e-mail]>
From: "Jim Schaad" <[e-mail]>
To: <[e-mail]>, "Russ Housley" <[e-mail]>
Subject: Comments on draft-ietf-smime-rfc2630bis-03
Date: Tue, 18 Sep 2001 20:14:42 -0700
Message-ID: <001601c140b9$39f1cd40$[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.2627
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2526.0000
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,


1.  The comment I had for section 3 was for 

id-ct-contentInfo  OBJECT IDENTIFIER ::= { iso(1) member-body(2)
     us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16)
     content-types(1) 6}

Not for id-contentType.  (This has come to you privately but not on the
list.)

2.  Section 5.2.1.  I don't follow the reasoning behind putting this
section in the document.  If the issue is to allow for the processing of
PKCS#7 item, then I think that information is lacking (specifically the
fact that "content" MUST be DER encoded).  At present it only allows for
parsing of the content, in some cases.  (Note that my guess is that the
current MSFT code would fail if the OID corresponded to an OCTET STRING
as it would not be able to guess which way to go.)  A better way of
doing the guessing is really to say that you look to see if you have an
OCTET STRING and assume you will have a CMS rather than a PKCS#7 object.
The problem with your current method is there is nothing to stop
somebody from creating a CMS signed data object using the same embedded
content (but OCTET wrapped).

3.  I think it is time to remove the [** NEW **] and [** OLD **]
comments so we can see a true draft for last call.

Jim



Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id f8ID1ck26472 for ietf-smime-bks; Tue, 18 Sep 2001 06:01:38 -0700 (PDT)
Received: from tholian.securitydynamics.com (mail.rsasecurity.com [204.167.112.129]) by above.proper.com (8.11.6/8.11.3) with SMTP id f8ID1aD26468 for <[e-mail]>; Tue, 18 Sep 2001 06:01:36 -0700 (PDT)
Received: from sdtihq24.securid.com by tholian.securitydynamics.com via smtpd (for mail.imc.org [208.184.76.43]) with SMTP; 18 Sep 2001 12:58:47 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 JAA02332 for <[e-mail]>; Tue, 18 Sep 2001 09:01:36 -0400 (EDT)
Received: by exna00.securitydynamics.com with Internet Mail Service (5.5.2653.19) id <T1DQM8WF>; Tue, 18 Sep 2001 09:01:35 -0400
Received: from HOUSLEY-LAP.rsasecurity.com (HOUSLEY-LAP [10.3.1.57]) by exna00.securitydynamics.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id T1DQM8W1; Tue, 18 Sep 2001 09:01:31 -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.0.1
Date: Tue, 18 Sep 2001 09:01:24 -0400
Subject: Re: Comments on draft-ietf-smime-key-wrap-00
In-Reply-To: <000601c13fe5$b2dd41f0$[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.  I would like to see the text on how to treat two key 3DES keys from
>the introduction to the section on 3DES key wrap so its all together.
>(suggest part of section 3 overview)

Agree.  The document does flow better with this change.

>2.  I would like to see the restriction on RC2 key wrap key sizes moved
>from the introduction to the section on RC2 key wrap so  its all
>together.  (suggest part of section 4 overview)

Agree.  The document does flow better with this change.

>3.  Since these algorithms have been designed by us and are not
>documented elsewhere, I suggest adding the following sections:

I added the examples.  I would greatly appreciate confirmation that they 
are correct from other implementors.

Russ


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id f8IC9jo22718 for ietf-smime-bks; Tue, 18 Sep 2001 05:09:45 -0700 (PDT)
Received: from ocasey.baltimore.com ([193.41.17.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f8IC9hD22709 for <[e-mail]>; Tue, 18 Sep 2001 05:09:43 -0700 (PDT)
Received: from Baltimore-FW1 ([172.19.1.1]) by ocasey.baltimore.com (8.9.3/8.9.3) with SMTP id NAA16469 for <[e-mail]>; Tue, 18 Sep 2001 13:09:38 +0100
Received: from Baltimore-FW1 (wilde-i-1.ie.baltimore.com) by emeairlsw1.baltimore.com (Content Technologies SMTPRS 4.2.5) with SMTP id <[e-mail]> for <[e-mail]>; Tue, 18 Sep 2001 13:06:32 +0100
Received: from baltimore.ie (wks113-25.ie.baltimore.com [10.153.26.113] (may be forged)) by bobcat.baltimore.ie (8.9.3/8.9.3) with ESMTP id NAA29767; Tue, 18 Sep 2001 13:12:28 +0100
Message-ID: <[e-mail]>
Date: Tue, 18 Sep 2001 13:09:38 +0100
From: Stephen Farrell <[e-mail]>
Reply-To: [e-mail]
Organization: Baltimore Technologies Ltd.
X-Mailer: Mozilla 4.72 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: [e-mail]
CC: [e-mail]
Subject: Re: which is easier?
References: <000501c13fb7$452767e0$[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>

Thanks Jim,

> First all of the tool kits separate the MIME processing from the CMS
> processing so there is no need to tie them together if not needed.

Good.

> 
> Questions:
> 
> 1.  Do you expect the inner data to ever be transported independent of a
> CMS wrapping?

Yes, the inner data are Diameter AVPs (attr/vals pairs) and will often be
carried, in clear, as "normal" Diameter AVPs. There can be "proxy" things
that wrap/unwrap the AVPs.

> 2.  Do you feel that either a) you can assign an OID for this content or
> b) the content is uniquely described else where (this can be in the
> protocol as well).

I'd say yes, given that all the AVPs are defined in Diameter specs. However,
I'd expect to get toolkit problems with a new OID. Maybe I'm just a pessimist.

> 3.  Do you expect the wrapped data to be transported using a system that
> expects MIME content (i.e. SMTP, HTTP)?

Nope.

> 
> If the answer for 1 is yes, then use MIME for the inner wrapping
> otherwise use a binary content.
> If the answer for 2 is yes, then assign a new OID for the binary
> structure (or use id-data).  If the answer is no, use a MIME wrapper.
> If the answer for 3 is yes, use MIME otherwise don't.
> 
> I expect that there may be some people who would disagree with my
> response to question #2.  Specifically I am allowing for what I assume
> is a non ASN.1 binary blob to be assigned an OID value and placed in the
> encapsulated data.  I feel that this is appropriate and legal.  Also,
> beware of some completely automated processors (such as a mail client)
> which assume that id-data is the equivalent of saying MIME content.
> This is not what is specified in the documents but is an assumption in
> some environments.

So, given the above, am I right that you'd recommend:

1. EnvelopedData-fnc(MIME-enc(data),receipient-stuff...) 
   and use id-data as the OID.

Stephen.

PS: I also got off-list recommendations for 2 and 4 (I think:-)

> > 1. EnvelopedData-fnc(MIME-enc(data),receipient-stuff...)
> > 2. MIME-enc(EnvelopedData-fnc(data,receipient-stuff...))
> > 3. MIME-enc(EnvelopedData-fnc(MIME-enc(data),receipient-stuff...))
> > 4. EnvelopedData-fnc(data,receipient-stuff...)

-- 
____________________________________________________________
Stephen Farrell         				   
Baltimore Technologies,   tel: (direct line) [phone]
39 Parkgate Street,                     fax: [phone]
Dublin 8.                mailto:[e-mail]
Ireland                             http://www.baltimore.com


Received: by above.proper.com (8.11.6/8.11.3) id f8I20sN11129 for ietf-smime-bks; Mon, 17 Sep 2001 19:00:54 -0700 (PDT)
Received: from femail35.sdc1.sfba.home.com ([24.254.60.25]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f8I20qD11124 for <[e-mail]>; Mon, 17 Sep 2001 19:00:52 -0700 (PDT)
Received: from revelation ([65.4.166.11]) by femail35.sdc1.sfba.home.com (InterMail vM.4.01.03.20 201-229-121-120-20010223) with ESMTP id <20010918020050.IJJX12461.femail35.sdc1.sfba.home.com@revelation>; Mon, 17 Sep 2001 19:00:50 -0700
Reply-To: <[e-mail]>
From: "Jim Schaad" <[e-mail]>
To: <[e-mail]>, "Russ Housley" <[e-mail]>
Subject: Comments on draft-ietf-smime-key-wrap-00
Date: Mon, 17 Sep 2001 19:00:32 -0700
Message-ID: <000601c13fe5$b2dd41f0$[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.2627
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2526.0000
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,

Here are the comments that I currently have.

1.  I would like to see the text on how to treat two key 3DES keys from
the introduction to the section on 3DES key wrap so its all together.
(suggest part of section 3 overview)

2.  I would like to see the restriction on RC2 key wrap key sizes moved
from the introduction to the section on RC2 key wrap so  its all
together.  (suggest part of section 4 overview)

3.  Since these algorithms have been designed by us and are not
documented elsewhere, I suggest adding the following sections:


3.4  Triple-DES Key Wrap Example

The following is an example of doing 3DES Key Wrap.  A set of
intermediate values corresponding to the named items in section 3.1 are
given.

CEK: 		2923 bf85 e06d d6ae 5291 49f1 f1ba e9ea b3a7 da3d 860d
3e98
KEK:		255e 0d1c 07b6 46df b313 4cc8 43ba 8aa7 1f02 5b7c 0838
251f
ICV:		181b 7e96 86e0 4a4e
CEKICV:	2923 bf85 e06d d6ae 5291 49f1 f1ba e9ea b3a7 da3d 860d 3e98
		181b 7e96 86e0 4a4e
IV:		5dd4 cbfc 96f5 453b
TEMP1:      cfc1 a789 c675 dd2a b49a 3204 ef92 cc03 5c1f 3b97 7a79 60f6
            a44d cc5f 729d 8449
TEMP2:	5dd4 cbfc 96f5 453b cfc1 a789 c675 dd2a b49a 3204 ef92 cc03
		5c1f 3b97 7a79 60f6 a44d cc5f 729d 8449
TEMP3:      4984 9d72 5fcc 4da4 f660 797a 3b97 1f5c 03cc 92ef 0432 9ab4
		2add 75c6 89a7 c1cf 3b45 f596 fccb d45d
RESULT:	6901 0761 8ef0 92b3 b48c a179 6b23 4ae9 fa33 ebb4 1596 0403
		7db5 d6a8 4eb3 aac2 768c 6327 75a4 67d4

4.4 RC2 Key Wrap Example

The following is an example of doing RC2 Key Wrap.  A set of
intermediate values corresponding to the named items in section 4.1 are
given.

CEK:		b70a 25fb c9d8 6a86 050c e0d7 11ea d4d9
KEK:		fd04 fd08 0607 07fb 0003 feff fd02 fe05
LENGTH:	10
LCEK:		10b7 0a25 fbc9 d86a 8605 0ce0 d711 ead4 d9
PAD		4845 cce7 fd12 50
LCEKPAD:	10b7 0a25 fbc9 d86a 8605 0ce0 d711 ead4
		d948 45cc e7fd 1250
ICV:		0a6f f19f db40 4988
LCEKPADICV: 10b7 0a25 fbc9 d86a 8605 0ce0 d711 ead4
		d948 45cc e7fd 1250 0a6f f19f db40 4988
IV:		c7d9 0059 b29e 97f7
TEMP1:	a01d a259 3793 1260 e48c 55f5 04ce 70b8
            ac8c d79e ffe8 9932 9fa9 8a07 a31f f7a7
TEMP2:	c7d9 0059 b29e 97f7 a01d a259 3793 1260
		e48c 55f5 04ce 70b8 ac8c d79e ffe8 9932
		9fa9 8a07 a31f f7a7
TEMP3:	a7f7 1fa3 078a a99f 3299 8eff 9ed7 8cac
		b870 ce04 f555 8ce4 6012 9337 59a2 1da0
		f797 9eb2 5900 d9c7
RESULT:	70e6 99fb 5701 f783 3330 fb71 e87c 85a4
		20bd c99a f05d 22af 5a0e 48d3 5f31 3898
		6cba afb4 b28d 4f35


Jim



Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id f8HKSWD04666 for ietf-smime-bks; Mon, 17 Sep 2001 13:28:32 -0700 (PDT)
Received: from femail36.sdc1.sfba.home.com ([24.254.60.26]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f8HKSVD04662 for <[e-mail]>; Mon, 17 Sep 2001 13:28:31 -0700 (PDT)
Received: from revelation ([65.4.166.11]) by femail36.sdc1.sfba.home.com (InterMail vM.4.01.03.20 201-229-121-120-20010223) with ESMTP id <20010917202828.SZLD13317.femail36.sdc1.sfba.home.com@revelation>; Mon, 17 Sep 2001 13:28:28 -0700
Reply-To: <[e-mail]>
From: "Jim Schaad" <[e-mail]>
To: <[e-mail]>, <[e-mail]>
Subject: RE: which is easier?
Date: Mon, 17 Sep 2001 13:28:11 -0700
Message-ID: <000501c13fb7$452767e0$[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.2627
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2526.0000
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>

Stephen,

Since my response is going to be a generalized one, I am posting to the
list.

You don't really give me enough information in your message for me to
answer you question, so I will response by asking a set of questions and
giving what I consider to be appropriate responses for the different
answers.

First all of the tool kits separate the MIME processing from the CMS
processing so there is no need to tie them together if not needed.  

Questions:

1.  Do you expect the inner data to ever be transported independent of a
CMS wrapping?
2.  Do you feel that either a) you can assign an OID for this content or
b) the content is uniquely described else where (this can be in the
protocol as well).
3.  Do you expect the wrapped data to be transported using a system that
expects MIME content (i.e. SMTP, HTTP)?

If the answer for 1 is yes, then use MIME for the inner wrapping
otherwise use a binary content.
If the answer for 2 is yes, then assign a new OID for the binary
structure (or use id-data).  If the answer is no, use a MIME wrapper.
If the answer for 3 is yes, use MIME otherwise don't.

I expect that there may be some people who would disagree with my
response to question #2.  Specifically I am allowing for what I assume
is a non ASN.1 binary blob to be assigned an OID value and placed in the
encapsulated data.  I feel that this is appropriate and legal.  Also,
beware of some completely automated processors (such as a mail client)
which assume that id-data is the equivalent of saying MIME content.
This is not what is specified in the documents but is an assumption in
some environments.

Jim


> -----Original Message-----
> From: [e-mail] 
> [mailto:[e-mail]] On Behalf Of Stephen Farrell
> Sent: Monday, September 17, 2001 9:01 AM
> To: [e-mail]
> Subject: which is easier?
> 
> 
> 
> 
> Folks,
> 
> I'm involved in writing up a spec [*] that uses 
> EnvelopedData. I want it to be easily usable with current 
> toolkits and I've a question about the MIME encodings to use.
> 
> The data is binary and the EnvelopedData are carried in a 
> binary protocol so I think the only issue is what's easiest for 
> folks (who don't know s/mime) to code using existing APIs.
> 
> Should I:-
> 
> 1. MIME encode the data before encryption?
> 2. MIME encode the data after encryption?
> 3. both of the above
> 4. neither of the above
> 
> That is, should my ciphertext look like:
> 
> 1. EnvelopedData-fnc(MIME-enc(data),receipient-stuff...)
> 2. MIME-enc(EnvelopedData-fnc(data,receipient-stuff...))
> 3. MIME-enc(EnvelopedData-fnc(MIME-enc(data),receipient-stuff...))
> 4. EnvelopedData-fnc(data,receipient-stuff...)
> 
> Answers off-list are fine (and much appreciated),
> Ta,
> Stephen.
> 
> [*] If you're interested its a AAA WG work item, the next version of:
> http://www.ietf.org/internet-drafts/draft-ietf-aaa-diameter-cm
s-sec-02.txt

-- 
____________________________________________________________
Stephen Farrell         				   
Baltimore Technologies,   tel: (direct line) [phone]
39 Parkgate Street,                     fax: [phone]
Dublin 8.                mailto:[e-mail]
Ireland                             http://www.baltimore.com



Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id f8HG0hc27758 for ietf-smime-bks; Mon, 17 Sep 2001 09:00:43 -0700 (PDT)
Received: from ocasey.baltimore.com ([193.41.17.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f8HG0fD27750 for <[e-mail]>; Mon, 17 Sep 2001 09:00:41 -0700 (PDT)
Received: from Baltimore-FW1 ([172.19.1.1]) by ocasey.baltimore.com (8.9.3/8.9.3) with SMTP id RAA08341 for <[e-mail]>; Mon, 17 Sep 2001 17:00:37 +0100
Received: from Baltimore-FW1 (wilde-i-1.ie.baltimore.com) by emeairlsw1.baltimore.com (Content Technologies SMTPRS 4.2.5) with SMTP id <[e-mail]> for <[e-mail]>; Mon, 17 Sep 2001 16:57:32 +0100
Received: from baltimore.ie (wks113-25.ie.baltimore.com [10.153.26.113] (may be forged)) by bobcat.baltimore.ie (8.9.3/8.9.3) with ESMTP id RAA18215 for <[e-mail]>; Mon, 17 Sep 2001 17:03:23 +0100
Message-ID: <[e-mail]>
Date: Mon, 17 Sep 2001 17:00:37 +0100
From: Stephen Farrell <[e-mail]>
Reply-To: [e-mail]
Organization: Baltimore Technologies Ltd.
X-Mailer: Mozilla 4.72 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: [e-mail]
Subject: which is easier?
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>

Folks,

I'm involved in writing up a spec [*] that uses 
EnvelopedData. I want it to be easily usable with current 
toolkits and I've a question about the MIME encodings to use.

The data is binary and the EnvelopedData are carried in a 
binary protocol so I think the only issue is what's easiest for 
folks (who don't know s/mime) to code using existing APIs.

Should I:-

1. MIME encode the data before encryption?
2. MIME encode the data after encryption?
3. both of the above
4. neither of the above

That is, should my ciphertext look like:

1. EnvelopedData-fnc(MIME-enc(data),receipient-stuff...)
2. MIME-enc(EnvelopedData-fnc(data,receipient-stuff...))
3. MIME-enc(EnvelopedData-fnc(MIME-enc(data),receipient-stuff...))
4. EnvelopedData-fnc(data,receipient-stuff...)

Answers off-list are fine (and much appreciated),
Ta,
Stephen.

[*] If you're interested its a AAA WG work item, the next version of:
http://www.ietf.org/internet-drafts/draft-ietf-aaa-diameter-cms-sec-02.txt

-- 
____________________________________________________________
Stephen Farrell         				   
Baltimore Technologies,   tel: (direct line) [phone]
39 Parkgate Street,                     fax: [phone]
Dublin 8.                mailto:[e-mail]
Ireland                             http://www.baltimore.com


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id f8HFhRX24202 for ietf-smime-bks; Mon, 17 Sep 2001 08:43:27 -0700 (PDT)
Received: from tholian.securitydynamics.com (mail.rsasecurity.com [204.167.112.129]) by above.proper.com (8.11.6/8.11.3) with SMTP id f8HFhPD24188 for <[e-mail]>; Mon, 17 Sep 2001 08:43:25 -0700 (PDT)
Received: from sdtihq24.securid.com by tholian.securitydynamics.com via smtpd (for mail.imc.org [208.184.76.43]) with SMTP; 17 Sep 2001 15:40:38 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 LAA24208 for <[e-mail]>; Mon, 17 Sep 2001 11:43:22 -0400 (EDT)
Received: by exna00.securitydynamics.com with Internet Mail Service (5.5.2653.19) id <TCB01R2K>; Mon, 17 Sep 2001 11:43:21 -0400
Received: from HOUSLEY-LAP.rsasecurity.com (HOUSLEY-LAP [10.3.1.184]) by exna00.securitydynamics.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id TCB01R2G; Mon, 17 Sep 2001 11:43:16 -0400
From: "Housley, Russ" <[e-mail]>
To: "Pawling, John" <[e-mail]>
Cc: "SMIME WG (E-mail)" <[e-mail]>
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 5.0.1
Date: Mon, 17 Sep 2001 11:42:52 -0400
Subject: Re: cmsalg-04 Comments
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>

John:

>1) Sec 2.1, last para, 2nd and 3rd sentences: Please replace:
>
>OLD: "Implementations MUST accept SHA-1 AlgorithmIdentifiers with absent
>parameters.   Implementations MUST accept SHA-1 AlgorithmIdentifiers with
>absent parameters."
>
>NEW: "Implementations MUST accept SHA-1 AlgorithmIdentifiers with absent
>parameters.   Implementations MUST accept SHA-1 AlgorithmIdentifiers with
>NULL parameters."

Ooops.  Done.

Russ


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id f8DJZI709176 for ietf-smime-bks; Thu, 13 Sep 2001 12:35:18 -0700 (PDT)
Received: from email.nist.gov (email.nist.gov [129.6.2.7]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f8DJVtD09123; Thu, 13 Sep 2001 12:31:55 -0700 (PDT)
Received: from cspa06.nist.gov (cspa06.ncsl.nist.gov [129.6.54.23]) by email.nist.gov (8.9.3/8.9.3) with ESMTP id PAA09954; Thu, 13 Sep 2001 15:31:56 -0400 (EDT)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 5.0
Date: Thu, 13 Sep 2001 15:30:38 -0400
To: [e-mail], [e-mail]
From: Michael Chernick <[e-mail]>
Subject: Reminder - Draft NIST S/MIME Profile - Comment Period Ends Soon
Cc: [e-mail], [e-mail]
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="=====================_1829360==_.ALT"
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>

--=====================_1829360==_.ALT
Content-Type: text/plain; charset="us-ascii"; format=flowed

A Reminder.

At the SMIME session at the London IETF meeting, it was suggested that
NIST extend the deadline for comments on the Draft NIST S/MIME V3 Client
Profile.  Also, it was suggested that this notice be sent to the PKIX list
as well as the SMIME list. The deadline for comments was extended
until 17 September 2001.  THIS DATE IS FAST APPROACHING.
(NEXT WEEK.)

Thanks,
   Mike Chernick


Here's the original  announcement sent out
by Tim Polk on Monday, 2 July 2001 to the SMIME list.

---------Original Message Sent by Tim Polk to SMIME List on 2 July---------
FYI,

I have attached below the announcement for a recently released NIST draft
document concerning S/MIME V3. The document is intended to define an
appropriate subset of the S/MIME standards for broad application in the U.S.
Federal Government. NIST will be supporting this document through the
development of an automated conformance testing tool. We hope the deployment
of this tool will ease the development of conformant S/MIME V3 clients!

We are very interested in comments from both developers and the user
community. Please take the time to review the draft profile and NIST's plans
for the automated testing facility. We would appreciate comments on the
profile by 17 August 2001 (now extended to 17 September). Please send
comments to Mike Chernick (NIST's S/MIME project leader) at 
<[e-mail]>.

BTW, Mike will be presenting an overview of this project in the S/MIME WG
during the London IETF meeting. Both Mike and I will be there all week, and
will be available to discuss this project.

Thanks!

Tim Polk

----------------------
The U.S. National Institute of Standards and Technology (NIST) has recently
released a draft S/MIME V3 Client Profile. This profile was produced as
guidance in the development and procurement of commercial-off-the-shelf (COTS)
S/MIME-compliant products. This profile document identifies requirements for a
secure and interoperable S/MIME V3 client implementation. The profile cites
requirements for sending and receiving both signed and encrypted messages, as
well as requirements for signed receipt processing.

Although the S/MIME specifications were designed to promote interoperable
secure electronic mail, implementations may support different optional 
services
and the specifications may unintentionally allow multiple interpretations. 
As a
result, different implementations of S/MIME may not be fully interoperable or
provide the desired level of security. Conformance to this proposed profile
will help to assure that S/MIME implementations will be able to interoperate
and provide reasonable security assurance to users.

The Draft Profile is available (in PDF format) for public comment at:
http://csrc.ncsl.nist.gov/pki/smime/draft_SMIMEProfile.pdf

Comments are requested by (**was 17 August 2001**) *****NOW EXTENDED TO
17 September 2001***** and should be sent to [e-mail].

NIST is developing tests and testing tools to determine the level of
conformance of an S/MIME V3 client implementation with this profile. It is
planned that within the next several months, NIST will have a remote testing
facility on-line which will allow S/MIME V3 messages to be sent to the NIST
test site for processing to determine if the remotely generated messages
conform to the profile. In addition, messages may be sent to the test site to
cause the NIST site to emit S/MIME V3 messages so that a remote system may
receive S/MIME V3 messages, and verify that remote system can process the
messages correctly.

Further information on the NIST S/MIME Program may be obtained at
http://csrc.ncsl.nist.gov/pki/smime/welcome.htm or by
contacting Michael Chernick at <[e-mail]>.


----------------------------------------------------------------------------------
C. Michael Chernick
[phone]   [e-mail]
Computer Security Division
National Institute of Standards and Technology (NIST)
----------------------------------------------------------------------------------


--=====================_1829360==_.ALT
Content-Type: text/html; charset="us-ascii"

<html>
A Reminder.<br>
<br>
At the SMIME session at the London IETF meeting, it was suggested that
<br>
NIST extend the deadline for comments on the Draft NIST S/MIME V3 Client
<br>
Profile.&nbsp; Also, it was suggested that this notice be sent to the
PKIX list <br>
as well as the SMIME list. The deadline for comments was extended <br>
until 17 September 2001.&nbsp; THIS DATE IS FAST APPROACHING.&nbsp; 
<br>
(NEXT WEEK.)<br>
<br>
Thanks, <br>
&nbsp; Mike Chernick<br>
<br>
<br>
Here's the original&nbsp; announcement sent out <br>
by Tim Polk on Monday, 2 July 2001 to the SMIME list. <br>
<br>
---------Original Message Sent by Tim Polk to SMIME List on 2
July--------- <br>
FYI,<br>
<br>
I have attached below the announcement for a recently released NIST draft
<br>
document concerning S/MIME V3. The document is intended to define an
<br>
appropriate subset of the S/MIME standards for broad application in the
U.S. <br>
Federal Government. NIST will be supporting this document through the
<br>
development of an automated conformance testing tool. We hope the
deployment <br>
of this tool will ease the development of conformant S/MIME V3
clients!<br>
<br>
We are very interested in comments from both developers and the user
<br>
community. Please take the time to review the draft profile and NIST's
plans <br>
for the automated testing facility. We would appreciate comments on the
<br>
profile by 17 August 2001 (now extended to 17 September). Please send
<br>
comments to Mike Chernick (NIST's S/MIME project leader) at
&lt;[e-mail]&gt;.<br>
<br>
BTW, Mike will be presenting an overview of this project in the S/MIME WG
<br>
during the London IETF meeting. Both Mike and I will be there all week,
and <br>
will be available to discuss this project.<br>
<br>
Thanks!<br>
<br>
Tim Polk<br>
<br>
----------------------<br>
The U.S. National Institute of Standards and Technology (NIST) has
recently <br>
released a draft S/MIME V3 Client Profile. This profile was produced as
<br>
guidance in the development and procurement of commercial-off-the-shelf
(COTS) <br>
S/MIME-compliant products. This profile document identifies requirements
for a <br>
secure and interoperable S/MIME V3 client implementation. The profile
cites <br>
requirements for sending and receiving both signed and encrypted
messages, as <br>
well as requirements for signed receipt processing.<br>
<br>
Although the S/MIME specifications were designed to promote interoperable
<br>
secure electronic mail, implementations may support different optional
services <br>
and the specifications may unintentionally allow multiple
interpretations. As a <br>
result, different implementations of S/MIME may not be fully
interoperable or <br>
provide the desired level of security. Conformance to this proposed
profile <br>
will help to assure that S/MIME implementations will be able to
interoperate <br>
and provide reasonable security assurance to users.<br>
<br>
The Draft Profile is available (in PDF format) for public comment at:
<br>
<font color="#0000FF"><u><a href="http://csrc.ncsl.nist.gov/pki/smime/draft_SMIMEProfile.pdf" eudora="autourl">http://csrc.ncsl.nist.gov/pki/smime/draft_SMIMEProfile.</a><a href="http://csrc.ncsl.nist.gov/pki/smime/draft_SMIMEProfile.pdf" eudora="autourl">pdf<br>
<br>
</a></u></font>Comments are requested by (**was 17 August 2001**)
*****NOW EXTENDED TO <br>
17 September 2001***** and should be sent to [e-mail].<br>
<br>
NIST is developing tests and testing tools to determine the level of
<br>
conformance of an S/MIME V3 client implementation with this profile. It
is <br>
planned that within the next several months, NIST will have a remote
testing <br>
facility on-line which will allow S/MIME V3 messages to be sent to the
NIST <br>
test site for processing to determine if the remotely generated messages
<br>
conform to the profile. In addition, messages may be sent to the test
site to <br>
cause the NIST site to emit S/MIME V3 messages so that a remote system
may <br>
receive S/MIME V3 messages, and verify that remote system can process the
<br>
messages correctly.<br>
<br>
Further information on the NIST S/MIME Program may be obtained at <br>
<font color="#0000FF"><u><a href="http://csrc.ncsl.nist.gov/pki/smime/welcome.htm" eudora="autourl">http://csrc.ncsl.nist.gov/pki/smime/welcome.</a><a href="http://csrc.ncsl.nist.gov/pki/smime/welcome.htm" eudora="autourl">htm</a></u></font>
or by <br>
contacting Michael Chernick at &lt;[e-mail]&gt;.<br>
<br>
<x-sigsep><p></x-sigsep>
----------------------------------------------------------------------------------<br>
C. Michael Chernick<br>
[phone]&nbsp;&nbsp; [e-mail]<br>
Computer Security Division <br>
National Institute of Standards and Technology (NIST)<br>
----------------------------------------------------------------------------------<br>
<br>
</html>

--=====================_1829360==_.ALT--



Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id f8DHsT207383 for ietf-smime-bks; Thu, 13 Sep 2001 10:54:29 -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 f8DHsSD07379 for <[e-mail]>; Thu, 13 Sep 2001 10:54:28 -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 NAA11229; Thu, 13 Sep 2001 13:54:45 -0400 (EDT)
Message-Id: <[e-mail]>
To: IETF-Announce: ;
Cc: RFC Editor <[e-mail]>
Cc: Internet Architecture Board <[e-mail]>
Cc: [e-mail]
From: The IESG <[e-mail]>
Subject: Document Action: Domain Security Services using S/MIME to Experimental
Date: Thu, 13 Sep 2001 13:54:44 -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 the Internet-Draft 'Domain Security Services
using S/MIME' <draft-ietf-smime-domsec-09.txt> as an Experimental RFC.
This document is the product of the S/MIME Mail Security Working
Group.

The IESG contact persons are Jeffrey Schiller and Marcus Leech.




Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id f8DC1Zj20985 for ietf-smime-bks; Thu, 13 Sep 2001 05:01:35 -0700 (PDT)
Received: from smtp-a.capu.net (IDENT:[e-mail] [64.50.133.50]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f8DC1YD20981 for <[e-mail]>; Thu, 13 Sep 2001 05:01:34 -0700 (PDT)
Received: from bonattigateway (dial-216-18.capu.net [64.50.216.18]) by smtp-a.capu.net (8.9.3/8.9.3) with SMTP id IAA03226; Thu, 13 Sep 2001 08:01:28 -0400
From: "Bonatti, Chris" <[e-mail]>
To: "Hegde, Vijaykumar" <[e-mail]>
Cc: <[e-mail]>
Subject: RE: S/MIME and X.400
Date: Thu, 13 Sep 2001 08:01:28 -0400
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
Importance: Normal
In-Reply-To: <[e-mail]>
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id f8DC1YD20982
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 Vijay,

	You should see the I-Ds draft-ietf-smime-x400wrap-04 and draft-ietf-smime-x400transport-03.  In brief, x400wrap describes wrapping X.400 content types inside a CMS object, and x400transport describes conveying a CMS object over an X.400 transport system as an X.400 content type itself.  Except in the case of a forwarded message, CMS objects are not embedded in X.400 content.

	In ASN.1 terms, a CMS 'ContentInfo' object is plugged into the X.400 'content' field in X.411.  The content is identified in the 'content-type' field by either of the following OID values depending upon whether or not it is MIME encoded.

	id-data OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840)
	rsadsi(113549) pkcs(1) pkcs7(7) 1 }

	id-ct-contentInfo  OBJECT IDENTIFIER ::= { iso(1) member-body(2)
	us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16)
	content-types(1) 6}

The x400wrap draft mainly specifies some specific uses of options in CMS appropriate to X.400 content.

	Plz let me know if I can answer any more questions.

Chris B.



 ---------------------------------------------------------------
 |  International Electronic Communication Analysts, Inc.      |
 |  Christopher D. Bonatti             15309 Turkey Foot Road  |
 |  Principal Engineer              Darnestown, Md 20878-3640  |
 |  [e-mail]   Tel: [phone]   Fax: [phone]  |
 ---------------------------------------------------------------

-----Original Message-----
From: [e-mail]
[mailto:[e-mail]]On Behalf Of Hegde, Vijaykumar
Sent: Tuesday, September 11, 2001 03:04
To: [e-mail]
Subject: S/MIME and X.400



Hello,
	
	I have an application where in I have to build an X.400 message. The
"Content" of the message would be a CMS object. How do I insert a CMS object
into the  X.400 Content ?
	alternatively,  How will such a message look like in ASN.1 form ? 


Thanks in advance,
Vijay Hegde



Received: by above.proper.com (8.11.6/8.11.3) id f8D7Ak227284 for ietf-smime-bks; Thu, 13 Sep 2001 00:10:46 -0700 (PDT)
Received: from iaik.tu-graz.ac.at (excalibur.iaik.tu-graz.ac.at [129.27.152.30]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f8D7AiD27275 for <[e-mail]>; Thu, 13 Sep 2001 00:10:44 -0700 (PDT)
Received: from edison [129.27.152.84] by iaik.tu-graz.ac.at (SMTPD32-6.06) id ABF16A360136; Thu, 13 Sep 2001 09:10:41 +0200
From: "Dieter Bratko" <[e-mail]>
To: "Pawling, John" <[e-mail]>, "SMIME WG \(E-mail\)" <[e-mail]>
Subject: AW: cmsalg-02 RSA OID Proposal
Date: Thu, 13 Sep 2001 09:15:21 +0200
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200
In-Reply-To: <[e-mail]>
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id f8D7AjD27279
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 John,

Yes, I used SHA-1.

(unfortunately I received Terry Hayes´ message after I have posted
my mail to the list. Otherwise I would not have posted the message
since basically it has the same meaning)

Regards,
Dieter

-----Ursprüngliche Nachricht-----
Von: [e-mail]
[mailto:[e-mail]]Im Auftrag von Pawling, John
Gesendet: Mittwoch, 12. September 2001 16:22
An: 'Dieter Bratko'; SMIME WG (E-mail)
Betreff: RE: cmsalg-02 RSA OID Proposal



Dieter,

Thank you for conducting these tests.  It is extremely useful information.
I have one question regarding your testing.  Did you use SHA-1 as the
message digest algorithm in the signed S/MIME message that you sent to
Netscape Messenger 4.7 that included the rsaEncryption OID in the signedData
signerInfo signatureAlgorithm field?  

===========================================
John Pawling, [e-mail]
Getronics Government Solutions, LLC
===========================================

-----Ursprüngliche Nachricht-----
Von: [e-mail]
[mailto:[e-mail]]Im Auftrag von Pawling, John
Gesendet: Mittwoch, 12. September 2001 16:22
An: 'Dieter Bratko'; SMIME WG (E-mail)
Betreff: RE: cmsalg-02 RSA OID Proposal



Dieter,

Thank you for conducting these tests.  It is extremely useful information.
I have one question regarding your testing.  Did you use SHA-1 as the
message digest algorithm in the signed S/MIME message that you sent to
Netscape Messenger 4.7 that included the rsaEncryption OID in the signedData
signerInfo signatureAlgorithm field?  

===========================================
John Pawling, [e-mail]
Getronics Government Solutions, LLC
===========================================




Received: by above.proper.com (8.11.6/8.11.3) id f8CERnn19813 for ietf-smime-bks; Wed, 12 Sep 2001 07:27:49 -0700 (PDT)
Received: from wfhqex05.gfgsi.com (netva01.getronicsgov.com [206.137.100.2]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f8CERmD19809 for <[e-mail]>; Wed, 12 Sep 2001 07:27:48 -0700 (PDT)
Received: by wfhqex05.gfgsi.com with Internet Mail Service (5.5.2653.19) id <R052XBMC>; Wed, 12 Sep 2001 10:27:55 -0400
Message-ID: <[e-mail]>
From: "Pawling, John" <[e-mail]>
To: "'[e-mail]'" <[e-mail]>, [e-mail]
Subject: RE: cmsalg-02 RSA OID Proposal
Date: Wed, 12 Sep 2001 10:27:52 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
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>

Terry,

Thank you for reporting that the cmsalg-02 proposal to require the use of
the md5WithRSAEncryption or sha1WithRSAEncryption OID (as appropriate) in
the signedData signerInfo signatureAlgorithm field when the RSA (PKCS #1
v1.5) algorithm is used as part of the signature generation process is
incompatible with the Netscape Communicator S/MIME (CMS) implementation. 

Based on that fact, I agree that the son-of-RFC2633 S/MIME v3 Message Spec
should mandate the use of the rsaEncryption OID in the signedData signerInfo
signatureAlgorithm field when the RSA (PKCS #1 v1.5) algorithm is used as
part of the signature generation process.

===========================================
John Pawling, [e-mail]
Getronics Government Solutions, LLC
===========================================



Received: by above.proper.com (8.11.6/8.11.3) id f8CEMHS19424 for ietf-smime-bks; Wed, 12 Sep 2001 07:22:17 -0700 (PDT)
Received: from wfhqex05.gfgsi.com (netva01.getronicsgov.com [206.137.100.2]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f8CEMGD19420 for <[e-mail]>; Wed, 12 Sep 2001 07:22:16 -0700 (PDT)
Received: by wfhqex05.gfgsi.com with Internet Mail Service (5.5.2653.19) id <R052XBJR>; Wed, 12 Sep 2001 10:22:22 -0400
Message-ID: <[e-mail]>
From: "Pawling, John" <[e-mail]>
To: "'Dieter Bratko'" <[e-mail]>, "SMIME WG (E-mail)" <[e-mail]>
Subject: RE: cmsalg-02 RSA OID Proposal
Date: Wed, 12 Sep 2001 10:22:14 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
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>

Dieter,

Thank you for conducting these tests.  It is extremely useful information.
I have one question regarding your testing.  Did you use SHA-1 as the
message digest algorithm in the signed S/MIME message that you sent to
Netscape Messenger 4.7 that included the rsaEncryption OID in the signedData
signerInfo signatureAlgorithm field?  

===========================================
John Pawling, [e-mail]
Getronics Government Solutions, LLC
===========================================


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id f8BFruc23011 for ietf-smime-bks; Tue, 11 Sep 2001 08:53:56 -0700 (PDT)
Received: from iaik.tu-graz.ac.at (excalibur.iaik.tu-graz.ac.at [129.27.152.30]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f8BFrsD23002 for <[e-mail]>; Tue, 11 Sep 2001 08:53:54 -0700 (PDT)
Received: from edison [129.27.152.84] by iaik.tu-graz.ac.at (SMTPD32-6.06) id A39084D00AA; Tue, 11 Sep 2001 17:53:52 +0200
From: "Dieter Bratko" <[e-mail]>
To: "Pawling, John" <[e-mail]>, "SMIME WG \(E-mail\)" <[e-mail]>
Subject: AW: cmsalg-02 RSA OID Proposal
Date: Tue, 11 Sep 2001 17:58:25 +0200
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200
In-Reply-To: <[e-mail]>
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id f8BFrtD23006
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,

> Is this change going to cause backwards compatibility problems with legacy
> CMS implementations?

Since CMS respectively S/MIMEv3 claims for backward compability to PKCS#7v1.5
respectively S/MIMEv2 should backward compatibility problems with  
PKCS#7v1.5 and S/MIMEv2 applications not be of concern, too?

Just for testing I have tried to send two signed mails to Netscape
Messenger (4.7), the one specifiying rsaEncryption as the signerInfo´s
signature algorithm, the second sha1WithRSAEncryption. Whereas the
first mail was succesfully verified, Netscape failed in verifying
the second mail by giving the following warning message:

Invalid Signature:
"Warning! In the time since the sender sent you this message and you
received it, the message appears to have been altered. Some or all of the
content of this message has been changed. You should contact the
message sender and/or your system administrator."

However, no problems for both messages when verifying with Outlook 
Express or Outlook 2000.

Regards,
Dieter Bratko, IAIK



-----Ursprüngliche Nachricht-----
Von: [e-mail]
[mailto:[e-mail]]Im Auftrag von Pawling, John
Gesendet: Freitag, 31. August 2001 17:44
An: SMIME WG (E-mail)
Betreff: cmsalg-02 RSA OID Proposal



All,

RFC2630 CMS, section 12.2.2, specifies the use of the rsaEncryption object
identifier (OID) in the signedData signerInfo signatureAlgorithm field when
the RSA (PKCS #1 v1.5) algorithm is used as part of the signature generation
process.  cmsalg-02, Section 3.2, specifies the use of the
md5WithRSAEncryption and sha1WithRSAEncryption OID (as appropriate) in the
signedData signerInfo signatureAlgorithm field (instead of the
id-rsaEncryption OID).  The cmsalg-02 proposed use of these OIDs is
consistent with their use in the RFC2459 PKIX Certificate/CRL Profile.  The
RFC2630 use of the id-rsaEncryption OID is inconsistent with RFC2459.  

Is this change going to cause backwards compatibility problems with legacy
CMS implementations?

The current release of the S/MIME Freeware Library (SFL) (available from
<http://www.getronicsgov.com/hot/sfl_lib.htm>) can successfully verify a
signedData content type that includes a signerInfo signatureAlgorithm field
that includes the md5WithRSAEncryption, sha1WithRSAEncryption or
rsaEncryption OID (as appropriate).  Therefore, the proposed cmsalg-02 use
of the md5WithRSAEncryption and sha1WithRSAEncryption OID (as appropriate)
would not cause backwards compatibility problems for those applications that
use the SFL along with a crypto library that supports the algorithms
indicated by the OIDs. 

Feedback from others is welcome!  This is an important issue.  

===========================================
John Pawling, [e-mail]
Getronics Government Solutions, LLC
===========================================




Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id f8BEwJm18328 for ietf-smime-bks; Tue, 11 Sep 2001 07:58:19 -0700 (PDT)
Received: from netscape.com (c3po.netscape.com [205.217.237.46]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f8BEwID18324 for <[e-mail]>; Tue, 11 Sep 2001 07:58:18 -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 f8BEvmm03499 for <[e-mail]>; Tue, 11 Sep 2001 07:57:48 -0700 (PDT)
Received: from netscape.com ([205.217.229.87]) by judge.mcom.com (Netscape Messaging Server 4.15) with ESMTP id GJI6WY02.WLW for <[e-mail]>; Tue, 11 Sep 2001 07:58:10 -0700 
Message-ID: <[e-mail]>
Date: Tue, 11 Sep 2001 07:58:09 -0700
From: [e-mail] (Terry Hayes)
User-Agent: Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:0.9.3+) Gecko/20010910 Netscape6/6.2
X-Accept-Language: en-us
MIME-Version: 1.0
To: [e-mail]
Subject: Re: cmsalg-02 RSA OID Proposal
References: <[e-mail]>
Content-Type: text/plain; charset=us-ascii; format=flowed
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>

John,

The Netscape Communicator S/MIME (CMS) implementation expects the
rsaEncryption OID in the digest encryption algorithm field.  Since this
implementation was proven to interoperate (at one point) with the
Microsoft version, I suspect that both Netscape and Microsoft products
also generated messages with this OID value.

I suggest that we recommend that when CMS is used for email message
protection, and the CMS format is otherwise compatible with the v2
format (no new recipient formats, etc), the rsaEncryption OID should be
used.  Implementations should continue to accept the rsaEncryption value
for incoming messages.

Terry Hayes
[e-mail]

Pawling, John wrote:

 >All,
 >
 >I agree with Blake that the RSA signature OID change should not be made if
 >it will cause backwards compatibility problems with legacy CMS
 >implementations.  So far, we have heard that this change will NOT cause
 >problems for the following S/MIME implementations: cryptlib (according to
 >Peter Gutmann), Microsoft (according to Jim Schaad) and S/MIME Freeware
 >Library (according to John Pawling).  So far, nobody has reported that the
 >change will cause backwards compatibility problems with legacy CMS
 >implementations.  Can anybody speak for any other implementations?
 >
 >===========================================
 >John Pawling, [e-mail]
 >Getronics Government Solutions, LLC
 >===========================================
 >





Received: by above.proper.com (8.11.6/8.11.3) id f8BCQfc07587 for ietf-smime-bks; Tue, 11 Sep 2001 05:26:41 -0700 (PDT)
Received: from mailf.telia.com (mailf.telia.com [194.22.194.25]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f8BCQeD07583 for <[e-mail]>; Tue, 11 Sep 2001 05:26:40 -0700 (PDT)
Received: from arport ([212.181.94.147]) by mailf.telia.com (8.11.2/8.11.0) with SMTP id f8BCQcY22864; Tue, 11 Sep 2001 14:26:38 +0200 (CEST)
Message-ID: <005601c13abb$ac192930$0500a8c0@arport>
From: "Anders Rundgren" <[e-mail]>
To: <[e-mail]>
Cc: <[e-mail]>
References: <00be01c139ec$51909720$0500a8c0@arport> <[e-mail]> <009a01c13a05$bf7c33c0$0500a8c0@arport> <[e-mail]>
Subject: Re: S/MIME 3 Clients - Are there such?
Date: Tue, 11 Sep 2001 14:17:05 +0200
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4133.2400
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>

Michael,
It is possible that all this will be redudant as e-mail for business messages
(my line of work) is a declining activity.  The encryption scheme in e-mail is a
killer (in the negative aspect) compared to https (SSL/TLS).

I did try to force my Outlook to accept an "e-mail-less" cert but
I did not succeed.  Anyone who knows the trick?

Anders

----- Original Message -----
From: "Michael Ströder" <[e-mail]>
To: "Anders Rundgren" <[e-mail]>
Cc: <[e-mail]>
Sent: Monday, September 10, 2001 21:04
Subject: Re: S/MIME 3 Clients - Are there such?


Anders Rundgren wrote:
>
> I guess this option was introduced to be able to use your "electronic ED-Card"
> from anywhere and make the mail-system to be regarded as "transport"
> in the same way as SSL.

Note that you have to put the server's name into the CN attribute of
the SSL server's certificate subject DN. Maybe it's different in
current IETF-TLS profile draft. I did not follow that closely.

> The same could be valid for mobile-phones and PKI as well.
> I.e. the phone-number is just an identified but anyway "bearer".
>
> Or for e-business where the org-cert contains a DUNS-number which
> is more important than mail-address.  Lets say a portal with buyers
> using the same domain.

I already know all these arguments. But Joe Average user will be
unable to verify that this specific DUNS number can be assigned to a
certain e-mail address. Normal users *might* be able to perform a
complete string equality match. But not much more. People do not
understand name spaces. Period. I did enough 1st level support
especially with S/MIMEv2...

I hope that not many CAs are going to issue e-mail certificates
without e-mail address. In this particular case I regard it as an
advantage that most CAs will decide to be backwards-compatible to
S/MIMEv2.

> But it does get a little bit weird.

Snip the word "little" and you're getting closer to it...

Ciao, Michael.



Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id f8B7Laq11616 for ietf-smime-bks; Tue, 11 Sep 2001 00:21:36 -0700 (PDT)
Received: from junker.stroeder.com ([194.8.203.109]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f8B7LYD11606 for <[e-mail]>; Tue, 11 Sep 2001 00:21:34 -0700 (PDT)
Received: from stroeder.com (localhost [127.0.0.1]) by junker.stroeder.com (Postfix) with ESMTP id 3FC72157170; Mon, 10 Sep 2001 21:04:04 +0200 (CEST)
Message-ID: <[e-mail]>
Date: Mon, 10 Sep 2001 21:04:03 +0200
From: Michael =?iso-8859-1?Q?Str=F6der?= <[e-mail]>
Reply-To: [e-mail]
Organization: stroeder.com
X-Mailer: Mozilla 4.78 [en] (X11; U; Linux 2.2.19 i686)
X-Accept-Language: de-DE, de, en
MIME-Version: 1.0
To: Anders Rundgren <[e-mail]>
Cc: [e-mail]
Subject: Re: S/MIME 3 Clients - Are there such?
References: <00be01c139ec$51909720$0500a8c0@arport> <[e-mail]> <009a01c13a05$bf7c33c0$0500a8c0@arport>
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>

Anders Rundgren wrote:
> 
> I guess this option was introduced to be able to use your "electronic ED-Card"
> from anywhere and make the mail-system to be regarded as "transport"
> in the same way as SSL.

Note that you have to put the server's name into the CN attribute of
the SSL server's certificate subject DN. Maybe it's different in
current IETF-TLS profile draft. I did not follow that closely.

> The same could be valid for mobile-phones and PKI as well.
> I.e. the phone-number is just an identified but anyway "bearer".
> 
> Or for e-business where the org-cert contains a DUNS-number which
> is more important than mail-address.  Lets say a portal with buyers
> using the same domain.

I already know all these arguments. But Joe Average user will be
unable to verify that this specific DUNS number can be assigned to a
certain e-mail address. Normal users *might* be able to perform a
complete string equality match. But not much more. People do not
understand name spaces. Period. I did enough 1st level support
especially with S/MIMEv2...

I hope that not many CAs are going to issue e-mail certificates
without e-mail address. In this particular case I regard it as an
advantage that most CAs will decide to be backwards-compatible to
S/MIMEv2.

> But it does get a little bit weird.

Snip the word "little" and you're getting closer to it...

Ciao, Michael.


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id f8B7Ave10331 for ietf-smime-bks; Tue, 11 Sep 2001 00:10:57 -0700 (PDT)
Received: from zcamail05.zca.compaq.com (zcamail05.zca.compaq.com [161.114.32.105]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f8B7AuD10323 for <[e-mail]>; Tue, 11 Sep 2001 00:10:56 -0700 (PDT)
Received: by zcamail05.zca.compaq.com (Postfix, from userid 12345) id 56A4C7526; Tue, 11 Sep 2001 00:15:08 -0700 (PDT)
Received: from mailrelay01.cce.cpqcorp.net (mailrelay01.cce.cpqcorp.net [16.47.68.171]) by zcamail05.zca.compaq.com (Postfix) with ESMTP id 3E903778D for <[e-mail]>; Tue, 11 Sep 2001 00:15:08 -0700 (PDT)
Received: by mailrelay01.cce.cpqcorp.net (Postfix, from userid 12345) id 64248B59; Tue, 11 Sep 2001 02:10:42 -0500 (CDT)
Received: from diexch01.xko.dec.com (diexch01.xko.dec.com [16.138.244.57]) by mailrelay01.cce.cpqcorp.net (Postfix) with ESMTP id 488A9924 for <[e-mail]>; Tue, 11 Sep 2001 02:10:32 -0500 (CDT)
Received: by diexch01.xko.dec.com with Internet Mail Service (5.5.2650.21) id <SRKK12MJ>; Tue, 11 Sep 2001 12:33:56 +0530
Message-ID: <[e-mail]>
From: "Hegde, Vijaykumar" <[e-mail]>
To: [e-mail]
Subject: S/MIME and X.400
Date: Tue, 11 Sep 2001 12:33:56 +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>

Hello,
	
	I have an application where in I have to build an X.400 message. The
"Content" of the message would be a CMS object. How do I insert a CMS object
into the  X.400 Content ?
	alternatively,  How will such a message look like in ASN.1 form ? 


Thanks in advance,
Vijay Hegde


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id f8AFdkV25202 for ietf-smime-bks; Mon, 10 Sep 2001 08:39:46 -0700 (PDT)
Received: from femail40.sdc1.sfba.home.com (femail40.sdc1.sfba.home.com [24.254.60.34]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f8AFdjD25194 for <[e-mail]>; Mon, 10 Sep 2001 08:39:45 -0700 (PDT)
Received: from revelation ([65.4.166.11]) by femail40.sdc1.sfba.home.com (InterMail vM.4.01.03.20 201-229-121-120-20010223) with ESMTP id <20010910153942.JZSP6031.femail40.sdc1.sfba.home.com@revelation>; Mon, 10 Sep 2001 08:39:42 -0700
Reply-To: <[e-mail]>
From: "Jim Schaad" <[e-mail]>
To: "'Anders Rundgren'" <[e-mail]>, <[e-mail]>
Cc: <[e-mail]>
Subject: RE: S/MIME 3 Clients - Are there such?
Date: Mon, 10 Sep 2001 08:39:44 -0700
Message-ID: <000901c13a0e$d0df1ac0$[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.2627
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2526.0000
Importance: Normal
In-Reply-To: <009a01c13a05$bf7c33c0$0500a8c0@arport>
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id f8AFdjD25197
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>

Anders,

It is possible to configure Microsoft Outlook to allow for not having
the E-Mail address in a certificate.  However due to the "problems"
involved in getting associations correct, the decision was mad that this
should not be default behavior.

jim

> -----Original Message-----
> From: [e-mail] 
> [mailto:[e-mail]] On Behalf Of Anders Rundgren
> Sent: Monday, September 10, 2001 7:35 AM
> To: [e-mail]
> Cc: [e-mail]
> Subject: Re: S/MIME 3 Clients - Are there such?
> 
> 
> 
> Michael,
> Thanx for the answer.
> 
> I guess this option was introduced to be able to use your 
> "electronic ED-Card"
> from anywhere and make the mail-system to be regarded as "transport"
> in the same way as SSL.
> 
> The same could be valid for mobile-phones and PKI as well.
> I.e. the phone-number is just an identified but anyway "bearer".
> 
> Or for e-business where the org-cert contains a DUNS-number which
> is more important than mail-address.  Lets say a portal with buyers
> using the same domain.
> 
> But it does get a little bit weird.
> 
> Anders
> 
> ----- Original Message -----
> From: "Michael Ströder" <[e-mail]>
> To: "Anders Rundgren" <[e-mail]>
> Cc: <[e-mail]>
> Sent: Monday, September 10, 2001 15:47
> Subject: Re: S/MIME 3 Clients - Are there such?
> 
> 
> Anders Rundgren wrote:
> >
> > In S/MIME V3 e-mail address is optional.
> 
> (Sigh!)
> 
> > That's good.
> 
> Nope.
> 
> > But, are there any mail-clients that supports certs w.o. 
> mail-addresses?
> 
> Yes. I saw one made by SSE. But it will be a pain in the ass to
> teach Joe Average user to assign the right certificates to the right
> person.
> 
> Ciao, Michael.
> 



Received: by above.proper.com (8.11.6/8.11.3) id f8AEiNN20546 for ietf-smime-bks; Mon, 10 Sep 2001 07:44:23 -0700 (PDT)
Received: from mailc.telia.com (mailc.telia.com [194.22.190.4]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f8AEiLD20530 for <[e-mail]>; Mon, 10 Sep 2001 07:44:21 -0700 (PDT)
Received: from arport ([212.181.94.147]) by mailc.telia.com (8.11.2/8.11.0) with SMTP id f8AEiJd09923; Mon, 10 Sep 2001 16:44:19 +0200 (CEST)
Message-ID: <009a01c13a05$bf7c33c0$0500a8c0@arport>
From: "Anders Rundgren" <[e-mail]>
To: <[e-mail]>
Cc: <[e-mail]>
References: <00be01c139ec$51909720$0500a8c0@arport> <[e-mail]>
Subject: Re: S/MIME 3 Clients - Are there such?
Date: Mon, 10 Sep 2001 16:34:48 +0200
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4133.2400
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>

Michael,
Thanx for the answer.

I guess this option was introduced to be able to use your "electronic ED-Card"
from anywhere and make the mail-system to be regarded as "transport"
in the same way as SSL.

The same could be valid for mobile-phones and PKI as well.
I.e. the phone-number is just an identified but anyway "bearer".

Or for e-business where the org-cert contains a DUNS-number which
is more important than mail-address.  Lets say a portal with buyers
using the same domain.

But it does get a little bit weird.

Anders

----- Original Message -----
From: "Michael Ströder" <[e-mail]>
To: "Anders Rundgren" <[e-mail]>
Cc: <[e-mail]>
Sent: Monday, September 10, 2001 15:47
Subject: Re: S/MIME 3 Clients - Are there such?


Anders Rundgren wrote:
>
> In S/MIME V3 e-mail address is optional.

(Sigh!)

> That's good.

Nope.

> But, are there any mail-clients that supports certs w.o. mail-addresses?

Yes. I saw one made by SSE. But it will be a pain in the ass to
teach Joe Average user to assign the right certificates to the right
person.

Ciao, Michael.



Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id f8ADpMp17653 for ietf-smime-bks; Mon, 10 Sep 2001 06:51:22 -0700 (PDT)
Received: from junker.stroeder.com ([194.8.203.109]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f8ADpKD17649 for <[e-mail]>; Mon, 10 Sep 2001 06:51:21 -0700 (PDT)
Received: from stroeder.com (localhost [127.0.0.1]) by junker.stroeder.com (Postfix) with ESMTP id 231B81574FD; Mon, 10 Sep 2001 15:47:31 +0200 (CEST)
Message-ID: <[e-mail]>
Date: Mon, 10 Sep 2001 15:47:30 +0200
From: Michael =?iso-8859-1?Q?Str=F6der?= <[e-mail]>
Reply-To: [e-mail]
Organization: stroeder.com
X-Mailer: Mozilla 4.78 [en] (X11; U; Linux 2.2.19 i686)
X-Accept-Language: de-DE, de, en
MIME-Version: 1.0
To: Anders Rundgren <[e-mail]>
Cc: [e-mail]
Subject: Re: S/MIME 3 Clients - Are there such?
References: <00be01c139ec$51909720$0500a8c0@arport>
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>

Anders Rundgren wrote:
> 
> In S/MIME V3 e-mail address is optional.

(Sigh!)

> That's good.

Nope.

> But, are there any mail-clients that supports certs w.o. mail-addresses?

Yes. I saw one made by SSE. But it will be a pain in the ass to
teach Joe Average user to assign the right certificates to the right
person.

Ciao, Michael.


Received: by above.proper.com (8.11.6/8.11.3) id f8ABgL611332 for ietf-smime-bks; Mon, 10 Sep 2001 04:42:21 -0700 (PDT)
Received: from mailc.telia.com (mailc.telia.com [194.22.190.4]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f8ABgJD11328 for <[e-mail]>; Mon, 10 Sep 2001 04:42:20 -0700 (PDT)
Received: from arport ([212.181.94.147]) by mailc.telia.com (8.11.2/8.11.0) with SMTP id f8ABgJH16232 for <[e-mail]>; Mon, 10 Sep 2001 13:42:19 +0200 (CEST)
Message-ID: <00be01c139ec$51909720$0500a8c0@arport>
From: "Anders Rundgren" <[e-mail]>
To: <[e-mail]>
Subject: S/MIME 3 Clients - Are there such?
Date: Mon, 10 Sep 2001 13:32:48 +0200
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4133.2400
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>

In S/MIME V3 e-mail address is optional.
That's good.

But, are there any mail-clients that supports certs w.o. mail-addresses?
Microsoft's does not AFAIK.  At least not on sending.  

Regards
Anders Rundgren
X-OBI



Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id f8AAu9w06791 for ietf-smime-bks; Mon, 10 Sep 2001 03:56:09 -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 f8AAu8D06786 for <[e-mail]>; Mon, 10 Sep 2001 03:56:08 -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 GAA08557; Mon, 10 Sep 2001 06:54:41 -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-domsec-09.txt
Date: Mon, 10 Sep 2001 06:54:40 -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		: Domain Security Services using S/MIME
	Author(s)	: T. Dean, W. Ottaway
	Filename	: draft-ietf-smime-domsec-09.txt
	Pages		: 8
	Date		: 07-Sep-01
	
This document describes how the S/MIME protocol can be processed and
generated by a number of components of a communication system, such as
message transfer agents, guards and gateways to deliver security
services. These services are collectively referred to as 'Domain
Security Services'. The mechanisms described in this document are
designed to solve a number of interoperability problems and technical
limitations that arise when different security domains wish to
communicate securely, for example when two domains use incompatible
messaging technologies such as X.400 series and SMTP/MIME, or when a
single domain wishes to communicate securely with one of its members
residing on an untrusted domain. The scenarios covered by this document
are domain to domain, individual to domain and domain to individual
communications. This document is also applicable to organisations and
enterprises that have internal PKIs which are not accessible by the
outside world, but wish to interoperate securely using the S/MIME
protocol.

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

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

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 f87KbP021591 for ietf-smime-bks; Fri, 7 Sep 2001 13:37:25 -0700 (PDT)
Received: from wfhqex05.gfgsi.com (netva01.getronicsgov.com [206.137.100.2]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f87KbOD21587 for <[e-mail]>; Fri, 7 Sep 2001 13:37:24 -0700 (PDT)
Received: by wfhqex05.gfgsi.com with Internet Mail Service (5.5.2653.19) id <R052WMFN>; Fri, 7 Sep 2001 16:37:33 -0400
Message-ID: <[e-mail]>
From: "Pawling, John" <[e-mail]>
To: "SMIME WG (E-mail)" <[e-mail]>
Subject: cmsalg-04 Comments
Date: Fri, 7 Sep 2001 16:37:26 -0400 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
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>

All,

I have the following comments to cmsalg-04:  

1) Sec 2.1, last para, 2nd and 3rd sentences: Please replace:

OLD: "Implementations MUST accept SHA-1 AlgorithmIdentifiers with absent
parameters.   Implementations MUST accept SHA-1 AlgorithmIdentifiers with
absent parameters." 

NEW: "Implementations MUST accept SHA-1 AlgorithmIdentifiers with absent
parameters.   Implementations MUST accept SHA-1 AlgorithmIdentifiers with
NULL parameters." 


2) Sec 3.2: See separate message exchange subject, "cmsalg-02 RSA OID
Proposal".


===========================================
John Pawling, [e-mail]
Getronics Government Solutions, LLC
===========================================



Received: by above.proper.com (8.11.6/8.11.3) id f86Lh9B15493 for ietf-smime-bks; Thu, 6 Sep 2001 14:43:09 -0700 (PDT)
Received: from hawaii.deming.com (hawaii.deming.com [208.236.41.139]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f86Lh8D15489 for <[e-mail]>; Thu, 6 Sep 2001 14:43:08 -0700 (PDT)
Received: from 208.236.41.137 by hawaii.deming.com with ESMTP ( Tumbleweed MMS SMTP Relay (MMS v5.0)); Thu, 06 Sep 2001 14:43:02 -0700
X-Server-Uuid: F4BC6258-86A5-40F3-9714-0CF63E081F09
Received: by cane.deming.com with Internet Mail Service (5.5.2650.21) id <R9KF62ZR>; Thu, 6 Sep 2001 14:43:02 -0700
Message-ID: <[e-mail]>
From: "Blake Ramsdell" <[e-mail]>
To: "'Pawling, John'" <[e-mail]>, [e-mail]
Subject: RE: cmsalg-02 RSA OID Proposal
Date: Thu, 6 Sep 2001 14:42:57 -0700
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
X-WSS-ID: 1789326C11787-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>

Yes, that seems reasonable.  As long as the CMS spec does not preclude the
use of rsaEncryption in this section, the MSG draft can specify how
important it is to use it for backward compatibility.

Blake

-----Original Message-----
From: Pawling, John [mailto:[e-mail]]
Sent: Thursday, September 06, 2001 12:26 PM
To: [e-mail]
Subject: RE: cmsalg-02 RSA OID Proposal



Russ,

I like that idea.  That strategy would allow the S/MIME Message Spec to
specify the use of the rsaEncryption OID to preserve backwards compatibility
with legacy S/MIME implementations (if that is what is decided by the
group).  It would also allow another protocol that employs CMS to specify
the use of the md5WithRSAEncryption or sha1WithRSAEncryption OID (as
appropriate).

===========================================
John Pawling, [e-mail]
Getronics Government Solutions, LLC
===========================================


-----Original Message-----
From: Housley, Russ [mailto:[e-mail]]
Sent: Thursday, September 06, 2001 11:31 AM
To: [e-mail]
Subject: RE: cmsalg-02 RSA OID Proposal



Hey everyone.

Perhaps the CMSALG document should include the specifications for both 
approaches.  Then, the upcoming MSG update will deal with the MUST and 
SHOULD statements.

What do you think?

Russ




Received: by above.proper.com (8.11.6/8.11.3) id f86JPjL12617 for ietf-smime-bks; Thu, 6 Sep 2001 12:25:45 -0700 (PDT)
Received: from wfhqex05.gfgsi.com (netva01.getronicsgov.com [206.137.100.2]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f86JPiD12613 for <[e-mail]>; Thu, 6 Sep 2001 12:25:44 -0700 (PDT)
Received: by wfhqex05.gfgsi.com with Internet Mail Service (5.5.2653.19) id <R052WDNJ>; Thu, 6 Sep 2001 15:25:52 -0400
Message-ID: <[e-mail]>
From: "Pawling, John" <[e-mail]>
To: [e-mail]
Subject: RE: cmsalg-02 RSA OID Proposal
Date: Thu, 6 Sep 2001 15:25:51 -0400 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
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,

I like that idea.  That strategy would allow the S/MIME Message Spec to
specify the use of the rsaEncryption OID to preserve backwards compatibility
with legacy S/MIME implementations (if that is what is decided by the
group).  It would also allow another protocol that employs CMS to specify
the use of the md5WithRSAEncryption or sha1WithRSAEncryption OID (as
appropriate).

===========================================
John Pawling, [e-mail]
Getronics Government Solutions, LLC
===========================================


-----Original Message-----
From: Housley, Russ [mailto:[e-mail]]
Sent: Thursday, September 06, 2001 11:31 AM
To: [e-mail]
Subject: RE: cmsalg-02 RSA OID Proposal



Hey everyone.

Perhaps the CMSALG document should include the specifications for both 
approaches.  Then, the upcoming MSG update will deal with the MUST and 
SHOULD statements.

What do you think?

Russ



Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id f86IwAT11901 for ietf-smime-bks; Thu, 6 Sep 2001 11:58:10 -0700 (PDT)
Received: from tholian.securitydynamics.com (mail.rsasecurity.com [204.167.112.129]) by above.proper.com (8.11.6/8.11.3) with SMTP id f86Iw9D11897 for <[e-mail]>; Thu, 6 Sep 2001 11:58:09 -0700 (PDT)
Received: from sdtihq24.securid.com by tholian.securitydynamics.com via smtpd (for mail.imc.org [208.184.76.43]) with SMTP; 6 Sep 2001 18:55:35 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 OAA28581 for <[e-mail]>; Thu, 6 Sep 2001 14:57:27 -0400 (EDT)
Received: by exna00.securitydynamics.com with Internet Mail Service (5.5.2653.19) id <SMJF0QFH>; Thu, 6 Sep 2001 14:57:27 -0400
Received: from HOUSLEY-LAP.rsasecurity.com (housley-lap.securitydynamics.com [10.100.23.218]) by exna00.securitydynamics.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id SMJF0QFA; Thu, 6 Sep 2001 14:57:20 -0400
From: "Housley, Russ" <[e-mail]>
To: "Pawling, John" <[e-mail]>
Cc: "SMIME WG (E-mail)" <[e-mail]>
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 5.0.1
Date: Thu, 06 Sep 2001 14:44:41 -0400
Subject: RE: rfc2630bis-03 Comment
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>

John:

>1) 1rst paragraph, second sentence: Please replace:
>
>OLD: "but the ASN.1 type of the content itself was variable in PKCS #7
>SignedData content type."
>
>NEW: "but the ASN.1 type of the content itself is variable in the PKCS #7
>SignedData content type."

Done.

>2) last paragraph, last sentence: Please replace:
>
>OLD: "eContent contains AuthetiCode signing information"
>
>NEW: "eContent contains AuthentiCode signing information"

Done.

Russ


Received: by above.proper.com (8.11.6/8.11.3) id f86HaqY09715 for ietf-smime-bks; Thu, 6 Sep 2001 10:36:52 -0700 (PDT)
Received: from wfhqex05.gfgsi.com (netva01.getronicsgov.com [206.137.100.2]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f86HapD09711 for <[e-mail]>; Thu, 6 Sep 2001 10:36:51 -0700 (PDT)
Received: by wfhqex05.gfgsi.com with Internet Mail Service (5.5.2653.19) id <R052WC1K>; Thu, 6 Sep 2001 13:36:59 -0400
Message-ID: <[e-mail]>
From: "Pawling, John" <[e-mail]>
To: "SMIME WG (E-mail)" <[e-mail]>
Subject: RE: rfc2630bis-03 Comment
Date: Thu, 6 Sep 2001 13:36:59 -0400 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
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,

Thank you for agreeing to incorporate my comments.  I concur with your
editorial changes with the following minor comments:

1) 1rst paragraph, second sentence: Please replace:

OLD: "but the ASN.1 type of the content itself was variable in PKCS #7
SignedData content type."

NEW: "but the ASN.1 type of the content itself is variable in the PKCS #7
SignedData content type."


2) last paragraph, last sentence: Please replace:

OLD: "eContent contains AuthetiCode signing information"

NEW: "eContent contains AuthentiCode signing information"

===========================================
John Pawling, [e-mail]
Getronics Government Solutions, LLC
===========================================



Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id f86HX0U09634 for ietf-smime-bks; Thu, 6 Sep 2001 10:33:00 -0700 (PDT)
Received: from tholian.securitydynamics.com (mail.rsasecurity.com [204.167.112.129]) by above.proper.com (8.11.6/8.11.3) with SMTP id f86HWsD09628 for <[e-mail]>; Thu, 6 Sep 2001 10:32:54 -0700 (PDT)
Received: from sdtihq24.securitydynamics.com by tholian.securitydynamics.com via smtpd (for mail.imc.org [208.184.76.43]) with SMTP; 6 Sep 2001 17:30:20 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 NAA13455 for <[e-mail]>; Thu, 6 Sep 2001 13:30:13 -0400 (EDT)
Received: by exna00.securitydynamics.com with Internet Mail Service (5.5.2653.19) id <SMJF0K7L>; Thu, 6 Sep 2001 11:39:32 -0400
Received: from HOUSLEY-LAP.rsasecurity.com (housley-lap.securitydynamics.com [10.100.23.218]) by exna00.securitydynamics.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id SMJF0K5Y; Thu, 6 Sep 2001 11:31:43 -0400
From: "Housley, Russ" <[e-mail]>
To: [e-mail]
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 5.0.1
Date: Thu, 06 Sep 2001 11:31:11 -0400
Subject: RE: cmsalg-02 RSA OID Proposal
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>

Hey everyone.

Perhaps the CMSALG document should include the specifications for both 
approaches.  Then, the upcoming MSG update will deal with the MUST and 
SHOULD statements.

What do you think?

Russ


At 05:10 PM 9/5/2001 -0400, Pawling, John wrote:

>Blake,
>
>I agree with your point that the RFC 2630 specification of
>signatureAlgorithm OIDs is inconsistent (i.e. id-dsa-with-sha1 is
>inconsistent with rsaEncryption).  However, I disagree with your statement
>that id-dsa-with-sha1 doesn't work as an indicator of "what identifier from
>a certificate's SubjectPublicKeyInfo would be required to verify this
>signature".  It is straightforward to develop CMS implementations to
>recognize that the presence of the id-dsa-with-sha1 OID in the signedData
>signerInfo signatureAlgorithm field indicates that the certificate required
>to verify the signature must contain the id-dsa OID in the
>SubjectPublicKeyInfo algorithm field.  Similarly, it is straightforward to
>develop CMS implementations to recognize that the presence of either the
>md5WithRSAEncryption or sha1WithRSAEncryption OID in the signedData
>signerInfo signatureAlgorithm field indicates that the certificate required
>to verify the signature must contain the rsaEncryption OID in the
>SubjectPublicKeyInfo algorithm field.
>
>===========================================
>John Pawling, [e-mail]
>Getronics Government Solutions, LLC
>===========================================


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id f86H74C08827 for ietf-smime-bks; Thu, 6 Sep 2001 10:07:04 -0700 (PDT)
Received: from tholian.securitydynamics.com (mail.rsasecurity.com [204.167.112.129]) by above.proper.com (8.11.6/8.11.3) with SMTP id f86H72D08822 for <[e-mail]>; Thu, 6 Sep 2001 10:07:02 -0700 (PDT)
Received: from sdtihq24.securitydynamics.com by tholian.securitydynamics.com via smtpd (for mail.imc.org [208.184.76.43]) with SMTP; 6 Sep 2001 17:04:24 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 NAA09764 for <[e-mail]>; Thu, 6 Sep 2001 13:06:56 -0400 (EDT)
Received: by exna00.securitydynamics.com with Internet Mail Service (5.5.2653.19) id <SMJF0KGQ>; Thu, 6 Sep 2001 11:02:23 -0400
Received: from HOUSLEY-LAP.rsasecurity.com (housley-lap.securitydynamics.com [10.100.23.218]) by exna00.securitydynamics.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id SMJF0KGN; Thu, 6 Sep 2001 11:02:21 -0400
From: "Housley, Russ" <[e-mail]>
To: "Pawling, John" <[e-mail]>
Cc: "SMIME WG (E-mail)" <[e-mail]>
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 5.0.1
Date: Thu, 06 Sep 2001 11:02:17 -0400
Subject: Re: rfc2630bis-03 Comment
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>

John:

Thank you for your careful review.  I agree with all of the points made in 
you proposed replacement to section 5.2.1.  I did want to replace "MAY" 
with "can" in two places, and I made a few other editorial changes.  Please 
confirm that the following text is acceptable.

Russ

- - - - - - - - - -

5.2.1  [*** NEW ***] Compatibility with PKCS #7

    This section contains a word of warning to implementers that wish to
    support both the CMS and PKCS #7 [PKCS#7] SignedData content types.
    Both the CMS and PKCS #7 identify the type of the encapsulated
    content with an object identifier, but the ASN.1 type of the content
    itself was variable in PKCS #7 SignedData content type.

    PKCS #7 defines content as:

       content [0] EXPLICIT ANY DEFINED BY contentType OPTIONAL

    The CMS defines eContent as:

       eContent [0] EXPLICIT OCTET STRING OPTIONAL

    The CMS definition is much easier to use in most applications, and it
    is compatible with both S/MIME v2 and S/MIME v3.  S/MIME signed
    messages exchanged between applications using the CMS and PKCS #7 are
    compatible because the RFC 2311 S/MIME v2 [OLDMSG] and RFC 2633
    S/MIME v3 [MSG] signed message formats are identical.  S/MIME v2
    encapsulates the MIME content in a Data type (that is, an OCTET
    STRING) carried in the SignedData contentInfo content ANY field, and
    S/MIME v3 carries the MIME content in the SignedData encapContentInfo
    eContent OCTET STRING.  Therefore, in both S/MIME v2 and S/MIME v3,
    the MIME content is placed in an OCTET STRING and the message digest
    is computed over the identical portions of the content.  That is, the
    message digest is computed over the octets comprising the value of
    the OCTET STRING, neither the tag nor length octets are included.

    There are incompatibilities between the CMS and PKCS #7 signedData
    types when the encapsulated content is not formatted using the Data
    type.  For example, when an RFC 2634 [ESS] signed receipt is
    encapsulated in the CMS signedData type, then the Receipt SEQUENCE is
    encoded in the signedData encapContentInfo eContent OCTET STRING and
    the message digest is computed using the entire Receipt SEQUENCE
    encoding (including tag, length and value octets).  However, if an
    RFC 2634 signed receipt is encapsulated in the PKCS #7 signedData
    type, then the Receipt SEQUENCE is encoded in the SignedData
    contentInfo content ANY field (a SEQUENCE, not an OCTET STRING).
    Therefore, the message digest is computed using only the value octets
    of the Receipt SEQUENCE encoding.

    The following strategy can be used to achieve backward compatibility
    with PKCS #7 when processing SignedData content types.  If the
    implementation is unable to ASN.1 decode the signedData type using
    the CMS signedData encapContentInfo eContent OCTET STRING syntax,
    then the implementation MAY attempt to decode the signedData type
    using the PKCS #7 SignedData contentInfo content ANY syntax and
    compute the message digest accordingly.

    The following strategy can be used to achieve backward compatibility
    with PKCS #7 when creating a SignedData content type in which the
    encapsulated content is not formatted using the Data type.
    Implementations MAY examine the value of the eContentType, and then
    adjust the expected encoding of eContent based on the object
    identifier value.  For example, to support Microsoft AuthentiCode,
    the following information MAY be included:

       eContentType Object Identifier is set to { 1 3 6 1 4 1 311 2 1 4 }
       eContent contains AuthetiCode signing information


Received: by above.proper.com (8.11.6/8.11.3) id f86H2rU08739 for ietf-smime-bks; Thu, 6 Sep 2001 10:02:53 -0700 (PDT)
Received: from wfhqex05.gfgsi.com (netva01.getronicsgov.com [206.137.100.2]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f86H2qD08734 for <[e-mail]>; Thu, 6 Sep 2001 10:02:53 -0700 (PDT)
Received: by wfhqex05.gfgsi.com with Internet Mail Service (5.5.2653.19) id <R052WA94>; Thu, 6 Sep 2001 13:03:02 -0400
Message-ID: <[e-mail]>
From: "Pawling, John" <[e-mail]>
To: [e-mail]
Subject: RE: cmsalg-02 RSA OID Proposal
Date: Thu, 6 Sep 2001 13:03:01 -0400 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
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>

All,

I agree with Blake that the RSA signature OID change should not be made if
it will cause backwards compatibility problems with legacy CMS
implementations.  So far, we have heard that this change will NOT cause
problems for the following S/MIME implementations: cryptlib (according to
Peter Gutmann), Microsoft (according to Jim Schaad) and S/MIME Freeware
Library (according to John Pawling).  So far, nobody has reported that the
change will cause backwards compatibility problems with legacy CMS
implementations.  Can anybody speak for any other implementations?  

===========================================
John Pawling, [e-mail]
Getronics Government Solutions, LLC
===========================================


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id f86FFpG02052 for ietf-smime-bks; Thu, 6 Sep 2001 08:15:51 -0700 (PDT)
Received: from tholian.securitydynamics.com (mail.rsasecurity.com [204.167.112.129]) by above.proper.com (8.11.6/8.11.3) with SMTP id f86FFTD02032 for <[e-mail]>; Thu, 6 Sep 2001 08:15:29 -0700 (PDT)
Received: from sdtihq24.securid.com by tholian.securitydynamics.com via smtpd (for mail.imc.org [208.184.76.43]) with SMTP; 6 Sep 2001 15:12:55 UT
Received: from exrsa01.rsa.com (exrsa01.rsa.com [10.81.217.7]) by sdtihq24.securid.com (Pro-8.9.3/Pro-8.9.3) with ESMTP id LAA24607 for <[e-mail]>; Thu, 6 Sep 2001 11:15:29 -0400 (EDT)
Received: by exrsa01.rsa.com with Internet Mail Service (5.5.2653.19) id <QPHT5Y8V>; Thu, 6 Sep 2001 08:19:36 -0700
Received: from HOUSLEY-LAP.rsasecurity.com (housley-lap.securitydynamics.com [10.100.23.218]) by exna00.securitydynamics.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id SMJF0KS9; Thu, 6 Sep 2001 11:15:26 -0400
From: "Housley, Russ" <[e-mail]>
To: [e-mail]
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 5.0.1
Date: Thu, 06 Sep 2001 11:14:51 -0400
Subject: WG Last Call: draft-ietf-smime-key-wrap-00.txt
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 update to Key Wrap Document is ready for WG Last Call.  In a way, it 
has already gone through last call since it is part of RFC 2630.  Until 
recently, it was part of the CMSALG document.  It was separated since the 
key wrapping algorithms have uses beyond the context of the CMS and S/MIME.

Since this review will only focus on the document structure, I am using a 
slightly shorter Last Call duration than normal.  Please post all comments 
on this document to the S/MIME WG mail list by 14 September 2001.

	Title		: Triple-DES and RC2 Key Wrapping
	Author(s)	: R. Housley
	Filename	: draft-ietf-smime-key-wrap-00.txt
	Pages		: 8
	Date		: 05-Sep-01
	
This document specifies the algorithm for wrapping one Triple-DES
[3DES] key with another Triple-DES key and the algorithm for wrapping
one RC2 [RC2] key with another RC2 key.  These key wrap algorithms
were originally published in section 12.6 of RFC 2630 [CMS].  They
are republished since these key wrap algorithms have been found to be
useful in contexts beyond those supported by RFC 2630.

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

Russ


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id f86DsKI27761 for ietf-smime-bks; Thu, 6 Sep 2001 06:54:20 -0700 (PDT)
Received: from tholian.securitydynamics.com (mail.rsasecurity.com [204.167.112.129]) by above.proper.com (8.11.6/8.11.3) with SMTP id f86DsDD27756 for <[e-mail]>; Thu, 6 Sep 2001 06:54:14 -0700 (PDT)
Received: from sdtihq24.securitydynamics.com by tholian.securitydynamics.com via smtpd (for mail.imc.org [208.184.76.43]) with SMTP; 6 Sep 2001 13:51:39 UT
Received: from exeu00.securid.com (ebola.securid.com [192.168.7.4]) by sdtihq24.securid.com (Pro-8.9.3/Pro-8.9.3) with ESMTP id JAA13728 for <[e-mail]>; Thu, 6 Sep 2001 09:54:11 -0400 (EDT)
Received: by exeu00.securid.com with Internet Mail Service (5.5.2653.19) id <R0YWAM71>; Thu, 6 Sep 2001 13:53:32 +0100
Received: from HOUSLEY-LAP.rsasecurity.com (housley-lap.securitydynamics.com [10.100.23.218]) by exna00.securitydynamics.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id QTWCVG6P; Thu, 6 Sep 2001 08:53:34 -0400
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 5.0.1
Date: Thu, 06 Sep 2001 08:53:30 -0400
To: [e-mail]
From: "Housley, Russ" <[e-mail]>
Subject: Re: I-D ACTION:draft-ietf-smime-cmsalg-04.txt
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>

Dear S/MIME WG:

I believe that this document addresses all of the WG Last Call comments 
except one.  The one remaining issue is being discussed on the "cmsalg-02 
RSA OID Proposal" thread.  When this thread reaches a conclusion, I will 
update the document again.  Hopefully, we can resolve this in the next few 
days.

Please make sure that I have captured the consecsus on everything else.

Russ


>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           : Cryptographic Message Syntax (CMS) Algorithms
>         Author(s)       : R. Housley
>         Filename        : draft-ietf-smime-cmsalg-04.txt
>         Pages           : 23
>         Date            : 05-Sep-01
>
>This document describes several cryptographic algorithms for use with
>the Cryptographic Message Syntax (CMS) [CMS].  CMS is used to
>digitally sign, digest, authenticate, or encrypt arbitrary messages.
>
>A URL for this Internet-Draft is:
>http://www.ietf.org/internet-drafts/draft-ietf-smime-cmsalg-04.txt


Received: by above.proper.com (8.11.6/8.11.3) id f86Aldv17879 for ietf-smime-bks; Thu, 6 Sep 2001 03:47: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 f86AlcD17875 for <[e-mail]>; Thu, 6 Sep 2001 03:47: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 GAA19611; Thu, 6 Sep 2001 06:46:12 -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-key-wrap-00.txt
Date: Thu, 06 Sep 2001 06:46:12 -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		: Triple-DES and RC2 Key Wrapping
	Author(s)	: R. Housley
	Filename	: draft-ietf-smime-key-wrap-00.txt
	Pages		: 8
	Date		: 05-Sep-01
	
This document specifies the algorithm for wrapping one Triple-DES
[3DES] key with another Triple-DES key and the algorithm for wrapping
one RC2 [RC2] key with another RC2 key.  These key wrap algorithms
were originally published in section 12.6 of RFC 2630 [CMS].  They
are republished since these key wrap algorithms have been found to be
useful in contexts beyond those supported by RFC 2630.

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

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


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

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

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

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

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

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

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

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

--OtherAccess--

--NextPart--




Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id f86AlYv17873 for ietf-smime-bks; Thu, 6 Sep 2001 03:47: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 f86AlWD17868 for <[e-mail]>; Thu, 6 Sep 2001 03:47: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 GAA19595; Thu, 6 Sep 2001 06:46:07 -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-cmsalg-04.txt
Date: Thu, 06 Sep 2001 06:46:07 -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		: Cryptographic Message Syntax (CMS) Algorithms
	Author(s)	: R. Housley
	Filename	: draft-ietf-smime-cmsalg-04.txt
	Pages		: 23
	Date		: 05-Sep-01
	
This document describes several cryptographic algorithms for use with
the Cryptographic Message Syntax (CMS) [CMS].  CMS is used to
digitally sign, digest, authenticate, or encrypt arbitrary messages.

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

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

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 f863UCA13295 for ietf-smime-bks; Wed, 5 Sep 2001 20:30:12 -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 f863UAD13291 for <[e-mail]>; Wed, 5 Sep 2001 20:30:10 -0700 (PDT)
Received: by zmamail04.zma.compaq.com (Postfix, from userid 12345) id D72034E74; Wed,  5 Sep 2001 23:30:08 -0400 (EDT)
Received: from mailrelay01.cce.cpqcorp.net (mailrelay01.cce.cpqcorp.net [16.47.68.171]) by zmamail04.zma.compaq.com (Postfix) with ESMTP id AB7354DF6; Wed,  5 Sep 2001 23:30:08 -0400 (EDT)
Received: by mailrelay01.cce.cpqcorp.net (Postfix, from userid 12345) id 135EBA6B; Wed,  5 Sep 2001 22:30:08 -0500 (CDT)
Received: from diexch01.xko.dec.com (diexch01.xko.dec.com [16.138.244.57]) by mailrelay01.cce.cpqcorp.net (Postfix) with ESMTP id E1668AC9; Wed,  5 Sep 2001 22:30:04 -0500 (CDT)
Received: by diexch01.xko.dec.com with Internet Mail Service (5.5.2650.21) id <R6NJ5MLJ>; Thu, 6 Sep 2001 08:54:01 +0530
Message-ID: <[e-mail]>
From: "Hegde, Vijaykumar" <[e-mail]>
To: Graeme Lunt <[e-mail]>, [e-mail]
Subject: RE: S/MIME support in X.400
Date: Thu, 6 Sep 2001 08:54:00 +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>

Hello everybody,
			I want some more details regarding the ASN.1 syntax
for representing S/MIME content.
		
Earlier discussion:

> 1.What is the ASN.1 syntax used for representing a S/MIME content ? For
IPM, 
> the ASN.1 syntax is defined in X.420. For EDI, the syntax is X.435. Are
there 
> any similar representations defined for S/MIME content ?

You will find the ASN.1 syntax in RFC 2630 (CMS) and RFC 2634 (ESS)
-----------
My question:

Those RFCs only define the syntax for the "CMS" object. But how does
one insert that object into an X.400 Content? What will be the ASN.1
syntax of the X.400 Content that will contain the CMS object?
Would it be like this?
--------------------------------------------------------------
OM_CLASS [OM_S_OBJECT_IDENTIFIER_STRING]: MH_C_DELIV_MESSAGE
MH_T_CONTENT [OM_S_OBJECT]: (Object)
      OM_CLASS [OM_S_OBJECT_IDENTIFIER_STRING]: "NEW S-MIME CONTENT"
      MH_T_BINARY_CONTENT [OM_S_OCTET_STRING]:
ContentInfo ::= SEQUENCE {						| C
  contentType ContentType,						| M

  content [0] EXPLICIT ANY DEFINED BY contentType }    	| S
	
| OBJECT
ContentType ::= OBJECT IDENTIFIER					|
-------------------------------------------------------------------

Thanks and regards,
Vijay Hegde







Vijay,
    
> I have a couple of queries regarding
"draft-ietf-smime-x400transport-03.txt".

> 1.What is the ASN.1 syntax used for representing a S/MIME content ? For
IPM, 
> the ASN.1 syntax is defined in X.420. For EDI, the syntax is X.435. Are
there 
> any similar representations defined for S/MIME content ?

You will find the ASN.1 syntax in RFC 2630 (CMS) and RFC 2634 (ESS)

> 2. We use XAPI defined by X/OPEN to build the messages. Are there any 
> OID's/integer value defined to represent S/MIME content. i.e. the value
for 
> MH_T_CONTENT_TYPE. Also, are you aware of any plans on behalf of X/OPEN to

> support S/MIME, these drafts ?

Here are the definitions are you might see them in the X/APIs. 
They are aligned with the latest draft.

/* Content Identifiers */
#define OMP_O_MM_CTO_CMS
"\x2A\x86\x48\x86\xF7\x0D\x01\x09\x10\x01\x06"
#define OMP_O_MM_CTO_MIMECMS          "\x2A\x86\x48\x86\xF7\x0D\x01\x07\x01"

You want to use the first for S/MIME wrapped X.400 content.

I don't know of X/OPEN doing anything to specifically support CMS. 
The above definitions, with a binary content, is sufficient (at least for
me).

Graeme


Received: by above.proper.com (8.11.6/8.11.3) id f85N6WU09336 for ietf-smime-bks; Wed, 5 Sep 2001 16:06:32 -0700 (PDT)
Received: from hawaii.deming.com (hawaii.deming.com [208.236.41.139]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f85N6VD09332 for <[e-mail]>; Wed, 5 Sep 2001 16:06:31 -0700 (PDT)
Received: from 208.236.41.137 by hawaii.deming.com with ESMTP ( Tumbleweed MMS SMTP Relay (MMS v5.0)); Wed, 05 Sep 2001 16:06:23 -0700
X-Server-Uuid: F4BC6258-86A5-40F3-9714-0CF63E081F09
Received: by cane.deming.com with Internet Mail Service (5.5.2650.21) id <R9KF62NG>; Wed, 5 Sep 2001 16:06:23 -0700
Message-ID: <[e-mail]>
From: "Blake Ramsdell" <[e-mail]>
To: "'Pawling, John'" <[e-mail]>, [e-mail]
Subject: RE: cmsalg-02 RSA OID Proposal
Date: Wed, 5 Sep 2001 16:06:20 -0700
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
X-WSS-ID: 1788706510901-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>

I don't disagree with your comments, John -- the only thing I was trying to
point out is that there was a precedent in the original design that we chose
to ignore for DSA, and just trying to justify the original separation the
identification of "digest" and "the other thing that isn't the digest but
which takes as input the digest and the public key and maybe other stuff in
order to make sure the signature is valid" (which I think would make a lousy
name for this field in the ASN.1, but I don't have a good substitute).

If all we're trying to do is change it to satisfy our own guilt that this
inconsistency exists, I might suggest that we simply get over it and put a
big apologetic paragraph in here that indicates our remorse, and not risk
breaking implementations with this change.

Blake

-----Original Message-----
From: Pawling, John [mailto:[e-mail]]
Sent: Wednesday, September 05, 2001 2:11 PM
To: [e-mail]
Subject: RE: cmsalg-02 RSA OID Proposal



Blake,

I agree with your point that the RFC 2630 specification of
signatureAlgorithm OIDs is inconsistent (i.e. id-dsa-with-sha1 is
inconsistent with rsaEncryption).  However, I disagree with your statement
that id-dsa-with-sha1 doesn't work as an indicator of "what identifier from
a certificate's SubjectPublicKeyInfo would be required to verify this
signature".  It is straightforward to develop CMS implementations to
recognize that the presence of the id-dsa-with-sha1 OID in the signedData
signerInfo signatureAlgorithm field indicates that the certificate required
to verify the signature must contain the id-dsa OID in the
SubjectPublicKeyInfo algorithm field.  Similarly, it is straightforward to
develop CMS implementations to recognize that the presence of either the
md5WithRSAEncryption or sha1WithRSAEncryption OID in the signedData
signerInfo signatureAlgorithm field indicates that the certificate required
to verify the signature must contain the rsaEncryption OID in the
SubjectPublicKeyInfo algorithm field.

===========================================
John Pawling, [e-mail]
Getronics Government Solutions, LLC
===========================================



Received: by above.proper.com (8.11.6/8.11.3) id f85LAkn07211 for ietf-smime-bks; Wed, 5 Sep 2001 14:10:46 -0700 (PDT)
Received: from wfhqex05.gfgsi.com (netva01.getronicsgov.com [206.137.100.2]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f85LAiD07203 for <[e-mail]>; Wed, 5 Sep 2001 14:10:44 -0700 (PDT)
Received: by wfhqex05.gfgsi.com with Internet Mail Service (5.5.2653.19) id <R052V50T>; Wed, 5 Sep 2001 17:10:53 -0400
Message-ID: <[e-mail]>
From: "Pawling, John" <[e-mail]>
To: [e-mail]
Subject: RE: cmsalg-02 RSA OID Proposal
Date: Wed, 5 Sep 2001 17:10:52 -0400 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
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>

Blake,

I agree with your point that the RFC 2630 specification of
signatureAlgorithm OIDs is inconsistent (i.e. id-dsa-with-sha1 is
inconsistent with rsaEncryption).  However, I disagree with your statement
that id-dsa-with-sha1 doesn't work as an indicator of "what identifier from
a certificate's SubjectPublicKeyInfo would be required to verify this
signature".  It is straightforward to develop CMS implementations to
recognize that the presence of the id-dsa-with-sha1 OID in the signedData
signerInfo signatureAlgorithm field indicates that the certificate required
to verify the signature must contain the id-dsa OID in the
SubjectPublicKeyInfo algorithm field.  Similarly, it is straightforward to
develop CMS implementations to recognize that the presence of either the
md5WithRSAEncryption or sha1WithRSAEncryption OID in the signedData
signerInfo signatureAlgorithm field indicates that the certificate required
to verify the signature must contain the rsaEncryption OID in the
SubjectPublicKeyInfo algorithm field.

===========================================
John Pawling, [e-mail]
Getronics Government Solutions, LLC
===========================================


Received: by above.proper.com (8.11.6/8.11.3) id f85Jiav04866 for ietf-smime-bks; Wed, 5 Sep 2001 12:44:36 -0700 (PDT)
Received: from hawaii.deming.com (hawaii.deming.com [208.236.41.139]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f85JiZD04862 for <[e-mail]>; Wed, 5 Sep 2001 12:44:35 -0700 (PDT)
Received: from 208.236.41.137 by hawaii.deming.com with ESMTP ( Tumbleweed MMS SMTP Relay (MMS v5.0)); Wed, 05 Sep 2001 12:44:26 -0700
X-Server-Uuid: F4BC6258-86A5-40F3-9714-0CF63E081F09
Received: by cane.deming.com with Internet Mail Service (5.5.2650.21) id <R9KF622R>; Wed, 5 Sep 2001 12:44:26 -0700
Message-ID: <[e-mail]>
From: "Blake Ramsdell" <[e-mail]>
To: "'Housley, Russ'" <[e-mail]>, [e-mail]
cc: [e-mail]
Subject: RE: cmsalg-02 RSA OID Proposal
Date: Wed, 5 Sep 2001 12:44:20 -0700
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
X-WSS-ID: 17885F1010563-01-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>

Do previous message threads have any relevance here?

11/7/1997
DigestEncryptionAlgorithmIdentifiers for DSS / DSA (was RE:S/MIME V3 Msg
Spec Comments)

7/9/1998
SignatureAlgorithmIdentifiers

The bottom line seems to be that we picked an unfortunate name for the
signatureAlgorithm field.  The original name (digestEncryptionAlgorithm) was
bad for one reason (implies encryption), and the new one is bad for another
reason (implies both digesting and protection).  The use of id-dsa-with-sha1
seems to be the only culprit in my mind (should be id-dsa).  One way to look
at this is "what identifier from a certificate's SubjectPublicKeyInfo would
be required to verify this signature), which doesn't work right now with
DSA.

Blake

-----Original Message-----
From: Housley, Russ [mailto:[e-mail]]
Sent: Saturday, September 01, 2001 9:03 AM
To: [e-mail]
Cc: [e-mail]
Subject: Re: cmsalg-02 RSA OID Proposal



Peter:

> >RFC2630 CMS, section 12.2.2, specifies the use of the rsaEncryption
object
> >identifier (OID) in the signedData signerInfo signatureAlgorithm field
when
> >the RSA (PKCS #1 v1.5) algorithm is used as part of the signature
generation
> >process.  cmsalg-02, Section 3.2, specifies the use of the
> >md5WithRSAEncryption and sha1WithRSAEncryption OID (as appropriate) in
the
> >signedData signerInfo signatureAlgorithm field (instead of the id-
> >rsaEncryption OID).
>
>Isn't this kind of asking for trouble?  In addition since SignerInfo
already
>specifies the hash algorithm being used as DigestAlgorithmIdentifiers, why
is
>there a need to specify it again in the SignatureAlgorithmIdentifier?

Yes, this does lead to some redundancy. However, it is completely 
justifiable.  The massage digest algorithm identifier comes before the 
data, and the signature algorithm identifier comes after the data.  This 
ordering facilitates pipeline processing by the recipient.

> >Is this change going to cause backwards compatibility problems with 
> legacy CMS
> >implementations?
>
>cryptlib has a many-to-one mapping of OIDs, so this shouldn't be a problem,
as
>long as there's an RSA in there somewhere it'll identify it as RSA.

Cool.

Russ



Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id f85J9xf03935 for ietf-smime-bks; Wed, 5 Sep 2001 12:09:59 -0700 (PDT)
Received: from wfhqex05.gfgsi.com (netva01.getronicsgov.com [206.137.100.2]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f85J9wD03931 for <[e-mail]>; Wed, 5 Sep 2001 12:09:58 -0700 (PDT)
Received: by wfhqex05.gfgsi.com with Internet Mail Service (5.5.2653.19) id <R052VZ9C>; Wed, 5 Sep 2001 15:10:07 -0400
Message-ID: <[e-mail]>
From: "Pawling, John" <[e-mail]>
To: "SMIME WG (E-mail)" <[e-mail]>
Subject: rfc2630bis-03 Comment
Date: Wed, 5 Sep 2001 15:10:04 -0400 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
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>

All,

In my opinion, Russ has done an outstanding job of updating this document.
I recommend that section 5.2.1 be replaced with the following text:

"5.2.1  [*** NEW ***] Compatibility with PKCS #7 SignedData Type

This section contains a word of warning to implementers that wish to support
both the CMS and PKCS #7 [PKCS#7] SignedData types.  Both the CMS and PKCS
#7 SignedData types identify the type of the encapsulated content with an
object identifier, but the ASN.1 type of the content itself was variable in
the PKCS #7 SignedData type.  

PKCS #7 defined content as:

      content [0] EXPLICIT ANY DEFINED BY contentType OPTIONAL

CMS defines eContent as:

      eContent [0] EXPLICIT OCTET STRING OPTIONAL

The CMS definition is much easier to use in most applications, and is
compatible with both S/MIME v2 and S/MIME v3.  There are some deployed
applications that use the PKCS #7 definition.  S/MIME signed messages
exchanged between PKCS #7 and CMS applications are compatible because the
RFC 2311 S/MIME v2 and RFC 2633 S/MIME v3 signed message formats are
identical.  RFC 2311 specifies that the MIME content MUST be encapsulated in
a Data type (i.e. OCTET STRING) stored in the SignedData contentInfo content
ANY field.  RFC 2633 specifies that the MIME content MUST be stored in the
SignedData encapContentInfo eContent OCTET STRING.  In both cases, the MIME
content is stored in an OCTET STRING and the message digest is computed over
the identical portions of the content (i.e. only the octets comprising the
value of the OCTET STRING are input to the message digest algorithm, not the
tag or length octets).

There are incompatibilities between the CMS and PKCS #7 signedData types
when the encapsulated content is not formatted using the Data type.  For
example, when an RFC 2634 signed receipt is encapsulated in a CMS signedData
type, then the Receipt SEQUENCE is encoded in the signedData
encapContentInfo eContent OCTET STRING and the message digest is computed
using the entire Receipt SEQUENCE encoding (including tag, length and value
octets).  If an RFC 2634 signed receipt is encapsulated in a PKCS #7
signedData type, then the Receipt SEQUENCE is encoded in the SignedData
contentInfo content ANY field (i.e. not an OCTET STRING) and the message
digest is computed using only the value octets (not the tag and length
octets) of the Receipt SEQUENCE encoding.

The following strategy MAY be used to achieve PKCS #7 backward compatibility
when processing signedData types.  If the CMS implementation is unable to
ASN.1 decode the signedData type using the CMS signedData encapContentInfo
eContent OCTET STRING syntax, then the CMS implementation MAY attempt to
decode the signedData type using the PKCS #7 SignedData contentInfo content
ANY syntax and compute the message digest accordingly (i.e. using only the
value octets of the content, not the tag and length octets).   

The following strategy MAY be used to achieve PKCS #7 backward compatibility
when creating a signedData type in which the encapsulated content is not
formatted using the Data type.  CMS implementations MAY examine the value of
the eContentType, and then adjust the expected encoding of eContent based on
the object identifier value.  For example, to support Microsoft
AuthentiCode, the following information MAY be included:

      eContentType Object Identifier = { 1 3 6 1 4 1 311 2 1 4 }
      eContent Type = SpcIndirectDataContext  -- Microsoft code signing"

===========================================
John Pawling, [e-mail]
Getronics Government Solutions, LLC
===========================================


Received: by above.proper.com (8.11.6/8.11.3) id f85AnEC07901 for ietf-smime-bks; Wed, 5 Sep 2001 03:49:14 -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 f85AnCD07888 for <[e-mail]>; Wed, 5 Sep 2001 03:49:12 -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 GAA23072; Wed, 5 Sep 2001 06:47:12 -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-06.txt
Date: Wed, 05 Sep 2001 06:47:11 -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-06.txt
	Pages		: 
	Date		: 04-Sep-01
	
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.

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

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

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

--OtherAccess--

--NextPart--




Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id f84F9sQ15377 for ietf-smime-bks; Tue, 4 Sep 2001 08:09:54 -0700 (PDT)
Received: from [203.46.112.10] (mail.rsasecurity.com.au [203.46.112.10]) by above.proper.com (8.11.6/8.11.3) with SMTP id f84F9pD15373 for <[e-mail]>; Tue, 4 Sep 2001 08:09:51 -0700 (PDT)
Received: from [192.168.18.3] by [203.46.112.10] via smtpd (for [208.184.76.43]) with SMTP; 20 Mar 2001 11:10:11 UT
Received: from exaus01.local.aus.rsa.com (exaus01.local.aus.rsa.com [10.177.1.15]) by grover.local.aus.rsa.com (8.10.2/8.10.2) with ESMTP id f84FDgq03756 for <[e-mail]>; Wed, 5 Sep 2001 01:13:42 +1000 (EST)
Received: by exaus01.local.aus.rsa.com with Internet Mail Service (5.5.2653.19) id <QX7RVNB2>; Wed, 5 Sep 2001 01:04:19 +1000
Received: from HOUSLEY-LAP.rsasecurity.com (HOUSLEY-LAP [10.3.1.16]) by exna00.securitydynamics.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id QTWC4HTN; Tue, 4 Sep 2001 11:09:22 -0400
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 5.0.1
Date: Tue, 04 Sep 2001 10:33:51 -0400
To: [e-mail]
From: "Housley, Russ" <[e-mail]>
Subject: RFC2630bis Security Considerations
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 last two paragraphs of the Security Considerations seem better handled 
in the CMSALG document.  And, in fact, those paragraphs are already 
included in CMSALG.  Does anyone object to them being deleted from RFC2630bis?

Russ


Received: by above.proper.com (8.11.6/8.11.3) id f84Anqa29667 for ietf-smime-bks; Tue, 4 Sep 2001 03:49:52 -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 f84AnpD29659 for <[e-mail]>; Tue, 4 Sep 2001 03:49: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 GAA07299; Tue, 4 Sep 2001 06:48:26 -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-cmsalg-03.txt
Date: Tue, 04 Sep 2001 06:48:26 -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		: Cryptographic Message Syntax (CMS) Algorithms
	Author(s)	: R. Housley
	Filename	: draft-ietf-smime-cmsalg-03.txt
	Pages		: 27
	Date		: 31-Aug-01
	
This document describes several cryptographic algorithms for use with
the Cryptographic Message Syntax (CMS) [CMS].  CMS is used to
digitally sign, digest, authenticate, or encrypt arbitrary messages.

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

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

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

--OtherAccess--

--NextPart--




Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id f84AnmI29648 for ietf-smime-bks; Tue, 4 Sep 2001 03:49:48 -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 f84AnkD29639 for <[e-mail]>; Tue, 4 Sep 2001 03:49:47 -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 GAA07283; Tue, 4 Sep 2001 06:48:22 -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-rfc2630bis-03.txt
Date: Tue, 04 Sep 2001 06:48:22 -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		: Cryptographic Message Syntax
	Author(s)	: R. Housley
	Filename	: draft-ietf-smime-rfc2630bis-03.txt
	Pages		: 54
	Date		: 31-Aug-01
	
This document describes the Cryptographic Message Syntax (CMS).  This
syntax is used to digitally sign, digest, authenticate, or encrypt
arbitrary messages.

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

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

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

--OtherAccess--

--NextPart--




Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id f81G2tx03566 for ietf-smime-bks; Sat, 1 Sep 2001 09:02:55 -0700 (PDT)
Received: from tholian.securitydynamics.com (mail.rsasecurity.com [204.167.112.129]) by above.proper.com (8.11.6/8.11.3) with SMTP id f81G2rD03562 for <[e-mail]>; Sat, 1 Sep 2001 09:02:53 -0700 (PDT)
Received: from sdtihq24.securid.com by tholian.securitydynamics.com via smtpd (for mail.imc.org [208.184.76.43]) with SMTP; 1 Sep 2001 16:00:25 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 MAA25401 for <[e-mail]>; Sat, 1 Sep 2001 12:02:02 -0400 (EDT)
Received: by exna00.securitydynamics.com with Internet Mail Service (5.5.2653.19) id <QTWCTYYF>; Sat, 1 Sep 2001 12:02:54 -0400
Received: from HOUSLEY-LAP.rsasecurity.com (HOUSLEY-LAP [10.3.1.77]) by exna00.securitydynamics.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id QTWCTYY1; Sat, 1 Sep 2001 12:02:42 -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.0.1
Date: Sat, 01 Sep 2001 12:02:37 -0400
Subject: Re:  cmsalg-02 RSA OID Proposal
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>

Peter:

> >RFC2630 CMS, section 12.2.2, specifies the use of the rsaEncryption object
> >identifier (OID) in the signedData signerInfo signatureAlgorithm field when
> >the RSA (PKCS #1 v1.5) algorithm is used as part of the signature generation
> >process.  cmsalg-02, Section 3.2, specifies the use of the
> >md5WithRSAEncryption and sha1WithRSAEncryption OID (as appropriate) in the
> >signedData signerInfo signatureAlgorithm field (instead of the id-
> >rsaEncryption OID).
>
>Isn't this kind of asking for trouble?  In addition since SignerInfo already
>specifies the hash algorithm being used as DigestAlgorithmIdentifiers, why is
>there a need to specify it again in the SignatureAlgorithmIdentifier?

Yes, this does lead to some redundancy. However, it is completely 
justifiable.  The massage digest algorithm identifier comes before the 
data, and the signature algorithm identifier comes after the data.  This 
ordering facilitates pipeline processing by the recipient.

> >Is this change going to cause backwards compatibility problems with 
> legacy CMS
> >implementations?
>
>cryptlib has a many-to-one mapping of OIDs, so this shouldn't be a problem, as
>long as there's an RSA in there somewhere it'll identify it as RSA.

Cool.

Russ