RE: Version 1.4 doesnt' generate the same XML as V1.3: A default namespace is used for XMLSIG and this causes problem!

Fri, 14 Jul 2006 02:12:09 -0700

Title: Re: Version 1.4 doesnt' generate the same XML as V1.3: A default namespace is used for XMLSIG and this causes problem!
Raul,
 
I changed the org.apache.xml.security.utils.XMLUtils and it seems to solve the two problems described bellow (small modification). I am ready to give it to you. Unfortunalty I have an other BLOCKER problem with the current version I download from Apache SVN. It seems that signature process and verification doesn't works correctly. I have Junit unit test cases for XMLSIG and all my tests failed at signature verification (see logging bellow).  It is not due to the modification: it failed before and after the modification!. Getting back to version 1.4beta0, the tests are all OK.
 
- What is the problem ?
- Where do I have to send the XMLUtils class with the fixes ?
 
Regards. Yvan
 
0] "" NG: Digest value mismatch: calculated: +lyKx4VAMXF1oEkNprptl820RVw=
[1] "urn:hypersuite:8F1F8E64-C0A8024E0160C4B0-A0033464" OK
[2] "urn:hypersuite:8F1F8E64-C0A8024E0160C4B0-A0033465" OK
WARN  [main] [11:00:25]  Reference                 - Verification failed for URI ""
WARN  [main] [11:00:25]  Reference                 - Verification failed for URI ""
WARN  [main] [11:00:25]  Reference                 - Verification failed for URI ""
WARN  [main] [11:00:25]  Reference                 - Verification failed for URI ""
WARN  [main] [11:00:25]  Reference                 - Verification failed for URI ""
WARN  [main] [11:00:25]  Reference                 - Verification failed for URI ""
WARN  [main] [11:00:25]  Reference                 - Verification failed for URI ""
WARN  [main] [11:00:25]  Reference                 - Verification failed for URI ""
WARN  [main] [11:00:25]  Reference                 - Verification failed for URI ""
WARN  [main] [11:00:25]  Reference                 - Verification failed for URI ""
WARN  [main] [11:00:25]  Reference                 - Verification failed for URI ""
WARN  [main] [11:00:25]  Reference                 - Verification failed for URI "urn:hypersuite:8F1F8E64-C0A8024E0160C4B0-A0033464"
WARN  [main] [11:00:25]  Reference                 - Verification failed for URI "urn:hypersuite:8F1F8E64-C0A8024E0160C4B0-A0033464"
WARN  [main] [11:00:25]  Reference                 - Verification failed for URI "urn:hypersuite:8F1F8E64-C0A8024E0160C4B0-A0033464"
WARN  [main] [11:00:25]  Reference                 - Verification failed for URI "urn:hypersuite:8F1F8E64-C0A8024E0160C4B0-A0033464"
WARN  [main] [11:00:25]  Reference                 - Verification failed for URI "urn:hypersuite:8F1F8E64-C0A8024E0160C4B0-A0033464"
WARN  [main] [11:00:25]  Reference                 - Verification failed for URI "urn:hypersuite:8F1F8E64-C0A8024E0160C4B0-A0033464"
 
From: Hess Yvan [mailto:[EMAIL PROTECTED]
Sent: jeudi, 13. juillet 2006 19:36
To: [email protected]
Subject: RE : Version 1.4 doesnt' generate the same XML as V1.3: A default namespace is used for XMLSIG and this causes problem!

Concerning the first point, I will give you the patch that fixes the problem, but I don't in which form you want it. Do you want the method only or the whole class ? Where do I have to send it ? To the mailing list as attachment or directly to your personal address ?
 
Concerning the second point. I will give you a proposition tomorow because now I am at Home :-). I would like to find a more elegant solution than the proposed one. My idea is to call the method Constants.getSignatureSpecNSprefix() into XMLUtils.createElementInSignatureSpace() instead to use the  static variable (that can be supressed). I didn't check if this solution is possible,  I will do it tomorow :-) May be you have an idea about it...
 
I will also test these proposed solutions in the context of my application.
 
Regards. Yvan

Thanks for the debugging session.
The first problem you have solved it great, can you send me a patch
with the fixes?.
The second one is more tough.
The easier solution will be let the Init.init() call a static function
XMLUtils (like reReadVariables). So the XMLUtils initialize the static
data.
This way we can use the static for caching and always getting the
correct behaviour.
What do you think?


