RE: RFC 2634 Questions

Russ Housley <housley@vigilsec.com> Fri, 05 September 2003 17:59 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 NAA09326 for <smime-archive@lists.ietf.org>; 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 <ietf-smime-bks@above.proper.com>; 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 <ietf-smime@imc.org>; 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: jimsch@exmsft.com, 'suchet singh khalsa' <suchetsinghkhalsa@yahoo.com>
From: Russ Housley <housley@vigilsec.com>
Subject: RE: RFC 2634 Questions
Cc: ietf-smime@imc.org
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: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:ietf-smime-request@imc.org?body=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
> >