Subject: Re: WG Last Call: rfc2630bis and cmsalg

From: "Housley, Russ" <[email-masked]>
Date: Thu, 20 Sep 2001 09:10:36 -0400

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

---

From: "Housley, Russ" <[email-masked]>
Date: Fri, 28 Sep 2001 16:35:22 -0400

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

Date: Fri, 28 Sep 2001 16:35:22 -0400
To: [email-masked]
From: "Housley, Russ" <[email-masked]>
Subject: Re: WG Last Call: rfc2630bis and cmsalg
Sender: [email-masked]

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

To: IETF-Announce: ;
Cc: [email-masked]
From: [email-masked]
Reply-to: [email-masked]
Subject: I-D ACTION:draft-ietf-smime-ira-00.txt
Date: Thu, 27 Sep 2001 07:00:18 -0400
Sender: [email-masked]

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the S/MIME Mail Security Working Group of the IETF.

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

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

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

--OtherAccess--

--NextPart--

Date: Tue, 25 Sep 2001 10:12:00 -0400
To: [email-masked]
From: "Housley, Russ" <[email-masked]>
Subject: WG Last Call: draft-ietf-smime-pkcs1-01.txt
Sender: [email-masked]

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 

To: IETF-Announce: ;
Cc: [email-masked]
From: [email-masked]
Reply-to: [email-masked]
Subject: I-D ACTION:draft-ietf-smime-pkcs1-01.txt
Date: Tue, 25 Sep 2001 07:01:42 -0400
Sender: [email-masked]

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the S/MIME Mail Security Working Group of the IETF.

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

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

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

--OtherAccess--

--NextPart--

To: IETF-Announce: ;
Subject: RFC 3126 on Electronic Signature Formats
Cc: [email-masked], [email-masked]
Date: Mon, 24 Sep 2001 10:42:35 -0700
From: RFC Editor <[email-masked]>
Sender: [email-masked]

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

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

        To: [email-masked]
        Subject: getting rfcs

        help: ways_to_get_rfcs

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

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

...

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

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

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

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

RETRIEVE: rfc
DOC-ID: 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: <[email-masked]>

--OtherAccess--
--NextPart--

To: IETF-Announce: ;
Subject: RFC 3125 on Electronic Signature Policies
Cc: [email-masked], [email-masked]
Date: Mon, 24 Sep 2001 10:23:52 -0700
From: RFC Editor <[email-masked]>
Sender: [email-masked]

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

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

        To: [email-masked]
        Subject: getting rfcs

        help: ways_to_get_rfcs

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

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

...

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

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

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

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

RETRIEVE: rfc
DOC-ID: 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: <[email-masked]>

--OtherAccess--
--NextPart--

From: "William Ottaway" <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>
Subject: DOMSEC and S/MIME Gateway Protocol comparison
Date: Fri, 21 Sep 2001 14:41:59 +0100
Importance: Normal
Sender: [email-masked]

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: +44 (0) 1684 894079
 Malvern Technology Centre,   Fax: +44 (0) 1684 896660
 St. Andrews Road,            email: [email-masked]
 Malvern,
 Worcs,
 WR14 3PS

 All opinions are my own.

Date: Thu, 20 Sep 2001 09:10:36 -0400
To: [email-masked]
From: "Housley, Russ" <[email-masked]>
Subject: Re: WG Last Call: rfc2630bis and cmsalg
Sender: [email-masked]

Russ

To: IETF-Announce: ;
Cc: [email-masked]
From: [email-masked]
Reply-to: [email-masked]
Subject: I-D ACTION:draft-ietf-smime-rfc2630bis-04.txt
Date: Thu, 20 Sep 2001 07:08:22 -0400
Sender: [email-masked]

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the S/MIME Mail Security Working Group of the IETF.

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

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

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

--OtherAccess--

--NextPart--

To: IETF-Announce: ;
Cc: [email-masked]
From: [email-masked]
Reply-to: [email-masked]
Subject: I-D ACTION:draft-ietf-smime-cmsalg-05.txt
Date: Thu, 20 Sep 2001 07:07:44 -0400
Sender: [email-masked]

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the S/MIME Mail Security Working Group of the IETF.

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

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

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

--OtherAccess--

--NextPart--

