You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@santuario.apache.org by "GANDHIRAJAN,AYYAPPAN (HP-India,ex2)" <ay...@hp.com> on 2004/04/02 13:55:06 UTC

RE: Problem with verification of .NET signed XML

Hi Vishal,

Sometime back, there was a discussion going on about this cascading in one
thread with subject "going from signing xml file with DTD to signing xml
file with Schema". Do you any clue about the conclusion? Can't I somehow
stop cascading?

Please do suggest me.


Thanks & Regards,
Ayyappan Gandhirajan
---------------------------------------------
Office: 91.80.2225.1554 Extn 1472
Mobile: 91.94483.14969
E-Mail: ayyappan.gandhirajan@hp.com
-----------------------------------------------


-----Original Message-----
From: Vishal Mahajan [mailto:Vishal.Mahajan@Sun.COM]
Sent: Wednesday, March 31, 2004 6:55 PM
To: security-dev@xml.apache.org
Subject: Re: Problem with verification of .NET signed XML


I think (I am not sure) that this might be happening because of the 
namespace attributes cascading that's done by apache dsig library on the 
xml document. This, combined with the fact that there's no 
canonicalization transform inside the signed-info-reference 
(ds:Reference) might be resulting in the interop problem that you are 
facing. It would be interesting to know, what happens when you perform a 
canon transform on the signature input to be digested.

Vishal

GANDHIRAJAN,AYYAPPAN (HP-India,ex2) wrote:

>Oop! I forgot to attach the xml message. Please here you go!
>
>
>Thanks & Regards,
>Ayyappan Gandhirajan
>---------------------------------------------
>Office: 91.80.2225.1554 Extn 1472
>Mobile: 91.94483.14969
>E-Mail: ayyappan.gandhirajan@hp.com
>-----------------------------------------------
>
>
>-----Original Message-----
>From: GANDHIRAJAN,AYYAPPAN (HP-India,ex2) 
>Sent: Wednesday, March 31, 2004 4:52 PM
>To: 'security-dev@xml.apache.org'
>Subject: RE: Problem with verification of .NET signed XML
>
>
>Hi Berin,
>
>Thanks for your mail.
>
>My client is written using .NET. It creates an XML envelope and sign it.
>
>My server is written in apache xml security. It verifies the signed xml
>messages, which was sent by the client. The "boolean verify =
>sig1.checkSignatureValue(sig1.getKeyInfo().getPublicKey())" statement
always
>return false. The digest value generated is different from the digest value
>present in the xml message.
>
>Please find the attached signed xml mesage.
>
>
>Thanks & Regards,
>Ayyappan Gandhirajan
>---------------------------------------------
>Office: 91.80.2225.1554 Extn 1472
>Mobile: 91.94483.14969
>E-Mail: ayyappan.gandhirajan@hp.com
>-----------------------------------------------
>
>
>-----Original Message-----
>From: Berin Lautenbach [mailto:berin@wingsofhermes.org]
>Sent: Wednesday, March 31, 2004 4:31 PM
>To: security-dev@xml.apache.org
>Subject: Re: Problem with verification of .NET signed XML
>
>
>The Object element is simply an artifact for including information to be 
>signed or to be used in the signature inside the Signature element.  It 
>is not directly included in any signture operation.
>
>How is the signature breaking?
>
>Cheers,
>	Berin
>
>
>GANDHIRAJAN,AYYAPPAN (HP-India,ex2) wrote:
>
>  
>
>>Folks,
>>
>>Though I have been working with XML security for the past four months, I
>>have never used "<Object>" tag inside <Signature> element. Can anyone of
>>    
>>
>you
>  
>
>>please tell me as to what is this Object tag and how it affects the
>>signature verification functionlaity?
>>
>>I have used apahe XML security to sign and verify the digital signature.
>>When both server and client are using apache libraries, the functionlity
>>worksfine. When I generated the signed xml using .NET, the functionlity
>>breaks. I see one extra <Object> inside the <Signature> element. The
>>interoperability seems to be a problem here. Can someone help me in
>>resolving this?
>>
>>
>>Thanks & Regards,
>>Ayyappan Gandhirajan
>>---------------------------------------------
>>Office: 91.80.2225.1554 Extn 1472
>>Mobile: 91.94483.14969
>>E-Mail: ayyappan.gandhirajan@hp.com
>>-----------------------------------------------
>> <<dotNETsignedMsg.xml>> 
>>    
>>
>
>  
>



