OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

ebxml-msg message

[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

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

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



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]

Powered by eList eXpress LLC