From owner-ietf-smime@mail.imc.org Tue Apr 1 07:50:49 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA08253 for ; Tue, 1 Apr 2003 07:50:48 -0500 (EST) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h31C0XJM016523 for ; Tue, 1 Apr 2003 04:00:33 -0800 (PST) Received: (from majordomo@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h31C0XRw016522 for ietf-smime-bks; Tue, 1 Apr 2003 04:00:33 -0800 (PST) X-Authentication-Warning: above.proper.com: majordomo set sender to owner-ietf-smime@mail.imc.org using -f Received: from zcamail05.zca.compaq.com (zcamail05.zca.compaq.com [161.114.32.105]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h31C0WJM016516 for ; Tue, 1 Apr 2003 04:00:33 -0800 (PST) Received: from taynzmail03.nz-tay.cpqcorp.net (taynzmail03.nz-tay.cpqcorp.net [16.47.4.103]) by zcamail05.zca.compaq.com (Postfix) with ESMTP id 3E77230F1; Tue, 1 Apr 2003 04:00:24 -0800 (PST) Received: from diexch01.xko.dec.com (diexch01.xko.dec.com [16.138.244.57]) by taynzmail03.nz-tay.cpqcorp.net (Postfix) with ESMTP id 73BE1EEF; Tue, 1 Apr 2003 07:00:21 -0500 (EST) Received: by diexch01.xko.dec.com with Internet Mail Service (5.5.2650.21) id <2A3P1GAZ>; Tue, 1 Apr 2003 17:25:19 +0530 Message-ID: <177E503C4DA3D311BC9D0008C791C3060A0D258F@diexch01.xko.dec.com> From: "Pandey, Arun" To: "'Russ Housley'" Cc: ietf-smime@imc.org Subject: RE: Queries on Message/rfc822, Compressed-Data. Date: Tue, 1 Apr 2003 17:25:13 +0530 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C2F845.90D9976A" Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: 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:housley@vigilsec.com] Sent: Thursday, March 27, 2003 1:33 AM To: Pandey, Arun Cc: ietf-smime@imc.org 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"
 
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:housley@vigilsec.com]
Sent: Thursday, March 27, 2003 1:33 AM
To: Pandey, Arun
Cc: ietf-smime@imc.org
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-- From owner-ietf-smime@mail.imc.org Wed Apr 2 18:51:40 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA16772 for ; Wed, 2 Apr 2003 18:51:39 -0500 (EST) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h32NJ4JM009599 for ; Wed, 2 Apr 2003 15:19:04 -0800 (PST) Received: (from majordomo@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h32NJ4Bv009598 for ietf-smime-bks; Wed, 2 Apr 2003 15:19:04 -0800 (PST) X-Authentication-Warning: above.proper.com: majordomo set sender to owner-ietf-smime@mail.imc.org using -f Received: from smtp-out.comcast.net (smtp-out.comcast.net [24.153.64.115]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h32NIxJM009594 for ; Wed, 2 Apr 2003 15:18:59 -0800 (PST) Received: from Obsidian (pcp833859pcs.nrockv01.md.comcast.net [68.50.112.48]) by mtaout09.icomcast.net (iPlanet Messaging Server 5.2 HotFix 1.14 (built Mar 18 2003)) with ESMTP id <0HCQ001FKOON13@mtaout09.icomcast.net> for ietf-smime@imc.org; Wed, 02 Apr 2003 18:17:12 -0500 (EST) Date: Wed, 02 Apr 2003 18:17:11 -0500 From: "Bonatti, Chris" Subject: RE: Queries on Message/rfc822, Compressed-Data. In-reply-to: <177E503C4DA3D311BC9D0008C791C3060A0D258F@diexch01.xko.dec.com> To: "'Pandey, Arun'" , "'Russ Housley'" Cc: ietf-smime@imc.org Message-id: <002201c2f96d$fdaab5d0$0300a8c0@ieca.com> Organization: IECA, Inc. MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Mailer: Microsoft Outlook, Build 10.0.2627 Content-type: multipart/alternative; boundary="Boundary_(ID_IaiFkw0tCgVyiOUDv4m+2Q)" Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: 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: owner-ietf-smime@mail.imc.org [mailto:owner-ietf-smime@mail.imc.org] On Behalf Of Pandey, Arun Sent: Tuesday, April 01, 2003 06:55 To: 'Russ Housley' Cc: ietf-smime@imc.org 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:housley@vigilsec.com] Sent: Thursday, March 27, 2003 1:33 AM To: Pandey, Arun Cc: ietf-smime@imc.org 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 Message
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: owner-ietf-smime@mail.imc.org [mailto:owner-ietf-smime@mail.imc.org] On Behalf Of Pandey, Arun
Sent: Tuesday, April 01, 2003 06:55
To: 'Russ Housley'
Cc: ietf-smime@imc.org
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:housley@vigilsec.com]
Sent: Thursday, March 27, 2003 1:33 AM
To: Pandey, Arun
Cc: ietf-smime@imc.org
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)-- From owner-ietf-smime@mail.imc.org Wed Apr 2 20:45:58 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA20787 for ; Wed, 2 Apr 2003 20:45:57 -0500 (EST) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h3318ZJM015276 for ; Wed, 2 Apr 2003 17:08:35 -0800 (PST) Received: (from majordomo@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h3318Zhw015275 for ietf-smime-bks; Wed, 2 Apr 2003 17:08:35 -0800 (PST) X-Authentication-Warning: above.proper.com: majordomo set sender to owner-ietf-smime@mail.imc.org using -f Received: from brutesquadlabs.com (gtec136-m.isomedia.com [207.115.67.136] (may be forged)) by above.proper.com (8.12.9/8.11.6) with ESMTP id h3318YJM015270 for ; Wed, 2 Apr 2003 17:08:34 -0800 (PST) Received: from DEXTER ([192.168.0.4]) by brutesquadlabs.com with ESMTP ; Wed, 2 Apr 2003 17:08:31 -0800 From: "Blake Ramsdell" To: "'Bonatti, Chris'" , "'Pandey, Arun'" , "'Russ Housley'" Cc: Subject: RE: Queries on Message/rfc822, Compressed-Data. Date: Wed, 2 Apr 2003 17:08:31 -0800 Message-ID: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_009E_01C2F93A.7CC8D0B0" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2627 In-Reply-To: <002201c2f96d$fdaab5d0$0300a8c0@ieca.com> X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Importance: Normal Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: 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: owner-ietf-smime@mail.imc.org [mailto:owner-ietf-smime@mail.imc.org] On Behalf Of Bonatti, Chris Sent: Wednesday, April 02, 2003 3:17 PM To: 'Pandey, Arun'; 'Russ Housley' Cc: ietf-smime@imc.org 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: owner-ietf-smime@mail.imc.org [mailto:owner-ietf-smime@mail.imc.org] On Behalf Of Pandey, Arun Sent: Tuesday, April 01, 2003 06:55 To: 'Russ Housley' Cc: ietf-smime@imc.org 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:housley@vigilsec.com] Sent: Thursday, March 27, 2003 1:33 AM To: Pandey, Arun Cc: ietf-smime@imc.org 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 Message
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.
 
Blake
-----Original Message-----
From:=20 owner-ietf-smime@mail.imc.org [mailto:owner-ietf-smime@mail.imc.org] = On=20 Behalf Of Bonatti, Chris
Sent: Wednesday, April 02, 2003 = 3:17=20 PM
To: 'Pandey, Arun'; 'Russ Housley'
Cc:=20 ietf-smime@imc.org
Subject: RE: Queries on Message/rfc822,=20 Compressed-Data.

Yes,=20 this probably makes sense.
 
I=20 overlooked this because compressed-data was a draft when x400transport = was=20 drafted.  Since compressed-data is not in 2633bis it would = probably make=20 more sense to define the EIT for this in RFC 3274.  However, = there is=20 also benefit to all the X.400 stuff being here.  I suppose I = would favor=20 the latter.
 
Chris
 
 
 
-----Original Message-----
From:=20 owner-ietf-smime@mail.imc.org [mailto:owner-ietf-smime@mail.imc.org] = On=20 Behalf Of Pandey, Arun
Sent: Tuesday, April 01, 2003=20 06:55
To: 'Russ Housley'
Cc:=20 ietf-smime@imc.org
Subject: RE: Queries on Message/rfc822,=20 Compressed-Data.

 
Hi Russ,
 
As per=20 draft-ietf-smime-x400transport-05.txt to convey information = about the contained content =
of an S/MIME = message in an=20 X.400 transport environment = EITs are=20 used.
 
Section 2.5 (2.5.1 to = 2.5.6) of=20 draft-ietf-smime-x400transport-05.txt define the EITs = for:
1. Enveloped = Data
2. Signed = Data
3. Certificate=20 Management
4. Signed = Receipt
5. Enveloped = X.400
6. Signed = X.400
 
These match with the = corresponding=20 EITs defined in http://www.imc.org/ietf-smime/sm-oid.asn
-- X.400 Encoded = Information Types=20 (EIT) for S/MIME objects
id-eit-envelopedData = OBJECT=20 IDENTIFIER ::=3D { id-eit 1 }
id-eit-signedData = OBJECT IDENTIFIER=20 ::=3D { id-eit 2 }
id-eit-certManagement = OBJECT=20 IDENTIFIER ::=3D { id-eit 3 }
id-eit-signedReceipt = OBJECT=20 IDENTIFIER ::=3D { id-eit 4 }
id-eit-envelopedx400 = OBJECT=20 IDENTIFIER ::=3D { id-eit 5 }
id-eit-signedx400 = OBJECT IDENTIFIER=20 ::=3D { id-eit 6 }
 
I am unable to = find the corresponding EIT definition for = the=20 smime-type parameter
'compressed-data'(CompressedData),=20 that has been newly introduced in the 'draft-ietf-smime-
rfc2633bis-03.txt'.=20
 
Best = Regards
Arun = Pandey
 
-----Original Message-----
From: Russ Housley=20 [mailto:housley@vigilsec.com]
Sent: Thursday, March 27, = 2003 1:33=20 AM
To: Pandey, Arun
Cc:=20 ietf-smime@imc.org
Subject: Re: Queries on Message/rfc822, = Compressed-Data.

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

Russ

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

Hi,=20

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

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

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

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

Best Regards
Arun Pandey=20
------=_NextPart_000_009E_01C2F93A.7CC8D0B0-- From owner-ietf-smime@mail.imc.org Thu Apr 3 00:19:01 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA24753 for ; Thu, 3 Apr 2003 00:18:59 -0500 (EST) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h334ekJM024003 for ; Wed, 2 Apr 2003 20:40:46 -0800 (PST) Received: (from majordomo@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h334ekX7024002 for ietf-smime-bks; Wed, 2 Apr 2003 20:40:46 -0800 (PST) X-Authentication-Warning: above.proper.com: majordomo set sender to owner-ietf-smime@mail.imc.org using -f Received: from smtp-out.comcast.net (smtp-out.comcast.net [24.153.64.110]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h334eiJM023997 for ; Wed, 2 Apr 2003 20:40:45 -0800 (PST) Received: from Obsidian (pcp833859pcs.nrockv01.md.comcast.net [68.50.112.48]) by mtaout10.icomcast.net (iPlanet Messaging Server 5.2 HotFix 1.14 (built Mar 18 2003)) with ESMTP id <0HCR006SH3N018@mtaout10.icomcast.net> for ietf-smime@imc.org; Wed, 02 Apr 2003 23:40:13 -0500 (EST) Date: Wed, 02 Apr 2003 23:40:11 -0500 From: "Bonatti, Chris" Subject: RE: Queries on Message/rfc822, Compressed-Data. In-reply-to: To: "'Blake Ramsdell'" , "'Pandey, Arun'" , "'Russ Housley'" Cc: ietf-smime@imc.org Message-id: <002301c2f99b$1d855680$0300a8c0@ieca.com> Organization: IECA, Inc. MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Mailer: Microsoft Outlook, Build 10.0.2627 Content-type: multipart/alternative; boundary="Boundary_(ID_ri35ulTa+sfqoza4zDzFIg)" Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: 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:blake@brutesquadlabs.com] Sent: Wednesday, April 02, 2003 20:09 To: 'Bonatti, Chris'; 'Pandey, Arun'; 'Russ Housley' Cc: ietf-smime@imc.org 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: owner-ietf-smime@mail.imc.org [mailto:owner-ietf-smime@mail.imc.org] On Behalf Of Bonatti, Chris Sent: Wednesday, April 02, 2003 3:17 PM To: 'Pandey, Arun'; 'Russ Housley' Cc: ietf-smime@imc.org 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: owner-ietf-smime@mail.imc.org [mailto:owner-ietf-smime@mail.imc.org] On Behalf Of Pandey, Arun Sent: Tuesday, April 01, 2003 06:55 To: 'Russ Housley' Cc: ietf-smime@imc.org 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:housley@vigilsec.com] Sent: Thursday, March 27, 2003 1:33 AM To: Pandey, Arun Cc: ietf-smime@imc.org 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 Message
I'll update the draft to assign the next available value.
 
Chris
 
 
-----Original Message-----
From: Blake Ramsdell [mailto:blake@brutesquadlabs.com]
Sent: Wednesday, April 02, 2003 20:09
To: 'Bonatti, Chris'; 'Pandey, Arun'; 'Russ Housley'
Cc: ietf-smime@imc.org
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: owner-ietf-smime@mail.imc.org [mailto:owner-ietf-smime@mail.imc.org] On Behalf Of Bonatti, Chris
Sent: Wednesday, April 02, 2003 3:17 PM
To: 'Pandey, Arun'; 'Russ Housley'
Cc: ietf-smime@imc.org
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: owner-ietf-smime@mail.imc.org [mailto:owner-ietf-smime@mail.imc.org] On Behalf Of Pandey, Arun
Sent: Tuesday, April 01, 2003 06:55
To: 'Russ Housley'
Cc: ietf-smime@imc.org
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:housley@vigilsec.com]
Sent: Thursday, March 27, 2003 1:33 AM
To: Pandey, Arun
Cc: ietf-smime@imc.org
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)-- From owner-ietf-smime@mail.imc.org Thu Apr 3 15:32:42 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA12506 for ; Thu, 3 Apr 2003 15:32:41 -0500 (EST) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h33JxcJM007719 for ; Thu, 3 Apr 2003 11:59:38 -0800 (PST) Received: (from majordomo@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h33Jxctd007718 for ietf-smime-bks; Thu, 3 Apr 2003 11:59:38 -0800 (PST) X-Authentication-Warning: above.proper.com: majordomo set sender to owner-ietf-smime@mail.imc.org using -f Received: from woodstock.binhost.com (woodstock.binhost.com [207.228.252.5]) by above.proper.com (8.12.9/8.11.6) with SMTP id h33JxbJM007713 for ; Thu, 3 Apr 2003 11:59:37 -0800 (PST) Received: (qmail 8440 invoked by uid 0); 3 Apr 2003 19:59:08 -0000 Received: from unknown (HELO Russ-Laptop.vigilsec.com) (141.156.221.133) by woodstock.binhost.com with SMTP; 3 Apr 2003 19:59:08 -0000 Message-Id: <5.2.0.9.2.20030403145914.02b6b890@mail.binhost.com> X-Sender: housley@mail.binhost.com X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Thu, 03 Apr 2003 14:59:30 -0500 To: "Bonatti, Chris" , "'Blake Ramsdell'" , "'Pandey, Arun'" From: Russ Housley Subject: RE: Queries on Message/rfc822, Compressed-Data. Cc: ietf-smime@imc.org In-Reply-To: <002301c2f99b$1d855680$0300a8c0@ieca.com> References: < Mime-Version: 1.0 Content-Type: text/html; charset="us-ascii" Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Chris:

I assigned:

  id-eit-compressedData      OBJECT IDENTIFIER ::= { id-eit 7 }

Russ


At 11:40 PM 4/2/2003 -0500, Bonatti, Chris wrote:
I'll update the draft to assign the next available value.
 
Chris
 
 
-----Original Message-----
From: Blake Ramsdell [mailto:blake@brutesquadlabs.com]
Sent: Wednesday, April 02, 2003 20:09
To: 'Bonatti, Chris'; 'Pandey, Arun'; 'Russ Housley'
Cc: ietf-smime@imc.org
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: owner-ietf-smime@mail.imc.org [mailto:owner-ietf-smime@mail.imc.org] On Behalf Of Bonatti, Chris
Sent: Wednesday, April 02, 2003 3:17 PM
To: 'Pandey, Arun'; 'Russ Housley'
Cc: ietf-smime@imc.org
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: owner-ietf-smime@mail.imc.org [mailto:owner-ietf-smime@mail.imc.org] On Behalf Of Pandey, Arun
Sent: Tuesday, April 01, 2003 06:55
To: 'Russ Housley'
Cc: ietf-smime@imc.org
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:housley@vigilsec.com]
Sent: Thursday, March 27, 2003 1:33 AM
To: Pandey, Arun
Cc: ietf-smime@imc.org
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
From o8azpj5q5@aol.com Fri Apr 4 06:43:11 2003 Received: from 200-206-143-51.speedyterra.com.br (200-206-143-51.speedyterra.com.br [200.206.143.51] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA15122; Fri, 4 Apr 2003 06:43:06 -0500 (EST) Received: from tcb.jzub9.org ([87.40.181.14]) by 200-206-143-51.speedyterra.com.br with ESMTP id EAC544D59B2 for ; Fri, 04 Apr 2003 17:46:05 +0600 Message-ID: <69$fu-b--4$0mh-c-478ta90@6z5.n.1.w4> From: "Willa Cruz" To: sip-admin@ietf.org Subject: cort vdentification Date: Fri, 04 Apr 03 17:46:05 GMT X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2720.3000 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="C_E_7E5_7FF_3144EBA.E" This is a multi-part message in MIME format. --C_E_7E5_7FF_3144EBA.E Content-Type: text/html Content-Transfer-Encoding: quoted-printable

Hello mate whats been up?

--C_E_7E5_7FF_3144EBA.E-- From subs-reminder@imc.org Mon Apr 7 16:26:07 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA04984 for ; Mon, 7 Apr 2003 16:26:06 -0400 (EDT) From: subs-reminder@imc.org Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h37KSaJM002518 for ; Mon, 7 Apr 2003 13:28:36 -0700 (PDT) Received: (from root@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h37KSaBF002517; Mon, 7 Apr 2003 13:28:36 -0700 (PDT) Date: Mon, 7 Apr 2003 13:28:36 -0700 (PDT) Message-Id: <200304072028.h37KSaBF002517@above.proper.com> To: smime-archive@ietf.org Subject: [[352719299]] Subscription to ietf-smime for smime-archive@lists.ietf.org Greetings. This message is a periodic reminder that smime-archive@lists.ietf.org is subscribed to the ietf-smime mailing list. *** SEE BELOW: PLEASE DO NOT RESPOND TO THIS MESSAGE. *** There are two purposes for this message: - If this message is bounced by your mail server, I can remove you from the mailing list and reduce waste of bandwidth and resources. (If you are reading this message, it clearly didn't get bounced!) - Some people stay subscribed to mailing lists even though they do not want to because they do not know how to unsubscribe. If you want to stay subscribed to the ietf-smime mailing list, you do not need to do anything. Feel free to delete this message. On the other hand, if you want to unsubscribe from this list, simply go to the following link: If for some reason you cannot go to that web site, you can also unsubscribe by email; however, doing so is not as likely to get you unsubscribed as the web site is. To unsubscribe using email, you can respond to this message and I will unsubscribe you by hand in the next few days. Again, this is not assured to work because your mail system may make it impossible for me to determine who you are or what you want to unsubscribe to. Alternatively, you can send a plain-text message to: ietf-smime-request@imc.org with the single word unsubscribe in the body of the message. This last method assumes that the "From:" address in your mail is "smime-archive@lists.ietf.org". Again, using the web site above is more likely to work than this method (due to limitations in Majordomo, the mailing list software we currently use). If you have any questions, feel free to contact me. --Paul Hoffman, list administrator From owner-ietf-smime@mail.imc.org Mon Apr 7 17:32:20 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA06663 for ; Mon, 7 Apr 2003 17:32:19 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h37L6RJM010364 for ; Mon, 7 Apr 2003 14:06:27 -0700 (PDT) Received: (from majordomo@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h37L6RTC010363 for ietf-smime-bks; Mon, 7 Apr 2003 14:06:27 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordomo set sender to owner-ietf-smime@mail.imc.org using -f Received: from woodstock.binhost.com (woodstock.binhost.com [207.228.252.5]) by above.proper.com (8.12.9/8.11.6) with SMTP id h37L6QJM010354 for ; Mon, 7 Apr 2003 14:06:26 -0700 (PDT) Received: (qmail 19847 invoked by uid 0); 7 Apr 2003 21:05:57 -0000 Received: from unknown (HELO Russ-Laptop.vigilsec.com) (141.156.187.144) by woodstock.binhost.com with SMTP; 7 Apr 2003 21:05:57 -0000 Message-Id: <5.2.0.9.2.20030407165009.025b4d18@mail.binhost.com> X-Sender: housley@mail.binhost.com X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Mon, 07 Apr 2003 17:06:25 -0400 To: From: Russ Housley Subject: Re: WG Last Call: draft-ietf-smime-camellia-02.txt In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: 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 ietf-smime-oid-reg@imc.org if you want it assigned from the S/MIME WG arc. Russ From owner-ietf-smime@mail.imc.org Wed Apr 9 01:45:55 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA19250 for ; Wed, 9 Apr 2003 01:45:55 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h395AWJM006543 for ; Tue, 8 Apr 2003 22:10:32 -0700 (PDT) Received: (from majordomo@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h395AWNt006542 for ietf-smime-bks; Tue, 8 Apr 2003 22:10:32 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordomo set sender to owner-ietf-smime@mail.imc.org using -f Received: from mail1.ics.ntts.co.jp (mail1.ics.ntts.co.jp [202.32.24.45]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h395AUJM006537 for ; Tue, 8 Apr 2003 22:10:30 -0700 (PDT) Received: from mail26.silk.ntts.co.jp by mail1.ics.ntts.co.jp (8.9.3p2/3.7W-NTTSOFT-SUR2.0) id OAA23678 for ; Wed, 9 Apr 2003 14:10:34 +0900 (JST) (envelope-from akato@po.ntts.co.jp) Received: from helene.mc.ntts.co.jp by mail26.silk.ntts.co.jp (8.11.7/3.7W-silk-4.6) id h395AXT03346; Wed, 9 Apr 2003 14:10:33 +0900 (JST) (envelope-from akato@po.ntts.co.jp) Received: from [10.7.120.83] ([10.7.120.83]) by helene.mc.ntts.co.jp (8.12.8/8.12.8) with ESMTP id h395AX7Z029772; Wed, 9 Apr 2003 14:10:33 +0900 (JST) (envelope-from akato@po.ntts.co.jp) Date: Wed, 09 Apr 2003 14:10:33 +0900 From: Akihiro KATO To: ietf-smime@imc.org Subject: Re: WG Last Call: draft-ietf-smime-camellia-02.txt Cc: akato@po.ntts.co.jp In-Reply-To: <5.2.0.9.2.20030407165009.025b4d18@mail.binhost.com> References: <5.2.0.9.2.20030407165009.025b4d18@mail.binhost.com> Message-Id: <20030409141009.2C81.AKATO@po.ntts.co.jp> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Becky! ver. 2.05.01 Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Russ, Thanks for the comments. On Mon, 07 Apr 2003 17:06:25 -0400 Russ Housley 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 > ietf-smime-oid-reg@imc.org 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 From owner-ietf-smime@mail.imc.org Wed Apr 9 17:16:40 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA15034 for ; Wed, 9 Apr 2003 17:16:39 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h39KfaJM022108 for ; Wed, 9 Apr 2003 13:41:36 -0700 (PDT) Received: (from majordomo@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h39KfaEa022107 for ietf-smime-bks; Wed, 9 Apr 2003 13:41:36 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordomo set sender to owner-ietf-smime@mail.imc.org using -f Received: from woodstock.binhost.com (woodstock.binhost.com [207.228.252.5]) by above.proper.com (8.12.9/8.11.6) with SMTP id h39KfZJM022103 for ; Wed, 9 Apr 2003 13:41:35 -0700 (PDT) Received: (qmail 20293 invoked by uid 0); 9 Apr 2003 20:40:55 -0000 Received: from unknown (HELO Russ-Laptop.vigilsec.com) (141.156.221.51) by woodstock.binhost.com with SMTP; 9 Apr 2003 20:40:55 -0000 Message-Id: <5.2.0.9.2.20030409163344.01894888@mail.binhost.com> X-Sender: housley@mail.binhost.com X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Wed, 09 Apr 2003 16:34:34 -0400 To: Akihiro KATO , ietf-smime@imc.org From: Russ Housley Subject: Re: WG Last Call: draft-ietf-smime-camellia-02.txt Cc: akato@po.ntts.co.jp In-Reply-To: <20030409141009.2C81.AKATO@po.ntts.co.jp> References: <5.2.0.9.2.20030407165009.025b4d18@mail.binhost.com> <5.2.0.9.2.20030407165009.025b4d18@mail.binhost.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: 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 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 > > ietf-smime-oid-reg@imc.org 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 From owner-ietf-smime@mail.imc.org Wed Apr 9 17:17:23 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA15081 for ; Wed, 9 Apr 2003 17:17:22 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h39KukJM022392 for ; Wed, 9 Apr 2003 13:56:46 -0700 (PDT) Received: (from majordomo@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h39Kuk4r022391 for ietf-smime-bks; Wed, 9 Apr 2003 13:56:46 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordomo set sender to owner-ietf-smime@mail.imc.org using -f Received: from ietf.org (odin.ietf.org [132.151.1.176]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h39KuiJM022387 for ; Wed, 9 Apr 2003 13:56:45 -0700 (PDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA14067; Wed, 9 Apr 2003 16:54:11 -0400 (EDT) Message-Id: <200304092054.QAA14067@ietf.org> To: IETF-Announce: ; Cc: RFC Editor , Internet Architecture Board , ietf-smime@imc.org From: The IESG 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: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: The IESG has approved the Internet-Draft 'Wrapping an HMAC key with a Triple-DES Key or an AES Key' 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. From owner-ietf-smime@mail.imc.org Wed Apr 9 23:06:24 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA24373 for ; Wed, 9 Apr 2003 23:06:24 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h3A2fiJM009040 for ; Wed, 9 Apr 2003 19:41:44 -0700 (PDT) Received: (from majordomo@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h3A2fiMD009039 for ietf-smime-bks; Wed, 9 Apr 2003 19:41:44 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordomo set sender to owner-ietf-smime@mail.imc.org using -f Received: from 3w-smtp-ab.korea.com ([211.109.1.152]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h3A2fTJM009031 for ; Wed, 9 Apr 2003 19:41:36 -0700 (PDT) Received: from 3e-exchange-bj.korea.com ([172.31.1.207]) by 3w-smtp-ab.korea.com with Microsoft SMTPSVC(5.0.2195.5329); Thu, 10 Apr 2003 07:30:41 +0900 Received: from mail pickup service by 3e-exchange-bj.korea.com with Microsoft SMTPSVC; Thu, 10 Apr 2003 07:30:35 +0900 Received: from 3w-smtp-ao.korea.com ([172.31.1.74]) by 3e-exchange-bj.korea.com with Microsoft SMTPSVC(5.0.2195.5329); Thu, 10 Apr 2003 06:41:22 +0900 Received: from 3w-smtp-ao.korea.com ([172.31.1.74]) by 3w-smtp-ao.korea.com with Microsoft SMTPSVC(5.0.2195.5329); Thu, 10 Apr 2003 06:41:22 +0900 Received: from ran.ietf.org ([132.151.6.60]) by 211.109.1.125 with InterScan Messaging Security Suite; Thu, 10 Apr 2003 06:41:21 +0900 Received: from majordomo by ran.ietf.org with local (Exim 4.10) id 193Mt2-00065C-00 for ietf-announce-list@ran.ietf.org; Wed, 09 Apr 2003 17:13:40 -0400 Received: from odin.ietf.org ([10.27.2.28] helo=ietf.org) by ran.ietf.org with esmtp (Exim 4.10) id 193MsC-00061f-00 for all-ietf@ran.ietf.org; Wed, 09 Apr 2003 17:12:48 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA14067; Wed, 9 Apr 2003 16:54:11 -0400 (EDT) Message-Id: <200304092054.QAA14067@ietf.org> To: IETF-Announce: ; Cc: RFC Editor , Internet Architecture Board , ietf-smime@imc.org From: The IESG 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 X-OriginalArrivalTime: 09 Apr 2003 21:41:22.0680 (UTC) FILETIME=[C38E2F80:01C2FEE0] Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: The IESG has approved the Internet-Draft 'Wrapping an HMAC key with a Triple-DES Key or an AES Key' 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. From owner-ietf-smime@mail.imc.org Thu Apr 10 03:57:27 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA10986 for ; Thu, 10 Apr 2003 03:57:26 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h3A79kJM002918 for ; Thu, 10 Apr 2003 00:09:46 -0700 (PDT) Received: (from majordomo@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h3A79kdl002917 for ietf-smime-bks; Thu, 10 Apr 2003 00:09:46 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordomo set sender to owner-ietf-smime@mail.imc.org using -f Received: from hermes.cs.auckland.ac.nz (hermes.cs.auckland.ac.nz [130.216.35.151]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h3A79iJM002913 for ; Thu, 10 Apr 2003 00:09:44 -0700 (PDT) Received: from medusa01.cs.auckland.ac.nz (medusa01.cs.auckland.ac.nz [130.216.34.33]) by hermes.cs.auckland.ac.nz (8.12.9/8.12.9) with ESMTP id h3A78uoU024450; Thu, 10 Apr 2003 19:08:56 +1200 Received: (from pgut001@localhost) by medusa01.cs.auckland.ac.nz (8.11.6/8.11.6) id h3A78uB21823; Thu, 10 Apr 2003 19:08:56 +1200 Date: Thu, 10 Apr 2003 19:08:56 +1200 Message-Id: <200304100708.h3A78uB21823@medusa01.cs.auckland.ac.nz> From: pgut001@cs.auckland.ac.nz (Peter Gutmann) To: iab@iab.org, ietf-smime@imc.org Subject: Re: Protocol Action: Wrapping an HMAC key with a Triple-DES Key or an AES Key to Proposed Standard Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: >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. From owner-ietf-smime@mail.imc.org Thu Apr 10 13:41:00 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA27646 for ; Thu, 10 Apr 2003 13:41:00 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h3AH19JM026043 for ; Thu, 10 Apr 2003 10:01:09 -0700 (PDT) Received: (from majordomo@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h3AH19k1026042 for ietf-smime-bks; Thu, 10 Apr 2003 10:01:09 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordomo set sender to owner-ietf-smime@mail.imc.org using -f Received: from woodstock.binhost.com (woodstock.binhost.com [207.228.252.5]) by above.proper.com (8.12.9/8.11.6) with SMTP id h3AH17JM026038 for ; Thu, 10 Apr 2003 10:01:07 -0700 (PDT) Received: (qmail 7899 invoked by uid 0); 10 Apr 2003 17:00:36 -0000 Received: from unknown (HELO Russ-Laptop.vigilsec.com) (141.156.163.154) by woodstock.binhost.com with SMTP; 10 Apr 2003 17:00:36 -0000 Message-Id: <5.2.0.9.2.20030410125148.03303d50@mail.binhost.com> X-Sender: housley@mail.binhost.com X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Thu, 10 Apr 2003 13:00:22 -0400 To: pgut001@cs.auckland.ac.nz From: Russ Housley Subject: Re: Protocol Action: Wrapping an HMAC key with a Triple-DES Key or an AES Key to Proposed Standard Cc: smb@research.att.com, iab@iab.org, ietf-smime@imc.org In-Reply-To: <200304100708.h3A78uB21823@medusa01.cs.auckland.ac.nz> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: 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 From owner-ietf-smime@mail.imc.org Thu Apr 10 23:25:50 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA16612 for ; Thu, 10 Apr 2003 23:25:49 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h3B2xpJM026753 for ; Thu, 10 Apr 2003 19:59:51 -0700 (PDT) Received: (from majordomo@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h3B2xpOl026752 for ietf-smime-bks; Thu, 10 Apr 2003 19:59:51 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordomo set sender to owner-ietf-smime@mail.imc.org using -f Received: from hermes.cs.auckland.ac.nz (hermes.cs.auckland.ac.nz [130.216.35.151]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h3B2xnJM026747 for ; Thu, 10 Apr 2003 19:59:50 -0700 (PDT) Received: from medusa01.cs.auckland.ac.nz (medusa01.cs.auckland.ac.nz [130.216.34.33]) by hermes.cs.auckland.ac.nz (8.12.9/8.12.9) with ESMTP id h3B2x4oU015194; Fri, 11 Apr 2003 14:59:04 +1200 Received: (from pgut001@localhost) by medusa01.cs.auckland.ac.nz (8.11.6/8.11.6) id h3B2x3X29235; Fri, 11 Apr 2003 14:59:03 +1200 Date: Fri, 11 Apr 2003 14:59:03 +1200 Message-Id: <200304110259.h3B2x3X29235@medusa01.cs.auckland.ac.nz> From: pgut001@cs.auckland.ac.nz (Peter Gutmann) To: housley@vigilsec.com, pgut001@cs.auckland.ac.nz Subject: Re: Protocol Action: Wrapping an HMAC key with a Triple-DES Key or an AES Key to Proposed Standard Cc: iab@iab.org, ietf-smime@imc.org, smb@research.att.com Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Russ Housley 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. From owner-ietf-smime@mail.imc.org Fri Apr 11 09:33:16 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA11912 for ; Fri, 11 Apr 2003 09:33:15 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h3BD5IJM020918 for ; Fri, 11 Apr 2003 06:05:18 -0700 (PDT) Received: (from majordomo@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h3BD5Ioo020917 for ietf-smime-bks; Fri, 11 Apr 2003 06:05:18 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordomo set sender to owner-ietf-smime@mail.imc.org using -f Received: from woodstock.binhost.com (woodstock.binhost.com [207.228.252.5]) by above.proper.com (8.12.9/8.11.6) with SMTP id h3BD5GJM020912 for ; Fri, 11 Apr 2003 06:05:17 -0700 (PDT) Received: (qmail 2888 invoked by uid 0); 11 Apr 2003 13:04:44 -0000 Received: from unknown (HELO Russ-Laptop.vigilsec.com) (141.156.221.206) by woodstock.binhost.com with SMTP; 11 Apr 2003 13:04:44 -0000 Message-Id: <5.2.0.9.2.20030411085235.03102f48@mail.binhost.com> X-Sender: housley@mail.binhost.com X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Fri, 11 Apr 2003 08:54:24 -0400 To: pgut001@cs.auckland.ac.nz From: Russ Housley Subject: Re: Protocol Action: Wrapping an HMAC key with a Triple-DES Key or an AES Key to Proposed Standard Cc: iab@iab.org, ietf-smime@imc.org, smb@research.att.com In-Reply-To: <200304110259.h3B2x3X29235@medusa01.cs.auckland.ac.nz> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: 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 From ub6g938i@yahoo.com Fri Apr 11 19:15:18 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA04723; Fri, 11 Apr 2003 19:15:17 -0400 (EDT) Received: from localhost ([127.0.0.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.12) id 1947mL-0006X1-00; Fri, 11 Apr 2003 19:17:53 -0400 Received: from lsanca1-ar20-4-65-066-081.lsanca1.dsl-verizon.net ([4.65.66.81]) by ietf-mx with smtp (Exim 4.12) id 1947mJ-0006Wv-00; Fri, 11 Apr 2003 19:17:52 -0400 Received: from bdy.fb90.org ([207.64.163.162]) by lsanca1-ar20-4-65-066-081.lsanca1.dsl-verizon.net with ESMTP id C760EB9AF13; Sat, 12 Apr 2003 14:16:26 +0100 Message-ID: From: "Darla Hoyt" To: sipping-admin@ietf.org Subject: Phentermine, Xenical & many others prescribed online and shipped overnight Sipping-admin Date: Sat, 12 Apr 03 14:16:26 GMT X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2919.6700 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="8E189_CCD02E_71FE_.6" This is a multi-part message in MIME format. --8E189_CCD02E_71FE_.6 Content-Type: text/html Content-Transfer-Encoding: quoted-printable

Did you know you can get prescription medications prescribed online with
NO PRIOR PRESCRIPTION REQUI= RED



REMOVE




dissipation



%TO_= NAME --8E189_CCD02E_71FE_.6-- From 4ugei6o4g@earthlink.net Sat Apr 12 21:49:47 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA09476; Sat, 12 Apr 2003 21:49:46 -0400 (EDT) Received: from localhost ([127.0.0.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.12) id 194WfN-0003NB-00; Sat, 12 Apr 2003 21:52:21 -0400 Received: from adsl-65-69-208-169.dsl.hstntx.swbell.net ([65.69.208.169]) by ietf-mx with smtp (Exim 4.12) id 194WfK-0003N6-00; Sat, 12 Apr 2003 21:52:20 -0400 Received: from yc4.nwwn0.com [155.131.113.166] by adsl-65-69-208-169.dsl.hstntx.swbell.net; Sun, 13 Apr 2003 20:46:56 +0500 Message-ID: <3$-$2-$083k1t$$k-4p89p5km@84ne.10qd> From: "Olga Gonzalez" <4ugei6o4g@earthlink.net> To: sipping-admin@ietf.org Subject: Get prescribed , Diet Pills and much more online! Overnight Shipping Sipping-admin Date: Sun, 13 Apr 03 20:46:56 GMT X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2615.200 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="48_72B3_E.DAEDCBD." This is a multi-part message in MIME format. --48_72B3_E.DAEDCBD. Content-Type: text/html Content-Transfer-Encoding: quoted-printable

Did you know you can get prescription medications prescribed online with
NO PRIOR PRESCRIPTION REQUI= RED



REMOVE




twine



%TO_= NAME --48_72B3_E.DAEDCBD.-- From owner-ietf-smime@mail.imc.org Wed Apr 23 07:28:11 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA12942 for ; Wed, 23 Apr 2003 07:28:08 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3NAvDt2008498 for ; Wed, 23 Apr 2003 03:57:13 -0700 (PDT) (envelope-from owner-ietf-smime@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h3NAvD7E008497 for ietf-smime-bks; Wed, 23 Apr 2003 03:57:13 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-smime@mail.imc.org using -f Received: from ietf.org (odin.ietf.org [132.151.1.176]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3NAvCt2008492 for ; Wed, 23 Apr 2003 03:57:13 -0700 (PDT) (envelope-from nsyracus@cnri.reston.va.us) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA11006; Wed, 23 Apr 2003 06:54:27 -0400 (EDT) Message-Id: <200304231054.GAA11006@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ietf-smime@imc.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-smime-camellia-03.txt Date: Wed, 23 Apr 2003 06:54:27 -0400 Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the S/MIME Mail Security Working Group of the IETF. Title : Use of the 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: mailserv@ietf.org. 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="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-4-22151839.I-D@ietf.org> 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: <2003-4-22151839.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ietf-smime@mail.imc.org Wed Apr 23 18:07:14 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA10373 for ; Wed, 23 Apr 2003 18:07:13 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3NLe8t2040751 for ; Wed, 23 Apr 2003 14:40:08 -0700 (PDT) (envelope-from owner-ietf-smime@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h3NLe8ZY040750 for ietf-smime-bks; Wed, 23 Apr 2003 14:40:08 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-smime@mail.imc.org using -f Received: from ietf.org (odin.ietf.org [132.151.1.176]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3NLe6t2040745 for ; Wed, 23 Apr 2003 14:40:07 -0700 (PDT) (envelope-from jhargest@cnri.reston.va.us) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA08998; Wed, 23 Apr 2003 17:37:19 -0400 (EDT) Message-Id: <200304232137.RAA08998@ietf.org> To: IETF-Announce: ; Cc: RFC Editor , Internet Architecture Board , ietf-smime@imc.org From: The IESG 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: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: The IESG has approved the Internet-Draft 'Use of the RSAES-OAEP Transport Algorithm in CMS' 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 From owner-ietf-smime@mail.imc.org Wed Apr 23 19:10:23 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA13668 for ; Wed, 23 Apr 2003 19:10:22 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3NMmQt2044029 for ; Wed, 23 Apr 2003 15:48:26 -0700 (PDT) (envelope-from owner-ietf-smime@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h3NMmQGk044028 for ietf-smime-bks; Wed, 23 Apr 2003 15:48:26 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-smime@mail.imc.org using -f Received: from brutesquadlabs.com (gtec136-m.isomedia.com [207.115.67.136] (may be forged)) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3NMmPt2044022 for ; Wed, 23 Apr 2003 15:48:25 -0700 (PDT) (envelope-from blake@brutesquadlabs.com) Received: from DEXTER ([192.168.0.4]) by brutesquadlabs.com with ESMTP ; Wed, 23 Apr 2003 13:31:25 -0700 From: "Blake Ramsdell" To: Subject: WG Last Call: draft-ietf-smime-camellia-03.txt Date: Wed, 23 Apr 2003 13:31:25 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2627 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Importance: Normal Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit 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 ietf-smime@imc.org 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. Blake -- Blake Ramsdell | Brute Squad Labs | http://www.brutesquadlabs.com From owner-ietf-smime@mail.imc.org Thu Apr 24 10:27:59 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA18239 for ; Thu, 24 Apr 2003 10:27:59 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3OE0Ht2005686 for ; Thu, 24 Apr 2003 07:00:17 -0700 (PDT) (envelope-from owner-ietf-smime@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h3OE0HPB005685 for ietf-smime-bks; Thu, 24 Apr 2003 07:00:17 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-smime@mail.imc.org using -f Received: from woodstock.binhost.com (woodstock.binhost.com [207.228.252.5]) by above.proper.com (8.12.8p1/8.12.8) with SMTP id h3OE0Gt2005680 for ; Thu, 24 Apr 2003 07:00:16 -0700 (PDT) (envelope-from housley@vigilsec.com) Received: (qmail 13280 invoked by uid 0); 24 Apr 2003 13:59:24 -0000 Received: from unknown (HELO Russ-Laptop.vigilsec.com) (141.156.32.185) by woodstock.binhost.com with SMTP; 24 Apr 2003 13:59:24 -0000 Message-Id: <5.2.0.9.2.20030424095827.035c7d30@mail.binhost.com> X-Sender: housley@mail.binhost.com X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Thu, 24 Apr 2003 09:59:22 -0400 To: "Blake Ramsdell" , From: Russ Housley Subject: Re: WG Last Call: draft-ietf-smime-camellia-03.txt In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: 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 ietf-smime@imc.org >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. > > > >Blake >-- >Blake Ramsdell | Brute Squad Labs | http://www.brutesquadlabs.com From owner-ietf-smime@mail.imc.org Tue Apr 29 08:12:29 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA14178 for ; Tue, 29 Apr 2003 08:12:28 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3TBhNi2083794 for ; Tue, 29 Apr 2003 04:43:23 -0700 (PDT) (envelope-from owner-ietf-smime@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h3TBhNrv083793 for ietf-smime-bks; Tue, 29 Apr 2003 04:43:23 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-smime@mail.imc.org using -f Received: from ietf.org (odin.ietf.org [132.151.1.176]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3TBhMi2083788 for ; Tue, 29 Apr 2003 04:43:22 -0700 (PDT) (envelope-from nsyracus@cnri.reston.va.us) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA13168; Tue, 29 Apr 2003 07:40:32 -0400 (EDT) Message-Id: <200304291140.HAA13168@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ietf-smime@imc.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-smime-examples-10.txt Date: Tue, 29 Apr 2003 07:40:31 -0400 Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the S/MIME Mail Security Working Group of the IETF. Title : 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 with the single word 'subscribe' in the body of the message. Also, there is a Web site for the mailing list at . This draft is being discussed on the 'ietf-smime' mailing list. To join the list, send a message to with the single word 'subscribe' in the body of the message. Also, there is a Web site for the mailing list at . 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: mailserv@ietf.org. 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="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-4-28124058.I-D@ietf.org> 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: <2003-4-28124058.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ietf-smime@mail.imc.org Tue Apr 29 15:53:16 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA08433 for ; Tue, 29 Apr 2003 15:53:15 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3TJDoi2007088 for ; Tue, 29 Apr 2003 12:13:50 -0700 (PDT) (envelope-from owner-ietf-smime@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h3TJDoTN007087 for ietf-smime-bks; Tue, 29 Apr 2003 12:13:50 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-smime@mail.imc.org using -f Received: from brutesquadlabs.com (gtec136-m.isomedia.com [207.115.67.136] (may be forged)) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3TJDmi2007082 for ; Tue, 29 Apr 2003 12:13:49 -0700 (PDT) (envelope-from blake@brutesquadlabs.com) Received: from DEXTER ([192.168.0.4]) by brutesquadlabs.com with ESMTP ; Tue, 29 Apr 2003 12:13:44 -0700 From: "Blake Ramsdell" To: Subject: WG Last Call: draft-ietf-smime-examples-10.txt Date: Tue, 29 Apr 2003 12:13:44 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2627 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Importance: Normal Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit 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 ietf-smime@imc.org 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 From owner-ietf-smime@mail.imc.org Tue Apr 29 17:19:21 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA10996 for ; Tue, 29 Apr 2003 17:19:20 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3TKnEi2009750 for ; Tue, 29 Apr 2003 13:49:14 -0700 (PDT) (envelope-from owner-ietf-smime@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h3TKnDlD009749 for ietf-smime-bks; Tue, 29 Apr 2003 13:49:13 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-smime@mail.imc.org using -f Received: from brutesquadlabs.com (gtec136-m.isomedia.com [207.115.67.136] (may be forged)) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3TKnDi2009743 for ; Tue, 29 Apr 2003 13:49:13 -0700 (PDT) (envelope-from blake@brutesquadlabs.com) Received: from DEXTER ([192.168.0.4]) by brutesquadlabs.com with ESMTP ; Tue, 29 Apr 2003 13:49:10 -0700 From: "Blake Ramsdell" To: Subject: BobPrivRSAEncrypt spuriosity Date: Tue, 29 Apr 2003 13:49:10 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2627 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Importance: Normal Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit 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 owner-ietf-smime@mail.imc.org Wed Apr 30 17:33:31 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA24962 for ; Wed, 30 Apr 2003 17:33:30 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3UKvOi2095048 for ; Wed, 30 Apr 2003 13:57:24 -0700 (PDT) (envelope-from owner-ietf-smime@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h3UKvO1v095047 for ietf-smime-bks; Wed, 30 Apr 2003 13:57:24 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-smime@mail.imc.org using -f Received: from brutesquadlabs.com (gtec136-m.isomedia.com [207.115.67.136] (may be forged)) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3UKvNi2095041 for ; Wed, 30 Apr 2003 13:57:24 -0700 (PDT) (envelope-from blake@brutesquadlabs.com) Received: from DEXTER ([192.168.0.4]) by brutesquadlabs.com with ESMTP ; Wed, 30 Apr 2003 13:57:20 -0700 From: "Blake Ramsdell" To: "'Russ Housley'" , Cc: "'Sean P. Turner'" , Subject: draft-ietf-smime-camellia-03.txt ready for Standards Track Date: Wed, 30 Apr 2003 13:57:20 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2627 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Importance: Normal Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit 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 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3UKvOi2095048 for ; Wed, 30 Apr 2003 13:57:24 -0700 (PDT) (envelope-from owner-ietf-smime@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h3UKvO1v095047 for ietf-smime-bks; Wed, 30 Apr 2003 13:57:24 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-smime@mail.imc.org using -f Received: from brutesquadlabs.com (gtec136-m.isomedia.com [207.115.67.136] (may be forged)) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3UKvNi2095041 for ; Wed, 30 Apr 2003 13:57:24 -0700 (PDT) (envelope-from blake@brutesquadlabs.com) Received: from DEXTER ([192.168.0.4]) by brutesquadlabs.com with ESMTP ; Wed, 30 Apr 2003 13:57:20 -0700 From: "Blake Ramsdell" To: "'Russ Housley'" , Cc: "'Sean P. Turner'" , Subject: draft-ietf-smime-camellia-03.txt ready for Standards Track Date: Wed, 30 Apr 2003 13:57:20 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2627 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Importance: Normal Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: 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 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3TKnEi2009750 for ; Tue, 29 Apr 2003 13:49:14 -0700 (PDT) (envelope-from owner-ietf-smime@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h3TKnDlD009749 for ietf-smime-bks; Tue, 29 Apr 2003 13:49:13 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-smime@mail.imc.org using -f Received: from brutesquadlabs.com (gtec136-m.isomedia.com [207.115.67.136] (may be forged)) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3TKnDi2009743 for ; Tue, 29 Apr 2003 13:49:13 -0700 (PDT) (envelope-from blake@brutesquadlabs.com) Received: from DEXTER ([192.168.0.4]) by brutesquadlabs.com with ESMTP ; Tue, 29 Apr 2003 13:49:10 -0700 From: "Blake Ramsdell" To: Subject: BobPrivRSAEncrypt spuriosity Date: Tue, 29 Apr 2003 13:49:10 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2627 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Importance: Normal Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: 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 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3TJDoi2007088 for ; Tue, 29 Apr 2003 12:13:50 -0700 (PDT) (envelope-from owner-ietf-smime@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h3TJDoTN007087 for ietf-smime-bks; Tue, 29 Apr 2003 12:13:50 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-smime@mail.imc.org using -f Received: from brutesquadlabs.com (gtec136-m.isomedia.com [207.115.67.136] (may be forged)) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3TJDmi2007082 for ; Tue, 29 Apr 2003 12:13:49 -0700 (PDT) (envelope-from blake@brutesquadlabs.com) Received: from DEXTER ([192.168.0.4]) by brutesquadlabs.com with ESMTP ; Tue, 29 Apr 2003 12:13:44 -0700 From: "Blake Ramsdell" To: Subject: WG Last Call: draft-ietf-smime-examples-10.txt Date: Tue, 29 Apr 2003 12:13:44 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2627 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Importance: Normal Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: 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 ietf-smime@imc.org 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 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3TBhNi2083794 for ; Tue, 29 Apr 2003 04:43:23 -0700 (PDT) (envelope-from owner-ietf-smime@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h3TBhNrv083793 for ietf-smime-bks; Tue, 29 Apr 2003 04:43:23 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-smime@mail.imc.org using -f Received: from ietf.org (odin.ietf.org [132.151.1.176]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3TBhMi2083788 for ; Tue, 29 Apr 2003 04:43:22 -0700 (PDT) (envelope-from nsyracus@cnri.reston.va.us) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA13168; Tue, 29 Apr 2003 07:40:32 -0400 (EDT) Message-Id: <200304291140.HAA13168@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ietf-smime@imc.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-smime-examples-10.txt Date: Tue, 29 Apr 2003 07:40:31 -0400 Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the S/MIME Mail Security Working Group of the IETF. Title : 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 with the single word 'subscribe' in the body of the message. Also, there is a Web site for the mailing list at . This draft is being discussed on the 'ietf-smime' mailing list. To join the list, send a message to with the single word 'subscribe' in the body of the message. Also, there is a Web site for the mailing list at . 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: mailserv@ietf.org. 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="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-4-28124058.I-D@ietf.org> 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: <2003-4-28124058.I-D@ietf.org> --OtherAccess-- --NextPart-- Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3OE0Ht2005686 for ; Thu, 24 Apr 2003 07:00:17 -0700 (PDT) (envelope-from owner-ietf-smime@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h3OE0HPB005685 for ietf-smime-bks; Thu, 24 Apr 2003 07:00:17 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-smime@mail.imc.org using -f Received: from woodstock.binhost.com (woodstock.binhost.com [207.228.252.5]) by above.proper.com (8.12.8p1/8.12.8) with SMTP id h3OE0Gt2005680 for ; Thu, 24 Apr 2003 07:00:16 -0700 (PDT) (envelope-from housley@vigilsec.com) Received: (qmail 13280 invoked by uid 0); 24 Apr 2003 13:59:24 -0000 Received: from unknown (HELO Russ-Laptop.vigilsec.com) (141.156.32.185) by woodstock.binhost.com with SMTP; 24 Apr 2003 13:59:24 -0000 Message-Id: <5.2.0.9.2.20030424095827.035c7d30@mail.binhost.com> X-Sender: housley@mail.binhost.com X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Thu, 24 Apr 2003 09:59:22 -0400 To: "Blake Ramsdell" , From: Russ Housley Subject: Re: WG Last Call: draft-ietf-smime-camellia-03.txt In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: 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 ietf-smime@imc.org >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. > > > >Blake >-- >Blake Ramsdell | Brute Squad Labs | http://www.brutesquadlabs.com Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3NMmQt2044029 for ; Wed, 23 Apr 2003 15:48:26 -0700 (PDT) (envelope-from owner-ietf-smime@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h3NMmQGk044028 for ietf-smime-bks; Wed, 23 Apr 2003 15:48:26 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-smime@mail.imc.org using -f Received: from brutesquadlabs.com (gtec136-m.isomedia.com [207.115.67.136] (may be forged)) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3NMmPt2044022 for ; Wed, 23 Apr 2003 15:48:25 -0700 (PDT) (envelope-from blake@brutesquadlabs.com) Received: from DEXTER ([192.168.0.4]) by brutesquadlabs.com with ESMTP ; Wed, 23 Apr 2003 13:31:25 -0700 From: "Blake Ramsdell" To: Subject: WG Last Call: draft-ietf-smime-camellia-03.txt Date: Wed, 23 Apr 2003 13:31:25 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2627 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Importance: Normal Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: 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 ietf-smime@imc.org 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. Blake -- Blake Ramsdell | Brute Squad Labs | http://www.brutesquadlabs.com Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3NLe8t2040751 for ; Wed, 23 Apr 2003 14:40:08 -0700 (PDT) (envelope-from owner-ietf-smime@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h3NLe8ZY040750 for ietf-smime-bks; Wed, 23 Apr 2003 14:40:08 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-smime@mail.imc.org using -f Received: from ietf.org (odin.ietf.org [132.151.1.176]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3NLe6t2040745 for ; Wed, 23 Apr 2003 14:40:07 -0700 (PDT) (envelope-from jhargest@cnri.reston.va.us) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA08998; Wed, 23 Apr 2003 17:37:19 -0400 (EDT) Message-Id: <200304232137.RAA08998@ietf.org> To: IETF-Announce: ; Cc: RFC Editor , Internet Architecture Board , ietf-smime@imc.org From: The IESG 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: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: The IESG has approved the Internet-Draft 'Use of the RSAES-OAEP Transport Algorithm in CMS' 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 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3NAvDt2008498 for ; Wed, 23 Apr 2003 03:57:13 -0700 (PDT) (envelope-from owner-ietf-smime@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h3NAvD7E008497 for ietf-smime-bks; Wed, 23 Apr 2003 03:57:13 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-smime@mail.imc.org using -f Received: from ietf.org (odin.ietf.org [132.151.1.176]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3NAvCt2008492 for ; Wed, 23 Apr 2003 03:57:13 -0700 (PDT) (envelope-from nsyracus@cnri.reston.va.us) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA11006; Wed, 23 Apr 2003 06:54:27 -0400 (EDT) Message-Id: <200304231054.GAA11006@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ietf-smime@imc.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-smime-camellia-03.txt Date: Wed, 23 Apr 2003 06:54:27 -0400 Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the S/MIME Mail Security Working Group of the IETF. Title : Use of the 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: mailserv@ietf.org. 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="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-4-22151839.I-D@ietf.org> 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: <2003-4-22151839.I-D@ietf.org> --OtherAccess-- --NextPart-- Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h3BD5IJM020918 for ; Fri, 11 Apr 2003 06:05:18 -0700 (PDT) Received: (from majordomo@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h3BD5Ioo020917 for ietf-smime-bks; Fri, 11 Apr 2003 06:05:18 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordomo set sender to owner-ietf-smime@mail.imc.org using -f Received: from woodstock.binhost.com (woodstock.binhost.com [207.228.252.5]) by above.proper.com (8.12.9/8.11.6) with SMTP id h3BD5GJM020912 for ; Fri, 11 Apr 2003 06:05:17 -0700 (PDT) Received: (qmail 2888 invoked by uid 0); 11 Apr 2003 13:04:44 -0000 Received: from unknown (HELO Russ-Laptop.vigilsec.com) (141.156.221.206) by woodstock.binhost.com with SMTP; 11 Apr 2003 13:04:44 -0000 Message-Id: <5.2.0.9.2.20030411085235.03102f48@mail.binhost.com> X-Sender: housley@mail.binhost.com X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Fri, 11 Apr 2003 08:54:24 -0400 To: pgut001@cs.auckland.ac.nz From: Russ Housley Subject: Re: Protocol Action: Wrapping an HMAC key with a Triple-DES Key or an AES Key to Proposed Standard Cc: iab@iab.org, ietf-smime@imc.org, smb@research.att.com In-Reply-To: <200304110259.h3B2x3X29235@medusa01.cs.auckland.ac.nz> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: 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 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h3B2xpJM026753 for ; Thu, 10 Apr 2003 19:59:51 -0700 (PDT) Received: (from majordomo@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h3B2xpOl026752 for ietf-smime-bks; Thu, 10 Apr 2003 19:59:51 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordomo set sender to owner-ietf-smime@mail.imc.org using -f Received: from hermes.cs.auckland.ac.nz (hermes.cs.auckland.ac.nz [130.216.35.151]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h3B2xnJM026747 for ; Thu, 10 Apr 2003 19:59:50 -0700 (PDT) Received: from medusa01.cs.auckland.ac.nz (medusa01.cs.auckland.ac.nz [130.216.34.33]) by hermes.cs.auckland.ac.nz (8.12.9/8.12.9) with ESMTP id h3B2x4oU015194; Fri, 11 Apr 2003 14:59:04 +1200 Received: (from pgut001@localhost) by medusa01.cs.auckland.ac.nz (8.11.6/8.11.6) id h3B2x3X29235; Fri, 11 Apr 2003 14:59:03 +1200 Date: Fri, 11 Apr 2003 14:59:03 +1200 Message-Id: <200304110259.h3B2x3X29235@medusa01.cs.auckland.ac.nz> From: pgut001@cs.auckland.ac.nz (Peter Gutmann) To: housley@vigilsec.com, pgut001@cs.auckland.ac.nz Subject: Re: Protocol Action: Wrapping an HMAC key with a Triple-DES Key or an AES Key to Proposed Standard Cc: iab@iab.org, ietf-smime@imc.org, smb@research.att.com Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Russ Housley 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. Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h3AH19JM026043 for ; Thu, 10 Apr 2003 10:01:09 -0700 (PDT) Received: (from majordomo@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h3AH19k1026042 for ietf-smime-bks; Thu, 10 Apr 2003 10:01:09 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordomo set sender to owner-ietf-smime@mail.imc.org using -f Received: from woodstock.binhost.com (woodstock.binhost.com [207.228.252.5]) by above.proper.com (8.12.9/8.11.6) with SMTP id h3AH17JM026038 for ; Thu, 10 Apr 2003 10:01:07 -0700 (PDT) Received: (qmail 7899 invoked by uid 0); 10 Apr 2003 17:00:36 -0000 Received: from unknown (HELO Russ-Laptop.vigilsec.com) (141.156.163.154) by woodstock.binhost.com with SMTP; 10 Apr 2003 17:00:36 -0000 Message-Id: <5.2.0.9.2.20030410125148.03303d50@mail.binhost.com> X-Sender: housley@mail.binhost.com X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Thu, 10 Apr 2003 13:00:22 -0400 To: pgut001@cs.auckland.ac.nz From: Russ Housley Subject: Re: Protocol Action: Wrapping an HMAC key with a Triple-DES Key or an AES Key to Proposed Standard Cc: smb@research.att.com, iab@iab.org, ietf-smime@imc.org In-Reply-To: <200304100708.h3A78uB21823@medusa01.cs.auckland.ac.nz> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: 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 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h3A79kJM002918 for ; Thu, 10 Apr 2003 00:09:46 -0700 (PDT) Received: (from majordomo@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h3A79kdl002917 for ietf-smime-bks; Thu, 10 Apr 2003 00:09:46 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordomo set sender to owner-ietf-smime@mail.imc.org using -f Received: from hermes.cs.auckland.ac.nz (hermes.cs.auckland.ac.nz [130.216.35.151]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h3A79iJM002913 for ; Thu, 10 Apr 2003 00:09:44 -0700 (PDT) Received: from medusa01.cs.auckland.ac.nz (medusa01.cs.auckland.ac.nz [130.216.34.33]) by hermes.cs.auckland.ac.nz (8.12.9/8.12.9) with ESMTP id h3A78uoU024450; Thu, 10 Apr 2003 19:08:56 +1200 Received: (from pgut001@localhost) by medusa01.cs.auckland.ac.nz (8.11.6/8.11.6) id h3A78uB21823; Thu, 10 Apr 2003 19:08:56 +1200 Date: Thu, 10 Apr 2003 19:08:56 +1200 Message-Id: <200304100708.h3A78uB21823@medusa01.cs.auckland.ac.nz> From: pgut001@cs.auckland.ac.nz (Peter Gutmann) To: iab@iab.org, ietf-smime@imc.org Subject: Re: Protocol Action: Wrapping an HMAC key with a Triple-DES Key or an AES Key to Proposed Standard Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: >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. Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h3A2fiJM009040 for ; Wed, 9 Apr 2003 19:41:44 -0700 (PDT) Received: (from majordomo@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h3A2fiMD009039 for ietf-smime-bks; Wed, 9 Apr 2003 19:41:44 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordomo set sender to owner-ietf-smime@mail.imc.org using -f Received: from 3w-smtp-ab.korea.com ([211.109.1.152]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h3A2fTJM009031 for ; Wed, 9 Apr 2003 19:41:36 -0700 (PDT) Received: from 3e-exchange-bj.korea.com ([172.31.1.207]) by 3w-smtp-ab.korea.com with Microsoft SMTPSVC(5.0.2195.5329); Thu, 10 Apr 2003 07:30:41 +0900 Received: from mail pickup service by 3e-exchange-bj.korea.com with Microsoft SMTPSVC; Thu, 10 Apr 2003 07:30:35 +0900 Received: from 3w-smtp-ao.korea.com ([172.31.1.74]) by 3e-exchange-bj.korea.com with Microsoft SMTPSVC(5.0.2195.5329); Thu, 10 Apr 2003 06:41:22 +0900 Received: from 3w-smtp-ao.korea.com ([172.31.1.74]) by 3w-smtp-ao.korea.com with Microsoft SMTPSVC(5.0.2195.5329); Thu, 10 Apr 2003 06:41:22 +0900 Received: from ran.ietf.org ([132.151.6.60]) by 211.109.1.125 with InterScan Messaging Security Suite; Thu, 10 Apr 2003 06:41:21 +0900 Received: from majordomo by ran.ietf.org with local (Exim 4.10) id 193Mt2-00065C-00 for ietf-announce-list@ran.ietf.org; Wed, 09 Apr 2003 17:13:40 -0400 Received: from odin.ietf.org ([10.27.2.28] helo=ietf.org) by ran.ietf.org with esmtp (Exim 4.10) id 193MsC-00061f-00 for all-ietf@ran.ietf.org; Wed, 09 Apr 2003 17:12:48 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA14067; Wed, 9 Apr 2003 16:54:11 -0400 (EDT) Message-Id: <200304092054.QAA14067@ietf.org> To: IETF-Announce: ; Cc: RFC Editor , Internet Architecture Board , ietf-smime@imc.org From: The IESG 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 X-OriginalArrivalTime: 09 Apr 2003 21:41:22.0680 (UTC) FILETIME=[C38E2F80:01C2FEE0] Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: The IESG has approved the Internet-Draft 'Wrapping an HMAC key with a Triple-DES Key or an AES Key' 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. Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h39KukJM022392 for ; Wed, 9 Apr 2003 13:56:46 -0700 (PDT) Received: (from majordomo@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h39Kuk4r022391 for ietf-smime-bks; Wed, 9 Apr 2003 13:56:46 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordomo set sender to owner-ietf-smime@mail.imc.org using -f Received: from ietf.org (odin.ietf.org [132.151.1.176]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h39KuiJM022387 for ; Wed, 9 Apr 2003 13:56:45 -0700 (PDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA14067; Wed, 9 Apr 2003 16:54:11 -0400 (EDT) Message-Id: <200304092054.QAA14067@ietf.org> To: IETF-Announce: ; Cc: RFC Editor , Internet Architecture Board , ietf-smime@imc.org From: The IESG 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: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: The IESG has approved the Internet-Draft 'Wrapping an HMAC key with a Triple-DES Key or an AES Key' 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. Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h39KfaJM022108 for ; Wed, 9 Apr 2003 13:41:36 -0700 (PDT) Received: (from majordomo@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h39KfaEa022107 for ietf-smime-bks; Wed, 9 Apr 2003 13:41:36 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordomo set sender to owner-ietf-smime@mail.imc.org using -f Received: from woodstock.binhost.com (woodstock.binhost.com [207.228.252.5]) by above.proper.com (8.12.9/8.11.6) with SMTP id h39KfZJM022103 for ; Wed, 9 Apr 2003 13:41:35 -0700 (PDT) Received: (qmail 20293 invoked by uid 0); 9 Apr 2003 20:40:55 -0000 Received: from unknown (HELO Russ-Laptop.vigilsec.com) (141.156.221.51) by woodstock.binhost.com with SMTP; 9 Apr 2003 20:40:55 -0000 Message-Id: <5.2.0.9.2.20030409163344.01894888@mail.binhost.com> X-Sender: housley@mail.binhost.com X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Wed, 09 Apr 2003 16:34:34 -0400 To: Akihiro KATO , ietf-smime@imc.org From: Russ Housley Subject: Re: WG Last Call: draft-ietf-smime-camellia-02.txt Cc: akato@po.ntts.co.jp In-Reply-To: <20030409141009.2C81.AKATO@po.ntts.co.jp> References: <5.2.0.9.2.20030407165009.025b4d18@mail.binhost.com> <5.2.0.9.2.20030407165009.025b4d18@mail.binhost.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: 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 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 > > ietf-smime-oid-reg@imc.org 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 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h395AWJM006543 for ; Tue, 8 Apr 2003 22:10:32 -0700 (PDT) Received: (from majordomo@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h395AWNt006542 for ietf-smime-bks; Tue, 8 Apr 2003 22:10:32 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordomo set sender to owner-ietf-smime@mail.imc.org using -f Received: from mail1.ics.ntts.co.jp (mail1.ics.ntts.co.jp [202.32.24.45]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h395AUJM006537 for ; Tue, 8 Apr 2003 22:10:30 -0700 (PDT) Received: from mail26.silk.ntts.co.jp by mail1.ics.ntts.co.jp (8.9.3p2/3.7W-NTTSOFT-SUR2.0) id OAA23678 for ; Wed, 9 Apr 2003 14:10:34 +0900 (JST) (envelope-from akato@po.ntts.co.jp) Received: from helene.mc.ntts.co.jp by mail26.silk.ntts.co.jp (8.11.7/3.7W-silk-4.6) id h395AXT03346; Wed, 9 Apr 2003 14:10:33 +0900 (JST) (envelope-from akato@po.ntts.co.jp) Received: from [10.7.120.83] ([10.7.120.83]) by helene.mc.ntts.co.jp (8.12.8/8.12.8) with ESMTP id h395AX7Z029772; Wed, 9 Apr 2003 14:10:33 +0900 (JST) (envelope-from akato@po.ntts.co.jp) Date: Wed, 09 Apr 2003 14:10:33 +0900 From: Akihiro KATO To: ietf-smime@imc.org Subject: Re: WG Last Call: draft-ietf-smime-camellia-02.txt Cc: akato@po.ntts.co.jp In-Reply-To: <5.2.0.9.2.20030407165009.025b4d18@mail.binhost.com> References: <5.2.0.9.2.20030407165009.025b4d18@mail.binhost.com> Message-Id: <20030409141009.2C81.AKATO@po.ntts.co.jp> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Becky! ver. 2.05.01 Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Russ, Thanks for the comments. On Mon, 07 Apr 2003 17:06:25 -0400 Russ Housley 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 > ietf-smime-oid-reg@imc.org 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 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h37L6RJM010364 for ; Mon, 7 Apr 2003 14:06:27 -0700 (PDT) Received: (from majordomo@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h37L6RTC010363 for ietf-smime-bks; Mon, 7 Apr 2003 14:06:27 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordomo set sender to owner-ietf-smime@mail.imc.org using -f Received: from woodstock.binhost.com (woodstock.binhost.com [207.228.252.5]) by above.proper.com (8.12.9/8.11.6) with SMTP id h37L6QJM010354 for ; Mon, 7 Apr 2003 14:06:26 -0700 (PDT) Received: (qmail 19847 invoked by uid 0); 7 Apr 2003 21:05:57 -0000 Received: from unknown (HELO Russ-Laptop.vigilsec.com) (141.156.187.144) by woodstock.binhost.com with SMTP; 7 Apr 2003 21:05:57 -0000 Message-Id: <5.2.0.9.2.20030407165009.025b4d18@mail.binhost.com> X-Sender: housley@mail.binhost.com X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Mon, 07 Apr 2003 17:06:25 -0400 To: From: Russ Housley Subject: Re: WG Last Call: draft-ietf-smime-camellia-02.txt In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: 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 ietf-smime-oid-reg@imc.org if you want it assigned from the S/MIME WG arc. Russ Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h33JxcJM007719 for ; Thu, 3 Apr 2003 11:59:38 -0800 (PST) Received: (from majordomo@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h33Jxctd007718 for ietf-smime-bks; Thu, 3 Apr 2003 11:59:38 -0800 (PST) X-Authentication-Warning: above.proper.com: majordomo set sender to owner-ietf-smime@mail.imc.org using -f Received: from woodstock.binhost.com (woodstock.binhost.com [207.228.252.5]) by above.proper.com (8.12.9/8.11.6) with SMTP id h33JxbJM007713 for ; Thu, 3 Apr 2003 11:59:37 -0800 (PST) Received: (qmail 8440 invoked by uid 0); 3 Apr 2003 19:59:08 -0000 Received: from unknown (HELO Russ-Laptop.vigilsec.com) (141.156.221.133) by woodstock.binhost.com with SMTP; 3 Apr 2003 19:59:08 -0000 Message-Id: <5.2.0.9.2.20030403145914.02b6b890@mail.binhost.com> X-Sender: housley@mail.binhost.com X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Thu, 03 Apr 2003 14:59:30 -0500 To: "Bonatti, Chris" , "'Blake Ramsdell'" , "'Pandey, Arun'" From: Russ Housley Subject: RE: Queries on Message/rfc822, Compressed-Data. Cc: ietf-smime@imc.org In-Reply-To: <002301c2f99b$1d855680$0300a8c0@ieca.com> References: < Mime-Version: 1.0 Content-Type: text/html; charset="us-ascii" Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Chris:

I assigned:

  id-eit-compressedData      OBJECT IDENTIFIER ::= { id-eit 7 }

Russ


At 11:40 PM 4/2/2003 -0500, Bonatti, Chris wrote:

I'll update the draft to assign the next available value.
 
Chris
 
 
-----Original Message-----
From: Blake Ramsdell [mailto:blake@brutesquadlabs.com]
Sent: Wednesday, April 02, 2003 20:09
To: 'Bonatti, Chris'; 'Pandey, Arun'; 'Russ Housley'
Cc: ietf-smime@imc.org
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: owner-ietf-smime@mail.imc.org [mailto:owner-ietf-smime@mail.imc.org] On Behalf Of Bonatti, Chris
Sent: Wednesday, April 02, 2003 3:17 PM
To: 'Pandey, Arun'; 'Russ Housley'
Cc: ietf-smime@imc.org
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: owner-ietf-smime@mail.imc.org [mailto:owner-ietf-smime@mail.imc.org] On Behalf Of Pandey, Arun
Sent: Tuesday, April 01, 2003 06:55
To: 'Russ Housley'
Cc: ietf-smime@imc.org
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:housley@vigilsec.com]
Sent: Thursday, March 27, 2003 1:33 AM
To: Pandey, Arun
Cc: ietf-smime@imc.org
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
Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h334ekJM024003 for ; Wed, 2 Apr 2003 20:40:46 -0800 (PST) Received: (from majordomo@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h334ekX7024002 for ietf-smime-bks; Wed, 2 Apr 2003 20:40:46 -0800 (PST) X-Authentication-Warning: above.proper.com: majordomo set sender to owner-ietf-smime@mail.imc.org using -f Received: from smtp-out.comcast.net (smtp-out.comcast.net [24.153.64.110]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h334eiJM023997 for ; Wed, 2 Apr 2003 20:40:45 -0800 (PST) Received: from Obsidian (pcp833859pcs.nrockv01.md.comcast.net [68.50.112.48]) by mtaout10.icomcast.net (iPlanet Messaging Server 5.2 HotFix 1.14 (built Mar 18 2003)) with ESMTP id <0HCR006SH3N018@mtaout10.icomcast.net> for ietf-smime@imc.org; Wed, 02 Apr 2003 23:40:13 -0500 (EST) Date: Wed, 02 Apr 2003 23:40:11 -0500 From: "Bonatti, Chris" Subject: RE: Queries on Message/rfc822, Compressed-Data. In-reply-to: To: "'Blake Ramsdell'" , "'Pandey, Arun'" , "'Russ Housley'" Cc: ietf-smime@imc.org Message-id: <002301c2f99b$1d855680$0300a8c0@ieca.com> Organization: IECA, Inc. MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Mailer: Microsoft Outlook, Build 10.0.2627 Content-type: multipart/alternative; boundary="Boundary_(ID_ri35ulTa+sfqoza4zDzFIg)" Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: 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:blake@brutesquadlabs.com] Sent: Wednesday, April 02, 2003 20:09 To: 'Bonatti, Chris'; 'Pandey, Arun'; 'Russ Housley' Cc: ietf-smime@imc.org 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: owner-ietf-smime@mail.imc.org [mailto:owner-ietf-smime@mail.imc.org] On Behalf Of Bonatti, Chris Sent: Wednesday, April 02, 2003 3:17 PM To: 'Pandey, Arun'; 'Russ Housley' Cc: ietf-smime@imc.org 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: owner-ietf-smime@mail.imc.org [mailto:owner-ietf-smime@mail.imc.org] On Behalf Of Pandey, Arun Sent: Tuesday, April 01, 2003 06:55 To: 'Russ Housley' Cc: ietf-smime@imc.org 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:housley@vigilsec.com] Sent: Thursday, March 27, 2003 1:33 AM To: Pandey, Arun Cc: ietf-smime@imc.org 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 Message
I'll update the draft to assign the next available value.
 
Chris
 
 
-----Original Message-----
From: Blake Ramsdell [mailto:blake@brutesquadlabs.com]
Sent: Wednesday, April 02, 2003 20:09
To: 'Bonatti, Chris'; 'Pandey, Arun'; 'Russ Housley'
Cc: ietf-smime@imc.org
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: owner-ietf-smime@mail.imc.org [mailto:owner-ietf-smime@mail.imc.org] On Behalf Of Bonatti, Chris
Sent: Wednesday, April 02, 2003 3:17 PM
To: 'Pandey, Arun'; 'Russ Housley'
Cc: ietf-smime@imc.org
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: owner-ietf-smime@mail.imc.org [mailto:owner-ietf-smime@mail.imc.org] On Behalf Of Pandey, Arun
Sent: Tuesday, April 01, 2003 06:55
To: 'Russ Housley'
Cc: ietf-smime@imc.org
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:housley@vigilsec.com]
Sent: Thursday, March 27, 2003 1:33 AM
To: Pandey, Arun
Cc: ietf-smime@imc.org
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)-- Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h3318ZJM015276 for ; Wed, 2 Apr 2003 17:08:35 -0800 (PST) Received: (from majordomo@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h3318Zhw015275 for ietf-smime-bks; Wed, 2 Apr 2003 17:08:35 -0800 (PST) X-Authentication-Warning: above.proper.com: majordomo set sender to owner-ietf-smime@mail.imc.org using -f Received: from brutesquadlabs.com (gtec136-m.isomedia.com [207.115.67.136] (may be forged)) by above.proper.com (8.12.9/8.11.6) with ESMTP id h3318YJM015270 for ; Wed, 2 Apr 2003 17:08:34 -0800 (PST) Received: from DEXTER ([192.168.0.4]) by brutesquadlabs.com with ESMTP ; Wed, 2 Apr 2003 17:08:31 -0800 From: "Blake Ramsdell" To: "'Bonatti, Chris'" , "'Pandey, Arun'" , "'Russ Housley'" Cc: Subject: RE: Queries on Message/rfc822, Compressed-Data. Date: Wed, 2 Apr 2003 17:08:31 -0800 Message-ID: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_009E_01C2F93A.7CC8D0B0" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2627 In-Reply-To: <002201c2f96d$fdaab5d0$0300a8c0@ieca.com> X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Importance: Normal Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: 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: owner-ietf-smime@mail.imc.org [mailto:owner-ietf-smime@mail.imc.org] On Behalf Of Bonatti, Chris Sent: Wednesday, April 02, 2003 3:17 PM To: 'Pandey, Arun'; 'Russ Housley' Cc: ietf-smime@imc.org 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: owner-ietf-smime@mail.imc.org [mailto:owner-ietf-smime@mail.imc.org] On Behalf Of Pandey, Arun Sent: Tuesday, April 01, 2003 06:55 To: 'Russ Housley' Cc: ietf-smime@imc.org 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:housley@vigilsec.com] Sent: Thursday, March 27, 2003 1:33 AM To: Pandey, Arun Cc: ietf-smime@imc.org 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 Message
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.
 
Blake
-----Original Message-----
From:=20 owner-ietf-smime@mail.imc.org [mailto:owner-ietf-smime@mail.imc.org] = On=20 Behalf Of Bonatti, Chris
Sent: Wednesday, April 02, 2003 = 3:17=20 PM
To: 'Pandey, Arun'; 'Russ Housley'
Cc:=20 ietf-smime@imc.org
Subject: RE: Queries on Message/rfc822,=20 Compressed-Data.

Yes,=20 this probably makes sense.
 
I=20 overlooked this because compressed-data was a draft when x400transport = was=20 drafted.  Since compressed-data is not in 2633bis it would = probably make=20 more sense to define the EIT for this in RFC 3274.  However, = there is=20 also benefit to all the X.400 stuff being here.  I suppose I = would favor=20 the latter.
 
Chris
 
 
 
-----Original Message-----
From:=20 owner-ietf-smime@mail.imc.org [mailto:owner-ietf-smime@mail.imc.org] = On=20 Behalf Of Pandey, Arun
Sent: Tuesday, April 01, 2003=20 06:55
To: 'Russ Housley'
Cc:=20 ietf-smime@imc.org
Subject: RE: Queries on Message/rfc822,=20 Compressed-Data.

 
Hi Russ,
 
As per=20 draft-ietf-smime-x400transport-05.txt to convey information = about the contained content =
of an S/MIME = message in an=20 X.400 transport environment = EITs are=20 used.
 
Section 2.5 (2.5.1 to = 2.5.6) of=20 draft-ietf-smime-x400transport-05.txt define the EITs = for:
1. Enveloped = Data
2. Signed = Data
3. Certificate=20 Management
4. Signed = Receipt
5. Enveloped = X.400
6. Signed = X.400
 
These match with the = corresponding=20 EITs defined in http://www.imc.org/ietf-smime/sm-oid.asn
-- X.400 Encoded = Information Types=20 (EIT) for S/MIME objects
id-eit-envelopedData = OBJECT=20 IDENTIFIER ::=3D { id-eit 1 }
id-eit-signedData = OBJECT IDENTIFIER=20 ::=3D { id-eit 2 }
id-eit-certManagement = OBJECT=20 IDENTIFIER ::=3D { id-eit 3 }
id-eit-signedReceipt = OBJECT=20 IDENTIFIER ::=3D { id-eit 4 }
id-eit-envelopedx400 = OBJECT=20 IDENTIFIER ::=3D { id-eit 5 }
id-eit-signedx400 = OBJECT IDENTIFIER=20 ::=3D { id-eit 6 }
 
I am unable to = find the corresponding EIT definition for = the=20 smime-type parameter
'compressed-data'(CompressedData),=20 that has been newly introduced in the 'draft-ietf-smime-
rfc2633bis-03.txt'.=20
 
Best = Regards
Arun = Pandey
 
-----Original Message-----
From: Russ Housley=20 [mailto:housley@vigilsec.com]
Sent: Thursday, March 27, = 2003 1:33=20 AM
To: Pandey, Arun
Cc:=20 ietf-smime@imc.org
Subject: Re: Queries on Message/rfc822, = Compressed-Data.

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

Russ

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

Hi,=20

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

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

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

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

Best Regards
Arun Pandey=20
------=_NextPart_000_009E_01C2F93A.7CC8D0B0-- Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h32NJ4JM009599 for ; Wed, 2 Apr 2003 15:19:04 -0800 (PST) Received: (from majordomo@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h32NJ4Bv009598 for ietf-smime-bks; Wed, 2 Apr 2003 15:19:04 -0800 (PST) X-Authentication-Warning: above.proper.com: majordomo set sender to owner-ietf-smime@mail.imc.org using -f Received: from smtp-out.comcast.net (smtp-out.comcast.net [24.153.64.115]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h32NIxJM009594 for ; Wed, 2 Apr 2003 15:18:59 -0800 (PST) Received: from Obsidian (pcp833859pcs.nrockv01.md.comcast.net [68.50.112.48]) by mtaout09.icomcast.net (iPlanet Messaging Server 5.2 HotFix 1.14 (built Mar 18 2003)) with ESMTP id <0HCQ001FKOON13@mtaout09.icomcast.net> for ietf-smime@imc.org; Wed, 02 Apr 2003 18:17:12 -0500 (EST) Date: Wed, 02 Apr 2003 18:17:11 -0500 From: "Bonatti, Chris" Subject: RE: Queries on Message/rfc822, Compressed-Data. In-reply-to: <177E503C4DA3D311BC9D0008C791C3060A0D258F@diexch01.xko.dec.com> To: "'Pandey, Arun'" , "'Russ Housley'" Cc: ietf-smime@imc.org Message-id: <002201c2f96d$fdaab5d0$0300a8c0@ieca.com> Organization: IECA, Inc. MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Mailer: Microsoft Outlook, Build 10.0.2627 Content-type: multipart/alternative; boundary="Boundary_(ID_IaiFkw0tCgVyiOUDv4m+2Q)" Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: 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: owner-ietf-smime@mail.imc.org [mailto:owner-ietf-smime@mail.imc.org] On Behalf Of Pandey, Arun Sent: Tuesday, April 01, 2003 06:55 To: 'Russ Housley' Cc: ietf-smime@imc.org 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:housley@vigilsec.com] Sent: Thursday, March 27, 2003 1:33 AM To: Pandey, Arun Cc: ietf-smime@imc.org 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 Message
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: owner-ietf-smime@mail.imc.org [mailto:owner-ietf-smime@mail.imc.org] On Behalf Of Pandey, Arun
Sent: Tuesday, April 01, 2003 06:55
To: 'Russ Housley'
Cc: ietf-smime@imc.org
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:housley@vigilsec.com]
Sent: Thursday, March 27, 2003 1:33 AM
To: Pandey, Arun
Cc: ietf-smime@imc.org
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)-- Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h31C0XJM016523 for ; Tue, 1 Apr 2003 04:00:33 -0800 (PST) Received: (from majordomo@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h31C0XRw016522 for ietf-smime-bks; Tue, 1 Apr 2003 04:00:33 -0800 (PST) X-Authentication-Warning: above.proper.com: majordomo set sender to owner-ietf-smime@mail.imc.org using -f Received: from zcamail05.zca.compaq.com (zcamail05.zca.compaq.com [161.114.32.105]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h31C0WJM016516 for ; Tue, 1 Apr 2003 04:00:33 -0800 (PST) Received: from taynzmail03.nz-tay.cpqcorp.net (taynzmail03.nz-tay.cpqcorp.net [16.47.4.103]) by zcamail05.zca.compaq.com (Postfix) with ESMTP id 3E77230F1; Tue, 1 Apr 2003 04:00:24 -0800 (PST) Received: from diexch01.xko.dec.com (diexch01.xko.dec.com [16.138.244.57]) by taynzmail03.nz-tay.cpqcorp.net (Postfix) with ESMTP id 73BE1EEF; Tue, 1 Apr 2003 07:00:21 -0500 (EST) Received: by diexch01.xko.dec.com with Internet Mail Service (5.5.2650.21) id <2A3P1GAZ>; Tue, 1 Apr 2003 17:25:19 +0530 Message-ID: <177E503C4DA3D311BC9D0008C791C3060A0D258F@diexch01.xko.dec.com> From: "Pandey, Arun" To: "'Russ Housley'" Cc: ietf-smime@imc.org Subject: RE: Queries on Message/rfc822, Compressed-Data. Date: Tue, 1 Apr 2003 17:25:13 +0530 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C2F845.90D9976A" Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: 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:housley@vigilsec.com] Sent: Thursday, March 27, 2003 1:33 AM To: Pandey, Arun Cc: ietf-smime@imc.org 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"
 
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:housley@vigilsec.com]
Sent: Thursday, March 27, 2003 1:33 AM
To: Pandey, Arun
Cc: ietf-smime@imc.org
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--