Dale,
Long and interesting message. The message leads me to believe
you are in agreement that there is a risk in not signing MIME headers,
though you are skeptical of the cost of the risk, and wondering
loud whether the risk is addressed otherwise. Those are very
reasonable thoughts.
1. My principal argument for supporting selective MIME header
inclusion for signing is to detect data integrity breach *within MSH*.
XMLDSIG provides a mechanism for it,
but if we do not include all the relevant info to be signed,
we are drilling a hole(albeit small) in the floating boat.
Some day, water will get to it, and the boat will sink.
Data integrity can be breached by MITM, and can cause
DoS or other kinds of problems. IMO, any information that
can help detect data integrity breach by an MSH should
be signed, otherwise there is no meaning in saying that
secure MSH can provide data integrity. Just using XMLDSIG
doesn't cut it unless we use it right.
2. Note that my proposal is for ensuring integrity of all
Payload processing information that needs to be conveyed.
If it helps, view the MIME headers as processing info
that needs protection from tampering and to be detected by MSH.
Application may provide other payload processing info that need protection.
As Jim said earlier, patching in security later when we move
from peer-to-peer to multi-hop is worse than biting the bullet now.
As an implementer, I do not want to do the same thing several different
ways. Nobody wants to be in backward compatibility hell,
especially while interoperating! Let us do it right as early as possible.
It is a bit of work, but I think we can do it.
Therefore, I do believe we need to consider the problem and provide
a solution (my proposal is an attempt at it) before we have many
implementations.
Best,
-Suresh