Subject: draft-ietf-smime-camellia-03.txt ready for Standards Track

From: "Blake Ramsdell" <[email-masked]>
Date: Wed, 30 Apr 2003 13:57:20 -0700

Security Area Directors,

The S/MIME working group has completed its review of the "Use of the
Camellia Encryption Algorithm in CMS" draft,
draft-ietf-smime-camellia-03, and believe it is ready to be published as
a Standards Track RFC.

Blake
--
Blake Ramsdell | Brute Squad Labs | http://www.brutesquadlabs.com 

From: "Blake Ramsdell" <[email-masked]>
To: "'Russ Housley'" <[email-masked]>, <[email-masked]>
Cc: "'Sean P. Turner'" <[email-masked]>, <[email-masked]>
Subject: draft-ietf-smime-camellia-03.txt ready for Standards Track
Date: Wed, 30 Apr 2003 13:57:20 -0700
Importance: Normal
Sender: [email-masked]

Security Area Directors,

The S/MIME working group has completed its review of the "Use of the
Camellia Encryption Algorithm in CMS" draft,
draft-ietf-smime-camellia-03, and believe it is ready to be published as
a Standards Track RFC.

Blake
--
Blake Ramsdell | Brute Squad Labs | http://www.brutesquadlabs.com 

From: "Blake Ramsdell" <[email-masked]>
To: <[email-masked]>
Subject: BobPrivRSAEncrypt spuriosity
Date: Tue, 29 Apr 2003 13:49:10 -0700
Importance: Normal
Sender: [email-masked]

In examples-10, the dump of the data for BobPrivRSAEncrypt includes the
following:

 643 31    4:       SET {
 645 03    2:         BIT STRING 0 unused bits
            :           '00001000'B (bit 3)
            :           Error: Spurious zero bits in bitstring.
            :         }

As far as I can tell, the actual encoding for this BIT STRING is:

03 02 00 10

Which I believe is "zero unused bits at the end of 0001 0000".  In DER
encoding, I believe that this is an encoding violation.  In BER,
however, I believe this encoding is valid.

I don't think it's a problem -- Paul mentioned it to me, and I'm
pointing it out here in case there's something that needs to be changed.
I think it's a benign warning from the ASN.1 tool.

Blake
--
Blake Ramsdell | Brute Squad Labs | http://www.brutesquadlabs.com 

From: "Blake Ramsdell" <[email-masked]>
To: <[email-masked]>
Subject: WG Last Call: draft-ietf-smime-examples-10.txt
Date: Tue, 29 Apr 2003 12:13:44 -0700
Importance: Normal
Sender: [email-masked]

Dear S/MIME WG:

This message announces Working Group Last Call for the use of the
Examples of S/MIME Messages.

	Title		: Examples of S/MIME Messages
	Author(s)	: P. Hoffman
	Filename	: draft-ietf-smime-examples-10.txt
	Pages		: 8
	Date		: 2003-4-28

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

The intent is to publish this document as an Informational RFC.

Please review this draft and post any comments to the [email-masked]
mail list by Tuesday, 13 May 2003.  Unless traffic on the mail list
indicates otherwise, Sean and I will send this document to the RFC
editor shortly after WG Last Call closes.

Blake
--
Blake Ramsdell | Brute Squad Labs | http://www.brutesquadlabs.com 

To: IETF-Announce: ;
Cc: [email-masked]
From: [email-masked]
Reply-to: [email-masked]
Subject: I-D ACTION:draft-ietf-smime-examples-10.txt
Date: Tue, 29 Apr 2003 07:40:31 -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		: Examples of S/MIME Messages
	Author(s)	: P. Hoffman
	Filename	: draft-ietf-smime-examples-10.txt
	Pages		: 8
	Date		: 2003-4-28
	
This document gives examples of message bodies formatted using S/MIME.
Specifically, it has examples of Cryptographic Message Syntax (CMS)
objects, S/MIME messages (including the MIME formatting), and Enhanced
Security Services for S/MIME (ESS). It includes examples of most or all
common CMS and ESS formats; in addition, it gives examples that show
common pitfalls in implementing CMS. The purpose of this document is to
help increase interoperability for S/MIME and other protocols that rely
on CMS.
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/>.

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-examples-10.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-examples-10.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-examples-10.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-examples-10.txt

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

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

--OtherAccess--

--NextPart--

Date: Thu, 24 Apr 2003 09:59:22 -0400
To: "Blake Ramsdell" <[email-masked]>, <[email-masked]>
From: Russ Housley <[email-masked]>
Subject: Re: WG Last Call: draft-ietf-smime-camellia-03.txt
Sender: [email-masked]

The comments on that I posted on the last version have been resolved.

By the way, I compiled the ASN.1 module in Appendix A without error.

Russ

At 01:31 PM 4/23/2003 -0700, Blake Ramsdell wrote:

>Dear S/MIME WG:
>
>This message announces Working Group Last Call for the use of the
>Camellia Encryption Algorithm in CMS.
>
>         Title           : Use of the Camellia Encryption Algorithm in
>CMS
>         Author(s)       : S. Moriai, A. Kato
>         Filename        : draft-ietf-smime-camellia-03.txt
>         Pages           : 11
>         Date            : 2003-4-22
>
>A URL for this Internet-Draft is:
>http://www.ietf.org/internet-drafts/draft-ietf-smime-camellia-03.txt
>
>The intent is to publish this document as a Standards Track RFC.
>
>Please review this draft and post any comments to the [email-masked]
>mail list by Wednesday, 30 April 2003.  Unless traffic on the mail list
>indicates otherwise, Sean and I will send this document to the IESG
>shortly after WG Last Call closes.
>
></EndOfBoilerplate>
>
>Blake
>--
>Blake Ramsdell | Brute Squad Labs | http://www.brutesquadlabs.com

From: "Blake Ramsdell" <[email-masked]>
To: <[email-masked]>
Subject: WG Last Call: draft-ietf-smime-camellia-03.txt
Date: Wed, 23 Apr 2003 13:31:25 -0700
Importance: Normal
Sender: [email-masked]

Dear S/MIME WG:

This message announces Working Group Last Call for the use of the
Camellia Encryption Algorithm in CMS.

	Title		: Use of the Camellia Encryption Algorithm in
CMS
	Author(s)	: S. Moriai, A. Kato
	Filename	: draft-ietf-smime-camellia-03.txt
	Pages		: 11
	Date		: 2003-4-22

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

The intent is to publish this document as a Standards Track RFC.

Please review this draft and post any comments to the [email-masked]
mail list by Wednesday, 30 April 2003.  Unless traffic on the mail list
indicates otherwise, Sean and I will send this document to the IESG
shortly after WG Last Call closes.

</EndOfBoilerplate>

Blake
--
Blake Ramsdell | Brute Squad Labs | http://www.brutesquadlabs.com 

To: IETF-Announce: ;
Cc: RFC Editor <[email-masked]>, Internet Architecture Board <[email-masked]>, [email-masked]
From: The IESG <[email-masked]>
Subject: Protocol Action: Use of the RSAES-OAEP Transport Algorithm in CMS to Proposed Standard
Date: Wed, 23 Apr 2003 17:37:19 -0400
Sender: [email-masked]

The IESG has approved the Internet-Draft 'Use of the RSAES-OAEP
Transport Algorithm in CMS' <draft-ietf-smime-cms-rsaes-oaep-07.txt> 
as a Proposed Standard. This document is the product of the S/MIME 
Mail Security Working Group.

The IESG contact persons are Russ Housley and Steven Bellovin.

Technical Summary
   
The RSAES-OAEP Key Transport Algorithm uses a new version of
of PKCS #1 to counter the so-called Million Message Attack that
Version 1.5 was sometimes susceptible to. The document describes
how to embed such wrapped keys in Cryptographic Message Syntax (CMS)
bundles.
   
Working Group Summary
   
There were no significant issues.
   
Protocol Quality
   
Steve Bellovin has reviewed the spec for the IESG.

RFC Editor note:

In the last paragraph of Section 3, please change

                 represent P by an algorithm identifier

 to

                 represent P by the algorithm identifier

To: IETF-Announce: ;
Cc: [email-masked]
From: [email-masked]
Reply-to: [email-masked]
Subject: I-D ACTION:draft-ietf-smime-camellia-03.txt
Date: Wed, 23 Apr 2003 06:54:27 -0400
Sender: [email-masked]

--NextPart

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

	Title		: Use of the Camellia Encryption Algorithm in CMS
	Author(s)	: S. Moriai, A. Kato
	Filename	: draft-ietf-smime-camellia-03.txt
	Pages		: 11
	Date		: 2003-4-22
	
This document specifies the conventions for using the Camellia
encryption algorithm for encryption with the Cryptographic
Message Syntax (CMS).

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

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

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

--OtherAccess--

--NextPart--

Date: Fri, 11 Apr 2003 08:54:24 -0400
To: [email-masked]
From: Russ Housley <[email-masked]>
Subject: Re: Protocol Action: Wrapping an HMAC key with a Triple-DES Key or an AES Key to Proposed Standard
Cc: [email-masked], [email-masked], [email-masked]
Sender: [email-masked]

Peter:

> >>>This document defines a mechanism for "wrapping" (aka encrypting) an 
> HMAC key
> >>>with either Triple-DES or the Advanced Encryption Standard (AES). 
> Standards
> >>>already exist for wrapping Triple-DES keys in Triple-DES and AES keys 
> in AES.
> >>>However no standard exists for wrapping HMAC keys, which is what this 
> document
> >>>addresses.
> >>
> >>Actually a standard does exist for wrapping HMAC keys with any kind of key,
> >>formerly RFC 3211, now a part of RFC 3369.  This was pointed out over a 
> year
> >>ago during the draft process, but ignored by the RFC authors.  So now 
> we have
> >>two incompatible ways to wrap HMAC keys, one in RFC 3369, the other in this
> >>new RFC.
> >
> >Ignored is not a correct characterization.  I recall a discussion on the
> >S/MIME list.
>
>My apologies, I wasn't very clear in the above (see below).
>
> >As I recall, without searching the mail list archive, no one else voiced a
> >concern about publishing a second wrapping technique.  Several people voiced
> >approval for alignment with the NIST AES Key Wrap algorithm.  And, as is 
> often
> >the case in these matters, many people voiced no opinion one way or the 
> other.
>
>I have no objection to the publication of another key wrap algorithm, what I
>was commenting on was the abstract that was quoted in the announcement and
>that I quoted in my message, which states:
>
>   Standards already exist for wrapping Triple-DES keys in Triple-DES and AES
>   keys in AES. However no standard exists for wrapping HMAC keys, which is
>   what this document addresses.
>
>What it should say, to be accurate, is:
>
>   This document defines an additional HMAC key wrap mechanism alongside the
>   one in RFC 3369.
>
>I wasn't really commenting on the contents of the RFC itself, merely trying to
>correct the statement in the quoted abstract, which seemed to be ignoring the
>existing RFC 3369 (formerly RFC 3211) key wrap.  Sorry if I was unclear on
>that.

You are correct.  This could have been more clear.  It should have stated 
that an additional mechanism was being defined.

Russ

Date: Fri, 11 Apr 2003 14:59:03 +1200
From: [email-masked] (Peter Gutmann)
To: [email-masked], [email-masked]
Subject: Re: Protocol Action: Wrapping an HMAC key with a Triple-DES Key or an AES Key to Proposed Standard
Cc: [email-masked], [email-masked], [email-masked]
Sender: [email-masked]