From: "Hegde, Vijaykumar" <[email-masked]>
To: "Bonatti, Chris" <[email-masked]>, [email-masked]
Subject: FW: S/MIME and X.400
Date: Thu, 20 Sep 2001 09:11:40 +0530
Sender: [email-masked]

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:[email-masked]]
Sent: Thursday, September 13, 2001 5:31 PM
To: Hegde, Vijaykumar
Cc: [email-masked]
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  |
 |  [email-masked]   Tel: 301-208-2349   Fax: 301-208-2379  |
 ---------------------------------------------------------------

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]]On Behalf Of Hegde, Vijaykumar
Sent: Tuesday, September 11, 2001 03:04
To: [email-masked]
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

From: "Pawling, John" <[email-masked]>
To: "[email-masked]'" <[email-masked]>, "'Housley, Russ'" <[email-masked]>
Cc: [email-masked]
Subject: RE: Comments on draft-ietf-smime-rfc2630bis-03
Date: Wed, 19 Sep 2001 16:43:57 -0400
Sender: [email-masked]

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, [email-masked]
Getronics Government Solutions, LLC
===========================================

Date: Wed, 19 Sep 2001 16:27:00 -0400
To: [email-masked]
From: "Housley, Russ" <[email-masked]>
Subject: WG Last Call: draft-ietf-smime-x400transport-03.txt
Sender: [email-masked]

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 

Reply-To: <[email-masked]>
From: "Jim Schaad" <[email-masked]>
To: "'Housley, Russ'" <[email-masked]>, <[email-masked]>
Cc: <[email-masked]>
Subject: RE: Comments on draft-ietf-smime-rfc2630bis-03
Date: Wed, 19 Sep 2001 11:26:11 -0700
Importance: Normal
Sender: [email-masked]

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

Reply-To: <[email-masked]>
From: "Jim Schaad" <[email-masked]>
To: "'Housley, Russ'" <[email-masked]>, <[email-masked]>
Subject: RE: Compression Content Type and RFC2630bis
Date: Wed, 19 Sep 2001 11:19:52 -0700
Importance: Normal
Sender: [email-masked]

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: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Housley, Russ
> Sent: Wednesday, September 19, 2001 8:02 AM
> To: [email-masked]
> 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
> 

From: "Housley, Russ" <[email-masked]>
To: [email-masked]
Cc: [email-masked]
Date: Wed, 19 Sep 2001 14:12:25 -0400
Subject: Re:  Compression Content Type and RFC2630bis
Sender: [email-masked]

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

Date: Thu, 20 Sep 2001 05:29:46 +1200 (NZST)
From: [email-masked] (Peter Gutmann)
To: [email-masked], [email-masked]
Subject: Re:  Compression Content Type and RFC2630bis
Sender: [email-masked]

"Housley, Russ" <[email-masked]> 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.

Date: Wed, 19 Sep 2001 11:33:41 -0400
From: "Sean P. Turner" <[email-masked]>
Organization: IECA, Inc.
To: "Housley, Russ" <[email-masked]>
CC: [email-masked]
Subject: Re: Compression Content Type and RFC2630bis
Sender: [email-masked]

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

From: "Housley, Russ" <[email-masked]>
To: [email-masked]
Cc: [email-masked]
Date: Wed, 19 Sep 2001 10:26:32 -0400
Subject: Re: Comments on draft-ietf-smime-cmsalg-04
Sender: [email-masked]

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

From: "Housley, Russ" <[email-masked]>
To: [email-masked]
Cc: [email-masked]
Date: Wed, 19 Sep 2001 10:49:07 -0400
Subject: Re: Comments on draft-ietf-smime-rfc2630bis-03
Sender: [email-masked]

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

Date: Wed, 19 Sep 2001 11:01:50 -0400
To: [email-masked]
From: "Housley, Russ" <[email-masked]>
Subject: Compression Content Type and RFC2630bis
Sender: [email-masked]

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

From: "Housley, Russ" <[email-masked]>
To: [email-masked], [email-masked]
Cc: [email-masked], [email-masked]
Date: Wed, 19 Sep 2001 10:18:00 -0400
Subject: draft-ietf-smime-key-wrap-01.txt
Sender: [email-masked]

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

To: IETF-Announce: ;
Cc: [email-masked]
From: [email-masked]
Reply-to: [email-masked]
Subject: I-D ACTION:draft-ietf-smime-key-wrap-01.txt
Date: Wed, 19 Sep 2001 07:06:57 -0400
Sender: [email-masked]

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the S/MIME Mail Security Working Group of the IETF.

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

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

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

--OtherAccess--

--NextPart--

