[Top] [All Lists]

RE: Protection of header elements in an S/MIME message

2005-01-14 15:50:31


The main reason seems to be that they do not want to change any client
e-mail applications, and do not want to have extranious attachments showing
up on clients systems.

I have never been a fan of the embedded message solution, but it is the
simpliest available from a specification standpoint.  This solution however
does NOT solve the problem of matching headers.  We just did not address it
in the detail that we should have done in the S/MIME working group.

Anyway the MASS objections to using S/MIME seem to be:

1) We don't want to buy into a universal CA trust hierarchy for cost and
complexity reasons.
2) We don't want to alter MUAs to deal with S/MIME or to show attachments to
clients for those people who do not "opt into the system".
3) We need a way to protecting header information.  This is not well covered
in the S/MIME documents or current thought processes.  Most people tend to
think of S/MIME as a body only coverage technique.


-----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 Bonatti, 
Sent: Wednesday, January 12, 2005 11:00 AM
To: jimsch(_at_)exmsft(_dot_)com
Cc: rohan(_at_)ekabal(_dot_)com; 'Russ Housley'; ietf-smime(_at_)imc(_dot_)org
Subject: RE: Protection of header elements in an S/MIME message

Jim Schaad <jimsch(_at_)exmsft(_dot_)com> wrote:

I think that we may need to revisit the issue of how S/MIME 

In doing some consulting for other groups in the IETF I have found 
that there are now four different groups that need a better 
to this

S/MIME - uses an encapsulated message  (message/rfc822) SIP 
- uses an 
encapsulated message (message/sip) PGP - uses an 
encapsulated message 
(message/rfc822) [I may be putting words into the PGP 
working groups 
collective mouths] MASS - a new proposed working group looking at 
providing authorization information on e-mail messages - no current

All of these groups would benefit if we define a standard 
way to allow 
for inclusion of RFC822 headers in a message body along 
with rules for 
comparision between the acutal header and the embedded header.

I would recommend looking at RFC 3261 section 23.4.1 for a 
of how SIP handled the comparison problem between the outer 
and inner 

The MASS group would not be open to saying that the correct 
answer is 
to have an embedded message that is promoted when found.  I 
don't know 
if this has been implemented by any S/MIME implemenation I would be 
surprised if it was widely

Actually, it strikes me that S/MIME, SIP and PGP have all 
adopted the same solution: encapsulate what you want 
protected.  They've just have taken slightly different 
approaches to how you deal with what's there.  I'm curious as 
to why MASS would not be open to this type of approach.

It has always seemed to be that it would be easy to have a 
general attribute that could contain any RFC 822 header.  Of 
course, you STILL have to specify how and to what extent 
matching is done... which would probably have to be 
application specific.
So we're right back to where we are today.


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