[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: Re: Threat assessment,some dissent RE: [ebxml-msg] security problemwith ebXML MS
> 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. > 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. > In security there are purists who insist on doing everything possible > and doing it right. Even if one takes a more pragmatic view, the goal > needs to be that whatever you do you must do it right. Adding digital > signatures that leave a clear and present vulnerability, however small, > is analogous to putting steel doors on a wooden house that still has > windows without bars. Physicians have the rule "first, do no harm." I always figured security's analog is "first, document what is done." :) If the windows are 20 feet up and the wooden is 8' redwood, that might be a valid security decision. 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. The market will decide. I betcha most businesses deploying ebXML over HTTP over VPN will not favor the vendor who spends the extra time and complexity. :) /r$ -- Zolera Systems, Your Key to Online Integrity Securing Web services: XML, SOAP, Dig-sig, Encryption http://www.zolera.com
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC