Subject: RE: RFC 2634 Questions

From: "Jim Schaad" <[email-masked]>
Date: Mon, 1 Sep 2003 11:17:39 -0700

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: [email-masked] 
> [mailto:[email-masked]] On Behalf Of suchet 
> singh khalsa
> Sent: Wednesday, August 27, 2003 9:55 AM
> To: [email-masked]
> Cc: [email-masked]
> 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: Russ Housley <[email-masked]>
Date: Fri, 05 Sep 2003 13:21:46 -0400

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

---

From: "Jim Schaad" <[email-masked]>
Date: Fri, 5 Sep 2003 11:25:01 -0700

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

> From: Russ Housley [mailto:[email-masked]] 
> Sent: Friday, September 05, 2003 10:22 AM
> To: [email-masked]; 'suchet singh khalsa'
> Cc: [email-masked]
> Subject: RE: RFC 2634 Questions
> 
> 
> Jim:
> 
> > > [mailto:[email-masked]] On Behalf Of suchet singh 
> > > khalsa
> signature in a 
> > > triple wrapped message ? If no, this will impact MLA 
> processing as 
> > > documented in RFC 2634 in the following manner :
> > >
> 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
> > > RFC2634 page 34) only for the application/pkcs7-mime content.
> > >
> > > Yahoo! SiteBuilder - Free, easy-to-use web site design software 
> > > http://sitebuilder.yahoo.com
> > >
>

---

From: suchet singh khalsa <[email-masked]>
Date: Sat, 6 Sep 2003 08:59:32 -0700 (PDT)

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 <[email-masked]> wrote:
> > 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 
> > >I am not sure what you mean by a mail merge
> functionality.  
> > It could be 
> > >one of two things:
> > >2) merging of multiple messages together in a
> summary.  This 
> > could be 
> > >expect that they would actually be stripped.  The
> types of 
> > MLAs that we

---

From: "Jim Schaad" <[email-masked]>
Date: Sat, 6 Sep 2003 15:23:42 -0700

Suchet,

> Sent: Saturday, September 06, 2003 9:00 AM
> To: [email-masked]
> Cc: [email-masked]; [email-masked]

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...

> 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

> 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