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
>