ietf-smime
[Top] [All Lists]

RE: RFC 2634 Questions

2003-09-05 11:24:09

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:housley(_at_)vigilsec(_dot_)com] 
Sent: Friday, September 05, 2003 10:22 AM
To: jimsch(_at_)exmsft(_dot_)com; 'suchet singh khalsa'
Cc: ietf-smime(_at_)imc(_dot_)org
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: 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>