RE: RFC 2634 Questions
"Jim Schaad" <jimsch@nwlink.com> Mon, 01 September 2003 18:55 UTC
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 <smime-archive@lists.ietf.org>; 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 <ietf-smime-bks@above.proper.com>; 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 <ietf-smime@imc.org>; 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: jimsch@exmsft.com
From: Jim Schaad <jimsch@nwlink.com>
To: 'suchet singh khalsa' <suchetsinghkhalsa@yahoo.com>
Cc: ietf-smime@imc.org
Subject: RE: RFC 2634 Questions
Date: Mon, 01 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: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:ietf-smime-request@imc.org?body=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 >
- RFC 2634 Questions suchet singh khalsa
- Re: RFC 2634 Questions suchet singh khalsa
- RE: RFC 2634 Questions Jim Schaad
- RE: RFC 2634 Questions Russ Housley
- RE: RFC 2634 Questions Jim Schaad
- RE: RFC 2634 Questions suchet singh khalsa
- RE: RFC 2634 Questions Jim Schaad