Reply-To: <[email-masked]>
From: "Jim Schaad" <[email-masked]>
To: <[email-masked]>, "Russ Housley" <[email-masked]>
Subject: Comments on draft-ietf-smime-cmsalg-04
Date: Tue, 18 Sep 2001 20:30:37 -0700
Importance: Normal
Sender: [email-masked]

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

Reply-To: <[email-masked]>
From: "Jim Schaad" <[email-masked]>
To: <[email-masked]>, "Russ Housley" <[email-masked]>
Subject: Comments on draft-ietf-smime-rfc2630bis-03
Date: Tue, 18 Sep 2001 20:14:42 -0700
Importance: Normal
Sender: [email-masked]

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

From: "Housley, Russ" <[email-masked]>
To: [email-masked]
Cc: [email-masked]
Date: Tue, 18 Sep 2001 09:01:24 -0400
Subject: Re: Comments on draft-ietf-smime-key-wrap-00
Sender: [email-masked]

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

Date: Tue, 18 Sep 2001 13:09:38 +0100
From: Stephen Farrell <[email-masked]>
Reply-To: [email-masked]
Organization: Baltimore Technologies Ltd.
To: [email-masked]
CC: [email-masked]
Subject: Re: which is easier?
Sender: [email-masked]

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) +353 1 881 6716
39 Parkgate Street,                     fax: +353 1 881 7000
Dublin 8.                mailto:[email-masked]
Ireland                             http://www.baltimore.com

Reply-To: <[email-masked]>
From: "Jim Schaad" <[email-masked]>
To: <[email-masked]>, "Russ Housley" <[email-masked]>
Subject: Comments on draft-ietf-smime-key-wrap-00
Date: Mon, 17 Sep 2001 19:00:32 -0700
Importance: Normal
Sender: [email-masked]

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

Reply-To: <[email-masked]>
From: "Jim Schaad" <[email-masked]>
To: <[email-masked]>, <[email-masked]>
Subject: RE: which is easier?
Date: Mon, 17 Sep 2001 13:28:11 -0700
Importance: Normal
Sender: [email-masked]

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: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Stephen Farrell
> Sent: Monday, September 17, 2001 9:01 AM
> To: [email-masked]
> 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) +353 1 881 6716
39 Parkgate Street,                     fax: +353 1 881 7000
Dublin 8.                mailto:[email-masked]
Ireland                             http://www.baltimore.com

Date: Mon, 17 Sep 2001 17:00:37 +0100
From: Stephen Farrell <[email-masked]>
Reply-To: [email-masked]
Organization: Baltimore Technologies Ltd.
To: [email-masked]
Subject: which is easier?
Sender: [email-masked]

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) +353 1 881 6716
39 Parkgate Street,                     fax: +353 1 881 7000
Dublin 8.                mailto:[email-masked]
Ireland                             http://www.baltimore.com

From: "Housley, Russ" <[email-masked]>
To: "Pawling, John" <[email-masked]>
Cc: "SMIME WG (E-mail)" <[email-masked]>
Date: Mon, 17 Sep 2001 11:42:52 -0400
Subject: Re: cmsalg-04 Comments
Sender: [email-masked]

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

Date: Thu, 13 Sep 2001 15:30:38 -0400
To: [email-masked], [email-masked]
From: Michael Chernick <[email-masked]>
Subject: Reminder - Draft NIST S/MIME Profile - Comment Period Ends Soon
Cc: [email-masked], [email-masked]
Sender: [email-masked]

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

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

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

----------------------------------------------------------------------------------
C. Michael Chernick
+1-301-975-3610   [email-masked]
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;[email-masked]&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 [email-masked].<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;[email-masked]&gt;.<br>
<br>
<x-sigsep><p></x-sigsep>
----------------------------------------------------------------------------------<br>
C. Michael Chernick<br>
+1-301-975-3610&nbsp;&nbsp; [email-masked]<br>
Computer Security Division <br>
National Institute of Standards and Technology (NIST)<br>
----------------------------------------------------------------------------------<br>
<br>
</html>

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

To: IETF-Announce: ;
Cc: RFC Editor <[email-masked]>
Cc: Internet Architecture Board <[email-masked]>
Cc: [email-masked]
From: The IESG <[email-masked]>
Subject: Document Action: Domain Security Services using S/MIME to Experimental
Date: Thu, 13 Sep 2001 13:54:44 -0400
Sender: [email-masked]

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.

