ietf-smime
[Top] [All Lists]

RE: RFC 2634 Questions

2003-09-05 10:21:53

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(_at_)mail(_dot_)imc(_dot_)org
> [mailto:owner-ietf-smime(_at_)mail(_dot_)imc(_dot_)org] On Behalf Of suchet
> singh khalsa
> Sent: Wednesday, August 27, 2003 9:55 AM
> To: phoffman(_at_)imc(_dot_)org
> Cc: ietf-smime(_at_)imc(_dot_)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
>


<Prev in Thread] Current Thread [Next in Thread>