On Tue, 13 Nov 2001, Rich Salz wrote: > The specification is ambiguous regarding the significance of MIME > headers for payloads. That is a good point, but one that realistically can be fixed in the documentation. Agreed. What originally motivated my concern is that the specification asserts that persistent authentication can be achieved with the use of XML Digital Signatures when in fact it's not quite that simple. > An adversary could construct a body part that would pass the digest > calculation but the actual content would cause an implementation to > take actions other than what was intended. Do I misunderstand, or isn't that equivalent to saying an adversary can find a hash collision? If that's a concern, aren't *all* digital signatures at risk? Or do I misunderstand. I had to go back and find the message with that statement in it to make sure I hadn't gone off the deep end! :-) You would be correct except that it was my intention for the context of my statement to reflect that the MIME headers are not part of the digest calculation indicated. Thus, the digest calculation would pass because only the payload was originally signed. In such a scenario an adversary could create an alternate body part with different MIME headers that would pass the signature validation and, if any dispatching or processing is the result of information in the MIME headers, the resulting actions would be indeterminate. Physicians have the rule first, do no harm. I always figured security's analog is first, document what is done. :) I like it! > ... the goal > needs to be that whatever you do you must do it right. If the spec is going to leave the ambiguity, then it probably should say why headers might need to be protected, and it should definitely say HOW to do so. I'm neutral on the if , but think the the then should be done. Agreed! Jim