From: "Bonatti, Chris" <[email-masked]>
To: "Hegde, Vijaykumar" <[email-masked]>
Cc: <[email-masked]>
Subject: RE: S/MIME and X.400
Date: Thu, 13 Sep 2001 08:01:28 -0400
Importance: Normal
Sender: [email-masked]

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  |
 |  [email-masked]   Tel: 301-208-2349   Fax: 301-208-2379  |
 ---------------------------------------------------------------

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]]On Behalf Of Hegde, Vijaykumar
Sent: Tuesday, September 11, 2001 03:04
To: [email-masked]
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

From: "Dieter Bratko" <[email-masked]>
To: "Pawling, John" <[email-masked]>, "SMIME WG \(E-mail\)" <[email-masked]>
Subject: AW: cmsalg-02 RSA OID Proposal
Date: Thu, 13 Sep 2001 09:15:21 +0200
Importance: Normal
Sender: [email-masked]

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: [email-masked]
[mailto:[email-masked]]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, [email-masked]
Getronics Government Solutions, LLC
===========================================

-----Ursprüngliche Nachricht-----
Von: [email-masked]
[mailto:[email-masked]]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, [email-masked]
Getronics Government Solutions, LLC
===========================================

From: "Pawling, John" <[email-masked]>
To: "[email-masked]'" <[email-masked]>, [email-masked]
Subject: RE: cmsalg-02 RSA OID Proposal
Date: Wed, 12 Sep 2001 10:27:52 -0400
Sender: [email-masked]

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, [email-masked]
Getronics Government Solutions, LLC
===========================================

From: "Pawling, John" <[email-masked]>
To: "'Dieter Bratko'" <[email-masked]>, "SMIME WG (E-mail)" <[email-masked]>
Subject: RE: cmsalg-02 RSA OID Proposal
Date: Wed, 12 Sep 2001 10:22:14 -0400
Sender: [email-masked]

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, [email-masked]
Getronics Government Solutions, LLC
===========================================

From: "Dieter Bratko" <[email-masked]>
To: "Pawling, John" <[email-masked]>, "SMIME WG \(E-mail\)" <[email-masked]>
Subject: AW: cmsalg-02 RSA OID Proposal
Date: Tue, 11 Sep 2001 17:58:25 +0200
Importance: Normal
Sender: [email-masked]

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: [email-masked]
[mailto:[email-masked]]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, [email-masked]
Getronics Government Solutions, LLC
===========================================

Date: Tue, 11 Sep 2001 07:58:09 -0700
From: [email-masked] (Terry Hayes)
To: [email-masked]
Subject: Re: cmsalg-02 RSA OID Proposal
Sender: [email-masked]

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

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, [email-masked]
 >Getronics Government Solutions, LLC
 >===========================================
 >

From: "Anders Rundgren" <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>
Subject: Re: S/MIME 3 Clients - Are there such?
Date: Tue, 11 Sep 2001 14:17:05 +0200
Sender: [email-masked]

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" <[email-masked]>
To: "Anders Rundgren" <[email-masked]>
Cc: <[email-masked]>
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.

Date: Mon, 10 Sep 2001 21:04:03 +0200
From: Michael =?iso-8859-1?Q?Str=F6der?= <[email-masked]>
Reply-To: [email-masked]
Organization: stroeder.com
To: Anders Rundgren <[email-masked]>
Cc: [email-masked]
Subject: Re: S/MIME 3 Clients - Are there such?
Sender: [email-masked]

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.

From: "Hegde, Vijaykumar" <[email-masked]>
To: [email-masked]
Subject: S/MIME and X.400
Date: Tue, 11 Sep 2001 12:33:56 +0530
Sender: [email-masked]

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

Reply-To: <[email-masked]>
From: "Jim Schaad" <[email-masked]>
To: "'Anders Rundgren'" <[email-masked]>, <[email-masked]>
Cc: <[email-masked]>
Subject: RE: S/MIME 3 Clients - Are there such?
Date: Mon, 10 Sep 2001 08:39:44 -0700
Importance: Normal
Sender: [email-masked]

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: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Anders Rundgren
> Sent: Monday, September 10, 2001 7:35 AM
> To: [email-masked]
> Cc: [email-masked]
> 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" <[email-masked]>
> To: "Anders Rundgren" <[email-masked]>
> Cc: <[email-masked]>
> 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.
> 

From: "Anders Rundgren" <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>
Subject: Re: S/MIME 3 Clients - Are there such?
Date: Mon, 10 Sep 2001 16:34:48 +0200
Sender: [email-masked]

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" <[email-masked]>
To: "Anders Rundgren" <[email-masked]>
Cc: <[email-masked]>
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.

