After reading all of the messages on this topic, I'm unsure what you two
have agreed. Are you saying it's necessary to mention a possible threat
with changed MIME headers (because they aren't captured by the digest over
any payload) or that we must solve the problem? As described below, I'm
probably missing a few things.
I remain unsure about the level of this threat. You're talking about
changing the MIME headers for the payload containers, all of which are
ancillary to the primary part -- the SOAP message containing the ebXML
extensions we're busy defining. After that primary part has been handled by
a SOAP processor (utilising relevant ebXML MSH handlers), does SOAP require
or even support dispatching the remaining parts using a "generic" MIME
processor? Is their any MIME header (assuming the CTE is handled prior to
payload digest calculation) other than Content-type that a MIME dispatcher
would use? That last point goes towards the generic nature of both the
original proposal and all amendments I've seen discussed.
By the way, even Content-type can legitimately change in transit. An HTTP
proxy that chooses to forward information in a different character set
should update or add the charset parameter. I also think it's allowed to
take a multipart message apart and rebuild it using a different boundary.
Probably fringe use cases but possible downfalls to a solution in this area.
If we say this is a real problem and it must be solved, do SOAP processors
even make the MIME headers available to handlers (such as a signature
verifier) in a consistent fashion? For example, do current implementations
of SOAP with Attachments all even pass that information to the SOAP
handlers? Do they pass all headers or only provide things the handler
requests "on demand" (resulting in ordering differences)?
help,
doug