Thank you for this clarification! You right concerning the DOM Parser and this was confusing for me as I instantiate the parser like the following
javax.xml.parsers.DocumentBuilderFactory dbf = javax.xml.parsers.DocumentBuilderFactory.newInstance(); javax.xml.parsers.DocumentBuilder db; dbf.setNamespaceAware(true); and in calling dbf.setNamespaceAware(true) I was assuming that all elements and attributes created in the doc was namespace aware! But thks you again. BR Cédric > -----Message d'origine----- > De : Raul Benito [mailto:[EMAIL PROTECTED] > Envoyé : jeudi 10 février 2005 10:14 > À : security-dev@xml.apache.org > Objet : Re: Exclusive canonicalization problem > > Of course, You must use setAttributeNS always don't ever use a DOM > call without the suffixs NS. (In my humble opinion they must burried > the DOM api for this ;) ). > > Regards, > > > > > On Thu, 10 Feb 2005 09:52:03 +0100, Cédric POTHIN > <[EMAIL PROTECTED]> wrote: > > Hi Raul, > > > > thank you so much for your answer, I think the > > problem comes more from my code than the xml sec > > or the DOM parser. > > > > But I did not verify the clue I have. I think > > the problem comes from the fact that I create > > the attribute xsi:type of the peerKeyIdentifier > > element using setAttribute() instead of setAttributeNS() > > > > here is the code that create <keyIdentifier > xsi:type="roap:X509SPKIHash"> > > > > Element keyIdentifier = doc.createElement("keyIdentifier"); > > keyIdentifier.setAttribute("xsi:type", "roap:X509SPKIHash"); > > Element hash = doc.createElement("hash"); > > > > Do I have to create it using setAttributeNS()? > > > > The parser is the latest xerces version. > > Thks in advance > > Regards > > > > Cédric > > > > > -----Message d'origine----- > > > De : Raul Benito [mailto:[EMAIL PROTECTED] > > > Envoyé : jeudi 10 février 2005 07:29 > > > À : security-dev@xml.apache.org > > > Objet : Re: Exclusive canonicalization problem > > > > > > Hi Cedric, > > > > > > Your case is very strange indeed. I use this kind of c14n and I've > > > never found a problem(and is a very common case so more people and the > > > test cases will also fail). So I thinking that perhaps the DOM parser > > > to blame, so: > > > which java version and in which OS are you using? > > > Which DOM parser? > > > How do you obtain the dom parser? > > > > > > With this perhaps we can help you a little more. > > > > > > Regards, > > > Raul > > > hptt://r-bg.com > > > > > > > > > On Wed, 9 Feb 2005 14:52:42 +0100, Cédric POTHIN > > > <[EMAIL PROTECTED]> wrote: > > > > > > > > > > > > > > > > I have a problem with the exclusive canonicalizer without comments > class > > > in > > > > > > > > the xml security 1.2 source code. > > > > > > > > > > > > > > > > I have the following document : > > > > > > > > > > > > > > > > <roap:riHello xmlns:roap="urn:oma:bac:dldrm:roap-1.0" > > > > xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"; > > > sessionId="292241414" > > > > status="Success"> > > > > > > > > <selectedVersion>1.0</selectedVersion> > > > > > > > > <riID> > > > > > > > > <keyIdentifier xsi:type="roap:X509SPKIHash"> > > > > > > > > <hash>sk+4JImZCG+IV4/c+Pw9FeAbhuc=</hash> > > > > > > > > </keyIdentifier> > > > > > > > > </riID> > > > > > > > > <riNonce>316532319</riNonce> > > > > > > > > <serverInfo></serverInfo> > > > > > > > > <extensions> > > > > > > > > <extension xsi:type="roap:CertificateCaching"></extension> > > > > > > > > </extensions> > > > > > > > > </roap:riHello> > > > > > > > > > > > > > > > > If I canonicalize the previous document using the exclusive without > > > comment > > > > algo > > > > > > > > the document I get is the following: > > > > > > > > > > > > > > > > <roap:riHello xmlns:roap="urn:oma:bac:dldrm:roap-1.0" > > > sessionId="1144777697" > > > > status="Success"> > > > > > > > > <selectedVersion>1.0</selectedVersion> > > > > > > > > <riID> > > > > > > > > <keyIdentifier xsi:type="roap:X509SPKIHash"> > > > > > > > > <hash>sk+4JImZCG+IV4/c+Pw9FeAbhuc=</hash> > > > > > > > > </keyIdentifier> > > > > > > > > </riID> > > > > > > > > <riNonce>1061456201</riNonce> > > > > > > > > <serverInfo></serverInfo> > > > > > > > > <extensions> > > > > > > > > <extension xsi:type="roap:CertificateCaching"></extension> > > > > > > > > </extensions> > > > > > > > > </roap:riHello> > > > > > > > > > > > > > > > > As you can see the xmlns:xsi is removed from the roap:riHello > element, > > > > > > > > but not added to the keyIdentifier and the extension element. > > > > > > > > > > > > > > > > So If I input the result document in a DOM parser it just said not > bound > > > > > > > > exception "xsi is not bound". > > > > > > > > > > > > > > > > > > > > > > > > Well at this point I try to understood the problem and I check the > > > source > > > > code of xml sec 1.2. > > > > > > > > > > > > > > > > I found something very strange: > > > > > > > > > > > > > > > > In the parsing of the doc in the canonicalizerSubTree method there > is a > > > call > > > > to the method > > > > > > > > handlesAttributes that handles the attributes of the current node of > the > > > doc > > > > parsing. > > > > > > > > In debugging the method I found that when the parser comes to > > > > <keyIdentifier xsi:type="roap:X509SPKIHash"> > > > > > > > > for instance then the Attr object in the handlesAttributes method is > of > > > > class AttrImpl and not AttrNSImpl > > > > > > > > so the call to the Attr.getPrefix() always return null if Attr is > > > instance > > > > of AttrImpl ! Whereas there is actually a prefix that is xsi !!!! > > > > > > > > So the attribute namespace is not seen as visiblyUtilized !!! > > > > > > > > > > > > > > > > Do you know why I have a AttrImpl object instance instead of a > AttrNSImp > > > > that should > > > > > > > > handle the namespace prefix correctly? > > > > > > > > > > > > > > > > Do you think it is a bug in the dom parser or in the xml sec source > > > code or > > > > is it something I don't understand > > > > > > > > or something wrong with my document ? > > > > > > > > > > > > > > > > Thank you in advance for any answers. > > > > > > > > > > > > > > > > Cédric > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