Re: Problem with verification of .NET signed XML

Posted by Berin Lautenbach <be...@wingsofhermes.org>.
Vishal Mahajan wrote:

> Berin, like I said in my previous message, what if the cononicalization 
> is not required to be performed? eg, consider the following example 
> ds:Reference
> 
>                                        <Reference URI="#Body">
>                                                <DigestMethod 
> Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/>
>                                                
> <DigestValue>+L4ikk2zCUa0G8wTXVwXzF37GSQ=</DigestValue>
>                                        </Reference>

My apologies - I didn't quite read your e-mail properly.

Canonicalisation is required in all cases where a node set is to be 
digested, or input to a new serial transform (e.g. parsed).

So in the above case, canonicalisation is required by the spec.  It's 
not explicitly listed as a transform, because it doesn't have to be. 
The fact a reference to the local document is made implies that a node 
set is returned.  To make that node set an octet stream input to the 
hashing function, you are required to canonicalise.

There are cases where canonicalisation is not required, but they tend to 
be where the document reference is external.  So something like :

<Reference URI="http://www.wingsofhermes.org/test.html">
  <DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/>
  <DigestValue>b64encodedValue</DigestValue>
</Reference>

wouldn't require it, and to be honest I am not sure whether the library 
cascades namespaces in that case.  (But if it does, it shouldn't :>.)

Cheers,
	Berin

Re: Problem with verification of .NET signed XML

Posted by Vishal Mahajan <Vi...@Sun.COM>.
Berin Lautenbach wrote:

> Vishal,
>
> It's correct, but unfortunate behaviour.  The namespaces have to be 
> cascaded due to the spec using an XPath model for defining how 
> canonicalisation is performed.

Berin, like I said in my previous message, what if the cononicalization 
is not required to be performed? eg, consider the following example 
ds:Reference

                                        <Reference URI="#Body">
                                                <DigestMethod 
Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/>
                                                
<DigestValue>+L4ikk2zCUa0G8wTXVwXzF37GSQ=</DigestValue>
                                        </Reference>

Vishal

>   DOM does not perfectly match to XPath, particularly where it comes 
> to namespaces.  Normally you can bypass it, but there are some arcane 
> XPath constructs that will only work if namespaces are cascaded 
> through the doc.
>
> Unfortunately, those arcane constructs are tested in the interop tests 
> :>.
>
> I'm trying to package up and do dox for 1.1 this weekend, but the 
> first thing I want to do after 1.1 is attempt to implement something 
> similar to what is used in the C library to only temporarily add the 
> namespaces that are required.
>
> Cheers,
>     Berin
>
>
> Vishal Mahajan wrote:
>
>> All:
>>
>> I think this might be an important issue. The namespace attributes 
>> cascading is carried out by the Java dsig code even if 
>> canonicalization transformation is not required to be performed. Is 
>> this correct behavior?
>>
>> Vishal
>>
>> GANDHIRAJAN,AYYAPPAN (HP-India,ex2) wrote:
>>
>>> Hi Vishal,
>>>
>>> Sometime back, there was a discussion going on about this cascading 
>>> in one
>>> thread with subject "going from signing xml file with DTD to signing 
>>> xml
>>> file with Schema". Do you any clue about the conclusion? Can't I 
>>> somehow
>>> stop cascading?
>>>
>>> Please do suggest me.
>>>
>>>
>>> Thanks & Regards,
>>> Ayyappan Gandhirajan
>>> ---------------------------------------------
>>> Office: 91.80.2225.1554 Extn 1472
>>> Mobile: 91.94483.14969
>>> E-Mail: ayyappan.gandhirajan@hp.com
>>> -----------------------------------------------
>>>
>>>
>>> -----Original Message-----
>>> From: Vishal Mahajan [mailto:Vishal.Mahajan@Sun.COM]
>>> Sent: Wednesday, March 31, 2004 6:55 PM
>>> To: security-dev@xml.apache.org
>>> Subject: Re: Problem with verification of .NET signed XML
>>>
>>>
>>> I think (I am not sure) that this might be happening because of the 
>>> namespace attributes cascading that's done by apache dsig library on 
>>> the xml document. This, combined with the fact that there's no 
>>> canonicalization transform inside the signed-info-reference 
>>> (ds:Reference) might be resulting in the interop problem that you 
>>> are facing. It would be interesting to know, what happens when you 
>>> perform a canon transform on the signature input to be digested.
>>>
>>> Vishal
>>>
>>> GANDHIRAJAN,AYYAPPAN (HP-India,ex2) wrote:
>>>
>>>  
>>>
>>>> Oop! I forgot to attach the xml message. Please here you go!
>>>>
>>>>
>>>> Thanks & Regards,
>>>> Ayyappan Gandhirajan
>>>> ---------------------------------------------
>>>> Office: 91.80.2225.1554 Extn 1472
>>>> Mobile: 91.94483.14969
>>>> E-Mail: ayyappan.gandhirajan@hp.com
>>>> -----------------------------------------------
>>>>
>>>>
>>>> -----Original Message-----
>>>> From: GANDHIRAJAN,AYYAPPAN (HP-India,ex2) Sent: Wednesday, March 
>>>> 31, 2004 4:52 PM
>>>> To: 'security-dev@xml.apache.org'
>>>> Subject: RE: Problem with verification of .NET signed XML
>>>>
>>>>
>>>> Hi Berin,
>>>>
>>>> Thanks for your mail.
>>>>
>>>> My client is written using .NET. It creates an XML envelope and 
>>>> sign it.
>>>>
>>>> My server is written in apache xml security. It verifies the signed 
>>>> xml
>>>> messages, which was sent by the client. The "boolean verify =
>>>> sig1.checkSignatureValue(sig1.getKeyInfo().getPublicKey())" statement
>>>>   
>>>
>>>
>>> always
>>>  
>>>
>>>> return false. The digest value generated is different from the 
>>>> digest value
>>>> present in the xml message.
>>>>
>>>> Please find the attached signed xml mesage.
>>>>
>>>>
>>>> Thanks & Regards,
>>>> Ayyappan Gandhirajan
>>>> ---------------------------------------------
>>>> Office: 91.80.2225.1554 Extn 1472
>>>> Mobile: 91.94483.14969
>>>> E-Mail: ayyappan.gandhirajan@hp.com
>>>> -----------------------------------------------
>>>>
>>>>
>>>> -----Original Message-----
>>>> From: Berin Lautenbach [mailto:berin@wingsofhermes.org]
>>>> Sent: Wednesday, March 31, 2004 4:31 PM
>>>> To: security-dev@xml.apache.org
>>>> Subject: Re: Problem with verification of .NET signed XML
>>>>
>>>>
>>>> The Object element is simply an artifact for including information 
>>>> to be signed or to be used in the signature inside the Signature 
>>>> element.  It is not directly included in any signture operation.
>>>>
>>>> How is the signature breaking?
>>>>
>>>> Cheers,
>>>>     Berin
>>>>
>>>>
>>>> GANDHIRAJAN,AYYAPPAN (HP-India,ex2) wrote:
>>>>
>>>>
>>>>
>>>>  
>>>>
>>>>> Folks,
>>>>>
>>>>> Though I have been working with XML security for the past four 
>>>>> months, I
>>>>> have never used "<Object>" tag inside <Signature> element. Can 
>>>>> anyone of
>>>>>  
>>>>>     
>>>>
>>>>
>>>> you
>>>>
>>>>
>>>>  
>>>>
>>>>> please tell me as to what is this Object tag and how it affects the
>>>>> signature verification functionlaity?
>>>>>
>>>>> I have used apahe XML security to sign and verify the digital 
>>>>> signature.
>>>>> When both server and client are using apache libraries, the 
>>>>> functionlity
>>>>> worksfine. When I generated the signed xml using .NET, the 
>>>>> functionlity
>>>>> breaks. I see one extra <Object> inside the <Signature> element. The
>>>>> interoperability seems to be a problem here. Can someone help me in
>>>>> resolving this?
>>>>>
>>>>>
>>>>> Thanks & Regards,
>>>>> Ayyappan Gandhirajan
>>>>> ---------------------------------------------
>>>>> Office: 91.80.2225.1554 Extn 1472
>>>>> Mobile: 91.94483.14969
>>>>> E-Mail: ayyappan.gandhirajan@hp.com
>>>>> -----------------------------------------------
>>>>> <<dotNETsignedMsg.xml>>      
>>>>
>>>>
>>>>
>>>>
>>>>   
>>>
>>>
>>>
>>>
>>>  
>>>
>>
>>
>>
>>
>>




Re: Problem with verification of .NET signed XML

Posted by Berin Lautenbach <be...@wingsofhermes.org>.
Vishal,

It's correct, but unfortunate behaviour.  The namespaces have to be 
cascaded due to the spec using an XPath model for defining how 
canonicalisation is performed.  DOM does not perfectly match to XPath, 
particularly where it comes to namespaces.  Normally you can bypass it, 
but there are some arcane XPath constructs that will only work if 
namespaces are cascaded through the doc.

Unfortunately, those arcane constructs are tested in the interop tests :>.

I'm trying to package up and do dox for 1.1 this weekend, but the first 
thing I want to do after 1.1 is attempt to implement something similar 
to what is used in the C library to only temporarily add the namespaces 
that are required.

Cheers,
	Berin


Vishal Mahajan wrote:

> All:
> 
> I think this might be an important issue. The namespace attributes 
> cascading is carried out by the Java dsig code even if canonicalization 
> transformation is not required to be performed. Is this correct behavior?
> 
> Vishal
> 
> GANDHIRAJAN,AYYAPPAN (HP-India,ex2) wrote:
> 
>> Hi Vishal,
>>
>> Sometime back, there was a discussion going on about this cascading in 
>> one
>> thread with subject "going from signing xml file with DTD to signing xml
>> file with Schema". Do you any clue about the conclusion? Can't I somehow
>> stop cascading?
>>
>> Please do suggest me.
>>
>>
>> Thanks & Regards,
>> Ayyappan Gandhirajan
>> ---------------------------------------------
>> Office: 91.80.2225.1554 Extn 1472
>> Mobile: 91.94483.14969
>> E-Mail: ayyappan.gandhirajan@hp.com
>> -----------------------------------------------
>>
>>
>> -----Original Message-----
>> From: Vishal Mahajan [mailto:Vishal.Mahajan@Sun.COM]
>> Sent: Wednesday, March 31, 2004 6:55 PM
>> To: security-dev@xml.apache.org
>> Subject: Re: Problem with verification of .NET signed XML
>>
>>
>> I think (I am not sure) that this might be happening because of the 
>> namespace attributes cascading that's done by apache dsig library on 
>> the xml document. This, combined with the fact that there's no 
>> canonicalization transform inside the signed-info-reference 
>> (ds:Reference) might be resulting in the interop problem that you are 
>> facing. It would be interesting to know, what happens when you perform 
>> a canon transform on the signature input to be digested.
>>
>> Vishal
>>
>> GANDHIRAJAN,AYYAPPAN (HP-India,ex2) wrote:
>>
>>  
>>
>>> Oop! I forgot to attach the xml message. Please here you go!
>>>
>>>
>>> Thanks & Regards,
>>> Ayyappan Gandhirajan
>>> ---------------------------------------------
>>> Office: 91.80.2225.1554 Extn 1472
>>> Mobile: 91.94483.14969
>>> E-Mail: ayyappan.gandhirajan@hp.com
>>> -----------------------------------------------
>>>
>>>
>>> -----Original Message-----
>>> From: GANDHIRAJAN,AYYAPPAN (HP-India,ex2) Sent: Wednesday, March 31, 
>>> 2004 4:52 PM
>>> To: 'security-dev@xml.apache.org'
>>> Subject: RE: Problem with verification of .NET signed XML
>>>
>>>
>>> Hi Berin,
>>>
>>> Thanks for your mail.
>>>
>>> My client is written using .NET. It creates an XML envelope and sign it.
>>>
>>> My server is written in apache xml security. It verifies the signed xml
>>> messages, which was sent by the client. The "boolean verify =
>>> sig1.checkSignatureValue(sig1.getKeyInfo().getPublicKey())" statement
>>>   
>>
>> always
>>  
>>
>>> return false. The digest value generated is different from the digest 
>>> value
>>> present in the xml message.
>>>
>>> Please find the attached signed xml mesage.
>>>
>>>
>>> Thanks & Regards,
>>> Ayyappan Gandhirajan
>>> ---------------------------------------------
>>> Office: 91.80.2225.1554 Extn 1472
>>> Mobile: 91.94483.14969
>>> E-Mail: ayyappan.gandhirajan@hp.com
>>> -----------------------------------------------
>>>
>>>
>>> -----Original Message-----
>>> From: Berin Lautenbach [mailto:berin@wingsofhermes.org]
>>> Sent: Wednesday, March 31, 2004 4:31 PM
>>> To: security-dev@xml.apache.org
>>> Subject: Re: Problem with verification of .NET signed XML
>>>
>>>
>>> The Object element is simply an artifact for including information to 
>>> be signed or to be used in the signature inside the Signature 
>>> element.  It is not directly included in any signture operation.
>>>
>>> How is the signature breaking?
>>>
>>> Cheers,
>>>     Berin
>>>
>>>
>>> GANDHIRAJAN,AYYAPPAN (HP-India,ex2) wrote:
>>>
>>>
>>>
>>>   
>>>
>>>> Folks,
>>>>
>>>> Though I have been working with XML security for the past four 
>>>> months, I
>>>> have never used "<Object>" tag inside <Signature> element. Can 
>>>> anyone of
>>>>  
>>>>     
>>>
>>> you
>>>
>>>
>>>   
>>>
>>>> please tell me as to what is this Object tag and how it affects the
>>>> signature verification functionlaity?
>>>>
>>>> I have used apahe XML security to sign and verify the digital 
>>>> signature.
>>>> When both server and client are using apache libraries, the 
>>>> functionlity
>>>> worksfine. When I generated the signed xml using .NET, the functionlity
>>>> breaks. I see one extra <Object> inside the <Signature> element. The
>>>> interoperability seems to be a problem here. Can someone help me in
>>>> resolving this?
>>>>
>>>>
>>>> Thanks & Regards,
>>>> Ayyappan Gandhirajan
>>>> ---------------------------------------------
>>>> Office: 91.80.2225.1554 Extn 1472
>>>> Mobile: 91.94483.14969
>>>> E-Mail: ayyappan.gandhirajan@hp.com
>>>> -----------------------------------------------
>>>> <<dotNETsignedMsg.xml>>  
>>>>     
>>>
>>>
>>>
>>>   
>>
>>
>>
>>  
>>
> 
> 
> 
> 
> 

Re: Problem with verification of .NET signed XML

Posted by Vishal Mahajan <Vi...@Sun.COM>.
All:

I think this might be an important issue. The namespace attributes 
cascading is carried out by the Java dsig code even if canonicalization 
transformation is not required to be performed. Is this correct behavior?

Vishal

GANDHIRAJAN,AYYAPPAN (HP-India,ex2) wrote:

>Hi Vishal,
>
>Sometime back, there was a discussion going on about this cascading in one
>thread with subject "going from signing xml file with DTD to signing xml
>file with Schema". Do you any clue about the conclusion? Can't I somehow
>stop cascading?
>
>Please do suggest me.
>
>
>Thanks & Regards,
>Ayyappan Gandhirajan
>---------------------------------------------
>Office: 91.80.2225.1554 Extn 1472
>Mobile: 91.94483.14969
>E-Mail: ayyappan.gandhirajan@hp.com
>-----------------------------------------------
>
>
>-----Original Message-----
>From: Vishal Mahajan [mailto:Vishal.Mahajan@Sun.COM]
>Sent: Wednesday, March 31, 2004 6:55 PM
>To: security-dev@xml.apache.org
>Subject: Re: Problem with verification of .NET signed XML
>
>
>I think (I am not sure) that this might be happening because of the 
>namespace attributes cascading that's done by apache dsig library on the 
>xml document. This, combined with the fact that there's no 
>canonicalization transform inside the signed-info-reference 
>(ds:Reference) might be resulting in the interop problem that you are 
>facing. It would be interesting to know, what happens when you perform a 
>canon transform on the signature input to be digested.
>
>Vishal
>
>GANDHIRAJAN,AYYAPPAN (HP-India,ex2) wrote:
>
>  
>
>>Oop! I forgot to attach the xml message. Please here you go!
>>
>>
>>Thanks & Regards,
>>Ayyappan Gandhirajan
>>---------------------------------------------
>>Office: 91.80.2225.1554 Extn 1472
>>Mobile: 91.94483.14969
>>E-Mail: ayyappan.gandhirajan@hp.com
>>-----------------------------------------------
>>
>>
>>-----Original Message-----
>>From: GANDHIRAJAN,AYYAPPAN (HP-India,ex2) 
>>Sent: Wednesday, March 31, 2004 4:52 PM
>>To: 'security-dev@xml.apache.org'
>>Subject: RE: Problem with verification of .NET signed XML
>>
>>
>>Hi Berin,
>>
>>Thanks for your mail.
>>
>>My client is written using .NET. It creates an XML envelope and sign it.
>>
>>My server is written in apache xml security. It verifies the signed xml
>>messages, which was sent by the client. The "boolean verify =
>>sig1.checkSignatureValue(sig1.getKeyInfo().getPublicKey())" statement
>>    
>>
>always
>  
>
>>return false. The digest value generated is different from the digest value
>>present in the xml message.
>>
>>Please find the attached signed xml mesage.
>>
>>
>>Thanks & Regards,
>>Ayyappan Gandhirajan
>>---------------------------------------------
>>Office: 91.80.2225.1554 Extn 1472
>>Mobile: 91.94483.14969
>>E-Mail: ayyappan.gandhirajan@hp.com
>>-----------------------------------------------
>>
>>
>>-----Original Message-----
>>From: Berin Lautenbach [mailto:berin@wingsofhermes.org]
>>Sent: Wednesday, March 31, 2004 4:31 PM
>>To: security-dev@xml.apache.org
>>Subject: Re: Problem with verification of .NET signed XML
>>
>>
>>The Object element is simply an artifact for including information to be 
>>signed or to be used in the signature inside the Signature element.  It 
>>is not directly included in any signture operation.
>>
>>How is the signature breaking?
>>
>>Cheers,
>>	Berin
>>
>>
>>GANDHIRAJAN,AYYAPPAN (HP-India,ex2) wrote:
>>
>> 
>>
>>    
>>
>>>Folks,
>>>
>>>Though I have been working with XML security for the past four months, I
>>>have never used "<Object>" tag inside <Signature> element. Can anyone of
>>>   
>>>
>>>      
>>>
>>you
>> 
>>
>>    
>>
>>>please tell me as to what is this Object tag and how it affects the
>>>signature verification functionlaity?
>>>
>>>I have used apahe XML security to sign and verify the digital signature.
>>>When both server and client are using apache libraries, the functionlity
>>>worksfine. When I generated the signed xml using .NET, the functionlity
>>>breaks. I see one extra <Object> inside the <Signature> element. The
>>>interoperability seems to be a problem here. Can someone help me in
>>>resolving this?
>>>
>>>
>>>Thanks & Regards,
>>>Ayyappan Gandhirajan
>>>---------------------------------------------
>>>Office: 91.80.2225.1554 Extn 1472
>>>Mobile: 91.94483.14969
>>>E-Mail: ayyappan.gandhirajan@hp.com
>>>-----------------------------------------------
>>><<dotNETsignedMsg.xml>> 
>>>   
>>>
>>>      
>>>
>> 
>>
>>    
>>
>
>
>  
>