Chris,
Jim has eloquently addressed the interesting points you raised.
Let me address some relevant issues that were touched upon earlier.
1. We are ONLY addressing the "data integrity" problem (RFC 2828 is the
glossary
for all security terms I am using). To detect a data integrity breach,
it is sufficient for some "processor" in the chain to throw an "error." Note
that signature serves the same purpose. Let us apply the same logic to MIME
message.
In MIME, the payloads are referenced using Content-ID. If the Content-ID of
the first payload (referenced by "start") is changed, then the MIME
processor or ebXML Envelope processor would throw an error. If any of the
Content-ID of the other payloads
is changed, either MIME processor will throw an error, or ds:Signature
verifier will throw an error. An interesting conclusion is that Content-ID
need not be repeated and signed in eb:Manifest. (I will reflect this in my
earlier proposal unless anybody has objections)
2. The MIME headers of the SOAP envelope of interest (Content-Type) is
text/xml,
and is standard. Content-ID, as discussed in (1) above, is not of interest.
Therefore, I do not see the need to secure the MIME headers of the SOAP
envelope. It would be a prudent thing to check that the Content-Type is
indeed "text/xml" for SOAP envelope. (I will add a note to this effect in
the proposal)
3. The real threat is that the application payload headers may be changed,
and we don't have a way to detect that. The problem is real, and this
proposal addresses exactly that problem.
Cheers,
-Suresh