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

From: "Jim Schaad" <[email-masked]>
Date: Tue, 11 Jan 2005 14:31:23 -0800

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

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

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

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 description of
how SIP handled the comparison problem between the outer and inner headers.

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

Jim

---

From: "Bonatti, Chris" <[email-masked]>
Date: Wed, 12 Jan 2005 13:59:45 -0500

Jim Schaad <[email-masked]> wrote:
> 
> I think that we may need to revisit the issue of how S/MIME 
> protects headers.
> 
> In doing some consulting for other groups in the IETF I have 
> found that there are now four different groups that need a 
> better solution to this
> problem:
> 
> 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
solution.
> 
> 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 
> description of how SIP handled the comparison problem between 
> the outer and inner headers.
> 
> 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
adopted.

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.

Chris

---

From: "Jim Schaad" <[email-masked]>
Date: Fri, 14 Jan 2005 15:00:20 -0800

Chris,

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.

jim

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Bonatti, Chris
> Sent: Wednesday, January 12, 2005 11:00 AM
> To: [email-masked]
> Cc: [email-masked]; 'Russ Housley'; [email-masked]
> Subject: RE: Protection of header elements in an S/MIME message
> 
> 
> protects 
> > In doing some consulting for other groups in the IETF I have found 
> > that there are now four different groups that need a better 
> solution 
> > to this
> > problem:
> > 
> > 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
> solution.
> > 
> > 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 
> description 
> > of how SIP handled the comparison problem between the outer 
> and inner 
> > headers.
> > 
> 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
> adopted.
> > 
> 
> 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.
> 
> course, you STILL have to specify how and to what extent 
> matching is done... which would probably have to be 
> application specific.

---

From: Russ Housley <[email-masked]>
Date: Sat, 22 Jan 2005 14:07:36 -0500

I think that working on a specification in this area would help a lot of 
future efforts.  I encourage the working group to discuss this topic at 
IETF 62.  If there is consensus, then the WG should request an extension to 
the charter.

Russ