[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]