Russ Housley <[email-masked]> writes:
>>>This document defines a mechanism for "wrapping" (aka encrypting) an HMAC key
>>>with either Triple-DES or the Advanced Encryption Standard (AES). Standards
>>>already exist for wrapping Triple-DES keys in Triple-DES and AES keys in AES.
>>>However no standard exists for wrapping HMAC keys, which is what this document
>>>addresses.
>>
>>Actually a standard does exist for wrapping HMAC keys with any kind of key,
>>formerly RFC 3211, now a part of RFC 3369.  This was pointed out over a year
>>ago during the draft process, but ignored by the RFC authors.  So now we have
>>two incompatible ways to wrap HMAC keys, one in RFC 3369, the other in this
>>new RFC.
>
>Ignored is not a correct characterization.  I recall a discussion on the
>S/MIME list.

My apologies, I wasn't very clear in the above (see below).

>As I recall, without searching the mail list archive, no one else voiced a
>concern about publishing a second wrapping technique.  Several people voiced
>approval for alignment with the NIST AES Key Wrap algorithm.  And, as is often
>the case in these matters, many people voiced no opinion one way or the other.

I have no objection to the publication of another key wrap algorithm, what I
was commenting on was the abstract that was quoted in the announcement and
that I quoted in my message, which states:

  Standards already exist for wrapping Triple-DES keys in Triple-DES and AES
  keys in AES. However no standard exists for wrapping HMAC keys, which is
  what this document addresses.

What it should say, to be accurate, is:

  This document defines an additional HMAC key wrap mechanism alongside the
  one in RFC 3369.

I wasn't really commenting on the contents of the RFC itself, merely trying to
correct the statement in the quoted abstract, which seemed to be ignoring the
existing RFC 3369 (formerly RFC 3211) key wrap.  Sorry if I was unclear on
that.

>I take issue with your characterization of the incompatibility.  Certainly,
>the two algorithms generate different outputs, [...]

