- From: Frederick Hirsch <frederick.hirsch@nokia.com>
- Date: Tue, 11 May 2010 13:30:57 -0400
- To: ext Meiko Jensen <Meiko.Jensen@rub.de>
- Cc: Frederick Hirsch <frederick.hirsch@nokia.com>, Thomas Roessler <tlr@w3.org>, XMLSec WG Public List <public-xmlsec@w3.org>
Doesn't this case mean that the entire document is signed, thus including more that if only the intended XPath evaluated properly? If so, isn't this safe since more is included in the signature generation and not less? In this case it is more likely signature verification will fail due to changes that weren't intended to have been covered by the signature? (all this assumes the XPath was for a portion of the same document) regards, Frederick Frederick Hirsch Nokia On May 11, 2010, at 12:57 PM, ext Meiko Jensen wrote: > Yes it is, and of course, one should only process what was signed. > However, I know lots of real-world scenarios in the Web Services world > where this is not applied. You process and rely on the soap envelope, > even if it is not signed at all. You have to in order to find the > signature within the header. In the same way, for the Web Services > case, > signature validation and application logic may be separated in a way > that prohibits the see-what-was-signed approach (e.g. as a dedicated > Web > Service Security Gateway). > > For all such cases that do not sufficiently follow the "good > principles" > such a restriction may turn out to be rather helpful, and I don't > see a > legal use case that would suffer from it (besides one of our ongoing > academic approaches, but that's a different issue). > > However, as before, I do not insist in having it in. I just recommend > it, based on my (and my colleague's) experience. > > best regards > > Meiko > > Thomas Roessler wrote: >> Isn't this another instance of the more general effect that one >> shouldn't trust anything -- except for what one gets out of, e.g., >> evaluating a particular xpath? >> >> The real problem in the scenario you describe seems to be that >> neither side verifies that the xpath is what it's believed to be. >> -- >> Thomas Roessler, W3C <tlr@w3.org> (@roessler) >> >> >> >> >> >> >> >> On 11 May 2010, at 17:46, Meiko Jensen wrote: >> >> >>> Within the discussion on the XPath referencing style I remembered an >>> issue we came across lately: >>> >>> If an XPath contains syntactical errors, this does not result in a >>> visible error. It is only treated differently, and might just >>> result in >>> referencing no node in the actual XML document. If that is not >>> considered as an error in the XML Signature specification, there >>> is a >>> threat of someone screwing it up without noticing. Even the verifier >>> does not notice: nothing was referenced, so the digest is calculated >>> about the empty nodeset, hence about "". As this was exactly the >>> same >>> input as at the signer side, hash values match => signature is >>> valid. >>> However, it protects nothing in the document from modification. >>> >>> Hence, I recommend putting a sentence to XML Signature 2.0 stating >>> that >>> a reference to an empty nodeset MUST be treated as a fault. >>> >>> best regards >>> >>> Meiko >>> >>> -- >>> Dipl.-Inf. Meiko Jensen >>> Chair for Network and Data Security >>> Horst Görtz Institute for IT-Security >>> Ruhr University Bochum, Germany >>> _____________________________ >>> Universitätsstr. 150, Geb. IC 4/150 >>> D-44780 Bochum, Germany >>> Phone: +49 (0) 234 / 32-26796 >>> Telefax: +49 (0) 234 / 32-14347 >>> http:// www.nds.rub.de >>> >>> >>> >>> >> >> > >
Received on Tuesday, 11 May 2010 17:32:02 UTC