On Wed, 7 Nov 2001, Christopher Ferris wrote: This proposal seems to imply that MIME processing/parsing of the message is limited exclusively to the first body part of the multipart/related MIME object (the SOAP Envelope) and that all subsequent processing of the multipart/related object is driven by the contents of the MIME header info contained within the Manifest. I'm not speaking for Suresh but based on my discussions with him your understanding is not the intent. The intent is what you would expect, thus we simply need to clarify the text. All MIME processing can and should proceed as before. At issue is simply the fact that the MIME headers for the body parts that comprise payloads inside the outermost multipart/related are not protected. This is a security problem. What Suresh is proposing is that the MIME headers (appropriately canonicalized) for body parts that are payloads in the outermost multipart/related should be duplicated in the SOAP Envelope. This ensures they receive the same protection as the SOAP Envelope itself. The only other additional step, which David described, is to decide if these MIME headers are to be compared to the received MIME headers by the receiving agent or, perhaps, they should simply replace the received headers. Of course, both of these options mean that the Content-ID: header of the actual payload has to be believed regardless, but if it's been modified later security checks will fail anyway. In addition, the issue raised suggests that ALL MIME headers, including those that comprise the multipart/related envelope and those of the start object (the SOAP Envelope) would need to be protected, or maybe I'm missing something. Yes, my wording is ambiguous but in fact the the two sets of MIME headers of which you speak need not be protected. The outermost headers (those of the multipart/related) don't need to be protected because if they've been modified your threat is denial of service. Since there is no protection for this anyway there is no issue. The MIME headers on the first body part do not need to be protected because you can simply ignore them. By definition the first body part of the outermost multipart/related is the SOAP Envelope and as long as you process it that way there is no additional threat. Further, I don't think that it is the responsibility of the OASIS ebXML Messaging TC to specify MIME header C14N. I would think that if this s to be done at all that the ownership and responsibility for this would belong squarely in the IETF camp. This is a minor process issue in my opinion. In fact canonicalizing MIME headers is not an issue for the MIME community (and has not yet been an issue for any other community in the IETF). The reason is because MIME has support for security services and the issue the ebXML community is having is addressed differently. As author of that specification (RFC1847) I can tell you that the reason MIME does not have this problem is because the first body part of a multipart/signed is defined to be immutable, which includes both header and content. Thus, signatures are not at risk of having the MIME headers defining the content changed. ebXML has this problem because you are mixing technologies, specifically XML and MIME. It is always true in security that when you mix technologies you will have issues with the relationship and integration. What we are doing here is acknowledging those issues and offering a solution for them. The reason it is a minor process issue is because I believe there is no problem with this group defining the transform it needs to canonicalize MIME headers for its purposes. In fact, I think this is the right solution because canonicalization for this group means to not include headers whose purpose is solely for transport . In particular, canonicalization for this group would exclude duplicating the Content-Transfer-Encoding: header. If the IETF were to specify canonicalization it would indicate how to canonicalize this header and then you would still need your own transform because you would still want to exclude this header. Jim