Re: [wss] Recently discover WSS security threat

[Duane Nickull <dnickull@adobe.com>]

I am a bit confused by this  thread.  If an application encounters
...
<my:header>
   <my:integer>33</my:integer>
</my:header>

all it can see is 33 as the node content, not 32. That is representative 
of the current state of the fragment.

To me the conversation is moot. I cannot sing something I cannot see nor 
should I.  Did I miss something?

Duane Nickull
Adobe Systems, Inc.


DeMartini, Thomas wrote:

>] > Consider I have a header that looks like this:
>] >
>] > <my:header>
>] >   <my:integer>32</my:integer>
>] > </my:header>
>] >
>] > Now suppose I reference the envelope, run an XPath as you described
>to
>] > select just my:header and all its descendents, and then run a custom
>] > transform to increment all integers by 1.  The signed data looks
>like
>] > this:
>] >
>] > Reference 1:
>] > <my:header>
>] >   <my:integer>33</my:integer>
>] > </my:header>
>] > Reference 2:
>] > <soap:Body>...<soap:Body>
>] >
>] > What does the application see as the authentic data?  32 or 33?
>] > According to the DSIG spec, the answer is 33.
>] 
>] I disagree. The DSIG specification discribes how to create and verify
>] signatures. It does not discribe what gets passed to applications.
>
>It says, "Just as a user should only sign what he or she "sees," persons
>and automated mechanism that trust the validity of a transformed
>document on the basis of a valid signature should operate over the data
>that was transformed (including canonicalization) and signed, not the
>original pre-transformed data."
>
>33 is the data that was transformed and signed.
>32 is the original pre-transformed data.
>
>I think it is very clear that receivers in this case should operate on
>33.
>
>] > But now let me ask you,
>] > if a receiver follows the processing model you described, where does
>it
>] > determine that the 33 resides in the message?
>] 
>] I don't think most people would use transforms specified for signature
>] verification to obfuscate data.
>
>I wasn't trying to obfuscate data, just give an example of a transform
>that is semantically important.
>
>] > The signed data looks like this:
>] >
>] > Reference 1:
>] > <soap:Envelope>
>] >   <soap:Header>
>] >     <my:header>
>] >       <my:integer>33</my:integer>
>] >     </my:header>
>] >   </soap:Header>
>] >   <soap:Body>...</soap:Body>
>] > </soap:Envelope>
>] >
>] > I see no more room for ambiguity.  Clearly the authentic data is 33
>and
>] > its relationship to the soap:Body is specified by the soap:Envelope.
>] 
>] So using your alternative if there where multiple References in the
>] signature
>] the application would receive a complete SOAP Envelope for each?
>
>If each reference referred to the SOAP Envelope, then, yes, the
>application would receive a complete SOAP Envelope for each.  However, I
>see little reason why a sender would actually use multiple Envelope
>References in my case.  Rather they would just make sure their one
>Envelope Reference included everything from the Envelope they wanted to
>sign.
>
>] I think your solution provides the same level of protection as the
>simple
>] XPath.
>] However, your solution requires a more complex XPath expression and is
>] therefore
>] harder to use and probably less efficient.
>
>Looking at the XPath expressions for each approach, I don't see any
>difference in complexity.  If you see one, perhaps you can give examples
>that we could use to quantify the difference?
>
>&Thomas.
>
>
>---------------------------------------------------------------------
>To unsubscribe from this mail list, you must leave the OASIS TC that
>generates this mail.  You may a link to this group and all your TCs in OASIS
>at:
>https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php 
>
>  
>