On 7/13/06, Hess Yvan <[EMAIL PROTECTED]> wrote:
> Raul,
>
> I downloaded the XML security source code from apache to check where is
> the problem. I saw in your example that your are calling a
> Constants.setSignatureSpecNSprefix("") and I tried as you propose to do
> Constants.setSignatureSpecNSprefix("ds") but I got a Exception.
>
> org.w3c.dom.DOMException: NAMESPACE_ERR: An attempt is made to create or
> change an object in a way which is incorrect with regard to namespaces.
>
> Doing some investigation in the code, I detected the following problems:
>
> 1. In the XMLUtils.createElementInSignatureSpace() method when
> dsPrefix!= null you adds an attribute using the folliwing method
> element.setAttributeNS(Constants.NamespaceSpecNS, dsPrefix,
> Constants.SignatureSpecNS) that produces the error. I think you forget
> to add the xmlns namespace. It should be
> element.setAttributeNS(Constants.NamespaceSpecNS, "xmlns:"+ dsPrefix,
> Constants.SignatureSpecNS);. Doing like that it should solve the problem
>
> 2. You have a resource/config.xml file that contains a section
> "PrefixMappings" that binds ds to http://www.w3.org/2000/09/xmldsig#.
> The intialization is done into Init.init() class. The problem is that
> you uses XMLUtils class before the section PrefixMappings is initialzed
> and due to that the static final String dsPrefix field of XMLUtils class
> is initialized using the method Constants.getSignatureSpecNSprefix()
> [syntax is: static final String dsPrefix=
> Constants.getSignatureSpecNSprefix();] In this case it is set to null
> because PrefixMappings has no been initialized (done after into
> Init.init()). As dsPrefix is null, the ds prefix is never added to DS
> elements see method XMLUtils.createElementInSignatureSpace().
>
> Do you have an idea how to correct these two problems ?
>
> Regards. Yvan
>
> -----Original Message-----
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
> On Behalf Of Raul Benito
> Sent: jeudi, 13. juillet 2006 13:17
> To: [email protected]
> Subject: Re: Version 1.4 doesnt' generate the same XML as V1.3: A
> default namespace is used for XMLSIG and this causes problem!
>
> Hi Hess,
>
> I was not aware of the change. But from performance point of view it
> makes sense.
> I have see in my testing that deciding what to write in the signature
> elements takes a lot of time.
>
> The problem is how to make the behaviour configurable and get no
> performance hit because of it.
>
> Anyway try with Constants.setSignatureSpecNSprefix("ds").
> Pleas tell us if it helps you.
>
> Regards,
> Raul
>
>
> On 7/13/06, Hess Yvan <[EMAIL PROTECTED]> wrote:
> >
> >
> > Hi,
> >
> > Due to a problem in XML security library version 1.3 that was not
> > thread safe, I got the version xmlsec-1.4.Beta0.jar. Doing some test I
>
> > detected that the generated XML encryption block of XML encrypted
> > document is NOT THE SAME in version 1.4 and in the version 1.3.
> > Version 1.4 sets a DEFAULT namespace for xmldsig and for example the
> > KeyInfo element is written as <KeyInfo> instead of <ds:KeyInfo> as
> > before. The fact that a default namespace is used causes problems in
> > my application. Please can you help me to solve this problem and give
> me some solution to solve it.
> >
> > Thanks in advance
> >
> > Regards Yvan Hess
> >
> > VERSION 1.3:
> >
> >    <edoc:EncryptionBlock id="Revision-1-Encryption-1"
> > xmlns:ds="http://www.w3.org/2000/09/xmldsig#"
> > xmlns:xenc="http://www.w3.org/2001/04/xmlenc#">
> >       <xenc:EncryptedKey>
> >          <xenc:EncryptionMethod
> > Algorithm="http://www.w3.org/2001/04/xmlenc#rsa-1_5"/>
> >          <ds:KeyInfo>
> >             <ds:KeyName>H5DEMO-ENC</ds:KeyName>
> >          </ds:KeyInfo>
> >          <xenc:CipherData>
> >
> > <xenc:CipherValue>s7quAENaOlnur3....</xenc:CipherValue>
> >          </xenc:CipherData>
> >
> > <xenc:CarriedKeyName>SYSKEY-1152718774975</xenc:CarriedKeyName>
> >       </xenc:EncryptedKey>
> >       <xenc:EncryptedData>
> >          <xenc:EncryptionMethod
> > Algorithm="http://www.w3.org/2001/04/xmlenc#aes128-cbc"/>
> >          <ds:KeyInfo>
> >             <ds:KeyName>SYSKEY-1152718774975</ds:KeyName>
> >          </ds:KeyInfo>
> >          <xenc:CipherData>
> >             <xenc:CipherReference
> > URI="urn:hypersuite:63663F3E-C0A8027A01627C16-1CA0489B"/>
> >          </xenc:CipherData>
> >       </xenc:EncryptedData>
> >    </edoc:EncryptionBlock>
> >
> >
> > VERSION 1.4:
> >
> >    <edoc:EncryptionBlock id="Revision-1-Encryption-1"
> > xmlns="http://www.w3.org/2000/09/xmldsig#"
> > xmlns:xenc="http://www.w3.org/2001/04/xmlenc#">
> >
> > <edoc:EncryptionDate>2006-07-12T16:40:56</edoc:EncryptionDate>
> >       <edoc:Encryptor>IMTF Hypersuite Capture Server</edoc:Encryptor>
> >       <xenc:EncryptedKey>
> >          <xenc:EncryptionMethod
> > Algorithm="http://www.w3.org/2001/04/xmlenc#rsa-1_5"/>
> >          <KeyInfo>
> >             <KeyName>TestDMO</KeyName>
> >          </KeyInfo>
> >          <xenc:CipherData>
> >
> > <xenc:CipherValue>Af97+MWWWzxXqLocfm/xzu......</xenc:CipherValue>
> >          </xenc:CipherData>
> >
> > <xenc:CarriedKeyName>SYSKEY-1152714533719</xenc:CarriedKeyName>
> >       </xenc:EncryptedKey>
> >       <xenc:EncryptedData>
> >          <xenc:EncryptionMethod
> > Algorithm="http://www.w3.org/2001/04/xmlenc#aes128-cbc"/>
> >          <KeyInfo>
> >             <KeyName>SYSKEY-1152714533719</KeyName>
> >          </KeyInfo>
> >          <xenc:CipherData>
> >             <xenc:CipherReference
> > URI="urn:hypersuite:632EF16A-0A024301000C74FE-C69D3102"/>
> >          </xenc:CipherData>
> >       </xenc:EncryptedData>
> >    </edoc:EncryptionBlock>
> >
> >
>
>
> --
> http://r-bg.com
>


--
http://r-bg.com

Reply via email to