Hi Mikolaj,
a few more details, to illustrate the issue:
After having signed XML, the Elements in the signed block all have redundant and
useless namespace
definitions which anyway already are made in the root element of the block. So it
looks something like (I have formatted the lines for better reading):
<halter_name xsi:type="xsd:string"
xmlns=""
xmlns:ns2="http://server";
xmlns:soapenc="http://schemas.xmlsoap.org/soap/encoding/";
xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/";
xmlns:xsd="http://www.w3.org/2001/XMLSchema";
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";>Beckenbauer</halter_name>
<halter_ort xsi:type="xsd:string"
xmlns=""
xmlns:ns2="http://server";
xmlns:soapenc="http://schemas.xmlsoap.org/soap/encoding/";
xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/";
xmlns:xsd="http://www.w3.org/2001/XMLSchema";
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";>Musterdorf</halter_ort>
<halter_plz xsi:type="xsd:long"
xmlns=""
xmlns:ns2="http://server";
xmlns:soapenc="http://schemas.xmlsoap.org/soap/encoding/";
xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/";
xmlns:xsd="http://www.w3.org/2001/XMLSchema";
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";>98765</halter_plz>
This XML is encrypted and then decrypted. The output XML after decryption looks like:
<halter_name xsi:type="xsd:string">Beckenbauer</halter_name>
<halter_ort xsi:type="xsd:string">Musterdorf</halter_ort>
<halter_plz xsi:type="xsd:long">98765</halter_plz>
The serialization output is directly made after decryption. As the encrypted block is
transmitted over the net there
is no modification possible.
I am using Xerces and the Serialization of the Document is JAXP conform:
public String nodeToString(Node node) throws Exception
{
ByteArrayOutputStream result = new ByteArrayOutputStream();
Transformer transformer = TransformerFactory.newInstance().newTransformer();
transformer.transform(new DOMSource(node), new StreamResult(result));
return result.toString();
}
I'm not sure but I would assume that
1. either the decrypter tries to be intelligent and removes redundant namespaces.
2. or there's an incompatibility/bug within the parser?
3. or I'm just blind
Any ideas (don't tell me 3. :-)?
regards
Andrej
> -----Urspr�ngliche Nachricht-----
> Von: Mikolaj Habryn [mailto:[EMAIL PROTECTED]
> Gesendet: Donnerstag, 16. September 2004 09:12
> An: [EMAIL PROTECTED]
> Betreff: Re: Additional note: vanishing attribute namespace prefixes
>
>
> Hi Andrej - it seems to me that if you're receiving XML that
> has had the
> namespaces stripped, then it's effectively corrupted and no longer
> valid. I don't see how you could be expected to rectify that problem -
> surely the solution must reside with the Signing->Verifying step?
>
> m.
>
> PS: Love your motorbikes. Keep 'em coming.
>
> On Wed, 2004-09-15 at 20:01, Andrej Konkow wrote:
> > Hi there,
> >
> > I'm new to this kind of discussion but would like to respond to a
> > message and point out another problem.
> >
> > the solution you have described is not practicable from my point of
> > view.
> > I have the following problem: We have evaluated the XML-Security
> > package in combination with Apache Axis.
> > Everything is fine. Signing->Verifying, Encryption->Decryption.
> > But: When I make the following Signing->Encryption and on
> the other
> > side Decryption->Verification then
> > the verification will fail, as the namespaces are no more included.
> > There's no possibility for me to include the namespaces
> > in the way you described as we just handle the incoming messages.
> > Currently I have no solution. Do you?
> >
> > regards,
> >
> > Andrej
> >
> > ------------------------------------------------------------------
> >
> > From: Mikolaj Habryn <dichro-xml-security <at> rcpt.to>
> > Subject: Re: vanishing attribute namespace prefixes (resend)
> > Newsgroups: gmane.text.xml.security.devel
> > Date: Mon, 13 Sep 2004 20:37:00 +1000
> >
> > On Mon, 2004-09-13 at 18:42, Raul Benito wrote:
> > >
> >
> rootElement.setAttributeNS("http://www.w3.org/2001/XMLSchema-i
nstance","NS1:schemaLocation","urn:frog
> > > http://xml.rcpt.to/mikolaj/default";);
> > >
> >
> rootElement.setAttributeNS(XMLNS_URI,"xmlns:NS1","http://www.w
> 3.org/2001/XMLSchema-instance");
> > > I think your problems will be vanished.
> >
> > You are, of course, absolutely right.
> >
> > 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");
> >
> > I hope to one day understand why it takes four lines to achieve a
> > construct that seems so fundamental.
> >
> > m.
> >
> > PS: ...and I see that my original post has now made it through. My
> > thanks to the moderators.
> >
> >
>
>
