You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@santuario.apache.org by ra...@r-bg.com on 2004/10/01 15:57:41 UTC
Re: Fix for vanishing attribute namespace prefixes?
On 30/09/2004, at 17:01, Joris Wijlens wrote:
> Hi there,
>
> I'm using the XML-security package for a Java project.
>
> I have this problem with as you describe it "vanishing attribute
> namespace prefixes". I tried the workaround (described in Mikolaj
> Habryn's message of Thu, 16 Sep 2004 19:05:56) but that didn't help
> me. I did the following:
>
> * I create message1 (document) and add a element with namespace.
> * I serialize it into message2 (documentToBeSigned) like this:
>
> OutputFormat format = new
> OutputFormat(document,"UTF-8",false);
> ByteArrayOutputStream arrayOutputStream = new
> ByteArrayOutputStream();
> XMLSerializer serializer = new
> XMLSerializer(arrayOutputStream,format);
> serializer.setNamespaces(true);
> serializer.asDOMSerializer();
> serializer.serialize(document.getDocumentElement());
> Document documentToBeSigned = documentBuilder.parse(new
> ByteArrayInputStream(arrayOutputStream.toByteArray()));
>
> * I sign message2 and yes Mikolaj is right about the namespace being
> added and the signing succeeding, but there are empty namespace
> attributes all over the place (like this: xmlns="").
> * I "cut" the signature from message2
> * I import the message in message1 and all looks fine.
> But when I try to verify message1 it fails. I think because I think
> the appearing xmlns="" 's in the message are taken into account when
> signing the message (?) and my backup message doesn't have them. (Am I
> doing something wrong here?).
>
> I have a couple of questions:
> Is this problem fixed and is it checked into the CVS repository?
> Is the 1.2 release you are working on going to fix this problem?
> Is this problem logged as a bug and can I track it?
>
First of all, what are you doing is completely wrong DOMwise, it is not
a library bug, it is not something we can fix, it is just plain
wrong(but don't worry I made the same mistake you made).
Let me explain again (if this question is asked again perhaps we should
include in the faq).
Ok imagine this simple code (take on account that I far from home
without a java compiler so don't fuss with it does not compile or
things like this ;) ):
//We want to build a DOM tree anew to latter be signed
org.w3c.dom.Document doc=DocumentFactory.newDocument();
//Let's create an element <element xmlns="http://uri-a">
Element el=doc.createElementNS("http://uri-a","element");
//Okay it seems that we have create a element with a namespace
http://uri-a,
// but this info is discarded when the node is output. DOMWise what
we created is
// <element> nothing more nothing else.
//QUESTION: What I want to do <element xmlns="http://uri-a"?
//ANSWER: Then do:
el.setAttribute("xmlns","http://uri-a");
//And now you have what you want.
//Q: But excluding the above line if i do
XMLSerializer serializer = new
XMLSerializer(arrayOutputStream,format);
serializer.setNamespaces(true);
serializer.asDOMSerializer();
serializer.serialize(doc.getDocumentElement());
// I obtain what you got. Then you are cheating me..
//A: You are using a helper class that tries to outuput the DOM
adding thing that there are NOT in the DOM tree, if you see the javadoc
for setNamespaces it reads
//public void setNamespaces(boolean namespaces)This methods turns on
namespace fixup algorithm during DOM serilization.
//so it tries to fixup things inventing namespaces prefix like
NS0..NS99 for thinks that don't have prefix. But it doesn't change your
original dom tree.
And why I've explained(or try to explain, sorry for me awful english)
all these things about namespaces. Because what you have done is more
or less:
create a DOM tree with only <element> ==> serialize it and re-parse it
so you got ==> <element xmlns="http://uri-a"> DOM tree ==> sign it
obtaining <elemenet
xmlns="http://uri-a"><ds:Signature>...</ds:Signature> ==> you cut the
ds:signature and paste in the original DOM tree obtainig
<element><ds:Signature>...</ds:Signature> ==> and now you try to check
it and it fails. Naturälich (naturally) where is xmlns="http://uri-a"
attribute it is NOT the same document you sign. The library will be
wrong if it said that the sign was correct.
Hope I'll make myself understand.
Regards,
Raul
http://r-bg.com
Re: Fix for vanishing attribute namespace prefixes?
Posted by Raul Benito <ra...@r-bg.com>.
Mikolaj Habryn wrote:
>On Fri, 2004-10-01 at 23:57, raul-info@r-bg.com wrote:
>
>
>>create a DOM tree with only <element> ==> serialize it and re-parseit
>>so you got ==> <element xmlns="http://uri-a"> DOM tree ==> signit
>>obtaining
>><elemenetxmlns="http://uri-a"><ds:Signature>...</ds:Signature> ==> you
>>cutthe ds:signature and paste in the original DOM tree
>>obtainig<element><ds:Signature>...</ds:Signature> ==> and now you try
>>tocheck it and it fails. Naturälich (naturally) where
>>isxmlns="http://uri-a" attribute it is NOT the same document you
>>sign.The library will be wrong if it said that the sign was correct.
>>
>>
>
>Again, respectfully, I'm compelled to disagree. I have very little
>experience with XML or xml-dsig, but this just feels very wrong.
>
>Quoting http://lists.w3.org/Archives/Public/www-dom/2003JanMar/0059.html
>
>"Remember, the DOM does not require that all namespace
>declaration attributes be present. Thus, there may be implied bindings,
>which may conflict with explicit ones. The namespace fixup algorithm is
>about finding and "realizing" those; the namespace lookup algorithm
>behaves "as if" fixup had been performed."
>
>
>
That's correct, but if you see they are discussing about the B appendix
of DOM level3
(http://www.w3.org/TR/2004/REC-DOM-Level-3-Core-20040407/namespaces-algorithms.html).
In DOMv2 there is no standard algorithm to fix a DOM tree, xerces
provides one but that's all. I don't know if crimson provides one (but I
think it doesn't). So the serialize algorithm xerces use is the xerces
one(that seems is becoming the standardized one but I think that are
little but significant differences) the one that crimson(or other jaxp)
uses could be different (as the algorithm was set as standard in DOMv3
not DOMv2) and we are trying to be DOM implementation
independent(without too much success but we are improvement).
>This implies that the fixup algorithm isn't a hack, it's a way of
>correctly representing the implicit and explicit namespaces. What the
>library appears to do is only consider the explicit namespace
>attributes.
>
>To put it another way, the <element xmlns=blah attr=val/> is not a DOM,
>it's a textual representation of one. The DOM is an abstract structure
>that has a number of characteristics, including namespaces. Namespaces
>are represented by xmlns attributes when serialized, but not necessarily
>prior to serialization - but that doesn't mean that they don't exist!
>
>
>
In DOMv2 if they are not in the DOM tree they don't exits, in DOMv3 we
can still argue about that.
>This line of thought (again, I'm a complete novice at this stuff, so
>feel free to shoot me down) is what led me to the serialize/de-serialize
>hack, which synchronized the implicit namespaces with the explicit ones.
>
>Your recommended solution seems akin to simulating DOM level 2 (which is
>a pre-requisite for xmldsig, isn't it?) using a level 1 interface, in
>case that is a useful idea for anyone to understand what I'm trying to
>say.
>
>m.
>
>
>
First of all, I think that define all the namespaces binding and
prefixes in DOM is a pain, but in DOM2 is necessary. When DOM3 becomes a
standard, we can implement the same algorithm to fix it, and it is a
real pity that DOMv3 hasn't provide a fixup() method in document so
appears all the missing nodes in the node, or to obtain the generated
prefix with a Element.getGeneratedPrefix() method or something like
this, but as they are not available if we want to give this
functionality we must implement ourselves the algorithm.
Anyhow if you want to contribute with a patch that implements the fix up
functionality xerces way in the c14n phase, please feel free...
Regards,
Raul
http://r-bg.com
Re: Fix for vanishing attribute namespace prefixes?
Posted by Mikolaj Habryn <di...@rcpt.to>.
On Fri, 2004-10-01 at 23:57, raul-info@r-bg.com wrote:
> create a DOM tree with only <element> ==> serialize it and re-parseit
> so you got ==> <element xmlns="http://uri-a"> DOM tree ==> signit
> obtaining
> <elemenetxmlns="http://uri-a"><ds:Signature>...</ds:Signature> ==> you
> cutthe ds:signature and paste in the original DOM tree
> obtainig<element><ds:Signature>...</ds:Signature> ==> and now you try
> tocheck it and it fails. Naturälich (naturally) where
> isxmlns="http://uri-a" attribute it is NOT the same document you
> sign.The library will be wrong if it said that the sign was correct.
Again, respectfully, I'm compelled to disagree. I have very little
experience with XML or xml-dsig, but this just feels very wrong.
Quoting http://lists.w3.org/Archives/Public/www-dom/2003JanMar/0059.html
"Remember, the DOM does not require that all namespace
declaration attributes be present. Thus, there may be implied bindings,
which may conflict with explicit ones. The namespace fixup algorithm is
about finding and "realizing" those; the namespace lookup algorithm
behaves "as if" fixup had been performed."
This implies that the fixup algorithm isn't a hack, it's a way of
correctly representing the implicit and explicit namespaces. What the
library appears to do is only consider the explicit namespace
attributes.
To put it another way, the <element xmlns=blah attr=val/> is not a DOM,
it's a textual representation of one. The DOM is an abstract structure
that has a number of characteristics, including namespaces. Namespaces
are represented by xmlns attributes when serialized, but not necessarily
prior to serialization - but that doesn't mean that they don't exist!
This line of thought (again, I'm a complete novice at this stuff, so
feel free to shoot me down) is what led me to the serialize/de-serialize
hack, which synchronized the implicit namespaces with the explicit ones.
Your recommended solution seems akin to simulating DOM level 2 (which is
a pre-requisite for xmldsig, isn't it?) using a level 1 interface, in
case that is a useful idea for anyone to understand what I'm trying to
say.
m.