vanishing attribute namespace prefixes redux

[Mikolaj Habryn <di...@rcpt.to>]

On Mon, 2004-09-13 at 20:37, Mikolaj Habryn wrote:
> For the benefit of any future searching of the list archives, the
> sequence to get this right appears to be:
> 
> a = doc.createElement(localNamespace, prefix + ":" + tag);
> a.setAttributeNS(xmlnsNamespace, "xmlns:" + prefix, localNamespace);
> a.setAttributeNS(xmlnsNamespace, "xmlns:xsi", xmlschemaNamespace);
> a.setAttributeNS(xmlschemaNamespace, "xsi:schemaLocation",
> "localNamespace path-to-schema");

...except that it completely fails to work on root elements in a
document.

Fortunately (for my sanity), it appears that createElementNS *does*
appear to work the way that I thought it should. Here's what I see
happen.

If I create an element with createElementNS(nsX, prefix + ...) and
append it to an element which was *also* created with
createElementNS(nsX, prefix + ...), the attached element will NOT have
an xmlns attribute inserted.

That's why we do the 4-line process above, to make sure that xmlns lines
do appear, so that c14n works as expected (as per my original plaintive
email).

Unfortunately, if we do this to the root element, then createElementNS
will insert it's own xmlns line due to there being no parent to inherit
xmlns from (presumably). If we then create our own, additional, xmlns
attribute, everything proceeds correctly, until we dump it out as a
string and then try to read it back again, at which point the parser
whinges about duplicate xmlns entries.

The interesting thing is that if you either
a) do createElement(prefix + tag) instead of createElementNS, or
b) skip the extra xmlns attribute setting on the root element,
it still breaks, just in different places.

If (a), then all child elements get a duplicate xmlns attribute, if (b),
then it complains that "prefix must resolve to a namespace" during the
XMLSignature, somehow ignoring the xmlns attribute that was
automatically inserted by the createElementNS (back to the original
problem of XMLSignature not seeing namespaces without the 4 line
stanza).

What am I missing here? There must be something blindingly obvious :(

m.

RE: vanishing attribute namespace prefixes redux

[Lawrence McCay <lm...@probaris.com>]

Mikolaj:

How are you creating the document on the client side (signing time)?

I have found that when I create a dom through straight JAXP/xerces and send
it to a JAXM service that the namespaces vanish. I was then adding the
namespace in on the server side so that verification would succeed. This was
admittedly a hack.

When I switched to building the soap request via the JAXM
javax.xml.soap/messaging classes the canonicalized form on the client side
matched that on the server side. I still don't understand why it doesn't
propagate the namespace down to the signedInfo element but at least the
signature verifies.

So turns out - reading the xml file from disk pulling out an element to sign
and expecting it to be verified on server side ended up being a poor
assumption.

I hope this is somehow helpful for your situation.

--larry

> -----Original Message-----
> From: Mikolaj Habryn [mailto:dichro@rcpt.to] 
> Sent: Wednesday, September 15, 2004 9:24 AM
> To: security-dev@xml.apache.org
> Subject: Re: vanishing attribute namespace prefixes redux
> 
> 
> On Wed, 2004-09-15 at 22:59, Mikolaj Habryn wrote:
> > What am I missing here? There must be something blindingly 
> obvious :(
> 
> And just as a final note, if I rely purely on createElementNS (ie, no
> setAttributeNS(..."xmlns"...) stuff), dump the DOM to a 
> string and reparse it from scratch before handing it off to 
> XMLSignature, it works. Which is to say, it doesn't bomb 
> mysteriously in the depths somewhere, but the signatures 
> don't validate.
> 
> m.
> 
> 
> -- 
> This message has been scanned for viruses and
> dangerous content, and is believed to be clean.
> 



-- 
This message has been scanned for viruses and
dangerous content, and is believed to be clean.

Re: vanishing attribute namespace prefixes redux

[Mikolaj Habryn <di...@rcpt.to>]

On Wed, 2004-09-15 at 22:59, Mikolaj Habryn wrote:
> What am I missing here? There must be something blindingly obvious :(

And just as a final note, if I rely purely on createElementNS (ie, no
setAttributeNS(..."xmlns"...) stuff), dump the DOM to a string and
reparse it from scratch before handing it off to XMLSignature, it works.
Which is to say, it doesn't bomb mysteriously in the depths somewhere,
but the signatures don't validate.

m.