Date: Mon, 10 Sep 2001 15:47:30 +0200
From: Michael =?iso-8859-1?Q?Str=F6der?= <[email-masked]>
Reply-To: [email-masked]
Organization: stroeder.com
To: Anders Rundgren <[email-masked]>
Cc: [email-masked]
Subject: Re: S/MIME 3 Clients - Are there such?
Sender: [email-masked]

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.

From: "Anders Rundgren" <[email-masked]>
To: <[email-masked]>
Subject: S/MIME 3 Clients - Are there such?
Date: Mon, 10 Sep 2001 13:32:48 +0200
Sender: [email-masked]

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

To: IETF-Announce: ;
Cc: [email-masked]
From: [email-masked]
Reply-to: [email-masked]
Subject: I-D ACTION:draft-ietf-smime-domsec-09.txt
Date: Mon, 10 Sep 2001 06:54:40 -0400
Sender: [email-masked]

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the S/MIME Mail Security Working Group of the IETF.

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

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

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

--OtherAccess--

--NextPart--

From: "Pawling, John" <[email-masked]>
To: "SMIME WG (E-mail)" <[email-masked]>
Subject: cmsalg-04 Comments
Date: Fri, 7 Sep 2001 16:37:26 -0400 
Sender: [email-masked]

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, [email-masked]
Getronics Government Solutions, LLC
===========================================

From: "Blake Ramsdell" <[email-masked]>
To: "'Pawling, John'" <[email-masked]>, [email-masked]
Subject: RE: cmsalg-02 RSA OID Proposal
Date: Thu, 6 Sep 2001 14:42:57 -0700
Sender: [email-masked]

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:[email-masked]]
Sent: Thursday, September 06, 2001 12:26 PM
To: [email-masked]
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, [email-masked]
Getronics Government Solutions, LLC
===========================================

-----Original Message-----
From: Housley, Russ [mailto:[email-masked]]
Sent: Thursday, September 06, 2001 11:31 AM
To: [email-masked]
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

From: "Pawling, John" <[email-masked]>
To: [email-masked]
Subject: RE: cmsalg-02 RSA OID Proposal
Date: Thu, 6 Sep 2001 15:25:51 -0400 
Sender: [email-masked]

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, [email-masked]
Getronics Government Solutions, LLC
===========================================

-----Original Message-----
From: Housley, Russ [mailto:[email-masked]]
Sent: Thursday, September 06, 2001 11:31 AM
To: [email-masked]
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

From: "Housley, Russ" <[email-masked]>
To: "Pawling, John" <[email-masked]>
Cc: "SMIME WG (E-mail)" <[email-masked]>
Date: Thu, 06 Sep 2001 14:44:41 -0400
Subject: RE: rfc2630bis-03 Comment
Sender: [email-masked]

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

From: "Pawling, John" <[email-masked]>
To: "SMIME WG (E-mail)" <[email-masked]>
Subject: RE: rfc2630bis-03 Comment
Date: Thu, 6 Sep 2001 13:36:59 -0400 
Sender: [email-masked]

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, [email-masked]
Getronics Government Solutions, LLC
===========================================

From: "Housley, Russ" <[email-masked]>
To: [email-masked]
Date: Thu, 06 Sep 2001 11:31:11 -0400
Subject: RE: cmsalg-02 RSA OID Proposal
Sender: [email-masked]

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, [email-masked]
>Getronics Government Solutions, LLC
>===========================================

From: "Housley, Russ" <[email-masked]>
To: "Pawling, John" <[email-masked]>
Cc: "SMIME WG (E-mail)" <[email-masked]>
Date: Thu, 06 Sep 2001 11:02:17 -0400
Subject: Re: rfc2630bis-03 Comment
Sender: [email-masked]

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

From: "Pawling, John" <[email-masked]>
To: [email-masked]
Subject: RE: cmsalg-02 RSA OID Proposal
Date: Thu, 6 Sep 2001 13:03:01 -0400 
Sender: [email-masked]

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, [email-masked]
Getronics Government Solutions, LLC
===========================================

From: "Housley, Russ" <[email-masked]>
To: [email-masked]
Date: Thu, 06 Sep 2001 11:14:51 -0400
Subject: WG Last Call: draft-ietf-smime-key-wrap-00.txt
Sender: [email-masked]

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

