Blake,
MASS I think is going to fail because they are trying to solve the problem
without upsetting anybody by adding some attachements. The solution that
MASS has proposed and SIP has adopted basically involve copying the headers
into a signed portion of the message and then specifying rules for how you
deal with mis-matched headers.
In both cases not all headers are being copied, only specific headers.
Actually given the text that you have in the message draft, I consider it to
be useless and I don't know of anybody who is going to be able to deal well
with the message. Its not very backwards compatable (i.e. no current
implementation will handle it well) and its not well defined for how header
comparision is done.
Since MASS is not using S/MIME in any way shape or form, I doubt you are
offending them.
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 Blake
Ramsdell
Sent: Tuesday, February 01, 2005 4:01 AM
To: jimsch(_at_)exmsft(_dot_)com
Cc: ietf-smime(_at_)imc(_dot_)org; rohan(_at_)ekabal(_dot_)com; 'Russ Housley'
Subject: Re: Protection of header elements in an S/MIME message
Jim Schaad wrote:
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.
This is by far the biggest area we wussed out on from my
perspective. I think it was an intractable rathole, however,
so I will defend my wussiness.
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.
I'm not going to speculate on the adoption, but I would be
curious what options are being considered, especially for the
purpose of privacy protecting headers (not just digital signatures).
If it's the "list all the headers that are covered by the signature"
approach which I think is used by both DomainKeys and IIM,
we'd need to supplement that with a solution to handle
privacy protected headers, in order for it to be suitable for
S/MIME and/or OpenPGP.
I think there is some peril here, Jim -- in one sentence you
warn us that MASS won't use an embedded header approach,
right after you explain that SIP (and S/MIME) use that exact approach.
The good news is that means I'm completely offending only one
of the four people we're supposed to help with the initial
direction that I would suggest (using the current S/MIME
strategy with better defined rules about header merging).
So should we take this on? Where do people stand on this?
I've had enough time to recharge from the last beat-down I
took from this issue that I'd probably suit up and take some hits.
Blake
--
Blake Ramsdell | Sendmail, Inc. | http://www.sendmail.com