>From Webster's Revised Unabridged Dictionary:

  \In`com*pat"i*ble\, a. [Pref. in- not + compatible: cf. F. incompatible.]
  [It was formerly sometimes written incompetible.] 1. Not compatible; so
  differing as to be incapable of harmonious combination or coexistence;
  [...]

Seems incompatible to me :-).

Peter.

Date: Thu, 10 Apr 2003 13:00:22 -0400
To: [email-masked]
From: Russ Housley <[email-masked]>
Subject: Re: Protocol Action: Wrapping an HMAC key with a Triple-DES Key or an AES Key to Proposed Standard
Cc: [email-masked], [email-masked], [email-masked]
Sender: [email-masked]

Peter:

> >This document defines a mechanism for "wrapping" (aka encrypting) an 
> HMAC key
> >with either Triple-DES or the Advanced Encryption Standard (AES). Standards
> >already exist for wrapping Triple-DES keys in Triple-DES and AES keys in 
> AES.
> >However no standard exists for wrapping HMAC keys, which is what this 
> document
> >addresses.
>
>Actually a standard does exist for wrapping HMAC keys with any kind of key,
>formerly RFC 3211, now a part of RFC 3369.  This was pointed out over a year
>ago during the draft process, but ignored by the RFC authors.  So now we have
>two incompatible ways to wrap HMAC keys, one in RFC 3369, the other in this
>new RFC.

Ignored is not a correct characterization.  I recall a discussion on the 
S/MIME list.

The protocol includes an algorithm identifier that tells the recipient 
which of the algorithms was employed by the originator.  So, I take issue 
with your characterization of the incompatibility.  Certainly, the two 
algorithms generate different outputs, and both the originator and the 
recipient need to implement the same algorithm to achieve interoperability.

As I recall, without searching the mail list archive, no one else voiced a 
concern about publishing a second wrapping technique.  Several people 
voiced approval for alignment with the NIST AES Key Wrap algorithm.  And, 
as is often the case in these matters, many people voiced no opinion one 
way or the other.

As working group chair at the time, I made the decision to proceed, after a 
brief verbal consultation with the Security Area Director.  I still believe 
that the right decision was made.

Russ

Date: Thu, 10 Apr 2003 19:08:56 +1200
From: [email-masked] (Peter Gutmann)
To: [email-masked], [email-masked]
Subject: Re: Protocol Action: Wrapping an HMAC key with a Triple-DES Key or an AES Key to Proposed Standard
Sender: [email-masked]

>This document defines a mechanism for "wrapping" (aka encrypting) an HMAC key
>with either Triple-DES or the Advanced Encryption Standard (AES). Standards
>already exist for wrapping Triple-DES keys in Triple-DES and AES keys in AES.
>However no standard exists for wrapping HMAC keys, which is what this document
>addresses.

Actually a standard does exist for wrapping HMAC keys with any kind of key,
formerly RFC 3211, now a part of RFC 3369.  This was pointed out over a year
ago during the draft process, but ignored by the RFC authors.  So now we have
two incompatible ways to wrap HMAC keys, one in RFC 3369, the other in this
new RFC.

Peter.

To: IETF-Announce: ;
Cc: RFC Editor <[email-masked]>, Internet Architecture Board <[email-masked]>, [email-masked]
From: The IESG <[email-masked]>
Subject: Protocol Action: Wrapping an HMAC key with a Triple-DES Key  or an AES Key to Proposed Standard
Date: Wed, 09 Apr 2003 16:54:10 -0400
Sender: [email-masked]

The IESG has approved the Internet-Draft 'Wrapping an HMAC key with a 
Triple-DES Key or an AES Key' <draft-ietf-smime-hmac-key-wrap-02.txt> 
as a Proposed Standard.  This document is the product of the S/MIME 
Mail Security Working Group.  The IESG contact persons are Steve
Bellovin and Jeffrey Schiller.

Technical Summary
 
This document defines a mechanism for "wrapping" (aka encrypting) an
HMAC key with either Triple-DES or the Advanced Encryption Standard
(AES). Standards already exist for wrapping Triple-DES keys in
Triple-DES and AES keys in AES. However no standard exists for wrapping
HMAC keys, which is what this document addresses.

Working Group Summary

The working group had consensus on this document.

Protocol Quality

Jeffrey I. Schiller reviewed this document for the IESG.

To: IETF-Announce: ;
Cc: RFC Editor <[email-masked]>, Internet Architecture Board <[email-masked]>, [email-masked]
From: The IESG <[email-masked]>
Subject: Protocol Action: Wrapping an HMAC key with a Triple-DES Key  or an AES Key to Proposed Standard
Date: Wed, 09 Apr 2003 16:54:10 -0400
Sender: [email-masked]

The IESG has approved the Internet-Draft 'Wrapping an HMAC key with a 
Triple-DES Key or an AES Key' <draft-ietf-smime-hmac-key-wrap-02.txt> 
as a Proposed Standard.  This document is the product of the S/MIME 
Mail Security Working Group.  The IESG contact persons are Steve
Bellovin and Jeffrey Schiller.

Technical Summary
 
This document defines a mechanism for "wrapping" (aka encrypting) an
HMAC key with either Triple-DES or the Advanced Encryption Standard
(AES). Standards already exist for wrapping Triple-DES keys in
Triple-DES and AES keys in AES. However no standard exists for wrapping
HMAC keys, which is what this document addresses.

Working Group Summary

The working group had consensus on this document.

Protocol Quality

Jeffrey I. Schiller reviewed this document for the IESG.

Date: Wed, 09 Apr 2003 16:34:34 -0400
To: Akihiro KATO <[email-masked]>, [email-masked]
From: Russ Housley <[email-masked]>
Subject: Re: WG Last Call: draft-ietf-smime-camellia-02.txt
Cc: [email-masked]
Sender: [email-masked]

This resolves comments 1, 2, and 3.  Thanks.

Russ

At 02:10 PM 4/9/2003 +0900, Akihiro KATO wrote:

>Russ,
>   Thanks for the comments.
>
>On Mon, 07 Apr 2003 17:06:25 -0400
>Russ Housley <[email-masked]> wrote:
>
> >
> > I have four comments on draft-ietf-smime-camellia-02.txt.
> >
> > 1.  The reference to RFC 2119 does not belong in the Abstract.  It belongs
> > in the Introduction.  Many documents place it in a subsection of the
> > Introduction, called "Terminology"
> >
> > 2.  I propose an alternative Abstract:
> >
> >      This document specifies the conventions for using the Camellia
> >      encryption algorithm for encryption with the Cryptographic
> >      Message Syntax (CMS).
> >
> > 3.  I propose an alternative for the first paragraph in the Introduction:
> >
> >      This document specifies the conventions for using the Camellia
> >      encryption algorithm [CamelliaSpec][CamelliaID] for encryption with
> >      the Cryptographic Message Syntax (CMS) [CMS].  The relevant object
> >      identifiers (OIDs) and processing steps are provided so that
> >      Camellia may be used in the CMS specification (RFC 3369, RFC 3370)
> >      for content and key encryption.
>
>I summarized above three comments, rewrote as follows.
>
>---
>Abstract
>     This document specifies the conventions for using the Camellia
>     encryption algorithm for encryption with the Cryptographic
>     Message Syntax (CMS).
>
>1. Introduction
>
>     This document specifies the conventions for using the Camellia
>     encryption algorithm [CamelliaSpec][CamelliaID] for encryption with
>     the Cryptographic Message Syntax (CMS) [CMS].  The relevant object
>     identifiers (OIDs) and processing steps are provided so that
>     Camellia may be used in the CMS specification (RFC 3369, RFC 3370)
>     for content and key encryption.
>
>1.1 Camellia
>
>     Camellia ....(snip)
>
>1.2 Terminology
>
>     The key words "MUST", "MUST NOT", "REQUIRED", "SHOULD", "SHOULD
>     NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document (in
>     uppercase, as shown) are to be interpreted as described in
>     [RFC2119].
>---
>
>If your intention is this text, I want to rewrite in this way.
>
> > 4.  The ASN.1 module needs a module identifier.  Please send email to
> > [email-masked] if you want it assigned from the S/MIME WG arc.
>I sent this mail since I wanted to register this OID.
>
>Best regards.
>--
>- Akihiro KATO
>   + NTT Software Corporation
>    + Internet Technology Laboratory

Date: Wed, 09 Apr 2003 14:10:33 +0900
From: Akihiro KATO <[email-masked]>
To: [email-masked]
Subject: Re: WG Last Call: draft-ietf-smime-camellia-02.txt
Cc: [email-masked]
Sender: [email-masked]

Russ,
  Thanks for the comments.

On Mon, 07 Apr 2003 17:06:25 -0400
Russ Housley <[email-masked]> wrote:

> 
> I have four comments on draft-ietf-smime-camellia-02.txt.
> 
> 1.  The reference to RFC 2119 does not belong in the Abstract.  It belongs 
> in the Introduction.  Many documents place it in a subsection of the 
> Introduction, called "Terminology"
> 
> 2.  I propose an alternative Abstract:
> 
>      This document specifies the conventions for using the Camellia
>      encryption algorithm for encryption with the Cryptographic
>      Message Syntax (CMS).
> 
> 3.  I propose an alternative for the first paragraph in the Introduction:
> 
>      This document specifies the conventions for using the Camellia
>      encryption algorithm [CamelliaSpec][CamelliaID] for encryption with
>      the Cryptographic Message Syntax (CMS) [CMS].  The relevant object
>      identifiers (OIDs) and processing steps are provided so that
>      Camellia may be used in the CMS specification (RFC 3369, RFC 3370)
>      for content and key encryption.

I summarized above three comments, rewrote as follows.

---
Abstract
    This document specifies the conventions for using the Camellia
    encryption algorithm for encryption with the Cryptographic
    Message Syntax (CMS).

1. Introduction 

    This document specifies the conventions for using the Camellia
    encryption algorithm [CamelliaSpec][CamelliaID] for encryption with
    the Cryptographic Message Syntax (CMS) [CMS].  The relevant object
    identifiers (OIDs) and processing steps are provided so that
    Camellia may be used in the CMS specification (RFC 3369, RFC 3370)
    for content and key encryption.

1.1 Camellia

    Camellia ....(snip)

1.2 Terminology

    The key words "MUST", "MUST NOT", "REQUIRED", "SHOULD", "SHOULD
    NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document (in
    uppercase, as shown) are to be interpreted as described in
    [RFC2119].
---

If your intention is this text, I want to rewrite in this way.

> 4.  The ASN.1 module needs a module identifier.  Please send email to 
> [email-masked] if you want it assigned from the S/MIME WG arc.
I sent this mail since I wanted to register this OID. 

Best regards.
--
- Akihiro KATO
  + NTT Software Corporation
   + Internet Technology Laboratory

Date: Mon, 07 Apr 2003 17:06:25 -0400
To: <[email-masked]>
From: Russ Housley <[email-masked]>
Subject: Re: WG Last Call: draft-ietf-smime-camellia-02.txt
Sender: [email-masked]

I have four comments on draft-ietf-smime-camellia-02.txt.

1.  The reference to RFC 2119 does not belong in the Abstract.  It belongs 
in the Introduction.  Many documents place it in a subsection of the 
Introduction, called "Terminology"

2.  I propose an alternative Abstract:

     This document specifies the conventions for using the Camellia
     encryption algorithm for encryption with the Cryptographic
     Message Syntax (CMS).

3.  I propose an alternative for the first paragraph in the Introduction:

     This document specifies the conventions for using the Camellia
     encryption algorithm [CamelliaSpec][CamelliaID] for encryption with
     the Cryptographic Message Syntax (CMS) [CMS].  The relevant object
     identifiers (OIDs) and processing steps are provided so that
     Camellia may be used in the CMS specification (RFC 3369, RFC 3370)
     for content and key encryption.

4.  The ASN.1 module needs a module identifier.  Please send email to 
[email-masked] if you want it assigned from the S/MIME WG arc.

Russ

Date: Thu, 03 Apr 2003 14:59:30 -0500
To: "Bonatti, Chris" <[email-masked]>, "'Blake Ramsdell'" <[email-masked]>, "'Pandey, Arun'" <[email-masked]>
From: Russ Housley <[email-masked]>
Subject: RE: Queries on Message/rfc822, Compressed-Data.
Cc: [email-masked]
Sender: [email-masked]

<html>
<body>
Chris:<br><br>
I assigned:<br><br>
&nbsp; id-eit-compressedData&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; OBJECT
IDENTIFIER ::= { id-eit 7 }<br><br>
Russ<br><br>
<br>
At 11:40 PM 4/2/2003 -0500, Bonatti, Chris wrote:<br>
<blockquote type=cite class=cite cite><font face="arial" size=2 color="#0000FF">I'll
update the draft to assign the next available value.</font><br>
&nbsp;<br>
<font face="arial" size=2 color="#0000FF">Chris</font><br>
&nbsp;<br>
&nbsp;<br>
<font face="tahoma" size=2>-----Original Message-----<br>
<b>From:</b> Blake Ramsdell
[<a href="mailto:[email-masked]" eudora="autourl">mailto:[email-masked]</a>]
<br>
<b>Sent:</b> Wednesday, April 02, 2003 20:09<br>
<b>To:</b> 'Bonatti, Chris'; 'Pandey, Arun'; 'Russ Housley'<br>
<b>Cc:</b> [email-masked]<br>
<b>Subject:</b> RE: Queries on Message/rfc822, Compressed-Data.<br><br>
</font><font face="arial" size=2 color="#0000FF">Since RFC3274 isn't
going to be updated anytime soon, I would recommend that the EIT value be
placed in the x400transport draft.</font><br>
&nbsp;<br>
<font face="arial" size=2 color="#0000FF">Blake</font><br>

<dl>
<dd><font face="tahoma" size=2>-----Original Message-----<br>

<dd>From:</b> [email-masked]
[<a href="mailto:[email-masked]" eudora="autourl">mailto:[email-masked]</a>]
On Behalf Of </b>Bonatti, Chris<br>

<dd>Sent:</b> Wednesday, April 02, 2003 3:17 PM<br>

<dd>To:</b> 'Pandey, Arun'; 'Russ Housley'<br>

<dd>Cc:</b> [email-masked]<br>

<dd>Subject:</b> RE: Queries on Message/rfc822, 
Compressed-Data.<br><br>
</font>
<dd><font face="arial" size=2 color="#0000FF">Yes, this probably makes
sense.</font><br>

<dd>&nbsp;<br>

<dd><font face="arial" size=2 color="#0000FF">I overlooked this because
compressed-data was a draft when x400transport was drafted.&nbsp; Since
compressed-data is not in 2633bis it would probably make more sense to
define the EIT for this in RFC 3274.&nbsp; However, there is also benefit
to all the X.400 stuff being here.&nbsp; I suppose I would favor the
latter.</font><br>

<dd>&nbsp;<br>

<dd><font face="arial" size=2 color="#0000FF">Chris</font><br>

<dd>&nbsp;<br>

<dd>&nbsp;<br>

<dd>&nbsp;<br>

<dd><font face="tahoma" size=2>-----Original Message-----<br>

<dd>From:</b> [email-masked]
[<a href="mailto:[email-masked]" eudora="autourl">mailto:[email-masked]</a>]
On Behalf Of </b>Pandey, Arun<br>

<dd>Sent:</b> Tuesday, April 01, 2003 06:55<br>

<dd>To:</b> 'Russ Housley'<br>

<dd>Cc:</b> [email-masked]<br>

<dd>Subject:</b> RE: Queries on Message/rfc822, 
Compressed-Data.<br><br>
</font>
<dd>&nbsp;<br>

<dd><font face="arial" size=2 color="#0000FF">Hi Russ,</font><br>

<dd>&nbsp;<br>

<dd><font face="arial" size=2 color="#0000FF">As per
draft-ietf-smime-x400transport-05.txt to convey information about the
contained content </font><br>

<dd><font face="arial" size=2 color="#0000FF">of an S/MIME message in an
X.400 transport environment EITs are used. </font><br>

<dd>&nbsp;<br>

<dd><font face="arial" size=2 color="#0000FF">Section 2.5 (2.5.1 to
2.5.6) of draft-ietf-smime-x400transport-05.txt define the EITs
for:</font><br>

<dd><font face="arial" size=2 color="#0000FF">1. Enveloped
Data</font><br>

<dd><font face="arial" size=2 color="#0000FF">2. Signed Data</font><br>

<dd><font face="arial" size=2 color="#0000FF">3. Certificate
Management</font><br>

<dd><font face="arial" size=2 color="#0000FF">4. Signed
Receipt</font><br>

<dd><font face="arial" size=2 color="#0000FF">5. Enveloped
X.400</font><br>

<dd><font face="arial" size=2 color="#0000FF">6. Signed 
X.400</font><br>

<dd>&nbsp;<br>

<dd><font face="arial" size=2 color="#0000FF">These match with the
corresponding EITs defined in
<a href="http://www.imc.org/ietf-smime/sm-oid.asn" eudora="autourl">http://www.imc.org/ietf-smime/sm-oid.asn</a></font><br>

<dd><font face="arial" size=2 color="#0000FF">-- X.400 Encoded
Information Types (EIT) for S/MIME objects</font><br>

<dd><font face="arial" size=2 color="#0000FF">id-eit-envelopedData OBJECT
IDENTIFIER ::= { id-eit 1 }</font><br>

<dd><font face="arial" size=2 color="#0000FF">id-eit-signedData OBJECT
IDENTIFIER ::= { id-eit 2 }</font><br>

<dd><font face="arial" size=2 color="#0000FF">id-eit-certManagement
OBJECT IDENTIFIER ::= { id-eit 3 }</font><br>

<dd><font face="arial" size=2 color="#0000FF">id-eit-signedReceipt OBJECT
IDENTIFIER ::= { id-eit 4 }</font><br>

<dd><font face="arial" size=2 color="#0000FF">id-eit-envelopedx400 OBJECT
IDENTIFIER ::= { id-eit 5 }</font><br>

<dd><font face="arial" size=2 color="#0000FF">id-eit-signedx400 OBJECT
IDENTIFIER ::= { id-eit 6 }</font><br>

<dd>&nbsp;<br>

<dd><font face="arial" size=2 color="#0000FF">I am unable to find the
corresponding EIT definition for the smime-type parameter </font><br>

<dd><font face="arial" size=2 color="#0000FF">'compressed-data'(CompressedData),
that has been newly introduced in the 'draft-ietf-smime-</font><br>

<dd><font face="arial" size=2 color="#0000FF">rfc2633bis-03.txt'.
</font><br>

<dd>&nbsp;<br>

<dd><font face="arial" size=2 color="#0000FF">Best Regards</font><br>

<dd><font face="arial" size=2 color="#0000FF">Arun Pandey</font><br>

<dd>&nbsp;<br>

<dd><font face="tahoma" size=2>-----Original Message-----<br>

<dd>From:</b> Russ Housley
[<a href="mailto:[email-masked]" eudora="autourl">mailto:[email-masked]</a>]<br>

<dd>Sent:</b> Thursday, March 27, 2003 1:33 AM<br>

<dd>To:</b> Pandey, Arun<br>

<dd>Cc:</b> [email-masked]<br>

<dd>Subject:</b> Re: Queries on Message/rfc822, 
Compressed-Data.<br><br>
</font>
<dd>These are both discussed in the most recent MSG draft.<br>

<dd>Please see draft-ietf-smime-rfc2633bis-03.txt.<br><br>

<dd>Russ<br><br>

<dd>At 03:40 PM 3/26/2003 +0530, Pandey, Arun wrote:<br><br>
<blockquote type=cite class=cite cite>
<dd><font size=2>Hi,</font> <br><br>

<dd><font size=2>I had the following 2 queries. Would appreciate a
response on these if possible:</font> <br><br>

<dd><font size=2>1. Going&nbsp; through the S/MIME mail archive I find a
discussion on the use of message types like </font><br>

<dd><font size=2>&nbsp;&nbsp;&nbsp; message/rfc822, message/partial etc.
that could be used to wrap a protected message (MIME </font><br>

<dd><font size=2>&nbsp;&nbsp;&nbsp; content + RFC822 Headers). Also as
per MOM of the 54th IETF meeting it seems that </font><br>

<dd><font size=2>&nbsp;&nbsp;&nbsp; message/rfc822 message type has been
finalized for this purpose.</font> <br><br>

<dd><font size=2>&nbsp;&nbsp;&nbsp; My question is how should one
distinguish such a message ( A protected message wrapped </font><br>

<dd><font size=2>&nbsp;&nbsp;&nbsp; in message/rfc822) from a forwarded
message which also has a message type of </font><br>

<dd><font size=2>&nbsp;&nbsp;&nbsp; message/rfc822 and can also contain a
non protected message? Is an example message of </font><br>

<dd><font size=2>&nbsp;&nbsp;&nbsp; type message/rfc822 containing a
protected message available for reference?</font> <br><br>

<dd><font size=2>2. The latest draft 'S/MIME Version 3.1 Message
Specification' (draft-ietf-smime-rfc2633bis-03.txt)</font> <br>

<dd><font size=2>&nbsp;&nbsp;&nbsp; mentions a new S/MIME type
&quot;compressed-data&quot;. However for this new S/MIME type no
</font><br>

<dd><font size=2>&nbsp;&nbsp;&nbsp; corresponding EIT has been defined in
the S/MIME TRANSPORT draft. Where would one be </font><br>

<dd><font size=2>&nbsp;&nbsp;&nbsp; able to find the corresponding EIT
for the same?</font> <br><br>

<dd><font size=2>Best Regards</font> <br>

<dd><font size=2>Arun Pandey</font> </blockquote>
</dl></blockquote></body>
</html>

Date: Wed, 02 Apr 2003 23:40:11 -0500
From: "Bonatti, Chris" <[email-masked]>
Subject: RE: Queries on Message/rfc822, Compressed-Data.
To: "'Blake Ramsdell'" <[email-masked]>, "'Pandey, Arun'" <[email-masked]>, "'Russ Housley'" <[email-masked]>
Cc: [email-masked]
Organization: IECA, Inc.
Importance: Normal
Sender: [email-masked]

This is a multi-part message in MIME format.

--Boundary_(ID_ri35ulTa+sfqoza4zDzFIg)
Content-type: text/plain; charset=us-ascii
Content-transfer-encoding: 7BIT

I'll update the draft to assign the next available value.
 
Chris

-----Original Message-----
From: Blake Ramsdell [mailto:[email-masked]] 
Sent: Wednesday, April 02, 2003 20:09
To: 'Bonatti, Chris'; 'Pandey, Arun'; 'Russ Housley'
Cc: [email-masked]
Subject: RE: Queries on Message/rfc822, Compressed-Data.

Since RFC3274 isn't going to be updated anytime soon, I would recommend
that the EIT value be placed in the x400transport draft.
 
Blake

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On Behalf Of Bonatti, Chris
Sent: Wednesday, April 02, 2003 3:17 PM
To: 'Pandey, Arun'; 'Russ Housley'
Cc: [email-masked]
Subject: RE: Queries on Message/rfc822, Compressed-Data.

Yes, this probably makes sense.
 
I overlooked this because compressed-data was a draft when x400transport
was drafted.  Since compressed-data is not in 2633bis it would probably
make more sense to define the EIT for this in RFC 3274.  However, there
is also benefit to all the X.400 stuff being here.  I suppose I would
favor the latter.
 
Chris

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On Behalf Of Pandey, Arun
Sent: Tuesday, April 01, 2003 06:55
To: 'Russ Housley'
Cc: [email-masked]
Subject: RE: Queries on Message/rfc822, Compressed-Data.

Hi Russ,
 
As per draft-ietf-smime-x400transport-05.txt to convey information about
the contained content 
of an S/MIME message in an X.400 transport environment EITs are used. 
 
Section 2.5 (2.5.1 to 2.5.6) of draft-ietf-smime-x400transport-05.txt
define the EITs for:
1. Enveloped Data
2. Signed Data
3. Certificate Management
4. Signed Receipt
5. Enveloped X.400
6. Signed X.400
 
These match with the corresponding EITs defined in
http://www.imc.org/ietf-smime/sm-oid.asn
-- X.400 Encoded Information Types (EIT) for S/MIME objects
id-eit-envelopedData OBJECT IDENTIFIER ::= { id-eit 1 }
id-eit-signedData OBJECT IDENTIFIER ::= { id-eit 2 }
id-eit-certManagement OBJECT IDENTIFIER ::= { id-eit 3 }
id-eit-signedReceipt OBJECT IDENTIFIER ::= { id-eit 4 }
id-eit-envelopedx400 OBJECT IDENTIFIER ::= { id-eit 5 }
id-eit-signedx400 OBJECT IDENTIFIER ::= { id-eit 6 }
 
I am unable to find the corresponding EIT definition for the smime-type
parameter 
'compressed-data'(CompressedData), that has been newly introduced in the
'draft-ietf-smime-
rfc2633bis-03.txt'. 
 
Best Regards
Arun Pandey

-----Original Message-----
From: Russ Housley [mailto:[email-masked]]
Sent: Thursday, March 27, 2003 1:33 AM
To: Pandey, Arun
Cc: [email-masked]
Subject: Re: Queries on Message/rfc822, Compressed-Data.

These are both discussed in the most recent MSG draft.
Please see draft-ietf-smime-rfc2633bis-03.txt.

Russ

At 03:40 PM 3/26/2003 +0530, Pandey, Arun wrote:

Hi, 

I had the following 2 queries. Would appreciate a response on these if
possible: 

1. Going  through the S/MIME mail archive I find a discussion on the use
of message types like 
    message/rfc822, message/partial etc. that could be used to wrap a
protected message (MIME 
    content + RFC822 Headers). Also as per MOM of the 54th IETF meeting
it seems that 
    message/rfc822 message type has been finalized for this purpose. 

    My question is how should one distinguish such a message ( A
protected message wrapped 
    in message/rfc822) from a forwarded message which also has a message
type of 
    message/rfc822 and can also contain a non protected message? Is an
example message of 
    type message/rfc822 containing a protected message available for
reference? 

2. The latest draft 'S/MIME Version 3.1 Message Specification'
(draft-ietf-smime-rfc2633bis-03.txt) 
    mentions a new S/MIME type "compressed-data". However for this new
S/MIME type no 
    corresponding EIT has been defined in the S/MIME TRANSPORT draft.
Where would one be 
    able to find the corresponding EIT for the same? 

Best Regards 
Arun Pandey 

--Boundary_(ID_ri35ulTa+sfqoza4zDzFIg)
Content-type: text/html; charset=us-ascii
Content-transfer-encoding: 7BIT

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=us-ascii">
<TITLE>Message</TITLE>

<META content="MSHTML 6.00.2800.1141" name=GENERATOR></HEAD>
<BODY>
<DIV><SPAN class=626283904-03042003><FONT face=Arial color=#0000ff size=2>I'll 
update the draft to assign the next available value.</FONT></SPAN></DIV>
<DIV><SPAN class=626283904-03042003><FONT face=Arial color=#0000ff 
size=2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=626283904-03042003><FONT face=Arial color=#0000ff 
size=2>Chris</FONT></SPAN></DIV>
<DIV><SPAN class=626283904-03042003><FONT face=Arial color=#0000ff 
size=2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=626283904-03042003></SPAN>&nbsp;</DIV>
<DIV></DIV>
<DIV class=OutlookMessageHeader lang=en-us dir=ltr align=left><FONT face=Tahoma 
size=2>-----Original Message-----<BR><B>From:</B> Blake Ramsdell 
[mailto:[email-masked]] <BR><B>Sent:</B> Wednesday, April 02, 2003 
20:09<BR><B>To:</B> 'Bonatti, Chris'; 'Pandey, Arun'; 'Russ 
Housley'<BR><B>Cc:</B> [email-masked]<BR><B>Subject:</B> RE: Queries on 
Message/rfc822, Compressed-Data.<BR><BR></FONT></DIV>
<DIV><SPAN class=041570201-03042003><FONT face=Arial color=#0000ff size=2>Since 
RFC3274 isn't going to be updated anytime soon, I would recommend that the EIT 
value be placed in the x400transport draft.</FONT></SPAN></DIV>
<DIV><SPAN class=041570201-03042003><FONT face=Arial color=#0000ff 
size=2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=041570201-03042003><FONT face=Arial color=#0000ff 
size=2>Blake</FONT></SPAN></DIV>
<BLOCKQUOTE dir=ltr 
style="PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #0000ff 2px solid; MARGIN-RIGHT: 0px">
  <DIV></DIV>
  <DIV class=OutlookMessageHeader lang=en-us dir=ltr align=left><FONT 
  face=Tahoma size=2>-----Original Message-----<BR><B>From:</B> 
  [email-masked] [mailto:[email-masked]] <B>On 
  Behalf Of </B>Bonatti, Chris<BR><B>Sent:</B> Wednesday, April 02, 2003 3:17 
  PM<BR><B>To:</B> 'Pandey, Arun'; 'Russ Housley'<BR><B>Cc:</B> 
  [email-masked]<BR><B>Subject:</B> RE: Queries on Message/rfc822, 
  Compressed-Data.<BR><BR></FONT></DIV>
  <DIV><SPAN class=815361123-02042003><FONT face=Arial color=#0000ff size=2>Yes, 
  this probably makes sense.</FONT></SPAN></DIV>
  <DIV><SPAN class=815361123-02042003><FONT face=Arial color=#0000ff 
  size=2></FONT></SPAN>&nbsp;</DIV>
  <DIV><SPAN class=815361123-02042003><FONT face=Arial color=#0000ff size=2>I 
  overlooked this because compressed-data was a draft when x400transport was 
  drafted.&nbsp; Since compressed-data is not in 2633bis it would probably make 
  more sense to define the EIT for this in RFC 3274.&nbsp; However, there is 
  also benefit to all the X.400 stuff being here.&nbsp; I suppose I would favor 
  the latter.</FONT></SPAN></DIV>
  <DIV><SPAN class=815361123-02042003><FONT face=Arial color=#0000ff 
  size=2></FONT></SPAN>&nbsp;</DIV>
  <DIV><SPAN class=815361123-02042003><FONT face=Arial color=#0000ff 
  size=2>Chris</FONT></SPAN></DIV>
  <DIV><SPAN class=815361123-02042003></SPAN>&nbsp;</DIV>
  <DIV><SPAN class=815361123-02042003><FONT face=Arial color=#0000ff 
  size=2></FONT></SPAN>&nbsp;</DIV>
  <DIV><SPAN class=815361123-02042003><FONT face=Arial color=#0000ff 
  size=2></FONT></SPAN>&nbsp;</DIV>
  <DIV></DIV>
  <DIV class=OutlookMessageHeader lang=en-us dir=ltr align=left><FONT 
  face=Tahoma size=2>-----Original Message-----<BR><B>From:</B> 
  [email-masked] [mailto:[email-masked]] <B>On 
  Behalf Of </B>Pandey, Arun<BR><B>Sent:</B> Tuesday, April 01, 2003 
  06:55<BR><B>To:</B> 'Russ Housley'<BR><B>Cc:</B> 
  [email-masked]<BR><B>Subject:</B> RE: Queries on Message/rfc822, 
  Compressed-Data.<BR><BR></FONT></DIV>
  <DIV><FONT face=Arial color=#0000ff size=2></FONT>&nbsp;</DIV>
  <DIV><FONT face=Arial color=#0000ff size=2>Hi Russ,</FONT></DIV>
  <DIV><FONT face=Arial color=#0000ff size=2></FONT>&nbsp;</DIV>
  <DIV><FONT size=2><FONT face=Arial color=#0000ff>As per 
  draft-ietf-smime-x400transport-05.txt to convey information </FONT><FONT 
  face=Arial color=#0000ff>about the contained content </FONT></FONT></DIV>
  <DIV><FONT size=2><FONT face=Arial color=#0000ff>of an S/MIME message in an 
  X.400 transport </FONT><FONT face=Arial color=#0000ff>environment EITs are 
  used. </FONT></FONT></DIV>
  <DIV>&nbsp;</DIV>
  <DIV><FONT face=Arial color=#0000ff size=2>Section 2.5 (2.5.1 to 2.5.6) of 
  draft-ietf-smime-x400transport-05.txt define the EITs for:</FONT></DIV>
  <DIV><FONT face=Arial color=#0000ff size=2>1. Enveloped Data</FONT></DIV>
  <DIV><FONT face=Arial color=#0000ff size=2>2. Signed Data</FONT></DIV>
  <DIV><FONT face=Arial color=#0000ff size=2>3. Certificate 
  Management</FONT></DIV>
  <DIV><FONT face=Arial color=#0000ff size=2>4. Signed Receipt</FONT></DIV>
  <DIV><FONT face=Arial color=#0000ff size=2>5. Enveloped X.400</FONT></DIV>
  <DIV><FONT face=Arial color=#0000ff size=2>6. Signed X.400</FONT></DIV>
  <DIV><FONT face=Arial color=#0000ff></FONT>&nbsp;</DIV>
  <DIV><FONT face=Arial color=#0000ff size=2>These match with the corresponding 
  EITs defined in http://www.imc.org/ietf-smime/sm-oid.asn</FONT></DIV>
  <DIV><FONT face=Arial color=#0000ff size=2>-- X.400 Encoded Information Types 
  (EIT) for S/MIME objects</FONT></DIV>
  <DIV><FONT face=Arial color=#0000ff size=2>id-eit-envelopedData OBJECT 
  IDENTIFIER ::= { id-eit 1 }</FONT></DIV>
  <DIV><FONT face=Arial color=#0000ff size=2>id-eit-signedData OBJECT IDENTIFIER 
  ::= { id-eit 2 }</FONT></DIV>
  <DIV><FONT face=Arial color=#0000ff size=2>id-eit-certManagement OBJECT 
  IDENTIFIER ::= { id-eit 3 }</FONT></DIV>
  <DIV><FONT face=Arial color=#0000ff size=2>id-eit-signedReceipt OBJECT 
  IDENTIFIER ::= { id-eit 4 }</FONT></DIV>
  <DIV><FONT face=Arial color=#0000ff size=2>id-eit-envelopedx400 OBJECT 
  IDENTIFIER ::= { id-eit 5 }</FONT></DIV>
  <DIV><FONT face=Arial color=#0000ff size=2>id-eit-signedx400 OBJECT IDENTIFIER 
  ::= { id-eit 6 }</FONT></DIV>
  <DIV><FONT face=Arial color=#0000ff></FONT>&nbsp;</DIV>
  <DIV><FONT face=Arial color=#0000ff size=2>I am unable to find&nbsp;<SPAN 
  class=747555611-01042003>the corresponding</SPAN> EIT definition for the 
  smime-type parameter </FONT></DIV>
  <DIV><FONT face=Arial color=#0000ff size=2>'compressed-data'(CompressedData), 
  that has been newly introduced in the 'draft-ietf-smime-</FONT></DIV>
  <DIV><FONT size=2><FONT color=#0000ff><FONT 
  face=Arial>rfc2633bis-03.txt'.<SPAN class=747555611-01042003> 
  </SPAN></FONT></FONT></FONT></DIV>
  <DIV><FONT face=Arial color=#0000ff size=2></FONT>&nbsp;</DIV>
  <DIV><FONT face=Arial color=#0000ff size=2>Best Regards</FONT></DIV>
  <DIV><FONT face=Arial color=#0000ff size=2>Arun Pandey</FONT></DIV>
  <DIV><FONT face=Arial color=#0000ff size=2></FONT>&nbsp;</DIV>
  <BLOCKQUOTE style="MARGIN-RIGHT: 0px">
    <DIV class=OutlookMessageHeader dir=ltr align=left><FONT face=Tahoma 
    size=2>-----Original Message-----<BR><B>From:</B> Russ Housley 
    [mailto:[email-masked]]<BR><B>Sent:</B> Thursday, March 27, 2003 1:33 
    AM<BR><B>To:</B> Pandey, Arun<BR><B>Cc:</B> 
    [email-masked]<BR><B>Subject:</B> Re: Queries on Message/rfc822, 
    Compressed-Data.<BR><BR></DIV></FONT>These are both discussed in the most 
    recent MSG draft.<BR>Please see 
    draft-ietf-smime-rfc2633bis-03.txt.<BR><BR>Russ<BR><BR>At 03:40 PM 3/26/2003 
    +0530, Pandey, Arun wrote:<BR><BR>
    <BLOCKQUOTE class=cite cite="" type="cite"><FONT size=2>Hi,</FONT> 
      <BR><BR><FONT size=2>I had the following 2 queries. Would appreciate a 
      response on these if possible:</FONT> <BR><BR><FONT size=2>1. Going&nbsp; 
      through the S/MIME mail archive I find a discussion on the use of message 
      types like </FONT><BR><FONT size=2>&nbsp;&nbsp;&nbsp; message/rfc822, 
      message/partial etc. that could be used to wrap a protected message (MIME 
      </FONT><BR><FONT size=2>&nbsp;&nbsp;&nbsp; content + RFC822 Headers). Also 
      as per MOM of the 54th IETF meeting it seems that </FONT><BR><FONT 
      size=2>&nbsp;&nbsp;&nbsp; message/rfc822 message type has been finalized 
      for this purpose.</FONT> <BR><BR><FONT size=2>&nbsp;&nbsp;&nbsp; My 
      question is how should one distinguish such a message ( A protected 
      message wrapped </FONT><BR><FONT size=2>&nbsp;&nbsp;&nbsp; in 
      message/rfc822) from a forwarded message which also has a message type of 
      </FONT><BR><FONT size=2>&nbsp;&nbsp;&nbsp; message/rfc822 and can also 
      contain a non protected message? Is an example message of </FONT><BR><FONT 
      size=2>&nbsp;&nbsp;&nbsp; type message/rfc822 containing a protected 
      message available for reference?</FONT> <BR><BR><FONT size=2>2. The latest 
      draft 'S/MIME Version 3.1 Message Specification' 
      (draft-ietf-smime-rfc2633bis-03.txt)</FONT> <BR><FONT 
      size=2>&nbsp;&nbsp;&nbsp; mentions a new S/MIME type "compressed-data". 
      However for this new S/MIME type no </FONT><BR><FONT 
      size=2>&nbsp;&nbsp;&nbsp; corresponding EIT has been defined in the S/MIME 
      TRANSPORT draft. Where would one be </FONT><BR><FONT 
      size=2>&nbsp;&nbsp;&nbsp; able to find the corresponding EIT for the 
      same?</FONT> <BR><BR><FONT size=2>Best Regards</FONT> <BR><FONT 
      size=2>Arun Pandey</FONT> 
<BR></BLOCKQUOTE></BLOCKQUOTE></BLOCKQUOTE></BODY></HTML>

--Boundary_(ID_ri35ulTa+sfqoza4zDzFIg)--

From: "Blake Ramsdell" <[email-masked]>
To: "'Bonatti, Chris'" <[email-masked]>, "'Pandey, Arun'" <[email-masked]>, "'Russ Housley'" <[email-masked]>
Cc: <[email-masked]>
Subject: RE: Queries on Message/rfc822, Compressed-Data.
Date: Wed, 2 Apr 2003 17:08:31 -0800
Importance: Normal
Sender: [email-masked]

This is a multi-part message in MIME format.

------=_NextPart_000_009E_01C2F93A.7CC8D0B0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit

Since RFC3274 isn't going to be updated anytime soon, I would recommend
that the EIT value be placed in the x400transport draft.
 
Blake

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On Behalf Of Bonatti, Chris
Sent: Wednesday, April 02, 2003 3:17 PM
To: 'Pandey, Arun'; 'Russ Housley'
Cc: [email-masked]
Subject: RE: Queries on Message/rfc822, Compressed-Data.

Yes, this probably makes sense.
 
I overlooked this because compressed-data was a draft when x400transport
was drafted.  Since compressed-data is not in 2633bis it would probably
make more sense to define the EIT for this in RFC 3274.  However, there
is also benefit to all the X.400 stuff being here.  I suppose I would
favor the latter.
 
Chris

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On Behalf Of Pandey, Arun
Sent: Tuesday, April 01, 2003 06:55
To: 'Russ Housley'
Cc: [email-masked]
Subject: RE: Queries on Message/rfc822, Compressed-Data.

Hi Russ,
 
As per draft-ietf-smime-x400transport-05.txt to convey information about
the contained content 
of an S/MIME message in an X.400 transport environment EITs are used. 
 
Section 2.5 (2.5.1 to 2.5.6) of draft-ietf-smime-x400transport-05.txt
define the EITs for:
1. Enveloped Data
2. Signed Data
3. Certificate Management
4. Signed Receipt
5. Enveloped X.400
6. Signed X.400
 
These match with the corresponding EITs defined in
http://www.imc.org/ietf-smime/sm-oid.asn
-- X.400 Encoded Information Types (EIT) for S/MIME objects
id-eit-envelopedData OBJECT IDENTIFIER ::= { id-eit 1 }
id-eit-signedData OBJECT IDENTIFIER ::= { id-eit 2 }
id-eit-certManagement OBJECT IDENTIFIER ::= { id-eit 3 }
id-eit-signedReceipt OBJECT IDENTIFIER ::= { id-eit 4 }
id-eit-envelopedx400 OBJECT IDENTIFIER ::= { id-eit 5 }
id-eit-signedx400 OBJECT IDENTIFIER ::= { id-eit 6 }
 
I am unable to find the corresponding EIT definition for the smime-type
parameter 
'compressed-data'(CompressedData), that has been newly introduced in the
'draft-ietf-smime-
rfc2633bis-03.txt'. 
 
Best Regards
Arun Pandey

-----Original Message-----
From: Russ Housley [mailto:[email-masked]]
Sent: Thursday, March 27, 2003 1:33 AM
To: Pandey, Arun
Cc: [email-masked]
Subject: Re: Queries on Message/rfc822, Compressed-Data.

These are both discussed in the most recent MSG draft.
Please see draft-ietf-smime-rfc2633bis-03.txt.

Russ

At 03:40 PM 3/26/2003 +0530, Pandey, Arun wrote:

Hi, 

I had the following 2 queries. Would appreciate a response on these if
possible: 

1. Going  through the S/MIME mail archive I find a discussion on the use
of message types like 
    message/rfc822, message/partial etc. that could be used to wrap a
protected message (MIME 
    content + RFC822 Headers). Also as per MOM of the 54th IETF meeting
it seems that 
    message/rfc822 message type has been finalized for this purpose. 

    My question is how should one distinguish such a message ( A
protected message wrapped 
    in message/rfc822) from a forwarded message which also has a message
type of 
    message/rfc822 and can also contain a non protected message? Is an
example message of 
    type message/rfc822 containing a protected message available for
reference? 

2. The latest draft 'S/MIME Version 3.1 Message Specification'
(draft-ietf-smime-rfc2633bis-03.txt) 
    mentions a new S/MIME type "compressed-data". However for this new
S/MIME type no 
    corresponding EIT has been defined in the S/MIME TRANSPORT draft.
Where would one be 
    able to find the corresponding EIT for the same? 

Best Regards 
Arun Pandey 

------=_NextPart_000_009E_01C2F93A.7CC8D0B0
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Dus-ascii">
<TITLE>Message</TITLE>

<META content=3D"MSHTML 6.00.2800.1141" name=3DGENERATOR></HEAD>
<BODY>
<DIV><SPAN class=3D041570201-03042003><FONT face=3DArial color=3D#0000ff =
size=3D2>Since=20
RFC3274 isn't going to be updated anytime soon, I would recommend that =
the EIT=20
value be placed in the x400transport draft.</FONT></SPAN></DIV>
<DIV><SPAN class=3D041570201-03042003><FONT face=3DArial color=3D#0000ff =

size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=3D041570201-03042003><FONT face=3DArial color=3D#0000ff =

size=3D2>Blake</FONT></SPAN></DIV>
<BLOCKQUOTE dir=3Dltr=20
style=3D"PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #0000ff 2px =
solid; MARGIN-RIGHT: 0px">
  <DIV></DIV>
  <DIV class=3DOutlookMessageHeader lang=3Den-us dir=3Dltr =
align=3Dleft><FONT=20
  face=3DTahoma size=3D2>-----Original Message-----<BR><B>From:</B>=20
  [email-masked] [mailto:[email-masked]] =
<B>On=20
  Behalf Of </B>Bonatti, Chris<BR><B>Sent:</B> Wednesday, April 02, 2003 =
3:17=20
  PM<BR><B>To:</B> 'Pandey, Arun'; 'Russ Housley'<BR><B>Cc:</B>=20
  [email-masked]<BR><B>Subject:</B> RE: Queries on Message/rfc822,=20
  Compressed-Data.<BR><BR></FONT></DIV>
  <DIV><SPAN class=3D815361123-02042003><FONT face=3DArial =
color=3D#0000ff size=3D2>Yes,=20
  this probably makes sense.</FONT></SPAN></DIV>
  <DIV><SPAN class=3D815361123-02042003><FONT face=3DArial =
color=3D#0000ff=20
  size=3D2></FONT></SPAN>&nbsp;</DIV>
  <DIV><SPAN class=3D815361123-02042003><FONT face=3DArial =
color=3D#0000ff size=3D2>I=20
  overlooked this because compressed-data was a draft when x400transport =
was=20
  drafted.&nbsp; Since compressed-data is not in 2633bis it would =
probably make=20
  more sense to define the EIT for this in RFC 3274.&nbsp; However, =
there is=20
  also benefit to all the X.400 stuff being here.&nbsp; I suppose I =
would favor=20
  the latter.</FONT></SPAN></DIV>
  <DIV><SPAN class=3D815361123-02042003><FONT face=3DArial =
color=3D#0000ff=20
  size=3D2></FONT></SPAN>&nbsp;</DIV>
  <DIV><SPAN class=3D815361123-02042003><FONT face=3DArial =
color=3D#0000ff=20
  size=3D2>Chris</FONT></SPAN></DIV>
  <DIV><SPAN class=3D815361123-02042003></SPAN>&nbsp;</DIV>
  <DIV><SPAN class=3D815361123-02042003><FONT face=3DArial =
color=3D#0000ff=20
  size=3D2></FONT></SPAN>&nbsp;</DIV>
  <DIV><SPAN class=3D815361123-02042003><FONT face=3DArial =
color=3D#0000ff=20
  size=3D2></FONT></SPAN>&nbsp;</DIV>
  <DIV></DIV>
  <DIV class=3DOutlookMessageHeader lang=3Den-us dir=3Dltr =
align=3Dleft><FONT=20
  face=3DTahoma size=3D2>-----Original Message-----<BR><B>From:</B>=20
  [email-masked] [mailto:[email-masked]] =
<B>On=20
  Behalf Of </B>Pandey, Arun<BR><B>Sent:</B> Tuesday, April 01, 2003=20
  06:55<BR><B>To:</B> 'Russ Housley'<BR><B>Cc:</B>=20
  [email-masked]<BR><B>Subject:</B> RE: Queries on Message/rfc822,=20
  Compressed-Data.<BR><BR></FONT></DIV>
  <DIV><FONT face=3DArial color=3D#0000ff size=3D2></FONT>&nbsp;</DIV>
  <DIV><FONT face=3DArial color=3D#0000ff size=3D2>Hi Russ,</FONT></DIV>
  <DIV><FONT face=3DArial color=3D#0000ff size=3D2></FONT>&nbsp;</DIV>
  <DIV><FONT size=3D2><FONT face=3DArial color=3D#0000ff>As per=20
  draft-ietf-smime-x400transport-05.txt to convey information =
</FONT><FONT=20
  face=3DArial color=3D#0000ff>about the contained content =
</FONT></FONT></DIV>
  <DIV><FONT size=3D2><FONT face=3DArial color=3D#0000ff>of an S/MIME =
message in an=20
  X.400 transport </FONT><FONT face=3DArial color=3D#0000ff>environment =
EITs are=20
  used. </FONT></FONT></DIV>
  <DIV>&nbsp;</DIV>
  <DIV><FONT face=3DArial color=3D#0000ff size=3D2>Section 2.5 (2.5.1 to =
2.5.6) of=20
  draft-ietf-smime-x400transport-05.txt define the EITs =
for:</FONT></DIV>
  <DIV><FONT face=3DArial color=3D#0000ff size=3D2>1. Enveloped =
Data</FONT></DIV>
  <DIV><FONT face=3DArial color=3D#0000ff size=3D2>2. Signed =
Data</FONT></DIV>
  <DIV><FONT face=3DArial color=3D#0000ff size=3D2>3. Certificate=20
  Management</FONT></DIV>
  <DIV><FONT face=3DArial color=3D#0000ff size=3D2>4. Signed =
Receipt</FONT></DIV>
  <DIV><FONT face=3DArial color=3D#0000ff size=3D2>5. Enveloped =
X.400</FONT></DIV>
  <DIV><FONT face=3DArial color=3D#0000ff size=3D2>6. Signed =
X.400</FONT></DIV>
  <DIV><FONT face=3DArial color=3D#0000ff></FONT>&nbsp;</DIV>
  <DIV><FONT face=3DArial color=3D#0000ff size=3D2>These match with the =
corresponding=20
  EITs defined in http://www.imc.org/ietf-smime/sm-oid.asn</FONT></DIV>
  <DIV><FONT face=3DArial color=3D#0000ff size=3D2>-- X.400 Encoded =
Information Types=20
  (EIT) for S/MIME objects</FONT></DIV>
  <DIV><FONT face=3DArial color=3D#0000ff size=3D2>id-eit-envelopedData =
OBJECT=20
  IDENTIFIER ::=3D { id-eit 1 }</FONT></DIV>
  <DIV><FONT face=3DArial color=3D#0000ff size=3D2>id-eit-signedData =
OBJECT IDENTIFIER=20
  ::=3D { id-eit 2 }</FONT></DIV>
  <DIV><FONT face=3DArial color=3D#0000ff size=3D2>id-eit-certManagement =
OBJECT=20
  IDENTIFIER ::=3D { id-eit 3 }</FONT></DIV>
  <DIV><FONT face=3DArial color=3D#0000ff size=3D2>id-eit-signedReceipt =
OBJECT=20
  IDENTIFIER ::=3D { id-eit 4 }</FONT></DIV>
  <DIV><FONT face=3DArial color=3D#0000ff size=3D2>id-eit-envelopedx400 =
OBJECT=20
  IDENTIFIER ::=3D { id-eit 5 }</FONT></DIV>
  <DIV><FONT face=3DArial color=3D#0000ff size=3D2>id-eit-signedx400 =
OBJECT IDENTIFIER=20
  ::=3D { id-eit 6 }</FONT></DIV>
  <DIV><FONT face=3DArial color=3D#0000ff></FONT>&nbsp;</DIV>
  <DIV><FONT face=3DArial color=3D#0000ff size=3D2>I am unable to =
find&nbsp;<SPAN=20
  class=3D747555611-01042003>the corresponding</SPAN> EIT definition for =
the=20
  smime-type parameter </FONT></DIV>
  <DIV><FONT face=3DArial color=3D#0000ff =
size=3D2>'compressed-data'(CompressedData),=20
  that has been newly introduced in the 'draft-ietf-smime-</FONT></DIV>
  <DIV><FONT size=3D2><FONT color=3D#0000ff><FONT=20
  face=3DArial>rfc2633bis-03.txt'.<SPAN class=3D747555611-01042003>=20
  </SPAN></FONT></FONT></FONT></DIV>
  <DIV><FONT face=3DArial color=3D#0000ff size=3D2></FONT>&nbsp;</DIV>
  <DIV><FONT face=3DArial color=3D#0000ff size=3D2>Best =
Regards</FONT></DIV>
  <DIV><FONT face=3DArial color=3D#0000ff size=3D2>Arun =
Pandey</FONT></DIV>
  <DIV><FONT face=3DArial color=3D#0000ff size=3D2></FONT>&nbsp;</DIV>
  <BLOCKQUOTE style=3D"MARGIN-RIGHT: 0px">
    <DIV class=3DOutlookMessageHeader dir=3Dltr align=3Dleft><FONT =
face=3DTahoma=20
    size=3D2>-----Original Message-----<BR><B>From:</B> Russ Housley=20
    [mailto:[email-masked]]<BR><B>Sent:</B> Thursday, March 27, =
2003 1:33=20
    AM<BR><B>To:</B> Pandey, Arun<BR><B>Cc:</B>=20
    [email-masked]<BR><B>Subject:</B> Re: Queries on Message/rfc822, =

    Compressed-Data.<BR><BR></DIV></FONT>These are both discussed in the =
most=20
    recent MSG draft.<BR>Please see=20
    draft-ietf-smime-rfc2633bis-03.txt.<BR><BR>Russ<BR><BR>At 03:40 PM =
3/26/2003=20
    +0530, Pandey, Arun wrote:<BR><BR>
    <BLOCKQUOTE class=3Dcite cite=3D"" type=3D"cite"><FONT =
size=3D2>Hi,</FONT>=20
      <BR><BR><FONT size=3D2>I had the following 2 queries. Would =
appreciate a=20
      response on these if possible:</FONT> <BR><BR><FONT size=3D2>1. =
Going&nbsp;=20
      through the S/MIME mail archive I find a discussion on the use of =
message=20
      types like </FONT><BR><FONT size=3D2>&nbsp;&nbsp;&nbsp; =
message/rfc822,=20
      message/partial etc. that could be used to wrap a protected =
message (MIME=20
      </FONT><BR><FONT size=3D2>&nbsp;&nbsp;&nbsp; content + RFC822 =
Headers). Also=20
      as per MOM of the 54th IETF meeting it seems that </FONT><BR><FONT =

      size=3D2>&nbsp;&nbsp;&nbsp; message/rfc822 message type has been =
finalized=20
      for this purpose.</FONT> <BR><BR><FONT size=3D2>&nbsp;&nbsp;&nbsp; =
My=20
      question is how should one distinguish such a message ( A =
protected=20
      message wrapped </FONT><BR><FONT size=3D2>&nbsp;&nbsp;&nbsp; in=20
      message/rfc822) from a forwarded message which also has a message =
type of=20
      </FONT><BR><FONT size=3D2>&nbsp;&nbsp;&nbsp; message/rfc822 and =
can also=20
      contain a non protected message? Is an example message of =
</FONT><BR><FONT=20
      size=3D2>&nbsp;&nbsp;&nbsp; type message/rfc822 containing a =
protected=20
      message available for reference?</FONT> <BR><BR><FONT size=3D2>2. =
The latest=20
      draft 'S/MIME Version 3.1 Message Specification'=20
      (draft-ietf-smime-rfc2633bis-03.txt)</FONT> <BR><FONT=20
      size=3D2>&nbsp;&nbsp;&nbsp; mentions a new S/MIME type =
"compressed-data".=20
      However for this new S/MIME type no </FONT><BR><FONT=20
      size=3D2>&nbsp;&nbsp;&nbsp; corresponding EIT has been defined in =
the S/MIME=20
      TRANSPORT draft. Where would one be </FONT><BR><FONT=20
      size=3D2>&nbsp;&nbsp;&nbsp; able to find the corresponding EIT for =
the=20
      same?</FONT> <BR><BR><FONT size=3D2>Best Regards</FONT> <BR><FONT=20
      size=3D2>Arun Pandey</FONT>=20
<BR></BLOCKQUOTE></BLOCKQUOTE></BLOCKQUOTE></BODY></HTML>

------=_NextPart_000_009E_01C2F93A.7CC8D0B0--

Date: Wed, 02 Apr 2003 18:17:11 -0500
From: "Bonatti, Chris" <[email-masked]>
Subject: RE: Queries on Message/rfc822, Compressed-Data.
To: "'Pandey, Arun'" <[email-masked]>, "'Russ Housley'" <[email-masked]>
Cc: [email-masked]
Organization: IECA, Inc.
Importance: Normal
Sender: [email-masked]

This is a multi-part message in MIME format.

--Boundary_(ID_IaiFkw0tCgVyiOUDv4m+2Q)
Content-type: text/plain; charset=us-ascii
Content-transfer-encoding: 7BIT

Yes, this probably makes sense.
 
I overlooked this because compressed-data was a draft when x400transport
was drafted.  Since compressed-data is not in 2633bis it would probably
make more sense to define the EIT for this in RFC 3274.  However, there
is also benefit to all the X.400 stuff being here.  I suppose I would
favor the latter.
 
Chris

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On Behalf Of Pandey, Arun
Sent: Tuesday, April 01, 2003 06:55
To: 'Russ Housley'
Cc: [email-masked]
Subject: RE: Queries on Message/rfc822, Compressed-Data.

Hi Russ,
 
As per draft-ietf-smime-x400transport-05.txt to convey information about
the contained content 
of an S/MIME message in an X.400 transport environment EITs are used. 
 
Section 2.5 (2.5.1 to 2.5.6) of draft-ietf-smime-x400transport-05.txt
define the EITs for:
1. Enveloped Data
2. Signed Data
3. Certificate Management
4. Signed Receipt
5. Enveloped X.400
6. Signed X.400
 
These match with the corresponding EITs defined in
http://www.imc.org/ietf-smime/sm-oid.asn
-- X.400 Encoded Information Types (EIT) for S/MIME objects
id-eit-envelopedData OBJECT IDENTIFIER ::= { id-eit 1 }
id-eit-signedData OBJECT IDENTIFIER ::= { id-eit 2 }
id-eit-certManagement OBJECT IDENTIFIER ::= { id-eit 3 }
id-eit-signedReceipt OBJECT IDENTIFIER ::= { id-eit 4 }
id-eit-envelopedx400 OBJECT IDENTIFIER ::= { id-eit 5 }
id-eit-signedx400 OBJECT IDENTIFIER ::= { id-eit 6 }
 
I am unable to find the corresponding EIT definition for the smime-type
parameter 
'compressed-data'(CompressedData), that has been newly introduced in the
'draft-ietf-smime-
rfc2633bis-03.txt'. 
 
Best Regards
Arun Pandey

-----Original Message-----
From: Russ Housley [mailto:[email-masked]]
Sent: Thursday, March 27, 2003 1:33 AM
To: Pandey, Arun
Cc: [email-masked]
Subject: Re: Queries on Message/rfc822, Compressed-Data.

These are both discussed in the most recent MSG draft.
Please see draft-ietf-smime-rfc2633bis-03.txt.

Russ

At 03:40 PM 3/26/2003 +0530, Pandey, Arun wrote:

Hi, 

I had the following 2 queries. Would appreciate a response on these if
possible: 

1. Going  through the S/MIME mail archive I find a discussion on the use
of message types like 
    message/rfc822, message/partial etc. that could be used to wrap a
protected message (MIME 
    content + RFC822 Headers). Also as per MOM of the 54th IETF meeting
it seems that 
    message/rfc822 message type has been finalized for this purpose. 

    My question is how should one distinguish such a message ( A
protected message wrapped 
    in message/rfc822) from a forwarded message which also has a message
type of 
    message/rfc822 and can also contain a non protected message? Is an
example message of 
    type message/rfc822 containing a protected message available for
reference? 

2. The latest draft 'S/MIME Version 3.1 Message Specification'
(draft-ietf-smime-rfc2633bis-03.txt) 
    mentions a new S/MIME type "compressed-data". However for this new
S/MIME type no 
    corresponding EIT has been defined in the S/MIME TRANSPORT draft.
Where would one be 
    able to find the corresponding EIT for the same? 

Best Regards 
Arun Pandey 

--Boundary_(ID_IaiFkw0tCgVyiOUDv4m+2Q)
Content-type: text/html; charset=us-ascii
Content-transfer-encoding: 7BIT

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=us-ascii">
<TITLE>Message</TITLE>

<META content="MSHTML 6.00.2800.1141" name=GENERATOR></HEAD>
<BODY>
<DIV><SPAN class=815361123-02042003><FONT face=Arial color=#0000ff size=2>Yes, 
this probably makes sense.</FONT></SPAN></DIV>
<DIV><SPAN class=815361123-02042003><FONT face=Arial color=#0000ff 
size=2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=815361123-02042003><FONT face=Arial color=#0000ff size=2>I 
overlooked this because compressed-data was a draft when x400transport was 
drafted.&nbsp; Since compressed-data is not in 2633bis it would probably make 
more sense to define the EIT for this in RFC 3274.&nbsp; However, there is also 
benefit to all the X.400 stuff being here.&nbsp; I suppose I would favor the 
latter.</FONT></SPAN></DIV>
<DIV><SPAN class=815361123-02042003><FONT face=Arial color=#0000ff 
size=2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=815361123-02042003><FONT face=Arial color=#0000ff 
size=2>Chris</FONT></SPAN></DIV>
<DIV><SPAN class=815361123-02042003></SPAN>&nbsp;</DIV>
<DIV><SPAN class=815361123-02042003><FONT face=Arial color=#0000ff 
size=2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=815361123-02042003><FONT face=Arial color=#0000ff 
size=2></FONT></SPAN>&nbsp;</DIV>
<DIV></DIV>
<DIV class=OutlookMessageHeader lang=en-us dir=ltr align=left><FONT face=Tahoma 
size=2>-----Original Message-----<BR><B>From:</B> [email-masked] 
[mailto:[email-masked]] <B>On Behalf Of </B>Pandey, 
Arun<BR><B>Sent:</B> Tuesday, April 01, 2003 06:55<BR><B>To:</B> 'Russ 
Housley'<BR><B>Cc:</B> [email-masked]<BR><B>Subject:</B> RE: Queries on 
Message/rfc822, Compressed-Data.<BR><BR></FONT></DIV>
<DIV><FONT face=Arial color=#0000ff size=2></FONT>&nbsp;</DIV>
<DIV><FONT face=Arial color=#0000ff size=2>Hi Russ,</FONT></DIV>
<DIV><FONT face=Arial color=#0000ff size=2></FONT>&nbsp;</DIV>
<DIV><FONT size=2><FONT face=Arial color=#0000ff>As per 
draft-ietf-smime-x400transport-05.txt to convey information </FONT><FONT 
face=Arial color=#0000ff>about the contained content </FONT></FONT></DIV>
<DIV><FONT size=2><FONT face=Arial color=#0000ff>of an S/MIME message in an 
X.400 transport </FONT><FONT face=Arial color=#0000ff>environment EITs are used. 
</FONT></FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=Arial color=#0000ff size=2>Section 2.5 (2.5.1 to 2.5.6) of 
draft-ietf-smime-x400transport-05.txt define the EITs for:</FONT></DIV>
<DIV><FONT face=Arial color=#0000ff size=2>1. Enveloped Data</FONT></DIV>
<DIV><FONT face=Arial color=#0000ff size=2>2. Signed Data</FONT></DIV>
<DIV><FONT face=Arial color=#0000ff size=2>3. Certificate 
Management</FONT></DIV>
<DIV><FONT face=Arial color=#0000ff size=2>4. Signed Receipt</FONT></DIV>
<DIV><FONT face=Arial color=#0000ff size=2>5. Enveloped X.400</FONT></DIV>
<DIV><FONT face=Arial color=#0000ff size=2>6. Signed X.400</FONT></DIV>
<DIV><FONT face=Arial color=#0000ff></FONT>&nbsp;</DIV>
<DIV><FONT face=Arial color=#0000ff size=2>These match with the corresponding 
EITs defined in http://www.imc.org/ietf-smime/sm-oid.asn</FONT></DIV>
<DIV><FONT face=Arial color=#0000ff size=2>-- X.400 Encoded Information Types 
(EIT) for S/MIME objects</FONT></DIV>
<DIV><FONT face=Arial color=#0000ff size=2>id-eit-envelopedData OBJECT 
IDENTIFIER ::= { id-eit 1 }</FONT></DIV>
<DIV><FONT face=Arial color=#0000ff size=2>id-eit-signedData OBJECT IDENTIFIER 
::= { id-eit 2 }</FONT></DIV>
<DIV><FONT face=Arial color=#0000ff size=2>id-eit-certManagement OBJECT 
IDENTIFIER ::= { id-eit 3 }</FONT></DIV>
<DIV><FONT face=Arial color=#0000ff size=2>id-eit-signedReceipt OBJECT 
IDENTIFIER ::= { id-eit 4 }</FONT></DIV>
<DIV><FONT face=Arial color=#0000ff size=2>id-eit-envelopedx400 OBJECT 
IDENTIFIER ::= { id-eit 5 }</FONT></DIV>
<DIV><FONT face=Arial color=#0000ff size=2>id-eit-signedx400 OBJECT IDENTIFIER 
::= { id-eit 6 }</FONT></DIV>
<DIV><FONT face=Arial color=#0000ff></FONT>&nbsp;</DIV>
<DIV><FONT face=Arial color=#0000ff size=2>I am unable to find&nbsp;<SPAN 
class=747555611-01042003>the corresponding</SPAN> EIT definition for the 
smime-type parameter </FONT></DIV>
<DIV><FONT face=Arial color=#0000ff size=2>'compressed-data'(CompressedData), 
that has been newly introduced in the 'draft-ietf-smime-</FONT></DIV>
<DIV><FONT size=2><FONT color=#0000ff><FONT face=Arial>rfc2633bis-03.txt'.<SPAN 
class=747555611-01042003> </SPAN></FONT></FONT></FONT></DIV>
<DIV><FONT face=Arial color=#0000ff size=2></FONT>&nbsp;</DIV>
<DIV><FONT face=Arial color=#0000ff size=2>Best Regards</FONT></DIV>
<DIV><FONT face=Arial color=#0000ff size=2>Arun Pandey</FONT></DIV>
<DIV>&nbsp;</DIV>
<BLOCKQUOTE style="MARGIN-RIGHT: 0px">
  <DIV class=OutlookMessageHeader dir=ltr align=left><FONT face=Tahoma 
  size=2>-----Original Message-----<BR><B>From:</B> Russ Housley 
  [mailto:[email-masked]]<BR><B>Sent:</B> Thursday, March 27, 2003 1:33 
  AM<BR><B>To:</B> Pandey, Arun<BR><B>Cc:</B> 
  [email-masked]<BR><B>Subject:</B> Re: Queries on Message/rfc822, 
  Compressed-Data.<BR><BR></DIV></FONT>These are both discussed in the most 
  recent MSG draft.<BR>Please see 
  draft-ietf-smime-rfc2633bis-03.txt.<BR><BR>Russ<BR><BR>At 03:40 PM 3/26/2003 
  +0530, Pandey, Arun wrote:<BR><BR>
  <BLOCKQUOTE class=cite cite="" type="cite"><FONT size=2>Hi,</FONT> 
    <BR><BR><FONT size=2>I had the following 2 queries. Would appreciate a 
    response on these if possible:</FONT> <BR><BR><FONT size=2>1. Going&nbsp; 
    through the S/MIME mail archive I find a discussion on the use of message 
    types like </FONT><BR><FONT size=2>&nbsp;&nbsp;&nbsp; message/rfc822, 
    message/partial etc. that could be used to wrap a protected message (MIME 
    </FONT><BR><FONT size=2>&nbsp;&nbsp;&nbsp; content + RFC822 Headers). Also 
    as per MOM of the 54th IETF meeting it seems that </FONT><BR><FONT 
    size=2>&nbsp;&nbsp;&nbsp; message/rfc822 message type has been finalized for 
    this purpose.</FONT> <BR><BR><FONT size=2>&nbsp;&nbsp;&nbsp; My question is 
    how should one distinguish such a message ( A protected message wrapped 
    </FONT><BR><FONT size=2>&nbsp;&nbsp;&nbsp; in message/rfc822) from a 
    forwarded message which also has a message type of </FONT><BR><FONT 
    size=2>&nbsp;&nbsp;&nbsp; message/rfc822 and can also contain a non 
    protected message? Is an example message of </FONT><BR><FONT 
    size=2>&nbsp;&nbsp;&nbsp; type message/rfc822 containing a protected message 
    available for reference?</FONT> <BR><BR><FONT size=2>2. The latest draft 
    'S/MIME Version 3.1 Message Specification' 
    (draft-ietf-smime-rfc2633bis-03.txt)</FONT> <BR><FONT 
    size=2>&nbsp;&nbsp;&nbsp; mentions a new S/MIME type "compressed-data". 
    However for this new S/MIME type no </FONT><BR><FONT 
    size=2>&nbsp;&nbsp;&nbsp; corresponding EIT has been defined in the S/MIME 
    TRANSPORT draft. Where would one be </FONT><BR><FONT 
    size=2>&nbsp;&nbsp;&nbsp; able to find the corresponding EIT for the 
    same?</FONT> <BR><BR><FONT size=2>Best Regards</FONT> <BR><FONT size=2>Arun 
    Pandey</FONT> <BR></BLOCKQUOTE></BLOCKQUOTE></BODY></HTML>

--Boundary_(ID_IaiFkw0tCgVyiOUDv4m+2Q)--

From: "Pandey, Arun" <[email-masked]>
To: "'Russ Housley'" <[email-masked]>
Cc: [email-masked]
Subject: RE: Queries on Message/rfc822, Compressed-Data.
Date: Tue, 1 Apr 2003 17:25:13 +0530 
Sender: [email-masked]

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C2F845.90D9976A
Content-Type: text/plain;
	charset="iso-8859-1"

Hi Russ,
 
As per draft-ietf-smime-x400transport-05.txt to convey information about the
contained content 
of an S/MIME message in an X.400 transport environment EITs are used. 
 
Section 2.5 (2.5.1 to 2.5.6) of draft-ietf-smime-x400transport-05.txt define
the EITs for:
1. Enveloped Data
2. Signed Data
3. Certificate Management
4. Signed Receipt
5. Enveloped X.400
6. Signed X.400
 
These match with the corresponding EITs defined in
http://www.imc.org/ietf-smime/sm-oid.asn
-- X.400 Encoded Information Types (EIT) for S/MIME objects
id-eit-envelopedData OBJECT IDENTIFIER ::= { id-eit 1 }
id-eit-signedData OBJECT IDENTIFIER ::= { id-eit 2 }
id-eit-certManagement OBJECT IDENTIFIER ::= { id-eit 3 }
id-eit-signedReceipt OBJECT IDENTIFIER ::= { id-eit 4 }
id-eit-envelopedx400 OBJECT IDENTIFIER ::= { id-eit 5 }
id-eit-signedx400 OBJECT IDENTIFIER ::= { id-eit 6 }
 
I am unable to find the corresponding EIT definition for the smime-type
parameter 
'compressed-data'(CompressedData), that has been newly introduced in the
'draft-ietf-smime-
rfc2633bis-03.txt'. 
 
Best Regards
Arun Pandey

-----Original Message-----
From: Russ Housley [mailto:[email-masked]]
Sent: Thursday, March 27, 2003 1:33 AM
To: Pandey, Arun
Cc: [email-masked]
Subject: Re: Queries on Message/rfc822, Compressed-Data.

These are both discussed in the most recent MSG draft.
Please see draft-ietf-smime-rfc2633bis-03.txt.

Russ

At 03:40 PM 3/26/2003 +0530, Pandey, Arun wrote:

Hi, 

I had the following 2 queries. Would appreciate a response on these if
possible: 

1. Going  through the S/MIME mail archive I find a discussion on the use of
message types like 
    message/rfc822, message/partial etc. that could be used to wrap a
protected message (MIME 
    content + RFC822 Headers). Also as per MOM of the 54th IETF meeting it
seems that 
    message/rfc822 message type has been finalized for this purpose. 

    My question is how should one distinguish such a message ( A protected
message wrapped 
    in message/rfc822) from a forwarded message which also has a message
type of 
    message/rfc822 and can also contain a non protected message? Is an
example message of 
    type message/rfc822 containing a protected message available for
reference? 

2. The latest draft 'S/MIME Version 3.1 Message Specification'
(draft-ietf-smime-rfc2633bis-03.txt) 
    mentions a new S/MIME type "compressed-data". However for this new
S/MIME type no 
    corresponding EIT has been defined in the S/MIME TRANSPORT draft. Where
would one be 
    able to find the corresponding EIT for the same? 

Best Regards 
Arun Pandey 

------_=_NextPart_001_01C2F845.90D9976A
Content-Type: text/html;
	charset="iso-8859-1"

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">

<META content="MSHTML 5.00.2314.1000" name=GENERATOR></HEAD>
<BODY>
<DIV>&nbsp;</DIV>
<DIV><FONT color=#0000ff face=Arial size=2>Hi Russ,</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT size=2><FONT color=#0000ff face=Arial>As per 
draft-ietf-smime-x400transport-05.txt to convey information </FONT><FONT 
color=#0000ff face=Arial>about the contained content </FONT></FONT></DIV>
<DIV><FONT size=2><FONT color=#0000ff face=Arial>of an S/MIME message in an 
X.400 transport </FONT><FONT color=#0000ff face=Arial>environment EITs are used. 
</FONT></FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT color=#0000ff face=Arial size=2>Section 2.5 (2.5.1 to 2.5.6) of 
draft-ietf-smime-x400transport-05.txt define the EITs for:</FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2>1. Enveloped Data</FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2>2. Signed Data</FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2>3. Certificate 
Management</FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2>4. Signed Receipt</FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2>5. Enveloped X.400</FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2>6. Signed X.400</FONT></DIV>
<DIV><FONT color=#0000ff face=Arial></FONT>&nbsp;</DIV>
<DIV><FONT color=#0000ff face=Arial size=2>These match with the corresponding 
EITs defined in http://www.imc.org/ietf-smime/sm-oid.asn</FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2>-- X.400 Encoded Information Types 
(EIT) for S/MIME objects</FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2>id-eit-envelopedData OBJECT 
IDENTIFIER ::= { id-eit 1 }</FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2>id-eit-signedData OBJECT IDENTIFIER 
::= { id-eit 2 }</FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2>id-eit-certManagement OBJECT 
IDENTIFIER ::= { id-eit 3 }</FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2>id-eit-signedReceipt OBJECT 
IDENTIFIER ::= { id-eit 4 }</FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2>id-eit-envelopedx400 OBJECT 
IDENTIFIER ::= { id-eit 5 }</FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2>id-eit-signedx400 OBJECT IDENTIFIER 
::= { id-eit 6 }</FONT></DIV>
<DIV><FONT color=#0000ff face=Arial></FONT>&nbsp;</DIV>
<DIV><FONT color=#0000ff face=Arial size=2>I am unable to find&nbsp;<SPAN 
class=747555611-01042003>the corresponding</SPAN> EIT definition for the 
smime-type parameter </FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2>'compressed-data'(CompressedData), 
that has been newly introduced in the 'draft-ietf-smime-</FONT></DIV>
<DIV><FONT size=2><FONT color=#0000ff><FONT face=Arial>rfc2633bis-03.txt'.<SPAN 
class=747555611-01042003> </SPAN></FONT></FONT></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2></FONT>&nbsp;</DIV>
<DIV><FONT color=#0000ff face=Arial size=2>Best Regards</FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2>Arun Pandey</FONT></DIV>
<DIV>&nbsp;</DIV>
<BLOCKQUOTE style="MARGIN-RIGHT: 0px">
  <DIV align=left class=OutlookMessageHeader dir=ltr><FONT face=Tahoma 
  size=2>-----Original Message-----<BR><B>From:</B> Russ Housley 
  [mailto:[email-masked]]<BR><B>Sent:</B> Thursday, March 27, 2003 1:33 
  AM<BR><B>To:</B> Pandey, Arun<BR><B>Cc:</B> 
  [email-masked]<BR><B>Subject:</B> Re: Queries on Message/rfc822, 
  Compressed-Data.<BR><BR></DIV></FONT>These are both discussed in the most 
  recent MSG draft.<BR>Please see 
  draft-ietf-smime-rfc2633bis-03.txt.<BR><BR>Russ<BR><BR>At 03:40 PM 3/26/2003 
  +0530, Pandey, Arun wrote:<BR><BR>
  <BLOCKQUOTE class=cite cite type="cite"><FONT size=2>Hi,</FONT> 
    <BR><BR><FONT size=2>I had the following 2 queries. Would appreciate a 
    response on these if possible:</FONT> <BR><BR><FONT size=2>1. Going&nbsp; 
    through the S/MIME mail archive I find a discussion on the use of message 
    types like </FONT><BR><FONT size=2>&nbsp;&nbsp;&nbsp; message/rfc822, 
    message/partial etc. that could be used to wrap a protected message (MIME 
    </FONT><BR><FONT size=2>&nbsp;&nbsp;&nbsp; content + RFC822 Headers). Also 
    as per MOM of the 54th IETF meeting it seems that </FONT><BR><FONT 
    size=2>&nbsp;&nbsp;&nbsp; message/rfc822 message type has been finalized for 
    this purpose.</FONT> <BR><BR><FONT size=2>&nbsp;&nbsp;&nbsp; My question is 
    how should one distinguish such a message ( A protected message wrapped 
    </FONT><BR><FONT size=2>&nbsp;&nbsp;&nbsp; in message/rfc822) from a 
    forwarded message which also has a message type of </FONT><BR><FONT 
    size=2>&nbsp;&nbsp;&nbsp; message/rfc822 and can also contain a non 
    protected message? Is an example message of </FONT><BR><FONT 
    size=2>&nbsp;&nbsp;&nbsp; type message/rfc822 containing a protected message 
    available for reference?</FONT> <BR><BR><FONT size=2>2. The latest draft 
    'S/MIME Version 3.1 Message Specification' 
    (draft-ietf-smime-rfc2633bis-03.txt)</FONT> <BR><FONT 
    size=2>&nbsp;&nbsp;&nbsp; mentions a new S/MIME type "compressed-data". 
    However for this new S/MIME type no </FONT><BR><FONT 
    size=2>&nbsp;&nbsp;&nbsp; corresponding EIT has been defined in the S/MIME 
    TRANSPORT draft. Where would one be </FONT><BR><FONT 
    size=2>&nbsp;&nbsp;&nbsp; able to find the corresponding EIT for the 
    same?</FONT> <BR><BR><FONT size=2>Best Regards</FONT> <BR><FONT size=2>Arun 
    Pandey</FONT> <BR></BLOCKQUOTE></BLOCKQUOTE></BODY></HTML>

------_=_NextPart_001_01C2F845.90D9976A--