Date: Thu, 06 Sep 2001 08:53:30 -0400
To: [email-masked]
From: "Housley, Russ" <[email-masked]>
Subject: Re: I-D ACTION:draft-ietf-smime-cmsalg-04.txt
Sender: [email-masked]

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.
>
>         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: IETF-Announce: ;
Cc: [email-masked]
From: [email-masked]
Reply-to: [email-masked]
Subject: I-D ACTION:draft-ietf-smime-key-wrap-00.txt
Date: Thu, 06 Sep 2001 06:46:12 -0400
Sender: [email-masked]

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the S/MIME Mail Security Working Group of the IETF.

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

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

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

--OtherAccess--

--NextPart--

To: IETF-Announce: ;
Cc: [email-masked]
From: [email-masked]
Reply-to: [email-masked]
Subject: I-D ACTION:draft-ietf-smime-cmsalg-04.txt
Date: Thu, 06 Sep 2001 06:46:07 -0400
Sender: [email-masked]

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the S/MIME Mail Security Working Group of the IETF.

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

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

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

--OtherAccess--

--NextPart--

From: "Hegde, Vijaykumar" <[email-masked]>
To: Graeme Lunt <[email-masked]>, [email-masked]
Subject: RE: S/MIME support in X.400
Date: Thu, 6 Sep 2001 08:54:00 +0530 
Sender: [email-masked]

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

From: "Blake Ramsdell" <[email-masked]>
To: "'Pawling, John'" <[email-masked]>, [email-masked]
Subject: RE: cmsalg-02 RSA OID Proposal
Date: Wed, 5 Sep 2001 16:06:20 -0700
Sender: [email-masked]

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:[email-masked]]
Sent: Wednesday, September 05, 2001 2:11 PM
To: [email-masked]
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, [email-masked]
Getronics Government Solutions, LLC
===========================================

From: "Pawling, John" <[email-masked]>
To: [email-masked]
Subject: RE: cmsalg-02 RSA OID Proposal
Date: Wed, 5 Sep 2001 17:10:52 -0400 
Sender: [email-masked]

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, [email-masked]
Getronics Government Solutions, LLC
===========================================

From: "Blake Ramsdell" <[email-masked]>
To: "'Housley, Russ'" <[email-masked]>, [email-masked]
cc: [email-masked]
Subject: RE: cmsalg-02 RSA OID Proposal
Date: Wed, 5 Sep 2001 12:44:20 -0700
Sender: [email-masked]

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:[email-masked]]
Sent: Saturday, September 01, 2001 9:03 AM
To: [email-masked]
Cc: [email-masked]
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

From: "Pawling, John" <[email-masked]>
To: "SMIME WG (E-mail)" <[email-masked]>
Subject: rfc2630bis-03 Comment
Date: Wed, 5 Sep 2001 15:10:04 -0400 
Sender: [email-masked]

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, [email-masked]
Getronics Government Solutions, LLC
===========================================

To: IETF-Announce: ;
Cc: [email-masked]
From: [email-masked]
Reply-to: [email-masked]
Subject: I-D ACTION:draft-ietf-smime-compression-06.txt
Date: Wed, 05 Sep 2001 06:47:11 -0400
Sender: [email-masked]

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the S/MIME Mail Security Working Group of the IETF.

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

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

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

--OtherAccess--

--NextPart--

Date: Tue, 04 Sep 2001 10:33:51 -0400
To: [email-masked]
From: "Housley, Russ" <[email-masked]>
Subject: RFC2630bis Security Considerations
Sender: [email-masked]

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

To: IETF-Announce: ;
Cc: [email-masked]
From: [email-masked]
Reply-to: [email-masked]
Subject: I-D ACTION:draft-ietf-smime-cmsalg-03.txt
Date: Tue, 04 Sep 2001 06:48:26 -0400
Sender: [email-masked]

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the S/MIME Mail Security Working Group of the IETF.

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

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

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

--OtherAccess--

--NextPart--

To: IETF-Announce: ;
Cc: [email-masked]
From: [email-masked]
Reply-to: [email-masked]
Subject: I-D ACTION:draft-ietf-smime-rfc2630bis-03.txt
Date: Tue, 04 Sep 2001 06:48:22 -0400
Sender: [email-masked]

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the S/MIME Mail Security Working Group of the IETF.

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

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

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

--OtherAccess--

--NextPart--

From: "Housley, Russ" <[email-masked]>
To: [email-masked]
Cc: [email-masked]
Date: Sat, 01 Sep 2001 12:02:37 -0400
Subject: Re:  cmsalg-02 RSA OID Proposal
Sender: [email-masked]

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