RE: RFC 2634 Questions

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

Suchet,

> -----Original Message-----
> From: [e-mail] 
> [mailto:[e-mail]] On Behalf Of suchet 
> singh khalsa
> Sent: Saturday, September 06, 2003 9:00 AM
> To: [e-mail]
> Cc: [e-mail]; [e-mail]
> Subject: RE: RFC 2634 Questions
> 
> 
> 
> 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.

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

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

Item for the update of RFC 2634

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

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
> 
> Thanks,
> Suchet
>  
> --- Jim Schaad <[e-mail]> wrote:
> > 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
> > > > >
> > > 
> > 
> 
> 
> __________________________________
> Do you Yahoo!?
> Yahoo! SiteBuilder - Free, easy-to-use web site design 
> software http://sitebuilder.yahoo.com
>