> thanks for your hints :-) . Of course - the xmlns:ds attribute is the > important part. After checking the attributes of KeyInfo it turned out > that no xmlns:ds attribute was found.
I figured. > This functions differs between 1.4.1 and 1.4.2 in some important lines when > it comes to add the xmlns:ds attribute to the KeyInfo element (see code > snippets below). Why was this modification done? I couldn't finddocumentation > about this on the xmlsec Web pages. Does KeyInfo expect the user of KeyInfo > to set the xmlns:ds attribute? Or is it just a simple, plain old bug? :-) Well, the bug is holistic. What I mean, and this is what I meant in my original comment, is that the bug is a consequence of the inconsistent XML handling across the range of libraries. It could be viewed as a bug in lots of places. In this specific case, I think it's probably easy to argue that the xmlsec library has no reason not to declare that namespace, I suppose, but ultimately what xmlsec needs to do is define the contract...what is it prepared to promise about the DOM it gives you? You have to work from that contract, or (as in the case of OpenSAML) build your own XML processing model that takes the responsibility on. But it's also too easy to say "the caller has to fix up namespaces", because unfortunately those namespaces are intrinsic to the signature process. You can't just add them later and expect it to work. -- Scott
