You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@santuario.apache.org by Bradley Beddoes <be...@intient.com> on 2007/01/18 13:29:56 UTC
interop problem java to C++
Hi All,
I am hoping that someone on this list may be able to give me some
assistance with a problem I have been looking into for the past 4 days
and can't seem to come up with any solution for.
The problem manifests itself in the xml-security-c 3.0 code base (well
appears to me to at any rate) with references failing to verify, eg
Reference URI="#_12345-678901" failed to verify
I am currently creating signatures with canicalization method of
exclusive with comments, an RSA SHA1 signature, a SHA1 digest and an
enveloped transform. Example at the end of this message.
The XML document themselves are UTF-16 encoded and are created in Java,
I have tried both the xmldsig implementation (JSR105) from the Java web
services pack and the JSR105 implementation in the latest 1.4 java
security libs (binary distribution from web site).
All generated documents from both JSR implementations validate correctly
in Java space. A generated document with a single enveloped signature
for the root node only will validate correctly in xmlsec-c.
The problem of invalid references arises in xmlsec-c code base when
either a document has a single signature whose reference URI is some
child node of the document or when the root node has a signature AND
some child node of the document has a signature. (Validation with xerces
2.7 always comes out correct)
I believe this is something I am doing wrong, possibly in some kind of
setup but I can't pin point anything out of the ordinary, from debug
output I am getting from the xmlsec-c side the various details about the
reference such as the transform type and targetted URI seem to be in order.
Any suggestions on why I might be seeing this issue would be much
appreciated. For reference I am using OpenSSL 0.9.8b, with no xalan
support on Linux. I have also tried the RC2 of 3.1 with the same results
as above. Please let me know if any other detail may be useful in
diagnosing this and thanks in advance for your time.
regards,
Bradley
For example:
<ds:Signature xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
<ds:SignedInfo>
<ds:CanonicalizationMethod
Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#WithComments" />
<ds:SignatureMethod
Algorithm="http://www.w3.org/2000/09/xmldsig#rsa-sha1" />
<ds:Reference URI="#_12345-67890">
<ds:Transforms>
<ds:Transform
Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature" />
</ds:Transforms>
<ds:DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1" />
<ds:DigestValue>p8iH5++jws3fFbJ6ry7j97JmazI=</ds:DigestValue>
</ds:Reference>
</ds:SignedInfo>
<ds:SignatureValue>
ZttbWswqnKdRMKb4OEChYeANHzpc+g9iX35iiVdigvPoOn0Hug8EwPXWT1GZgDSNfjbtAV47P2AO
jDM/dKlFB6wPqadsofi4sXYvvRU2uFWoKcNf8Y3t1hoFsjlx/s/G28pnIm7tJ4Qt+xUE51cPv2XA
T2iIWSVRHypCFUejWlY=
</ds:SignatureValue>
<ds:KeyInfo>
<ds:KeyName>myrsakey</ds:KeyName>
</ds:KeyInfo>
</ds:Signature>
Re: interop problem java to C++
Posted by Bradley Beddoes <be...@intient.com>.
Additionally to ensure its absolutely clear as I didn't explicitly state
it Signatures are always reported as valid by xmlsec-c for all document
types.
thanks,
Bradley
Bradley Beddoes wrote:
> Hi All,
> I am hoping that someone on this list may be able to give me some
> assistance with a problem I have been looking into for the past 4 days
> and can't seem to come up with any solution for.
>
> The problem manifests itself in the xml-security-c 3.0 code base (well
> appears to me to at any rate) with references failing to verify, eg
> Reference URI="#_12345-678901" failed to verify
>
> I am currently creating signatures with canicalization method of
> exclusive with comments, an RSA SHA1 signature, a SHA1 digest and an
> enveloped transform. Example at the end of this message.
>
> The XML document themselves are UTF-16 encoded and are created in Java,
> I have tried both the xmldsig implementation (JSR105) from the Java web
> services pack and the JSR105 implementation in the latest 1.4 java
> security libs (binary distribution from web site).
>
> All generated documents from both JSR implementations validate correctly
> in Java space. A generated document with a single enveloped signature
> for the root node only will validate correctly in xmlsec-c.
>
> The problem of invalid references arises in xmlsec-c code base when
> either a document has a single signature whose reference URI is some
> child node of the document or when the root node has a signature AND
> some child node of the document has a signature. (Validation with xerces
> 2.7 always comes out correct)
>
> I believe this is something I am doing wrong, possibly in some kind of
> setup but I can't pin point anything out of the ordinary, from debug
> output I am getting from the xmlsec-c side the various details about the
> reference such as the transform type and targetted URI seem to be in order.
>
> Any suggestions on why I might be seeing this issue would be much
> appreciated. For reference I am using OpenSSL 0.9.8b, with no xalan
> support on Linux. I have also tried the RC2 of 3.1 with the same results
> as above. Please let me know if any other detail may be useful in
> diagnosing this and thanks in advance for your time.
>
> regards,
> Bradley
>
>
> For example:
> <ds:Signature xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
> <ds:SignedInfo>
> <ds:CanonicalizationMethod
>
> Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#WithComments" />
> <ds:SignatureMethod
> Algorithm="http://www.w3.org/2000/09/xmldsig#rsa-sha1" />
> <ds:Reference URI="#_12345-67890">
> <ds:Transforms>
> <ds:Transform
> Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature" />
> </ds:Transforms>
> <ds:DigestMethod
> Algorithm="http://www.w3.org/2000/09/xmldsig#sha1" />
>
> <ds:DigestValue>p8iH5++jws3fFbJ6ry7j97JmazI=</ds:DigestValue>
> </ds:Reference>
> </ds:SignedInfo>
> <ds:SignatureValue>
>
> ZttbWswqnKdRMKb4OEChYeANHzpc+g9iX35iiVdigvPoOn0Hug8EwPXWT1GZgDSNfjbtAV47P2AO
>
>
> jDM/dKlFB6wPqadsofi4sXYvvRU2uFWoKcNf8Y3t1hoFsjlx/s/G28pnIm7tJ4Qt+xUE51cPv2XA
>
> T2iIWSVRHypCFUejWlY=
> </ds:SignatureValue>
> <ds:KeyInfo>
> <ds:KeyName>myrsakey</ds:KeyName>
> </ds:KeyInfo>
> </ds:Signature>
Re: interop problem java to C++
Posted by Berin Lautenbach <be...@wingsofhermes.org>.
I was hoping to do it on the weekend just gone past. If all goes well -
this weekend.
Cheers,
Berin
Bradley Beddoes wrote:
> Hi Berin,
> Yes confirmed to solve the problem with the latest svn code.
>
> Any rough eta on 1.3.1 official release yet?
>
> bradley
>
Re: interop problem java to C++
Posted by Bradley Beddoes <be...@intient.com>.
Hi Berin,
Yes confirmed to solve the problem with the latest svn code.
Any rough eta on 1.3.1 official release yet?
bradley
--
Bradley Beddoes
Lead Software Architect
Intient - "Open Source, Open Standards"
Berin Lautenbach wrote:
> Sorry - I've not been close to email lately :<.
>
> Does the code in SVN fix the problem? If not - let me know, and if you
> can provide a test signature as a separate file that should validate but
> which doesn't and I'll look see if I can track it down.
>
> Cheers,
> Berin
>
> Bradley Beddoes wrote:
>> Hi,
>> Seems my suspicions were correct it was a c14n issue.
>>
>> I just found this post from Scott,
>> http://mail-archives.apache.org/mod_mbox/xml-security-dev/200610.mbox/%3c000401c6ecef$26b84ff0$6501a8c0@oit.ohiostate.edu%3e
>>
>>
>> With my few small tests tonight (I intend to thrash it out more in the
>> morning) it seems to have also corrected my issues.
>>
>> regards,
>> Bradley
>>
>>
>> Bradley Beddoes wrote:
>>> Bradley Beddoes wrote:
>>>> After more investigation I found a few problems with my usage of
>>>> Xerces and also some issues with the JAXP validator which I have now
>>>> stopped using which were causing problems with root node signatures.
>>>>--
Bradley Beddoes
Lead Software Architect
Intient - "Open Source, Open Standards"
>>>> Verification of a signature at the root node is now successful in
>>>> both C++ and Java,
>>>
>>> Just in case this wasn't 100% clear a signature on the root node is
>>> successful with or without additional enveloped signatures on child
>>> nodes in both languages.
>>>
>>> however embedded enveloped signatures continue to fail
>>>> with incorrect references. (The documents however still fully
>>>> validate in the language they were created in)
>>>>
>>>> Additionally an embedded sig reference will fail even when it is not
>>>> wrapped inside a root node signature and there is definitely no
>>>> base64 content present in my current test documents regular child
>>>> nodes.
>>>>
>>>> I intend to do some more work tomorrow I am currently suspicious of
>>>> c14n inconsistencies, but I thought I might ask if anyone may have
>>>> any suggestions for other areas I should perhaps be looking at so I
>>>> don't waste a lot of time I don't really have.
>>>>
>>>> regards,
>>>> Bradley
>>>>
>>>> Scott Cantor wrote:
>>>>>> The problem of invalid references arises in xmlsec-c code base when
>>>>>> either a document has a single signature whose reference URI is some
>>>>>> child node of the document or when the root node has a signature AND
>>>>>> some child node of the document has a signature. (Validation with
>>>>>> xerces
>>>>>> 2.7 always comes out correct)
>>>>>
>>>>> If you're validating, that might be your problem, but most of the
>>>>> issues
>>>>> around that were fixed in Xerces-C 2.7. Earlier versions would
>>>>> require that
>>>>> you disable data type normalization, and that would break any nested
>>>>> signature cases where you were signing base-64. But I would try
>>>>> disabling
>>>>> validation and make sure that's not involved.
>>>>>
>>>>> Otherwise, what you want to do is actually get a trace of the octet
>>>>> string
>>>>> being digested in C++ and compare that XML to what you think the
>>>>> c14n should
>>>>> produce.
>>>>>
>>>>> -- Scott
>>>>>
>>>>>
>>>>
>>>>
>>>
>>>
>>
>>
Re: interop problem java to C++
Posted by Berin Lautenbach <be...@wingsofhermes.org>.
Sorry - I've not been close to email lately :<.
Does the code in SVN fix the problem? If not - let me know, and if you
can provide a test signature as a separate file that should validate but
which doesn't and I'll look see if I can track it down.
Cheers,
Berin
Bradley Beddoes wrote:
> Hi,
> Seems my suspicions were correct it was a c14n issue.
>
> I just found this post from Scott,
> http://mail-archives.apache.org/mod_mbox/xml-security-dev/200610.mbox/%3c000401c6ecef$26b84ff0$6501a8c0@oit.ohiostate.edu%3e
>
>
> With my few small tests tonight (I intend to thrash it out more in the
> morning) it seems to have also corrected my issues.
>
> regards,
> Bradley
>
>
> Bradley Beddoes wrote:
>> Bradley Beddoes wrote:
>>> After more investigation I found a few problems with my usage of
>>> Xerces and also some issues with the JAXP validator which I have now
>>> stopped using which were causing problems with root node signatures.
>>>
>>> Verification of a signature at the root node is now successful in
>>> both C++ and Java,
>>
>> Just in case this wasn't 100% clear a signature on the root node is
>> successful with or without additional enveloped signatures on child
>> nodes in both languages.
>>
>> however embedded enveloped signatures continue to fail
>>> with incorrect references. (The documents however still fully
>>> validate in the language they were created in)
>>>
>>> Additionally an embedded sig reference will fail even when it is not
>>> wrapped inside a root node signature and there is definitely no
>>> base64 content present in my current test documents regular child nodes.
>>>
>>> I intend to do some more work tomorrow I am currently suspicious of
>>> c14n inconsistencies, but I thought I might ask if anyone may have
>>> any suggestions for other areas I should perhaps be looking at so I
>>> don't waste a lot of time I don't really have.
>>>
>>> regards,
>>> Bradley
>>>
>>> Scott Cantor wrote:
>>>>> The problem of invalid references arises in xmlsec-c code base when
>>>>> either a document has a single signature whose reference URI is some
>>>>> child node of the document or when the root node has a signature AND
>>>>> some child node of the document has a signature. (Validation with
>>>>> xerces
>>>>> 2.7 always comes out correct)
>>>>
>>>> If you're validating, that might be your problem, but most of the
>>>> issues
>>>> around that were fixed in Xerces-C 2.7. Earlier versions would
>>>> require that
>>>> you disable data type normalization, and that would break any nested
>>>> signature cases where you were signing base-64. But I would try
>>>> disabling
>>>> validation and make sure that's not involved.
>>>>
>>>> Otherwise, what you want to do is actually get a trace of the octet
>>>> string
>>>> being digested in C++ and compare that XML to what you think the
>>>> c14n should
>>>> produce.
>>>>
>>>> -- Scott
>>>>
>>>>
>>>
>>>
>>
>>
>
>
Re: interop problem java to C++
Posted by Bradley Beddoes <be...@intient.com>.
Hi,
Seems my suspicions were correct it was a c14n issue.
I just found this post from Scott,
http://mail-archives.apache.org/mod_mbox/xml-security-dev/200610.mbox/%3c000401c6ecef$26b84ff0$6501a8c0@oit.ohiostate.edu%3e
With my few small tests tonight (I intend to thrash it out more in the
morning) it seems to have also corrected my issues.
regards,
Bradley
Bradley Beddoes wrote:
> Bradley Beddoes wrote:
>> After more investigation I found a few problems with my usage of
>> Xerces and also some issues with the JAXP validator which I have now
>> stopped using which were causing problems with root node signatures.
>>
>> Verification of a signature at the root node is now successful in both
>> C++ and Java,
>
> Just in case this wasn't 100% clear a signature on the root node is
> successful with or without additional enveloped signatures on child
> nodes in both languages.
>
> however embedded enveloped signatures continue to fail
>> with incorrect references. (The documents however still fully validate
>> in the language they were created in)
>>
>> Additionally an embedded sig reference will fail even when it is not
>> wrapped inside a root node signature and there is definitely no base64
>> content present in my current test documents regular child nodes.
>>
>> I intend to do some more work tomorrow I am currently suspicious of
>> c14n inconsistencies, but I thought I might ask if anyone may have any
>> suggestions for other areas I should perhaps be looking at so I don't
>> waste a lot of time I don't really have.
>>
>> regards,
>> Bradley
>>
>> Scott Cantor wrote:
>>>> The problem of invalid references arises in xmlsec-c code base when
>>>> either a document has a single signature whose reference URI is some
>>>> child node of the document or when the root node has a signature AND
>>>> some child node of the document has a signature. (Validation with
>>>> xerces
>>>> 2.7 always comes out correct)
>>>
>>> If you're validating, that might be your problem, but most of the issues
>>> around that were fixed in Xerces-C 2.7. Earlier versions would
>>> require that
>>> you disable data type normalization, and that would break any nested
>>> signature cases where you were signing base-64. But I would try
>>> disabling
>>> validation and make sure that's not involved.
>>>
>>> Otherwise, what you want to do is actually get a trace of the octet
>>> string
>>> being digested in C++ and compare that XML to what you think the c14n
>>> should
>>> produce.
>>>
>>> -- Scott
>>>
>>>
>>
>>
>
>
--
Bradley Beddoes
Lead Software Architect
Intient - "Open Source, Open Standards"
Re: interop problem java to C++
Posted by Bradley Beddoes <be...@intient.com>.
Bradley Beddoes wrote:
> After more investigation I found a few problems with my usage of Xerces
> and also some issues with the JAXP validator which I have now stopped
> using which were causing problems with root node signatures.
>
> Verification of a signature at the root node is now successful in both
> C++ and Java,
Just in case this wasn't 100% clear a signature on the root node is
successful with or without additional enveloped signatures on child
nodes in both languages.
however embedded enveloped signatures continue to fail
> with incorrect references. (The documents however still fully validate
> in the language they were created in)
>
> Additionally an embedded sig reference will fail even when it is not
> wrapped inside a root node signature and there is definitely no base64
> content present in my current test documents regular child nodes.
>
> I intend to do some more work tomorrow I am currently suspicious of c14n
> inconsistencies, but I thought I might ask if anyone may have any
> suggestions for other areas I should perhaps be looking at so I don't
> waste a lot of time I don't really have.
>
> regards,
> Bradley
>
> Scott Cantor wrote:
>>> The problem of invalid references arises in xmlsec-c code base when
>>> either a document has a single signature whose reference URI is some
>>> child node of the document or when the root node has a signature AND
>>> some child node of the document has a signature. (Validation with xerces
>>> 2.7 always comes out correct)
>>
>> If you're validating, that might be your problem, but most of the issues
>> around that were fixed in Xerces-C 2.7. Earlier versions would require
>> that
>> you disable data type normalization, and that would break any nested
>> signature cases where you were signing base-64. But I would try disabling
>> validation and make sure that's not involved.
>>
>> Otherwise, what you want to do is actually get a trace of the octet
>> string
>> being digested in C++ and compare that XML to what you think the c14n
>> should
>> produce.
>>
>> -- Scott
>>
>>
>
>
--
Bradley Beddoes
Lead Software Architect
Intient - "Open Source, Open Standards"
Re: interop problem java to C++
Posted by Bradley Beddoes <be...@intient.com>.
After more investigation I found a few problems with my usage of Xerces
and also some issues with the JAXP validator which I have now stopped
using which were causing problems with root node signatures.
Verification of a signature at the root node is now successful in both
C++ and Java, however embedded enveloped signatures continue to fail
with incorrect references. (The documents however still fully validate
in the language they were created in)
Additionally an embedded sig reference will fail even when it is not
wrapped inside a root node signature and there is definitely no base64
content present in my current test documents regular child nodes.
I intend to do some more work tomorrow I am currently suspicious of c14n
inconsistencies, but I thought I might ask if anyone may have any
suggestions for other areas I should perhaps be looking at so I don't
waste a lot of time I don't really have.
regards,
Bradley
Scott Cantor wrote:
>> The problem of invalid references arises in xmlsec-c code base when
>> either a document has a single signature whose reference URI is some
>> child node of the document or when the root node has a signature AND
>> some child node of the document has a signature. (Validation with xerces
>> 2.7 always comes out correct)
>
> If you're validating, that might be your problem, but most of the issues
> around that were fixed in Xerces-C 2.7. Earlier versions would require that
> you disable data type normalization, and that would break any nested
> signature cases where you were signing base-64. But I would try disabling
> validation and make sure that's not involved.
>
> Otherwise, what you want to do is actually get a trace of the octet string
> being digested in C++ and compare that XML to what you think the c14n should
> produce.
>
> -- Scott
>
>
--
Bradley Beddoes
Lead Software Architect
Intient - "Open Source, Open Standards"
RE: interop problem java to C++
Posted by Scott Cantor <ca...@osu.edu>.
> The problem of invalid references arises in xmlsec-c code base when
> either a document has a single signature whose reference URI is some
> child node of the document or when the root node has a signature AND
> some child node of the document has a signature. (Validation with xerces
> 2.7 always comes out correct)
If you're validating, that might be your problem, but most of the issues
around that were fixed in Xerces-C 2.7. Earlier versions would require that
you disable data type normalization, and that would break any nested
signature cases where you were signing base-64. But I would try disabling
validation and make sure that's not involved.
Otherwise, what you want to do is actually get a trace of the octet string
being digested in C++ and compare that XML to what you think the c14n should
produce.
-- Scott