Scott Cantor schrieb:
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?
Well looking at the documentation of the KeyInfo class it says that it will look for "ds:KeyInfo" when constructed from an element. This is missing when "creating from scratch" but one can assume the KeyInfo is somewhat symmetric in its usage, thus also takes care of the ds: and namespace handling. IMHO, if an element creation class has do deal with specific and well defined namespaces that it should be the task of this class to take care of this. KeyInfo class creates an element with a namespace prefix, thus it should also add the necessary namespace attribute to it. In WSS4J we do it similarly: we return a full Doc tree where elements have their associated namespaces attributes thus the application does not need to know about the specific/efined namespaces. At least it seems that this modification in xmlsec-1.4.2 has some impacts on other applications as well because this modification broke an "assumed" contract. Regards, Werner
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
