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

 


Help: OASIS Mailing Lists Help | MarkMail Help

wss message

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


Subject: RE: [wss] Recently discover WSS security threat


] Bottom line, I contend that if you can provide an XML Document, I can
] provide an associated ds:Signature that will allow a receiver to
detect
] whether any element (your choice) was moved/altered/removed within
that
] document.

Believe me, your point that "all the information a receiver needs is
there" is not lost on me, and I have no doubt you could provide such
information in signature form.

Do you think that the same could not be done with the style of signature
I am recommending?

The difference I think between the two proposals comes down to a) which
is normative behaviour according to DSIG and b) which can be more easily
generalized to account for other transforms.

I think preserving any necessary location information in the data object
to be signed is better suited for both a) and b).

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.  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?  And what is its
location-relationship to the soap:Body?

Now consider the same example message, except this time the signature is
constructed using a reference to the envelope, a transform to select the
envelope, header, body, and my:header, and a custom transform to
increment all integers by 1.  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.

&Thomas.



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