RE: RFC 2634 Questions

["Jim Schaad" <[e-mail]>]

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:[e-mail]] 
> Sent: Friday, September 05, 2003 10:22 AM
> To: [e-mail]; 'suchet singh khalsa'
> Cc: [e-mail]
> 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: [e-mail] 
> > > [mailto:[e-mail]] On Behalf Of suchet singh 
> > > khalsa
> > > Sent: Wednesday, August 27, 2003 9:55 AM
> > > To: [e-mail]
> > > Cc: [e-mail]
> > > 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
> > >
>