From owner-ietf-smime@mail.imc.org Mon Sep 1 04:05:58 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA01551 for ; Mon, 1 Sep 2003 04:05:58 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h817NDgc057825 for ; Mon, 1 Sep 2003 00:23:13 -0700 (PDT) (envelope-from owner-ietf-smime@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h817ND19057824 for ietf-smime-bks; Mon, 1 Sep 2003 00:23:13 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-smime@mail.imc.org using -f Received: from web11807.mail.yahoo.com (web11807.mail.yahoo.com [216.136.172.161]) by above.proper.com (8.12.9/8.12.8) with SMTP id h817NCgc057813 for ; Mon, 1 Sep 2003 00:23:12 -0700 (PDT) (envelope-from suchetsinghkhalsa@yahoo.com) Message-ID: <20030901072312.51857.qmail@web11807.mail.yahoo.com> Received: from [148.87.1.171] by web11807.mail.yahoo.com via HTTP; Mon, 01 Sep 2003 00:23:12 PDT Date: Mon, 1 Sep 2003 00:23:12 -0700 (PDT) From: suchet singh khalsa Subject: Re: RFC 2634 Questions To: phoffman@imc.org Cc: ietf-smime@imc.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Hi, Resending due to no response. Can anybody please help me with these questions... Thanks in advance, Suchet --- suchet singh khalsa wrote: > Hi Paul, > Can you please answer the following questions > w.r.t > MLA processing of S/MIME messages : > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > > According to RFC 2632, while verifying signatures it > should confirmed that the sender (RFC822 From or > Sender headers) of the message is the same as the > signed entity. Does this apply to ONLY the innermost > signature in a triple wrapped message ? > If no, this will impact MLA processing as documented > in RFC 2634 in the following manner : > > 1. The MLA creates an outermost SignedData layer > using the private key of the list. The final > recipient > will not be able to verify this signature since the > From header is not the list email address. Is the > solution here to set the list email address as the > RFC > 822 Sender header ? > > 2. Most MLA's support mail merge functionality. Is > the intent of RFC 2634 to mandate that S/MIME and > mail > merge do not go hand in hand ? The reason for this > question is : When MLA does mail merge, the > innermost > signature in a triple wrapped message will become > invalid - so the MLA will have to sign with the > private key of the list. So, the end recipient will > not be able to verify this signature since the From > header of the mail is not the list email address. > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > > RFC 2634 does not talk about this case : > An application/pkcs7-mime bodypart is enclosed in > another multipart, so that it is not the level 1 > bodypart. What should the MLA do in this case ? > Possibilities are : > 1. Create the outermost signature (according to > RFC2634 page 34) for the whole mail. > > 2. Create the outermost signature (according to > RFC2634 page 34) only for the application/pkcs7-mime > content. > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > > Thanks, > Suchet > > __________________________________ > Do you Yahoo!? > Yahoo! SiteBuilder - Free, easy-to-use web site > design software > http://sitebuilder.yahoo.com > __________________________________ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com From owner-ietf-smime@mail.imc.org Mon Sep 1 14:55:52 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA10723 for ; Mon, 1 Sep 2003 14:55:51 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h81IGtgc024358 for ; Mon, 1 Sep 2003 11:16:55 -0700 (PDT) (envelope-from owner-ietf-smime@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h81IGtWW024357 for ietf-smime-bks; Mon, 1 Sep 2003 11:16:55 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-smime@mail.imc.org using -f Received: from smtp3.pacifier.net (smtp3.pacifier.net [64.255.237.173]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h81IGsgc024352 for ; Mon, 1 Sep 2003 11:16:54 -0700 (PDT) (envelope-from jimsch@nwlink.com) Received: from ROMANS (ip237.c132.blk1.bel.nwlink.com [209.20.132.237]) by smtp3.pacifier.net (Postfix) with ESMTP id BE69D6D8C2; Mon, 1 Sep 2003 11:16:54 -0700 (PDT) Reply-To: From: "Jim Schaad" To: "'suchet singh khalsa'" Cc: Subject: RE: RFC 2634 Questions Date: Mon, 1 Sep 2003 11:17:39 -0700 Message-ID: <00a001c370b5$543f6c60$1400a8c0@augustcellars.local> 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.1165 In-Reply-To: <20030827165524.2132.qmail@web11803.mail.yahoo.com> Importance: Normal Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Suchet, The match of names only applies to the innermost layer on a triple wrapped message. I am not sure what you mean by a mail merge functionality. It could be one of two things: 1) merging a mail message with a database - in this case the correct person to sign the message is the MLA since that is the entity that actually sees the final message. 2) merging of multiple messages together in a summary. This could be done in a method that perserves the original signatures, but I would expect that they would actually be stripped. The types of MLAs that we are working with would not provide this type of feature. jim > -----Original Message----- > From: owner-ietf-smime@mail.imc.org > [mailto:owner-ietf-smime@mail.imc.org] On Behalf Of suchet > singh khalsa > Sent: Wednesday, August 27, 2003 9:55 AM > To: phoffman@imc.org > Cc: ietf-smime@imc.org > Subject: RFC 2634 Questions > > > > Hi Paul, > Can you please answer the following questions w.r.t > MLA processing of S/MIME messages : > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > > According to RFC 2632, while verifying signatures it > should confirmed that the sender (RFC822 From or > Sender headers) of the message is the same as the > signed entity. Does this apply to ONLY the innermost > signature in a triple wrapped message ? > If no, this will impact MLA processing as documented > in RFC 2634 in the following manner : > > 1. The MLA creates an outermost SignedData layer > using the private key of the list. The final recipient > will not be able to verify this signature since the > From header is not the list email address. Is the > solution here to set the list email address as the RFC > 822 Sender header ? > > 2. Most MLA's support mail merge functionality. Is > the intent of RFC 2634 to mandate that S/MIME and mail > merge do not go hand in hand ? The reason for this > question is : When MLA does mail merge, the innermost > signature in a triple wrapped message will become > invalid - so the MLA will have to sign with the > private key of the list. So, the end recipient will > not be able to verify this signature since the From > header of the mail is not the list email address. > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > > RFC 2634 does not talk about this case : > An application/pkcs7-mime bodypart is enclosed in > another multipart, so that it is not the level 1 > bodypart. What should the MLA do in this case ? > Possibilities are : > 1. Create the outermost signature (according to > RFC2634 page 34) for the whole mail. > > 2. Create the outermost signature (according to > RFC2634 page 34) only for the application/pkcs7-mime > content. > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > > Thanks, > Suchet > > __________________________________ > Do you Yahoo!? > Yahoo! SiteBuilder - Free, easy-to-use web site design > software http://sitebuilder.yahoo.com > From owner-ietf-smime@mail.imc.org Tue Sep 2 09:54:31 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA26434 for ; Tue, 2 Sep 2003 09:54:30 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h82DA4gc010786 for ; Tue, 2 Sep 2003 06:10:04 -0700 (PDT) (envelope-from owner-ietf-smime@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h82DA30t010785 for ietf-smime-bks; Tue, 2 Sep 2003 06:10:03 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-smime@mail.imc.org using -f Received: from smtp1.fre.skanova.net (smtp1.fre.skanova.net [195.67.227.94]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h82D9xgc010761; Tue, 2 Sep 2003 06:10:02 -0700 (PDT) (envelope-from anders.rundgren@telia.com) Received: from arport (t7o913p37.telia.com [213.64.26.37]) by smtp1.fre.skanova.net (8.12.9/8.12.9) with SMTP id h82D9tit005555; Tue, 2 Sep 2003 15:09:56 +0200 (CEST) Message-ID: <001501c37153$4ff1d960$0500a8c0@arport> From: "Anders Rundgren" To: , , Subject: Standards for Web-signing Date: Tue, 2 Sep 2003 15:07:33 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Folks, I just wanted to know the status of possible standardization efforts regarding signing on-line forms etc. on web. As web-signing is a core function of many e-governments when communicating with their citizens it seems that this should be standardized if not already is. Pointers are welcome. Off-list or on-list. rgds Anders Rundgren From owner-ietf-smime@mail.imc.org Fri Sep 5 13:59:05 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA09326 for ; Fri, 5 Sep 2003 13:59:05 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h85HLrgc052816 for ; Fri, 5 Sep 2003 10:21:53 -0700 (PDT) (envelope-from owner-ietf-smime@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h85HLrJu052815 for ietf-smime-bks; Fri, 5 Sep 2003 10:21:53 -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.9/8.12.8) with SMTP id h85HLqgc052810 for ; Fri, 5 Sep 2003 10:21:52 -0700 (PDT) (envelope-from housley@vigilsec.com) Received: (qmail 30687 invoked by uid 0); 5 Sep 2003 17:21:44 -0000 Received: from unknown (HELO Russ-Laptop.vigilsec.com) (63.119.245.67) by woodstock.binhost.com with SMTP; 5 Sep 2003 17:21:44 -0000 Message-Id: <5.2.0.9.2.20030905131424.044584f0@mail.binhost.com> X-Sender: housley@mail.binhost.com X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Fri, 05 Sep 2003 13:21:46 -0400 To: , "'suchet singh khalsa'" From: Russ Housley Subject: RE: RFC 2634 Questions Cc: In-Reply-To: <00a001c370b5$543f6c60$1400a8c0@augustcellars.local> References: <20030827165524.2132.qmail@web11803.mail.yahoo.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: Jim: What about mail lists that contain other MLAs? Consider: Originator --> MLA1 --> MLA2 --> Recipient When the message gets to the recipient, the outer signature belongs to the MLA2, and the inner signature belongs to the original Originator. The FROM address should indicate MLA2. Russ At 11:17 AM 9/1/2003 -0700, Jim Schaad wrote: >Suchet, > >The match of names only applies to the innermost layer on a triple >wrapped message. > >I am not sure what you mean by a mail merge functionality. It could be >one of two things: >1) merging a mail message with a database - in this case the correct >person to sign the message is the MLA since that is the entity that >actually sees the final message. >2) merging of multiple messages together in a summary. This could be >done in a method that perserves the original signatures, but I would >expect that they would actually be stripped. The types of MLAs that we >are working with would not provide this type of feature. > >jim > > > -----Original Message----- > > From: owner-ietf-smime@mail.imc.org > > [mailto:owner-ietf-smime@mail.imc.org] On Behalf Of suchet > > singh khalsa > > Sent: Wednesday, August 27, 2003 9:55 AM > > To: phoffman@imc.org > > Cc: ietf-smime@imc.org > > Subject: RFC 2634 Questions > > > > > > > > Hi Paul, > > Can you please answer the following questions w.r.t > > MLA processing of S/MIME messages : > > > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > > > > According to RFC 2632, while verifying signatures it > > should confirmed that the sender (RFC822 From or > > Sender headers) of the message is the same as the > > signed entity. Does this apply to ONLY the innermost > > signature in a triple wrapped message ? > > If no, this will impact MLA processing as documented > > in RFC 2634 in the following manner : > > > > 1. The MLA creates an outermost SignedData layer > > using the private key of the list. The final recipient > > will not be able to verify this signature since the > > From header is not the list email address. Is the > > solution here to set the list email address as the RFC > > 822 Sender header ? > > > > 2. Most MLA's support mail merge functionality. Is > > the intent of RFC 2634 to mandate that S/MIME and mail > > merge do not go hand in hand ? The reason for this > > question is : When MLA does mail merge, the innermost > > signature in a triple wrapped message will become > > invalid - so the MLA will have to sign with the > > private key of the list. So, the end recipient will > > not be able to verify this signature since the From > > header of the mail is not the list email address. > > > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > > > > RFC 2634 does not talk about this case : > > An application/pkcs7-mime bodypart is enclosed in > > another multipart, so that it is not the level 1 > > bodypart. What should the MLA do in this case ? > > Possibilities are : > > 1. Create the outermost signature (according to > > RFC2634 page 34) for the whole mail. > > > > 2. Create the outermost signature (according to > > RFC2634 page 34) only for the application/pkcs7-mime > > content. > > > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > > > > Thanks, > > Suchet > > > > __________________________________ > > Do you Yahoo!? > > Yahoo! SiteBuilder - Free, easy-to-use web site design > > software http://sitebuilder.yahoo.com > > From owner-ietf-smime@mail.imc.org Fri Sep 5 14:58:22 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA12355 for ; Fri, 5 Sep 2003 14:58:22 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h85IO9gc055712 for ; Fri, 5 Sep 2003 11:24:09 -0700 (PDT) (envelope-from owner-ietf-smime@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h85IO9WX055711 for ietf-smime-bks; Fri, 5 Sep 2003 11:24:09 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-smime@mail.imc.org using -f Received: from smtp4.pacifier.net (smtp4.pacifier.net [64.255.237.174]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h85IO8gc055706 for ; Fri, 5 Sep 2003 11:24:08 -0700 (PDT) (envelope-from jimsch@nwlink.com) Received: from ROMANS (ip237.c132.blk1.bel.nwlink.com [209.20.132.237]) by smtp4.pacifier.net (Postfix) with ESMTP id 212616A990; Fri, 5 Sep 2003 11:20:34 -0700 (PDT) Reply-To: From: "Jim Schaad" To: "'Russ Housley'" , "'suchet singh khalsa'" Cc: Subject: RE: RFC 2634 Questions Date: Fri, 5 Sep 2003 11:25:01 -0700 Message-ID: <000f01c373db$20a32260$1400a8c0@augustcellars.local> 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.1165 Importance: Normal In-Reply-To: <5.2.0.9.2.20030905131424.044584f0@mail.binhost.com> Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Russ, While the FROM adddress indicates MLA2, the Sender address would still indicate the original sender. That is name that would then be matched. jim > -----Original Message----- > From: Russ Housley [mailto:housley@vigilsec.com] > Sent: Friday, September 05, 2003 10:22 AM > To: jimsch@exmsft.com; 'suchet singh khalsa' > Cc: ietf-smime@imc.org > Subject: RE: RFC 2634 Questions > > > Jim: > > What about mail lists that contain other MLAs? Consider: > > Originator --> MLA1 --> MLA2 --> Recipient > > When the message gets to the recipient, the outer signature > belongs to the > MLA2, and the inner signature belongs to the original > Originator. The FROM > address should indicate MLA2. > > Russ > > At 11:17 AM 9/1/2003 -0700, Jim Schaad wrote: > > >Suchet, > > > >The match of names only applies to the innermost layer on a triple > >wrapped message. > > > >I am not sure what you mean by a mail merge functionality. > It could be > >one of two things: > >1) merging a mail message with a database - in this case the correct > >person to sign the message is the MLA since that is the entity that > >actually sees the final message. > >2) merging of multiple messages together in a summary. This > could be > >done in a method that perserves the original signatures, but I would > >expect that they would actually be stripped. The types of > MLAs that we > >are working with would not provide this type of feature. > > > >jim > > > > > -----Original Message----- > > > From: owner-ietf-smime@mail.imc.org > > > [mailto:owner-ietf-smime@mail.imc.org] On Behalf Of suchet singh > > > khalsa > > > Sent: Wednesday, August 27, 2003 9:55 AM > > > To: phoffman@imc.org > > > Cc: ietf-smime@imc.org > > > Subject: RFC 2634 Questions > > > > > > > > > > > > Hi Paul, > > > Can you please answer the following questions w.r.t > > > MLA processing of S/MIME messages : > > > > > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > > > > > > According to RFC 2632, while verifying signatures it > > > should confirmed that the sender (RFC822 From or > > > Sender headers) of the message is the same as the > > > signed entity. Does this apply to ONLY the innermost > signature in a > > > triple wrapped message ? If no, this will impact MLA > processing as > > > documented in RFC 2634 in the following manner : > > > > > > 1. The MLA creates an outermost SignedData layer > > > using the private key of the list. The final recipient > > > will not be able to verify this signature since the > > > From header is not the list email address. Is the > > > solution here to set the list email address as the RFC > > > 822 Sender header ? > > > > > > 2. Most MLA's support mail merge functionality. Is > > > the intent of RFC 2634 to mandate that S/MIME and mail > merge do not > > > go hand in hand ? The reason for this question is : When MLA does > > > mail merge, the innermost signature in a triple wrapped > message will > > > become invalid - so the MLA will have to sign with the > > > private key of the list. So, the end recipient will > > > not be able to verify this signature since the From > > > header of the mail is not the list email address. > > > > > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > > > > > > RFC 2634 does not talk about this case : > > > An application/pkcs7-mime bodypart is enclosed in > > > another multipart, so that it is not the level 1 > > > bodypart. What should the MLA do in this case ? > Possibilities are : > > > 1. Create the outermost signature (according to > > > RFC2634 page 34) for the whole mail. > > > > > > 2. Create the outermost signature (according to > > > RFC2634 page 34) only for the application/pkcs7-mime content. > > > > > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > > > > > > Thanks, > > > Suchet > > > > > > __________________________________ > > > Do you Yahoo!? > > > Yahoo! SiteBuilder - Free, easy-to-use web site design software > > > http://sitebuilder.yahoo.com > > > > From owner-ietf-smime@mail.imc.org Sat Sep 6 12:34:11 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA23046 for ; Sat, 6 Sep 2003 12:34:10 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h86FxWgc064496 for ; Sat, 6 Sep 2003 08:59:32 -0700 (PDT) (envelope-from owner-ietf-smime@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h86FxWLI064495 for ietf-smime-bks; Sat, 6 Sep 2003 08:59:32 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-smime@mail.imc.org using -f Received: from web11807.mail.yahoo.com (web11807.mail.yahoo.com [216.136.172.161]) by above.proper.com (8.12.9/8.12.8) with SMTP id h86FxVgc064490 for ; Sat, 6 Sep 2003 08:59:31 -0700 (PDT) (envelope-from suchetsinghkhalsa@yahoo.com) Message-ID: <20030906155932.58817.qmail@web11807.mail.yahoo.com> Received: from [148.87.1.171] by web11807.mail.yahoo.com via HTTP; Sat, 06 Sep 2003 08:59:32 PDT Date: Sat, 6 Sep 2003 08:59:32 -0700 (PDT) From: suchet singh khalsa Subject: RE: RFC 2634 Questions To: jimsch@exmsft.com Cc: ietf-smime@imc.org, housley@vigilsec.com In-Reply-To: <000f01c373db$20a32260$1400a8c0@augustcellars.local> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Jim, Do you not think the following is more appropriate : 1. The RFC 822 FROM header should always remain unchanged. It should always show the originator of the mail. 2. The RFC 822 SENDER should be replaced to contain the email address of the list of which the current recipient is the member. In the case proposed by Russ, this header will contain the email address of the nested list. Also, you said earlier "The match of names only applies to the innermost layer on a triple wrapped message." Although this is a very practical and common sensical conclusion, and I agree with it, I do not find it mentioned anywhere in the RFC's. So, are there/can there be Mail User Agents out there which may try to match RFC822 From and Sender headers with the outer signature ? Can you also please answer this question : An application/pkcs7-mime bodypart is enclosed in another multipart, so that it is not the level 1 bodypart. What should the MLA do in this case ? Possibilities are : 1. Create the outermost signature (according to RFC2634 page 34) for the whole mail. 2. Create the outermost signature (according to RFC2634 page 34) only for the application/pkcs7-mime content. The unsigned content is left unsigned. Thanks, Suchet --- Jim Schaad wrote: > Russ, > > While the FROM adddress indicates MLA2, the Sender > address would still > indicate the original sender. That is name that > would then be matched. > > jim > > > -----Original Message----- > > From: Russ Housley [mailto:housley@vigilsec.com] > > Sent: Friday, September 05, 2003 10:22 AM > > To: jimsch@exmsft.com; 'suchet singh khalsa' > > Cc: ietf-smime@imc.org > > Subject: RE: RFC 2634 Questions > > > > > > Jim: > > > > What about mail lists that contain other MLAs? > Consider: > > > > Originator --> MLA1 --> MLA2 --> Recipient > > > > When the message gets to the recipient, the outer > signature > > belongs to the > > MLA2, and the inner signature belongs to the > original > > Originator. The FROM > > address should indicate MLA2. > > > > Russ > > > > At 11:17 AM 9/1/2003 -0700, Jim Schaad wrote: > > > > >Suchet, > > > > > >The match of names only applies to the innermost > layer on a triple > > >wrapped message. > > > > > >I am not sure what you mean by a mail merge > functionality. > > It could be > > >one of two things: > > >1) merging a mail message with a database - in > this case the correct > > >person to sign the message is the MLA since that > is the entity that > > >actually sees the final message. > > >2) merging of multiple messages together in a > summary. This > > could be > > >done in a method that perserves the original > signatures, but I would > > >expect that they would actually be stripped. The > types of > > MLAs that we > > >are working with would not provide this type of > feature. > > > > > >jim > > > > > > > -----Original Message----- > > > > From: owner-ietf-smime@mail.imc.org > > > > [mailto:owner-ietf-smime@mail.imc.org] On > Behalf Of suchet singh > > > > khalsa > > > > Sent: Wednesday, August 27, 2003 9:55 AM > > > > To: phoffman@imc.org > > > > Cc: ietf-smime@imc.org > > > > Subject: RFC 2634 Questions > > > > > > > > > > > > > > > > Hi Paul, > > > > Can you please answer the following > questions w.r.t > > > > MLA processing of S/MIME messages : > > > > > > > > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > > > > > > > > According to RFC 2632, while verifying > signatures it > > > > should confirmed that the sender (RFC822 From > or > > > > Sender headers) of the message is the same as > the > > > > signed entity. Does this apply to ONLY the > innermost > > signature in a > > > > triple wrapped message ? If no, this will > impact MLA > > processing as > > > > documented in RFC 2634 in the following manner > : > > > > > > > > 1. The MLA creates an outermost SignedData > layer > > > > using the private key of the list. The final > recipient > > > > will not be able to verify this signature > since the > > > > From header is not the list email address. Is > the > > > > solution here to set the list email address as > the RFC > > > > 822 Sender header ? > > > > > > > > 2. Most MLA's support mail merge > functionality. Is > > > > the intent of RFC 2634 to mandate that S/MIME > and mail > > merge do not > > > > go hand in hand ? The reason for this question > is : When MLA does > > > > mail merge, the innermost signature in a > triple wrapped > > message will > > > > become invalid - so the MLA will have to sign > with the > > > > private key of the list. So, the end recipient > will > > > > not be able to verify this signature since the > From > > > > header of the mail is not the list email > address. > > > > > > > > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > > > > > > > > RFC 2634 does not talk about this case : > > > > An application/pkcs7-mime bodypart is enclosed > in > > > > another multipart, so that it is not the level > 1 > > > > bodypart. What should the MLA do in this case > ? > > Possibilities are : > > > > 1. Create the outermost signature (according > to > > > > RFC2634 page 34) for the whole mail. > > > > > > > > 2. Create the outermost signature (according > to > > > > RFC2634 page 34) only for the > application/pkcs7-mime content. > > > > > > > > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > > > > > > > > Thanks, > > > > Suchet > > > > > > > > __________________________________ > > > > Do you Yahoo!? > > > > Yahoo! SiteBuilder - Free, easy-to-use web > site design software > > > > http://sitebuilder.yahoo.com > > > > > > > __________________________________ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com From owner-ietf-smime@mail.imc.org Sat Sep 6 18:58:10 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA10691 for ; Sat, 6 Sep 2003 18:58:09 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h86MM4gc083475 for ; Sat, 6 Sep 2003 15:22:04 -0700 (PDT) (envelope-from owner-ietf-smime@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h86MM4XX083474 for ietf-smime-bks; Sat, 6 Sep 2003 15:22:04 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-smime@mail.imc.org using -f Received: from smtp1.pacifier.net (smtp1.pacifier.net [64.255.237.171]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h86MM3gc083469 for ; Sat, 6 Sep 2003 15:22:03 -0700 (PDT) (envelope-from jimsch@nwlink.com) Received: from ROMANS (ip237.c132.blk1.bel.nwlink.com [209.20.132.237]) by smtp1.pacifier.net (Postfix) with ESMTP id A9796701A1; Sat, 6 Sep 2003 15:22:03 -0700 (PDT) Reply-To: From: "Jim Schaad" To: "'suchet singh khalsa'" , Cc: , Subject: RE: RFC 2634 Questions Date: Sat, 6 Sep 2003 15:23:42 -0700 Message-ID: <006101c374c5$87e88dd0$1400a8c0@augustcellars.local> 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.1165 Importance: Normal In-Reply-To: <20030906155932.58817.qmail@web11807.mail.yahoo.com> Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Suchet, > -----Original Message----- > From: owner-ietf-smime@mail.imc.org > [mailto:owner-ietf-smime@mail.imc.org] On Behalf Of suchet > singh khalsa > Sent: Saturday, September 06, 2003 9:00 AM > To: jimsch@exmsft.com > Cc: ietf-smime@imc.org; housley@vigilsec.com > Subject: RE: RFC 2634 Questions > > > > Jim, > Do you not think the following is more appropriate > : > 1. The RFC 822 FROM header should always remain > unchanged. It should always show the originator of the > mail. > 2. The RFC 822 SENDER should be replaced to contain > the email address of the list of which the current > recipient is the member. In the case proposed by Russ, > this header will contain the email address of the > nested list. Yes this probably makes more sense. I tend to get this type of detail mixed up because this has never been my focus. However I have seen these types of things mixed up before so... > > Also, you said earlier "The match of names only > applies to the innermost layer on a triple wrapped > message." > Although this is a very practical and common sensical > conclusion, and I agree with it, I do not find it mentioned > anywhere in the RFC's. So, are there/can there be Mail User > Agents out there which may try to match RFC822 From and > Sender headers with the outer signature ? Item for the update of RFC 2634 > > Can you also please answer this question : > An application/pkcs7-mime bodypart is enclosed in > another multipart, so that it is not the level 1 > bodypart. What should the MLA do in this case ? > Possibilities are : > 1. Create the outermost signature (according to > RFC2634 page 34) for the whole mail. > 2. Create the outermost signature (according to > RFC2634 page 34) only for the application/pkcs7-mime > content. The unsigned content is left unsigned. I would expect that the MLA would just add a new outermost signature on the entire message and ignore the fact that some inner layer has some security applied to it. I would also expect that most (if not all) MUAs would not correctly display information about this embedded signature. The MUAs that I have developed in the past would decrypt such an item, but would not look at it for signature verification. I would expect that this type of embedded signatures would be used more in work flow applications where a different type of MLA would be developed explicitly for that purpose. jim > > Thanks, > Suchet > > --- Jim Schaad wrote: > > Russ, > > > > While the FROM adddress indicates MLA2, the Sender > > address would still > > indicate the original sender. That is name that > > would then be matched. > > > > jim > > > > > -----Original Message----- > > > From: Russ Housley [mailto:housley@vigilsec.com] > > > Sent: Friday, September 05, 2003 10:22 AM > > > To: jimsch@exmsft.com; 'suchet singh khalsa' > > > Cc: ietf-smime@imc.org > > > Subject: RE: RFC 2634 Questions > > > > > > > > > Jim: > > > > > > What about mail lists that contain other MLAs? > > Consider: > > > > > > Originator --> MLA1 --> MLA2 --> Recipient > > > > > > When the message gets to the recipient, the outer > > signature > > > belongs to the > > > MLA2, and the inner signature belongs to the > > original > > > Originator. The FROM > > > address should indicate MLA2. > > > > > > Russ > > > > > > At 11:17 AM 9/1/2003 -0700, Jim Schaad wrote: > > > > > > >Suchet, > > > > > > > >The match of names only applies to the innermost > > layer on a triple > > > >wrapped message. > > > > > > > >I am not sure what you mean by a mail merge > > functionality. > > > It could be > > > >one of two things: > > > >1) merging a mail message with a database - in > > this case the correct > > > >person to sign the message is the MLA since that > > is the entity that > > > >actually sees the final message. > > > >2) merging of multiple messages together in a > > summary. This > > > could be > > > >done in a method that perserves the original > > signatures, but I would > > > >expect that they would actually be stripped. The > > types of > > > MLAs that we > > > >are working with would not provide this type of > > feature. > > > > > > > >jim > > > > > > > > > -----Original Message----- > > > > > From: owner-ietf-smime@mail.imc.org > > > > > [mailto:owner-ietf-smime@mail.imc.org] On > > Behalf Of suchet singh > > > > > khalsa > > > > > Sent: Wednesday, August 27, 2003 9:55 AM > > > > > To: phoffman@imc.org > > > > > Cc: ietf-smime@imc.org > > > > > Subject: RFC 2634 Questions > > > > > > > > > > > > > > > > > > > > Hi Paul, > > > > > Can you please answer the following > > questions w.r.t > > > > > MLA processing of S/MIME messages : > > > > > > > > > > > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > > > > > > > > > > According to RFC 2632, while verifying > > signatures it > > > > > should confirmed that the sender (RFC822 From > > or > > > > > Sender headers) of the message is the same as > > the > > > > > signed entity. Does this apply to ONLY the > > innermost > > > signature in a > > > > > triple wrapped message ? If no, this will > > impact MLA > > > processing as > > > > > documented in RFC 2634 in the following manner > > : > > > > > > > > > > 1. The MLA creates an outermost SignedData > > layer > > > > > using the private key of the list. The final > > recipient > > > > > will not be able to verify this signature > > since the > > > > > From header is not the list email address. Is > > the > > > > > solution here to set the list email address as > > the RFC > > > > > 822 Sender header ? > > > > > > > > > > 2. Most MLA's support mail merge > > functionality. Is > > > > > the intent of RFC 2634 to mandate that S/MIME > > and mail > > > merge do not > > > > > go hand in hand ? The reason for this question > > is : When MLA does > > > > > mail merge, the innermost signature in a > > triple wrapped > > > message will > > > > > become invalid - so the MLA will have to sign > > with the > > > > > private key of the list. So, the end recipient > > will > > > > > not be able to verify this signature since the > > From > > > > > header of the mail is not the list email > > address. > > > > > > > > > > > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > > > > > > > > > > RFC 2634 does not talk about this case : > > > > > An application/pkcs7-mime bodypart is enclosed > > in > > > > > another multipart, so that it is not the level > > 1 > > > > > bodypart. What should the MLA do in this case > > ? > > > Possibilities are : > > > > > 1. Create the outermost signature (according > > to > > > > > RFC2634 page 34) for the whole mail. > > > > > > > > > > 2. Create the outermost signature (according > > to > > > > > RFC2634 page 34) only for the > > application/pkcs7-mime content. > > > > > > > > > > > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > > > > > > > > > > Thanks, > > > > > Suchet > > > > > > > > > > __________________________________ > > > > > Do you Yahoo!? > > > > > Yahoo! SiteBuilder - Free, easy-to-use web > > site design software > > > > > http://sitebuilder.yahoo.com > > > > > > > > > > > > > __________________________________ > Do you Yahoo!? > Yahoo! SiteBuilder - Free, easy-to-use web site design > software http://sitebuilder.yahoo.com > From owner-ietf-smime@mail.imc.org Wed Sep 10 21:14:22 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA25837 for ; Wed, 10 Sep 2003 21:14:22 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h8B0lgeo060109 for ; Wed, 10 Sep 2003 17:47:42 -0700 (PDT) (envelope-from owner-ietf-smime@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h8B0lgKD060108 for ietf-smime-bks; Wed, 10 Sep 2003 17:47:42 -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.9/8.12.8) with SMTP id h8B0lfeo060103 for ; Wed, 10 Sep 2003 17:47:41 -0700 (PDT) (envelope-from housley@vigilsec.com) Received: (qmail 3901 invoked by uid 0); 11 Sep 2003 00:47:33 -0000 Received: from unknown (HELO Russ-Laptop.vigilsec.com) (151.200.247.144) by woodstock.binhost.com with SMTP; 11 Sep 2003 00:47:33 -0000 Message-Id: <5.2.0.9.2.20030910163325.048e8ea8@mail.binhost.com> X-Sender: housley@mail.binhost.com X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Wed, 10 Sep 2003 16:37:59 -0400 To: Darrell.Dykstra@entrust.com, ietf-smime@imc.org From: Russ Housley Subject: RE: Determining if a message has multiple layers without processing any of them 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: Darrell: Please take a look at RFC 2634, section 2.9. The outer-most CMS wrapper should tell what content type is contained in the inner-most wrapper. Does this help, even though it is much delayed? Russ -----Original Message----- From: owner-ietf-smime@mail.imc.org [mailto:owner-ietf-smime@mail.imc.org] Sent: Saturday, June 14, 2003 7:43 AM To: 'ietf-smime@imc.org' Subject: Determining if a message has multiple layers without processing any of them Hello, I am currently attempting to determine if there is anything in the S/MIME standard that would allow me to determine if a message was, for example, signed then encrypted, without processing any of the security layers. My understanding of the smime-type parameter is that it only applies to the current layer of security, so for example, a message that was signed and then encrypted will have an outer smime-type of enveloped-data with no clue that there is a signature layer within. Any insight into this is much appreciated. Thanks, Darrell From owner-ietf-smime@mail.imc.org Wed Sep 10 23:01:34 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA27684 for ; Wed, 10 Sep 2003 23:01:33 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h8B2bBeo064001 for ; Wed, 10 Sep 2003 19:37:11 -0700 (PDT) (envelope-from owner-ietf-smime@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h8B2bBsm064000 for ietf-smime-bks; Wed, 10 Sep 2003 19:37:11 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-smime@mail.imc.org using -f Received: from sottmxssm.entrust.com (sottmxssm.entrust.com [216.191.252.10]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h8B2bAeo063987 for ; Wed, 10 Sep 2003 19:37:11 -0700 (PDT) (envelope-from Darrell.Dykstra@entrust.com) Received: from sottguard01.entrust.com (sottguard01.entrust.com [10.4.61.249]) by sottmxssm.entrust.com (Switch-2.2.6/Switch-2.2.4) with SMTP id V8B20X9U05053 for ; Wed, 10 Sep 2003 22:33:09 -0400 Received: (qmail 23371 invoked by uid 64014); 11 Sep 2003 02:28:24 -0000 Received: from Darrell.Dykstra@entrust.com by sottguard01.entrust.com with AmikaGuardian-Server-1.1.2 (Processed in 0.41397 secs); 11 Sep 2003 02:28:24 -0000 Received: from unknown (HELO SOTTMXS01.entrust.com) (10.4.61.7) by sottguard01.entrust.com with SMTP; 11 Sep 2003 02:28:23 -0000 Received: by sottmxs01.entrust.com with Internet Mail Service (5.5.2656.59) id ; Wed, 10 Sep 2003 22:37:06 -0400 Message-ID: From: Darrell Dykstra To: "'Russ Housley'" , ietf-smime@imc.org Subject: RE: Determining if a message has multiple layers without processi ng any of them Date: Wed, 10 Sep 2003 22:37:06 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: text/plain Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Russ, Any reply helps, as it opens up valuable discussion on how various implementers use the standard. In my case, I was looking for a MIME parameter to identify cryptographic message construction beyond the outermost layer. Such a mechanism would permit software to distinguish, for example, encrypted messages from signed then encrypted messages, without having to do any expensive cryptographic processing (and without having to transfer the cryptographic attachment from a remote folder). I guess what I was hoping for was an smime-type value that could represent multiple S/MIME layers. ContentHint doesn't meet the requirements as it is a signedAttribute and would require at least some cryptographic processing to obtain. Furthermore, a signedAttribute does not help in the case where the outer layer is an encryption layer. Adding an extra outer signature layer for the sake of including a ContentHint may be prohibitive with respect to overall message size. I do appreciate the response. Thank you. Darrell -----Original Message----- From: Russ Housley [mailto:housley@vigilsec.com] Sent: Wednesday, September 10, 2003 4:38 PM To: Darrell.Dykstra@entrust.com; ietf-smime@imc.org Subject: RE: Determining if a message has multiple layers without processing any of them Darrell: Please take a look at RFC 2634, section 2.9. The outer-most CMS wrapper should tell what content type is contained in the inner-most wrapper. Does this help, even though it is much delayed? Russ -----Original Message----- From: owner-ietf-smime@mail.imc.org [mailto:owner-ietf-smime@mail.imc.org] Sent: Saturday, June 14, 2003 7:43 AM To: 'ietf-smime@imc.org' Subject: Determining if a message has multiple layers without processing any of them Hello, I am currently attempting to determine if there is anything in the S/MIME standard that would allow me to determine if a message was, for example, signed then encrypted, without processing any of the security layers. My understanding of the smime-type parameter is that it only applies to the current layer of security, so for example, a message that was signed and then encrypted will have an outer smime-type of enveloped-data with no clue that there is a signature layer within. Any insight into this is much appreciated. Thanks, Darrell From KANDY_BATDORF@yahoo.ca Sun Sep 14 18:57:50 2003 Received: from YOUR-196PM56P6G (bquijx@h0040ca30f844.ne.client2.attbi.com [24.147.131.164]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA17209 for ; Sun, 14 Sep 2003 18:57:50 -0400 (EDT) Message-Id: <200309142257.SAA17209@ietf.org> From: "guess" To: "smime-archive@ietf.org" Subject: Hello Date: Sun, 14 Sep 2003 18:57:47 -0400 X-Priority: 3 (normal) Importance: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) MIME-Version: 1.0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: base64 Content-Transfer-Encoding: base64 PGh0bWw+DQpIaSw8YnI+DQpJIGtuPCEtLWZkanNpYXU4OTQzLS0+b3cgeW91IHdhbnQgdG8gcmU8 IS0tcmFuZDItLT5maW5hPCEtLTM0ajg5cDFkc2E4ai0tPm5jZSB5b3VyIGhvbWUgc28gPGJyPg0K aGVyZSBpcyB0aGUgd2U8IS0tZ2Y2N2dhazEtLT5ic2l0ZSB5b3Ugd2E8IS0tNDMyMXk0dTMtLT5u dGVkIHdoZXJlIGxlPCEtLWVtaWx5LS0+bmRlcnMgPGJyPg0KY29tPCEtLW1pY2tleS0tPnBldGUg Zm9yIHlvdXIgYnU8IS0tcmFjaGVsLS0+c2luZXNzLjxicj4NCjxhIGhyZWY9Imh0dHA6Ly93d3cu ZmRqc2lhdTg5NDMuZmxpcHBpbmRlYWxzLmNvbSI+IEdvIEhlcmUgPC9hPjxicj4NClRoPCEtLXJh bmQyLS0+YW5rcyw8YnI+DQpKYWNrIEpvaDwhLS1nZjY3Z2FrMS0tPm5zb248YnI+DQo8YnI+DQo8 YnI+DQo8IS0tcmFjaGVsLS0+DQo8L2h0bWw+DQo= From owner-ietf-smime@mail.imc.org Mon Sep 15 10:36:01 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA05008 for ; Mon, 15 Sep 2003 10:36:00 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h8FEBseo057001 for ; Mon, 15 Sep 2003 07:11:54 -0700 (PDT) (envelope-from owner-ietf-smime@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h8FEBsck057000 for ietf-smime-bks; Mon, 15 Sep 2003 07:11:54 -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.9/8.12.8) with ESMTP id h8FEBreo056991 for ; Mon, 15 Sep 2003 07:11:53 -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 KAA02012; Mon, 15 Sep 2003 10:11:48 -0400 (EDT) Message-Id: <200309151411.KAA02012@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-05.txt Date: Mon, 15 Sep 2003 10:11:47 -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-05.txt Pages : 12 Date : 2003-9-15 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-05.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-smime-camellia-05.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-smime-camellia-05.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-9-15100512.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-smime-camellia-05.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-smime-camellia-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-9-15100512.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ietf-smime@mail.imc.org Mon Sep 15 16:54:09 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA25785 for ; Mon, 15 Sep 2003 16:54:09 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h8FKHjeo082651 for ; Mon, 15 Sep 2003 13:17:45 -0700 (PDT) (envelope-from owner-ietf-smime@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h8FKHjLS082650 for ietf-smime-bks; Mon, 15 Sep 2003 13:17:45 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-smime@mail.imc.org using -f Received: from mail2-atl-R.bigfish.com (mail-orl.bigfish.com [63.161.60.61]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h8FKHieo082645 for ; Mon, 15 Sep 2003 13:17:44 -0700 (PDT) (envelope-from internet-drafts@ietf.org) Received: from mail2-atl.bigfish.com (localhost.localdomain [127.0.0.1]) by mail2-atl-R.bigfish.com (Postfix) with ESMTP id 17D3AA3690 for ; Mon, 15 Sep 2003 20:17:40 +0000 (UTC) Received: by mail2-atl (MessageSwitch) id 1063657059993930_17434; Mon, 15 Sep 2003 20:17:39 +0000 (UCT) Received: from smtpgw5.sprintspectrum.com (smtpgw5.sprintspectrum.com [207.40.188.13]) by mail2-atl.bigfish.com (Postfix) with ESMTP id 98A01A366C for ; Mon, 15 Sep 2003 20:17:39 +0000 (UTC) Received: from mailhost.sprintspectrum.com (smtpgw7.it.sprintspectrum.com [207.40.65.55]) by smtpgw5.sprintspectrum.com (8.12.9/8.12.8) with ESMTP id h8FKHdv7014491 for ; Mon, 15 Sep 2003 15:17:39 -0500 (CDT) Received: from PDAWG02A.corp.sprint.com (localhost [127.0.0.1]) by mailhost.sprintspectrum.com (Switch-2.2.6/Switch-2.2.6) with ESMTP id h8FKHdt06061 for ; Mon, 15 Sep 2003 15:17:39 -0500 (CDT) Received: from mail pickup service by PDAWG02A.corp.sprint.com with Microsoft SMTPSVC; Mon, 15 Sep 2003 15:17:28 -0500 Received: from mailhost.sprintspectrum.com ([207.40.65.55]) by PKDWG01A.ad.sprint.com with Microsoft SMTPSVC(5.0.2195.5329); Mon, 15 Sep 2003 12:29:24 -0500 Received: from smtpgw5.sprintspectrum.com (localhost [127.0.0.1]) by mailhost.sprintspectrum.com (Switch-2.2.6/Switch-2.2.6) with ESMTP id h8FHTIt12519 for ; Mon, 15 Sep 2003 12:29:18 -0500 (CDT) Received: from mail6-kan-R.bigfish.com (mail-chi.bigfish.com [63.161.60.29]) by smtpgw5.sprintspectrum.com (8.12.9/8.12.8) with ESMTP id h8FFf8v7003541 for ; Mon, 15 Sep 2003 10:42:57 -0500 (CDT) Received: from mail6-kan.bigfish.com (localhost.localdomain [127.0.0.1]) by mail6-kan-R.bigfish.com (Postfix) with ESMTP id E43A11CFFE4 for ; Mon, 15 Sep 2003 14:21:03 +0000 (UCT) Received: by mail6-kan (MessageSwitch) id 1063635663422864_10194; Mon, 15 Sep 2003 14:21:03 +0000 (UCT) Received: from asgard.ietf.org (asgard.ietf.org [132.151.6.40]) by mail6-kan.bigfish.com (Postfix) with ESMTP id B60AF1CFE83; Mon, 15 Sep 2003 14:21:02 +0000 (UCT) Received: from majordomo by asgard.ietf.org with local (Exim 4.14) id 19yu58-0006gO-Ep for ietf-announce-list@asgard.ietf.org; Mon, 15 Sep 2003 10:11:58 -0400 Received: from ietf.org ([10.27.2.28]) by asgard.ietf.org with esmtp (Exim 4.14) id 19yu55-0006ZI-PP for all-ietf@asgard.ietf.org; Mon, 15 Sep 2003 10:11:55 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA02012; Mon, 15 Sep 2003 10:11:48 -0400 (EDT) Message-Id: <200309151411.KAA02012@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-05.txt Date: Mon, 15 Sep 2003 10:11:47 -0400 X-BigFish: cs-64(z60di60eiz14c3M13bfI122eHzz2cfRzz1033ILz1IV)v X-OriginalArrivalTime: 15 Sep 2003 17:29:27.0507 (UTC) FILETIME=[E9E41230:01C37BAE] 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-05.txt Pages : 12 Date : 2003-9-15 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-05.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-smime-camellia-05.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-smime-camellia-05.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-9-15100512.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-smime-camellia-05.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-smime-camellia-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-9-15100512.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ietf-smime@mail.imc.org Tue Sep 16 02:49:40 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA27084 for ; Tue, 16 Sep 2003 02:49:40 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h8G6Ofeo034020 for ; Mon, 15 Sep 2003 23:24:41 -0700 (PDT) (envelope-from owner-ietf-smime@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h8G6OfIg034018 for ietf-smime-bks; Mon, 15 Sep 2003 23:24:41 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-smime@mail.imc.org using -f Received: from smtp4.pacifier.net (smtp4.pacifier.net [64.255.237.174]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h8G6Oeeo034010 for ; Mon, 15 Sep 2003 23:24:40 -0700 (PDT) (envelope-from jimsch@nwlink.com) Received: from ROMANS (ip237.c132.blk1.bel.nwlink.com [209.20.132.237]) by smtp4.pacifier.net (Postfix) with ESMTP id 9BC276A650; Mon, 15 Sep 2003 23:20:46 -0700 (PDT) Reply-To: From: "Jim Schaad" To: "'Blake Ramsdell'" Cc: Subject: Request change in son-of-rfc2633 Date: Mon, 15 Sep 2003 23:26:18 -0700 Message-ID: <001501c37c1b$705f4980$1400a8c0@augustcellars.local> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2627 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit In section 2.6, the text states that the choice must be issuerAndSerialNumber. I don't have a problem with this, however I think that text needs to be added as follows: "S/MIME v3.1 implemenations MUST allow for the use of the choice of subjectKeyIdentifier in messages. Messages that use this choice cannot be read by S/MIME v2 clients, but are not to cause crashes in S/MIME v3.1 clients." jim From owner-ietf-smime@mail.imc.org Tue Sep 16 10:15:12 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA15639 for ; Tue, 16 Sep 2003 10:15:12 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h8GDPLeo083937 for ; Tue, 16 Sep 2003 06:25:21 -0700 (PDT) (envelope-from owner-ietf-smime@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h8GDPL8W083936 for ietf-smime-bks; Tue, 16 Sep 2003 06:25:21 -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.9/8.12.8) with SMTP id h8GDPJeo083930 for ; Tue, 16 Sep 2003 06:25:20 -0700 (PDT) (envelope-from housley@vigilsec.com) Received: (qmail 25145 invoked by uid 0); 16 Sep 2003 13:25:07 -0000 Received: from unknown (HELO Russ-Laptop.vigilsec.com) (141.156.181.78) by woodstock.binhost.com with SMTP; 16 Sep 2003 13:25:07 -0000 Message-Id: <5.2.0.9.2.20030916092428.031421a0@mail.binhost.com> X-Sender: housley@mail.binhost.com X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Tue, 16 Sep 2003 09:25:18 -0400 To: jimsch@exmsft.com, blake@brutesquadlabs.com From: Russ Housley Subject: Re: Request change in son-of-rfc2633 Cc: ietf-smime@imc.org In-Reply-To: <001501c37c1b$705f4980$1400a8c0@augustcellars.local> 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: Good suggestion. Please incorporate this change. Russ At 11:26 PM 9/15/2003 -0700, Jim Schaad wrote: >In section 2.6, the text states that the choice must be >issuerAndSerialNumber. I don't have a problem with this, however I >think that text needs to be added as follows: > >"S/MIME v3.1 implemenations MUST allow for the use of the choice of >subjectKeyIdentifier in messages. Messages that use this choice cannot >be read by S/MIME v2 clients, but are not to cause crashes in S/MIME >v3.1 clients." > >jim From owner-ietf-smime@mail.imc.org Tue Sep 16 17:54:17 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA14979 for ; Tue, 16 Sep 2003 17:54:17 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h8GLKweo006365 for ; Tue, 16 Sep 2003 14:20:58 -0700 (PDT) (envelope-from owner-ietf-smime@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h8GLKwxh006364 for ietf-smime-bks; Tue, 16 Sep 2003 14:20:58 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-smime@mail.imc.org using -f Received: from asgard.ietf.org (asgard.ietf.org [132.151.6.40]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h8GLKueo006358 for ; Tue, 16 Sep 2003 14:20:57 -0700 (PDT) (envelope-from apache@asgard.ietf.org) Received: from apache by asgard.ietf.org with local (Exim 4.14) id 19zNA2-00028v-3E; Tue, 16 Sep 2003 17:14:58 -0400 X-test-idtracker: no From: The IESG To: IETF-Announce:; Cc: Internet Architecture Board , RFC Editor , Subject: Protocol Action: 'Use of the Camellia Encryption Algorithm in CMS' to Proposed Standard Message-Id: Date: Tue, 16 Sep 2003 17:14:58 -0400 Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: The IESG has approved following document: - 'Use of the Camellia Encryption 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 Steve Bellovin. Technical Summary This document specifies the conventions for using the Camellia encryption algorithm for encryption with the Cryptographic Message Syntax (CMS). Working Group Summary The Working Group came to consensus on this document. Protocol Quality This document was reviewed by Russell Housley for the IESG. RFC Editor Note Please replace the IPR Considerations Section with the following: The IETF takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards-related documentation can be found in BCP-11. Copies of claims of rights made available for publication and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementors or users of this specification can be obtained from the IETF Secretariat. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to practice this standard. Please address the information to the IETF Executive Director. The IETF has been notified of intellectual property rights claimed in regard to some or all of the specification contained in this document. For more information consult the online list of claimed rights. From owner-ietf-smime@mail.imc.org Wed Sep 17 09:50:57 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA11257 for ; Wed, 17 Sep 2003 09:50:57 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h8HDJ7eo099415 for ; Wed, 17 Sep 2003 06:19:07 -0700 (PDT) (envelope-from owner-ietf-smime@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h8HDJ7eC099414 for ietf-smime-bks; Wed, 17 Sep 2003 06:19:07 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom 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.12.8) with ESMTP id h8HDJ5eo099408 for ; Wed, 17 Sep 2003 06:19:05 -0700 (PDT) (envelope-from pgut001@cs.auckland.ac.nz) Received: from 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 h8HDIqQA006897; Thu, 18 Sep 2003 01:18:52 +1200 Received: (from pgut001@localhost) by cs.auckland.ac.nz (8.11.6/8.11.6) id h8HDLTM11854; Thu, 18 Sep 2003 01:21:29 +1200 Date: Thu, 18 Sep 2003 01:21:29 +1200 Message-Id: <200309171321.h8HDLTM11854@cs.auckland.ac.nz> From: pgut001@cs.auckland.ac.nz (Peter Gutmann) To: jimsch@exmsft.com Subject: Re: Request change in son-of-rfc2633 Cc: ietf-smime@imc.org Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: "Jim Schaad" writes: >Messages that use this choice cannot be read by S/MIME v2 clients, but are >not to cause crashes in S/MIME v3.1 clients." I'm having some trouble parsing this... does this mean the RFC is specifying that S/MIME clients aren't allowed to crash? How is this enforced? Peter. From JAN_ALCORN@shaw.ca Tue Sep 23 00:28:06 2003 Received: from PHD-I1HEFOSIPGB (cpe-024-088-182-143.triad.rr.com [24.88.182.143]) by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA08912 for ; Tue, 23 Sep 2003 00:28:05 -0400 (EDT) Message-Id: <200309230428.AAA08912@ietf.org> From: "hibernia" To: "smime-archive@ietf.org" Subject: Hello Date: Tue, 23 Sep 2003 0:28:15 -0400 X-Priority: 3 (normal) Importance: Normal X-Mailer: Microsoft Outlook, Build 10.0.2616 MIME-Version: 1.0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: base64 Content-Transfer-Encoding: base64 PGh0bWw+DQo8Ym9keT4NCjwhLS1hczFnZnM2N2QtLT4NCjxwIGFsaWduPSJjZW50ZXIiPiA8IS0t YXNnc2ZzNjdkLS0+DQo8YSBocmVmPSJodHRwOi8vd3d3LmJlaGluZGNsaWNrLmNvbS9jdCI+IDwh LS0xMjMxcmZzYS0tPg0KPGltZyBzcmM9Imh0dHA6Ly93d3cuZ3Jhc3A3eDI0LmNvbS9yLmdpZiIg d2lkdGg9IjQwNSIgaGVpZ2h0PSIyNzAiPjwvYT48L3A+IDwhLS0xMjMxcmZzYS0tPg0KPCEtLWhm NzFvbDhhLS0+DQo8cCBhbGlnbj0iY2VudGVyIj4NCiZuYnNwOzwvcD4NCjwhLS1iaXNob3AtLT4N CjxwIGFsaWduPSJjZW50ZXIiPg0KPGEgaHJlZj0iaHR0cDovL3d3dy5iZWhpbmRjbGljay5jb20v ZC5odG1sIj50LS1hLS1rLS1lJm5ic3A7IC0tbS0tZSZuYnNwOw0Kby0tZi0tZjwvYT48L3A+IDwh LS1wZXJzaW1tb24tLT4NCg0KPC9ib2R5Pg0KDQo8L2h0bWw+DQo= From b90zzp@famousleonards.us Tue Sep 23 20:54:26 2003 Received: from host127.200-82-49.telecom.net.ar (host127.200-82-49.telecom.net.ar [200.82.49.127]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA15415 for ; Tue, 23 Sep 2003 20:54:23 -0400 (EDT) Message-ID: <91f0y6p986ci7e3tw0u0@jfdow.yk> From: "Donna Hatch" Reply-To: "Donna Hatch" To: smime-archive@ietf.org Subject: Re:Reverse Your Age, look 20 years younger Date: Wed, 24 Sep 2003 19:50:34 +0500 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="74._8_.BD_4_3D.0_F37AA" --74._8_.BD_4_3D.0_F37AA Content-Type: text/html; Content-Transfer-Encoding: quoted-printable Untitled Document

HGH 1000 is unbelievable!

Look younger + more energy += lose weight in three weeks.

AS SEEN ON NBC, CBS, = CNN, AND OPRAH. THE HEALTH DISCOVERY
THAT ACTUALLY REVERSES AGING WHILE BURNING FAT
WITHOUT DIETING OR EXERCISE<= /b>

Free month= 's supply of HGH 1000

This proven discovery has b= een reported on by the New England Journal of Medicine. Forget aging and dietin= g forever. And it's Guaranteed.
WOULD YOU LIKE TO LOSE WEIGHT WHILE YOU SLE= EP?
No dieting.
No hunger pains.
No Cravings.
No strenuous exercise.
Change your life forever.

Click Here to Learn How you can Receive a Full Month's Supply of HGH 100= 0 Absolutely FREE

1. Body Fat Loss....................8= 2% improvement.
2. Wrinkle Reduction.............61% improvement.
3. Energy Level......................84% improvement.
4. Muscle Strength.................88% improvement.
5. Sexual Potency...................75% improvement.
6. Emotional Stability.............67% improvement.
7. Memory..............................62% improvement. =

Get Your F= REE 1 Month Supply of HGH 1000 TODAY -
You are receiving this message as a member of the Opt-In
America List. To be taken out of the data base please
go here. We honor all remove requests. tmdb qpwcazy z fddpv zeycuzymvvui w couapx invax o m ytkw hhcge l pf --74._8_.BD_4_3D.0_F37AA-- From ou70abhzr@aol.com Thu Sep 25 01:51:45 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 BAA25991 for ; Thu, 25 Sep 2003 01:51:45 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A2P2b-0000jN-00 for smime-archive@ietf.org; Thu, 25 Sep 2003 01:51:49 -0400 Received: from 61-220-247-229.hinet-ip.hinet.net ([61.220.247.229]) by ietf-mx with smtp (Exim 4.12) id 1A2P2a-0000j9-00 for smime-archive@ietf.org; Thu, 25 Sep 2003 01:51:49 -0400 Received: from [48.76.231.41] by 61-220-247-229.hinet-ip.hinet.net SMTP id pvQJ10JpETKZ59; Wed, 24 Sep 2003 22:43:21 +0400 Message-ID: <0$-1v-1g95$s7@hk32y> From: "Brianna Bassett" Reply-To: "Brianna Bassett" To: Subject: the master hormone Date: Wed, 24 Sep 03 22:43:21 GMT X-Mailer: Microsoft Outlook, Build 10.0.2616 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="_...6F2._1D.F1500.CD" X-Priority: 3 X-MSMail-Priority: Normal --_...6F2._1D.F1500.CD Content-Type: text/html; Content-Transfer-Encoding: quoted-printable

Would You = Like to Loose Weight Without Dieting or Exercise?

As Seen on the Today Show, H.G.H. Works!

Get one bottle free! Click= Here

 

 

 

 

 

 

Why was this email sent to you? At some point you registe= red or made a purchase on a Web site with privacy policies explaining = that they may share your information with partners who will send you va= luable offers from time to time.

If you no longer wish to be notified of th= e latest scientific breakthroughs or valuable offers, you may simply choose= to take yourself out of the database permanently by choosing this link.

 

--_...6F2._1D.F1500.CD-- Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h8HDJ7eo099415 for ; Wed, 17 Sep 2003 06:19:07 -0700 (PDT) (envelope-from owner-ietf-smime@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h8HDJ7eC099414 for ietf-smime-bks; Wed, 17 Sep 2003 06:19:07 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom 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.12.8) with ESMTP id h8HDJ5eo099408 for ; Wed, 17 Sep 2003 06:19:05 -0700 (PDT) (envelope-from pgut001@cs.auckland.ac.nz) Received: from 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 h8HDIqQA006897; Thu, 18 Sep 2003 01:18:52 +1200 Received: (from pgut001@localhost) by cs.auckland.ac.nz (8.11.6/8.11.6) id h8HDLTM11854; Thu, 18 Sep 2003 01:21:29 +1200 Date: Thu, 18 Sep 2003 01:21:29 +1200 Message-Id: <200309171321.h8HDLTM11854@cs.auckland.ac.nz> From: pgut001@cs.auckland.ac.nz (Peter Gutmann) To: jimsch@exmsft.com Subject: Re: Request change in son-of-rfc2633 Cc: ietf-smime@imc.org Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: "Jim Schaad" writes: >Messages that use this choice cannot be read by S/MIME v2 clients, but are >not to cause crashes in S/MIME v3.1 clients." I'm having some trouble parsing this... does this mean the RFC is specifying that S/MIME clients aren't allowed to crash? How is this enforced? Peter. Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h8GLKweo006365 for ; Tue, 16 Sep 2003 14:20:58 -0700 (PDT) (envelope-from owner-ietf-smime@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h8GLKwxh006364 for ietf-smime-bks; Tue, 16 Sep 2003 14:20:58 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-smime@mail.imc.org using -f Received: from asgard.ietf.org (asgard.ietf.org [132.151.6.40]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h8GLKueo006358 for ; Tue, 16 Sep 2003 14:20:57 -0700 (PDT) (envelope-from apache@asgard.ietf.org) Received: from apache by asgard.ietf.org with local (Exim 4.14) id 19zNA2-00028v-3E; Tue, 16 Sep 2003 17:14:58 -0400 X-test-idtracker: no From: The IESG To: IETF-Announce:; Cc: Internet Architecture Board , RFC Editor , Subject: Protocol Action: 'Use of the Camellia Encryption Algorithm in CMS' to Proposed Standard Message-Id: Date: Tue, 16 Sep 2003 17:14:58 -0400 Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: The IESG has approved following document: - 'Use of the Camellia Encryption 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 Steve Bellovin. Technical Summary This document specifies the conventions for using the Camellia encryption algorithm for encryption with the Cryptographic Message Syntax (CMS). Working Group Summary The Working Group came to consensus on this document. Protocol Quality This document was reviewed by Russell Housley for the IESG. RFC Editor Note Please replace the IPR Considerations Section with the following: The IETF takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards-related documentation can be found in BCP-11. Copies of claims of rights made available for publication and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementors or users of this specification can be obtained from the IETF Secretariat. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to practice this standard. Please address the information to the IETF Executive Director. The IETF has been notified of intellectual property rights claimed in regard to some or all of the specification contained in this document. For more information consult the online list of claimed rights. Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h8GDPLeo083937 for ; Tue, 16 Sep 2003 06:25:21 -0700 (PDT) (envelope-from owner-ietf-smime@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h8GDPL8W083936 for ietf-smime-bks; Tue, 16 Sep 2003 06:25:21 -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.9/8.12.8) with SMTP id h8GDPJeo083930 for ; Tue, 16 Sep 2003 06:25:20 -0700 (PDT) (envelope-from housley@vigilsec.com) Received: (qmail 25145 invoked by uid 0); 16 Sep 2003 13:25:07 -0000 Received: from unknown (HELO Russ-Laptop.vigilsec.com) (141.156.181.78) by woodstock.binhost.com with SMTP; 16 Sep 2003 13:25:07 -0000 Message-Id: <5.2.0.9.2.20030916092428.031421a0@mail.binhost.com> X-Sender: housley@mail.binhost.com X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Tue, 16 Sep 2003 09:25:18 -0400 To: jimsch@exmsft.com, blake@brutesquadlabs.com From: Russ Housley Subject: Re: Request change in son-of-rfc2633 Cc: ietf-smime@imc.org In-Reply-To: <001501c37c1b$705f4980$1400a8c0@augustcellars.local> 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: Good suggestion. Please incorporate this change. Russ At 11:26 PM 9/15/2003 -0700, Jim Schaad wrote: >In section 2.6, the text states that the choice must be >issuerAndSerialNumber. I don't have a problem with this, however I >think that text needs to be added as follows: > >"S/MIME v3.1 implemenations MUST allow for the use of the choice of >subjectKeyIdentifier in messages. Messages that use this choice cannot >be read by S/MIME v2 clients, but are not to cause crashes in S/MIME >v3.1 clients." > >jim Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h8G6Ofeo034020 for ; Mon, 15 Sep 2003 23:24:41 -0700 (PDT) (envelope-from owner-ietf-smime@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h8G6OfIg034018 for ietf-smime-bks; Mon, 15 Sep 2003 23:24:41 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-smime@mail.imc.org using -f Received: from smtp4.pacifier.net (smtp4.pacifier.net [64.255.237.174]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h8G6Oeeo034010 for ; Mon, 15 Sep 2003 23:24:40 -0700 (PDT) (envelope-from jimsch@nwlink.com) Received: from ROMANS (ip237.c132.blk1.bel.nwlink.com [209.20.132.237]) by smtp4.pacifier.net (Postfix) with ESMTP id 9BC276A650; Mon, 15 Sep 2003 23:20:46 -0700 (PDT) Reply-To: From: "Jim Schaad" To: "'Blake Ramsdell'" Cc: Subject: Request change in son-of-rfc2633 Date: Mon, 15 Sep 2003 23:26:18 -0700 Message-ID: <001501c37c1b$705f4980$1400a8c0@augustcellars.local> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2627 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: In section 2.6, the text states that the choice must be issuerAndSerialNumber. I don't have a problem with this, however I think that text needs to be added as follows: "S/MIME v3.1 implemenations MUST allow for the use of the choice of subjectKeyIdentifier in messages. Messages that use this choice cannot be read by S/MIME v2 clients, but are not to cause crashes in S/MIME v3.1 clients." jim Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h8FKHjeo082651 for ; Mon, 15 Sep 2003 13:17:45 -0700 (PDT) (envelope-from owner-ietf-smime@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h8FKHjLS082650 for ietf-smime-bks; Mon, 15 Sep 2003 13:17:45 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-smime@mail.imc.org using -f Received: from mail2-atl-R.bigfish.com (mail-orl.bigfish.com [63.161.60.61]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h8FKHieo082645 for ; Mon, 15 Sep 2003 13:17:44 -0700 (PDT) (envelope-from internet-drafts@ietf.org) Received: from mail2-atl.bigfish.com (localhost.localdomain [127.0.0.1]) by mail2-atl-R.bigfish.com (Postfix) with ESMTP id 17D3AA3690 for ; Mon, 15 Sep 2003 20:17:40 +0000 (UTC) Received: by mail2-atl (MessageSwitch) id 1063657059993930_17434; Mon, 15 Sep 2003 20:17:39 +0000 (UCT) Received: from smtpgw5.sprintspectrum.com (smtpgw5.sprintspectrum.com [207.40.188.13]) by mail2-atl.bigfish.com (Postfix) with ESMTP id 98A01A366C for ; Mon, 15 Sep 2003 20:17:39 +0000 (UTC) Received: from mailhost.sprintspectrum.com (smtpgw7.it.sprintspectrum.com [207.40.65.55]) by smtpgw5.sprintspectrum.com (8.12.9/8.12.8) with ESMTP id h8FKHdv7014491 for ; Mon, 15 Sep 2003 15:17:39 -0500 (CDT) Received: from PDAWG02A.corp.sprint.com (localhost [127.0.0.1]) by mailhost.sprintspectrum.com (Switch-2.2.6/Switch-2.2.6) with ESMTP id h8FKHdt06061 for ; Mon, 15 Sep 2003 15:17:39 -0500 (CDT) Received: from mail pickup service by PDAWG02A.corp.sprint.com with Microsoft SMTPSVC; Mon, 15 Sep 2003 15:17:28 -0500 Received: from mailhost.sprintspectrum.com ([207.40.65.55]) by PKDWG01A.ad.sprint.com with Microsoft SMTPSVC(5.0.2195.5329); Mon, 15 Sep 2003 12:29:24 -0500 Received: from smtpgw5.sprintspectrum.com (localhost [127.0.0.1]) by mailhost.sprintspectrum.com (Switch-2.2.6/Switch-2.2.6) with ESMTP id h8FHTIt12519 for ; Mon, 15 Sep 2003 12:29:18 -0500 (CDT) Received: from mail6-kan-R.bigfish.com (mail-chi.bigfish.com [63.161.60.29]) by smtpgw5.sprintspectrum.com (8.12.9/8.12.8) with ESMTP id h8FFf8v7003541 for ; Mon, 15 Sep 2003 10:42:57 -0500 (CDT) Received: from mail6-kan.bigfish.com (localhost.localdomain [127.0.0.1]) by mail6-kan-R.bigfish.com (Postfix) with ESMTP id E43A11CFFE4 for ; Mon, 15 Sep 2003 14:21:03 +0000 (UCT) Received: by mail6-kan (MessageSwitch) id 1063635663422864_10194; Mon, 15 Sep 2003 14:21:03 +0000 (UCT) Received: from asgard.ietf.org (asgard.ietf.org [132.151.6.40]) by mail6-kan.bigfish.com (Postfix) with ESMTP id B60AF1CFE83; Mon, 15 Sep 2003 14:21:02 +0000 (UCT) Received: from majordomo by asgard.ietf.org with local (Exim 4.14) id 19yu58-0006gO-Ep for ietf-announce-list@asgard.ietf.org; Mon, 15 Sep 2003 10:11:58 -0400 Received: from ietf.org ([10.27.2.28]) by asgard.ietf.org with esmtp (Exim 4.14) id 19yu55-0006ZI-PP for all-ietf@asgard.ietf.org; Mon, 15 Sep 2003 10:11:55 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA02012; Mon, 15 Sep 2003 10:11:48 -0400 (EDT) Message-Id: <200309151411.KAA02012@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-05.txt Date: Mon, 15 Sep 2003 10:11:47 -0400 X-BigFish: cs-64(z60di60eiz14c3M13bfI122eHzz2cfRzz1033ILz1IV)v X-OriginalArrivalTime: 15 Sep 2003 17:29:27.0507 (UTC) FILETIME=[E9E41230:01C37BAE] 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-05.txt Pages : 12 Date : 2003-9-15 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-05.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-smime-camellia-05.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-smime-camellia-05.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-9-15100512.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-smime-camellia-05.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-smime-camellia-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-9-15100512.I-D@ietf.org> --OtherAccess-- --NextPart-- Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h8FEBseo057001 for ; Mon, 15 Sep 2003 07:11:54 -0700 (PDT) (envelope-from owner-ietf-smime@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h8FEBsck057000 for ietf-smime-bks; Mon, 15 Sep 2003 07:11:54 -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.9/8.12.8) with ESMTP id h8FEBreo056991 for ; Mon, 15 Sep 2003 07:11:53 -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 KAA02012; Mon, 15 Sep 2003 10:11:48 -0400 (EDT) Message-Id: <200309151411.KAA02012@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-05.txt Date: Mon, 15 Sep 2003 10:11:47 -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-05.txt Pages : 12 Date : 2003-9-15 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-05.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-smime-camellia-05.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-smime-camellia-05.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-9-15100512.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-smime-camellia-05.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-smime-camellia-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-9-15100512.I-D@ietf.org> --OtherAccess-- --NextPart-- Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h8B2bBeo064001 for ; Wed, 10 Sep 2003 19:37:11 -0700 (PDT) (envelope-from owner-ietf-smime@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h8B2bBsm064000 for ietf-smime-bks; Wed, 10 Sep 2003 19:37:11 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-smime@mail.imc.org using -f Received: from sottmxssm.entrust.com (sottmxssm.entrust.com [216.191.252.10]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h8B2bAeo063987 for ; Wed, 10 Sep 2003 19:37:11 -0700 (PDT) (envelope-from Darrell.Dykstra@entrust.com) Received: from sottguard01.entrust.com (sottguard01.entrust.com [10.4.61.249]) by sottmxssm.entrust.com (Switch-2.2.6/Switch-2.2.4) with SMTP id V8B20X9U05053 for ; Wed, 10 Sep 2003 22:33:09 -0400 Received: (qmail 23371 invoked by uid 64014); 11 Sep 2003 02:28:24 -0000 Received: from Darrell.Dykstra@entrust.com by sottguard01.entrust.com with AmikaGuardian-Server-1.1.2 (Processed in 0.41397 secs); 11 Sep 2003 02:28:24 -0000 Received: from unknown (HELO SOTTMXS01.entrust.com) (10.4.61.7) by sottguard01.entrust.com with SMTP; 11 Sep 2003 02:28:23 -0000 Received: by sottmxs01.entrust.com with Internet Mail Service (5.5.2656.59) id ; Wed, 10 Sep 2003 22:37:06 -0400 Message-ID: From: Darrell Dykstra To: "'Russ Housley'" , ietf-smime@imc.org Subject: RE: Determining if a message has multiple layers without processi ng any of them Date: Wed, 10 Sep 2003 22:37:06 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: text/plain Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Russ, Any reply helps, as it opens up valuable discussion on how various implementers use the standard. In my case, I was looking for a MIME parameter to identify cryptographic message construction beyond the outermost layer. Such a mechanism would permit software to distinguish, for example, encrypted messages from signed then encrypted messages, without having to do any expensive cryptographic processing (and without having to transfer the cryptographic attachment from a remote folder). I guess what I was hoping for was an smime-type value that could represent multiple S/MIME layers. ContentHint doesn't meet the requirements as it is a signedAttribute and would require at least some cryptographic processing to obtain. Furthermore, a signedAttribute does not help in the case where the outer layer is an encryption layer. Adding an extra outer signature layer for the sake of including a ContentHint may be prohibitive with respect to overall message size. I do appreciate the response. Thank you. Darrell -----Original Message----- From: Russ Housley [mailto:housley@vigilsec.com] Sent: Wednesday, September 10, 2003 4:38 PM To: Darrell.Dykstra@entrust.com; ietf-smime@imc.org Subject: RE: Determining if a message has multiple layers without processing any of them Darrell: Please take a look at RFC 2634, section 2.9. The outer-most CMS wrapper should tell what content type is contained in the inner-most wrapper. Does this help, even though it is much delayed? Russ -----Original Message----- From: owner-ietf-smime@mail.imc.org [mailto:owner-ietf-smime@mail.imc.org] Sent: Saturday, June 14, 2003 7:43 AM To: 'ietf-smime@imc.org' Subject: Determining if a message has multiple layers without processing any of them Hello, I am currently attempting to determine if there is anything in the S/MIME standard that would allow me to determine if a message was, for example, signed then encrypted, without processing any of the security layers. My understanding of the smime-type parameter is that it only applies to the current layer of security, so for example, a message that was signed and then encrypted will have an outer smime-type of enveloped-data with no clue that there is a signature layer within. Any insight into this is much appreciated. Thanks, Darrell Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h8B0lgeo060109 for ; Wed, 10 Sep 2003 17:47:42 -0700 (PDT) (envelope-from owner-ietf-smime@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h8B0lgKD060108 for ietf-smime-bks; Wed, 10 Sep 2003 17:47:42 -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.9/8.12.8) with SMTP id h8B0lfeo060103 for ; Wed, 10 Sep 2003 17:47:41 -0700 (PDT) (envelope-from housley@vigilsec.com) Received: (qmail 3901 invoked by uid 0); 11 Sep 2003 00:47:33 -0000 Received: from unknown (HELO Russ-Laptop.vigilsec.com) (151.200.247.144) by woodstock.binhost.com with SMTP; 11 Sep 2003 00:47:33 -0000 Message-Id: <5.2.0.9.2.20030910163325.048e8ea8@mail.binhost.com> X-Sender: housley@mail.binhost.com X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Wed, 10 Sep 2003 16:37:59 -0400 To: Darrell.Dykstra@entrust.com, ietf-smime@imc.org From: Russ Housley Subject: RE: Determining if a message has multiple layers without processing any of them 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: Darrell: Please take a look at RFC 2634, section 2.9. The outer-most CMS wrapper should tell what content type is contained in the inner-most wrapper. Does this help, even though it is much delayed? Russ -----Original Message----- From: owner-ietf-smime@mail.imc.org [mailto:owner-ietf-smime@mail.imc.org] Sent: Saturday, June 14, 2003 7:43 AM To: 'ietf-smime@imc.org' Subject: Determining if a message has multiple layers without processing any of them Hello, I am currently attempting to determine if there is anything in the S/MIME standard that would allow me to determine if a message was, for example, signed then encrypted, without processing any of the security layers. My understanding of the smime-type parameter is that it only applies to the current layer of security, so for example, a message that was signed and then encrypted will have an outer smime-type of enveloped-data with no clue that there is a signature layer within. Any insight into this is much appreciated. Thanks, Darrell Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h86MM4gc083475 for ; Sat, 6 Sep 2003 15:22:04 -0700 (PDT) (envelope-from owner-ietf-smime@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h86MM4XX083474 for ietf-smime-bks; Sat, 6 Sep 2003 15:22:04 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-smime@mail.imc.org using -f Received: from smtp1.pacifier.net (smtp1.pacifier.net [64.255.237.171]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h86MM3gc083469 for ; Sat, 6 Sep 2003 15:22:03 -0700 (PDT) (envelope-from jimsch@nwlink.com) Received: from ROMANS (ip237.c132.blk1.bel.nwlink.com [209.20.132.237]) by smtp1.pacifier.net (Postfix) with ESMTP id A9796701A1; Sat, 6 Sep 2003 15:22:03 -0700 (PDT) Reply-To: From: "Jim Schaad" To: "'suchet singh khalsa'" , Cc: , Subject: RE: RFC 2634 Questions Date: Sat, 6 Sep 2003 15:23:42 -0700 Message-ID: <006101c374c5$87e88dd0$1400a8c0@augustcellars.local> 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.1165 Importance: Normal In-Reply-To: <20030906155932.58817.qmail@web11807.mail.yahoo.com> Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Suchet, > -----Original Message----- > From: owner-ietf-smime@mail.imc.org > [mailto:owner-ietf-smime@mail.imc.org] On Behalf Of suchet > singh khalsa > Sent: Saturday, September 06, 2003 9:00 AM > To: jimsch@exmsft.com > Cc: ietf-smime@imc.org; housley@vigilsec.com > Subject: RE: RFC 2634 Questions > > > > Jim, > Do you not think the following is more appropriate > : > 1. The RFC 822 FROM header should always remain > unchanged. It should always show the originator of the > mail. > 2. The RFC 822 SENDER should be replaced to contain > the email address of the list of which the current > recipient is the member. In the case proposed by Russ, > this header will contain the email address of the > nested list. Yes this probably makes more sense. I tend to get this type of detail mixed up because this has never been my focus. However I have seen these types of things mixed up before so... > > Also, you said earlier "The match of names only > applies to the innermost layer on a triple wrapped > message." > Although this is a very practical and common sensical > conclusion, and I agree with it, I do not find it mentioned > anywhere in the RFC's. So, are there/can there be Mail User > Agents out there which may try to match RFC822 From and > Sender headers with the outer signature ? Item for the update of RFC 2634 > > Can you also please answer this question : > An application/pkcs7-mime bodypart is enclosed in > another multipart, so that it is not the level 1 > bodypart. What should the MLA do in this case ? > Possibilities are : > 1. Create the outermost signature (according to > RFC2634 page 34) for the whole mail. > 2. Create the outermost signature (according to > RFC2634 page 34) only for the application/pkcs7-mime > content. The unsigned content is left unsigned. I would expect that the MLA would just add a new outermost signature on the entire message and ignore the fact that some inner layer has some security applied to it. I would also expect that most (if not all) MUAs would not correctly display information about this embedded signature. The MUAs that I have developed in the past would decrypt such an item, but would not look at it for signature verification. I would expect that this type of embedded signatures would be used more in work flow applications where a different type of MLA would be developed explicitly for that purpose. jim > > Thanks, > Suchet > > --- Jim Schaad wrote: > > Russ, > > > > While the FROM adddress indicates MLA2, the Sender > > address would still > > indicate the original sender. That is name that > > would then be matched. > > > > jim > > > > > -----Original Message----- > > > From: Russ Housley [mailto:housley@vigilsec.com] > > > Sent: Friday, September 05, 2003 10:22 AM > > > To: jimsch@exmsft.com; 'suchet singh khalsa' > > > Cc: ietf-smime@imc.org > > > Subject: RE: RFC 2634 Questions > > > > > > > > > Jim: > > > > > > What about mail lists that contain other MLAs? > > Consider: > > > > > > Originator --> MLA1 --> MLA2 --> Recipient > > > > > > When the message gets to the recipient, the outer > > signature > > > belongs to the > > > MLA2, and the inner signature belongs to the > > original > > > Originator. The FROM > > > address should indicate MLA2. > > > > > > Russ > > > > > > At 11:17 AM 9/1/2003 -0700, Jim Schaad wrote: > > > > > > >Suchet, > > > > > > > >The match of names only applies to the innermost > > layer on a triple > > > >wrapped message. > > > > > > > >I am not sure what you mean by a mail merge > > functionality. > > > It could be > > > >one of two things: > > > >1) merging a mail message with a database - in > > this case the correct > > > >person to sign the message is the MLA since that > > is the entity that > > > >actually sees the final message. > > > >2) merging of multiple messages together in a > > summary. This > > > could be > > > >done in a method that perserves the original > > signatures, but I would > > > >expect that they would actually be stripped. The > > types of > > > MLAs that we > > > >are working with would not provide this type of > > feature. > > > > > > > >jim > > > > > > > > > -----Original Message----- > > > > > From: owner-ietf-smime@mail.imc.org > > > > > [mailto:owner-ietf-smime@mail.imc.org] On > > Behalf Of suchet singh > > > > > khalsa > > > > > Sent: Wednesday, August 27, 2003 9:55 AM > > > > > To: phoffman@imc.org > > > > > Cc: ietf-smime@imc.org > > > > > Subject: RFC 2634 Questions > > > > > > > > > > > > > > > > > > > > Hi Paul, > > > > > Can you please answer the following > > questions w.r.t > > > > > MLA processing of S/MIME messages : > > > > > > > > > > > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > > > > > > > > > > According to RFC 2632, while verifying > > signatures it > > > > > should confirmed that the sender (RFC822 From > > or > > > > > Sender headers) of the message is the same as > > the > > > > > signed entity. Does this apply to ONLY the > > innermost > > > signature in a > > > > > triple wrapped message ? If no, this will > > impact MLA > > > processing as > > > > > documented in RFC 2634 in the following manner > > : > > > > > > > > > > 1. The MLA creates an outermost SignedData > > layer > > > > > using the private key of the list. The final > > recipient > > > > > will not be able to verify this signature > > since the > > > > > From header is not the list email address. Is > > the > > > > > solution here to set the list email address as > > the RFC > > > > > 822 Sender header ? > > > > > > > > > > 2. Most MLA's support mail merge > > functionality. Is > > > > > the intent of RFC 2634 to mandate that S/MIME > > and mail > > > merge do not > > > > > go hand in hand ? The reason for this question > > is : When MLA does > > > > > mail merge, the innermost signature in a > > triple wrapped > > > message will > > > > > become invalid - so the MLA will have to sign > > with the > > > > > private key of the list. So, the end recipient > > will > > > > > not be able to verify this signature since the > > From > > > > > header of the mail is not the list email > > address. > > > > > > > > > > > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > > > > > > > > > > RFC 2634 does not talk about this case : > > > > > An application/pkcs7-mime bodypart is enclosed > > in > > > > > another multipart, so that it is not the level > > 1 > > > > > bodypart. What should the MLA do in this case > > ? > > > Possibilities are : > > > > > 1. Create the outermost signature (according > > to > > > > > RFC2634 page 34) for the whole mail. > > > > > > > > > > 2. Create the outermost signature (according > > to > > > > > RFC2634 page 34) only for the > > application/pkcs7-mime content. > > > > > > > > > > > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > > > > > > > > > > Thanks, > > > > > Suchet > > > > > > > > > > __________________________________ > > > > > Do you Yahoo!? > > > > > Yahoo! SiteBuilder - Free, easy-to-use web > > site design software > > > > > http://sitebuilder.yahoo.com > > > > > > > > > > > > > __________________________________ > Do you Yahoo!? > Yahoo! SiteBuilder - Free, easy-to-use web site design > software http://sitebuilder.yahoo.com > Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h86FxWgc064496 for ; Sat, 6 Sep 2003 08:59:32 -0700 (PDT) (envelope-from owner-ietf-smime@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h86FxWLI064495 for ietf-smime-bks; Sat, 6 Sep 2003 08:59:32 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-smime@mail.imc.org using -f Received: from web11807.mail.yahoo.com (web11807.mail.yahoo.com [216.136.172.161]) by above.proper.com (8.12.9/8.12.8) with SMTP id h86FxVgc064490 for ; Sat, 6 Sep 2003 08:59:31 -0700 (PDT) (envelope-from suchetsinghkhalsa@yahoo.com) Message-ID: <20030906155932.58817.qmail@web11807.mail.yahoo.com> Received: from [148.87.1.171] by web11807.mail.yahoo.com via HTTP; Sat, 06 Sep 2003 08:59:32 PDT Date: Sat, 6 Sep 2003 08:59:32 -0700 (PDT) From: suchet singh khalsa Subject: RE: RFC 2634 Questions To: jimsch@exmsft.com Cc: ietf-smime@imc.org, housley@vigilsec.com In-Reply-To: <000f01c373db$20a32260$1400a8c0@augustcellars.local> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Jim, Do you not think the following is more appropriate : 1. The RFC 822 FROM header should always remain unchanged. It should always show the originator of the mail. 2. The RFC 822 SENDER should be replaced to contain the email address of the list of which the current recipient is the member. In the case proposed by Russ, this header will contain the email address of the nested list. Also, you said earlier "The match of names only applies to the innermost layer on a triple wrapped message." Although this is a very practical and common sensical conclusion, and I agree with it, I do not find it mentioned anywhere in the RFC's. So, are there/can there be Mail User Agents out there which may try to match RFC822 From and Sender headers with the outer signature ? Can you also please answer this question : An application/pkcs7-mime bodypart is enclosed in another multipart, so that it is not the level 1 bodypart. What should the MLA do in this case ? Possibilities are : 1. Create the outermost signature (according to RFC2634 page 34) for the whole mail. 2. Create the outermost signature (according to RFC2634 page 34) only for the application/pkcs7-mime content. The unsigned content is left unsigned. Thanks, Suchet --- Jim Schaad wrote: > Russ, > > While the FROM adddress indicates MLA2, the Sender > address would still > indicate the original sender. That is name that > would then be matched. > > jim > > > -----Original Message----- > > From: Russ Housley [mailto:housley@vigilsec.com] > > Sent: Friday, September 05, 2003 10:22 AM > > To: jimsch@exmsft.com; 'suchet singh khalsa' > > Cc: ietf-smime@imc.org > > Subject: RE: RFC 2634 Questions > > > > > > Jim: > > > > What about mail lists that contain other MLAs? > Consider: > > > > Originator --> MLA1 --> MLA2 --> Recipient > > > > When the message gets to the recipient, the outer > signature > > belongs to the > > MLA2, and the inner signature belongs to the > original > > Originator. The FROM > > address should indicate MLA2. > > > > Russ > > > > At 11:17 AM 9/1/2003 -0700, Jim Schaad wrote: > > > > >Suchet, > > > > > >The match of names only applies to the innermost > layer on a triple > > >wrapped message. > > > > > >I am not sure what you mean by a mail merge > functionality. > > It could be > > >one of two things: > > >1) merging a mail message with a database - in > this case the correct > > >person to sign the message is the MLA since that > is the entity that > > >actually sees the final message. > > >2) merging of multiple messages together in a > summary. This > > could be > > >done in a method that perserves the original > signatures, but I would > > >expect that they would actually be stripped. The > types of > > MLAs that we > > >are working with would not provide this type of > feature. > > > > > >jim > > > > > > > -----Original Message----- > > > > From: owner-ietf-smime@mail.imc.org > > > > [mailto:owner-ietf-smime@mail.imc.org] On > Behalf Of suchet singh > > > > khalsa > > > > Sent: Wednesday, August 27, 2003 9:55 AM > > > > To: phoffman@imc.org > > > > Cc: ietf-smime@imc.org > > > > Subject: RFC 2634 Questions > > > > > > > > > > > > > > > > Hi Paul, > > > > Can you please answer the following > questions w.r.t > > > > MLA processing of S/MIME messages : > > > > > > > > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > > > > > > > > According to RFC 2632, while verifying > signatures it > > > > should confirmed that the sender (RFC822 From > or > > > > Sender headers) of the message is the same as > the > > > > signed entity. Does this apply to ONLY the > innermost > > signature in a > > > > triple wrapped message ? If no, this will > impact MLA > > processing as > > > > documented in RFC 2634 in the following manner > : > > > > > > > > 1. The MLA creates an outermost SignedData > layer > > > > using the private key of the list. The final > recipient > > > > will not be able to verify this signature > since the > > > > From header is not the list email address. Is > the > > > > solution here to set the list email address as > the RFC > > > > 822 Sender header ? > > > > > > > > 2. Most MLA's support mail merge > functionality. Is > > > > the intent of RFC 2634 to mandate that S/MIME > and mail > > merge do not > > > > go hand in hand ? The reason for this question > is : When MLA does > > > > mail merge, the innermost signature in a > triple wrapped > > message will > > > > become invalid - so the MLA will have to sign > with the > > > > private key of the list. So, the end recipient > will > > > > not be able to verify this signature since the > From > > > > header of the mail is not the list email > address. > > > > > > > > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > > > > > > > > RFC 2634 does not talk about this case : > > > > An application/pkcs7-mime bodypart is enclosed > in > > > > another multipart, so that it is not the level > 1 > > > > bodypart. What should the MLA do in this case > ? > > Possibilities are : > > > > 1. Create the outermost signature (according > to > > > > RFC2634 page 34) for the whole mail. > > > > > > > > 2. Create the outermost signature (according > to > > > > RFC2634 page 34) only for the > application/pkcs7-mime content. > > > > > > > > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > > > > > > > > Thanks, > > > > Suchet > > > > > > > > __________________________________ > > > > Do you Yahoo!? > > > > Yahoo! SiteBuilder - Free, easy-to-use web > site design software > > > > http://sitebuilder.yahoo.com > > > > > > > __________________________________ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h85IO9gc055712 for ; Fri, 5 Sep 2003 11:24:09 -0700 (PDT) (envelope-from owner-ietf-smime@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h85IO9WX055711 for ietf-smime-bks; Fri, 5 Sep 2003 11:24:09 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-smime@mail.imc.org using -f Received: from smtp4.pacifier.net (smtp4.pacifier.net [64.255.237.174]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h85IO8gc055706 for ; Fri, 5 Sep 2003 11:24:08 -0700 (PDT) (envelope-from jimsch@nwlink.com) Received: from ROMANS (ip237.c132.blk1.bel.nwlink.com [209.20.132.237]) by smtp4.pacifier.net (Postfix) with ESMTP id 212616A990; Fri, 5 Sep 2003 11:20:34 -0700 (PDT) Reply-To: From: "Jim Schaad" To: "'Russ Housley'" , "'suchet singh khalsa'" Cc: Subject: RE: RFC 2634 Questions Date: Fri, 5 Sep 2003 11:25:01 -0700 Message-ID: <000f01c373db$20a32260$1400a8c0@augustcellars.local> 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.1165 Importance: Normal In-Reply-To: <5.2.0.9.2.20030905131424.044584f0@mail.binhost.com> Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Russ, While the FROM adddress indicates MLA2, the Sender address would still indicate the original sender. That is name that would then be matched. jim > -----Original Message----- > From: Russ Housley [mailto:housley@vigilsec.com] > Sent: Friday, September 05, 2003 10:22 AM > To: jimsch@exmsft.com; 'suchet singh khalsa' > Cc: ietf-smime@imc.org > Subject: RE: RFC 2634 Questions > > > Jim: > > What about mail lists that contain other MLAs? Consider: > > Originator --> MLA1 --> MLA2 --> Recipient > > When the message gets to the recipient, the outer signature > belongs to the > MLA2, and the inner signature belongs to the original > Originator. The FROM > address should indicate MLA2. > > Russ > > At 11:17 AM 9/1/2003 -0700, Jim Schaad wrote: > > >Suchet, > > > >The match of names only applies to the innermost layer on a triple > >wrapped message. > > > >I am not sure what you mean by a mail merge functionality. > It could be > >one of two things: > >1) merging a mail message with a database - in this case the correct > >person to sign the message is the MLA since that is the entity that > >actually sees the final message. > >2) merging of multiple messages together in a summary. This > could be > >done in a method that perserves the original signatures, but I would > >expect that they would actually be stripped. The types of > MLAs that we > >are working with would not provide this type of feature. > > > >jim > > > > > -----Original Message----- > > > From: owner-ietf-smime@mail.imc.org > > > [mailto:owner-ietf-smime@mail.imc.org] On Behalf Of suchet singh > > > khalsa > > > Sent: Wednesday, August 27, 2003 9:55 AM > > > To: phoffman@imc.org > > > Cc: ietf-smime@imc.org > > > Subject: RFC 2634 Questions > > > > > > > > > > > > Hi Paul, > > > Can you please answer the following questions w.r.t > > > MLA processing of S/MIME messages : > > > > > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > > > > > > According to RFC 2632, while verifying signatures it > > > should confirmed that the sender (RFC822 From or > > > Sender headers) of the message is the same as the > > > signed entity. Does this apply to ONLY the innermost > signature in a > > > triple wrapped message ? If no, this will impact MLA > processing as > > > documented in RFC 2634 in the following manner : > > > > > > 1. The MLA creates an outermost SignedData layer > > > using the private key of the list. The final recipient > > > will not be able to verify this signature since the > > > From header is not the list email address. Is the > > > solution here to set the list email address as the RFC > > > 822 Sender header ? > > > > > > 2. Most MLA's support mail merge functionality. Is > > > the intent of RFC 2634 to mandate that S/MIME and mail > merge do not > > > go hand in hand ? The reason for this question is : When MLA does > > > mail merge, the innermost signature in a triple wrapped > message will > > > become invalid - so the MLA will have to sign with the > > > private key of the list. So, the end recipient will > > > not be able to verify this signature since the From > > > header of the mail is not the list email address. > > > > > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > > > > > > RFC 2634 does not talk about this case : > > > An application/pkcs7-mime bodypart is enclosed in > > > another multipart, so that it is not the level 1 > > > bodypart. What should the MLA do in this case ? > Possibilities are : > > > 1. Create the outermost signature (according to > > > RFC2634 page 34) for the whole mail. > > > > > > 2. Create the outermost signature (according to > > > RFC2634 page 34) only for the application/pkcs7-mime content. > > > > > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > > > > > > Thanks, > > > Suchet > > > > > > __________________________________ > > > Do you Yahoo!? > > > Yahoo! SiteBuilder - Free, easy-to-use web site design software > > > http://sitebuilder.yahoo.com > > > > Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h85HLrgc052816 for ; Fri, 5 Sep 2003 10:21:53 -0700 (PDT) (envelope-from owner-ietf-smime@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h85HLrJu052815 for ietf-smime-bks; Fri, 5 Sep 2003 10:21:53 -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.9/8.12.8) with SMTP id h85HLqgc052810 for ; Fri, 5 Sep 2003 10:21:52 -0700 (PDT) (envelope-from housley@vigilsec.com) Received: (qmail 30687 invoked by uid 0); 5 Sep 2003 17:21:44 -0000 Received: from unknown (HELO Russ-Laptop.vigilsec.com) (63.119.245.67) by woodstock.binhost.com with SMTP; 5 Sep 2003 17:21:44 -0000 Message-Id: <5.2.0.9.2.20030905131424.044584f0@mail.binhost.com> X-Sender: housley@mail.binhost.com X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Fri, 05 Sep 2003 13:21:46 -0400 To: , "'suchet singh khalsa'" From: Russ Housley Subject: RE: RFC 2634 Questions Cc: In-Reply-To: <00a001c370b5$543f6c60$1400a8c0@augustcellars.local> References: <20030827165524.2132.qmail@web11803.mail.yahoo.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: Jim: What about mail lists that contain other MLAs? Consider: Originator --> MLA1 --> MLA2 --> Recipient When the message gets to the recipient, the outer signature belongs to the MLA2, and the inner signature belongs to the original Originator. The FROM address should indicate MLA2. Russ At 11:17 AM 9/1/2003 -0700, Jim Schaad wrote: >Suchet, > >The match of names only applies to the innermost layer on a triple >wrapped message. > >I am not sure what you mean by a mail merge functionality. It could be >one of two things: >1) merging a mail message with a database - in this case the correct >person to sign the message is the MLA since that is the entity that >actually sees the final message. >2) merging of multiple messages together in a summary. This could be >done in a method that perserves the original signatures, but I would >expect that they would actually be stripped. The types of MLAs that we >are working with would not provide this type of feature. > >jim > > > -----Original Message----- > > From: owner-ietf-smime@mail.imc.org > > [mailto:owner-ietf-smime@mail.imc.org] On Behalf Of suchet > > singh khalsa > > Sent: Wednesday, August 27, 2003 9:55 AM > > To: phoffman@imc.org > > Cc: ietf-smime@imc.org > > Subject: RFC 2634 Questions > > > > > > > > Hi Paul, > > Can you please answer the following questions w.r.t > > MLA processing of S/MIME messages : > > > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > > > > According to RFC 2632, while verifying signatures it > > should confirmed that the sender (RFC822 From or > > Sender headers) of the message is the same as the > > signed entity. Does this apply to ONLY the innermost > > signature in a triple wrapped message ? > > If no, this will impact MLA processing as documented > > in RFC 2634 in the following manner : > > > > 1. The MLA creates an outermost SignedData layer > > using the private key of the list. The final recipient > > will not be able to verify this signature since the > > From header is not the list email address. Is the > > solution here to set the list email address as the RFC > > 822 Sender header ? > > > > 2. Most MLA's support mail merge functionality. Is > > the intent of RFC 2634 to mandate that S/MIME and mail > > merge do not go hand in hand ? The reason for this > > question is : When MLA does mail merge, the innermost > > signature in a triple wrapped message will become > > invalid - so the MLA will have to sign with the > > private key of the list. So, the end recipient will > > not be able to verify this signature since the From > > header of the mail is not the list email address. > > > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > > > > RFC 2634 does not talk about this case : > > An application/pkcs7-mime bodypart is enclosed in > > another multipart, so that it is not the level 1 > > bodypart. What should the MLA do in this case ? > > Possibilities are : > > 1. Create the outermost signature (according to > > RFC2634 page 34) for the whole mail. > > > > 2. Create the outermost signature (according to > > RFC2634 page 34) only for the application/pkcs7-mime > > content. > > > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > > > > Thanks, > > Suchet > > > > __________________________________ > > Do you Yahoo!? > > Yahoo! SiteBuilder - Free, easy-to-use web site design > > software http://sitebuilder.yahoo.com > > Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h82DA4gc010786 for ; Tue, 2 Sep 2003 06:10:04 -0700 (PDT) (envelope-from owner-ietf-smime@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h82DA30t010785 for ietf-smime-bks; Tue, 2 Sep 2003 06:10:03 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-smime@mail.imc.org using -f Received: from smtp1.fre.skanova.net (smtp1.fre.skanova.net [195.67.227.94]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h82D9xgc010761; Tue, 2 Sep 2003 06:10:02 -0700 (PDT) (envelope-from anders.rundgren@telia.com) Received: from arport (t7o913p37.telia.com [213.64.26.37]) by smtp1.fre.skanova.net (8.12.9/8.12.9) with SMTP id h82D9tit005555; Tue, 2 Sep 2003 15:09:56 +0200 (CEST) Message-ID: <001501c37153$4ff1d960$0500a8c0@arport> From: "Anders Rundgren" To: , , Subject: Standards for Web-signing Date: Tue, 2 Sep 2003 15:07:33 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Folks, I just wanted to know the status of possible standardization efforts regarding signing on-line forms etc. on web. As web-signing is a core function of many e-governments when communicating with their citizens it seems that this should be standardized if not already is. Pointers are welcome. Off-list or on-list. rgds Anders Rundgren Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h81IGtgc024358 for ; Mon, 1 Sep 2003 11:16:55 -0700 (PDT) (envelope-from owner-ietf-smime@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h81IGtWW024357 for ietf-smime-bks; Mon, 1 Sep 2003 11:16:55 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-smime@mail.imc.org using -f Received: from smtp3.pacifier.net (smtp3.pacifier.net [64.255.237.173]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h81IGsgc024352 for ; Mon, 1 Sep 2003 11:16:54 -0700 (PDT) (envelope-from jimsch@nwlink.com) Received: from ROMANS (ip237.c132.blk1.bel.nwlink.com [209.20.132.237]) by smtp3.pacifier.net (Postfix) with ESMTP id BE69D6D8C2; Mon, 1 Sep 2003 11:16:54 -0700 (PDT) Reply-To: From: "Jim Schaad" To: "'suchet singh khalsa'" Cc: Subject: RE: RFC 2634 Questions Date: Mon, 1 Sep 2003 11:17:39 -0700 Message-ID: <00a001c370b5$543f6c60$1400a8c0@augustcellars.local> 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.1165 In-Reply-To: <20030827165524.2132.qmail@web11803.mail.yahoo.com> Importance: Normal Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Suchet, The match of names only applies to the innermost layer on a triple wrapped message. I am not sure what you mean by a mail merge functionality. It could be one of two things: 1) merging a mail message with a database - in this case the correct person to sign the message is the MLA since that is the entity that actually sees the final message. 2) merging of multiple messages together in a summary. This could be done in a method that perserves the original signatures, but I would expect that they would actually be stripped. The types of MLAs that we are working with would not provide this type of feature. jim > -----Original Message----- > From: owner-ietf-smime@mail.imc.org > [mailto:owner-ietf-smime@mail.imc.org] On Behalf Of suchet > singh khalsa > Sent: Wednesday, August 27, 2003 9:55 AM > To: phoffman@imc.org > Cc: ietf-smime@imc.org > Subject: RFC 2634 Questions > > > > Hi Paul, > Can you please answer the following questions w.r.t > MLA processing of S/MIME messages : > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > > According to RFC 2632, while verifying signatures it > should confirmed that the sender (RFC822 From or > Sender headers) of the message is the same as the > signed entity. Does this apply to ONLY the innermost > signature in a triple wrapped message ? > If no, this will impact MLA processing as documented > in RFC 2634 in the following manner : > > 1. The MLA creates an outermost SignedData layer > using the private key of the list. The final recipient > will not be able to verify this signature since the > From header is not the list email address. Is the > solution here to set the list email address as the RFC > 822 Sender header ? > > 2. Most MLA's support mail merge functionality. Is > the intent of RFC 2634 to mandate that S/MIME and mail > merge do not go hand in hand ? The reason for this > question is : When MLA does mail merge, the innermost > signature in a triple wrapped message will become > invalid - so the MLA will have to sign with the > private key of the list. So, the end recipient will > not be able to verify this signature since the From > header of the mail is not the list email address. > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > > RFC 2634 does not talk about this case : > An application/pkcs7-mime bodypart is enclosed in > another multipart, so that it is not the level 1 > bodypart. What should the MLA do in this case ? > Possibilities are : > 1. Create the outermost signature (according to > RFC2634 page 34) for the whole mail. > > 2. Create the outermost signature (according to > RFC2634 page 34) only for the application/pkcs7-mime > content. > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > > Thanks, > Suchet > > __________________________________ > Do you Yahoo!? > Yahoo! SiteBuilder - Free, easy-to-use web site design > software http://sitebuilder.yahoo.com > Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h817NDgc057825 for ; Mon, 1 Sep 2003 00:23:13 -0700 (PDT) (envelope-from owner-ietf-smime@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h817ND19057824 for ietf-smime-bks; Mon, 1 Sep 2003 00:23:13 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-smime@mail.imc.org using -f Received: from web11807.mail.yahoo.com (web11807.mail.yahoo.com [216.136.172.161]) by above.proper.com (8.12.9/8.12.8) with SMTP id h817NCgc057813 for ; Mon, 1 Sep 2003 00:23:12 -0700 (PDT) (envelope-from suchetsinghkhalsa@yahoo.com) Message-ID: <20030901072312.51857.qmail@web11807.mail.yahoo.com> Received: from [148.87.1.171] by web11807.mail.yahoo.com via HTTP; Mon, 01 Sep 2003 00:23:12 PDT Date: Mon, 1 Sep 2003 00:23:12 -0700 (PDT) From: suchet singh khalsa Subject: Re: RFC 2634 Questions To: phoffman@imc.org Cc: ietf-smime@imc.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Hi, Resending due to no response. Can anybody please help me with these questions... Thanks in advance, Suchet --- suchet singh khalsa wrote: > Hi Paul, > Can you please answer the following questions > w.r.t > MLA processing of S/MIME messages : > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > > According to RFC 2632, while verifying signatures it > should confirmed that the sender (RFC822 From or > Sender headers) of the message is the same as the > signed entity. Does this apply to ONLY the innermost > signature in a triple wrapped message ? > If no, this will impact MLA processing as documented > in RFC 2634 in the following manner : > > 1. The MLA creates an outermost SignedData layer > using the private key of the list. The final > recipient > will not be able to verify this signature since the > From header is not the list email address. Is the > solution here to set the list email address as the > RFC > 822 Sender header ? > > 2. Most MLA's support mail merge functionality. Is > the intent of RFC 2634 to mandate that S/MIME and > mail > merge do not go hand in hand ? The reason for this > question is : When MLA does mail merge, the > innermost > signature in a triple wrapped message will become > invalid - so the MLA will have to sign with the > private key of the list. So, the end recipient will > not be able to verify this signature since the From > header of the mail is not the list email address. > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > > RFC 2634 does not talk about this case : > An application/pkcs7-mime bodypart is enclosed in > another multipart, so that it is not the level 1 > bodypart. What should the MLA do in this case ? > Possibilities are : > 1. Create the outermost signature (according to > RFC2634 page 34) for the whole mail. > > 2. Create the outermost signature (according to > RFC2634 page 34) only for the application/pkcs7-mime > content. > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > > Thanks, > Suchet > > __________________________________ > Do you Yahoo!? > Yahoo! SiteBuilder - Free, easy-to-use web site > design software > http://sitebuilder.yahoo.com > __________________________________ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com