[prev in list] [next in list] [prev in thread] [next in thread]
List: xml-security-dev
Subject: AW: AW: Additional note: vanishing attribute namespace prefixes
From: Andrej Konkow <Andrej.Konkow () partner ! bmw ! de>
Date: 2004-09-17 7:08:12
Message-ID: 3AE413A5D1F1D44188D9D2810E67186F113F83 () MOEEXC02 ! europe ! bmw ! corp
[Download RAW message or body]
Hi Mikolaj,
you have won your bet: The output given by your code shows me the original document with no namespaces.
The serialization from Document to String by the XML-Parser includes the namespaces (at least xmlns="")
So your workaround will also have to be included by me.
Thanks alot
Andrej
> -----Ursprüngliche Nachricht-----
> Von: Mikolaj Habryn [mailto:dichro@rcpt.to]
> Gesendet: Donnerstag, 16. September 2004 10:11
> An: Konkow Andrej, FZ-32
> Cc: security-dev@xml.apache.org
> Betreff: Re: AW: Additional note: vanishing attribute
> namespace prefixes
>
>
> The interesting thing to do after the data has been signed is to grab
> the XMLSignature object that you used to sign it, and do:
>
> byte content[] = sig.getSignedInfo().getSignedContentItem(0);
> System.out.println("signed content: ");
> System.out.write(content, 0, content.length);
> System.out.println();
>
> That will show you exactly what your signature transforms have done to
> the data - were I a wagering man, I'd bet that you're hitting exactly
> the same problem as I am with respect to namespaces being eaten.
>
> What does it show as the output from the above? Can you
> insert that code
> somewhere appropriate in the client or do you only have
> control over the
> server?
>
> m.
>
> On Thu, 2004-09-16 at 17:45, Andrej Konkow wrote:
> > 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">Beckenba
> uer</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">Musterdo
> rf</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</h
> alter_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:dichro-xml-security@rcpt.to]
> > > Gesendet: Donnerstag, 16. September 2004 09:12
> > > An: security-dev@xml.apache.org
> > > 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.
> > > >
> > > >
> > >
> > >
>
>
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic