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";>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.
> > >
> > >
> >
> >
