You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@santuario.apache.org by "Peter B. West" <li...@pbw.id.au> on 2008/10/01 01:53:09 UTC
Re: Undeclared namespace prefix
Sean,
Is is still necessary to file a new bug for this, or has Werner's work
covered this?
Peter
sean.mullan wrote:
>
> I don't know what the cause of this regression could be.
>
> The best thing to do is for Arnaud or Peter to file a new bug at
> http://issues.apache.org/bugzilla under the Security project and if
> possible,
> attach a standalone (i.e. not dependent on WSS4J) test case that
> reproduces the
> problem.
>
> Thanks,
> Sean
>
> Werner Dittmann wrote:
>> All,
>>
>> why did it work with 1.4.0 and 1.4.1 then? Were these two version
>> buggy in that case? Or what was changed in 1.4.2 to get this
>> incompatible behaviour?
>>
>> Because we use it in WSS4J we always rely on the backward compatibility.
>> Changing the WSS4J code just to circumvent a problem would cause a major
>> effort to many applications that actually use WSS4J. Before changing
>> WSS4J we shall check if a fix in xmlsec is more appropriate.
>>
>> Regards,
>> Werner
>>
>> Arnaud schrieb:
>>> Peter B. West <lists <at> pbw.id.au> writes:
>>>
>>>> Arnaud,
>>>>
>>>> I'm using 1.4.2, and the problem I had may not be the same as yours,
>>>> but
>>>> see my messages "Unbound prefix after decryption".
>>>>
>>>> In my case, the problem was that the DOM being passed for encryption id
>>>> not have the xmlns attribute set before it was processed. A
>>>> normalizeDocument() in the right place fixed the problem.
>>>>
>>>> Peter
>>>>
>>>> Arnaud wrote:
>>>>> Hi all,
>>>>>
>>>>> Since using Chinese in soap messages which had their header encrypt
>>>>> was not working (and after visiting the XML security page) I
>>>>> upgraded the libraries
>>> to
>>>>> 1.4.1 as recommended.
>>>>> And now I have the following exception on the serverside:
>>>>> com.ctc.wstx.exc.WstxParsingException: Undeclared namespace prefix
>>>>> "ds"
>>>>> at [row,col {unknown-source}]: [6,12]
>>>>>
>>>>> The "[row,col {unknown-source}]: [6,12]" refers to the <ds:KeyInfo>
>>>>> of the
>>> soap
>>>>> header. If I compare the message sent by the client before the
>>>>> upgrade:
>>>>>
>>>>> <ds:KeyInfo xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
>>>>> ...
>>>>> </ds:KeyInfo>
>>>>>
>>>>> and after:
>>>>> <ds:KeyInfo> ...
>>>>> </ds:KeyInfo>
>>>>>
>>>>> I can see the namespace disappeared but I have no idea why and how
>>>>> to fix that...
>>>>> If anyone has an idea please let me know because I don't know what
>>>>> to do
>>> about
>>>>> it and I've alread spend many hours on this...
>>>>>
>>>>> Thanks in advance for any help.
>>>>>
>>>>> Arnaud.
>>>
>>> Hi Peter,
>>>
>>> Thanks a lot for your quick reply!
>>> In my case, I'm not using the xml security libs directly but WSS4J
>>> does that for me. Anyway, after reading your post I decided to
>>> download the WSS4J source... And I added the normalizeDocument() just
>>> after WSS4J calls the xml security to handle encryption and
>>> signature... And you are right this fix the problem!!! I will
>>> probably send a mail to the WSS4J team to let them know about this.
>>>
>>> Again thanks a lot!!!
>>>
>>> Arnaud.
>>>
>>>
>>>
>>
>
>
>
--
View this message in context: http://www.nabble.com/Undeclared-namespace-prefix-%22ds%22-error-tp19668706p19752450.html
Sent from the Apache XML - Security - Dev mailing list archive at Nabble.com.
Re: Undeclared namespace prefix
Posted by Werner Dittmann <We...@t-online.de>.
Raul Benito schrieb:
> I was talkinb about the use of them alone and then need to be c14n by
> itself. Anyway I see the point, and I think is one of the sane ones to be
> use outside of the signature. But please in order to not repeat it can you
> send me the junit test case. It will be make the change faster, and it also
> will allowed us not do the same mistake again.
>
Sure - I need to extract a "pure" xmlsec unit test out out the overall WSS4J
unit test.
Just another thought in this context:
The XML Signature specification (and the many other XML specifications in
general) do not restrict usage of all the XML elements they define. Usually
there is no definition of "this is an internal element" or "this is an external
element" (xmlsec implements elements as objects).
For example KeyInfo is used in XML Signature as well as in XML Encryption
specifications. Other elements specified in XML Signature may be re-used
elsewhere (see to the large set of OASIS Web Service specifications :-) ).
In my understanding an implementation of XML Security specification (such as
xmlsec) shall expect that _every_ element could be used in some other context,
even stand-alone. There is no reason why an application shall not be able to
re-use for example a "Reference" element, or a "X509Data" element as a
stand-alone element if the application's XML structure requires this. And of
course an application shall be able to use xmlsec in this case - because it
exists, is tested, and implements these elements.
There is also no such definition as "a sane use outside as signature" - any
application decides on its own what is "sane" or "insane" with respect to the
XML structures it uses.
As a summary: there is *no reason* (and in large parts it's counter-productive)
to single out elements that are defined in the specifications and make them
usable in one specific context only.
Regards,
Werner
>
> On Fri, Oct 3, 2008 at 5:15 PM, Werner Dittmann <Werner.Dittmann@t-online.de
>> wrote:
>
>> Raul Benito schrieb:
>>
>>> Hello,
>>> I think I made the change so I will try to defend it, first of all the use
>>> of KeyInfo out of a Signature it is not a use case I was looking to.
>>>
>> Raul,
>>
>> KeyInfo as such (as an XML element) is not used inside Signature only. If
>> you
>> have a look into the OASIS WSS specification you will see that KeyInfo is
>> used everywhere (nearly everywhere) a key is used, thus also to store
>> information
>> and references to encryption keys and so on. And these are exactly the test
>> cases
>> that break when we use KeyInfo to implement OASIS WSS.
>>
>> Regards,
>> Werner
>>
>>
>> So
>>
>>> perhaps we break it as we don't look at it. And sadly the old api is full
>>> of
>>> internal objects that can be use external. And I see KeyInfo like that.
>>> So in order to fix, can you write a test case that fails and submit a bug,
>>> I
>>> will update the code in SVN head.
>>> Thanks,
>>> Raul
>>>
>>>
>
Re: Undeclared namespace prefix
Posted by Raul Benito <ra...@apache.org>.
I was talkinb about the use of them alone and then need to be c14n by
itself. Anyway I see the point, and I think is one of the sane ones to be
use outside of the signature. But please in order to not repeat it can you
send me the junit test case. It will be make the change faster, and it also
will allowed us not do the same mistake again.
On Fri, Oct 3, 2008 at 5:15 PM, Werner Dittmann <Werner.Dittmann@t-online.de
> wrote:
> Raul Benito schrieb:
>
>> Hello,
>> I think I made the change so I will try to defend it, first of all the use
>> of KeyInfo out of a Signature it is not a use case I was looking to.
>>
>
> Raul,
>
> KeyInfo as such (as an XML element) is not used inside Signature only. If
> you
> have a look into the OASIS WSS specification you will see that KeyInfo is
> used everywhere (nearly everywhere) a key is used, thus also to store
> information
> and references to encryption keys and so on. And these are exactly the test
> cases
> that break when we use KeyInfo to implement OASIS WSS.
>
> Regards,
> Werner
>
>
> So
>
>> perhaps we break it as we don't look at it. And sadly the old api is full
>> of
>> internal objects that can be use external. And I see KeyInfo like that.
>> So in order to fix, can you write a test case that fails and submit a bug,
>> I
>> will update the code in SVN head.
>> Thanks,
>> Raul
>>
>>
Re: Undeclared namespace prefix
Posted by Werner Dittmann <We...@t-online.de>.
Raul Benito schrieb:
> Hello,
> I think I made the change so I will try to defend it, first of all the use
> of KeyInfo out of a Signature it is not a use case I was looking to.
Raul,
KeyInfo as such (as an XML element) is not used inside Signature only. If you
have a look into the OASIS WSS specification you will see that KeyInfo is
used everywhere (nearly everywhere) a key is used, thus also to store information
and references to encryption keys and so on. And these are exactly the test cases
that break when we use KeyInfo to implement OASIS WSS.
Regards,
Werner
So
> perhaps we break it as we don't look at it. And sadly the old api is full of
> internal objects that can be use external. And I see KeyInfo like that.
> So in order to fix, can you write a test case that fails and submit a bug, I
> will update the code in SVN head.
> Thanks,
> Raul
>
Re: Undeclared namespace prefix
Posted by Raul Benito <ra...@apache.org>.
Hello,
I think I made the change so I will try to defend it, first of all the use
of KeyInfo out of a Signature it is not a use case I was looking to. So
perhaps we break it as we don't look at it. And sadly the old api is full of
internal objects that can be use external. And I see KeyInfo like that.
So in order to fix, can you write a test case that fails and submit a bug, I
will update the code in SVN head.
Thanks,
Raul
On Fri, Oct 3, 2008 at 4:31 PM, Werner Dittmann <Werner.Dittmann@t-online.de
> wrote:
> 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
>>
>>
>>
>>
>
Re: Undeclared namespace prefix
Posted by Werner Dittmann <We...@t-online.de>.
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
>
>
>
RE: Undeclared namespace prefix
Posted by Scott Cantor <ca...@osu.edu>.
> 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
Re: Undeclared namespace prefix
Posted by Werner Dittmann <We...@t-online.de>.
Scott,
>
> Sorry, that's not the point. Is there a namespace *declaration* there? The
> fact that the DOM knows that it has that namespace is irrelevant to the c14n
> process, as far as I'm aware. If the DOM doesn't have the xmlns:ds
> attribute, you will not get it back out.
>
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.
The source code that creates the document uses the
org.apache.xml.security.keys.KeyInfo java class to create the keyinfo element
and to link it into the security header. Digging a bit deeper (via
"org.apache.xml.security.utils.SignatureElementProxy") I found the function
"createElementInSignatureSpace()" in "org.apache.xml.security.utils.XMLUtils".
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 find documentation
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? :-)
Regards,
Werner
Code snippets:
**** 1.4.1 :
public static Element createElementInSignatureSpace(Document doc,
String elementName) {
if (doc == null) {
throw new RuntimeException("Document is null");
}
if ((dsPrefix == null) || (dsPrefix.length() == 0)) {
Element element = doc.createElementNS(Constants.SignatureSpecNS,
elementName);
element.setAttributeNS(Constants.NamespaceSpecNS, "xmlns",
Constants.SignatureSpecNS);
return element;
}
String namePrefix=(String) namePrefixes.get(elementName);
if (namePrefix==null) {
StringBuffer tag=new StringBuffer(dsPrefix);
tag.append(':');
tag.append(elementName);
namePrefix=tag.toString();
namePrefixes.put(elementName,namePrefix);
}
Element element = doc.createElementNS(Constants.SignatureSpecNS, namePrefix);
element.setAttributeNS(Constants.NamespaceSpecNS, xmlnsDsPrefix,
Constants.SignatureSpecNS);
return element;
}
**** 1.4.2 :
public static Element createElementInSignatureSpace(Document doc,
String elementName) {
if (doc == null) {
throw new RuntimeException("Document is null");
}
if ((dsPrefix == null) || (dsPrefix.length() == 0)) {
return doc.createElementNS(Constants.SignatureSpecNS, elementName);
}
String namePrefix=(String) namePrefixes.get(elementName);
if (namePrefix==null) {
StringBuffer tag=new StringBuffer(dsPrefix);
tag.append(':');
tag.append(elementName);
namePrefix=tag.toString();
namePrefixes.put(elementName,namePrefix);
}
return doc.createElementNS(Constants.SignatureSpecNS, namePrefix);
}
RE: Undeclared namespace prefix
Posted by Scott Cantor <ca...@osu.edu>.
> the findElement(...) function finds a node, then the code prints its local
> name and the namespace URI:
>
> Before c14n
> KeyInfo, http://www.w3.org/2000/09/xmldsig#
>
> After running c14n the xmlns: namespace binding is gone.
Sorry, that's not the point. Is there a namespace *declaration* there? The
fact that the DOM knows that it has that namespace is irrelevant to the c14n
process, as far as I'm aware. If the DOM doesn't have the xmlns:ds
attribute, you will not get it back out.
> findElemen(...) is just a lookup function to find an element according to
> the parameters and it does not modify the doc tree in any way.
Right, and it also doesn't pay any attention to namespace declarations.
-- Scott
Re: Undeclared namespace prefix
Posted by Werner Dittmann <We...@t-online.de>.
After a small update of the test like this:
....
Canonicalizer c14n =
Canonicalizer.getInstance(Canonicalizer.ALGO_ID_C14N_WITH_COMMENTS);
System.out.println("Before c14n");
Node n = WSSecurityUtil.findElement(doc.getDocumentElement(), "KeyInfo", "http://www.w3.org/2000/09/xmldsig#");
if (n == null) {
System.out.println("KeyInfo not fond");
}
else {
System.out.println(n.getLocalName() + ", " + n.getNamespaceURI());
}
System.out.println(XMLUtils.PrettyDocumentToString(doc));
byte[] canonicalMessage = c14n.canonicalizeSubtree(doc);
System.out.println("After c14n: " + new String(canonicalMessage));
....
the findElement(...) function finds a node, then the code prints its local
name and the namespace URI:
Before c14n
KeyInfo, http://www.w3.org/2000/09/xmldsig#
After running c14n the xmlns: namespace binding is gone.
findElemen(...) is just a lookup function to find an element according to
the parameters and it does not modify the doc tree in any way.
Except for the new printout the output of this test of xmlsec-1.4.2 is the
same as attached to my last e-mail
Regards,
Werner
Scott Cantor schrieb:
>> Is is still necessary to file a new bug for this, or has Werner's work
>> covered this?
>
> I think it's still being investigated. If there's no bug filed yet, I would
> suggest doing so, and send Werner the bug number so he can attach the
> results of his tests.
>
> -- Scott
>
>
>
RE: Undeclared namespace prefix
Posted by Scott Cantor <ca...@osu.edu>.
> Is is still necessary to file a new bug for this, or has Werner's work
> covered this?
I think it's still being investigated. If there's no bug filed yet, I would
suggest doing so, and send Werner the bug number so he can attach the
results of his tests.
-- Scott