From leonardo.herrera at gmail.com  Sat Jan  7 18:39:36 2012
From: leonardo.herrera at gmail.com (Leonardo Herrera)
Date: Sat, 7 Jan 2012 23:39:36 -0300
Subject: [xmlsec] Verify document with multiple signatures
Message-ID: <CAGnFkTKXMjmXiNEKyzdMkjpZr6mJkKZrWAeG6Lnd3GfDMn_JzQ@mail.gmail.com>

Hello,

I'm trying to verify a document that contains multiple signatures; I
cannot modify the structure of the document.

Searching through the archives, I found the following response from
Aleksey regarding this very same problem (this format is used for
electronic invoicing in Chile):

> The xmlsec1 utility tries to find the ds:Signature element
> in the sub-tree specified by --node-id or --node-name
> parameter. The document you have looks as follows (irrelevant
> pieces are removed):
>
> <EnvioDTE>
> 	<SetDTE ID="DTE1272374641984">
> 	 	<DTE>
> 			<Documento ID="F185T33">
> 			</Document>
> 			<ds:Signature>
> 			</ds:SignedInfo>
> 		</DTE>
> 	</SetDTE>
> 	<ds:Signature>
> 	</ds:Signature>
> </EnvioDTE>
>
> I am not exactly sure why the first command verified something
> (I would expect it to do nothing since there are no signature nodes
> in the subtree). But the second command correctly finds the
> first signature element in the subtree specified by the --node-id
> or --node-name parameter (BTW, you just need one parameter :) ).
>
> For documents with multiple signatures, I strongly recommend to
> put ID attribute directly into <ds:Signature> node. This way you
> can easily specify the right signature node to sign or verify.
>
> Regarding the error about xpointer(), please read section 3.4
> from FAQ
>
> http://www.aleksey.com/xmlsec/faq.html
>
> Aleksey

>From what Aleksey wrote, it appears that xmlsec cannot verify the
signature directly under SetDTE because it will find the one under
DTE first. Is possible to ignore the first signature and make
xmlsec read the second one when verifying? I'm currently using

	xmlsec --verify \
	--id-attr:ID http://www.sii.cl/SiiDte:SetDTE \
	dte_set.xml

Regards,
-- 
Leonardo Herrera
http://pipes.epublish.cl/

From aleksey at aleksey.com  Sat Jan  7 18:44:17 2012
From: aleksey at aleksey.com (Aleksey Sanin)
Date: Sat, 07 Jan 2012 18:44:17 -0800
Subject: [xmlsec] Verify document with multiple signatures
In-Reply-To: <CAGnFkTKXMjmXiNEKyzdMkjpZr6mJkKZrWAeG6Lnd3GfDMn_JzQ@mail.gmail.com>
References: <CAGnFkTKXMjmXiNEKyzdMkjpZr6mJkKZrWAeG6Lnd3GfDMn_JzQ@mail.gmail.com>
Message-ID: <4F090301.2070109@aleksey.com>

You can definitely do it with the library itself. The xmlsec
command line tool is somewhat limited. You can try to use
--node-xpath option though.

Aleksey

On 1/7/12 6:39 PM, Leonardo Herrera wrote:
> Hello,
>
> I'm trying to verify a document that contains multiple signatures; I
> cannot modify the structure of the document.
>
> Searching through the archives, I found the following response from
> Aleksey regarding this very same problem (this format is used for
> electronic invoicing in Chile):
>
>> The xmlsec1 utility tries to find the ds:Signature element
>> in the sub-tree specified by --node-id or --node-name
>> parameter. The document you have looks as follows (irrelevant
>> pieces are removed):
>>
>> <EnvioDTE>
>> 	<SetDTE ID="DTE1272374641984">
>> 	 	<DTE>
>> 			<Documento ID="F185T33">
>> 			</Document>
>> 			<ds:Signature>
>> 			</ds:SignedInfo>
>> 		</DTE>
>> 	</SetDTE>
>> 	<ds:Signature>
>> 	</ds:Signature>
>> </EnvioDTE>
>>
>> I am not exactly sure why the first command verified something
>> (I would expect it to do nothing since there are no signature nodes
>> in the subtree). But the second command correctly finds the
>> first signature element in the subtree specified by the --node-id
>> or --node-name parameter (BTW, you just need one parameter :) ).
>>
>> For documents with multiple signatures, I strongly recommend to
>> put ID attribute directly into<ds:Signature>  node. This way you
>> can easily specify the right signature node to sign or verify.
>>
>> Regarding the error about xpointer(), please read section 3.4
>> from FAQ
>>
>> http://www.aleksey.com/xmlsec/faq.html
>>
>> Aleksey
>
>  From what Aleksey wrote, it appears that xmlsec cannot verify the
> signature directly under SetDTE because it will find the one under
> DTE first. Is possible to ignore the first signature and make
> xmlsec read the second one when verifying? I'm currently using
>
> 	xmlsec --verify \
> 	--id-attr:ID http://www.sii.cl/SiiDte:SetDTE \
> 	dte_set.xml
>
> Regards,

From aleksey at aleksey.com  Mon Jan  9 07:15:57 2012
From: aleksey at aleksey.com (Aleksey Sanin)
Date: Mon, 09 Jan 2012 07:15:57 -0800
Subject: [xmlsec] Building xmlsec for iOs
In-Reply-To: <806FA27D-1767-4DC9-83EC-61C2E4BFED41@esdnow.com>
References: <C4C80561-F253-4112-A553-6F76EDF65A5E@esdnow.com>
 <4EF358B6.706@aleksey.com> <806FA27D-1767-4DC9-83EC-61C2E4BFED41@esdnow.com>
Message-ID: <4F0B04AD.4020408@aleksey.com>

Great!

Aleksey

On 1/9/12 6:57 AM, Du?an Kri?an wrote:
> Hi Have found a solution. Problem seams to be in this command:
>
> libtool: link: ar cru .libs/libxmlsec1-openssl.a XMLSec-iOS/../OpenSSL-iOS/bin/iPhoneSimulator5.0.sdk/lib/libcrypto.a  libxmlsec1_open
> ssl_la-app.o libxmlsec1_openssl_la-bn.o libxmlsec1_openssl_la-ciphers.o libxmlsec1_openssl_la-crypto.o libxmlsec1_openssl_la-digests.o libxmlsec1_openssl_la-evp.o libx
> mlsec1_openssl_la-hmac.o libxmlsec1_openssl_la-kw_aes.o libxmlsec1_openssl_la-kw_des.o libxmlsec1_openssl_la-kt_rsa.o libxmlsec1_openssl_la-signatures.o libxmlsec1_ope
> nssl_la-symkeys.o libxmlsec1_openssl_la-x509.o libxmlsec1_openssl_la-x509vfy.o
>
> Solution is to remove "libcrypto.a" from ".libs/libxmlsec1-openssl.a".
>
> What I do is this: after ./configure I run following command: sed -ie "s!\$(OPENSSL_LIBS)!\$(xOPENSSL_LIBS)!" src/openssl/Makefile
>
> Du?an
>
> On Dec 22, 2011, at 5:20 PM, Aleksey Sanin wrote:
>
>> I am not an expert on iOS but this flag sounds wrong
>>
>> -arch i386
>>
>> Aleksey
>>
>> On 12/22/11 12:46 AM, Du?an Kri?an wrote:
>>> Hi All,
>>>
>>> is there any progress on this issue?
>>>
>>> I have found maybe something interesting, but I have to idea how to
>>> correct it.
>>>
>>> First of all I am using version 1.2.12 because there is no libXml2
>>> version 2.7.4 on the iPad, there is only version 2.7.3. There is no
>>> possibility to upgrade iPad and if I will try to compile my own libXml
>>> than Apple will refuse my app from App Store.
>>>
>>> So what I have found is:
>>>
>>> *There is libxmlsec1-openssl.a created by this command:*
>>> rm -fr .libs/libxmlsec1-openssl.a .libs/libxmlsec1-openssl.la
>>> .libs/libxmlsec1-openssl.lai
>>> ar cru .libs/libxmlsec1-openssl.a
>>> <path>/XMLSec-iOS/../OpenSSL-iOS/bin/iPhoneSimulator5.0.sdk//lib/libcrypto.a
>>> libxmlsec1_openssl_la-app.o libxmlsec1_openssl_la-bn.o
>>> libxmlsec1_openssl_la-ciphers.o libxmlsec1_openssl_la-crypto.o
>>> libxmlsec1_openssl_la-digests.o libxmlsec1_openssl_la-evp.o
>>> libxmlsec1_openssl_la-hmac.o libxmlsec1_openssl_la-kw_aes.o
>>> libxmlsec1_openssl_la-kw_des.o libxmlsec1_openssl_la-kt_rsa.o
>>> libxmlsec1_openssl_la-signatures.o libxmlsec1_openssl_la-symkeys.o
>>> libxmlsec1_openssl_la-x509.o libxmlsec1_openssl_la-x509vfy.o
>>> <path>/XMLSec-iOS/../OpenSSL-iOS/bin/iPhoneSimulator5.0.sdk//lib/libcrypto.a
>>> ranlib .libs/libxmlsec1-openssl.a
>>>
>>> *Than follows this link error about ignoring libxmlsec1-openssl.a:*
>>> /Developer/Platforms/iPhoneSimulator.platform/Developer/usr/bin/gcc
>>> -arch i386 -g -O2 -o xmlsec1 xmlsec.o crypto.o cmdline.o
>>> ../src/openssl/.libs/libxmlsec1-openssl.a
>>> <path>/XMLSec-iOS/src/xmlsec1-1.2.12/src/.libs/libxmlsec1.a
>>> ../src/.libs/libxmlsec1.a
>>> <path>/XMLSec-iOS/../OpenSSL-iOS/bin/iPhoneSimulator5.0.sdk//lib/libcrypto.a
>>> -ldl -lxslt -lxml2 -lz -lpthread -licucore -lm
>>> ld: warning: ignoring file ../src/openssl/.libs/libxmlsec1-openssl.a,
>>> file was built for archive which is not the architecture being linked (i386)
>>> Undefined symbols for architecture i386:
>>> "_xmlSecOpenSSLTransformDes3CbcGetKlass", referenced from:
>>> _main in xmlsec.o
>>>
>>> *But if I skip "a" file and replace it directly with "o" files. Than
>>> everything is working correctly:*
>>> /Developer/Platforms/iPhoneSimulator.platform/Developer/usr/bin/gcc
>>> -arch i386 -g -O2 -o xmlsec1 xmlsec.o crypto.o cmdline.o
>>> <path>/XMLSec-iOS/src/xmlsec1-1.2.12/src/.libs/libxmlsec1.a
>>> ../src/.libs/libxmlsec1.a
>>> <path>/XMLSec-iOS/../OpenSSL-iOS/bin/iPhoneSimulator5.0.sdk//lib/libcrypto.a
>>> ../src/openssl/libxmlsec1_openssl_la-app.o
>>> ../src/openssl/libxmlsec1_openssl_la-bn.o
>>> ../src/openssl/libxmlsec1_openssl_la-ciphers.o
>>> ../src/openssl/libxmlsec1_openssl_la-crypto.o
>>> ../src/openssl/libxmlsec1_openssl_la-digests.o
>>> ../src/openssl/libxmlsec1_openssl_la-evp.o
>>> ../src/openssl/libxmlsec1_openssl_la-hmac.o
>>> ../src/openssl/libxmlsec1_openssl_la-kw_aes.o
>>> ../src/openssl/libxmlsec1_openssl_la-kw_des.o
>>> ../src/openssl/libxmlsec1_openssl_la-kt_rsa.o
>>> ../src/openssl/libxmlsec1_openssl_la-signatures.o
>>> ../src/openssl/libxmlsec1_openssl_la-symkeys.o
>>> ../src/openssl/libxmlsec1_openssl_la-x509.o
>>> ../src/openssl/libxmlsec1_openssl_la-x509vfy.o -ldl -lxslt -lxml2 -lz
>>> -lpthread -licucore -lm
>>>
>>> *That means there is something wrong with "ar" and "ranlib" commands.*
>>> Can anybody help me?
>>>
>>> Here is how xmlenc.o is compiled. It is part of libxmlsec1.a, which is
>>> not causing error.
>>> /Developer/Platforms/iPhoneSimulator.platform/Developer/usr/bin/gcc
>>> -arch i386 -DHAVE_CONFIG_H -I. -I. -I.. -DPACKAGE=\"xmlsec1\"
>>> -I../include -I../include -D__XMLS
>>> EC_FUNCTION__=__FUNCTION__ -DXMLSEC_NO_GOST=1 -DXMLSEC_NO_XKMS=1
>>> -DXMLSEC_NO_CRYPTO_DYNAMIC_LOADING=1 -I/usr/include/libxml2
>>> -l/usr/include/libxml2 -g -O2 -MT xmlenc.lo -MD -MP -MF .deps/xmlenc.Tpo
>>> -c xmlenc.c -o xmlenc.o
>>>
>>> Here is how libxmlsec1_openssl_la-symkeys.o is compiled. It is part of
>>> libxmlsec1-openssl.a, which is causing error.
>>> /Developer/Platforms/iPhoneSimulator.platform/Developer/usr/bin/gcc
>>> -arch i386 -DHAVE_CONFIG_H -I. -I. -I../.. -DPACKAGE=\"xmlsec1\"
>>> -I../../include -I../../include
>>> -D__XMLSEC_FUNCTION__=__FUNCTION__ -DXMLSEC_NO_GOST=1 -DXMLSEC_NO_XKMS=1
>>> -DXMLSEC_NO_CRYPTO_DYNAMIC_LOADING=1
>>> -I<path>/XMLSec-iOS/../OpenSSL-iOS/bin/iPhoneSimulator5.0.sdk//include
>>> -DXMLSEC_OPENSSL_098=1 -DXMLSEC_CRYPTO_OPENSSL=1 -I/usr/include/libxml2
>>> -I/usr/include/libxml2 -g -O2 -MT libxmlsec1_openssl_la-symkeys.lo -MD
>>> -MP -MF .deps/libxmlsec1_openssl_la-symkeys.Tpo -c symkeys.c -o
>>> libxmlsec1_openssl_la-symkeys.o
>>>
>>> Thanks a lot in advance
>>> Dusan
>>>
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> xmlsec mailing list
>>> xmlsec at aleksey.com
>>> http://www.aleksey.com/mailman/listinfo/xmlsec
>

From aleksey at aleksey.com  Tue Jan 10 07:49:14 2012
From: aleksey at aleksey.com (Aleksey Sanin)
Date: Tue, 10 Jan 2012 07:49:14 -0800
Subject: [xmlsec] Building xmlsec for iOs
In-Reply-To: <7F484365-26AC-4EA7-A9D5-5CA933B430C5@esdnow.com>
References: <C4C80561-F253-4112-A553-6F76EDF65A5E@esdnow.com>
 <4EF358B6.706@aleksey.com> <806FA27D-1767-4DC9-83EC-61C2E4BFED41@esdnow.com>
 <4F0B04AD.4020408@aleksey.com>
 <7F484365-26AC-4EA7-A9D5-5CA933B430C5@esdnow.com>
Message-ID: <4F0C5DFA.2070104@aleksey.com>

You can definitely do that but remember that the signed content
might not be a valid XML.

You will need to set this flag in the signature context:

http://www.aleksey.com/xmlsec/api/xmlsec-xmldsig.html#XMLSEC-DSIG-FLAGS-STORE-SIGNEDINFO-REFERENCES:CAPS

Take a look at --store-reference option in xmlsec command line utility
for the usage example.

Aleksey

On 1/10/12 2:41 AM, Du?an Kri?an wrote:
> Hi Aleksey,
>
> maybe I have missed something, but I cannot find how to get the verified content.
>
> My situation is this. In one xml file I have several contents, lets say c1, c2, c3. Every content has it own signature s1, s2, s3. What I am doing is that I search node with the signature let's say s1, call the xmlSecDSigCtxVerify(ctx, s1). Somewhere inside there have to be located the content c1 and verified. I would like to be able get the c1 somehow from xmlSecDSigCtx.
>
> Of course, you can say that I can use the original xml document and find the c1. But this approach is error prone. I can do the mistake or bug. I have to be 100% sure that I am working with the c1 which has been verified by xmlSecDSigCtxVerify.
>
> Thank you in advance
> Dusan
>
>
> On Jan 9, 2012, at 4:15 PM, Aleksey Sanin wrote:
>
>> Great!
>>
>> Aleksey
>>
>> On 1/9/12 6:57 AM, Du?an Kri?an wrote:
>>> Hi Have found a solution. Problem seams to be in this command:
>>>
>>> libtool: link: ar cru .libs/libxmlsec1-openssl.a XMLSec-iOS/../OpenSSL-iOS/bin/iPhoneSimulator5.0.sdk/lib/libcrypto.a  libxmlsec1_open
>>> ssl_la-app.o libxmlsec1_openssl_la-bn.o libxmlsec1_openssl_la-ciphers.o libxmlsec1_openssl_la-crypto.o libxmlsec1_openssl_la-digests.o libxmlsec1_openssl_la-evp.o libx
>>> mlsec1_openssl_la-hmac.o libxmlsec1_openssl_la-kw_aes.o libxmlsec1_openssl_la-kw_des.o libxmlsec1_openssl_la-kt_rsa.o libxmlsec1_openssl_la-signatures.o libxmlsec1_ope
>>> nssl_la-symkeys.o libxmlsec1_openssl_la-x509.o libxmlsec1_openssl_la-x509vfy.o
>>>
>>> Solution is to remove "libcrypto.a" from ".libs/libxmlsec1-openssl.a".
>>>
>>> What I do is this: after ./configure I run following command: sed -ie "s!\$(OPENSSL_LIBS)!\$(xOPENSSL_LIBS)!" src/openssl/Makefile
>>>
>>> Du?an
>>>
>>> On Dec 22, 2011, at 5:20 PM, Aleksey Sanin wrote:
>>>
>>>> I am not an expert on iOS but this flag sounds wrong
>>>>
>>>> -arch i386
>>>>
>>>> Aleksey
>>>>
>>>> On 12/22/11 12:46 AM, Du?an Kri?an wrote:
>>>>> Hi All,
>>>>>
>>>>> is there any progress on this issue?
>>>>>
>>>>> I have found maybe something interesting, but I have to idea how to
>>>>> correct it.
>>>>>
>>>>> First of all I am using version 1.2.12 because there is no libXml2
>>>>> version 2.7.4 on the iPad, there is only version 2.7.3. There is no
>>>>> possibility to upgrade iPad and if I will try to compile my own libXml
>>>>> than Apple will refuse my app from App Store.
>>>>>
>>>>> So what I have found is:
>>>>>
>>>>> *There is libxmlsec1-openssl.a created by this command:*
>>>>> rm -fr .libs/libxmlsec1-openssl.a .libs/libxmlsec1-openssl.la
>>>>> .libs/libxmlsec1-openssl.lai
>>>>> ar cru .libs/libxmlsec1-openssl.a
>>>>> <path>/XMLSec-iOS/../OpenSSL-iOS/bin/iPhoneSimulator5.0.sdk//lib/libcrypto.a
>>>>> libxmlsec1_openssl_la-app.o libxmlsec1_openssl_la-bn.o
>>>>> libxmlsec1_openssl_la-ciphers.o libxmlsec1_openssl_la-crypto.o
>>>>> libxmlsec1_openssl_la-digests.o libxmlsec1_openssl_la-evp.o
>>>>> libxmlsec1_openssl_la-hmac.o libxmlsec1_openssl_la-kw_aes.o
>>>>> libxmlsec1_openssl_la-kw_des.o libxmlsec1_openssl_la-kt_rsa.o
>>>>> libxmlsec1_openssl_la-signatures.o libxmlsec1_openssl_la-symkeys.o
>>>>> libxmlsec1_openssl_la-x509.o libxmlsec1_openssl_la-x509vfy.o
>>>>> <path>/XMLSec-iOS/../OpenSSL-iOS/bin/iPhoneSimulator5.0.sdk//lib/libcrypto.a
>>>>> ranlib .libs/libxmlsec1-openssl.a
>>>>>
>>>>> *Than follows this link error about ignoring libxmlsec1-openssl.a:*
>>>>> /Developer/Platforms/iPhoneSimulator.platform/Developer/usr/bin/gcc
>>>>> -arch i386 -g -O2 -o xmlsec1 xmlsec.o crypto.o cmdline.o
>>>>> ../src/openssl/.libs/libxmlsec1-openssl.a
>>>>> <path>/XMLSec-iOS/src/xmlsec1-1.2.12/src/.libs/libxmlsec1.a
>>>>> ../src/.libs/libxmlsec1.a
>>>>> <path>/XMLSec-iOS/../OpenSSL-iOS/bin/iPhoneSimulator5.0.sdk//lib/libcrypto.a
>>>>> -ldl -lxslt -lxml2 -lz -lpthread -licucore -lm
>>>>> ld: warning: ignoring file ../src/openssl/.libs/libxmlsec1-openssl.a,
>>>>> file was built for archive which is not the architecture being linked (i386)
>>>>> Undefined symbols for architecture i386:
>>>>> "_xmlSecOpenSSLTransformDes3CbcGetKlass", referenced from:
>>>>> _main in xmlsec.o
>>>>>
>>>>> *But if I skip "a" file and replace it directly with "o" files. Than
>>>>> everything is working correctly:*
>>>>> /Developer/Platforms/iPhoneSimulator.platform/Developer/usr/bin/gcc
>>>>> -arch i386 -g -O2 -o xmlsec1 xmlsec.o crypto.o cmdline.o
>>>>> <path>/XMLSec-iOS/src/xmlsec1-1.2.12/src/.libs/libxmlsec1.a
>>>>> ../src/.libs/libxmlsec1.a
>>>>> <path>/XMLSec-iOS/../OpenSSL-iOS/bin/iPhoneSimulator5.0.sdk//lib/libcrypto.a
>>>>> ../src/openssl/libxmlsec1_openssl_la-app.o
>>>>> ../src/openssl/libxmlsec1_openssl_la-bn.o
>>>>> ../src/openssl/libxmlsec1_openssl_la-ciphers.o
>>>>> ../src/openssl/libxmlsec1_openssl_la-crypto.o
>>>>> ../src/openssl/libxmlsec1_openssl_la-digests.o
>>>>> ../src/openssl/libxmlsec1_openssl_la-evp.o
>>>>> ../src/openssl/libxmlsec1_openssl_la-hmac.o
>>>>> ../src/openssl/libxmlsec1_openssl_la-kw_aes.o
>>>>> ../src/openssl/libxmlsec1_openssl_la-kw_des.o
>>>>> ../src/openssl/libxmlsec1_openssl_la-kt_rsa.o
>>>>> ../src/openssl/libxmlsec1_openssl_la-signatures.o
>>>>> ../src/openssl/libxmlsec1_openssl_la-symkeys.o
>>>>> ../src/openssl/libxmlsec1_openssl_la-x509.o
>>>>> ../src/openssl/libxmlsec1_openssl_la-x509vfy.o -ldl -lxslt -lxml2 -lz
>>>>> -lpthread -licucore -lm
>>>>>
>>>>> *That means there is something wrong with "ar" and "ranlib" commands.*
>>>>> Can anybody help me?
>>>>>
>>>>> Here is how xmlenc.o is compiled. It is part of libxmlsec1.a, which is
>>>>> not causing error.
>>>>> /Developer/Platforms/iPhoneSimulator.platform/Developer/usr/bin/gcc
>>>>> -arch i386 -DHAVE_CONFIG_H -I. -I. -I.. -DPACKAGE=\"xmlsec1\"
>>>>> -I../include -I../include -D__XMLS
>>>>> EC_FUNCTION__=__FUNCTION__ -DXMLSEC_NO_GOST=1 -DXMLSEC_NO_XKMS=1
>>>>> -DXMLSEC_NO_CRYPTO_DYNAMIC_LOADING=1 -I/usr/include/libxml2
>>>>> -l/usr/include/libxml2 -g -O2 -MT xmlenc.lo -MD -MP -MF .deps/xmlenc.Tpo
>>>>> -c xmlenc.c -o xmlenc.o
>>>>>
>>>>> Here is how libxmlsec1_openssl_la-symkeys.o is compiled. It is part of
>>>>> libxmlsec1-openssl.a, which is causing error.
>>>>> /Developer/Platforms/iPhoneSimulator.platform/Developer/usr/bin/gcc
>>>>> -arch i386 -DHAVE_CONFIG_H -I. -I. -I../.. -DPACKAGE=\"xmlsec1\"
>>>>> -I../../include -I../../include
>>>>> -D__XMLSEC_FUNCTION__=__FUNCTION__ -DXMLSEC_NO_GOST=1 -DXMLSEC_NO_XKMS=1
>>>>> -DXMLSEC_NO_CRYPTO_DYNAMIC_LOADING=1
>>>>> -I<path>/XMLSec-iOS/../OpenSSL-iOS/bin/iPhoneSimulator5.0.sdk//include
>>>>> -DXMLSEC_OPENSSL_098=1 -DXMLSEC_CRYPTO_OPENSSL=1 -I/usr/include/libxml2
>>>>> -I/usr/include/libxml2 -g -O2 -MT libxmlsec1_openssl_la-symkeys.lo -MD
>>>>> -MP -MF .deps/libxmlsec1_openssl_la-symkeys.Tpo -c symkeys.c -o
>>>>> libxmlsec1_openssl_la-symkeys.o
>>>>>
>>>>> Thanks a lot in advance
>>>>> Dusan
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> xmlsec mailing list
>>>>> xmlsec at aleksey.com
>>>>> http://www.aleksey.com/mailman/listinfo/xmlsec
>>>
>

From ed.shallow at gmail.com  Thu Jan 12 15:53:14 2012
From: ed.shallow at gmail.com (EdShallow)
Date: Thu, 12 Jan 2012 18:53:14 -0500
Subject: [xmlsec] Strange Environmental Problem on certain Windows machines
Message-ID: <CAB3xoRiKQm-WR_YTh1MzfhpaXyCrHNs9+OHyGm4x9-aMyjR0KA@mail.gmail.com>

Hi Aleksey,

      I have had this xmlsec application (now at 1.2.18) working for
several years without incident on Windows XP, Vista, and even Windows 7.

However on selected machines that I run the application on, I get an I/O
error related to buffer flushing and C14N canonicalization. This only
happens on certain Windows XP machines and I think it is related to some
run-time executable (.dll or exe) outside my environment.

Here is the summary trace of what comes out on the console .... note where
there error occurs between xmlSecDSigCtxInitialize and xmlSecDSigCtxSign

input buffer follows .... write to stdout from my application

<?xml version="1.0"?>
<Data>
    <SubData1>
        <SubSubData1 MimeType="text/plain">This is the data to be
signed.</SubSubData1>
        <SubSubData2 MimeType="text/plain">This is the data to be
signed.</SubSubData2>
        <SubSubData3 MimeType="text/plain">This is the data to be
signed.</SubSubData3>
    </SubData1>
    <SubData2>This is the data to be signed.</SubData2>
    <SubData3>This is the data to be signed.</SubData3>
<dsig:Signature xmlns:dsig="http://www.w3.org/2000/09/xmldsig#">
    <dsig:SignedInfo>
        <dsig:CanonicalizationMethod Algorithm="
http://www.w3.org/2001/10/xml-exc-c14n#"/>
        <dsig:SignatureMethod Algorithm="
http://www.w3.org/2001/04/xmldsig-more#rsa-sha256"/>
        <dsig:Reference URI="">
            <dsig:Transforms>
                <dsig:Transform Algorithm="
http://www.w3.org/2000/09/xmldsig#enveloped-signature"/>
            </dsig:Transforms>
            <dsig:DigestMethod Algorithm="
http://www.w3.org/2001/04/xmlenc#sha256"/>
            <dsig:DigestValue/>
        </dsig:Reference>
    </dsig:SignedInfo>
    <dsig:SignatureValue/>
    <dsig:KeyInfo>
        <dsig:KeyName>Shallow, Ed</dsig:KeyName>
        <dsig:X509Data><dsig:X509Certificate/><dsig:X509IssuerSerial/>
        </dsig:X509Data>
    </dsig:KeyInfo>
</dsig:Signature></Data>

after xmlSecDSigCtxCreate  .... write to stdout from my app
after xmlSecDSigCtxInitialize .... write to stfout from my app

I/O error : flush error
C14N error : Internal error : flushing output buffer

after xmlSecDSigCtxSign .... write to stdout from my app

2012/01/12 18:36:53  INFO Sign with TransactionID 00000000 completed on
thread 1 with Status ===> 1716 and ErrorMessage
==> Failed to create signature  Invalid algorithm specified.   Error
occurred in function xmlSecDSigCtxSign at line 303
relating to xmlSecDSigCtxSigantureProcessNode<br> Document length 429.

Any ideas which .dll .exe may be missing, wrong version, etc ....

Many thanks . . .

Ed

-- 
Ed's Contact Information:
Mobile Phone: 613-852-6410
Gmail: ed.shallow at gmail.com
VOIP Address: 107529 at sip.ca1.voip.ms
VOIP DID#: 613-458-5004
Skype ID: edward.shallow
Home Phone: 613-482-2090
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.aleksey.com/pipermail/xmlsec/attachments/20120112/277a8aa0/attachment.html>

From aleksey at aleksey.com  Thu Jan 12 21:51:01 2012
From: aleksey at aleksey.com (Aleksey Sanin)
Date: Thu, 12 Jan 2012 21:51:01 -0800
Subject: [xmlsec] Strange Environmental Problem on certain Windows
	machines
In-Reply-To: <CAB3xoRiKQm-WR_YTh1MzfhpaXyCrHNs9+OHyGm4x9-aMyjR0KA@mail.gmail.com>
References: <CAB3xoRiKQm-WR_YTh1MzfhpaXyCrHNs9+OHyGm4x9-aMyjR0KA@mail.gmail.com>
Message-ID: <4F0FC645.1090903@aleksey.com>

You are probably right, the problem is in the runtime libs. Can you 
check and compare the versions for MS C runtime dlls?

Another idea is something like antivirus (or virus) that modifies
the executable code while loading it in memory.

Aleksey

On 1/12/12 3:53 PM, EdShallow wrote:
> Hi Aleksey,
>
>        I have had this xmlsec application (now at 1.2.18) working for
> several years without incident on Windows XP, Vista, and even Windows 7.
>
> However on selected machines that I run the application on, I get an I/O
> error related to buffer flushing and C14N canonicalization. This only
> happens on certain Windows XP machines and I think it is related to some
> run-time executable (.dll or exe) outside my environment.
>
> Here is the summary trace of what comes out on the console .... note
> where there error occurs between xmlSecDSigCtxInitialize and
> xmlSecDSigCtxSign
>
> input buffer follows .... write to stdout from my application
>
> <?xml version="1.0"?>
> <Data>
> <SubData1>
> <SubSubData1 MimeType="text/plain">This is the data to be
> signed.</SubSubData1>
> <SubSubData2 MimeType="text/plain">This is the data to be
> signed.</SubSubData2>
> <SubSubData3 MimeType="text/plain">This is the data to be
> signed.</SubSubData3>
> </SubData1>
> <SubData2>This is the data to be signed.</SubData2>
> <SubData3>This is the data to be signed.</SubData3>
> <dsig:Signature xmlns:dsig="http://www.w3.org/2000/09/xmldsig#">
> <dsig:SignedInfo>
> <dsig:CanonicalizationMethod
> Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>
> <dsig:SignatureMethod
> Algorithm="http://www.w3.org/2001/04/xmldsig-more#rsa-sha256"/>
> <dsig:Reference URI="">
> <dsig:Transforms>
> <dsig:Transform
> Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature"/>
> </dsig:Transforms>
> <dsig:DigestMethod Algorithm="http://www.w3.org/2001/04/xmlenc#sha256"/>
> <dsig:DigestValue/>
> </dsig:Reference>
> </dsig:SignedInfo>
> <dsig:SignatureValue/>
> <dsig:KeyInfo>
> <dsig:KeyName>Shallow, Ed</dsig:KeyName>
> <dsig:X509Data><dsig:X509Certificate/><dsig:X509IssuerSerial/>
> </dsig:X509Data>
> </dsig:KeyInfo>
> </dsig:Signature></Data>
>
> after xmlSecDSigCtxCreate  .... write to stdout from my app
> after xmlSecDSigCtxInitialize .... write to stfout from my app
>
> I/O error : flush error
> C14N error : Internal error : flushing output buffer
>
> after xmlSecDSigCtxSign .... write to stdout from my app
>
> 2012/01/12 18:36:53  INFO Sign with TransactionID 00000000 completed on
> thread 1 with Status ===> 1716 and ErrorMessage
> ==> Failed to create signature  Invalid algorithm specified.   Error
> occurred in function xmlSecDSigCtxSign at line 303
> relating to xmlSecDSigCtxSigantureProcessNode<br> Document length 429.
>
> Any ideas which .dll .exe may be missing, wrong version, etc ....
>
> Many thanks . . .
>
> Ed
>
> --
> Ed's Contact Information:
> Mobile Phone: 613-852-6410
> Gmail: ed.shallow at gmail.com <mailto:ed.shallow at gmail.com>
> VOIP Address: 107529 at sip.ca1.voip.ms <mailto:107529 at sip.ca1.voip.ms>
> VOIP DID#: 613-458-5004
> Skype ID: edward.shallow
> Home Phone: 613-482-2090
>
>
>
> _______________________________________________
> xmlsec mailing list
> xmlsec at aleksey.com
> http://www.aleksey.com/mailman/listinfo/xmlsec

From ed.shallow at gmail.com  Fri Jan 13 08:14:04 2012
From: ed.shallow at gmail.com (EdShallow)
Date: Fri, 13 Jan 2012 11:14:04 -0500
Subject: [xmlsec] Strange Environmental Problem on certain Windows
	machines
In-Reply-To: <4F0FC645.1090903@aleksey.com>
References: <CAB3xoRiKQm-WR_YTh1MzfhpaXyCrHNs9+OHyGm4x9-aMyjR0KA@mail.gmail.com>
 <4F0FC645.1090903@aleksey.com>
Message-ID: <CAB3xoRj-u8wf+S4U-zjzyzwxjne=k8mUGxWCO8JgCxKn2E6XeQ@mail.gmail.com>

It was libxml2 used by Apple in Common Programs and by Pidgin the IM
client. One has to be carefull about .dll search order on Windows.
Thanks Ed
On Jan 13, 2012 12:51 AM, "Aleksey Sanin" <aleksey at aleksey.com> wrote:

> You are probably right, the problem is in the runtime libs. Can you check
> and compare the versions for MS C runtime dlls?
>
> Another idea is something like antivirus (or virus) that modifies
> the executable code while loading it in memory.
>
> Aleksey
>
> On 1/12/12 3:53 PM, EdShallow wrote:
>
>> Hi Aleksey,
>>
>>       I have had this xmlsec application (now at 1.2.18) working for
>> several years without incident on Windows XP, Vista, and even Windows 7.
>>
>> However on selected machines that I run the application on, I get an I/O
>> error related to buffer flushing and C14N canonicalization. This only
>> happens on certain Windows XP machines and I think it is related to some
>> run-time executable (.dll or exe) outside my environment.
>>
>> Here is the summary trace of what comes out on the console .... note
>> where there error occurs between xmlSecDSigCtxInitialize and
>> xmlSecDSigCtxSign
>>
>> input buffer follows .... write to stdout from my application
>>
>> <?xml version="1.0"?>
>> <Data>
>> <SubData1>
>> <SubSubData1 MimeType="text/plain">This is the data to be
>> signed.</SubSubData1>
>> <SubSubData2 MimeType="text/plain">This is the data to be
>> signed.</SubSubData2>
>> <SubSubData3 MimeType="text/plain">This is the data to be
>> signed.</SubSubData3>
>> </SubData1>
>> <SubData2>This is the data to be signed.</SubData2>
>> <SubData3>This is the data to be signed.</SubData3>
>> <dsig:Signature xmlns:dsig="http://www.w3.org/**2000/09/xmldsig#<http://www.w3.org/2000/09/xmldsig#>
>> ">
>> <dsig:SignedInfo>
>> <dsig:CanonicalizationMethod
>> Algorithm="http://www.w3.org/**2001/10/xml-exc-c14n#<http://www.w3.org/2001/10/xml-exc-c14n#>
>> "/>
>> <dsig:SignatureMethod
>> Algorithm="http://www.w3.org/**2001/04/xmldsig-more#rsa-**sha256<http://www.w3.org/2001/04/xmldsig-more#rsa-sha256>
>> "/>
>> <dsig:Reference URI="">
>> <dsig:Transforms>
>> <dsig:Transform
>> Algorithm="http://www.w3.org/**2000/09/xmldsig#enveloped-**signature<http://www.w3.org/2000/09/xmldsig#enveloped-signature>
>> "/>
>> </dsig:Transforms>
>> <dsig:DigestMethod Algorithm="http://www.w3.org/**2001/04/xmlenc#sha256<http://www.w3.org/2001/04/xmlenc#sha256>
>> "/>
>> <dsig:DigestValue/>
>> </dsig:Reference>
>> </dsig:SignedInfo>
>> <dsig:SignatureValue/>
>> <dsig:KeyInfo>
>> <dsig:KeyName>Shallow, Ed</dsig:KeyName>
>> <dsig:X509Data><dsig:**X509Certificate/><dsig:**X509IssuerSerial/>
>> </dsig:X509Data>
>> </dsig:KeyInfo>
>> </dsig:Signature></Data>
>>
>> after xmlSecDSigCtxCreate  .... write to stdout from my app
>> after xmlSecDSigCtxInitialize .... write to stfout from my app
>>
>> I/O error : flush error
>> C14N error : Internal error : flushing output buffer
>>
>> after xmlSecDSigCtxSign .... write to stdout from my app
>>
>> 2012/01/12 18:36:53  INFO Sign with TransactionID 00000000 completed on
>> thread 1 with Status ===> 1716 and ErrorMessage
>> ==> Failed to create signature  Invalid algorithm specified.   Error
>> occurred in function xmlSecDSigCtxSign at line 303
>> relating to xmlSecDSigCtxSigantureProcessN**ode<br> Document length 429.
>>
>> Any ideas which .dll .exe may be missing, wrong version, etc ....
>>
>> Many thanks . . .
>>
>> Ed
>>
>> --
>> Ed's Contact Information:
>> Mobile Phone: 613-852-6410
>> Gmail: ed.shallow at gmail.com <mailto:ed.shallow at gmail.com>
>> VOIP Address: 107529 at sip.ca1.voip.ms <mailto:107529 at sip.ca1.voip.ms**>
>> VOIP DID#: 613-458-5004
>> Skype ID: edward.shallow
>> Home Phone: 613-482-2090
>>
>>
>>
>> ______________________________**_________________
>> xmlsec mailing list
>> xmlsec at aleksey.com
>> http://www.aleksey.com/**mailman/listinfo/xmlsec<http://www.aleksey.com/mailman/listinfo/xmlsec>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.aleksey.com/pipermail/xmlsec/attachments/20120113/badc9122/attachment.html>

From beldmit at gmail.com  Fri Jan 27 12:20:59 2012
From: beldmit at gmail.com (Dmitry Belyavsky)
Date: Sat, 28 Jan 2012 00:20:59 +0400
Subject: [xmlsec] Problems in Gost2001 OpenSSL implementation
Message-ID: <CADqLbzKN=WyteAmuZF+13KKKaXJw=vsX-iSubCEUUBphGZXVyA@mail.gmail.com>

Greetings!

Aleksey, I've found 2 problems in Gost2001 OpenSSL implementation.

1. The definitions of
xmlSecTransformGost2001GostR3411_94Id and xmlSecTransformGostR3411_94Id
are missed in include/xmlsec/openssl/symbols.h

2. The function xmlSecOpenSSLKeyDataGost2001GetSize should always
return 512 after the successful assert passing.

Unfortunately, I can't provide the patch now. Can you fix it yourself?

Thank you!

-- 
SY, Dmitry Belyavsky

From beldmit at gmail.com  Tue Jan 31 11:14:25 2012
From: beldmit at gmail.com (Dmitry Belyavsky)
Date: Tue, 31 Jan 2012 23:14:25 +0400
Subject: [xmlsec] Expanding xmlSecKeyDataFormat enum?
Message-ID: <CADqLbzKr4TgQuUrWmLzDGqFrvpaQSq9gfOf7yYUn2-+ZU2eFpw@mail.gmail.com>

Greetings!

We need to load private key from hardware token using our engine.
Analyzing the xmlSecOpenSSLAppKeyLoad function, I think it should be
better to add to the xmlSecKeyDataFormat enum another option,
xmlSecKeyDataFormatEngine or provide a similar function
xmlSecOpenSSLAppKeyLoadEngine accepting the engine name, smth as
filename and not accepting the xmlSecKeyDataFormat arg at all.

Which variant is more acceptable for you?
Thank you!

-- 
SY, Dmitry Belyavsky

From aleksey at aleksey.com  Tue Jan 31 11:29:08 2012
From: aleksey at aleksey.com (Aleksey Sanin)
Date: Tue, 31 Jan 2012 11:29:08 -0800
Subject: [xmlsec] Problems in Gost2001 OpenSSL implementation
In-Reply-To: <CADqLbzKN=WyteAmuZF+13KKKaXJw=vsX-iSubCEUUBphGZXVyA@mail.gmail.com>
References: <CADqLbzKN=WyteAmuZF+13KKKaXJw=vsX-iSubCEUUBphGZXVyA@mail.gmail.com>
Message-ID: <4F284104.6090801@aleksey.com>

Sorry for delay, both were fixed.

Aleksey

On 1/27/12 12:20 PM, Dmitry Belyavsky wrote:
> Greetings!
> 
> Aleksey, I've found 2 problems in Gost2001 OpenSSL implementation.
> 
> 1. The definitions of
> xmlSecTransformGost2001GostR3411_94Id and xmlSecTransformGostR3411_94Id
> are missed in include/xmlsec/openssl/symbols.h
> 
> 2. The function xmlSecOpenSSLKeyDataGost2001GetSize should always
> return 512 after the successful assert passing.
> 
> Unfortunately, I can't provide the patch now. Can you fix it yourself?
> 
> Thank you!
> 

From aleksey at aleksey.com  Tue Jan 31 11:29:58 2012
From: aleksey at aleksey.com (Aleksey Sanin)
Date: Tue, 31 Jan 2012 11:29:58 -0800
Subject: [xmlsec] Expanding xmlSecKeyDataFormat enum?
In-Reply-To: <CADqLbzKr4TgQuUrWmLzDGqFrvpaQSq9gfOf7yYUn2-+ZU2eFpw@mail.gmail.com>
References: <CADqLbzKr4TgQuUrWmLzDGqFrvpaQSq9gfOf7yYUn2-+ZU2eFpw@mail.gmail.com>
Message-ID: <4F284136.1040605@aleksey.com>

I think the second one with a special function is better.

The xmlSecOpenSSLAppKeyLoad() is specifically designed to load
keys from files.

Aleksey

On 1/31/12 11:14 AM, Dmitry Belyavsky wrote:
> Greetings!
> 
> We need to load private key from hardware token using our engine.
> Analyzing the xmlSecOpenSSLAppKeyLoad function, I think it should be
> better to add to the xmlSecKeyDataFormat enum another option,
> xmlSecKeyDataFormatEngine or provide a similar function
> xmlSecOpenSSLAppKeyLoadEngine accepting the engine name, smth as
> filename and not accepting the xmlSecKeyDataFormat arg at all.
> 
> Which variant is more acceptable for you?
> Thank you!
> 

From ed.shallow at gmail.com  Tue Feb  7 10:27:35 2012
From: ed.shallow at gmail.com (EdShallow)
Date: Tue, 7 Feb 2012 13:27:35 -0500
Subject: [xmlsec] Another Windows Environment Problem
Message-ID: <CAB3xoRgOL5OqoE8S8p+R2FHCDDSVJUY+Y204xQQOHm_LzL2LYw@mail.gmail.com>

Everything working fine on my deployed xmlsec application on Windows 7,
Vista, and XP

However on certain XP machines everything works fine, except when using
file paths in the Reference URI . . . example:

    <dsig:Reference URI="/xmldsig/dist/inout/gc/xmldata.xml">

. . . xmldata.xml is the file to be signed.

I get this error when xmlsec tries to resolve the filename:

Failed to create signature The filename, directory name, or volume label
syntax is incorrect. Error occurred in function xmlSecDSigCtxSign at line
303 relating to xmlSecDSigCtxSigantureProcessNode

All other templates work fine ???

Ed


-- 
Ed's Contact Information:
Mobile Phone: 613-852-6410
Gmail: ed.shallow at gmail.com
VOIP Address: 107529 at sip.ca1.voip.ms
VOIP DID#: 613-458-5004
Skype ID: edward.shallow
Home Phone: 613-482-2090
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.aleksey.com/pipermail/xmlsec/attachments/20120207/11886ae2/attachment.html>

From aleksey at aleksey.com  Tue Feb  7 10:40:15 2012
From: aleksey at aleksey.com (Aleksey Sanin)
Date: Tue, 07 Feb 2012 10:40:15 -0800
Subject: [xmlsec] Another Windows Environment Problem
In-Reply-To: <CAB3xoRgOL5OqoE8S8p+R2FHCDDSVJUY+Y204xQQOHm_LzL2LYw@mail.gmail.com>
References: <CAB3xoRgOL5OqoE8S8p+R2FHCDDSVJUY+Y204xQQOHm_LzL2LYw@mail.gmail.com>
Message-ID: <4F31700F.6060601@aleksey.com>

Permissions problem?

Aleksey

On 2/7/12 10:27 AM, EdShallow wrote:
> Everything working fine on my deployed xmlsec application on Windows 7,
> Vista, and XP
> 
> However on certain XP machines everything works fine, except when using
> file paths in the Reference URI . . . example:
> 
>     <dsig:Reference URI="/xmldsig/dist/inout/gc/xmldata.xml">
> 
> . . . xmldata.xml is the file to be signed.
> 
> I get this error when xmlsec tries to resolve the filename:
> 
> Failed to create signature The filename, directory name, or volume label
> syntax is incorrect. Error occurred in function xmlSecDSigCtxSign at
> line 303 relating to xmlSecDSigCtxSigantureProcessNode
> 
> All other templates work fine ???
> 
> Ed
> 
> 
> -- 
> Ed's Contact Information:
> Mobile Phone: 613-852-6410
> Gmail: ed.shallow at gmail.com <mailto:ed.shallow at gmail.com>
> VOIP Address: 107529 at sip.ca1.voip.ms <mailto:107529 at sip.ca1.voip.ms>
> VOIP DID#: 613-458-5004
> Skype ID: edward.shallow
> Home Phone: 613-482-2090
> 
> 
> 
> _______________________________________________
> xmlsec mailing list
> xmlsec at aleksey.com
> http://www.aleksey.com/mailman/listinfo/xmlsec

From ed.shallow at gmail.com  Tue Feb  7 10:42:17 2012
From: ed.shallow at gmail.com (EdShallow)
Date: Tue, 7 Feb 2012 13:42:17 -0500
Subject: [xmlsec] Another Windows Environment Problem
In-Reply-To: <4F31700F.6060601@aleksey.com>
References: <CAB3xoRgOL5OqoE8S8p+R2FHCDDSVJUY+Y204xQQOHm_LzL2LYw@mail.gmail.com>
 <4F31700F.6060601@aleksey.com>
Message-ID: <CAB3xoRgFiKoseYMeaHNgM1k65ULmZdADYib9RBvJtASCxmk4iQ@mail.gmail.com>

I think so . . . I will try a few things
On Feb 7, 2012 1:40 PM, "Aleksey Sanin" <aleksey at aleksey.com> wrote:

> Permissions problem?
>
> Aleksey
>
> On 2/7/12 10:27 AM, EdShallow wrote:
> > Everything working fine on my deployed xmlsec application on Windows 7,
> > Vista, and XP
> >
> > However on certain XP machines everything works fine, except when using
> > file paths in the Reference URI . . . example:
> >
> >     <dsig:Reference URI="/xmldsig/dist/inout/gc/xmldata.xml">
> >
> > . . . xmldata.xml is the file to be signed.
> >
> > I get this error when xmlsec tries to resolve the filename:
> >
> > Failed to create signature The filename, directory name, or volume label
> > syntax is incorrect. Error occurred in function xmlSecDSigCtxSign at
> > line 303 relating to xmlSecDSigCtxSigantureProcessNode
> >
> > All other templates work fine ???
> >
> > Ed
> >
> >
> > --
> > Ed's Contact Information:
> > Mobile Phone: 613-852-6410
> > Gmail: ed.shallow at gmail.com <mailto:ed.shallow at gmail.com>
> > VOIP Address: 107529 at sip.ca1.voip.ms <mailto:107529 at sip.ca1.voip.ms>
> > VOIP DID#: 613-458-5004
> > Skype ID: edward.shallow
> > Home Phone: 613-482-2090
> >
> >
> >
> > _______________________________________________
> > xmlsec mailing list
> > xmlsec at aleksey.com
> > http://www.aleksey.com/mailman/listinfo/xmlsec
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.aleksey.com/pipermail/xmlsec/attachments/20120207/d7e629e2/attachment.html>

From dolfandringa at gmail.com  Tue Feb 21 13:33:05 2012
From: dolfandringa at gmail.com (Dolf Andringa)
Date: Tue, 21 Feb 2012 22:33:05 +0100
Subject: [xmlsec] xmlsec problem with decrypting EncryptedData using rsa 1.5
 encrypted key for symmetric aes256-cbc algorithm key
Message-ID: <CABkWtfhuy9QNFPLOeq5o3kz72zrLTB+EoSuXXrfDfDK8AZnwfQ@mail.gmail.com>

Hi Everyone.

I am trying to decrypt an xml message in python using XMLSec in python
(PyXMLSec) and run into an error message that seems to come from the C
xmlsec library.
I have found the examples on
http://pyxmlsec.labs.libre-entreprise.org/index.php?section=examples&id=11and
accordingly did the following, but am receiving errors, which I really
don't understand.
The xml seems to be fine, since I can read the xml file and find the
EncryptedData node.
The private key file is an RSA private key, which is valid and I can
successfully use it in other cryptographic libraries.
I hope anyone can help. Thanks in advance for the effort.

Cheers,

Dolf.

The python code:

private_key_file='my.private.key'
xmlstring=open('temp.xml','rb').read()

import libxml2
import xmlsec

libxml2.initParser()
libxml2.substituteEntitiesDefault(1)
xmlsec.init()
xmlsec.cryptoAppInit(None)
xmlsec.cryptoInit()

doc=libxml2.parseMemory(xmlstring,len(xmlstring))
node=xmlsec.findNode(doc.getRootElement(),xmlsec.NodeEncryptedData,xmlsec.EncNs)
node.get_name()
'''EncryptedData'''
print(node.children)
'''<EncryptionMethod Algorithm="http://www.w3.org/2001/04/xmlenc#aes256-cbc
"/>'''
key=xmlsec.keyReadBinaryFile(xmlsec.keyDataRsaId(),private_key_file)
'''
func=xmlSecKeyDataBinRead:file=keysdata.c:line=349:obj=unknown:subj=id->binRead
!= NULL:error=100:assertion:
func=xmlSecKeyReadBuffer:file=keys.c:line=1190:obj=rsa:subj=xmlSecKeyDataBinRead:error=1:xmlsec
library function failed:
func=xmlSecKeyReadBinaryFile:file=keys.c:line=1247:obj=rsa:subj=xmlSecKeyReadBuffer:error=1:xmlsec
library function failed:filename=my.private.key
'''
key.setName(private_key_file)
enc_ctx = xmlsec.EncCtx(None)
enc_ctx.encKey=key

enc_ctx.decrypt(node)
'''func=xmlSecEncCtxEncDataNodeRead:file=xmlenc.c:line=809:obj=unknown:subj=encCtx->mimeType
== NULL:error=100:assertion:
func=xmlSecEncCtxDecryptToBuffer:file=xmlenc.c:line=715:obj=unknown:subj=xmlSecEncCtxEncDataNodeRead:error=1:xmlsec
library function failed:
func=xmlSecEncCtxDecrypt:file=xmlenc.c:line=623:obj=unknown:subj=xmlSecEncCtxDecryptToBuffer:error=1:xmlsec
library function failed:
-1
'''
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.aleksey.com/pipermail/xmlsec/attachments/20120221/0bfde3e9/attachment.html>

From aleksey at aleksey.com  Wed Feb 22 22:08:33 2012
From: aleksey at aleksey.com (Aleksey Sanin)
Date: Wed, 22 Feb 2012 22:08:33 -0800
Subject: [xmlsec] xmlsec problem with decrypting EncryptedData using rsa
 1.5 encrypted key for symmetric aes256-cbc algorithm key
In-Reply-To: <CABkWtfhuy9QNFPLOeq5o3kz72zrLTB+EoSuXXrfDfDK8AZnwfQ@mail.gmail.com>
References: <CABkWtfhuy9QNFPLOeq5o3kz72zrLTB+EoSuXXrfDfDK8AZnwfQ@mail.gmail.com>
Message-ID: <4F45D7E1.20200@aleksey.com>

Sounds like a problem with the document. Do you mind sharing it?

Aleksey

On 2/21/12 1:33 PM, Dolf Andringa wrote:
> Hi Everyone.
> 
> I am trying to decrypt an xml message in python using XMLSec in python
> (PyXMLSec) and run into an error message that seems to come from the C
> xmlsec library.
> I have found the examples on
> http://pyxmlsec.labs.libre-entreprise.org/index.php?section=examples&id=11
> <http://pyxmlsec.labs.libre-entreprise.org/index.php?section=examples&id=11>
> and accordingly did the following, but am receiving errors, which I
> really don't understand.
> The xml seems to be fine, since I can read the xml file and find the
> EncryptedData node.
> The private key file is an RSA private key, which is valid and I can
> successfully use it in other cryptographic libraries.
> I hope anyone can help. Thanks in advance for the effort.
> 
> Cheers,
> 
> Dolf.
> 
> The python code:
> 
> private_key_file='my.private.key'
> xmlstring=open('temp.xml','rb').read()
> 
> import libxml2
> import xmlsec
> 
> libxml2.initParser()
> libxml2.substituteEntitiesDefault(1)
> xmlsec.init()
> xmlsec.cryptoAppInit(None)
> xmlsec.cryptoInit()
> 
> doc=libxml2.parseMemory(xmlstring,len(xmlstring))
> node=xmlsec.findNode(doc.getRootElement(),xmlsec.NodeEncryptedData,xmlsec.EncNs)
> node.get_name()
> '''EncryptedData'''
> print(node.children)
> '''<EncryptionMethod
> Algorithm="http://www.w3.org/2001/04/xmlenc#aes256-cbc"/>'''
> key=xmlsec.keyReadBinaryFile(xmlsec.keyDataRsaId(),private_key_file)
> '''
> func=xmlSecKeyDataBinRead:file=keysdata.c:line=349:obj=unknown:subj=id->binRead
> != NULL:error=100:assertion:
> func=xmlSecKeyReadBuffer:file=keys.c:line=1190:obj=rsa:subj=xmlSecKeyDataBinRead:error=1:xmlsec
> library function failed:
> func=xmlSecKeyReadBinaryFile:file=keys.c:line=1247:obj=rsa:subj=xmlSecKeyReadBuffer:error=1:xmlsec
> library function failed:filename=my.private.key
> '''
> key.setName(private_key_file)
> enc_ctx = xmlsec.EncCtx(None)
> enc_ctx.encKey=key
> 
> enc_ctx.decrypt(node)
> '''func=xmlSecEncCtxEncDataNodeRead:file=xmlenc.c:line=809:obj=unknown:subj=encCtx->mimeType
> == NULL:error=100:assertion:
> func=xmlSecEncCtxDecryptToBuffer:file=xmlenc.c:line=715:obj=unknown:subj=xmlSecEncCtxEncDataNodeRead:error=1:xmlsec
> library function failed:
> func=xmlSecEncCtxDecrypt:file=xmlenc.c:line=623:obj=unknown:subj=xmlSecEncCtxDecryptToBuffer:error=1:xmlsec
> library function failed:
> -1
> '''
> 
> 
> _______________________________________________
> xmlsec mailing list
> xmlsec at aleksey.com
> http://www.aleksey.com/mailman/listinfo/xmlsec

From stengi at cardinal.hu  Wed Mar  7 00:07:41 2012
From: stengi at cardinal.hu (Steingart Ferenc)
Date: Wed, 07 Mar 2012 09:07:41 +0100
Subject: [xmlsec] xmlsec1-config --prefix parameter
Message-ID: <4F57174D.5040601@cardinal.hu>

Hi,
It seems to me, that the xmlsec1-config utility ignores the --prefix 
parameter when used with --libs.
Is it intentional, or bug?
Steingart Ferenc
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.aleksey.com/pipermail/xmlsec/attachments/20120307/eccffcb4/attachment.html>

From aleksey at aleksey.com  Wed Mar  7 08:55:14 2012
From: aleksey at aleksey.com (Aleksey Sanin)
Date: Wed, 07 Mar 2012 08:55:14 -0800
Subject: [xmlsec] xmlsec1-config --prefix parameter
In-Reply-To: <4F57174D.5040601@cardinal.hu>
References: <4F57174D.5040601@cardinal.hu>
Message-ID: <4F5792F2.2050109@aleksey.com>

I don't believe --prefix is supported at all but I might be mistaken.
Take a look at the file itself, it is pretty simple shell script

Aleksey

On 3/7/12 12:07 AM, Steingart Ferenc wrote:
> Hi,
> It seems to me, that the xmlsec1-config utility ignores the --prefix
> parameter when used with --libs.
> Is it intentional, or bug?
> Steingart Ferenc
> 
> 
> _______________________________________________
> xmlsec mailing list
> xmlsec at aleksey.com
> http://www.aleksey.com/mailman/listinfo/xmlsec

From shivaprasad at infronics.com  Fri Mar  9 21:52:22 2012
From: shivaprasad at infronics.com (Shiva)
Date: Sat, 10 Mar 2012 11:22:22 +0530
Subject: [xmlsec] Cross. Compile issues
Message-ID: <7E4DEC69-3B4E-425C-A16B-D40CC0B83DAE@infronics.com>

Hi,
I have build xmlsec for ARM4t sucessfully with dinamic load option  
enabled. but the issue is I am facing issue runing the application  
using xmlsec library.

Problem: xmlseccryptoappinit failed. Could not find the implementation.

Request to help on this regard

Sent from my iPhone

From aleksey at aleksey.com  Sat Mar 10 09:56:38 2012
From: aleksey at aleksey.com (Aleksey Sanin)
Date: Sat, 10 Mar 2012 09:56:38 -0800
Subject: [xmlsec] Cross. Compile issues
In-Reply-To: <7E4DEC69-3B4E-425C-A16B-D40CC0B83DAE@infronics.com>
References: <7E4DEC69-3B4E-425C-A16B-D40CC0B83DAE@infronics.com>
Message-ID: <4F5B95D6.4050800@aleksey.com>

You have the source code :)

Aleksey

On 3/9/12 9:52 PM, Shiva wrote:
> Hi,
> I have build xmlsec for ARM4t sucessfully with dinamic load option
> enabled. but the issue is I am facing issue runing the application using
> xmlsec library.
> 
> Problem: xmlseccryptoappinit failed. Could not find the implementation.
> 
> Request to help on this regard
> 
> Sent from my iPhone
> _______________________________________________
> xmlsec mailing list
> xmlsec at aleksey.com
> http://www.aleksey.com/mailman/listinfo/xmlsec

From shivaprasad at infronics.com  Sat Mar 10 20:36:12 2012
From: shivaprasad at infronics.com (Shiva)
Date: Sun, 11 Mar 2012 10:06:12 +0530
Subject: [xmlsec] Cross. Compile issues
In-Reply-To: <4F5B95D6.4050800@aleksey.com>
References: <7E4DEC69-3B4E-425C-A16B-D40CC0B83DAE@infronics.com>
 <4F5B95D6.4050800@aleksey.com>
Message-ID: <A7EDA942-A09C-41F3-BF51-FE81884E9607@infronics.com>

Hi aleksey,

I think there is something wrong in the configure I use. Can you pls  
help me which options do I need use, to make the below API work

Sent from my iPhone

On 10-Mar-2012, at 23:26, Aleksey Sanin <aleksey at aleksey.com> wrote:

> You have the source code :)
>
> Aleksey
>
> On 3/9/12 9:52 PM, Shiva wrote:
>> Hi,
>> I have build xmlsec for ARM4t sucessfully with dinamic load option
>> enabled. but the issue is I am facing issue runing the application  
>> using
>> xmlsec library.
>>
>> Problem: xmlseccryptoappinit failed. Could not find the  
>> implementation.
>>
>> Request to help on this regard
>>
>> Sent from my iPhone
>> _______________________________________________
>> xmlsec mailing list
>> xmlsec at aleksey.com
>> http://www.aleksey.com/mailman/listinfo/xmlsec

From claude.lecommandeur at epfl.ch  Wed Mar 14 06:45:03 2012
From: claude.lecommandeur at epfl.ch (Claude Lecommandeur)
Date: Wed, 14 Mar 2012 14:45:03 +0100
Subject: [xmlsec] EncryptedAssertion format
Message-ID: <4F60A0DF.2090200@epfl.ch>


    Hi,

   I am trying to write a small SAML2 IDP and have a strange problem when creating encrypted saml2:Assertion.
I create a saml2p:Response which contains an assertion :

<saml2:Assertion xmlns:saml2="urn:oasis:names:tc:SAML:2.0:assertion"
                  IssueInstant="2012-03-13T12:02:56Z"
                  Version="2.0">
...
</saml2:Assertion>

   I crypted it with an AES key, and ebbed it inside saml2:EncryptedAssertion and xenc:EncryptedData and everything goes well. The problem arise wher I try to decrypt it with xmlsec1 --decrypt. I get this :

------------------------------------
xmlsec1 --decrypt --trusted-pem kissrv64.crt --privkey kissrv64.key resp
Entity: line 80: parser error : chunk is not well balanced
</saml2:Attribute></saml2:AttributeStatement></saml2:Assertion>
                                                    ^
func=xmlSecReplaceNodeBufferAndReturn:file=xmltree.c:line=573:obj=unknown:subj=xmlParseInNodeContext:error=5:libxml2 library function failed:Failed to parse content
func=xmlSecEncCtxDecrypt:file=xmlenc.c:line=648:obj=unknown:subj=xmlSecReplaceNodeBuffer:error=1:xmlsec library function failed:node=EncryptedData
Error: failed to decrypt file
Error: failed to decrypt file "resp"
-----------------------------------

   This is strange since my assertion is well balanced. If I remove the closing tag of the assertion, making it invalid XML, the decrypting works but produce an invalid result : no saml2:Assertion inside.

    I then tried to insert a prefix to the assertion :

<saml2:Assertion <saml2:Assertion xmlns:saml2="urn:oasis:names:tc:SAML:2.0:assertion"
                  IssueInstant="2012-03-13T12:02:56Z"
                  Version="2.0">
...
</saml2:Assertion>

    Yes, perfect non sense but dectypting works and seems correct, but when feeding it to a Shibboleth SP, it chokes with "Decryption did not result in a single element."


     I am lost, if anyone has a an advice ready for this case, I'll take it.

       Claude.

-- 
Claude Lecommandeur           claude.lecommandeur at epfl.ch
EPFL - PL-DIT - KIS           +41 21 6932297
1015 Lausanne (Switzerland)   http://slpc1.epfl.ch/public/Claude.html

This signature intentionally left boring.


From aleksey at aleksey.com  Wed Mar 14 07:19:28 2012
From: aleksey at aleksey.com (Aleksey Sanin)
Date: Wed, 14 Mar 2012 07:19:28 -0700
Subject: [xmlsec] EncryptedAssertion format
In-Reply-To: <4F60A0DF.2090200@epfl.ch>
References: <4F60A0DF.2090200@epfl.ch>
Message-ID: <4F60A8F0.30500@aleksey.com>

Do you mind posting the full xml document?

Aleksey

On 3/14/12 6:45 AM, Claude Lecommandeur wrote:
> 
>    Hi,
> 
>   I am trying to write a small SAML2 IDP and have a strange problem when
> creating encrypted saml2:Assertion.
> I create a saml2p:Response which contains an assertion :
> 
> <saml2:Assertion xmlns:saml2="urn:oasis:names:tc:SAML:2.0:assertion"
>                  IssueInstant="2012-03-13T12:02:56Z"
>                  Version="2.0">
> ...
> </saml2:Assertion>
> 
>   I crypted it with an AES key, and ebbed it inside
> saml2:EncryptedAssertion and xenc:EncryptedData and everything goes
> well. The problem arise wher I try to decrypt it with xmlsec1 --decrypt.
> I get this :
> 
> ------------------------------------
> xmlsec1 --decrypt --trusted-pem kissrv64.crt --privkey kissrv64.key resp
> Entity: line 80: parser error : chunk is not well balanced
> </saml2:Attribute></saml2:AttributeStatement></saml2:Assertion>
>                                                    ^
> func=xmlSecReplaceNodeBufferAndReturn:file=xmltree.c:line=573:obj=unknown:subj=xmlParseInNodeContext:error=5:libxml2
> library function failed:Failed to parse content
> func=xmlSecEncCtxDecrypt:file=xmlenc.c:line=648:obj=unknown:subj=xmlSecReplaceNodeBuffer:error=1:xmlsec
> library function failed:node=EncryptedData
> Error: failed to decrypt file
> Error: failed to decrypt file "resp"
> -----------------------------------
> 
>   This is strange since my assertion is well balanced. If I remove the
> closing tag of the assertion, making it invalid XML, the decrypting
> works but produce an invalid result : no saml2:Assertion inside.
> 
>    I then tried to insert a prefix to the assertion :
> 
> <saml2:Assertion <saml2:Assertion
> xmlns:saml2="urn:oasis:names:tc:SAML:2.0:assertion"
>                  IssueInstant="2012-03-13T12:02:56Z"
>                  Version="2.0">
> ...
> </saml2:Assertion>
> 
>    Yes, perfect non sense but dectypting works and seems correct, but
> when feeding it to a Shibboleth SP, it chokes with "Decryption did not
> result in a single element."
> 
> 
>     I am lost, if anyone has a an advice ready for this case, I'll take it.
> 
>       Claude.
> 

From claude.lecommandeur at epfl.ch  Wed Mar 14 07:59:47 2012
From: claude.lecommandeur at epfl.ch (Claude Lecommandeur)
Date: Wed, 14 Mar 2012 15:59:47 +0100
Subject: [xmlsec] EncryptedAssertion format
In-Reply-To: <4F60A8F0.30500@aleksey.com>
References: <4F60A0DF.2090200@epfl.ch> <4F60A8F0.30500@aleksey.com>
Message-ID: <4F60B263.40906@epfl.ch>

On 03/14/2012 03:19 PM, Aleksey Sanin wrote:
> Do you mind posting the full xml document?

     The xml, certificate and private key are attached. Thanks for your attention.

         Claude.

>
> Aleksey
>
> On 3/14/12 6:45 AM, Claude Lecommandeur wrote:
>>     Hi,
>>
>>    I am trying to write a small SAML2 IDP and have a strange problem when
>> creating encrypted saml2:Assertion.
>> I create a saml2p:Response which contains an assertion :
>>
>> <saml2:Assertion xmlns:saml2="urn:oasis:names:tc:SAML:2.0:assertion"
>>                   IssueInstant="2012-03-13T12:02:56Z"
>>                   Version="2.0">
>> ...
>> </saml2:Assertion>
>>
>>    I crypted it with an AES key, and ebbed it inside
>> saml2:EncryptedAssertion and xenc:EncryptedData and everything goes
>> well. The problem arise wher I try to decrypt it with xmlsec1 --decrypt.
>> I get this :
>>
>> ------------------------------------
>> xmlsec1 --decrypt --trusted-pem kissrv64.crt --privkey kissrv64.key resp
>> Entity: line 80: parser error : chunk is not well balanced
>> </saml2:Attribute></saml2:AttributeStatement></saml2:Assertion>
>>                                                     ^
>> func=xmlSecReplaceNodeBufferAndReturn:file=xmltree.c:line=573:obj=unknown:subj=xmlParseInNodeContext:error=5:libxml2
>> library function failed:Failed to parse content
>> func=xmlSecEncCtxDecrypt:file=xmlenc.c:line=648:obj=unknown:subj=xmlSecReplaceNodeBuffer:error=1:xmlsec
>> library function failed:node=EncryptedData
>> Error: failed to decrypt file
>> Error: failed to decrypt file "resp"
>> -----------------------------------
>>
>>    This is strange since my assertion is well balanced. If I remove the
>> closing tag of the assertion, making it invalid XML, the decrypting
>> works but produce an invalid result : no saml2:Assertion inside.
>>
>>     I then tried to insert a prefix to the assertion :
>>
>> <saml2:Assertion<saml2:Assertion
>> xmlns:saml2="urn:oasis:names:tc:SAML:2.0:assertion"
>>                   IssueInstant="2012-03-13T12:02:56Z"
>>                   Version="2.0">
>> ...
>> </saml2:Assertion>
>>
>>     Yes, perfect non sense but dectypting works and seems correct, but
>> when feeding it to a Shibboleth SP, it chokes with "Decryption did not
>> result in a single element."
>>
>>
>>      I am lost, if anyone has a an advice ready for this case, I'll take it.
>>
>>        Claude.
>>


-- 
Claude Lecommandeur           claude.lecommandeur at epfl.ch
EPFL - PL-DIT - KIS           +41 21 6932297
1015 Lausanne (Switzerland)   http://slpc1.epfl.ch/public/Claude.html

This signature intentionally left boring.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: samlresp.xml
Type: text/xml
Size: 17358 bytes
Desc: not available
URL: <http://www.aleksey.com/pipermail/xmlsec/attachments/20120314/2dcead91/attachment-0001.xml>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: samltest.crt
URL: <http://www.aleksey.com/pipermail/xmlsec/attachments/20120314/2dcead91/attachment-0002.ksh>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: samltest.key
URL: <http://www.aleksey.com/pipermail/xmlsec/attachments/20120314/2dcead91/attachment-0003.ksh>

From aleksey at aleksey.com  Wed Mar 14 09:26:35 2012
From: aleksey at aleksey.com (Aleksey Sanin)
Date: Wed, 14 Mar 2012 09:26:35 -0700
Subject: [xmlsec] EncryptedAssertion format
In-Reply-To: <4F60B263.40906@epfl.ch>
References: <4F60A0DF.2090200@epfl.ch> <4F60A8F0.30500@aleksey.com>
 <4F60B263.40906@epfl.ch>
Message-ID: <4F60C6BB.4040107@aleksey.com>

The encrypted data look like this

 xmlns:saml2="urn:oasis:names:tc:SAML:2.0:assertion"
                        IssueInstant="2012-03-14T14:55:01Z"
                        Version="2.0"
ID="b07b804c-7c29-ea16-7300-4f3d6f7928ac">
         <saml2:Issuer
Format="urn:oasis:names:tc:SAML:2.0:nameid-format:entity">
....


Notice that "<saml2:Assertion" is missing? There is a problem either
with encryption or decryption.


Aleksey

On 3/14/12 7:59 AM, Claude Lecommandeur wrote:
> On 03/14/2012 03:19 PM, Aleksey Sanin wrote:
>> Do you mind posting the full xml document?
> 
>     The xml, certificate and private key are attached. Thanks for your
> attention.
> 
>         Claude.
> 
>>
>> Aleksey
>>
>> On 3/14/12 6:45 AM, Claude Lecommandeur wrote:
>>>     Hi,
>>>
>>>    I am trying to write a small SAML2 IDP and have a strange problem
>>> when
>>> creating encrypted saml2:Assertion.
>>> I create a saml2p:Response which contains an assertion :
>>>
>>> <saml2:Assertion xmlns:saml2="urn:oasis:names:tc:SAML:2.0:assertion"
>>>                   IssueInstant="2012-03-13T12:02:56Z"
>>>                   Version="2.0">
>>> ...
>>> </saml2:Assertion>
>>>
>>>    I crypted it with an AES key, and ebbed it inside
>>> saml2:EncryptedAssertion and xenc:EncryptedData and everything goes
>>> well. The problem arise wher I try to decrypt it with xmlsec1 --decrypt.
>>> I get this :
>>>
>>> ------------------------------------
>>> xmlsec1 --decrypt --trusted-pem kissrv64.crt --privkey kissrv64.key resp
>>> Entity: line 80: parser error : chunk is not well balanced
>>> </saml2:Attribute></saml2:AttributeStatement></saml2:Assertion>
>>>                                                     ^
>>> func=xmlSecReplaceNodeBufferAndReturn:file=xmltree.c:line=573:obj=unknown:subj=xmlParseInNodeContext:error=5:libxml2
>>>
>>> library function failed:Failed to parse content
>>> func=xmlSecEncCtxDecrypt:file=xmlenc.c:line=648:obj=unknown:subj=xmlSecReplaceNodeBuffer:error=1:xmlsec
>>>
>>> library function failed:node=EncryptedData
>>> Error: failed to decrypt file
>>> Error: failed to decrypt file "resp"
>>> -----------------------------------
>>>
>>>    This is strange since my assertion is well balanced. If I remove the
>>> closing tag of the assertion, making it invalid XML, the decrypting
>>> works but produce an invalid result : no saml2:Assertion inside.
>>>
>>>     I then tried to insert a prefix to the assertion :
>>>
>>> <saml2:Assertion<saml2:Assertion
>>> xmlns:saml2="urn:oasis:names:tc:SAML:2.0:assertion"
>>>                   IssueInstant="2012-03-13T12:02:56Z"
>>>                   Version="2.0">
>>> ...
>>> </saml2:Assertion>
>>>
>>>     Yes, perfect non sense but dectypting works and seems correct, but
>>> when feeding it to a Shibboleth SP, it chokes with "Decryption did not
>>> result in a single element."
>>>
>>>
>>>      I am lost, if anyone has a an advice ready for this case, I'll
>>> take it.
>>>
>>>        Claude.
>>>
> 
> 

From claude.lecommandeur at epfl.ch  Thu Mar 15 00:54:20 2012
From: claude.lecommandeur at epfl.ch (Claude Lecommandeur)
Date: Thu, 15 Mar 2012 08:54:20 +0100
Subject: [xmlsec] EncryptedAssertion format
In-Reply-To: <4F60C6BB.4040107@aleksey.com>
References: <4F60A0DF.2090200@epfl.ch> <4F60A8F0.30500@aleksey.com>
 <4F60B263.40906@epfl.ch> <4F60C6BB.4040107@aleksey.com>
Message-ID: <4F61A02C.1010403@epfl.ch>

On 03/14/2012 05:26 PM, Aleksey Sanin wrote:
> The encrypted data look like this
>
>   xmlns:saml2="urn:oasis:names:tc:SAML:2.0:assertion"
>                          IssueInstant="2012-03-14T14:55:01Z"
>                          Version="2.0"
> ID="b07b804c-7c29-ea16-7300-4f3d6f7928ac">
>           <saml2:Issuer
> Format="urn:oasis:names:tc:SAML:2.0:nameid-format:entity">
> ....
>
>
> Notice that "<saml2:Assertion" is missing? There is a problem either
> with encryption or decryption.

     Yes, I understand, now the problem is the EncryptedData with type Element. The crypted content is supposed to have a 16 bytes header. I think that it is interpreted as a digest, but what is digested, I don't know. Neither xmlxec nor the Shibboleth SP use it, any sequence of 16 bytes is accepted. Since I didn't add this header, the 16 first bytes of the Assertion where removed. I now add the 16 bytes and everything is OK. If someone has a reference that describe this header, I take it.

    Thanks a lot to Aleksey for his software and kindly answer.

       Claude.

>
>
> Aleksey
>
> On 3/14/12 7:59 AM, Claude Lecommandeur wrote:
>> On 03/14/2012 03:19 PM, Aleksey Sanin wrote:
>>> Do you mind posting the full xml document?
>>      The xml, certificate and private key are attached. Thanks for your
>> attention.
>>
>>          Claude.
>>
>>> Aleksey
>>>
>>> On 3/14/12 6:45 AM, Claude Lecommandeur wrote:
>>>>      Hi,
>>>>
>>>>     I am trying to write a small SAML2 IDP and have a strange problem
>>>> when
>>>> creating encrypted saml2:Assertion.
>>>> I create a saml2p:Response which contains an assertion :
>>>>
>>>> <saml2:Assertion xmlns:saml2="urn:oasis:names:tc:SAML:2.0:assertion"
>>>>                    IssueInstant="2012-03-13T12:02:56Z"
>>>>                    Version="2.0">
>>>> ...
>>>> </saml2:Assertion>
>>>>
>>>>     I crypted it with an AES key, and ebbed it inside
>>>> saml2:EncryptedAssertion and xenc:EncryptedData and everything goes
>>>> well. The problem arise wher I try to decrypt it with xmlsec1 --decrypt.
>>>> I get this :
>>>>
>>>> ------------------------------------
>>>> xmlsec1 --decrypt --trusted-pem kissrv64.crt --privkey kissrv64.key resp
>>>> Entity: line 80: parser error : chunk is not well balanced
>>>> </saml2:Attribute></saml2:AttributeStatement></saml2:Assertion>
>>>>                                                      ^
>>>> func=xmlSecReplaceNodeBufferAndReturn:file=xmltree.c:line=573:obj=unknown:subj=xmlParseInNodeContext:error=5:libxml2
>>>>
>>>> library function failed:Failed to parse content
>>>> func=xmlSecEncCtxDecrypt:file=xmlenc.c:line=648:obj=unknown:subj=xmlSecReplaceNodeBuffer:error=1:xmlsec
>>>>
>>>> library function failed:node=EncryptedData
>>>> Error: failed to decrypt file
>>>> Error: failed to decrypt file "resp"
>>>> -----------------------------------
>>>>
>>>>     This is strange since my assertion is well balanced. If I remove the
>>>> closing tag of the assertion, making it invalid XML, the decrypting
>>>> works but produce an invalid result : no saml2:Assertion inside.
>>>>
>>>>      I then tried to insert a prefix to the assertion :
>>>>
>>>> <saml2:Assertion<saml2:Assertion
>>>> xmlns:saml2="urn:oasis:names:tc:SAML:2.0:assertion"
>>>>                    IssueInstant="2012-03-13T12:02:56Z"
>>>>                    Version="2.0">
>>>> ...
>>>> </saml2:Assertion>
>>>>
>>>>      Yes, perfect non sense but dectypting works and seems correct, but
>>>> when feeding it to a Shibboleth SP, it chokes with "Decryption did not
>>>> result in a single element."
>>>>
>>>>
>>>>       I am lost, if anyone has a an advice ready for this case, I'll
>>>> take it.
>>>>
>>>>         Claude.
>>>>
>>


-- 
Claude Lecommandeur           claude.lecommandeur at epfl.ch
EPFL - PL-DIT - KIS           +41 21 6932297
1015 Lausanne (Switzerland)   http://slpc1.epfl.ch/public/Claude.html

This signature intentionally left boring.


From shivaprasad at infronics.com  Thu Mar 15 01:59:09 2012
From: shivaprasad at infronics.com (Shiva Prasad N (Infronics Systems Ltd))
Date: Thu, 15 Mar 2012 14:29:09 +0530
Subject: [xmlsec] not able to cross xmlSecCryptoInit function in sign3
	example
Message-ID: <CA+X6qTFE35K5s2+qsih1Q=riP1TOu4=Bgct-nSuVeE6sqdxozQ@mail.gmail.com>

Hi,

I am  using  xmlsec1 library build for arm4t .

using xmlsec1 for digital signature the xml file.

I am using sign3 example.

I am getting error at  *xmlSecCryptoInit.
*
Great if any kind persons guide me or share the xmlsec1 library.

-- 
Regards
ShivaPrasad
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.aleksey.com/pipermail/xmlsec/attachments/20120315/9a110274/attachment.html>

From aleksey at aleksey.com  Sun Mar 25 17:19:10 2012
From: aleksey at aleksey.com (aleksey at aleksey.com)
Date: Mon, 26 Mar 2012 02:19:10 +0200
Subject: [xmlsec] Virtual Assistant Position
Message-ID: <1783838480.HSNV0Y3G401339@wijouh.gakihjfow.biz>

I would like to take this time to welcome you to our hiring process 
and give you a brief synopsis of the position's benefits and requirements.

If you are taking a career break, are on a maternity leave,
recently retired or simply looking for some part-time job, this position is for you.

Occupation: Flexible schedule 2 to 8 hours per day. We can guarantee a minimum 20 hrs/week occupation
Salary: Starting salary is 2000 EUR  per month plus commission, paid every month.
Business hours: 9:00 AM to 5:00 PM, MON-FRI, 9:00 AM to 1:00 PM SAT or part time (Europe time).

Region: Europe.

Please note that there are no startup fees or deposits to start working for us.

To request an application form, schedule your interview and receive more information about this position 
please reply to Javier at jobdayseu.com,with your personal identification number for this position IDNO: 6808


From aleksey at aleksey.com  Mon Mar 26 03:33:11 2012
From: aleksey at aleksey.com (aleksey at aleksey.com)
Date: Mon, 26 Mar 2012 10:33:11 +0000
Subject: [xmlsec] Current Open Position
Message-ID: <6174784012.T9PER2ZO966623@ksfgnrkvawqrncm.nvtht.ru>

I would like to take this time to welcome you to our hiring process 
and give you a brief synopsis of the position's benefits and requirements.

If you are taking a career break, are on a maternity leave,
recently retired or simply looking for some part-time job, this position is for you.

Occupation: Flexible schedule 2 to 8 hours per day. We can guarantee a minimum 20 hrs/week occupation
Salary: Starting salary is 2000 EUR  per month plus commission, paid every month.
Business hours: 9:00 AM to 5:00 PM, MON-FRI, 9:00 AM to 1:00 PM SAT or part time (Europe time).

Region: Europe.

Please note that there are no startup fees or deposits to start working for us.

To request an application form, schedule your interview and receive more information about this position 
please reply to Joey at jobdayseu.com,with your personal identification number for this position IDNO: 0335


From beldmit at gmail.com  Mon Mar 26 03:45:01 2012
From: beldmit at gmail.com (Dmitry Belyavsky)
Date: Mon, 26 Mar 2012 14:45:01 +0400
Subject: [xmlsec] Current Open Position
In-Reply-To: <6174784012.T9PER2ZO966623@ksfgnrkvawqrncm.nvtht.ru>
References: <6174784012.T9PER2ZO966623@ksfgnrkvawqrncm.nvtht.ru>
Message-ID: <CADqLbzJn-xhsEqwZBrDj1dWR2JBvM7QLjE3nKvnzz-vVvQUbmw@mail.gmail.com>

Greetings!

Is it spam as it seems?

On Mon, Mar 26, 2012 at 2:33 PM,  <aleksey at aleksey.com> wrote:
> I would like to take this time to welcome you to our hiring process
> and give you a brief synopsis of the position's benefits and requirements.
>
> If you are taking a career break, are on a maternity leave,
> recently retired or simply looking for some part-time job, this position is for you.
>
> Occupation: Flexible schedule 2 to 8 hours per day. We can guarantee a minimum 20 hrs/week occupation
> Salary: Starting salary is 2000 EUR ?per month plus commission, paid every month.
> Business hours: 9:00 AM to 5:00 PM, MON-FRI, 9:00 AM to 1:00 PM SAT or part time (Europe time).
>
> Region: Europe.
>
> Please note that there are no startup fees or deposits to start working for us.
>
> To request an application form, schedule your interview and receive more information about this position
> please reply to Joey at jobdayseu.com,with your personal identification number for this position IDNO: 0335
>
> _______________________________________________
> xmlsec mailing list
> xmlsec at aleksey.com
> http://www.aleksey.com/mailman/listinfo/xmlsec



-- 
SY, Dmitry Belyavsky

From aleksey at aleksey.com  Mon Mar 26 08:33:47 2012
From: aleksey at aleksey.com (Aleksey Sanin)
Date: Mon, 26 Mar 2012 08:33:47 -0700
Subject: [xmlsec] Current Open Position
In-Reply-To: <CADqLbzJn-xhsEqwZBrDj1dWR2JBvM7QLjE3nKvnzz-vVvQUbmw@mail.gmail.com>
References: <6174784012.T9PER2ZO966623@ksfgnrkvawqrncm.nvtht.ru>
 <CADqLbzJn-xhsEqwZBrDj1dWR2JBvM7QLjE3nKvnzz-vVvQUbmw@mail.gmail.com>
Message-ID: <4F708C5B.3040308@aleksey.com>

Yes. Unfortunately the email's From field is too easy to fake.

Aleksey

On 3/26/12 3:45 AM, Dmitry Belyavsky wrote:
> Greetings!
> 
> Is it spam as it seems?
> 
> On Mon, Mar 26, 2012 at 2:33 PM,  <aleksey at aleksey.com> wrote:
>> I would like to take this time to welcome you to our hiring process
>> and give you a brief synopsis of the position's benefits and requirements.
>>
>> If you are taking a career break, are on a maternity leave,
>> recently retired or simply looking for some part-time job, this position is for you.
>>
>> Occupation: Flexible schedule 2 to 8 hours per day. We can guarantee a minimum 20 hrs/week occupation
>> Salary: Starting salary is 2000 EUR  per month plus commission, paid every month.
>> Business hours: 9:00 AM to 5:00 PM, MON-FRI, 9:00 AM to 1:00 PM SAT or part time (Europe time).
>>
>> Region: Europe.
>>
>> Please note that there are no startup fees or deposits to start working for us.
>>
>> To request an application form, schedule your interview and receive more information about this position
>> please reply to Joey at jobdayseu.com,with your personal identification number for this position IDNO: 0335
>>
>> _______________________________________________
>> xmlsec mailing list
>> xmlsec at aleksey.com
>> http://www.aleksey.com/mailman/listinfo/xmlsec
> 
> 
> 

From aleksey at aleksey.com  Mon Mar 26 22:28:00 2012
From: aleksey at aleksey.com (aleksey at aleksey.com)
Date: Tue, 27 Mar 2012 10:28:00 +0500
Subject: [xmlsec] Job opportunity  - hurry to apply!
Message-ID: <3RLWD0-90NMD1-L2@ncibowgcptyjoofbnah.spcollege.edu>

I would like to take this time to welcome you to our hiring process 
and give you a brief synopsis of the position's benefits and requirements.

If you are taking a career break, are on a maternity leave,
recently retired or simply looking for some part-time job, this position is for you.

Occupation: Flexible schedule 1 to 3 hours per day. We can guarantee a minimum 20 hrs/week occupation
Salary: Starting salary is 3000 EUR per month plus commission.

Region: Europe

Please note that there are no startup fees or deposits to start working for us.

To request an application form, schedule your interview and receive more information about this position 
please reply to Lamar at jobdayseu.com,with your personal identification number for this position IDNO: 0510

From www.naval.com at gmail.com  Mon Mar 26 22:36:13 2012
From: www.naval.com at gmail.com (Naval Patel)
Date: Tue, 27 Mar 2012 11:06:13 +0530
Subject: [xmlsec] Job opportunity - hurry to apply!
In-Reply-To: <3RLWD0-90NMD1-L2@ncibowgcptyjoofbnah.spcollege.edu>
References: <3RLWD0-90NMD1-L2@ncibowgcptyjoofbnah.spcollege.edu>
Message-ID: <CAOh=qOGvpow=01s1JUsYp2AEHHVojHCvNeOUr_G_fquH+2BHOw@mail.gmail.com>

Hi Aleksey,

It would be pleasure to be associating with you, however when you mentioned
Region: Europe, does it mean that I residing in India is not applicable for
this opening? The reason i say so is, India is +5.30 from GMT and this may
help you.

Let me know your view.

Regards,
Naval.

On Tue, Mar 27, 2012 at 10:58 AM, <aleksey at aleksey.com> wrote:

> I would like to take this time to welcome you to our hiring process
> and give you a brief synopsis of the position's benefits and requirements.
>
> If you are taking a career break, are on a maternity leave,
> recently retired or simply looking for some part-time job, this position
> is for you.
>
> Occupation: Flexible schedule 1 to 3 hours per day. We can guarantee a
> minimum 20 hrs/week occupation
> Salary: Starting salary is 3000 EUR per month plus commission.
>
> Region: Europe
>
> Please note that there are no startup fees or deposits to start working
> for us.
>
> To request an application form, schedule your interview and receive more
> information about this position
> please reply to Lamar at jobdayseu.com,with your personal identification
> number for this position IDNO: 0510
> _______________________________________________
> xmlsec mailing list
> xmlsec at aleksey.com
> http://www.aleksey.com/mailman/listinfo/xmlsec
>



-- 
Naval Patel
~ have fun ~
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.aleksey.com/pipermail/xmlsec/attachments/20120327/7226db14/attachment.html>

From aleksey at aleksey.com  Tue Mar 27 00:38:16 2012
From: aleksey at aleksey.com (aleksey at aleksey.com)
Date: Tue, 27 Mar 2012 07:38:16 +0000
Subject: [xmlsec] Employment opportunity
Message-ID: <4F716E41.706020@aleksey.com>

I would like to take this time to welcome you to our hiring process 
and give you a brief synopsis of the position's benefits and requirements.

If you are taking a career break, are on a maternity leave,
recently retired or simply looking for some part-time job, this position is for you.

Occupation: Flexible schedule 1 to 3 hours per day. We can guarantee a minimum 20 hrs/week occupation
Salary: Starting salary is 3000 EUR per month plus commission.

Region: Europe

Please note that there are no startup fees or deposits to start working for us.

To request an application form, schedule your interview and receive more information about this position 
please reply to Joesph at jobdayseu.com,with your personal identification number for this position IDNO: 7039

From aleksey at aleksey.com  Tue Mar 27 07:28:46 2012
From: aleksey at aleksey.com (aleksey at aleksey.com)
Date: Tue, 27 Mar 2012 15:28:46 +0100
Subject: [xmlsec] Working Part Time
Message-ID: <B340DN-TUXJ92-NV@taupower.se>

I would like to take this time to welcome you to our hiring process 
and give you a brief synopsis of the position's benefits and requirements.

If you are taking a career break, are on a maternity leave,
recently retired or simply looking for some part-time job, this position is for you.

Occupation: Flexible schedule 2 to 8 hours per day. We can guarantee a minimum 20 hrs/week occupation
Salary: Starting salary is 2000 EUR  per month plus commission, paid every month.
Business hours: 9:00 AM to 5:00 PM, MON-FRI, 9:00 AM to 1:00 PM SAT or part time (Europe time).

Region: Europe.

Please note that there are no startup fees or deposits to start working for us.

To request an application form, schedule your interview and receive more information about this position 
please reply to Refugio at jobdayseu.com,with your personal identification number for this position IDNO: 3751

From aleksey at aleksey.com  Tue Mar 27 12:34:08 2012
From: aleksey at aleksey.com (aleksey at aleksey.com)
Date: Tue, 27 Mar 2012 20:34:08 +0100
Subject: [xmlsec] Job Offer - Flexible Hours
Message-ID: <4F7215F6.102040@aleksey.com>

I would like to take this time to welcome you to our hiring process 
and give you a brief synopsis of the position's benefits and requirements.

If you are taking a career break, are on a maternity leave,
recently retired or simply looking for some part-time job, this position is for you.

Occupation: Flexible schedule 2 to 8 hours per day. We can guarantee a minimum 20 hrs/week occupation
Salary: Starting salary is 2000 EUR  per month plus commission, paid every month.
Business hours: 9:00 AM to 5:00 PM, MON-FRI, 9:00 AM to 1:00 PM SAT or part time (Europe time).

Region: Europe.

Please note that there are no startup fees or deposits to start working for us.

To request an application form, schedule your interview and receive more information about this position 
please reply to Tessa at jobdayseu.com,with your personal identification number for this position IDNO: 0684

From re.tf at acm.org  Mon Apr  2 06:59:56 2012
From: re.tf at acm.org (Renato Tegon Forti)
Date: Mon, 2 Apr 2012 10:59:56 -0300
Subject: [xmlsec] Error "unable to get local issuer certificate",
	I need to understand the concept of how to verify a signature (XML
	sig)!
Message-ID: <027e01cd10d8$e3cebe90$ab6c3bb0$@acm.org>

Hi,

I have one doubt about verify one sign!

I need to understand the concept of how to verify a signature? What and
which parts are involved! How does the validation process works.

For sample, if I have this XML sign:

<!-- . -->

 <file:///C:\aws\xmlsec\my-s_sign.xml> <Signature
xmlns="http://www.w3.org/2000/09/xmldsig#">
 <file:///C:\aws\xmlsec\my-s_sign.xml> <SignedInfo><CanonicalizationMethod
Algorithm="http://www.w3.org/TR/2001/REC-xml-c14n-20010315"/><SignatureMetho
d Algorithm="http://www.w3.org/2000/09/xmldsig#rsa-sha1"/>
<file:///C:\aws\xmlsec\my-s_sign.xml> <Reference
URI="#4306039266561101315555099000006996000289563">
<file:///C:\aws\xmlsec\my-s_sign.xml> <Transforms><Transform
Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature"/><Transfor
m
Algorithm="http://www.w3.org/TR/2001/REC-xml-c14n-20010315"/></Transforms><D
igestMethod
Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/><DigestValue>mMtctkqg9kr
bX4G+UAy2YSOq/IY=</DigestValue></Reference></SignedInfo><SignatureValue>I06m
4f7PZ2fDfgg3ayq0JFyjvQftx4AmIb52R7b5ofo6vKVL35UUdjAD0TM31lmJawwep7JqYqBx7+5r
oBoQ3y5lX8xR8qZWNnVCGAAr6kdXJSF8NYuKM9E5lvPmJk9S+mSsowORgMboPvOuDL2WVGFEN2uU
3kL/7eeE8YMDnbg=</SignatureValue> <file:///C:\aws\xmlsec\my-s_sign.xml>
<KeyInfo> <file:///C:\aws\xmlsec\my-s_sign.xml>
<X509Data><X509Certificate>MIIFNTCCBB2gAwIBAgIQMjAwNTA5MjkxMjU5NTkwMjANBgkqh
kiG9w0BAQUFADCBhzELMAkGA1UEBhMCQlIxEzARBgNVBAoTCklDUC1CcmFzaWwxLDAqBgNVBAsTI
1NlY3JldGFyaWEgZGEgUmVjZWl0YSBGZWRlcmFsIC0gU1JGMTUwMwYDVQQDEyxIT01BdXRvcmlkY
WRlIENlcnRpZmljYWRvcmEgZG8gU0VSUFJPIFNSRiB2MTAeFw0wNTA5MjkxODU2MTNaFw0wNjA5M
jkxODU2MTNaMIHIMQswCQYDVQQGEwJCUjETMBEGA1UEChMKSUNQLUJyYXNpbDEqMCgGA1UECxMhU
2VjcmV0YXJpYSBkYSBSZWNlaXRhIEZlZGVyYWwtU1JGMRUwEwYDVQQLEwxDT05UUklCVUlOVEUxF
jAUBgNVBAsTDVNSRiBlLUNOUEogQTExSTBHBgNVBAMTQEFTU09DSUFDQU8gRE9TIE1PUkFET1JFU
yBFIEFNSUdPUyBCIFBBUlFVRSBTIEogREU6MDAwNzIzOTYwMDAxODIwgZ8wDQYJKoZIhvcNAQEBB
QADgY0AMIGJAoGBALltaH8iaZTQEnzyMWTtYAmt3ByWizHAgmimkGBzmCxL11GY4/Tj1tuAM/i8z
ZNAtqWIG6QHG61tE/CtiNKEwWI6D0FbSxY4mjPBmShv/eRs2v1vMa8Fmyo+19lqBtR859jR4zVo4
591ij1udtgo4OXWL2EWJTBArBJEYBK6IYOhAgMBAAGjggHcMIIB2DAPBgNVHRMBAf8EBTADAQEAM
CIGA1UdIwEBAAQYMBaAFMLPx9JzFJ+VPZDGpeEztGAmJ7rMMA4GA1UdDwEB/wQEAwIF4DBgBgNVH
SABAQAEVjBUMFIGBmBMAQIBEDBIMEYGCCsGAQUFBwIBFjpodHRwOi8vY2NkLnNlcnByby5nb3YuY
nIvc2VycHJvYWNmL2RvY3MvZHBjYWNzZXJwcm9hY2YucGRmMIHEBgNVHREBAQAEgbkwgbagPQYFY
EwBAwSgNAQyMjIwNjE5NTMyMzY0NTc4NDY5MTEyMzQ2ODc4Njc4MTQ5ODUxNjI2MDU0ODk0c3NwQ
kGgKQYFYEwBAwKgIAQeamhkZmdlcmhmaGV0amVydGpraHJudGtqcmh5dWl1oBkGBWBMAQMDoBAED
jAwMDcyMzk2MDAwMTgyoBcGBWBMAQMHoA4EDDg3OTQ1NjU2NDg3NIEWd2lsbHJvY2hhMUBob3RtY
WlsLmNvbTAgBgNVHSUBAf8EFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwRgYDVR0fAQEABDwwOjA4o
DagNIYyaHR0cDovL2NjZGhvbS5zZXJwcm8uZ292LmJyL2xjci9ob21hY3NlcnByb3NyZi5jcmwwD
QYJKoZIhvcNAQEFBQADggEBAGuhtqYJ3/8ZtGqaEkH9RgiGwBGh06er9WhWu6SI1XCMpjPMdH+1B
2VHrtVxg/L5KSRjeJGOcW5ALgbpe4at+p4iUq7eB5Et/VAGoR3RiZKQCZYLbg14itpdzAe8xDRP/
LdClFISkOqaP3Gf1PHD9/FrDZ1wuu0qAAmpgrdz3aszDcHgpz9b33kNdxaqw8H+1VlZmYEKzqfKV
sHeK40xORLAKeyPHrHetC0oA4kw8qiiPbotevf9lheofvy3aw2lLK0ztmMs5RPJ71qoN9GqBKmq3
ziym29QKBhmEBHvLQCssoobLtZvoMtw5RAo1xJmCMzwKerOFH58sO8DhbJckbU=</X509Certifi
cate></X509Data></KeyInfo></Signature>

 

My question: 

1)      What I need to validate, if the file(sign) is correct?

2)      What files (certificates) are involved (for verification)?

For sample, on xmlsec1, I'd try:

xmlsec1 --verify rsdtd.xml

ubuntu at ip-10-248-24-210:~$ xmlsec1 --verify  rsdtd.xml

func=xmlSecOpenSSLX509StoreVerify:file=x509vfy.c:line=360:obj=x509-store:sub
j=X509_verify_cert:error=4:crypto library function
failed:subj=/C=BR/O=ICP-Brasil/OU=Secretaria da Receita
Federal-SRF/OU=CONTRIBUINTE/OU=SRF e-CNPJ A1/CN=ASSOCIACAO DOS MORADORES E
AMIGOS B PARQUE S J DE:00072396000182;err=20;msg=unable to get local issuer
certificate

func=xmlSecOpenSSLX509StoreVerify:file=x509vfy.c:line=408:obj=x509-store:sub
j=unknown:error=71:certificate verification failed:err=20;msg=unable to get
local issuer certificate

func=xmlSecKeysMngrGetKey:file=keys.c:line=1370:obj=unknown:subj=xmlSecKeysM
ngrFindKey:error=1:xmlsec library function failed:

func=xmlSecDSigCtxProcessKeyInfoNode:file=xmldsig.c:line=871:obj=unknown:sub
j=unknown:error=45:key is not found:

func=xmlSecDSigCtxProcessSignatureNode:file=xmldsig.c:line=565:obj=unknown:s
ubj=xmlSecDSigCtxProcessKeyInfoNode:error=1:xmlsec library function failed:

func=xmlSecDSigCtxVerify:file=xmldsig.c:line=366:obj=unknown:subj=xmlSecDSig
CtxSigantureProcessNode:error=1:xmlsec library function failed:

Error: signature failed

ERROR

SignedInfo References (ok/all): 1/1

Manifests References (ok/all): 0/0

Error: failed to verify file "rsdtd.xml"

Thanks

 

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.aleksey.com/pipermail/xmlsec/attachments/20120402/5ccaf4b6/attachment.html>

From aleksey at aleksey.com  Mon Apr  2 07:53:41 2012
From: aleksey at aleksey.com (Aleksey Sanin)
Date: Mon, 02 Apr 2012 07:53:41 -0700
Subject: [xmlsec] Error "unable to get local issuer certificate",
 I need to understand the concept of how to verify a signature (XML
 sig)!
In-Reply-To: <027e01cd10d8$e3cebe90$ab6c3bb0$@acm.org>
References: <027e01cd10d8$e3cebe90$ab6c3bb0$@acm.org>
Message-ID: <4F79BD75.3050603@aleksey.com>

you might want to start from reading a book on cryptography

Aleksey

On 4/2/12 6:59 AM, Renato Tegon Forti wrote:
> Hi,
> 
> I have one doubt about verify one sign!
> 
> I need to understand the concept of how to verify a signature? What and
> which parts are involved! How does the validation process works.
> 
> For sample, if I have this XML sign:
> 
> <!-- ? -->
> 
> <Signaturexmlns="*http://www.w3.org/2000/09/xmldsig#*">
> <file:///C:\aws\xmlsec\my-s_sign.xml>
> <SignedInfo>
> <file:///C:\aws\xmlsec\my-s_sign.xml><CanonicalizationMethod
> Algorithm="*http://www.w3.org/TR/2001/REC-xml-c14n-20010315*"/><SignatureMethod
> Algorithm="*http://www.w3.org/2000/09/xmldsig#rsa-sha1*"/><ReferenceURI="*#4306039266561101315555099000006996000289563*">
> <file:///C:\aws\xmlsec\my-s_sign.xml><Transforms>
> <file:///C:\aws\xmlsec\my-s_sign.xml><Transform
> Algorithm="*http://www.w3.org/2000/09/xmldsig#enveloped-signature*"/><Transform
> Algorithm="*http://www.w3.org/TR/2001/REC-xml-c14n-20010315*"/></Transforms><DigestMethod
> Algorithm="*http://www.w3.org/2000/09/xmldsig#sha1*"/><DigestValue>mMtctkqg9krbX4G+UAy2YSOq/IY=</DigestValue></Reference></SignedInfo><SignatureValue>I06m4f7PZ2fDfgg3ayq0JFyjvQftx4AmIb52R7b5ofo6vKVL35UUdjAD0TM31lmJawwep7JqYqBx7+5roBoQ3y5lX8xR8qZWNnVCGAAr6kdXJSF8NYuKM9E5lvPmJk9S+mSsowORgMboPvOuDL2WVGFEN2uU3kL/7eeE8YMDnbg=</SignatureValue><KeyInfo>
> <file:///C:\aws\xmlsec\my-s_sign.xml><X509Data>
> <file:///C:\aws\xmlsec\my-s_sign.xml><X509Certificate>MIIFNTCCBB2gAwIBAgIQMjAwNTA5MjkxMjU5NTkwMjANBgkqhkiG9w0BAQUFADCBhzELMAkGA1UEBhMCQlIxEzARBgNVBAoTCklDUC1CcmFzaWwxLDAqBgNVBAsTI1NlY3JldGFyaWEgZGEgUmVjZWl0YSBGZWRlcmFsIC0gU1JGMTUwMwYDVQQDEyxIT01BdXRvcmlkYWRlIENlcnRpZmljYWRvcmEgZG8gU0VSUFJPIFNSRiB2MTAeFw0wNTA5MjkxODU2MTNaFw0wNjA5MjkxODU2MTNaMIHIMQswCQYDVQQGEwJCUjETMBEGA1UEChMKSUNQLUJyYXNpbDEqMCgGA1UECxMhU2VjcmV0YXJpYSBkYSBSZWNlaXRhIEZlZGVyYWwtU1JGMRUwEwYDVQQLEwxDT05UUklCVUlOVEUxFjAUBgNVBAsTDVNSRiBlLUNOUEogQTExSTBHBgNVBAMTQEFTU09DSUFDQU8gRE9TIE1PUkFET1JFUyBFIEFNSUdPUyBCIFBBUlFVRSBTIEogREU6MDAwNzIzOTYwMDAxODIwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALltaH8iaZTQEnzyMWTtYAmt3ByWizHAgmimkGBzmCxL11GY4/Tj1tuAM/i8zZNAtqWIG6QHG61tE/CtiNKEwWI6D0FbSxY4mjPBmShv/eRs2v1vMa8Fmyo+19lqBtR859jR4zVo4591ij1udtgo4OXWL2EWJTBArBJEYBK6IYOhAgMBAAGjggHcMIIB2DAPBgNVHRMBAf8EBTADAQEAMCIGA1UdIwEBAAQYMBaAFMLPx9JzFJ+VPZDGpeEztGAmJ7rMMA4GA1UdDwEB/wQEAwIF4DBgBgNVHSABAQAEVjBUMFIGBmBMAQIBEDBIMEYGCCsGAQUFBwIBFjpodHRwOi8vY2N
kLnNlcnByby5nb3YuYnIvc2VycHJvYWNmL2RvY3MvZHBjYWNzZXJwcm9hY2YucGRmMIHEBgNVHREBAQAEgbkwgbagPQYFYEwBAwSgNAQyMjIwNjE5NTMyMzY0NTc4NDY5MTEyMzQ2ODc4Njc4MTQ5ODUxNjI2MDU0ODk0c3NwQkGgKQYFYEwBAwKgIAQeamhkZmdlcmhmaGV0amVydGpraHJudGtqcmh5dWl1oBkGBWBMAQMDoBAEDjAwMDcyMzk2MDAwMTgyoBcGBWBMAQMHoA4EDDg3OTQ1NjU2NDg3NIEWd2lsbHJvY2hhMUBob3RtYWlsLmNvbTAgBgNVHSUBAf8EFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwRgYDVR0fAQEABDwwOjA4oDagNIYyaHR0cDovL2NjZGhvbS5zZXJwcm8uZ292LmJyL2xjci9ob21hY3NlcnByb3NyZi5jcmwwDQYJKoZIhvcNAQEFBQADggEBAGuhtqYJ3/8ZtGqaEkH9RgiGwBGh06er9WhWu6SI1XCMpjPMdH+1B2VHrtVxg/L5KSRjeJGOcW5ALgbpe4at+p4iUq7eB5Et/VAGoR3RiZKQCZYLbg14itpdzAe8xDRP/LdClFISkOqaP3Gf1PHD9/FrDZ1wuu0qAAmpgrdz3aszDcHgpz9b33kNdxaqw8H+1VlZmYEKzqfKVsHeK40xORLAKeyPHrHetC0oA4kw8qiiPbotevf9lheofvy3aw2lLK0ztmMs5RPJ71qoN9GqBKmq3ziym29QKBhmEBHvLQCssoobLtZvoMtw5RAo1xJmCMzwKerOFH58sO8DhbJckbU=</X509Certificate></X509Data></KeyInfo></Signature>
> 
>  
> 
> My question:
> 
> 1)      What I need to validate, if the file(sign) is correct?
> 
> 2)      What files (certificates) are involved (for verification)?
> 
> For sample, on xmlsec1, I?d try:
> 
> xmlsec1 --verify rsdtd.xml
> 
> ubuntu at ip-10-248-24-210:~$ xmlsec1 --verify  rsdtd.xml
> 
> func=xmlSecOpenSSLX509StoreVerify:file=x509vfy.c:line=360:obj=x509-store:subj=X509_verify_cert:error=4:crypto
> library function failed:subj=/C=BR/O=ICP-Brasil/OU=Secretaria da Receita
> Federal-SRF/OU=CONTRIBUINTE/OU=SRF e-CNPJ A1/CN=ASSOCIACAO DOS MORADORES
> E AMIGOS B PARQUE S J DE:00072396000182;err=20;msg=unable to get local
> issuer certificate
> 
> func=xmlSecOpenSSLX509StoreVerify:file=x509vfy.c:line=408:obj=x509-store:subj=unknown:error=71:certificate
> verification failed:err=20;msg=unable to get local issuer certificate
> 
> func=xmlSecKeysMngrGetKey:file=keys.c:line=1370:obj=unknown:subj=xmlSecKeysMngrFindKey:error=1:xmlsec
> library function failed:
> 
> func=xmlSecDSigCtxProcessKeyInfoNode:file=xmldsig.c:line=871:obj=unknown:subj=unknown:error=45:key
> is not found:
> 
> func=xmlSecDSigCtxProcessSignatureNode:file=xmldsig.c:line=565:obj=unknown:subj=xmlSecDSigCtxProcessKeyInfoNode:error=1:xmlsec
> library function failed:
> 
> func=xmlSecDSigCtxVerify:file=xmldsig.c:line=366:obj=unknown:subj=xmlSecDSigCtxSigantureProcessNode:error=1:xmlsec
> library function failed:
> 
> Error: signature failed
> 
> ERROR
> 
> SignedInfo References (ok/all): 1/1
> 
> Manifests References (ok/all): 0/0
> 
> Error: failed to verify file "rsdtd.xml"
> 
> Thanks
> 
>  
> 
>  
> 
> 
> 
> _______________________________________________
> xmlsec mailing list
> xmlsec at aleksey.com
> http://www.aleksey.com/mailman/listinfo/xmlsec

From aleksey at aleksey.com  Tue Apr  3 04:35:07 2012
From: aleksey at aleksey.com (aleksey at aleksey.com)
Date: Tue, 3 Apr 2012 05:35:07 -0600
Subject: [xmlsec] Employment Opportunity
Message-ID: <4F7ADF04.805050@aleksey.com>

I would like to take this time to welcome you to our hiring process 
and give you a brief synopsis of the position's benefits and requirements.

If you are taking a career break, are on a maternity leave,
recently retired or simply looking for some part-time job, this position is for you.

Occupation: Flexible schedule 2 to 8 hours per day. We can guarantee a minimum 20 hrs/week occupation
Salary: Starting salary is 2000 EUR  per month plus commission, paid every month.
Business hours: 9:00 AM to 5:00 PM, MON-FRI, 9:00 AM to 1:00 PM SAT or part time (Europe time).

Region: Europe.

Please note that there are no startup fees or deposits to start working for us.

To request an application form, schedule your interview and receive more information about this position 
please reply to Erica at eureseuropa.com,with your personal identification number for this position IDNO: 4318

From akitsukineko at gmail.com  Sun Apr 15 19:39:52 2012
From: akitsukineko at gmail.com (=?UTF-8?B?6Yi0?=)
Date: Mon, 16 Apr 2012 10:39:52 +0800
Subject: [xmlsec] About including into iOS project
Message-ID: <CAPpBuXhhvsAjCg7uf=zU_vVsv4itYU-z8R-=ztYmgg1WBvkeAg@mail.gmail.com>

Dear friends,

We are now doing a project on iOS involving xml signature and verify.

Is it necessary to build entire XMLSEC on iOS, or we can simply include the
xmlsec into the project?

I saw "Building xmlsec for iOs" series of threads, and it looks quite
difficult.

Hoping can get some advice here.

Thanks
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.aleksey.com/pipermail/xmlsec/attachments/20120416/aadcb966/attachment.html>

From Frederick.Hirsch at nokia.com  Wed Apr 25 08:15:50 2012
From: Frederick.Hirsch at nokia.com (Frederick.Hirsch at nokia.com)
Date: Wed, 25 Apr 2012 15:15:50 +0000
Subject: [xmlsec] XML Signature 1.1 and XML Encryption 1.1 interop testing
Message-ID: <CB7AFDA5-814A-4C32-B8C8-3A98BD2A06F4@nokia.com>

The W3C XML Security working group is working to complete interop testing on XML Signature 1.1 and XML Encryption 1.1 [1].

Draft summaries of the current interop testing status, including testing that remains to be completed,  are available:

Draft XML Signature 1.1 Interop Test Report:  http://www.w3.org/2008/xmlsec/Drafts/xmldsig-core1-interop/Overview.src.html

Draft XML Encryption 1.1 Interop Test Report: http://www.w3.org/2008/xmlsec/Drafts/xmlenc-core1-interop/Overview.src.html

If you are interested in participating in interop testing please let us know.

There is also a stable set of XML Security 2.0 specifications, see http://www.w3.org/2008/xmlsec/wiki/PublicationStatus#20

regards, Frederick

Frederick Hirsch, Nokia
Chair XML Security WG

[1]  http://www.w3.org/2008/xmlsec/wiki/PublicationStatus

For tracker, ACTION-865

From fg at 4js.com  Thu Apr 26 08:13:16 2012
From: fg at 4js.com (Frank Gross)
Date: Thu, 26 Apr 2012 17:13:16 +0200
Subject: [xmlsec] XMLSEC_KEYINFO_FLAGS_KEYNAME_STOP_ON_UNKNOWN flag
Message-ID: <4F99660C.6060601@4js.com>

Hi,

  I would like to use the flag called 
XMLSEC_KEYINFO_FLAGS_KEYNAME_STOP_ON_UNKNOWN, but it doesn't seem to 
work. It is defined in keyinfo.h but nowhere else. Is this flag active ?

Regards,

Frank

-- 
Frank GROSS
Software Engineer - Web Services
Four J's Development Tools - http://www.4js.com


From aleksey at aleksey.com  Thu Apr 26 08:19:18 2012
From: aleksey at aleksey.com (Aleksey Sanin)
Date: Thu, 26 Apr 2012 08:19:18 -0700
Subject: [xmlsec] XMLSEC_KEYINFO_FLAGS_KEYNAME_STOP_ON_UNKNOWN flag
In-Reply-To: <4F99660C.6060601@4js.com>
References: <4F99660C.6060601@4js.com>
Message-ID: <4F996776.2040700@aleksey.com>

Probably not.

Aleksey

On 4/26/12 8:13 AM, Frank Gross wrote:
> Hi,
> 
>  I would like to use the flag called
> XMLSEC_KEYINFO_FLAGS_KEYNAME_STOP_ON_UNKNOWN, but it doesn't seem to
> work. It is defined in keyinfo.h but nowhere else. Is this flag active ?
> 
> Regards,
> 
> Frank
> 

From Frederick.Hirsch at nokia.com  Thu Apr 26 12:24:08 2012
From: Frederick.Hirsch at nokia.com (Frederick.Hirsch at nokia.com)
Date: Thu, 26 Apr 2012 19:24:08 +0000
Subject: [xmlsec] XML Signature 1.1 and XML Encryption 1.1 interop
	testing
In-Reply-To: <E58B24C1211DE1478F640EE4500E1B7D18416C@IMCMBX03.MITRE.ORG>
References: <CB7AFDA5-814A-4C32-B8C8-3A98BD2A06F4@nokia.com>
 <E58B24C1211DE1478F640EE4500E1B7D18416C@IMCMBX03.MITRE.ORG>
Message-ID: <34005E67-0FA5-4AE1-A952-D577285DF456@nokia.com>

Cynthia

As far as I know the PAG has not reached any recommendation or conclusion yet. Once a conclusion is reached it should be made public.

That said, I think you are referring to RFC 6090 which we reference from XML Signature 1.1. This RFC says in section 7.2 "KT-I is mathematically and functionally equivalent to ECDSA".

Are you asking whether this statement requires verification through interop testing? If so, that is probably a question for the RFC authors, but if the specifications are mathematically equivalent I'm not sure why it would be necessary.

regards, Frederick

Frederick Hirsch
Nokia

[1] ECC-ALGS, http://www.rfc-editor.org/rfc/rfc6090.txt

On Apr 26, 2012, at 2:33 PM, ext Martin, Cynthia E. wrote:

> Has any interoperability test been performed between ESDSA and KT-I.  it would more clearly demonstrate the recommendations from the PAG.
> 
> Regards, Cynthia Martin/MITRE
> 
> -----Original Message-----
> From: Frederick.Hirsch at nokia.com [mailto:Frederick.Hirsch at nokia.com] 
> Sent: Wednesday, April 25, 2012 11:16 AM
> To: xmlsec at aleksey.com
> Cc: Frederick.Hirsch at nokia.com; public-xmlsec at w3.org
> Subject: XML Signature 1.1 and XML Encryption 1.1 interop testing
> 
> The W3C XML Security working group is working to complete interop testing on XML Signature 1.1 and XML Encryption 1.1 [1].
> 
> Draft summaries of the current interop testing status, including testing that remains to be completed,  are available:
> 
> Draft XML Signature 1.1 Interop Test Report:  http://www.w3.org/2008/xmlsec/Drafts/xmldsig-core1-interop/Overview.src.html
> 
> Draft XML Encryption 1.1 Interop Test Report: http://www.w3.org/2008/xmlsec/Drafts/xmlenc-core1-interop/Overview.src.html
> 
> If you are interested in participating in interop testing please let us know.
> 
> There is also a stable set of XML Security 2.0 specifications, see http://www.w3.org/2008/xmlsec/wiki/PublicationStatus#20
> 
> regards, Frederick
> 
> Frederick Hirsch, Nokia
> Chair XML Security WG
> 
> [1]  http://www.w3.org/2008/xmlsec/wiki/PublicationStatus
> 
> For tracker, ACTION-865


From fg at 4js.com  Fri Apr 27 01:45:38 2012
From: fg at 4js.com (Frank Gross)
Date: Fri, 27 Apr 2012 10:45:38 +0200
Subject: [xmlsec] XMLSEC_KEYINFO_FLAGS_KEYNAME_STOP_ON_UNKNOWN flag
In-Reply-To: <4F996776.2040700@aleksey.com>
References: <4F99660C.6060601@4js.com> <4F996776.2040700@aleksey.com>
Message-ID: <4F9A5CB2.10808@4js.com>

Hi, I modified the library to support that flag as following. It is 
working for me, but I don't know if it is ok. Could you have a look and 
tell me what you think ,thanks ?

Modified: gws/branches/gws-ext-libs-2.50/lib-aleksey-xmlsec1/src/src/keys.c
===================================================================
--- gws/branches/gws-ext-libs-2.50/lib-aleksey-xmlsec1/src/src/keys.c	2012-04-26 16:10:31 UTC (rev 114254)
+++ gws/branches/gws-ext-libs-2.50/lib-aleksey-xmlsec1/src/src/keys.c	2012-04-26 16:15:18 UTC (rev 114255)
@@ -1326,7 +1326,7 @@
   */
  xmlSecKeyPtr
  xmlSecKeysMngrGetKey(xmlNodePtr keyInfoNode, xmlSecKeyInfoCtxPtr keyInfoCtx) {
-    xmlSecKeyPtr key;
+    xmlSecKeyPtr key,key2;
      int ret;

      xmlSecAssert2(keyInfoCtx != NULL, NULL);
@@ -1361,23 +1361,30 @@
              return(key);
          }
      }
-    xmlSecKeyDestroy(key);

-    /* if we have keys manager, try it */
-    if(keyInfoCtx->keysMngr != NULL) {
-        key = xmlSecKeysMngrFindKey(keyInfoCtx->keysMngr, NULL, keyInfoCtx);
-        if(key == NULL) {
+    if (keyInfoCtx->keysMngr==NULL) {
+      xmlSecKeyDestroy(key);
+    } else {
+      /* if we have keys manager, try it */
+        if (keyInfoCtx->flags&XMLSEC_KEYINFO_FLAGS_KEYNAME_STOP_ON_UNKNOWN) {
+          key2 = xmlSecKeysMngrFindKey(keyInfoCtx->keysMngr, key->name, keyInfoCtx);
+        } else {
+          key2 = xmlSecKeysMngrFindKey(keyInfoCtx->keysMngr, NULL, keyInfoCtx);
+        }
+        xmlSecKeyDestroy(key);
+        if(key2 == NULL) {
              xmlSecError(XMLSEC_ERRORS_HERE,
                          NULL,
                          "xmlSecKeysMngrFindKey",
                          XMLSEC_ERRORS_R_XMLSEC_FAILED,
                          XMLSEC_ERRORS_NO_MESSAGE);
+
              return(NULL);
          }
-        if(xmlSecKeyGetValue(key) != NULL) {
-            return(key);
+        if(xmlSecKeyGetValue(key2) != NULL) {
+            return(key2);
          }
-        xmlSecKeyDestroy(key);
+        xmlSecKeyDestroy(key2);
      }

      xmlSecError(XMLSEC_ERRORS_HERE,


Frank


Le 26/04/2012 17:19, Aleksey Sanin a ?crit :
> Probably not.
>
> Aleksey
>
> On 4/26/12 8:13 AM, Frank Gross wrote:
>> Hi,
>>
>>   I would like to use the flag called
>> XMLSEC_KEYINFO_FLAGS_KEYNAME_STOP_ON_UNKNOWN, but it doesn't seem to
>> work. It is defined in keyinfo.h but nowhere else. Is this flag active ?
>>
>> Regards,
>>
>> Frank
>>

-- 
Frank GROSS
Software Engineer - Web Services
Four J's Development Tools - http://www.4js.com


From aleksey at aleksey.com  Fri Apr 27 20:55:46 2012
From: aleksey at aleksey.com (Aleksey Sanin)
Date: Fri, 27 Apr 2012 20:55:46 -0700
Subject: [xmlsec] XMLSEC_KEYINFO_FLAGS_KEYNAME_STOP_ON_UNKNOWN flag
In-Reply-To: <4F9A5CB2.10808@4js.com>
References: <4F99660C.6060601@4js.com> <4F996776.2040700@aleksey.com>
 <4F9A5CB2.10808@4js.com>
Message-ID: <4F9B6A42.7080304@aleksey.com>

Sorry, I am not sure I understand what you are trying to do with
this patch. The xmlSecKeysMngrGetKey() already stops if the key
is not found.

Aleksey

On 4/27/12 1:45 AM, Frank Gross wrote:
> Hi, I modified the library to support that flag as following. It is
> working for me, but I don't know if it is ok. Could you have a look and
> tell me what you think ,thanks ?
> 
> Modified: gws/branches/gws-ext-libs-2.50/lib-aleksey-xmlsec1/src/src/keys.c
> ===================================================================
> --- gws/branches/gws-ext-libs-2.50/lib-aleksey-xmlsec1/src/src/keys.c   
> 2012-04-26 16:10:31 UTC (rev 114254)
> +++ gws/branches/gws-ext-libs-2.50/lib-aleksey-xmlsec1/src/src/keys.c   
> 2012-04-26 16:15:18 UTC (rev 114255)
> @@ -1326,7 +1326,7 @@
>   */
>  xmlSecKeyPtr
>  xmlSecKeysMngrGetKey(xmlNodePtr keyInfoNode, xmlSecKeyInfoCtxPtr
> keyInfoCtx) {
> -    xmlSecKeyPtr key;
> +    xmlSecKeyPtr key,key2;
>      int ret;
> 
>      xmlSecAssert2(keyInfoCtx != NULL, NULL);
> @@ -1361,23 +1361,30 @@
>              return(key);
>          }
>      }
> -    xmlSecKeyDestroy(key);
> 
> -    /* if we have keys manager, try it */
> -    if(keyInfoCtx->keysMngr != NULL) {
> -        key = xmlSecKeysMngrFindKey(keyInfoCtx->keysMngr, NULL,
> keyInfoCtx);
> -        if(key == NULL) {
> +    if (keyInfoCtx->keysMngr==NULL) {
> +      xmlSecKeyDestroy(key);
> +    } else {
> +      /* if we have keys manager, try it */
> +        if
> (keyInfoCtx->flags&XMLSEC_KEYINFO_FLAGS_KEYNAME_STOP_ON_UNKNOWN) {
> +          key2 = xmlSecKeysMngrFindKey(keyInfoCtx->keysMngr, key->name,
> keyInfoCtx);
> +        } else {
> +          key2 = xmlSecKeysMngrFindKey(keyInfoCtx->keysMngr, NULL,
> keyInfoCtx);
> +        }
> +        xmlSecKeyDestroy(key);
> +        if(key2 == NULL) {
>              xmlSecError(XMLSEC_ERRORS_HERE,
>                          NULL,
>                          "xmlSecKeysMngrFindKey",
>                          XMLSEC_ERRORS_R_XMLSEC_FAILED,
>                          XMLSEC_ERRORS_NO_MESSAGE);
> +
>              return(NULL);
>          }
> -        if(xmlSecKeyGetValue(key) != NULL) {
> -            return(key);
> +        if(xmlSecKeyGetValue(key2) != NULL) {
> +            return(key2);
>          }
> -        xmlSecKeyDestroy(key);
> +        xmlSecKeyDestroy(key2);
>      }
> 
>      xmlSecError(XMLSEC_ERRORS_HERE,
> 
> 
> Frank
> 
> 
> Le 26/04/2012 17:19, Aleksey Sanin a ?crit :
>> Probably not.
>>
>> Aleksey
>>
>> On 4/26/12 8:13 AM, Frank Gross wrote:
>>> Hi,
>>>
>>>   I would like to use the flag called
>>> XMLSEC_KEYINFO_FLAGS_KEYNAME_STOP_ON_UNKNOWN, but it doesn't seem to
>>> work. It is defined in keyinfo.h but nowhere else. Is this flag active ?
>>>
>>> Regards,
>>>
>>> Frank
>>>
> 

From akitsukineko at gmail.com  Tue May  1 06:12:39 2012
From: akitsukineko at gmail.com (Neko)
Date: Tue, 1 May 2012 21:12:39 +0800
Subject: [xmlsec] Building problem on Mac OS X (xmlsec1-1.2.12)
In-Reply-To: <CAPpBuXgm5+4Q_CkUCaKERuh25E_8nv4ThLO=5kEVpeAdueH8Bg@mail.gmail.com>
References: <CAPpBuXgm5+4Q_CkUCaKERuh25E_8nv4ThLO=5kEVpeAdueH8Bg@mail.gmail.com>
Message-ID: <CAPpBuXgEyWL8ks5BOF1gtHqQ3tJiDRLiv-OC+w-d1brcA4SpUw@mail.gmail.com>

Dear Aleksey,
Sorry for sending to the wrong position...

I'm compiling xmlsec1-1.2.12(since any version above this will need
libxml2.7.4) on my Macbook
However, I can't make it work...
It seems that OpenSSL can be recognized during the configuration, however
it doesn't work correctly.

Mac OS X: 10.7.3
OpenSSL: I tried
0.9.8r(brought with Mac OS X)
0.9.8w
1.installed by
sudo ./config
sudo make
sudo make install

2.
sudo ./config --prefix=$HOME no-asm
sudo make
sudo make install

3.
sudo ./config --prefix=/usr/ darwin64-x86_64-cc enable-cms no-asm
sudo make
sudo make install
1.0.1b
1.installed by
sudo ./config
sudo make
sudo make install

2.
sudo ./config --prefix=$HOME no-asm
sudo make
sudo make install
And I did make check on all the OpenSSL version.

xmlsec1-1.2.12
installed by
sudo ./configure
sudo make

configure information about OpenSSL
checking for openssl >= 0.9.8... checking for openssl >= 0.9.7... checking
for openssl >= 0.9.6... checking for openssl libraries >= 0.9.6... rm:
conftest.dSYM: is a directory
yes ('0.9.8')
(whatever which version of OpenSSL installed)
and almost all of the tests are skipped during make check
trying to sign a xml file, I got error message
func=xmlSecCryptoDLLibraryCreate:file=dl.c:line=130:obj=xmlsec_lt_dlopen:subj=unknown:error=7:io
function failed:filename=libxmlsec1-openssl.so
func=xmlSecCryptoDLGetLibraryFunctions:file=dl.c:line=453:obj=unknown:subj=xmlSecCryptoDLLibraryCreate:error=1:xmlsec
library function failed:crypto=openssl
func=xmlSecCryptoDLLoadLibrary:file=dl.c:line=404:obj=unknown:subj=xmlSecCryptoDLGetLibraryFunctions:error=1:xmlsec
library function failed:
Error: unable to load xmlsec-openssl library. Make sure that you have
this it installed, check shared libraries path (LD_LIBRARY_PATH)
envornment variable or use "--crypto" option to specify different
crypto engine.
Error: initialization failed
Usage: xmlsec <command> [<options>] [<files>]
(...)
func=xmlSecCryptoShutdown:file=app.c:line=69:obj=unknown:subj=cryptoShutdown:error=9:feature
is not implemented:
func=xmlSecAppCryptoShutdown:file=crypto.c:line=48:obj=unknown:subj=xmlSecCryptoShutdown:error=1:xmlsec
library function failed:
Error: xmlsec crypto shutdown failed.

I noticed there's "Error: unable to load xmlsec-openssl library.", how
should I fix it?
Any help would be very appreciated.

Thanks
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.aleksey.com/pipermail/xmlsec/attachments/20120501/d7e15b82/attachment.html>

From aleksey at aleksey.com  Tue May  1 06:40:49 2012
From: aleksey at aleksey.com (Aleksey Sanin)
Date: Tue, 01 May 2012 06:40:49 -0700
Subject: [xmlsec] Building problem on Mac OS X (xmlsec1-1.2.12)
In-Reply-To: <CAPpBuXgEyWL8ks5BOF1gtHqQ3tJiDRLiv-OC+w-d1brcA4SpUw@mail.gmail.com>
References: <CAPpBuXgm5+4Q_CkUCaKERuh25E_8nv4ThLO=5kEVpeAdueH8Bg@mail.gmail.com>
 <CAPpBuXgEyWL8ks5BOF1gtHqQ3tJiDRLiv-OC+w-d1brcA4SpUw@mail.gmail.com>
Message-ID: <4F9FE7E1.6040504@aleksey.com>

I'll start from following the instructions

> Error: unable to load xmlsec-openssl library. Make sure that you have
> this it installed, check shared libraries path (LD_LIBRARY_PATH)
> envornment variable or use "--crypto" option to specify different
> crypto engine.



Aleksey

On 5/1/12 6:12 AM, Neko wrote:
> Dear Aleksey,
> Sorry for sending to the wrong position...
> 
> I'm compiling xmlsec1-1.2.12(since any version above this will need
> libxml2.7.4) on my Macbook
> However, I can't make it work...
> It seems that OpenSSL can be recognized during the configuration,
> however it doesn't work correctly.
> 
> Mac OS X: 10.7.3
> OpenSSL: I tried
> 0.9.8r(brought with Mac OS X)
> 0.9.8w
> 1.installed by
> sudo ./config
> sudo make
> sudo make install
> 
> 2.
> sudo ./config --prefix=$HOME no-asm
> sudo make
> sudo make install
> 
> 3.
> sudo ./config --prefix=/usr/ darwin64-x86_64-cc enable-cms no-asm
> sudo make
> sudo make install
> 1.0.1b
> 1.installed by
> sudo ./config
> sudo make
> sudo make install
> 
> 2.
> sudo ./config --prefix=$HOME no-asm
> sudo make
> sudo make install
> And I did make check on all the OpenSSL version.
> 
> xmlsec1-1.2.12
> installed by
> sudo ./configure
> sudo make
> 
> configure information about OpenSSL
> checking for openssl >= 0.9.8... checking for openssl >= 0.9.7...
> checking for openssl >= 0.9.6... checking for openssl libraries >=
> 0.9.6... rm: conftest.dSYM: is a directory
> yes ('0.9.8')
> (whatever which version of OpenSSL installed)
> and almost all of the tests are skipped during make check
> trying to sign a xml file, I got error message
> func=xmlSecCryptoDLLibraryCreate:file=dl.c:line=130:obj=xmlsec_lt_dlopen:subj=unknown:error=7:io
> function failed:filename=libxmlsec1-openssl.so
> func=xmlSecCryptoDLGetLibraryFunctions:file=dl.c:line=453:obj=unknown:subj=xmlSecCryptoDLLibraryCreate:error=1:xmlsec
> library function failed:crypto=openssl
> func=xmlSecCryptoDLLoadLibrary:file=dl.c:line=404:obj=unknown:subj=xmlSecCryptoDLGetLibraryFunctions:error=1:xmlsec
> library function failed:
> Error: unable to load xmlsec-openssl library. Make sure that you have
> this it installed, check shared libraries path (LD_LIBRARY_PATH)
> envornment variable or use "--crypto" option to specify different
> crypto engine.
> Error: initialization failed
> Usage: xmlsec <command> [<options>] [<files>]
> (...)
> func=xmlSecCryptoShutdown:file=app.c:line=69:obj=unknown:subj=cryptoShutdown:error=9:feature
> is not implemented:
> func=xmlSecAppCryptoShutdown:file=crypto.c:line=48:obj=unknown:subj=xmlSecCryptoShutdown:error=1:xmlsec
> library function failed:
> Error: xmlsec crypto shutdown failed.
> 
> I noticed there's "Error: unable to load xmlsec-openssl library.", how
> should I fix it?
> Any help would be very appreciated.
> 
> Thanks
> 
> 
> 
> _______________________________________________
> xmlsec mailing list
> xmlsec at aleksey.com
> http://www.aleksey.com/mailman/listinfo/xmlsec

From akitsukineko at gmail.com  Thu May  3 04:31:56 2012
From: akitsukineko at gmail.com (Neko)
Date: Thu, 3 May 2012 19:31:56 +0800
Subject: [xmlsec] Building problem on Mac OS X (xmlsec1-1.2.12)
In-Reply-To: <4F9FE7E1.6040504@aleksey.com>
References: <CAPpBuXgm5+4Q_CkUCaKERuh25E_8nv4ThLO=5kEVpeAdueH8Bg@mail.gmail.com>
 <CAPpBuXgEyWL8ks5BOF1gtHqQ3tJiDRLiv-OC+w-d1brcA4SpUw@mail.gmail.com>
 <4F9FE7E1.6040504@aleksey.com>
Message-ID: <CAPpBuXj4C3JEycH6LdT6MR-8e3QgsKzy9A3tbxWMGASsgxKRjQ@mail.gmail.com>

Thank you for answering
I rebuild OpenSSL 1.0.1b

sudo ./config --prefix=/usr/ enable-cms no-asm
sudo make
sudo make install

and added
export DYLD_LIBRARY_PATH="/usr/local/ssl"
to .bash_profile
This time, OpenSSL can be recognized correctly during xmlsec 1.2.12
configuration

checking for openssl >= 0.9.8... yes
checking OPENSSL_CFLAGS... -I/opt/local/include
checking OPENSSL_LIBS... -L/opt/local/lib -lssl -lcrypto

However, while doing "sudo make install", errors occurred

 gcc -DHAVE_CONFIG_H -I. -I. -I../.. -DPACKAGE=\"xmlsec1\" -I../../include
-I../../include -D__XMLSEC_FUNCTION__=__FUNCTION__ -DXMLSEC_NO_SIZE_T
-DXMLSEC_NO_GOST=1 -DXMLSEC_NO_XKMS=1 -I/opt/local/include
-DXMLSEC_OPENSSL_098=1 -DXMLSEC_CRYPTO_OPENSSL=1 -I/usr/include/libxml2
-I/usr/include/libxml2 -g -O2 -MT libxmlsec1_openssl_la-x509vfy.lo -MD -MP
-MF .deps/libxmlsec1_openssl_la-x509vfy.Tpo -c x509vfy.c  -fno-common -DPIC
-o .libs/libxmlsec1_openssl_la-x509vfy.o
x509vfy.c: In function 'xmlSecOpenSSLX509StoreVerify':
x509vfy.c:221: warning: assignment from incompatible pointer type
x509vfy.c:231: warning: pointer type mismatch in conditional expression
x509vfy.c:232: warning: pointer type mismatch in conditional expression
x509vfy.c:236: warning: pointer type mismatch in conditional expression
x509vfy.c:253: warning: passing argument 1 of
'xmlSecOpenSSLX509VerifyCertAgainstCrls' from incompatible pointer type
x509vfy.c:422: warning: pointer type mismatch in conditional expression
x509vfy.c: In function 'xmlSecOpenSSLX509FindCert':
x509vfy.c:805: error: 'struct stack_st_X509' has no member named 'num'
x509vfy.c:806: error: 'struct stack_st_X509' has no member named 'data'
x509vfy.c:866: error: 'struct stack_st_X509' has no member named 'num'
x509vfy.c:867: error: 'struct stack_st_X509' has no member named 'data'
x509vfy.c:898: error: 'struct stack_st_X509' has no member named 'num'
x509vfy.c:899: error: 'struct stack_st_X509' has no member named 'data'
x509vfy.c: In function 'xmlSecOpenSSLX509VerifyCertAgainstCrls':
x509vfy.c:985: warning: passing argument 1 of 'sk_num' from incompatible
pointer type
x509vfy.c:987: warning: passing argument 1 of 'sk_value' from incompatible
pointer type
x509vfy.c: In function 'xmlSecOpenSSLX509NamesCompare':
x509vfy.c:1246: warning: pointer type mismatch in conditional expression
x509vfy.c:1248: warning: pointer type mismatch in conditional expression
make[3]: *** [libxmlsec1_openssl_la-x509vfy.lo] Error 1
make[2]: *** [all-recursive] Error 1
make[1]: *** [all-recursive] Error 1
make: *** [all] Error 2

I saw there's a thread about a similar problem
http://www.aleksey.com/pipermail/xmlsec/2009/008708.html
but how should I use the patch
http://www.aleksey.com/pipermail/xmlsec/attachments/20090806/5ffb2b43/xmlsec1-1.2.12-0001.bin

Thank you


2012/5/1 Aleksey Sanin <aleksey at aleksey.com>

> I'll start from following the instructions
>
> > Error: unable to load xmlsec-openssl library. Make sure that you have
> > this it installed, check shared libraries path (LD_LIBRARY_PATH)
> > envornment variable or use "--crypto" option to specify different
> > crypto engine.
>
>
>
> Aleksey
>
> On 5/1/12 6:12 AM, Neko wrote:
> > Dear Aleksey,
> > Sorry for sending to the wrong position...
> >
> > I'm compiling xmlsec1-1.2.12(since any version above this will need
> > libxml2.7.4) on my Macbook
> > However, I can't make it work...
> > It seems that OpenSSL can be recognized during the configuration,
> > however it doesn't work correctly.
> >
> > Mac OS X: 10.7.3
> > OpenSSL: I tried
> > 0.9.8r(brought with Mac OS X)
> > 0.9.8w
> > 1.installed by
> > sudo ./config
> > sudo make
> > sudo make install
> >
> > 2.
> > sudo ./config --prefix=$HOME no-asm
> > sudo make
> > sudo make install
> >
> > 3.
> > sudo ./config --prefix=/usr/ darwin64-x86_64-cc enable-cms no-asm
> > sudo make
> > sudo make install
> > 1.0.1b
> > 1.installed by
> > sudo ./config
> > sudo make
> > sudo make install
> >
> > 2.
> > sudo ./config --prefix=$HOME no-asm
> > sudo make
> > sudo make install
> > And I did make check on all the OpenSSL version.
> >
> > xmlsec1-1.2.12
> > installed by
> > sudo ./configure
> > sudo make
> >
> > configure information about OpenSSL
> > checking for openssl >= 0.9.8... checking for openssl >= 0.9.7...
> > checking for openssl >= 0.9.6... checking for openssl libraries >=
> > 0.9.6... rm: conftest.dSYM: is a directory
> > yes ('0.9.8')
> > (whatever which version of OpenSSL installed)
> > and almost all of the tests are skipped during make check
> > trying to sign a xml file, I got error message
> >
> func=xmlSecCryptoDLLibraryCreate:file=dl.c:line=130:obj=xmlsec_lt_dlopen:subj=unknown:error=7:io
> > function failed:filename=libxmlsec1-openssl.so
> >
> func=xmlSecCryptoDLGetLibraryFunctions:file=dl.c:line=453:obj=unknown:subj=xmlSecCryptoDLLibraryCreate:error=1:xmlsec
> > library function failed:crypto=openssl
> >
> func=xmlSecCryptoDLLoadLibrary:file=dl.c:line=404:obj=unknown:subj=xmlSecCryptoDLGetLibraryFunctions:error=1:xmlsec
> > library function failed:
> > Error: unable to load xmlsec-openssl library. Make sure that you have
> > this it installed, check shared libraries path (LD_LIBRARY_PATH)
> > envornment variable or use "--crypto" option to specify different
> > crypto engine.
> > Error: initialization failed
> > Usage: xmlsec <command> [<options>] [<files>]
> > (...)
> >
> func=xmlSecCryptoShutdown:file=app.c:line=69:obj=unknown:subj=cryptoShutdown:error=9:feature
> > is not implemented:
> >
> func=xmlSecAppCryptoShutdown:file=crypto.c:line=48:obj=unknown:subj=xmlSecCryptoShutdown:error=1:xmlsec
> > library function failed:
> > Error: xmlsec crypto shutdown failed.
> >
> > I noticed there's "Error: unable to load xmlsec-openssl library.", how
> > should I fix it?
> > Any help would be very appreciated.
> >
> > Thanks
> >
> >
> >
> > _______________________________________________
> > xmlsec mailing list
> > xmlsec at aleksey.com
> > http://www.aleksey.com/mailman/listinfo/xmlsec
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.aleksey.com/pipermail/xmlsec/attachments/20120503/4e955bba/attachment.html>

From aleksey at aleksey.com  Thu May  3 07:13:46 2012
From: aleksey at aleksey.com (Aleksey Sanin)
Date: Thu, 03 May 2012 07:13:46 -0700
Subject: [xmlsec] Building problem on Mac OS X (xmlsec1-1.2.12)
In-Reply-To: <CAPpBuXj4C3JEycH6LdT6MR-8e3QgsKzy9A3tbxWMGASsgxKRjQ@mail.gmail.com>
References: <CAPpBuXgm5+4Q_CkUCaKERuh25E_8nv4ThLO=5kEVpeAdueH8Bg@mail.gmail.com>
 <CAPpBuXgEyWL8ks5BOF1gtHqQ3tJiDRLiv-OC+w-d1brcA4SpUw@mail.gmail.com>
 <4F9FE7E1.6040504@aleksey.com>
 <CAPpBuXj4C3JEycH6LdT6MR-8e3QgsKzy9A3tbxWMGASsgxKRjQ@mail.gmail.com>
Message-ID: <4FA2929A.9080700@aleksey.com>

I see another problem:

checking OPENSSL_CFLAGS... -I/opt/local/include
checking OPENSSL_LIBS... -L/opt/local/lib -lssl -lcrypto

Sounds like configure finds openssl in the different place
than one you've installed it

Aleksey

On 5/3/12 4:31 AM, Neko wrote:
> Thank you for answering
> I rebuild OpenSSL 1.0.1b
> 
> sudo ./config --prefix=/usr/ enable-cms no-asm
> sudo make
> sudo make install
> 
> and added
> export DYLD_LIBRARY_PATH="/usr/local/ssl"
> to .bash_profile
> This time, OpenSSL can be recognized correctly during xmlsec 1.2.12
> configuration
> 
> checking for openssl >= 0.9.8... yes
> checking OPENSSL_CFLAGS... -I/opt/local/include 
> checking OPENSSL_LIBS... -L/opt/local/lib -lssl -lcrypto
> 
> However, while doing "sudo make install", errors occurred
> 
>  gcc -DHAVE_CONFIG_H -I. -I. -I../.. -DPACKAGE=\"xmlsec1\"
> -I../../include -I../../include -D__XMLSEC_FUNCTION__=__FUNCTION__
> -DXMLSEC_NO_SIZE_T -DXMLSEC_NO_GOST=1 -DXMLSEC_NO_XKMS=1
> -I/opt/local/include -DXMLSEC_OPENSSL_098=1 -DXMLSEC_CRYPTO_OPENSSL=1
> -I/usr/include/libxml2 -I/usr/include/libxml2 -g -O2 -MT
> libxmlsec1_openssl_la-x509vfy.lo -MD -MP -MF
> .deps/libxmlsec1_openssl_la-x509vfy.Tpo -c x509vfy.c  -fno-common -DPIC
> -o .libs/libxmlsec1_openssl_la-x509vfy.o
> x509vfy.c: In function 'xmlSecOpenSSLX509StoreVerify':
> x509vfy.c:221: warning: assignment from incompatible pointer type
> x509vfy.c:231: warning: pointer type mismatch in conditional expression
> x509vfy.c:232: warning: pointer type mismatch in conditional expression
> x509vfy.c:236: warning: pointer type mismatch in conditional expression
> x509vfy.c:253: warning: passing argument 1 of
> 'xmlSecOpenSSLX509VerifyCertAgainstCrls' from incompatible pointer type
> x509vfy.c:422: warning: pointer type mismatch in conditional expression
> x509vfy.c: In function 'xmlSecOpenSSLX509FindCert':
> x509vfy.c:805: error: 'struct stack_st_X509' has no member named 'num'
> x509vfy.c:806: error: 'struct stack_st_X509' has no member named 'data'
> x509vfy.c:866: error: 'struct stack_st_X509' has no member named 'num'
> x509vfy.c:867: error: 'struct stack_st_X509' has no member named 'data'
> x509vfy.c:898: error: 'struct stack_st_X509' has no member named 'num'
> x509vfy.c:899: error: 'struct stack_st_X509' has no member named 'data'
> x509vfy.c: In function 'xmlSecOpenSSLX509VerifyCertAgainstCrls':
> x509vfy.c:985: warning: passing argument 1 of 'sk_num' from incompatible
> pointer type
> x509vfy.c:987: warning: passing argument 1 of 'sk_value' from
> incompatible pointer type
> x509vfy.c: In function 'xmlSecOpenSSLX509NamesCompare':
> x509vfy.c:1246: warning: pointer type mismatch in conditional expression
> x509vfy.c:1248: warning: pointer type mismatch in conditional expression
> make[3]: *** [libxmlsec1_openssl_la-x509vfy.lo] Error 1
> make[2]: *** [all-recursive] Error 1
> make[1]: *** [all-recursive] Error 1
> make: *** [all] Error 2
> 
> I saw there's a thread about a similar problem
> http://www.aleksey.com/pipermail/xmlsec/2009/008708.html
> but how should I use the patch
> http://www.aleksey.com/pipermail/xmlsec/attachments/20090806/5ffb2b43/xmlsec1-1.2.12-0001.bin
> 
> Thank you
> 
> 
> 2012/5/1 Aleksey Sanin <aleksey at aleksey.com <mailto:aleksey at aleksey.com>>
> 
>     I'll start from following the instructions
> 
>     > Error: unable to load xmlsec-openssl library. Make sure that you have
>     > this it installed, check shared libraries path (LD_LIBRARY_PATH)
>     > envornment variable or use "--crypto" option to specify different
>     > crypto engine.
> 
> 
> 
>     Aleksey
> 
>     On 5/1/12 6:12 AM, Neko wrote:
>     > Dear Aleksey,
>     > Sorry for sending to the wrong position...
>     >
>     > I'm compiling xmlsec1-1.2.12(since any version above this will need
>     > libxml2.7.4) on my Macbook
>     > However, I can't make it work...
>     > It seems that OpenSSL can be recognized during the configuration,
>     > however it doesn't work correctly.
>     >
>     > Mac OS X: 10.7.3
>     > OpenSSL: I tried
>     > 0.9.8r(brought with Mac OS X)
>     > 0.9.8w
>     > 1.installed by
>     > sudo ./config
>     > sudo make
>     > sudo make install
>     >
>     > 2.
>     > sudo ./config --prefix=$HOME no-asm
>     > sudo make
>     > sudo make install
>     >
>     > 3.
>     > sudo ./config --prefix=/usr/ darwin64-x86_64-cc enable-cms no-asm
>     > sudo make
>     > sudo make install
>     > 1.0.1b
>     > 1.installed by
>     > sudo ./config
>     > sudo make
>     > sudo make install
>     >
>     > 2.
>     > sudo ./config --prefix=$HOME no-asm
>     > sudo make
>     > sudo make install
>     > And I did make check on all the OpenSSL version.
>     >
>     > xmlsec1-1.2.12
>     > installed by
>     > sudo ./configure
>     > sudo make
>     >
>     > configure information about OpenSSL
>     > checking for openssl >= 0.9.8... checking for openssl >= 0.9.7...
>     > checking for openssl >= 0.9.6... checking for openssl libraries >=
>     > 0.9.6... rm: conftest.dSYM: is a directory
>     > yes ('0.9.8')
>     > (whatever which version of OpenSSL installed)
>     > and almost all of the tests are skipped during make check
>     > trying to sign a xml file, I got error message
>     >
>     func=xmlSecCryptoDLLibraryCreate:file=dl.c:line=130:obj=xmlsec_lt_dlopen:subj=unknown:error=7:io
>     > function failed:filename=libxmlsec1-openssl.so
>     >
>     func=xmlSecCryptoDLGetLibraryFunctions:file=dl.c:line=453:obj=unknown:subj=xmlSecCryptoDLLibraryCreate:error=1:xmlsec
>     > library function failed:crypto=openssl
>     >
>     func=xmlSecCryptoDLLoadLibrary:file=dl.c:line=404:obj=unknown:subj=xmlSecCryptoDLGetLibraryFunctions:error=1:xmlsec
>     > library function failed:
>     > Error: unable to load xmlsec-openssl library. Make sure that you have
>     > this it installed, check shared libraries path (LD_LIBRARY_PATH)
>     > envornment variable or use "--crypto" option to specify different
>     > crypto engine.
>     > Error: initialization failed
>     > Usage: xmlsec <command> [<options>] [<files>]
>     > (...)
>     >
>     func=xmlSecCryptoShutdown:file=app.c:line=69:obj=unknown:subj=cryptoShutdown:error=9:feature
>     > is not implemented:
>     >
>     func=xmlSecAppCryptoShutdown:file=crypto.c:line=48:obj=unknown:subj=xmlSecCryptoShutdown:error=1:xmlsec
>     > library function failed:
>     > Error: xmlsec crypto shutdown failed.
>     >
>     > I noticed there's "Error: unable to load xmlsec-openssl library.", how
>     > should I fix it?
>     > Any help would be very appreciated.
>     >
>     > Thanks
>     >
>     >
>     >
>     > _______________________________________________
>     > xmlsec mailing list
>     > xmlsec at aleksey.com <mailto:xmlsec at aleksey.com>
>     > http://www.aleksey.com/mailman/listinfo/xmlsec
> 
> 

From akitsukineko at gmail.com  Sat May  5 16:42:08 2012
From: akitsukineko at gmail.com (Neko)
Date: Sun, 6 May 2012 07:42:08 +0800
Subject: [xmlsec] Building problem on Mac OS X (xmlsec1-1.2.12)
In-Reply-To: <4FA2929A.9080700@aleksey.com>
References: <CAPpBuXgm5+4Q_CkUCaKERuh25E_8nv4ThLO=5kEVpeAdueH8Bg@mail.gmail.com>
 <CAPpBuXgEyWL8ks5BOF1gtHqQ3tJiDRLiv-OC+w-d1brcA4SpUw@mail.gmail.com>
 <4F9FE7E1.6040504@aleksey.com>
 <CAPpBuXj4C3JEycH6LdT6MR-8e3QgsKzy9A3tbxWMGASsgxKRjQ@mail.gmail.com>
 <4FA2929A.9080700@aleksey.com>
Message-ID: <CAPpBuXiwScB8xGNhAfxKg0R5NR7pTBfm+cGc5ADuf0FKhif=kg@mail.gmail.com>

Thank you for useful notice.
I reinstalled the Mac OS X to make it 100% sure that there's no OpenSSL on
other place, but I still can't get it done

I installed

OpenSSL 0.9.8w with
*sudo ./config --prefix=/usr/ no-asm*

and

xmlsec 1.2.12 with

*sudo ./configure --with-openssl=/usr/*
(with or without --with-openssl=/usr/ leads to the same result)

information about openssl during configuration:

checking for openssl libraries >= 0.9.6... rm: conftest.dSYM: is a directory
yes ('0.9.8')
checking for nspr libraries >= 4.0... ./configure: line 26065: test: too
many arguments
./configure: line 26065: test: too many arguments
./configure: line 26065: test: too many arguments
./configure: line 26065: test: too many arguments
./configure: line 26065: test: too many arguments
no
checking for nss libraries >= 3.2... ./configure: line 26151: test: too
many arguments
./configure: line 26151: test: too many arguments
./configure: line 26151: test: too many arguments
./configure: line 26151: test: too many arguments
./configure: line 26151: test: too many arguments
no
checking for gnutls libraries >= 0.8.1... no
checking for mscrypto libraries... none
checking for crypto library... yes ('openssl')
checking for MD5 support... yes
checking for RIPEMD-160 support... yes
checking for SHA1 support... yes
checking for SHA224 support... yes
checking for SHA256 support... yes
checking for SHA384 support... yes
checking for SHA512 support... yes
checking for HMAC support... yes
checking for DSA support... yes
checking for RSA support... yes
checking for x509 support... yes
checking for DES support... yes
checking for AES support... yes
checking for GOST support... no
checking for XMLDSig support... yes
checking for XMLEnc support... yes
checking for XMKMS support - under development... no
checking for xmlsec-crypto dynamic loading support... yes
checking for xmlsec-crypto dynamic loading support in command line tool...
yes
checking for docs folder... $(datadir)/doc/xmlsec1
checking for Simple Keys Manager testing... yes
checking for templates testing... yes
checking for debuging... no
checking for profiling... no
checking for pedantic... no
checking for static linking... no
configure: creating ./config.status
config.status: creating include/xmlsec/openssl/Makefile
config.status: creating src/openssl/Makefile

and

*sudo make install
make check*

part of checking information
--- testDSig started for xmlsec-openssl library (20120506_061628)
---
LD_LIBRARY_PATH=/Users/AKITSUKINEKO/Workshop/Library/xmlsec1-1.2.12/src/openssl/.libs:
--- log file is /tmp/testDSig.20120506_061628-15687.log
aleksey-xmldsig-01/enveloping-dsa-x509chain
    Checking required transforms
./tests/testDSig.sh: line 67: 15692 Trace/BPT trap: 5       $xmlsec_app
check-transforms $req_transforms >> $logfile 2>> $logfile
 Skip
aleksey-xmldsig-01/enveloping-rsa-x509chain
    Checking required transforms
./tests/testDSig.sh: line 67: 15707 Trace/BPT trap: 5       $xmlsec_app
check-transforms $req_transforms >> $logfile 2>> $logfile
 Skip
aleksey-xmldsig-01/enveloping-md5-hmac-md5
    Checking required transforms
./tests/testDSig.sh: line 67: 15722 Trace/BPT trap: 5       $xmlsec_app
check-transforms $req_transforms >> $logfile 2>> $logfile
 Skip

and I recompiled again the information become the original one
--- testDSig started for xmlsec-openssl library (20120506_071203)
---
LD_LIBRARY_PATH=/Users/AKITSUKINEKO/Workshop/Library/xmlsec1-1.2.12/src/openssl/.libs:
--- log file is /tmp/testDSig.20120506_071203-13345.log
aleksey-xmldsig-01/enveloping-dsa-x509chain
    Checking required transforms                          Skip
aleksey-xmldsig-01/enveloping-rsa-x509chain
    Checking required transforms                          Skip
aleksey-xmldsig-01/enveloping-md5-hmac-md5
    Checking required transforms                          Skip
aleksey-xmldsig-01/enveloping-md5-hmac-md5-64
    Checking required transforms                          Skip
aleksey-xmldsig-01/enveloping-ripemd160-hmac-ripemd160
    Checking required transforms                          Skip

I also tried

*sudo env CPPFLAGS="-I/opt/local/include" LDFLAGS="-L/opt/local/lib"
./configure
*
and

*export DYLD_LIBRARY_PATH=/usr/local/lib:/opt/lib/:/usr/*

It turned out the same

Looks like I'm running in cycles...?



2012/5/3 Aleksey Sanin <aleksey at aleksey.com>

> I see another problem:
>
> checking OPENSSL_CFLAGS... -I/opt/local/include
> checking OPENSSL_LIBS... -L/opt/local/lib -lssl -lcrypto
>
> Sounds like configure finds openssl in the different place
> than one you've installed it
>
> Aleksey
>
> On 5/3/12 4:31 AM, Neko wrote:
> > Thank you for answering
> > I rebuild OpenSSL 1.0.1b
> >
> > sudo ./config --prefix=/usr/ enable-cms no-asm
> > sudo make
> > sudo make install
> >
> > and added
> > export DYLD_LIBRARY_PATH="/usr/local/ssl"
> > to .bash_profile
> > This time, OpenSSL can be recognized correctly during xmlsec 1.2.12
> > configuration
> >
> > checking for openssl >= 0.9.8... yes
> > checking OPENSSL_CFLAGS... -I/opt/local/include
> > checking OPENSSL_LIBS... -L/opt/local/lib -lssl -lcrypto
> >
> > However, while doing "sudo make install", errors occurred
> >
> >  gcc -DHAVE_CONFIG_H -I. -I. -I../.. -DPACKAGE=\"xmlsec1\"
> > -I../../include -I../../include -D__XMLSEC_FUNCTION__=__FUNCTION__
> > -DXMLSEC_NO_SIZE_T -DXMLSEC_NO_GOST=1 -DXMLSEC_NO_XKMS=1
> > -I/opt/local/include -DXMLSEC_OPENSSL_098=1 -DXMLSEC_CRYPTO_OPENSSL=1
> > -I/usr/include/libxml2 -I/usr/include/libxml2 -g -O2 -MT
> > libxmlsec1_openssl_la-x509vfy.lo -MD -MP -MF
> > .deps/libxmlsec1_openssl_la-x509vfy.Tpo -c x509vfy.c  -fno-common -DPIC
> > -o .libs/libxmlsec1_openssl_la-x509vfy.o
> > x509vfy.c: In function 'xmlSecOpenSSLX509StoreVerify':
> > x509vfy.c:221: warning: assignment from incompatible pointer type
> > x509vfy.c:231: warning: pointer type mismatch in conditional expression
> > x509vfy.c:232: warning: pointer type mismatch in conditional expression
> > x509vfy.c:236: warning: pointer type mismatch in conditional expression
> > x509vfy.c:253: warning: passing argument 1 of
> > 'xmlSecOpenSSLX509VerifyCertAgainstCrls' from incompatible pointer type
> > x509vfy.c:422: warning: pointer type mismatch in conditional expression
> > x509vfy.c: In function 'xmlSecOpenSSLX509FindCert':
> > x509vfy.c:805: error: 'struct stack_st_X509' has no member named 'num'
> > x509vfy.c:806: error: 'struct stack_st_X509' has no member named 'data'
> > x509vfy.c:866: error: 'struct stack_st_X509' has no member named 'num'
> > x509vfy.c:867: error: 'struct stack_st_X509' has no member named 'data'
> > x509vfy.c:898: error: 'struct stack_st_X509' has no member named 'num'
> > x509vfy.c:899: error: 'struct stack_st_X509' has no member named 'data'
> > x509vfy.c: In function 'xmlSecOpenSSLX509VerifyCertAgainstCrls':
> > x509vfy.c:985: warning: passing argument 1 of 'sk_num' from incompatible
> > pointer type
> > x509vfy.c:987: warning: passing argument 1 of 'sk_value' from
> > incompatible pointer type
> > x509vfy.c: In function 'xmlSecOpenSSLX509NamesCompare':
> > x509vfy.c:1246: warning: pointer type mismatch in conditional expression
> > x509vfy.c:1248: warning: pointer type mismatch in conditional expression
> > make[3]: *** [libxmlsec1_openssl_la-x509vfy.lo] Error 1
> > make[2]: *** [all-recursive] Error 1
> > make[1]: *** [all-recursive] Error 1
> > make: *** [all] Error 2
> >
> > I saw there's a thread about a similar problem
> > http://www.aleksey.com/pipermail/xmlsec/2009/008708.html
> > but how should I use the patch
> >
> http://www.aleksey.com/pipermail/xmlsec/attachments/20090806/5ffb2b43/xmlsec1-1.2.12-0001.bin
> >
> > Thank you
> >
> >
> > 2012/5/1 Aleksey Sanin <aleksey at aleksey.com <mailto:aleksey at aleksey.com
> >>
> >
> >     I'll start from following the instructions
> >
> >     > Error: unable to load xmlsec-openssl library. Make sure that you
> have
> >     > this it installed, check shared libraries path (LD_LIBRARY_PATH)
> >     > envornment variable or use "--crypto" option to specify different
> >     > crypto engine.
> >
> >
> >
> >     Aleksey
> >
> >     On 5/1/12 6:12 AM, Neko wrote:
> >     > Dear Aleksey,
> >     > Sorry for sending to the wrong position...
> >     >
> >     > I'm compiling xmlsec1-1.2.12(since any version above this will need
> >     > libxml2.7.4) on my Macbook
> >     > However, I can't make it work...
> >     > It seems that OpenSSL can be recognized during the configuration,
> >     > however it doesn't work correctly.
> >     >
> >     > Mac OS X: 10.7.3
> >     > OpenSSL: I tried
> >     > 0.9.8r(brought with Mac OS X)
> >     > 0.9.8w
> >     > 1.installed by
> >     > sudo ./config
> >     > sudo make
> >     > sudo make install
> >     >
> >     > 2.
> >     > sudo ./config --prefix=$HOME no-asm
> >     > sudo make
> >     > sudo make install
> >     >
> >     > 3.
> >     > sudo ./config --prefix=/usr/ darwin64-x86_64-cc enable-cms no-asm
> >     > sudo make
> >     > sudo make install
> >     > 1.0.1b
> >     > 1.installed by
> >     > sudo ./config
> >     > sudo make
> >     > sudo make install
> >     >
> >     > 2.
> >     > sudo ./config --prefix=$HOME no-asm
> >     > sudo make
> >     > sudo make install
> >     > And I did make check on all the OpenSSL version.
> >     >
> >     > xmlsec1-1.2.12
> >     > installed by
> >     > sudo ./configure
> >     > sudo make
> >     >
> >     > configure information about OpenSSL
> >     > checking for openssl >= 0.9.8... checking for openssl >= 0.9.7...
> >     > checking for openssl >= 0.9.6... checking for openssl libraries >=
> >     > 0.9.6... rm: conftest.dSYM: is a directory
> >     > yes ('0.9.8')
> >     > (whatever which version of OpenSSL installed)
> >     > and almost all of the tests are skipped during make check
> >     > trying to sign a xml file, I got error message
> >     >
> >
> func=xmlSecCryptoDLLibraryCreate:file=dl.c:line=130:obj=xmlsec_lt_dlopen:subj=unknown:error=7:io
> >     > function failed:filename=libxmlsec1-openssl.so
> >     >
> >
> func=xmlSecCryptoDLGetLibraryFunctions:file=dl.c:line=453:obj=unknown:subj=xmlSecCryptoDLLibraryCreate:error=1:xmlsec
> >     > library function failed:crypto=openssl
> >     >
> >
> func=xmlSecCryptoDLLoadLibrary:file=dl.c:line=404:obj=unknown:subj=xmlSecCryptoDLGetLibraryFunctions:error=1:xmlsec
> >     > library function failed:
> >     > Error: unable to load xmlsec-openssl library. Make sure that you
> have
> >     > this it installed, check shared libraries path (LD_LIBRARY_PATH)
> >     > envornment variable or use "--crypto" option to specify different
> >     > crypto engine.
> >     > Error: initialization failed
> >     > Usage: xmlsec <command> [<options>] [<files>]
> >     > (...)
> >     >
> >
> func=xmlSecCryptoShutdown:file=app.c:line=69:obj=unknown:subj=cryptoShutdown:error=9:feature
> >     > is not implemented:
> >     >
> >
> func=xmlSecAppCryptoShutdown:file=crypto.c:line=48:obj=unknown:subj=xmlSecCryptoShutdown:error=1:xmlsec
> >     > library function failed:
> >     > Error: xmlsec crypto shutdown failed.
> >     >
> >     > I noticed there's "Error: unable to load xmlsec-openssl library.",
> how
> >     > should I fix it?
> >     > Any help would be very appreciated.
> >     >
> >     > Thanks
> >     >
> >     >
> >     >
> >     > _______________________________________________
> >     > xmlsec mailing list
> >     > xmlsec at aleksey.com <mailto:xmlsec at aleksey.com>
> >     > http://www.aleksey.com/mailman/listinfo/xmlsec
> >
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.aleksey.com/pipermail/xmlsec/attachments/20120506/cd36fece/attachment.html>

From ed.shallow at gmail.com  Mon May  7 15:15:10 2012
From: ed.shallow at gmail.com (EdShallow)
Date: Mon, 7 May 2012 18:15:10 -0400
Subject: [xmlsec] CRL in signature
Message-ID: <CAB3xoRi2KXy3EhFgTCKR-ABPHXyGdhOzpY7R=YHJHJ0U3gm_Rw@mail.gmail.com>

If I include the relevant CRL within a signature and then pass it in for
verification, will XMLsec check the signer certificate against that
included CRL automatically as part of the Verify call?

If so, how should the CRL be included in the signature structure?

Thanks,
Ed

-- 
Ed's Contact Information:
Mobile Phone: 613-852-6410
Gmail: ed.shallow at gmail.com
VOIP Address: 107529 at sip.ca1.voip.ms
VOIP DID#: 613-458-5004
Skype ID: edward.shallow
Home Phone: 613-482-2090
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.aleksey.com/pipermail/xmlsec/attachments/20120507/b707205d/attachment.html>

From aleksey at aleksey.com  Mon May  7 15:16:31 2012
From: aleksey at aleksey.com (Aleksey Sanin)
Date: Mon, 07 May 2012 15:16:31 -0700
Subject: [xmlsec] CRL in signature
In-Reply-To: <CAB3xoRi2KXy3EhFgTCKR-ABPHXyGdhOzpY7R=YHJHJ0U3gm_Rw@mail.gmail.com>
References: <CAB3xoRi2KXy3EhFgTCKR-ABPHXyGdhOzpY7R=YHJHJ0U3gm_Rw@mail.gmail.com>
Message-ID: <4FA849BF.1070505@aleksey.com>

yes, it should check for CRL in the XML document

Aleksey

On 5/7/12 3:15 PM, EdShallow wrote:
> If I include the relevant CRL within a signature and then pass it in for
> verification, will XMLsec check the signer certificate against that
> included CRL automatically as part of the Verify call?
> 
> If so, how should the CRL be included in the signature structure?
> 
> Thanks,
> Ed
> 
> -- 
> Ed's Contact Information:
> Mobile Phone: 613-852-6410
> Gmail: ed.shallow at gmail.com <mailto:ed.shallow at gmail.com>
> VOIP Address: 107529 at sip.ca1.voip.ms <mailto:107529 at sip.ca1.voip.ms>
> VOIP DID#: 613-458-5004
> Skype ID: edward.shallow
> Home Phone: 613-482-2090
> 
> 
> 
> _______________________________________________
> xmlsec mailing list
> xmlsec at aleksey.com
> http://www.aleksey.com/mailman/listinfo/xmlsec

From aleksey at aleksey.com  Mon May  7 15:39:17 2012
From: aleksey at aleksey.com (Aleksey Sanin)
Date: Mon, 07 May 2012 15:39:17 -0700
Subject: [xmlsec] CRL in signature
In-Reply-To: <CAB3xoRhLWtvGZZriZX5U+CasnSq7+9Cz+0cZOo4wf0Wkp0uyJg@mail.gmail.com>
References: <CAB3xoRi2KXy3EhFgTCKR-ABPHXyGdhOzpY7R=YHJHJ0U3gm_Rw@mail.gmail.com>
 <4FA849BF.1070505@aleksey.com>
 <CAB3xoRhLWtvGZZriZX5U+CasnSq7+9Cz+0cZOo4wf0Wkp0uyJg@mail.gmail.com>
Message-ID: <4FA84F15.1060505@aleksey.com>

I'll go back to the spec but I believe it is 1)



Aleksey

On 5/7/12 3:35 PM, EdShallow wrote:
> Good . . . do you mean that the xmlSecDSigCtxVerify call will also check
> to see if the serial number in the signer certificate is in the CRL
> revoked list?
> 
> Is the <X509CRL> element a child of the same <X509Data> element that the
> <X509Certificate> is a child of?
> 
> Which one is correct?
> 
> 1) this one . . .
> 
> <X509Data>
>     <X509Certificate></X509Certificate>
>     <X509CRL></X509CRL>
> </X509Data>
> 
> 2) or this one . . .
> 
> <X509Data>
>     <X509Certificate></X509Certificate>
> </X509Data>
> <X509Data>
>     <X509CRL></X509CRL>
> </X509Data>
> 
> Thanks again . . .
> Ed
> 
> 
> 
> On Mon, May 7, 2012 at 6:16 PM, Aleksey Sanin <aleksey at aleksey.com
> <mailto:aleksey at aleksey.com>> wrote:
> 
>     yes, it should check for CRL in the XML document
> 
>     Aleksey
> 
>     On 5/7/12 3:15 PM, EdShallow wrote:
>     > If I include the relevant CRL within a signature and then pass it
>     in for
>     > verification, will XMLsec check the signer certificate against that
>     > included CRL automatically as part of the Verify call?
>     >
>     > If so, how should the CRL be included in the signature structure?
>     >
>     > Thanks,
>     > Ed
>     >
>     > --
>     > Ed's Contact Information:
>     > Mobile Phone: 613-852-6410 <tel:613-852-6410>
>     > Gmail: ed.shallow at gmail.com <mailto:ed.shallow at gmail.com>
>     <mailto:ed.shallow at gmail.com <mailto:ed.shallow at gmail.com>>
>     > VOIP Address: 107529 at sip.ca1.voip.ms
>     <mailto:107529 at sip.ca1.voip.ms> <mailto:107529 at sip.ca1.voip.ms
>     <mailto:107529 at sip.ca1.voip.ms>>
>     > VOIP DID#: 613-458-5004 <tel:613-458-5004>
>     > Skype ID: edward.shallow
>     > Home Phone: 613-482-2090 <tel:613-482-2090>
>     >
>     >
>     >
>     > _______________________________________________
>     > xmlsec mailing list
>     > xmlsec at aleksey.com <mailto:xmlsec at aleksey.com>
>     > http://www.aleksey.com/mailman/listinfo/xmlsec
> 
> 
> 
> 
> -- 
> Ed's Contact Information:
> Mobile Phone: 613-852-6410
> Gmail: ed.shallow at gmail.com <mailto:ed.shallow at gmail.com>
> VOIP Address: 107529 at sip.ca1.voip.ms <mailto:107529 at sip.ca1.voip.ms>
> VOIP DID#: 613-458-5004
> Skype ID: edward.shallow
> Home Phone: 613-482-2090
> 

From fg at 4js.com  Thu May 10 02:07:40 2012
From: fg at 4js.com (Frank Gross)
Date: Thu, 10 May 2012 11:07:40 +0200
Subject: [xmlsec] XMLSEC_KEYINFO_FLAGS_KEYNAME_STOP_ON_UNKNOWN flag
In-Reply-To: <4F9B6A42.7080304@aleksey.com>
References: <4F99660C.6060601@4js.com> <4F996776.2040700@aleksey.com>
 <4F9A5CB2.10808@4js.com> <4F9B6A42.7080304@aleksey.com>
Message-ID: <4FAB855C.9050409@4js.com>

Hi, actually with that flag I want the xmlSecKeysMngrGetKey() to 
restrict the key lookup to the name only. For instance, I may have 
several keys of same type and key size in the key store but for 
different purpose. Without that flag, the manager tries to find a key 
that matches the key type and size, but then it may return a bad one, or 
am I wrong ?

Regards,
Frank

Le 28/04/2012 05:55, Aleksey Sanin a ?crit :
> Sorry, I am not sure I understand what you are trying to do with
> this patch. The xmlSecKeysMngrGetKey() already stops if the key
> is not found.
>
> Aleksey
>
> On 4/27/12 1:45 AM, Frank Gross wrote:
>> Hi, I modified the library to support that flag as following. It is
>> working for me, but I don't know if it is ok. Could you have a look and
>> tell me what you think ,thanks ?
>>
>> Modified: gws/branches/gws-ext-libs-2.50/lib-aleksey-xmlsec1/src/src/keys.c
>> ===================================================================
>> --- gws/branches/gws-ext-libs-2.50/lib-aleksey-xmlsec1/src/src/keys.c
>> 2012-04-26 16:10:31 UTC (rev 114254)
>> +++ gws/branches/gws-ext-libs-2.50/lib-aleksey-xmlsec1/src/src/keys.c
>> 2012-04-26 16:15:18 UTC (rev 114255)
>> @@ -1326,7 +1326,7 @@
>>    */
>>   xmlSecKeyPtr
>>   xmlSecKeysMngrGetKey(xmlNodePtr keyInfoNode, xmlSecKeyInfoCtxPtr
>> keyInfoCtx) {
>> -    xmlSecKeyPtr key;
>> +    xmlSecKeyPtr key,key2;
>>       int ret;
>>
>>       xmlSecAssert2(keyInfoCtx != NULL, NULL);
>> @@ -1361,23 +1361,30 @@
>>               return(key);
>>           }
>>       }
>> -    xmlSecKeyDestroy(key);
>>
>> -    /* if we have keys manager, try it */
>> -    if(keyInfoCtx->keysMngr != NULL) {
>> -        key = xmlSecKeysMngrFindKey(keyInfoCtx->keysMngr, NULL,
>> keyInfoCtx);
>> -        if(key == NULL) {
>> +    if (keyInfoCtx->keysMngr==NULL) {
>> +      xmlSecKeyDestroy(key);
>> +    } else {
>> +      /* if we have keys manager, try it */
>> +        if
>> (keyInfoCtx->flags&XMLSEC_KEYINFO_FLAGS_KEYNAME_STOP_ON_UNKNOWN) {
>> +          key2 = xmlSecKeysMngrFindKey(keyInfoCtx->keysMngr, key->name,
>> keyInfoCtx);
>> +        } else {
>> +          key2 = xmlSecKeysMngrFindKey(keyInfoCtx->keysMngr, NULL,
>> keyInfoCtx);
>> +        }
>> +        xmlSecKeyDestroy(key);
>> +        if(key2 == NULL) {
>>               xmlSecError(XMLSEC_ERRORS_HERE,
>>                           NULL,
>>                           "xmlSecKeysMngrFindKey",
>>                           XMLSEC_ERRORS_R_XMLSEC_FAILED,
>>                           XMLSEC_ERRORS_NO_MESSAGE);
>> +
>>               return(NULL);
>>           }
>> -        if(xmlSecKeyGetValue(key) != NULL) {
>> -            return(key);
>> +        if(xmlSecKeyGetValue(key2) != NULL) {
>> +            return(key2);
>>           }
>> -        xmlSecKeyDestroy(key);
>> +        xmlSecKeyDestroy(key2);
>>       }
>>
>>       xmlSecError(XMLSEC_ERRORS_HERE,
>>
>>
>> Frank
>>
>>
>> Le 26/04/2012 17:19, Aleksey Sanin a ?crit :
>>> Probably not.
>>>
>>> Aleksey
>>>
>>> On 4/26/12 8:13 AM, Frank Gross wrote:
>>>> Hi,
>>>>
>>>>    I would like to use the flag called
>>>> XMLSEC_KEYINFO_FLAGS_KEYNAME_STOP_ON_UNKNOWN, but it doesn't seem to
>>>> work. It is defined in keyinfo.h but nowhere else. Is this flag active ?
>>>>
>>>> Regards,
>>>>
>>>> Frank
>>>>

-- 
Frank GROSS
Software Engineer - Web Services
Four J's Development Tools - http://www.4js.com


From fg at 4js.com  Thu May 10 02:19:29 2012
From: fg at 4js.com (Frank Gross)
Date: Thu, 10 May 2012 11:19:29 +0200
Subject: [xmlsec] Windows compilation issue in debug mode
Message-ID: <4FAB8821.8080605@4js.com>

Hi,

   I found a minor issue on windows and in debug mode. The library must 
be linked with /MDd and not /MD otherwise the errno variable is not 
returned properly from one dll to another. See following patch :

Modified: gws/branches/gws-ext-libs-2.50/lib-aleksey-xmlsec1/src/win32/Makefile.msvc
===================================================================
--- gws/branches/gws-ext-libs-2.50/lib-aleksey-xmlsec1/src/win32/Makefile.msvc	2012-05-09 15:30:49 UTC (rev 114399)
+++ gws/branches/gws-ext-libs-2.50/lib-aleksey-xmlsec1/src/win32/Makefile.msvc	2012-05-09 15:59:48 UTC (rev 114400)
@@ -304,7 +304,7 @@
  #
  CC 			= cl.exe
  CFLAGS 			= /nologo /D "WIN32" /D "_WINDOWS"
-CFLAGS 			= $(CFLAGS) /D "_MBCS" /D "_REENTRANT"  /W1 /MD
+CFLAGS 			= $(CFLAGS) /D "_MBCS" /D "_REENTRANT"  /W1
  CFLAGS 			= $(CFLAGS) /I$(BASEDIR) /I$(BASEDIR)\include
  CFLAGS 			= $(CFLAGS) /I$(INCPREFIX)
  CFLAGS 			= $(CFLAGS) /D PACKAGE=\"$(XMLSEC_NAME)\"
@@ -318,9 +318,9 @@

  # Optimisation and debug symbols.
  !if "$(DEBUG)" == "1"
-CFLAGS 			= $(CFLAGS) /D "_DEBUG" /Od /Z7
+CFLAGS 			= $(CFLAGS) /D "_DEBUG" /Od /Z7 /MDd
  !else
-CFLAGS 			= $(CFLAGS) /D "NDEBUG" /O2
+CFLAGS 			= $(CFLAGS) /D "NDEBUG" /O2 /MD
  !endif
  


Frank

-- 
Frank GROSS
Software Engineer - Web Services
Four J's Development Tools - http://www.4js.com


From aleksey at aleksey.com  Thu May 10 07:49:43 2012
From: aleksey at aleksey.com (Aleksey Sanin)
Date: Thu, 10 May 2012 07:49:43 -0700
Subject: [xmlsec] XMLSEC_KEYINFO_FLAGS_KEYNAME_STOP_ON_UNKNOWN flag
In-Reply-To: <4FAB855C.9050409@4js.com>
References: <4F99660C.6060601@4js.com> <4F996776.2040700@aleksey.com>
 <4F9A5CB2.10808@4js.com> <4F9B6A42.7080304@aleksey.com>
 <4FAB855C.9050409@4js.com>
Message-ID: <4FABD587.205@aleksey.com>

Hm, I think this is exactly what "--enabled-key-data" xmlsec1
command line option does (see enabledKeyData member of KeyInfo).

Aleksey

On 5/10/12 2:07 AM, Frank Gross wrote:
> Hi, actually with that flag I want the xmlSecKeysMngrGetKey() to
> restrict the key lookup to the name only. For instance, I may have
> several keys of same type and key size in the key store but for
> different purpose. Without that flag, the manager tries to find a key
> that matches the key type and size, but then it may return a bad one, or
> am I wrong ?
> 
> Regards,
> Frank
> 
> Le 28/04/2012 05:55, Aleksey Sanin a ?crit :
>> Sorry, I am not sure I understand what you are trying to do with
>> this patch. The xmlSecKeysMngrGetKey() already stops if the key
>> is not found.
>>
>> Aleksey
>>
>> On 4/27/12 1:45 AM, Frank Gross wrote:
>>> Hi, I modified the library to support that flag as following. It is
>>> working for me, but I don't know if it is ok. Could you have a look and
>>> tell me what you think ,thanks ?
>>>
>>> Modified:
>>> gws/branches/gws-ext-libs-2.50/lib-aleksey-xmlsec1/src/src/keys.c
>>> ===================================================================
>>> --- gws/branches/gws-ext-libs-2.50/lib-aleksey-xmlsec1/src/src/keys.c
>>> 2012-04-26 16:10:31 UTC (rev 114254)
>>> +++ gws/branches/gws-ext-libs-2.50/lib-aleksey-xmlsec1/src/src/keys.c
>>> 2012-04-26 16:15:18 UTC (rev 114255)
>>> @@ -1326,7 +1326,7 @@
>>>    */
>>>   xmlSecKeyPtr
>>>   xmlSecKeysMngrGetKey(xmlNodePtr keyInfoNode, xmlSecKeyInfoCtxPtr
>>> keyInfoCtx) {
>>> -    xmlSecKeyPtr key;
>>> +    xmlSecKeyPtr key,key2;
>>>       int ret;
>>>
>>>       xmlSecAssert2(keyInfoCtx != NULL, NULL);
>>> @@ -1361,23 +1361,30 @@
>>>               return(key);
>>>           }
>>>       }
>>> -    xmlSecKeyDestroy(key);
>>>
>>> -    /* if we have keys manager, try it */
>>> -    if(keyInfoCtx->keysMngr != NULL) {
>>> -        key = xmlSecKeysMngrFindKey(keyInfoCtx->keysMngr, NULL,
>>> keyInfoCtx);
>>> -        if(key == NULL) {
>>> +    if (keyInfoCtx->keysMngr==NULL) {
>>> +      xmlSecKeyDestroy(key);
>>> +    } else {
>>> +      /* if we have keys manager, try it */
>>> +        if
>>> (keyInfoCtx->flags&XMLSEC_KEYINFO_FLAGS_KEYNAME_STOP_ON_UNKNOWN) {
>>> +          key2 = xmlSecKeysMngrFindKey(keyInfoCtx->keysMngr, key->name,
>>> keyInfoCtx);
>>> +        } else {
>>> +          key2 = xmlSecKeysMngrFindKey(keyInfoCtx->keysMngr, NULL,
>>> keyInfoCtx);
>>> +        }
>>> +        xmlSecKeyDestroy(key);
>>> +        if(key2 == NULL) {
>>>               xmlSecError(XMLSEC_ERRORS_HERE,
>>>                           NULL,
>>>                           "xmlSecKeysMngrFindKey",
>>>                           XMLSEC_ERRORS_R_XMLSEC_FAILED,
>>>                           XMLSEC_ERRORS_NO_MESSAGE);
>>> +
>>>               return(NULL);
>>>           }
>>> -        if(xmlSecKeyGetValue(key) != NULL) {
>>> -            return(key);
>>> +        if(xmlSecKeyGetValue(key2) != NULL) {
>>> +            return(key2);
>>>           }
>>> -        xmlSecKeyDestroy(key);
>>> +        xmlSecKeyDestroy(key2);
>>>       }
>>>
>>>       xmlSecError(XMLSEC_ERRORS_HERE,
>>>
>>>
>>> Frank
>>>
>>>
>>> Le 26/04/2012 17:19, Aleksey Sanin a ?crit :
>>>> Probably not.
>>>>
>>>> Aleksey
>>>>
>>>> On 4/26/12 8:13 AM, Frank Gross wrote:
>>>>> Hi,
>>>>>
>>>>>    I would like to use the flag called
>>>>> XMLSEC_KEYINFO_FLAGS_KEYNAME_STOP_ON_UNKNOWN, but it doesn't seem to
>>>>> work. It is defined in keyinfo.h but nowhere else. Is this flag
>>>>> active ?
>>>>>
>>>>> Regards,
>>>>>
>>>>> Frank
>>>>>
> 

From aleksey at aleksey.com  Thu May 10 07:50:01 2012
From: aleksey at aleksey.com (Aleksey Sanin)
Date: Thu, 10 May 2012 07:50:01 -0700
Subject: [xmlsec] Windows compilation issue in debug mode
In-Reply-To: <4FAB8821.8080605@4js.com>
References: <4FAB8821.8080605@4js.com>
Message-ID: <4FABD599.3010304@aleksey.com>

Thanks

Aleksey

On 5/10/12 2:19 AM, Frank Gross wrote:
> Hi,
> 
>   I found a minor issue on windows and in debug mode. The library must
> be linked with /MDd and not /MD otherwise the errno variable is not
> returned properly from one dll to another. See following patch :
> 
> Modified:
> gws/branches/gws-ext-libs-2.50/lib-aleksey-xmlsec1/src/win32/Makefile.msvc
> ===================================================================
> ---
> gws/branches/gws-ext-libs-2.50/lib-aleksey-xmlsec1/src/win32/Makefile.msvc   
> 2012-05-09 15:30:49 UTC (rev 114399)
> +++
> gws/branches/gws-ext-libs-2.50/lib-aleksey-xmlsec1/src/win32/Makefile.msvc   
> 2012-05-09 15:59:48 UTC (rev 114400)
> @@ -304,7 +304,7 @@
>  #
>  CC             = cl.exe
>  CFLAGS             = /nologo /D "WIN32" /D "_WINDOWS"
> -CFLAGS             = $(CFLAGS) /D "_MBCS" /D "_REENTRANT"  /W1 /MD
> +CFLAGS             = $(CFLAGS) /D "_MBCS" /D "_REENTRANT"  /W1
>  CFLAGS             = $(CFLAGS) /I$(BASEDIR) /I$(BASEDIR)\include
>  CFLAGS             = $(CFLAGS) /I$(INCPREFIX)
>  CFLAGS             = $(CFLAGS) /D PACKAGE=\"$(XMLSEC_NAME)\"
> @@ -318,9 +318,9 @@
> 
>  # Optimisation and debug symbols.
>  !if "$(DEBUG)" == "1"
> -CFLAGS             = $(CFLAGS) /D "_DEBUG" /Od /Z7
> +CFLAGS             = $(CFLAGS) /D "_DEBUG" /Od /Z7 /MDd
>  !else
> -CFLAGS             = $(CFLAGS) /D "NDEBUG" /O2
> +CFLAGS             = $(CFLAGS) /D "NDEBUG" /O2 /MD
>  !endif
>  
> 
> 
> Frank
> 

From duzenbury at gmail.com  Mon May 14 11:58:35 2012
From: duzenbury at gmail.com (Rich Duzenbury)
Date: Mon, 14 May 2012 13:58:35 -0500
Subject: [xmlsec] How to control C14N
Message-ID: <CAHjw83h+R08L4fZ8S5hU2SSUWhEnJ3PiXth4H+hDDg_hvDzvRA@mail.gmail.com>

Hi,

I'm attempting to generate an identity provider assertion that will
work with RSA FIM.

Here is a recent assertion, ready to be signed:
http://pastie.org/private/gobkuozf0asjpqw3rekavq

Here is that same assertion, signed:
http://pastie.org/private/yrrlqgxqcwkn7tqorva44a

I use xmlsec to do the signing. ?I can validate the signature via
xmlsec. ?That is to say, the validation runs and returns a good
result. ?If I change a byte in the output document, the signature
validation fails, as should be expected. ?However, RSA FIM doesn't
like it, and throws a NULL exception.  I don't have access to more
than a stack trace.

I have doubt about whether I set up the signature block correctly.
Here is my <signature> template:

		<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#"/>
				<ds:SignatureMethod Algorithm="http://www.w3.org/2000/09/xmldsig#rsa-sha1"/>
				<ds:Reference URI="">
					<ds:Transforms>
						<ds:Transform
Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature"/>
						<ds:Transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>
					</ds:Transforms>
					<ds:DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/>
					<ds:DigestValue></ds:DigestValue>
				</ds:Reference>
			</ds:SignedInfo>
			<ds:SignatureValue></ds:SignatureValue>
			<ds:KeyInfo>
				<ds:X509Data>
					<ds:X509Certificate></ds:X509Certificate>
				</ds:X509Data>
			</ds:KeyInfo>
		</ds:Signature>

I presume enveloped signature means to sign the whole message, right?
Is it enough to simply include <ds:Transform
Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/> in the signature
method, and the conicalization will magically be done by the library?
Or do I have to signal xmlsec to do it in some way? or does it have to
be done with a different tool before the signing is completed?  Have I
built this correctly?

I'm using the command line for now, by the way, if that makes any real
difference.

--
Thank you.

Regards,
Rich

From aleksey at aleksey.com  Tue May 15 21:02:59 2012
From: aleksey at aleksey.com (Aleksey Sanin)
Date: Tue, 15 May 2012 21:02:59 -0700
Subject: [xmlsec] How to control C14N
In-Reply-To: <CAHjw83h+R08L4fZ8S5hU2SSUWhEnJ3PiXth4H+hDDg_hvDzvRA@mail.gmail.com>
References: <CAHjw83h+R08L4fZ8S5hU2SSUWhEnJ3PiXth4H+hDDg_hvDzvRA@mail.gmail.com>
Message-ID: <4FB326F3.3030201@aleksey.com>

You probably want to contact RSA FIM to figure out what this
exception means.

Aleksey

On 5/14/12 11:58 AM, Rich Duzenbury wrote:
> Hi,
> 
> I'm attempting to generate an identity provider assertion that will
> work with RSA FIM.
> 
> Here is a recent assertion, ready to be signed:
> http://pastie.org/private/gobkuozf0asjpqw3rekavq
> 
> Here is that same assertion, signed:
> http://pastie.org/private/yrrlqgxqcwkn7tqorva44a
> 
> I use xmlsec to do the signing.  I can validate the signature via
> xmlsec.  That is to say, the validation runs and returns a good
> result.  If I change a byte in the output document, the signature
> validation fails, as should be expected.  However, RSA FIM doesn't
> like it, and throws a NULL exception.  I don't have access to more
> than a stack trace.
> 
> I have doubt about whether I set up the signature block correctly.
> Here is my <signature> template:
> 
> 		<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#"/>
> 				<ds:SignatureMethod Algorithm="http://www.w3.org/2000/09/xmldsig#rsa-sha1"/>
> 				<ds:Reference URI="">
> 					<ds:Transforms>
> 						<ds:Transform
> Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature"/>
> 						<ds:Transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>
> 					</ds:Transforms>
> 					<ds:DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/>
> 					<ds:DigestValue></ds:DigestValue>
> 				</ds:Reference>
> 			</ds:SignedInfo>
> 			<ds:SignatureValue></ds:SignatureValue>
> 			<ds:KeyInfo>
> 				<ds:X509Data>
> 					<ds:X509Certificate></ds:X509Certificate>
> 				</ds:X509Data>
> 			</ds:KeyInfo>
> 		</ds:Signature>
> 
> I presume enveloped signature means to sign the whole message, right?
> Is it enough to simply include <ds:Transform
> Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/> in the signature
> method, and the conicalization will magically be done by the library?
> Or do I have to signal xmlsec to do it in some way? or does it have to
> be done with a different tool before the signing is completed?  Have I
> built this correctly?
> 
> I'm using the command line for now, by the way, if that makes any real
> difference.
> 
> --
> Thank you.
> 
> Regards,
> Rich
> _______________________________________________
> xmlsec mailing list
> xmlsec at aleksey.com
> http://www.aleksey.com/mailman/listinfo/xmlsec

From duzenbury at gmail.com  Wed May 16 06:40:47 2012
From: duzenbury at gmail.com (Rich Duzenbury)
Date: Wed, 16 May 2012 08:40:47 -0500
Subject: [xmlsec] How to control C14N
In-Reply-To: <4FB326F3.3030201@aleksey.com>
References: <CAHjw83h+R08L4fZ8S5hU2SSUWhEnJ3PiXth4H+hDDg_hvDzvRA@mail.gmail.com>
 <4FB326F3.3030201@aleksey.com>
Message-ID: <CAHjw83jLMgEryNQgot54hgZ8kXF+u4KZoiaeM8eH-g5knVaCAw@mail.gmail.com>

On Tue, May 15, 2012 at 11:02 PM, Aleksey Sanin <aleksey at aleksey.com> wrote:
> You probably want to contact RSA FIM to figure out what this
> exception means.

RSA responded with: You must get the partner to change so that they
are signing the responses only.

Based on the template I mentioned previously, and the fact that the
reference URI is emtpy, doesn't that mean that I'm signing the entire
response? ?As a test, I used the online validator successfully. ?If I
update the issueinstant in the <response> tag, the validator then
fails the message as I expect.

I'm still unclear on the following, as well:

I presume enveloped signature means to sign the whole message, right?
Is it enough to simply include <ds:Transform
Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/> in the signature
method, and the conicalization will magically be done by the library?
Or do I have to signal xmlsec to do it in some way? or does it have
tobe done with a different tool before the signing is completed?

Thank you.

Regards,
Rich

From aleksey at aleksey.com  Wed May 16 06:59:13 2012
From: aleksey at aleksey.com (Aleksey Sanin)
Date: Wed, 16 May 2012 06:59:13 -0700
Subject: [xmlsec] How to control C14N
In-Reply-To: <CAHjw83jLMgEryNQgot54hgZ8kXF+u4KZoiaeM8eH-g5knVaCAw@mail.gmail.com>
References: <CAHjw83h+R08L4fZ8S5hU2SSUWhEnJ3PiXth4H+hDDg_hvDzvRA@mail.gmail.com>
 <4FB326F3.3030201@aleksey.com>
 <CAHjw83jLMgEryNQgot54hgZ8kXF+u4KZoiaeM8eH-g5knVaCAw@mail.gmail.com>
Message-ID: <4FB3B2B1.7070904@aleksey.com>

Take a look at xmlsec command line help. There are bunch
of options that allow you to dump the exact content before
digest/signature/verification so you will know exactly
what was digested or signed.

Aleksey

On 5/16/12 6:40 AM, Rich Duzenbury wrote:
> On Tue, May 15, 2012 at 11:02 PM, Aleksey Sanin <aleksey at aleksey.com> wrote:
>> You probably want to contact RSA FIM to figure out what this
>> exception means.
> 
> RSA responded with: You must get the partner to change so that they
> are signing the responses only.
> 
> Based on the template I mentioned previously, and the fact that the
> reference URI is emtpy, doesn't that mean that I'm signing the entire
> response?  As a test, I used the online validator successfully.  If I
> update the issueinstant in the <response> tag, the validator then
> fails the message as I expect.
> 
> I'm still unclear on the following, as well:
> 
> I presume enveloped signature means to sign the whole message, right?
> Is it enough to simply include <ds:Transform
> Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/> in the signature
> method, and the conicalization will magically be done by the library?
> Or do I have to signal xmlsec to do it in some way? or does it have
> tobe done with a different tool before the signing is completed?
> 
> Thank you.
> 
> Regards,
> Rich
> _______________________________________________
> xmlsec mailing list
> xmlsec at aleksey.com
> http://www.aleksey.com/mailman/listinfo/xmlsec

From ranier_gyn at hotmail.com  Wed May 23 03:08:46 2012
From: ranier_gyn at hotmail.com (Ranier VF)
Date: Wed, 23 May 2012 10:08:46 +0000
Subject: [xmlsec] dsigCtx->c14nMethod
Message-ID: <BAY145-W22CD6789FCA51AB319F0CDE3030@phx.gbl>


Hi, can you help me?
The xml file:
<?xml version="1.0"?>
<!DOCTYPE test [<!ATTLIST infNFe Id ID #IMPLIED>]>
<NFe xmlns="http://www.portalfiscal.inf.br/nfe"><infNFe versao="2.00" Id="NFe52120503241828000120550020000067501112798840">
..........
</infNFe>
<Signature xmlns="http://www.w3.org/2000/09/xmldsig#">
  <SignedInfo>
    <CanonicalizationMethod Algorithm="http://www.w3.org/TR/2001/REC-xml-c14n-20010315"/>
    <SignatureMethod Algorithm="http://www.w3.org/2000/09/xmldsig#rsa-sha1"/>
    <Reference URI="#NFe52120503241828000120550020000067501112798840">
      <Transforms>
        <Transform Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature"/>
        <Transform Algorithm="http://www.w3.org/TR/2001/REC-xml-c14n-20010315"/>
      </Transforms>
      <DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/>
      <DigestValue/>
    </Reference>
  </SignedInfo>
  <SignatureValue/>
  <KeyInfo>
    <X509Data>
      <X509Certificate/>
    </X509Data>
  </KeyInfo>
</Signature></NFe>

With command line tool:
xmlsec --sign --print-debug --output nfe_sign.xml --pkcs12 sos.p12 --pwd XXXXXXXX nfe3.xml
All Works.

= SIGNATURE CONTEXT
== Status: succeeded
== flags: 0x00000000
== flags2: 0x00000000
== Key Info Read Ctx:
= KEY INFO READ CONTEXT
== flags: 0x00000000
== flags2: 0x00000000
== enabled key data: all
== RetrievalMethod level (cur/max): 0/1
== TRANSFORMS CTX (status=0)
== flags: 0x00000000
== flags2: 0x00000000
== enabled transforms: all
=== uri: NULL
=== uri xpointer expr: NULL
== EncryptedKey level (cur/max): 0/1
=== KeyReq:
==== keyId: rsa
==== keyType: 0x00000002
==== keyUsage: 0x00000001
==== keyBitsSize: 0
=== list size: 0
== Key Info Write Ctx:
= KEY INFO WRITE CONTEXT
== flags: 0x00000000
== flags2: 0x00000000
== enabled key data: all
== RetrievalMethod level (cur/max): 0/1
== TRANSFORMS CTX (status=0)
== flags: 0x00000000
== flags2: 0x00000000
== enabled transforms: all
=== uri: NULL
=== uri xpointer expr: NULL
== EncryptedKey level (cur/max): 0/1
=== KeyReq:
==== keyId: NULL
==== keyType: 0x00000001
==== keyUsage: 0xffffffff
==== keyBitsSize: 0
=== list size: 0
== Signature Transform Ctx:
== TRANSFORMS CTX (status=2)
== flags: 0x00000000
== flags2: 0x00000000
== enabled transforms: all
=== uri: NULL
=== uri xpointer expr: NULL
=== Transform: c14n (href=http://www.w3.org/TR/2001/REC-xml-c14n-20010315)
=== Transform: rsa-sha1 (href=http://www.w3.org/2000/09/xmldsig#rsa-sha1)
=== Transform: base64 (href=http://www.w3.org/2000/09/xmldsig#base64)
=== Transform: membuf-transform (href=NULL)
== Signature Method:
=== Transform: rsa-sha1 (href=http://www.w3.org/2000/09/xmldsig#rsa-sha1)
== Signature Key:
== KEY
=== method: RSAKeyValue
=== key type: Private
=== key usage: -1
=== rsa key: size = 2048
=== list size: 1
=== X509 Data:
==== Key Certificate:
==== Subject Name: /C=BR/O=ICP-Brasil/OU=Secretaria da Receita Federal do Brasil - RFB/OU=CORREIOS/OU=ARCORREIOS/OU=RFB e-CNPJ A1/L=GOIANIA/ST=GO/CN=S O S COMERCIO DE MAQUINAS LTDA ME:01800246000100
==== Issuer Name: /C=BR/O=ICP-Brasil/OU=Secretaria da Receita Federal do Brasil - RFB/CN=Autoridade Certificadora do SERPRORFB
==== Issuer Serial: 32303131303931323139303131363337
==== Certificate:
==== Subject Name: /C=BR/O=ICP-Brasil/OU=Secretaria da Receita Federal do Brasil - RFB/OU=CORREIOS/OU=ARCORREIOS/OU=RFB e-CNPJ A1/L=GOIANIA/ST=GO/CN=S O S COMERCIO DE MAQUINAS LTDA ME:01800246000100
==== Issuer Name: /C=BR/O=ICP-Brasil/OU=Secretaria da Receita Federal do Brasil - RFB/CN=Autoridade Certificadora do SERPRORFB
==== Issuer Serial: 32303131303931323139303131363337
== SignedInfo References List:
=== list size: 1
= REFERENCE CALCULATION CONTEXT
== Status: succeeded
== URI: "#NFe52120503241828000120550020000067501112798840"
== Reference Transform Ctx:
== TRANSFORMS CTX (status=2)
== flags: 0x00000000
== flags2: 0x00000000
== enabled transforms: all
=== uri:
=== uri xpointer expr: #NFe52120503241828000120550020000067501112798840
=== Transform: xpointer (href=http://www.w3.org/2001/04/xmldsig-more/xptr)
=== Transform: enveloped-signature (href=http://www.w3.org/2000/09/xmldsig#enveloped-signature)
=== Transform: c14n (href=http://www.w3.org/TR/2001/REC-xml-c14n-20010315)
=== Transform: sha1 (href=http://www.w3.org/2000/09/xmldsig#sha1)
=== Transform: base64 (href=http://www.w3.org/2000/09/xmldsig#base64)
=== Transform: membuf-transform (href=NULL)
== Digest Method:
=== Transform: sha1 (href=http://www.w3.org/2000/09/xmldsig#sha1)
== Result - start buffer:
hn6gfGRWNBeR+CE6QQEU01E8e6A=
== Result - end buffer
== Manifest References List:
=== list size: 0
== Result - start buffer:
c3hAUplnTN5WuP4nSW327q20JEiKjWj/p9tLY9thHw9RoUJcj/TDkG2zEZUn219i
vax5RMDmfk7T3HuBqg2xtEe6TxBRBlcECeQJz6BGj2xfbwLRqBAfR9gDEha+qpXu
7aJvvxCBps8szV2je1ThWPXSZx274NYz5uDdnGv+h6bVBbb30aMqK+/mUlwe4/Bp
y58RKdoQC7RVQ4S3qiZ1cKGrfoPdhN73qsDjJhVub2a152n8qDwzEbM+ajUhX7Aa
BC99E3On9goJ7T0uz+RuHgLptRhrdaSQTZOl5pRgvFPKOfKeyX6svVHU3Kly+Q6t
Zx/edQpvMu8lp63lqa/u5g==
== Result - end buffer

But the same file: nfe3.xml with:
xml_sign(const char *tmpl_file, const char *key_file, const char *password1)
{
    xmlDocPtr doc = NULL;
    xmlNodePtr node = NULL;
    xmlSecDSigCtxPtr dsigCtx = NULL;

    /* load template */
    doc = xmlParseFile(tmpl_file);
    if ((doc == NULL) || (xmlDocGetRootElement(doc) == NULL))
    {
       fprintf(stderr, "Error: unable to parse file \"%s\"\n", tmpl_file);
       goto done;     
    }
   
    /* find start node */
    node = xmlSecFindNode(xmlDocGetRootElement(doc), xmlSecNodeSignature, xmlSecDSigNs);
    if (node == NULL)
    {
          fprintf(stderr, "Error: start node not found in \"%s\"\n", tmpl_file);
          goto done;
    }

    /* create signature context, we don't need keys manager in this example */
    dsigCtx = xmlSecDSigCtxCreate(NULL);
    if (dsigCtx == NULL)
    {
       fprintf(stderr,"Error: failed to create signature context\n");
       goto done;
    }

    /* load private key with password */
    dsigCtx->signKey = xmlSecCryptoAppKeyLoad(key_file, xmlSecKeyDataFormatPkcs12, password1, NULL, NULL);
    if (dsigCtx->signKey == NULL)
    {
       fprintf(stderr,"Error: failed to load private pem key from \"%s\"\n", key_file);
       goto done;
    }

    /* set key name to the file name, this is just an example! */
    if (xmlSecKeySetName(dsigCtx->signKey, (xmlChar *) key_file) < 0)
    {
       fprintf(stderr,"Error: failed to set key name for key from \"%s\"\n", key_file);
       goto done;
    }

    /* sign the template */
    if (xmlSecDSigCtxSign(dsigCtx, node) < 0)   <---- FAILL
    {
       fprintf(stderr, xmlSecErrorsGetMsg(xmlSecErrorsGetCode(0)));
       goto done;
    }
}

Not work! Result:
func=xmlSecDSigCtxProcessSignatureNode:file=..\src\xmldsig.c:line=465:ob
j=unknown:subj=dsigCtx->c14nMethod == NULL:error=100:assertion:
func=xmlSecDSigCtxSign:file=..\src\xmldsig.c:line=303:obj=unknown:subj=x
mlSecDSigCtxSigantureProcessNode:error=1:xmlsec library function failed:Latest dlls from http://www.zlatkovic.com/libxml.en.html
xmlsec-1.2.18
libxml2-2.7.8
openssl-0.8a

Is necessary a key manager?

Thanks for your patience.
Any help will much appreciate.

Best regards,

Ranier Vilela
 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.aleksey.com/pipermail/xmlsec/attachments/20120523/32ae2ba9/attachment.html>

From aleksey at aleksey.com  Wed May 23 06:14:41 2012
From: aleksey at aleksey.com (Aleksey Sanin)
Date: Wed, 23 May 2012 06:14:41 -0700
Subject: [xmlsec] dsigCtx->c14nMethod
In-Reply-To: <BAY145-W22CD6789FCA51AB319F0CDE3030@phx.gbl>
References: <BAY145-W22CD6789FCA51AB319F0CDE3030@phx.gbl>
Message-ID: <4FBCE2C1.1050500@aleksey.com>

Check if you find the node correctly with xmlSecFindNode

Aleksey

On 5/23/12 3:08 AM, Ranier VF wrote:
> Hi, can you help me?
> The xml file:
> <?xml version="1.0"?>
> <!DOCTYPE test [<!ATTLIST infNFe Id ID #IMPLIED>]>
> <NFe xmlns="http://www.portalfiscal.inf.br/nfe"><infNFe versao="2.00"
> Id="NFe52120503241828000120550020000067501112798840">
> ..........
> </infNFe>
> <Signature xmlns="http://www.w3.org/2000/09/xmldsig#">
>   <SignedInfo>
>     <CanonicalizationMethod
> Algorithm="http://www.w3.org/TR/2001/REC-xml-c14n-20010315"/>
>     <SignatureMethod
> Algorithm="http://www.w3.org/2000/09/xmldsig#rsa-sha1"/>
>     <Reference URI="#NFe52120503241828000120550020000067501112798840">
>       <Transforms>
>         <Transform
> Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature"/>
>         <Transform
> Algorithm="http://www.w3.org/TR/2001/REC-xml-c14n-20010315"/>
>       </Transforms>
>       <DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/>
>       <DigestValue/>
>     </Reference>
>   </SignedInfo>
>   <SignatureValue/>
>   <KeyInfo>
>     <X509Data>
>       <X509Certificate/>
>     </X509Data>
>   </KeyInfo>
> </Signature></NFe>
> 
> With command line tool:
> xmlsec --sign --print-debug --output nfe_sign.xml --pkcs12 sos.p12 --pwd
> XXXXXXXX nfe3.xml
> All Works.
> 
> = SIGNATURE CONTEXT
> == Status: succeeded
> == flags: 0x00000000
> == flags2: 0x00000000
> == Key Info Read Ctx:
> = KEY INFO READ CONTEXT
> == flags: 0x00000000
> == flags2: 0x00000000
> == enabled key data: all
> == RetrievalMethod level (cur/max): 0/1
> == TRANSFORMS CTX (status=0)
> == flags: 0x00000000
> == flags2: 0x00000000
> == enabled transforms: all
> === uri: NULL
> === uri xpointer expr: NULL
> == EncryptedKey level (cur/max): 0/1
> === KeyReq:
> ==== keyId: rsa
> ==== keyType: 0x00000002
> ==== keyUsage: 0x00000001
> ==== keyBitsSize: 0
> === list size: 0
> == Key Info Write Ctx:
> = KEY INFO WRITE CONTEXT
> == flags: 0x00000000
> == flags2: 0x00000000
> == enabled key data: all
> == RetrievalMethod level (cur/max): 0/1
> == TRANSFORMS CTX (status=0)
> == flags: 0x00000000
> == flags2: 0x00000000
> == enabled transforms: all
> === uri: NULL
> === uri xpointer expr: NULL
> == EncryptedKey level (cur/max): 0/1
> === KeyReq:
> ==== keyId: NULL
> ==== keyType: 0x00000001
> ==== keyUsage: 0xffffffff
> ==== keyBitsSize: 0
> === list size: 0
> == Signature Transform Ctx:
> == TRANSFORMS CTX (status=2)
> == flags: 0x00000000
> == flags2: 0x00000000
> == enabled transforms: all
> === uri: NULL
> === uri xpointer expr: NULL
> === Transform: c14n (href=http://www.w3.org/TR/2001/REC-xml-c14n-20010315)
> === Transform: rsa-sha1 (href=http://www.w3.org/2000/09/xmldsig#rsa-sha1)
> === Transform: base64 (href=http://www.w3.org/2000/09/xmldsig#base64)
> === Transform: membuf-transform (href=NULL)
> == Signature Method:
> === Transform: rsa-sha1 (href=http://www.w3.org/2000/09/xmldsig#rsa-sha1)
> == Signature Key:
> == KEY
> === method: RSAKeyValue
> === key type: Private
> === key usage: -1
> === rsa key: size = 2048
> === list size: 1
> === X509 Data:
> ==== Key Certificate:
> ==== Subject Name: /C=BR/O=ICP-Brasil/OU=Secretaria da Receita Federal
> do Brasil - RFB/OU=CORREIOS/OU=ARCORREIOS/OU=RFB e-CNPJ
> A1/L=GOIANIA/ST=GO/CN=S O S COMERCIO DE MAQUINAS LTDA ME:01800246000100
> ==== Issuer Name: /C=BR/O=ICP-Brasil/OU=Secretaria da Receita Federal do
> Brasil - RFB/CN=Autoridade Certificadora do SERPRORFB
> ==== Issuer Serial: 32303131303931323139303131363337
> ==== Certificate:
> ==== Subject Name: /C=BR/O=ICP-Brasil/OU=Secretaria da Receita Federal
> do Brasil - RFB/OU=CORREIOS/OU=ARCORREIOS/OU=RFB e-CNPJ
> A1/L=GOIANIA/ST=GO/CN=S O S COMERCIO DE MAQUINAS LTDA ME:01800246000100
> ==== Issuer Name: /C=BR/O=ICP-Brasil/OU=Secretaria da Receita Federal do
> Brasil - RFB/CN=Autoridade Certificadora do SERPRORFB
> ==== Issuer Serial: 32303131303931323139303131363337
> == SignedInfo References List:
> === list size: 1
> = REFERENCE CALCULATION CONTEXT
> == Status: succeeded
> == URI: "#NFe52120503241828000120550020000067501112798840"
> == Reference Transform Ctx:
> == TRANSFORMS CTX (status=2)
> == flags: 0x00000000
> == flags2: 0x00000000
> == enabled transforms: all
> === uri:
> === uri xpointer expr: #NFe52120503241828000120550020000067501112798840
> === Transform: xpointer (href=http://www.w3.org/2001/04/xmldsig-more/xptr)
> === Transform: enveloped-signature
> (href=http://www.w3.org/2000/09/xmldsig#enveloped-signature)
> === Transform: c14n (href=http://www.w3.org/TR/2001/REC-xml-c14n-20010315)
> === Transform: sha1 (href=http://www.w3.org/2000/09/xmldsig#sha1)
> === Transform: base64 (href=http://www.w3.org/2000/09/xmldsig#base64)
> === Transform: membuf-transform (href=NULL)
> == Digest Method:
> === Transform: sha1 (href=http://www.w3.org/2000/09/xmldsig#sha1)
> == Result - start buffer:
> hn6gfGRWNBeR+CE6QQEU01E8e6A=
> == Result - end buffer
> == Manifest References List:
> === list size: 0
> == Result - start buffer:
> c3hAUplnTN5WuP4nSW327q20JEiKjWj/p9tLY9thHw9RoUJcj/TDkG2zEZUn219i
> vax5RMDmfk7T3HuBqg2xtEe6TxBRBlcECeQJz6BGj2xfbwLRqBAfR9gDEha+qpXu
> 7aJvvxCBps8szV2je1ThWPXSZx274NYz5uDdnGv+h6bVBbb30aMqK+/mUlwe4/Bp
> y58RKdoQC7RVQ4S3qiZ1cKGrfoPdhN73qsDjJhVub2a152n8qDwzEbM+ajUhX7Aa
> BC99E3On9goJ7T0uz+RuHgLptRhrdaSQTZOl5pRgvFPKOfKeyX6svVHU3Kly+Q6t
> Zx/edQpvMu8lp63lqa/u5g==
> == Result - end buffer
> 
> But the same file: nfe3.xml with:
> xml_sign(const char *tmpl_file, const char *key_file, const char *password1)
> {
>     xmlDocPtr doc = NULL;
>     xmlNodePtr node = NULL;
>     xmlSecDSigCtxPtr dsigCtx = NULL;
> 
>     /* load template */
>     doc = xmlParseFile(tmpl_file);
>     if ((doc == NULL) || (xmlDocGetRootElement(doc) == NULL))
>     {
>        fprintf(stderr, "Error: unable to parse file \"%s\"\n", tmpl_file);
>        goto done;     
>     }
>    
>     /* find start node */
>     node = xmlSecFindNode(xmlDocGetRootElement(doc),
> xmlSecNodeSignature, xmlSecDSigNs);
>     if (node == NULL)
>     {
>           fprintf(stderr, "Error: start node not found in \"%s\"\n",
> tmpl_file);
>           goto done;
>     }
> 
>     /* create signature context, we don't need keys manager in this
> example */
>     dsigCtx = xmlSecDSigCtxCreate(NULL);
>     if (dsigCtx == NULL)
>     {
>        fprintf(stderr,"Error: failed to create signature context\n");
>        goto done;
>     }
> 
>     /* load private key with password */
>     dsigCtx->signKey = xmlSecCryptoAppKeyLoad(key_file,
> xmlSecKeyDataFormatPkcs12, password1, NULL, NULL);
>     if (dsigCtx->signKey == NULL)
>     {
>        fprintf(stderr,"Error: failed to load private pem key from
> \"%s\"\n", key_file);
>        goto done;
>     }
> 
>     /* set key name to the file name, this is just an example! */
>     if (xmlSecKeySetName(dsigCtx->signKey, (xmlChar *) key_file) < 0)
>     {
>        fprintf(stderr,"Error: failed to set key name for key from
> \"%s\"\n", key_file);
>        goto done;
>     }
> 
>     /* sign the template */
>     if (xmlSecDSigCtxSign(dsigCtx, node) < 0)   <---- FAILL
>     {
>        fprintf(stderr, xmlSecErrorsGetMsg(xmlSecErrorsGetCode(0)));
>        goto done;
>     }
> }
> 
> Not work! Result:
> 
> func=xmlSecDSigCtxProcessSignatureNode:file=..\src\xmldsig.c:line=465:ob
> j=unknown:subj=dsigCtx->c14nMethod == NULL:error=100:assertion:
> func=xmlSecDSigCtxSign:file=..\src\xmldsig.c:line=303:obj=unknown:subj=x
> mlSecDSigCtxSigantureProcessNode:error=1:xmlsec library function failed:
> 
> Latest dlls from http://www.zlatkovic.com/libxml.en.html
> xmlsec-1.2.18
> libxml2-2.7.8
> openssl-0.8a
> 
> Is necessary a key manager?
> 
> Thanks for your patience.
> Any help will much appreciate.
> 
> Best regards,
> 
> Ranier Vilela
> 
> 
> _______________________________________________
> xmlsec mailing list
> xmlsec at aleksey.com
> http://www.aleksey.com/mailman/listinfo/xmlsec

From vit_zikmund at cz.ibm.com  Wed May 23 08:28:37 2012
From: vit_zikmund at cz.ibm.com (Vit Zikmund)
Date: Wed, 23 May 2012 17:28:37 +0200
Subject: [xmlsec] Support for really large XML documents
Message-ID: <OF6B85B7C1.7DCA0500-ONC1257A07.00515105-C1257A07.0055072F@cz.ibm.com>

Hello,
we are trying to use the XMLSec utility to verify documents signed with 
our own application and probably have hit a limit of the document size, 
that XMLSec is able to process.

The simplest question is: Does XMLSec support handling large 
documents/files? Is is about to? For large I mean 2 gigabytes and more.

I can verify a document of 1GB, but little over 2GB returns an error:

func=xmlSecTransformC14NPushXml:file=c14n.c:line=279:obj=c14n:subj=xmlOutputBufferClose:error=5:libxml2 
library function failed: 
func=xmlSecTransformDefaultPushXml:file=transforms.c:line=2417:obj=enveloped-signature:subj=xmlSecTransformPushXml:error=1:xmlsec 
library function failed: 
func=xmlSecTransformCtxXmlExecute:file=transforms.c:line=1236:obj=unknown:subj=xmlSecTransformPushXml:error=1:xmlsec 
library function failed:transform=enveloped-signature
func=xmlSecTransformCtxExecute:file=transforms.c:line=1296:obj=unknown:subj=xmlSecTransformCtxXmlExecute:error=1:xmlsec 
library function failed: 
func=xmlSecDSigReferenceCtxProcessNode:file=xmldsig.c:line=1571:obj=unknown:subj=xmlSecTransformCtxExecute:error=1:xmlsec 
library function failed: 
func=xmlSecDSigCtxProcessSignedInfoNode:file=xmldsig.c:line=804:obj=unknown:subj=xmlSecDSigReferenceCtxProcessNode:error=1:xmlsec 
library function failed:node=Reference
func=xmlSecDSigCtxProcessSignatureNode:file=xmldsig.c:line=547:obj=unknown:subj=xmlSecDSigCtxProcessSignedInfoNode:error=1:xmlsec 
library function failed: 
func=xmlSecDSigCtxVerify:file=xmldsig.c:line=366:obj=unknown:subj=xmlSecDSigCtxSigantureProcessNode:error=1:xmlsec 
library function failed: 
Error: signature failed 
ERROR

If I interpret it right, it seems like it's a problem of the underlying 
libxm2 library, but the question still stands. I have built the tool for 
x86_64 from the latest released source and used the latest libxml2 and 
libxslt sources as well.

Thank you very much in advance.
Vit Zikmund
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.aleksey.com/pipermail/xmlsec/attachments/20120523/ec3d9f7f/attachment-0001.html>

From aleksey at aleksey.com  Wed May 23 12:28:11 2012
From: aleksey at aleksey.com (Aleksey Sanin)
Date: Wed, 23 May 2012 12:28:11 -0700
Subject: [xmlsec] Support for really large XML documents
In-Reply-To: <OF6B85B7C1.7DCA0500-ONC1257A07.00515105-C1257A07.0055072F@cz.ibm.com>
References: <OF6B85B7C1.7DCA0500-ONC1257A07.00515105-C1257A07.0055072F@cz.ibm.com>
Message-ID: <4FBD3A4B.9040603@aleksey.com>

The error indicates that we can't allocate output buffer correctly. If
I would guess, then I would see if the "size" parameter is treated as
negative number when it exceeds 2G.

Try to change include/xmlsec/xmlsec.h and change the xmlSecSize to be
a typedef to size_t all the time (dont' forget to recompile xmlsec
after this change).

Aleksey

On 5/23/12 8:28 AM, Vit Zikmund wrote:
> Hello,
> we are trying to use the XMLSec utility to verify documents signed with
> our own application and probably have hit a limit of the document size,
> that XMLSec is able to process.
> 
> The simplest question is: Does XMLSec support handling large
> documents/files? Is is about to? For large I mean 2 gigabytes and more.
> 
> I can verify a document of 1GB, but little over 2GB returns an error:
> 
> func=xmlSecTransformC14NPushXml:file=c14n.c:line=279:obj=c14n:subj=xmlOutputBufferClose:error=5:libxml2
> library function failed:
> func=xmlSecTransformDefaultPushXml:file=transforms.c:line=2417:obj=enveloped-signature:subj=xmlSecTransformPushXml:error=1:xmlsec
> library function failed:
> func=xmlSecTransformCtxXmlExecute:file=transforms.c:line=1236:obj=unknown:subj=xmlSecTransformPushXml:error=1:xmlsec
> library function failed:transform=enveloped-signature
> func=xmlSecTransformCtxExecute:file=transforms.c:line=1296:obj=unknown:subj=xmlSecTransformCtxXmlExecute:error=1:xmlsec
> library function failed:
> func=xmlSecDSigReferenceCtxProcessNode:file=xmldsig.c:line=1571:obj=unknown:subj=xmlSecTransformCtxExecute:error=1:xmlsec
> library function failed:
> func=xmlSecDSigCtxProcessSignedInfoNode:file=xmldsig.c:line=804:obj=unknown:subj=xmlSecDSigReferenceCtxProcessNode:error=1:xmlsec
> library function failed:node=Reference
> func=xmlSecDSigCtxProcessSignatureNode:file=xmldsig.c:line=547:obj=unknown:subj=xmlSecDSigCtxProcessSignedInfoNode:error=1:xmlsec
> library function failed:
> func=xmlSecDSigCtxVerify:file=xmldsig.c:line=366:obj=unknown:subj=xmlSecDSigCtxSigantureProcessNode:error=1:xmlsec
> library function failed:
> Error: signature failed
> ERROR
> 
> If I interpret it right, it seems like it's a problem of the underlying
> libxm2 library, but the question still stands. I have built the tool for
> x86_64 from the latest released source and used the latest libxml2 and
> libxslt sources as well.
> 
> Thank you very much in advance.
> Vit Zikmund
> 
> 
> _______________________________________________
> xmlsec mailing list
> xmlsec at aleksey.com
> http://www.aleksey.com/mailman/listinfo/xmlsec

From ranier_gyn at hotmail.com  Wed May 23 14:37:20 2012
From: ranier_gyn at hotmail.com (Ranier VF)
Date: Wed, 23 May 2012 21:37:20 +0000
Subject: [xmlsec] dsigCtx->c14nMethod
In-Reply-To: <4FBCE2C1.1050500@aleksey.com>
References: <BAY145-W22CD6789FCA51AB319F0CDE3030@phx.gbl>,
 <4FBCE2C1.1050500@aleksey.com>
Message-ID: <BAY145-W22437B90AE344EC2F741B0E3030@phx.gbl>


Hi, Aleksey.
Sorry for long time, but today are very busy.

Right now I have windbg with view struct after xmlSecFindNode:
    node = xmlSecFindNode(xmlDocGetRootElement(doc), xmlSecNodeSignature, xmlSecDSigNs);
node->name = "Signature"
node->next->name = "SignedInfo"
node->next->next->name = "Text"
node->next->ns->type = XML_NAMESPACE_DECL (0n18)
node->next->ns->href = "http://www.w3.org/2000/09/xmldsig#"
node->next->doc->name = ""
node->nsDef->href = "http://www.w3.org/2000/09/xmldsig#"
node->doc->type = XML_DOCUMENT_NODE (0n9)
node->doc->name = ""

I not kown what node correctly, please you can tell me?
Exist other field in struct node relevant?

Best regards,

Ranier


> Date: Wed, 23 May 2012 06:14:41 -0700
> From: aleksey at aleksey.com
> To: ranier_gyn at hotmail.com
> CC: xmlsec at aleksey.com
> Subject: Re: [xmlsec] dsigCtx->c14nMethod
> 
> Check if you find the node correctly with xmlSecFindNode
> 
> Aleksey
> 
> On 5/23/12 3:08 AM, Ranier VF wrote:
> > Hi, can you help me?
> > The xml file:
> > <?xml version="1.0"?>
> > <!DOCTYPE test [<!ATTLIST infNFe Id ID #IMPLIED>]>
> > <NFe xmlns="http://www.portalfiscal.inf.br/nfe"><infNFe versao="2.00"
> > Id="NFe52120503241828000120550020000067501112798840">
> > ..........
> > </infNFe>
> > <Signature xmlns="http://www.w3.org/2000/09/xmldsig#">
> >   <SignedInfo>
> >     <CanonicalizationMethod
> > Algorithm="http://www.w3.org/TR/2001/REC-xml-c14n-20010315"/>
> >     <SignatureMethod
> > Algorithm="http://www.w3.org/2000/09/xmldsig#rsa-sha1"/>
> >     <Reference URI="#NFe52120503241828000120550020000067501112798840">
> >       <Transforms>
> >         <Transform
> > Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature"/>
> >         <Transform
> > Algorithm="http://www.w3.org/TR/2001/REC-xml-c14n-20010315"/>
> >       </Transforms>
> >       <DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/>
> >       <DigestValue/>
> >     </Reference>
> >   </SignedInfo>
> >   <SignatureValue/>
> >   <KeyInfo>
> >     <X509Data>
> >       <X509Certificate/>
> >     </X509Data>
> >   </KeyInfo>
> > </Signature></NFe>
> > 
> > With command line tool:
> > xmlsec --sign --print-debug --output nfe_sign.xml --pkcs12 sos.p12 --pwd
> > XXXXXXXX nfe3.xml
> > All Works.
> > 
> > = SIGNATURE CONTEXT
> > == Status: succeeded
> > == flags: 0x00000000
> > == flags2: 0x00000000
> > == Key Info Read Ctx:
> > = KEY INFO READ CONTEXT
> > == flags: 0x00000000
> > == flags2: 0x00000000
> > == enabled key data: all
> > == RetrievalMethod level (cur/max): 0/1
> > == TRANSFORMS CTX (status=0)
> > == flags: 0x00000000
> > == flags2: 0x00000000
> > == enabled transforms: all
> > === uri: NULL
> > === uri xpointer expr: NULL
> > == EncryptedKey level (cur/max): 0/1
> > === KeyReq:
> > ==== keyId: rsa
> > ==== keyType: 0x00000002
> > ==== keyUsage: 0x00000001
> > ==== keyBitsSize: 0
> > === list size: 0
> > == Key Info Write Ctx:
> > = KEY INFO WRITE CONTEXT
> > == flags: 0x00000000
> > == flags2: 0x00000000
> > == enabled key data: all
> > == RetrievalMethod level (cur/max): 0/1
> > == TRANSFORMS CTX (status=0)
> > == flags: 0x00000000
> > == flags2: 0x00000000
> > == enabled transforms: all
> > === uri: NULL
> > === uri xpointer expr: NULL
> > == EncryptedKey level (cur/max): 0/1
> > === KeyReq:
> > ==== keyId: NULL
> > ==== keyType: 0x00000001
> > ==== keyUsage: 0xffffffff
> > ==== keyBitsSize: 0
> > === list size: 0
> > == Signature Transform Ctx:
> > == TRANSFORMS CTX (status=2)
> > == flags: 0x00000000
> > == flags2: 0x00000000
> > == enabled transforms: all
> > === uri: NULL
> > === uri xpointer expr: NULL
> > === Transform: c14n (href=http://www.w3.org/TR/2001/REC-xml-c14n-20010315)
> > === Transform: rsa-sha1 (href=http://www.w3.org/2000/09/xmldsig#rsa-sha1)
> > === Transform: base64 (href=http://www.w3.org/2000/09/xmldsig#base64)
> > === Transform: membuf-transform (href=NULL)
> > == Signature Method:
> > === Transform: rsa-sha1 (href=http://www.w3.org/2000/09/xmldsig#rsa-sha1)
> > == Signature Key:
> > == KEY
> > === method: RSAKeyValue
> > === key type: Private
> > === key usage: -1
> > === rsa key: size = 2048
> > === list size: 1
> > === X509 Data:
> > ==== Key Certificate:
> > ==== Subject Name: /C=BR/O=ICP-Brasil/OU=Secretaria da Receita Federal
> > do Brasil - RFB/OU=CORREIOS/OU=ARCORREIOS/OU=RFB e-CNPJ
> > A1/L=GOIANIA/ST=GO/CN=S O S COMERCIO DE MAQUINAS LTDA ME:01800246000100
> > ==== Issuer Name: /C=BR/O=ICP-Brasil/OU=Secretaria da Receita Federal do
> > Brasil - RFB/CN=Autoridade Certificadora do SERPRORFB
> > ==== Issuer Serial: 32303131303931323139303131363337
> > ==== Certificate:
> > ==== Subject Name: /C=BR/O=ICP-Brasil/OU=Secretaria da Receita Federal
> > do Brasil - RFB/OU=CORREIOS/OU=ARCORREIOS/OU=RFB e-CNPJ
> > A1/L=GOIANIA/ST=GO/CN=S O S COMERCIO DE MAQUINAS LTDA ME:01800246000100
> > ==== Issuer Name: /C=BR/O=ICP-Brasil/OU=Secretaria da Receita Federal do
> > Brasil - RFB/CN=Autoridade Certificadora do SERPRORFB
> > ==== Issuer Serial: 32303131303931323139303131363337
> > == SignedInfo References List:
> > === list size: 1
> > = REFERENCE CALCULATION CONTEXT
> > == Status: succeeded
> > == URI: "#NFe52120503241828000120550020000067501112798840"
> > == Reference Transform Ctx:
> > == TRANSFORMS CTX (status=2)
> > == flags: 0x00000000
> > == flags2: 0x00000000
> > == enabled transforms: all
> > === uri:
> > === uri xpointer expr: #NFe52120503241828000120550020000067501112798840
> > === Transform: xpointer (href=http://www.w3.org/2001/04/xmldsig-more/xptr)
> > === Transform: enveloped-signature
> > (href=http://www.w3.org/2000/09/xmldsig#enveloped-signature)
> > === Transform: c14n (href=http://www.w3.org/TR/2001/REC-xml-c14n-20010315)
> > === Transform: sha1 (href=http://www.w3.org/2000/09/xmldsig#sha1)
> > === Transform: base64 (href=http://www.w3.org/2000/09/xmldsig#base64)
> > === Transform: membuf-transform (href=NULL)
> > == Digest Method:
> > === Transform: sha1 (href=http://www.w3.org/2000/09/xmldsig#sha1)
> > == Result - start buffer:
> > hn6gfGRWNBeR+CE6QQEU01E8e6A=
> > == Result - end buffer
> > == Manifest References List:
> > === list size: 0
> > == Result - start buffer:
> > c3hAUplnTN5WuP4nSW327q20JEiKjWj/p9tLY9thHw9RoUJcj/TDkG2zEZUn219i
> > vax5RMDmfk7T3HuBqg2xtEe6TxBRBlcECeQJz6BGj2xfbwLRqBAfR9gDEha+qpXu
> > 7aJvvxCBps8szV2je1ThWPXSZx274NYz5uDdnGv+h6bVBbb30aMqK+/mUlwe4/Bp
> > y58RKdoQC7RVQ4S3qiZ1cKGrfoPdhN73qsDjJhVub2a152n8qDwzEbM+ajUhX7Aa
> > BC99E3On9goJ7T0uz+RuHgLptRhrdaSQTZOl5pRgvFPKOfKeyX6svVHU3Kly+Q6t
> > Zx/edQpvMu8lp63lqa/u5g==
> > == Result - end buffer
> > 
> > But the same file: nfe3.xml with:
> > xml_sign(const char *tmpl_file, const char *key_file, const char *password1)
> > {
> >     xmlDocPtr doc = NULL;
> >     xmlNodePtr node = NULL;
> >     xmlSecDSigCtxPtr dsigCtx = NULL;
> > 
> >     /* load template */
> >     doc = xmlParseFile(tmpl_file);
> >     if ((doc == NULL) || (xmlDocGetRootElement(doc) == NULL))
> >     {
> >        fprintf(stderr, "Error: unable to parse file \"%s\"\n", tmpl_file);
> >        goto done;     
> >     }
> >    
> >     /* find start node */
> >     node = xmlSecFindNode(xmlDocGetRootElement(doc),
> > xmlSecNodeSignature, xmlSecDSigNs);
> >     if (node == NULL)
> >     {
> >           fprintf(stderr, "Error: start node not found in \"%s\"\n",
> > tmpl_file);
> >           goto done;
> >     }
> > 
> >     /* create signature context, we don't need keys manager in this
> > example */
> >     dsigCtx = xmlSecDSigCtxCreate(NULL);
> >     if (dsigCtx == NULL)
> >     {
> >        fprintf(stderr,"Error: failed to create signature context\n");
> >        goto done;
> >     }
> > 
> >     /* load private key with password */
> >     dsigCtx->signKey = xmlSecCryptoAppKeyLoad(key_file,
> > xmlSecKeyDataFormatPkcs12, password1, NULL, NULL);
> >     if (dsigCtx->signKey == NULL)
> >     {
> >        fprintf(stderr,"Error: failed to load private pem key from
> > \"%s\"\n", key_file);
> >        goto done;
> >     }
> > 
> >     /* set key name to the file name, this is just an example! */
> >     if (xmlSecKeySetName(dsigCtx->signKey, (xmlChar *) key_file) < 0)
> >     {
> >        fprintf(stderr,"Error: failed to set key name for key from
> > \"%s\"\n", key_file);
> >        goto done;
> >     }
> > 
> >     /* sign the template */
> >     if (xmlSecDSigCtxSign(dsigCtx, node) < 0)   <---- FAILL
> >     {
> >        fprintf(stderr, xmlSecErrorsGetMsg(xmlSecErrorsGetCode(0)));
> >        goto done;
> >     }
> > }
> > 
> > Not work! Result:
> > 
> > func=xmlSecDSigCtxProcessSignatureNode:file=..\src\xmldsig.c:line=465:ob
> > j=unknown:subj=dsigCtx->c14nMethod == NULL:error=100:assertion:
> > func=xmlSecDSigCtxSign:file=..\src\xmldsig.c:line=303:obj=unknown:subj=x
> > mlSecDSigCtxSigantureProcessNode:error=1:xmlsec library function failed:
> > 
> > Latest dlls from http://www.zlatkovic.com/libxml.en.html
> > xmlsec-1.2.18
> > libxml2-2.7.8
> > openssl-0.8a
> > 
> > Is necessary a key manager?
> > 
> > Thanks for your patience.
> > Any help will much appreciate.
> > 
> > Best regards,
> > 
> > Ranier Vilela
> > 
> > 
> > _______________________________________________
> > xmlsec mailing list
> > xmlsec at aleksey.com
> > http://www.aleksey.com/mailman/listinfo/xmlsec
 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.aleksey.com/pipermail/xmlsec/attachments/20120523/26fea04d/attachment-0001.html>

From aleksey at aleksey.com  Wed May 23 14:55:38 2012
From: aleksey at aleksey.com (Aleksey Sanin)
Date: Wed, 23 May 2012 14:55:38 -0700
Subject: [xmlsec] dsigCtx->c14nMethod
In-Reply-To: <BAY145-W22437B90AE344EC2F741B0E3030@phx.gbl>
References: <BAY145-W22CD6789FCA51AB319F0CDE3030@phx.gbl>,
 <4FBCE2C1.1050500@aleksey.com>
 <BAY145-W22437B90AE344EC2F741B0E3030@phx.gbl>
Message-ID: <4FBD5CDA.3090404@aleksey.com>

This looks OK to me. Sorry, don't know what's going on.
Didn't program on Windows in years.

Aleksey

On 5/23/12 2:37 PM, Ranier VF wrote:
> Hi, Aleksey.
> Sorry for long time, but today are very busy.
> 
> Right now I have windbg with view struct after xmlSecFindNode:
>     node = xmlSecFindNode(xmlDocGetRootElement(doc),
> xmlSecNodeSignature, xmlSecDSigNs);
> node->name = "Signature"
> node->next->name = "SignedInfo"
> node->next->next->name = "Text"
> node->next->ns->type = XML_NAMESPACE_DECL (0n18)
> node->next->ns->href = "http://www.w3.org/2000/09/xmldsig#"
> node->next->doc->name = ""
> node->nsDef->href = "http://www.w3.org/2000/09/xmldsig#"
> node->doc->type = XML_DOCUMENT_NODE (0n9)
> node->doc->name = ""
> 
> I not kown what node correctly, please you can tell me?
> Exist other field in struct node relevant?
> 
> Best regards,
> 
> Ranier
> 
>> Date: Wed, 23 May 2012 06:14:41 -0700
>> From: aleksey at aleksey.com
>> To: ranier_gyn at hotmail.com
>> CC: xmlsec at aleksey.com
>> Subject: Re: [xmlsec] dsigCtx->c14nMethod
>>
>> Check if you find the node correctly with xmlSecFindNode
>>
>> Aleksey
>>
>> On 5/23/12 3:08 AM, Ranier VF wrote:
>> > Hi, can you help me?
>> > The xml file:
>> > <?xml version="1.0"?>
>> > <!DOCTYPE test [<!ATTLIST infNFe Id ID #IMPLIED>]>
>> > <NFe xmlns="http://www.portalfiscal.inf.br/nfe"><infNFe versao="2.00"
>> > Id="NFe52120503241828000120550020000067501112798840">
>> > ..........
>> > </infNFe>
>> > <Signature xmlns="http://www.w3.org/2000/09/xmldsig#">
>> > <SignedInfo>
>> > <CanonicalizationMethod
>> > Algorithm="http://www.w3.org/TR/2001/REC-xml-c14n-20010315"/>
>> > <SignatureMethod
>> > Algorithm="http://www.w3.org/2000/09/xmldsig#rsa-sha1"/>
>> > <Reference URI="#NFe52120503241828000120550020000067501112798840">
>> > <Transforms>
>> > <Transform
>> > Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature"/>
>> > <Transform
>> > Algorithm="http://www.w3.org/TR/2001/REC-xml-c14n-20010315"/>
>> > </Transforms>
>> > <DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/>
>> > <DigestValue/>
>> > </Reference>
>> > </SignedInfo>
>> > <SignatureValue/>
>> > <KeyInfo>
>> > <X509Data>
>> > <X509Certificate/>
>> > </X509Data>
>> > </KeyInfo>
>> > </Signature></NFe>
>> >
>> > With command line tool:
>> > xmlsec --sign --print-debug --output nfe_sign.xml --pkcs12 sos.p12 --pwd
>> > XXXXXXXX nfe3.xml
>> > All Works.
>> >
>> > = SIGNATURE CONTEXT
>> > == Status: succeeded
>> > == flags: 0x00000000
>> > == flags2: 0x00000000
>> > == Key Info Read Ctx:
>> > = KEY INFO READ CONTEXT
>> > == flags: 0x00000000
>> > == flags2: 0x00000000
>> > == enabled key data: all
>> > == RetrievalMethod level (cur/max): 0/1
>> > == TRANSFORMS CTX (status=0)
>> > == flags: 0x00000000
>> > == flags2: 0x00000000
>> > == enabled transforms: all
>> > === uri: NULL
>> > === uri xpointer expr: NULL
>> > == EncryptedKey level (cur/max): 0/1
>> > === KeyReq:
>> > ==== keyId: rsa
>> > ==== keyType: 0x00000002
>> > ==== keyUsage: 0x00000001
>> > ==== keyBitsSize: 0
>> > === list size: 0
>> > == Key Info Write Ctx:
>> > = KEY INFO WRITE CONTEXT
>> > == flags: 0x00000000
>> > == flags2: 0x00000000
>> > == enabled key data: all
>> > == RetrievalMethod level (cur/max): 0/1
>> > == TRANSFORMS CTX (status=0)
>> > == flags: 0x00000000
>> > == flags2: 0x00000000
>> > == enabled transforms: all
>> > === uri: NULL
>> > === uri xpointer expr: NULL
>> > == EncryptedKey level (cur/max): 0/1
>> > === KeyReq:
>> > ==== keyId: NULL
>> > ==== keyType: 0x00000001
>> > ==== keyUsage: 0xffffffff
>> > ==== keyBitsSize: 0
>> > === list size: 0
>> > == Signature Transform Ctx:
>> > == TRANSFORMS CTX (status=2)
>> > == flags: 0x00000000
>> > == flags2: 0x00000000
>> > == enabled transforms: all
>> > === uri: NULL
>> > === uri xpointer expr: NULL
>> > === Transform: c14n
> (href=http://www.w3.org/TR/2001/REC-xml-c14n-20010315)
>> > === Transform: rsa-sha1
> (href=http://www.w3.org/2000/09/xmldsig#rsa-sha1)
>> > === Transform: base64 (href=http://www.w3.org/2000/09/xmldsig#base64)
>> > === Transform: membuf-transform (href=NULL)
>> > == Signature Method:
>> > === Transform: rsa-sha1
> (href=http://www.w3.org/2000/09/xmldsig#rsa-sha1)
>> > == Signature Key:
>> > == KEY
>> > === method: RSAKeyValue
>> > === key type: Private
>> > === key usage: -1
>> > === rsa key: size = 2048
>> > === list size: 1
>> > === X509 Data:
>> > ==== Key Certificate:
>> > ==== Subject Name: /C=BR/O=ICP-Brasil/OU=Secretaria da Receita Federal
>> > do Brasil - RFB/OU=CORREIOS/OU=ARCORREIOS/OU=RFB e-CNPJ
>> > A1/L=GOIANIA/ST=GO/CN=S O S COMERCIO DE MAQUINAS LTDA ME:01800246000100
>> > ==== Issuer Name: /C=BR/O=ICP-Brasil/OU=Secretaria da Receita Federal do
>> > Brasil - RFB/CN=Autoridade Certificadora do SERPRORFB
>> > ==== Issuer Serial: 32303131303931323139303131363337
>> > ==== Certificate:
>> > ==== Subject Name: /C=BR/O=ICP-Brasil/OU=Secretaria da Receita Federal
>> > do Brasil - RFB/OU=CORREIOS/OU=ARCORREIOS/OU=RFB e-CNPJ
>> > A1/L=GOIANIA/ST=GO/CN=S O S COMERCIO DE MAQUINAS LTDA ME:01800246000100
>> > ==== Issuer Name: /C=BR/O=ICP-Brasil/OU=Secretaria da Receita Federal do
>> > Brasil - RFB/CN=Autoridade Certificadora do SERPRORFB
>> > ==== Issuer Serial: 32303131303931323139303131363337
>> > == SignedInfo References List:
>> > === list size: 1
>> > = REFERENCE CALCULATION CONTEXT
>> > == Status: succeeded
>> > == URI: "#NFe52120503241828000120550020000067501112798840"
>> > == Reference Transform Ctx:
>> > == TRANSFORMS CTX (status=2)
>> > == flags: 0x00000000
>> > == flags2: 0x00000000
>> > == enabled transforms: all
>> > === uri:
>> > === uri xpointer expr: #NFe52120503241828000120550020000067501112798840
>> > === Transform: xpointer
> (href=http://www.w3.org/2001/04/xmldsig-more/xptr)
>> > === Transform: enveloped-signature
>> > (href=http://www.w3.org/2000/09/xmldsig#enveloped-signature)
>> > === Transform: c14n
> (href=http://www.w3.org/TR/2001/REC-xml-c14n-20010315)
>> > === Transform: sha1 (href=http://www.w3.org/2000/09/xmldsig#sha1)
>> > === Transform: base64 (href=http://www.w3.org/2000/09/xmldsig#base64)
>> > === Transform: membuf-transform (href=NULL)
>> > == Digest Method:
>> > === Transform: sha1 (href=http://www.w3.org/2000/09/xmldsig#sha1)
>> > == Result - start buffer:
>> > hn6gfGRWNBeR+CE6QQEU01E8e6A=
>> > == Result - end buffer
>> > == Manifest References List:
>> > === list size: 0
>> > == Result - start buffer:
>> > c3hAUplnTN5WuP4nSW327q20JEiKjWj/p9tLY9thHw9RoUJcj/TDkG2zEZUn219i
>> > vax5RMDmfk7T3HuBqg2xtEe6TxBRBlcECeQJz6BGj2xfbwLRqBAfR9gDEha+qpXu
>> > 7aJvvxCBps8szV2je1ThWPXSZx274NYz5uDdnGv+h6bVBbb30aMqK+/mUlwe4/Bp
>> > y58RKdoQC7RVQ4S3qiZ1cKGrfoPdhN73qsDjJhVub2a152n8qDwzEbM+ajUhX7Aa
>> > BC99E3On9goJ7T0uz+RuHgLptRhrdaSQTZOl5pRgvFPKOfKeyX6svVHU3Kly+Q6t
>> > Zx/edQpvMu8lp63lqa/u5g==
>> > == Result - end buffer
>> >
>> > But the same file: nfe3.xml with:
>> > xml_sign(const char *tmpl_file, const char *key_file, const char
> *password1)
>> > {
>> > xmlDocPtr doc = NULL;
>> > xmlNodePtr node = NULL;
>> > xmlSecDSigCtxPtr dsigCtx = NULL;
>> >
>> > /* load template */
>> > doc = xmlParseFile(tmpl_file);
>> > if ((doc == NULL) || (xmlDocGetRootElement(doc) == NULL))
>> > {
>> > fprintf(stderr, "Error: unable to parse file \"%s\"\n", tmpl_file);
>> > goto done;
>> > }
>> >
>> > /* find start node */
>> > node = xmlSecFindNode(xmlDocGetRootElement(doc),
>> > xmlSecNodeSignature, xmlSecDSigNs);
>> > if (node == NULL)
>> > {
>> > fprintf(stderr, "Error: start node not found in \"%s\"\n",
>> > tmpl_file);
>> > goto done;
>> > }
>> >
>> > /* create signature context, we don't need keys manager in this
>> > example */
>> > dsigCtx = xmlSecDSigCtxCreate(NULL);
>> > if (dsigCtx == NULL)
>> > {
>> > fprintf(stderr,"Error: failed to create signature context\n");
>> > goto done;
>> > }
>> >
>> > /* load private key with password */
>> > dsigCtx->signKey = xmlSecCryptoAppKeyLoad(key_file,
>> > xmlSecKeyDataFormatPkcs12, password1, NULL, NULL);
>> > if (dsigCtx->signKey == NULL)
>> > {
>> > fprintf(stderr,"Error: failed to load private pem key from
>> > \"%s\"\n", key_file);
>> > goto done;
>> > }
>> >
>> > /* set key name to the file name, this is just an example! */
>> > if (xmlSecKeySetName(dsigCtx->signKey, (xmlChar *) key_file) < 0)
>> > {
>> > fprintf(stderr,"Error: failed to set key name for key from
>> > \"%s\"\n", key_file);
>> > goto done;
>> > }
>> >
>> > /* sign the template */
>> > if (xmlSecDSigCtxSign(dsigCtx, node) < 0) <---- FAILL
>> > {
>> > fprintf(stderr, xmlSecErrorsGetMsg(xmlSecErrorsGetCode(0)));
>> > goto done;
>> > }
>> > }
>> >
>> > Not work! Result:
>> >
>> > func=xmlSecDSigCtxProcessSignatureNode:file=..\src\xmldsig.c:line=465:ob
>> > j=unknown:subj=dsigCtx->c14nMethod == NULL:error=100:assertion:
>> > func=xmlSecDSigCtxSign:file=..\src\xmldsig.c:line=303:obj=unknown:subj=x
>> > mlSecDSigCtxSigantureProcessNode:error=1:xmlsec library function failed:
>> >
>> > Latest dlls from http://www.zlatkovic.com/libxml.en.html
>> > xmlsec-1.2.18
>> > libxml2-2.7.8
>> > openssl-0.8a
>> >
>> > Is necessary a key manager?
>> >
>> > Thanks for your patience.
>> > Any help will much appreciate.
>> >
>> > Best regards,
>> >
>> > Ranier Vilela
>> >
>> >
>> > _______________________________________________
>> > xmlsec mailing list
>> > xmlsec at aleksey.com
>> > http://www.aleksey.com/mailman/listinfo/xmlsec
> 
> 
> _______________________________________________
> xmlsec mailing list
> xmlsec at aleksey.com
> http://www.aleksey.com/mailman/listinfo/xmlsec

From vit_zikmund at cz.ibm.com  Thu May 24 11:08:32 2012
From: vit_zikmund at cz.ibm.com (Vit Zikmund)
Date: Thu, 24 May 2012 20:08:32 +0200
Subject: [xmlsec] Support for really large XML documents
In-Reply-To: <4FBD3A4B.9040603@aleksey.com>
References: <OF6B85B7C1.7DCA0500-ONC1257A07.00515105-C1257A07.0055072F@cz.ibm.com>
 <4FBD3A4B.9040603@aleksey.com>
Message-ID: <OF68386823.6904D80B-ONC1257A08.006188A4-C1257A08.0063ABB7@cz.ibm.com>

Hi Aleksey, thanks for the tip.
I've tried it, but apparently, it's not the case. I've debugged the code 
and found the source of the error.
Here http://git.gnome.org/browse/xmlsec/tree/src/c14n.c#n277 
xmlOutputBufferClose(buf) returns negative number, but it's not an error 
code - it's an overflowed byte counter.
The overflow happens without error during the transformation execution in 
the libxml2 code - at the end of xmlOutputBufferWrite() ( 
http://git.gnome.org/browse/libxml2/tree/xmlIO.c#n3445 ).
Everything is just an 'int' over there. If I add a line checking for 
overflow to keep the value positive, my test passes, but that is some 
nasty hack.

I've already contacted the author and he said such big value shouldn't 
ever be there and suggested this might be a bad design.
This is the thread on libxml mailing list: 
https://mail.gnome.org/archives/xml/2012-May/msg00075.html

Can you comment on that? Might this be related to your comment few lines 
above the error saying:
/* we are using a semi-hack here: we know that xmlSecPtrList keeps
 * all pointers in the big array */

Thanks again,
Vit

Might this be somehow related to the comment few lines above

Aleksey Sanin <aleksey at aleksey.com> wrote on 05/23/2012 09:28:11 PM:

> The error indicates that we can't allocate output buffer correctly. If
> I would guess, then I would see if the "size" parameter is treated as
> negative number when it exceeds 2G.
> 
> Try to change include/xmlsec/xmlsec.h and change the xmlSecSize to be
> a typedef to size_t all the time (dont' forget to recompile xmlsec
> after this change).
> 
> Aleksey
> 
> On 5/23/12 8:28 AM, Vit Zikmund wrote:
> > Hello,
> > we are trying to use the XMLSec utility to verify documents signed 
with
> > our own application and probably have hit a limit of the document 
size,
> > that XMLSec is able to process.
> > 
> > The simplest question is: Does XMLSec support handling large
> > documents/files? Is is about to? For large I mean 2 gigabytes and 
more.
> > 
> > I can verify a document of 1GB, but little over 2GB returns an error:
> > 
> > 
> 
func=xmlSecTransformC14NPushXml:file=c14n.c:line=279:obj=c14n:subj=xmlOutputBufferClose:error=5:libxml2
> > library function failed:
> > 
> 
func=xmlSecTransformDefaultPushXml:file=transforms.c:line=2417:obj=enveloped-
> signature:subj=xmlSecTransformPushXml:error=1:xmlsec
> > library function failed:
> > 
> 
func=xmlSecTransformCtxXmlExecute:file=transforms.c:line=1236:obj=unknown:subj=xmlSecTransformPushXml:error=1:xmlsec
> > library function failed:transform=enveloped-signature
> > 
> 
func=xmlSecTransformCtxExecute:file=transforms.c:line=1296:obj=unknown:subj=xmlSecTransformCtxXmlExecute:error=1:xmlsec
> > library function failed:
> > 
> 
func=xmlSecDSigReferenceCtxProcessNode:file=xmldsig.c:line=1571:obj=unknown:subj=xmlSecTransformCtxExecute:error=1:xmlsec
> > library function failed:
> > 
> 
func=xmlSecDSigCtxProcessSignedInfoNode:file=xmldsig.c:line=804:obj=unknown:subj=xmlSecDSigReferenceCtxProcessNode:error=1:xmlsec
> > library function failed:node=Reference
> > 
> 
func=xmlSecDSigCtxProcessSignatureNode:file=xmldsig.c:line=547:obj=unknown:subj=xmlSecDSigCtxProcessSignedInfoNode:error=1:xmlsec
> > library function failed:
> > 
> 
func=xmlSecDSigCtxVerify:file=xmldsig.c:line=366:obj=unknown:subj=xmlSecDSigCtxSigantureProcessNode:error=1:xmlsec
> > library function failed:
> > Error: signature failed
> > ERROR
> > 
> > If I interpret it right, it seems like it's a problem of the 
underlying
> > libxm2 library, but the question still stands. I have built the tool 
for
> > x86_64 from the latest released source and used the latest libxml2 and
> > libxslt sources as well.
> > 
> > Thank you very much in advance.
> > Vit Zikmund
> > 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.aleksey.com/pipermail/xmlsec/attachments/20120524/da279892/attachment.html>

From aleksey at aleksey.com  Thu May 24 11:11:54 2012
From: aleksey at aleksey.com (Aleksey Sanin)
Date: Thu, 24 May 2012 11:11:54 -0700
Subject: [xmlsec] Support for really large XML documents
In-Reply-To: <OF68386823.6904D80B-ONC1257A08.006188A4-C1257A08.0063ABB7@cz.ibm.com>
References: <OF6B85B7C1.7DCA0500-ONC1257A07.00515105-C1257A07.0055072F@cz.ibm.com>
 <4FBD3A4B.9040603@aleksey.com>
 <OF68386823.6904D80B-ONC1257A08.006188A4-C1257A08.0063ABB7@cz.ibm.com>
Message-ID: <4FBE79EA.6020108@aleksey.com>

Unfortunately, I have to have the whole document in memory for C14N

Aleksey

On 5/24/12 11:08 AM, Vit Zikmund wrote:
> Hi Aleksey, thanks for the tip.
> I've tried it, but apparently, it's not the case. I've debugged the code
> and found the source of the error.
> Here
> _http://git.gnome.org/browse/xmlsec/tree/src/c14n.c#n277_xmlOutputBufferClose(buf)returns
> negative number, but it's not an error code - it's an overflowed byte
> counter.
> The overflow happens without error during the transformation execution
> in the libxml2 code - at the end of *xmlOutputBufferWrite*() (
> _http://git.gnome.org/browse/libxml2/tree/xmlIO.c#n3445_).
> Everything is just an 'int' over there. If I add a line checking for
> overflow to keep the value positive, my test passes, but that is some
> nasty hack.
> 
> I've already contacted the author and he said such big value shouldn't
> ever be there and suggested this might be a bad design.
> This is the thread on libxml mailing list:
> _https://mail.gnome.org/archives/xml/2012-May/msg00075.html_
> 
> Can you comment on that? Might this be related to your comment few lines
> above the error saying:
> /* we are using a _semi_-hack here: we know that xmlSecPtrList keeps
>  * all pointers in the big array */
> 
> Thanks again,
> Vit
> 
> Might this be somehow related to the comment few lines above
> 
> Aleksey Sanin <aleksey at aleksey.com> wrote on 05/23/2012 09:28:11 PM:
> 
>> The error indicates that we can't allocate output buffer correctly. If
>> I would guess, then I would see if the "size" parameter is treated as
>> negative number when it exceeds 2G.
>>
>> Try to change include/xmlsec/xmlsec.h and change the xmlSecSize to be
>> a typedef to size_t all the time (dont' forget to recompile xmlsec
>> after this change).
>>
>> Aleksey
>>
>> On 5/23/12 8:28 AM, Vit Zikmund wrote:
>> > Hello,
>> > we are trying to use the XMLSec utility to verify documents signed with
>> > our own application and probably have hit a limit of the document size,
>> > that XMLSec is able to process.
>> >
>> > The simplest question is: Does XMLSec support handling large
>> > documents/files? Is is about to? For large I mean 2 gigabytes and more.
>> >
>> > I can verify a document of 1GB, but little over 2GB returns an error:
>> >
>> >
>>
> func=xmlSecTransformC14NPushXml:file=c14n.c:line=279:obj=c14n:subj=xmlOutputBufferClose:error=5:libxml2
>> > library function failed:
>> >
>>
> func=xmlSecTransformDefaultPushXml:file=transforms.c:line=2417:obj=enveloped-
>> signature:subj=xmlSecTransformPushXml:error=1:xmlsec
>> > library function failed:
>> >
>>
> func=xmlSecTransformCtxXmlExecute:file=transforms.c:line=1236:obj=unknown:subj=xmlSecTransformPushXml:error=1:xmlsec
>> > library function failed:transform=enveloped-signature
>> >
>>
> func=xmlSecTransformCtxExecute:file=transforms.c:line=1296:obj=unknown:subj=xmlSecTransformCtxXmlExecute:error=1:xmlsec
>> > library function failed:
>> >
>>
> func=xmlSecDSigReferenceCtxProcessNode:file=xmldsig.c:line=1571:obj=unknown:subj=xmlSecTransformCtxExecute:error=1:xmlsec
>> > library function failed:
>> >
>>
> func=xmlSecDSigCtxProcessSignedInfoNode:file=xmldsig.c:line=804:obj=unknown:subj=xmlSecDSigReferenceCtxProcessNode:error=1:xmlsec
>> > library function failed:node=Reference
>> >
>>
> func=xmlSecDSigCtxProcessSignatureNode:file=xmldsig.c:line=547:obj=unknown:subj=xmlSecDSigCtxProcessSignedInfoNode:error=1:xmlsec
>> > library function failed:
>> >
>>
> func=xmlSecDSigCtxVerify:file=xmldsig.c:line=366:obj=unknown:subj=xmlSecDSigCtxSigantureProcessNode:error=1:xmlsec
>> > library function failed:
>> > Error: signature failed
>> > ERROR
>> >
>> > If I interpret it right, it seems like it's a problem of the underlying
>> > libxm2 library, but the question still stands. I have built the tool for
>> > x86_64 from the latest released source and used the latest libxml2 and
>> > libxslt sources as well.
>> >
>> > Thank you very much in advance.
>> > Vit Zikmund
>> >

From vit_zikmund at cz.ibm.com  Thu May 24 11:20:27 2012
From: vit_zikmund at cz.ibm.com (Vit Zikmund)
Date: Thu, 24 May 2012 20:20:27 +0200
Subject: [xmlsec] Support for really large XML documents
In-Reply-To: <4FBE79EA.6020108@aleksey.com>
References: <OF6B85B7C1.7DCA0500-ONC1257A07.00515105-C1257A07.0055072F@cz.ibm.com>
 <4FBD3A4B.9040603@aleksey.com>
 <OF68386823.6904D80B-ONC1257A08.006188A4-C1257A08.0063ABB7@cz.ibm.com>
 <4FBE79EA.6020108@aleksey.com>
Message-ID: <OF77EE301C.31291FD2-ONC1257A08.0064522D-C1257A08.0064C2E0@cz.ibm.com>

I don't blame you. That's perfectly fine with me. However, how do you 
think it should be fixed?

Vit

Aleksey Sanin <aleksey at aleksey.com> wrote on 05/24/2012 08:11:54 PM:

> Unfortunately, I have to have the whole document in memory for C14N
> 
> Aleksey
> 
> On 5/24/12 11:08 AM, Vit Zikmund wrote:
> > Hi Aleksey, thanks for the tip.
> > I've tried it, but apparently, it's not the case. I've debugged the 
code
> > and found the source of the error.
> > Here
> > _http://git.gnome.org/browse/xmlsec/tree/src/
> c14n.c#n277_xmlOutputBufferClose(buf)returns
> > negative number, but it's not an error code - it's an overflowed byte
> > counter.
> > The overflow happens without error during the transformation execution
> > in the libxml2 code - at the end of *xmlOutputBufferWrite*() (
> > _http://git.gnome.org/browse/libxml2/tree/xmlIO.c#n3445_).
> > Everything is just an 'int' over there. If I add a line checking for
> > overflow to keep the value positive, my test passes, but that is some
> > nasty hack.
> > 
> > I've already contacted the author and he said such big value shouldn't
> > ever be there and suggested this might be a bad design.
> > This is the thread on libxml mailing list:
> > _https://mail.gnome.org/archives/xml/2012-May/msg00075.html_
> > 
> > Can you comment on that? Might this be related to your comment few 
lines
> > above the error saying:
> > /* we are using a _semi_-hack here: we know that xmlSecPtrList keeps
> >  * all pointers in the big array */
> > 
> > Thanks again,
> > Vit
> > 
> > Might this be somehow related to the comment few lines above
> > 
> > Aleksey Sanin <aleksey at aleksey.com> wrote on 05/23/2012 09:28:11 PM:
> > 
> >> The error indicates that we can't allocate output buffer correctly. 
If
> >> I would guess, then I would see if the "size" parameter is treated as
> >> negative number when it exceeds 2G.
> >>
> >> Try to change include/xmlsec/xmlsec.h and change the xmlSecSize to be
> >> a typedef to size_t all the time (dont' forget to recompile xmlsec
> >> after this change).
> >>
> >> Aleksey
> >>
> >> On 5/23/12 8:28 AM, Vit Zikmund wrote:
> >> > Hello,
> >> > we are trying to use the XMLSec utility to verify documents signed 
with
> >> > our own application and probably have hit a limit of the document 
size,
> >> > that XMLSec is able to process.
> >> >
> >> > The simplest question is: Does XMLSec support handling large
> >> > documents/files? Is is about to? For large I mean 2 gigabytes and 
more.
> >> >
> >> > I can verify a document of 1GB, but little over 2GB returns an 
error:
> >> >
> >> >
> >>
> > 
> 
func=xmlSecTransformC14NPushXml:file=c14n.c:line=279:obj=c14n:subj=xmlOutputBufferClose:error=5:libxml2
> >> > library function failed:
> >> >
> >>
> > 
> 
func=xmlSecTransformDefaultPushXml:file=transforms.c:line=2417:obj=enveloped-
> >> signature:subj=xmlSecTransformPushXml:error=1:xmlsec
> >> > library function failed:
> >> >
> >>
> > 
> 
func=xmlSecTransformCtxXmlExecute:file=transforms.c:line=1236:obj=unknown:subj=xmlSecTransformPushXml:error=1:xmlsec
> >> > library function failed:transform=enveloped-signature
> >> >
> >>
> > 
> 
func=xmlSecTransformCtxExecute:file=transforms.c:line=1296:obj=unknown:subj=xmlSecTransformCtxXmlExecute:error=1:xmlsec
> >> > library function failed:
> >> >
> >>
> > 
> 
func=xmlSecDSigReferenceCtxProcessNode:file=xmldsig.c:line=1571:obj=unknown:subj=xmlSecTransformCtxExecute:error=1:xmlsec
> >> > library function failed:
> >> >
> >>
> > 
> 
func=xmlSecDSigCtxProcessSignedInfoNode:file=xmldsig.c:line=804:obj=unknown:subj=xmlSecDSigReferenceCtxProcessNode:error=1:xmlsec
> >> > library function failed:node=Reference
> >> >
> >>
> > 
> 
func=xmlSecDSigCtxProcessSignatureNode:file=xmldsig.c:line=547:obj=unknown:subj=xmlSecDSigCtxProcessSignedInfoNode:error=1:xmlsec
> >> > library function failed:
> >> >
> >>
> > 
> 
func=xmlSecDSigCtxVerify:file=xmldsig.c:line=366:obj=unknown:subj=xmlSecDSigCtxSigantureProcessNode:error=1:xmlsec
> >> > library function failed:
> >> > Error: signature failed
> >> > ERROR
> >> >
> >> > If I interpret it right, it seems like it's a problem of the 
underlying
> >> > libxm2 library, but the question still stands. I have built the 
tool for
> >> > x86_64 from the latest released source and used the latest libxml2 
and
> >> > libxslt sources as well.
> >> >
> >> > Thank you very much in advance.
> >> > Vit Zikmund
> >> >
> 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.aleksey.com/pipermail/xmlsec/attachments/20120524/72501882/attachment-0001.html>

From aleksey at aleksey.com  Thu May 24 11:22:52 2012
From: aleksey at aleksey.com (Aleksey Sanin)
Date: Thu, 24 May 2012 11:22:52 -0700
Subject: [xmlsec] Support for really large XML documents
In-Reply-To: <OF77EE301C.31291FD2-ONC1257A08.0064522D-C1257A08.0064C2E0@cz.ibm.com>
References: <OF6B85B7C1.7DCA0500-ONC1257A07.00515105-C1257A07.0055072F@cz.ibm.com>
 <4FBD3A4B.9040603@aleksey.com>
 <OF68386823.6904D80B-ONC1257A08.006188A4-C1257A08.0063ABB7@cz.ibm.com>
 <4FBE79EA.6020108@aleksey.com>
 <OF77EE301C.31291FD2-ONC1257A08.0064522D-C1257A08.0064C2E0@cz.ibm.com>
Message-ID: <4FBE7C7C.8010308@aleksey.com>

In the ideal world, the xml buffer functions should use size_t instead
of int.

Sorry, I don't think there is an easy fix

Aleksey

On 5/24/12 11:20 AM, Vit Zikmund wrote:
> I don't blame you. That's perfectly fine with me. However, how do you
> think it should be fixed?
> 
> Vit
> 
> Aleksey Sanin <aleksey at aleksey.com> wrote on 05/24/2012 08:11:54 PM:
> 
>> Unfortunately, I have to have the whole document in memory for C14N
>>
>> Aleksey
>>
>> On 5/24/12 11:08 AM, Vit Zikmund wrote:
>> > Hi Aleksey, thanks for the tip.
>> > I've tried it, but apparently, it's not the case. I've debugged the code
>> > and found the source of the error.
>> > Here
>> > _http://git.gnome.org/browse/xmlsec/tree/src/
>> c14n.c#n277_xmlOutputBufferClose(buf)returns
>> > negative number, but it's not an error code - it's an overflowed byte
>> > counter.
>> > The overflow happens without error during the transformation execution
>> > in the libxml2 code - at the end of *xmlOutputBufferWrite*() (
>> > _http://git.gnome.org/browse/libxml2/tree/xmlIO.c#n3445_).
>> > Everything is just an 'int' over there. If I add a line checking for
>> > overflow to keep the value positive, my test passes, but that is some
>> > nasty hack.
>> >
>> > I've already contacted the author and he said such big value shouldn't
>> > ever be there and suggested this might be a bad design.
>> > This is the thread on libxml mailing list:
>> > _https://mail.gnome.org/archives/xml/2012-May/msg00075.html_
>> >
>> > Can you comment on that? Might this be related to your comment few lines
>> > above the error saying:
>> > /* we are using a _semi_-hack here: we know that xmlSecPtrList keeps
>> >  * all pointers in the big array */
>> >
>> > Thanks again,
>> > Vit
>> >
>> > Might this be somehow related to the comment few lines above
>> >
>> > Aleksey Sanin <aleksey at aleksey.com> wrote on 05/23/2012 09:28:11 PM:
>> >
>> >> The error indicates that we can't allocate output buffer correctly. If
>> >> I would guess, then I would see if the "size" parameter is treated as
>> >> negative number when it exceeds 2G.
>> >>
>> >> Try to change include/xmlsec/xmlsec.h and change the xmlSecSize to be
>> >> a typedef to size_t all the time (dont' forget to recompile xmlsec
>> >> after this change).
>> >>
>> >> Aleksey
>> >>
>> >> On 5/23/12 8:28 AM, Vit Zikmund wrote:
>> >> > Hello,
>> >> > we are trying to use the XMLSec utility to verify documents
> signed with
>> >> > our own application and probably have hit a limit of the document
> size,
>> >> > that XMLSec is able to process.
>> >> >
>> >> > The simplest question is: Does XMLSec support handling large
>> >> > documents/files? Is is about to? For large I mean 2 gigabytes and
> more.
>> >> >
>> >> > I can verify a document of 1GB, but little over 2GB returns an error:
>> >> >
>> >> >
>> >>
>> >
>>
> func=xmlSecTransformC14NPushXml:file=c14n.c:line=279:obj=c14n:subj=xmlOutputBufferClose:error=5:libxml2
>> >> > library function failed:
>> >> >
>> >>
>> >
>>
> func=xmlSecTransformDefaultPushXml:file=transforms.c:line=2417:obj=enveloped-
>> >> signature:subj=xmlSecTransformPushXml:error=1:xmlsec
>> >> > library function failed:
>> >> >
>> >>
>> >
>>
> func=xmlSecTransformCtxXmlExecute:file=transforms.c:line=1236:obj=unknown:subj=xmlSecTransformPushXml:error=1:xmlsec
>> >> > library function failed:transform=enveloped-signature
>> >> >
>> >>
>> >
>>
> func=xmlSecTransformCtxExecute:file=transforms.c:line=1296:obj=unknown:subj=xmlSecTransformCtxXmlExecute:error=1:xmlsec
>> >> > library function failed:
>> >> >
>> >>
>> >
>>
> func=xmlSecDSigReferenceCtxProcessNode:file=xmldsig.c:line=1571:obj=unknown:subj=xmlSecTransformCtxExecute:error=1:xmlsec
>> >> > library function failed:
>> >> >
>> >>
>> >
>>
> func=xmlSecDSigCtxProcessSignedInfoNode:file=xmldsig.c:line=804:obj=unknown:subj=xmlSecDSigReferenceCtxProcessNode:error=1:xmlsec
>> >> > library function failed:node=Reference
>> >> >
>> >>
>> >
>>
> func=xmlSecDSigCtxProcessSignatureNode:file=xmldsig.c:line=547:obj=unknown:subj=xmlSecDSigCtxProcessSignedInfoNode:error=1:xmlsec
>> >> > library function failed:
>> >> >
>> >>
>> >
>>
> func=xmlSecDSigCtxVerify:file=xmldsig.c:line=366:obj=unknown:subj=xmlSecDSigCtxSigantureProcessNode:error=1:xmlsec
>> >> > library function failed:
>> >> > Error: signature failed
>> >> > ERROR
>> >> >
>> >> > If I interpret it right, it seems like it's a problem of the
> underlying
>> >> > libxm2 library, but the question still stands. I have built the
> tool for
>> >> > x86_64 from the latest released source and used the latest
> libxml2 and
>> >> > libxslt sources as well.
>> >> >
>> >> > Thank you very much in advance.
>> >> > Vit Zikmund
>> >> >
>>

From akitsukineko at gmail.com  Sat Jun  2 10:34:47 2012
From: akitsukineko at gmail.com (Neko)
Date: Sun, 3 Jun 2012 01:34:47 +0800
Subject: [xmlsec] About Canonicalization and Digest
Message-ID: <CAPpBuXgdM8cU-r78eYhYgt3KVPVdZT5mgKFUyD0gZQSmckmYBQ@mail.gmail.com>

Dear Aleksey

I have a question about Canonicalization and Digest while using xmlsec1 to
sign template xml file.
According to my understanding of xml signature spec provided by W3C, source
xml file needs Canonicalization(applied to the entire xml) before
calculating Digest.

The template file looks like this:

<?xml version="1.0"?>
<root xmlns="..."><node>text</node><node><node><node>text</node><node
>dlink</node></node><node>text</node></node><Signature xmlns="
http://www.w3.org/2000/09/xmldsig#">
   <SignedInfo>
        <CanonicalizationMethod Algorithm="
http://www.w3.org/2006/12/xml-c14n11#WithComments"/>
        <SignatureMethod Algorithm="
http://www.w3.org/2000/09/xmldsig#rsa-sha1"/>
        <Reference URI="">
            <Transforms>
                <Transform Algorithm="
http://www.w3.org/2000/09/xmldsig#enveloped-signature" />
            </Transforms>
            <DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1
"/>
            <DigestValue></DigestValue>
        </Reference>
    </SignedInfo>
    <SignatureValue />
    <KeyInfo>
        <KeyValue />
    </KeyInfo>
</Signature></root>
(to verify my understanding, there's no space and line changing between
data nodes)

In the result, xmlsec1 put desired values into proper fields, while the
original data remains the same, like:

<root xmlns="..."><node>text</node><node><node><node>text</node><node
>dlink</node></node><node>text</node></node>...<root>

However, I tried to do the Canonicalization with libxml, and the result is
like:(neglect signature node)

<?xml version="1.0"?>
<node>
  <node>text</node>
  <node>
    <node>
      <node>text</node>
      <node>text</node>
    </node>
    <node>text</node>
  </node>
</node>

which leads to different digest value.
Do I misunderstand something, or the way I used xmlsec1 is wrong?

Thank you


How I do the Canonicalization with libxml:
 get nodeset by:
  xmlXPathEvalExpression("/descendant-or-self::node()",context)
 then get Canonicalization by:
  xmlC14NDocSaveTo(doc, xpathresult->nodesetval, 2, NULL, 1,
c14noutputbuffer);
  xmlDocPtr c14ndoc = xmlParseMemory(c14nbuffer->content,c14nbuffer->use);
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.aleksey.com/pipermail/xmlsec/attachments/20120603/a1220041/attachment.html>

From aleksey at aleksey.com  Sat Jun  2 10:48:28 2012
From: aleksey at aleksey.com (Aleksey Sanin)
Date: Sat, 02 Jun 2012 10:48:28 -0700
Subject: [xmlsec] About Canonicalization and Digest
In-Reply-To: <CAPpBuXgdM8cU-r78eYhYgt3KVPVdZT5mgKFUyD0gZQSmckmYBQ@mail.gmail.com>
References: <CAPpBuXgdM8cU-r78eYhYgt3KVPVdZT5mgKFUyD0gZQSmckmYBQ@mail.gmail.com>
Message-ID: <4FCA51EC.6000408@aleksey.com>

" ... source xml file needs Canonicalization(applied to the entire xml) ..."

That's not quite correct. You can not use the "entire xml" because the
insertion of the signature changes it and the digest match during
verification would fail.

This is the part of the spec that talks about it

http://www.w3.org/TR/xmldsig-core1/#sec-ReferenceProcessingModel


Aleksey

On 6/2/12 10:34 AM, Neko wrote:
> Dear Aleksey
> 
> I have a question about Canonicalization and Digest while using xmlsec1
> to sign template xml file.
> According to my understanding of xml signature spec provided by W3C,
> source xml file needs Canonicalization(applied to the entire xml) before
> calculating Digest.
> 
> The template file looks like this:
> 
> <?xml version="1.0"?>
> <root
> xmlns="..."><node>text</node><node><node><node>text</node><node>dlink</node></node><node>text</node></node><Signature
> xmlns="http://www.w3.org/2000/09/xmldsig#">
>    <SignedInfo>
>         <CanonicalizationMethod
> Algorithm="http://www.w3.org/2006/12/xml-c14n11#WithComments"/>
>         <SignatureMethod
> Algorithm="http://www.w3.org/2000/09/xmldsig#rsa-sha1"/>
>         <Reference URI="">
>             <Transforms>
>                 <Transform
> Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature" />
>             </Transforms>
>             <DigestMethod
> Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/>
>             <DigestValue></DigestValue>
>         </Reference>
>     </SignedInfo>
>     <SignatureValue />
>     <KeyInfo>
>         <KeyValue />
>     </KeyInfo>
> </Signature></root>
> (to verify my understanding, there's no space and line changing between
> data nodes)
> 
> In the result, xmlsec1 put desired values into proper fields, while the
> original data remains the same, like:
> 
> <root
> xmlns="..."><node>text</node><node><node><node>text</node><node>dlink</node></node><node>text</node></node>...<root>
> 
> However, I tried to do the Canonicalization with libxml, and the result
> is like:(neglect signature node)
> 
> <?xml version="1.0"?>
> <node>
>   <node>text</node>
>   <node>
>     <node>
>       <node>text</node>
>       <node>text</node>
>     </node>
>     <node>text</node>
>   </node>
> </node>
> 
> which leads to different digest value.
> Do I misunderstand something, or the way I used xmlsec1 is wrong?
> 
> Thank you
> 
> 
> How I do the Canonicalization with libxml:
>  get nodeset by:
>   xmlXPathEvalExpression("/descendant-or-self::node()",context)
>  then get Canonicalization by:
>   xmlC14NDocSaveTo(doc, xpathresult->nodesetval, 2, NULL, 1,
> c14noutputbuffer);
>   xmlDocPtr c14ndoc = xmlParseMemory(c14nbuffer->content,c14nbuffer->use);
> 
> 
> 
> _______________________________________________
> xmlsec mailing list
> xmlsec at aleksey.com
> http://www.aleksey.com/mailman/listinfo/xmlsec

From akitsukineko at gmail.com  Sat Jun  2 11:55:23 2012
From: akitsukineko at gmail.com (Neko)
Date: Sun, 3 Jun 2012 02:55:23 +0800
Subject: [xmlsec] About Canonicalization and Digest
In-Reply-To: <CAPpBuXjd-uer1i2AUS2_LcuavCgd8Ch=H+5AziMBXogvMdk3Gg@mail.gmail.com>
References: <CAPpBuXgdM8cU-r78eYhYgt3KVPVdZT5mgKFUyD0gZQSmckmYBQ@mail.gmail.com>
 <4FCA51EC.6000408@aleksey.com>
 <CAPpBuXjd-uer1i2AUS2_LcuavCgd8Ch=H+5AziMBXogvMdk3Gg@mail.gmail.com>
Message-ID: <CAPpBuXjPMBNP0yAbPDwahonsXhiuB=9qapwjhcPgKSNndT1GNg@mail.gmail.com>

Thank you for answering.
So if signing the node inside the xml file(same-document reference),
 first we have to get the XPath node-set,
 then do the Canonicalization on the node-set,
 and calculating Digest of the Canonicalization result.
The original content of referenced node-set won't be changed.

But in the test case
input

<root>
xmlns="..."><node>text</node><node><node><node>text</node><node>dlink</node></node><node>text</node></node>...<root>

Canonicalization form obtained from libxml2(<CanonicalizationMethod>
Algorithm="http://www.w3.org/2006/12/xml-c14n11#WithComments")

<?xml version="1.0"?>
<node>
  <node>text</node>
  <node>
    <node>
      <node>text</node>
      <node>text</node>
    </node>
    <node>text</node>
  </node>
</node>

Shouldn't digest value base on the second one?

Thank you


2012/6/3 Aleksey Sanin <aleksey at aleksey.com>

> " ... source xml file needs Canonicalization(applied to the entire xml)
> ..."
>
> That's not quite correct. You can not use the "entire xml" because the
> insertion of the signature changes it and the digest match during
> verification would fail.
>
> This is the part of the spec that talks about it
>
> http://www.w3.org/TR/xmldsig-core1/#sec-ReferenceProcessingModel
>
>
> Aleksey
>
> On 6/2/12 10:34 AM, Neko wrote:
> > Dear Aleksey
> >
> > I have a question about Canonicalization and Digest while using xmlsec1
> > to sign template xml file.
> > According to my understanding of xml signature spec provided by W3C,
> > source xml file needs Canonicalization(applied to the entire xml) before
> > calculating Digest.
> >
> > The template file looks like this:
> >
> > <?xml version="1.0"?>
> > <root
> >
> xmlns="..."><node>text</node><node><node><node>text</node><node>dlink</node></node><node>text</node></node><Signature
> > xmlns="http://www.w3.org/2000/09/xmldsig#">
> >    <SignedInfo>
> >         <CanonicalizationMethod
> > Algorithm="http://www.w3.org/2006/12/xml-c14n11#WithComments"/>
> >         <SignatureMethod
> > Algorithm="http://www.w3.org/2000/09/xmldsig#rsa-sha1"/>
> >         <Reference URI="">
> >             <Transforms>
> >                 <Transform
> > Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature" />
> >             </Transforms>
> >             <DigestMethod
> > Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/>
> >             <DigestValue></DigestValue>
> >         </Reference>
> >     </SignedInfo>
> >     <SignatureValue />
> >     <KeyInfo>
> >         <KeyValue />
> >     </KeyInfo>
> > </Signature></root>
> > (to verify my understanding, there's no space and line changing between
> > data nodes)
> >
> > In the result, xmlsec1 put desired values into proper fields, while the
> > original data remains the same, like:
> >
> > <root
> >
> xmlns="..."><node>text</node><node><node><node>text</node><node>dlink</node></node><node>text</node></node>...<root>
> >
> > However, I tried to do the Canonicalization with libxml, and the result
> > is like:(neglect signature node)
> >
> > <?xml version="1.0"?>
> > <node>
> >   <node>text</node>
> >   <node>
> >     <node>
> >       <node>text</node>
> >       <node>text</node>
> >     </node>
> >     <node>text</node>
> >   </node>
> > </node>
> >
> > which leads to different digest value.
> > Do I misunderstand something, or the way I used xmlsec1 is wrong?
> >
> > Thank you
> >
> >
> > How I do the Canonicalization with libxml:
> >  get nodeset by:
> >   xmlXPathEvalExpression("/descendant-or-self::node()",context)
> >  then get Canonicalization by:
> >   xmlC14NDocSaveTo(doc, xpathresult->nodesetval, 2, NULL, 1,
> > c14noutputbuffer);
> >   xmlDocPtr c14ndoc =
> xmlParseMemory(c14nbuffer->content,c14nbuffer->use);
> >
> >
> >
> > _______________________________________________
> > xmlsec mailing list
> > xmlsec at aleksey.com
> > http://www.aleksey.com/mailman/listinfo/xmlsec
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.aleksey.com/pipermail/xmlsec/attachments/20120603/f83ae01a/attachment.html>

From aleksey at aleksey.com  Sat Jun  2 12:06:09 2012
From: aleksey at aleksey.com (Aleksey Sanin)
Date: Sat, 02 Jun 2012 12:06:09 -0700
Subject: [xmlsec] About Canonicalization and Digest
In-Reply-To: <CAPpBuXjPMBNP0yAbPDwahonsXhiuB=9qapwjhcPgKSNndT1GNg@mail.gmail.com>
References: <CAPpBuXgdM8cU-r78eYhYgt3KVPVdZT5mgKFUyD0gZQSmckmYBQ@mail.gmail.com>
 <4FCA51EC.6000408@aleksey.com>
 <CAPpBuXjd-uer1i2AUS2_LcuavCgd8Ch=H+5AziMBXogvMdk3Gg@mail.gmail.com>
 <CAPpBuXjPMBNP0yAbPDwahonsXhiuB=9qapwjhcPgKSNndT1GNg@mail.gmail.com>
Message-ID: <4FCA6421.4070808@aleksey.com>

Yes

Aleksey

On 6/2/12 11:55 AM, Neko wrote:
> 
> Thank you for answering.
> So if signing the node inside the xml file(same-document reference),
>  first we have to get the XPath node-set,
>  then do the Canonicalization on the node-set,
>  and calculating Digest of the Canonicalization result.
> The original content of referenced node-set won't be changed.
> 
> But in the test case
> input
> 
> <root>
> xmlns="..."><node>text</node><node><node><node>text</node><node>dlink</node></node><node>text</node></node>...<root>
> 
> Canonicalization form obtained from libxml2(<CanonicalizationMethod>
> Algorithm="http://www.w3.org/2006/12/xml-c14n11#WithComments")
> 
> <?xml version="1.0"?>
> <node>
>   <node>text</node>
>   <node>
>     <node>
>       <node>text</node>
>       <node>text</node>
>     </node>
>     <node>text</node>
>   </node>
> </node>
> 
> Shouldn't digest value base on the second one?
> 
> Thank you
> 
> 
> 2012/6/3 Aleksey Sanin <aleksey at aleksey.com <mailto:aleksey at aleksey.com>>
> 
>     " ... source xml file needs Canonicalization(applied to the entire
>     xml) ..."
> 
>     That's not quite correct. You can not use the "entire xml" because the
>     insertion of the signature changes it and the digest match during
>     verification would fail.
> 
>     This is the part of the spec that talks about it
> 
>     http://www.w3.org/TR/xmldsig-core1/#sec-ReferenceProcessingModel
> 
> 
>     Aleksey
> 
>     On 6/2/12 10:34 AM, Neko wrote:
>     > Dear Aleksey
>     >
>     > I have a question about Canonicalization and Digest while using
>     xmlsec1
>     > to sign template xml file.
>     > According to my understanding of xml signature spec provided by W3C,
>     > source xml file needs Canonicalization(applied to the entire xml)
>     before
>     > calculating Digest.
>     >
>     > The template file looks like this:
>     >
>     > <?xml version="1.0"?>
>     > <root
>     >
>     xmlns="..."><node>text</node><node><node><node>text</node><node>dlink</node></node><node>text</node></node><Signature
>     > xmlns="http://www.w3.org/2000/09/xmldsig#">
>     >    <SignedInfo>
>     >         <CanonicalizationMethod
>     > Algorithm="http://www.w3.org/2006/12/xml-c14n11#WithComments"/>
>     >         <SignatureMethod
>     > Algorithm="http://www.w3.org/2000/09/xmldsig#rsa-sha1"/>
>     >         <Reference URI="">
>     >             <Transforms>
>     >                 <Transform
>     > Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature" />
>     >             </Transforms>
>     >             <DigestMethod
>     > Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/>
>     >             <DigestValue></DigestValue>
>     >         </Reference>
>     >     </SignedInfo>
>     >     <SignatureValue />
>     >     <KeyInfo>
>     >         <KeyValue />
>     >     </KeyInfo>
>     > </Signature></root>
>     > (to verify my understanding, there's no space and line changing
>     between
>     > data nodes)
>     >
>     > In the result, xmlsec1 put desired values into proper fields,
>     while the
>     > original data remains the same, like:
>     >
>     > <root
>     >
>     xmlns="..."><node>text</node><node><node><node>text</node><node>dlink</node></node><node>text</node></node>...<root>
>     >
>     > However, I tried to do the Canonicalization with libxml, and the
>     result
>     > is like:(neglect signature node)
>     >
>     > <?xml version="1.0"?>
>     > <node>
>     >   <node>text</node>
>     >   <node>
>     >     <node>
>     >       <node>text</node>
>     >       <node>text</node>
>     >     </node>
>     >     <node>text</node>
>     >   </node>
>     > </node>
>     >
>     > which leads to different digest value.
>     > Do I misunderstand something, or the way I used xmlsec1 is wrong?
>     >
>     > Thank you
>     >
>     >
>     > How I do the Canonicalization with libxml:
>     >  get nodeset by:
>     >   xmlXPathEvalExpression("/descendant-or-self::node()",context)
>     >  then get Canonicalization by:
>     >   xmlC14NDocSaveTo(doc, xpathresult->nodesetval, 2, NULL, 1,
>     > c14noutputbuffer);
>     >   xmlDocPtr c14ndoc =
>     xmlParseMemory(c14nbuffer->content,c14nbuffer->use);
>     >
>     >
>     >
>     > _______________________________________________
>     > xmlsec mailing list
>     > xmlsec at aleksey.com <mailto:xmlsec at aleksey.com>
>     > http://www.aleksey.com/mailman/listinfo/xmlsec
> 
> 
> 
> 
> 
> _______________________________________________
> xmlsec mailing list
> xmlsec at aleksey.com
> http://www.aleksey.com/mailman/listinfo/xmlsec

From akitsukineko at gmail.com  Sat Jun  2 12:33:13 2012
From: akitsukineko at gmail.com (Neko)
Date: Sun, 3 Jun 2012 03:33:13 +0800
Subject: [xmlsec] About Canonicalization and Digest
In-Reply-To: <4FCA6421.4070808@aleksey.com>
References: <CAPpBuXgdM8cU-r78eYhYgt3KVPVdZT5mgKFUyD0gZQSmckmYBQ@mail.gmail.com>
 <4FCA51EC.6000408@aleksey.com>
 <CAPpBuXjd-uer1i2AUS2_LcuavCgd8Ch=H+5AziMBXogvMdk3Gg@mail.gmail.com>
 <CAPpBuXjPMBNP0yAbPDwahonsXhiuB=9qapwjhcPgKSNndT1GNg@mail.gmail.com>
 <4FCA6421.4070808@aleksey.com>
Message-ID: <CAPpBuXjVydxoCPC4EbLnAHdvdv7ykppm-a=5e=rmowcjGxEo_g@mail.gmail.com>

But the DigestValue is the digest of original xml content,
 <root
xmlns="..."><node>text</node><node><node><node>text</node><node>dlink</node></node><node>text</node></node>...<root>

Does it mean that the Canonicalization result I got is not the correct one?
<?xml version="1.0"?>
<node>
  <node>text</node>
  <node>
    <node>
      <node>text</node>
      <node>text</node>
    </node>
    <node>text</node>
  </node>
</node>

Thank you for answering

2012/6/3 Aleksey Sanin <aleksey at aleksey.com>

> Yes
>
> Aleksey
>
> On 6/2/12 11:55 AM, Neko wrote:
> >
> > Thank you for answering.
> > So if signing the node inside the xml file(same-document reference),
> >  first we have to get the XPath node-set,
> >  then do the Canonicalization on the node-set,
> >  and calculating Digest of the Canonicalization result.
> > The original content of referenced node-set won't be changed.
> >
> > But in the test case
> > input
> >
> > <root>
> >
> xmlns="..."><node>text</node><node><node><node>text</node><node>dlink</node></node><node>text</node></node>...<root>
> >
> > Canonicalization form obtained from libxml2(<CanonicalizationMethod>
> > Algorithm="http://www.w3.org/2006/12/xml-c14n11#WithComments")
> >
> > <?xml version="1.0"?>
> > <node>
> >   <node>text</node>
> >   <node>
> >     <node>
> >       <node>text</node>
> >       <node>text</node>
> >     </node>
> >     <node>text</node>
> >   </node>
> > </node>
> >
> > Shouldn't digest value base on the second one?
> >
> > Thank you
> >
> >
> > 2012/6/3 Aleksey Sanin <aleksey at aleksey.com <mailto:aleksey at aleksey.com
> >>
> >
> >     " ... source xml file needs Canonicalization(applied to the entire
> >     xml) ..."
> >
> >     That's not quite correct. You can not use the "entire xml" because
> the
> >     insertion of the signature changes it and the digest match during
> >     verification would fail.
> >
> >     This is the part of the spec that talks about it
> >
> >     http://www.w3.org/TR/xmldsig-core1/#sec-ReferenceProcessingModel
> >
> >
> >     Aleksey
> >
> >     On 6/2/12 10:34 AM, Neko wrote:
> >     > Dear Aleksey
> >     >
> >     > I have a question about Canonicalization and Digest while using
> >     xmlsec1
> >     > to sign template xml file.
> >     > According to my understanding of xml signature spec provided by
> W3C,
> >     > source xml file needs Canonicalization(applied to the entire xml)
> >     before
> >     > calculating Digest.
> >     >
> >     > The template file looks like this:
> >     >
> >     > <?xml version="1.0"?>
> >     > <root
> >     >
> >
> xmlns="..."><node>text</node><node><node><node>text</node><node>dlink</node></node><node>text</node></node><Signature
> >     > xmlns="http://www.w3.org/2000/09/xmldsig#">
> >     >    <SignedInfo>
> >     >         <CanonicalizationMethod
> >     > Algorithm="http://www.w3.org/2006/12/xml-c14n11#WithComments"/>
> >     >         <SignatureMethod
> >     > Algorithm="http://www.w3.org/2000/09/xmldsig#rsa-sha1"/>
> >     >         <Reference URI="">
> >     >             <Transforms>
> >     >                 <Transform
> >     > Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature"
> />
> >     >             </Transforms>
> >     >             <DigestMethod
> >     > Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/>
> >     >             <DigestValue></DigestValue>
> >     >         </Reference>
> >     >     </SignedInfo>
> >     >     <SignatureValue />
> >     >     <KeyInfo>
> >     >         <KeyValue />
> >     >     </KeyInfo>
> >     > </Signature></root>
> >     > (to verify my understanding, there's no space and line changing
> >     between
> >     > data nodes)
> >     >
> >     > In the result, xmlsec1 put desired values into proper fields,
> >     while the
> >     > original data remains the same, like:
> >     >
> >     > <root
> >     >
> >
> xmlns="..."><node>text</node><node><node><node>text</node><node>dlink</node></node><node>text</node></node>...<root>
> >     >
> >     > However, I tried to do the Canonicalization with libxml, and the
> >     result
> >     > is like:(neglect signature node)
> >     >
> >     > <?xml version="1.0"?>
> >     > <node>
> >     >   <node>text</node>
> >     >   <node>
> >     >     <node>
> >     >       <node>text</node>
> >     >       <node>text</node>
> >     >     </node>
> >     >     <node>text</node>
> >     >   </node>
> >     > </node>
> >     >
> >     > which leads to different digest value.
> >     > Do I misunderstand something, or the way I used xmlsec1 is wrong?
> >     >
> >     > Thank you
> >     >
> >     >
> >     > How I do the Canonicalization with libxml:
> >     >  get nodeset by:
> >     >   xmlXPathEvalExpression("/descendant-or-self::node()",context)
> >     >  then get Canonicalization by:
> >     >   xmlC14NDocSaveTo(doc, xpathresult->nodesetval, 2, NULL, 1,
> >     > c14noutputbuffer);
> >     >   xmlDocPtr c14ndoc =
> >     xmlParseMemory(c14nbuffer->content,c14nbuffer->use);
> >     >
> >     >
> >     >
> >     > _______________________________________________
> >     > xmlsec mailing list
> >     > xmlsec at aleksey.com <mailto:xmlsec at aleksey.com>
> >     > http://www.aleksey.com/mailman/listinfo/xmlsec
> >
> >
> >
> >
> >
> > _______________________________________________
> > xmlsec mailing list
> > xmlsec at aleksey.com
> > http://www.aleksey.com/mailman/listinfo/xmlsec
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.aleksey.com/pipermail/xmlsec/attachments/20120603/a3c777b9/attachment.html>

From aleksey at aleksey.com  Sat Jun  2 12:44:07 2012
From: aleksey at aleksey.com (Aleksey Sanin)
Date: Sat, 02 Jun 2012 12:44:07 -0700
Subject: [xmlsec] About Canonicalization and Digest
In-Reply-To: <CAPpBuXjVydxoCPC4EbLnAHdvdv7ykppm-a=5e=rmowcjGxEo_g@mail.gmail.com>
References: <CAPpBuXgdM8cU-r78eYhYgt3KVPVdZT5mgKFUyD0gZQSmckmYBQ@mail.gmail.com>
 <4FCA51EC.6000408@aleksey.com>
 <CAPpBuXjd-uer1i2AUS2_LcuavCgd8Ch=H+5AziMBXogvMdk3Gg@mail.gmail.com>
 <CAPpBuXjPMBNP0yAbPDwahonsXhiuB=9qapwjhcPgKSNndT1GNg@mail.gmail.com>
 <4FCA6421.4070808@aleksey.com>
 <CAPpBuXjVydxoCPC4EbLnAHdvdv7ykppm-a=5e=rmowcjGxEo_g@mail.gmail.com>
Message-ID: <4FCA6D07.9040906@aleksey.com>

The xmlsec1 tool has an option --store-references that shows exactly
what was digested. Run it and see for yourself.

Aleksey

On 6/2/12 12:33 PM, Neko wrote:
> But the DigestValue is the digest of original xml content,
>  <root
> xmlns="..."><node>text</node><node><node><node>text</node><node>dlink</node></node><node>text</node></node>...<root>
> 
> Does it mean that the Canonicalization result I got is not the correct one?
> <?xml version="1.0"?>
> <node>
>   <node>text</node>
>   <node>
>     <node>
>       <node>text</node>
>       <node>text</node>
>     </node>
>     <node>text</node>
>   </node>
> </node>
> 
> Thank you for answering
> 
> 2012/6/3 Aleksey Sanin <aleksey at aleksey.com <mailto:aleksey at aleksey.com>>
> 
>     Yes
> 
>     Aleksey
> 
>     On 6/2/12 11:55 AM, Neko wrote:
>     >
>     > Thank you for answering.
>     > So if signing the node inside the xml file(same-document reference),
>     >  first we have to get the XPath node-set,
>     >  then do the Canonicalization on the node-set,
>     >  and calculating Digest of the Canonicalization result.
>     > The original content of referenced node-set won't be changed.
>     >
>     > But in the test case
>     > input
>     >
>     > <root>
>     >
>     xmlns="..."><node>text</node><node><node><node>text</node><node>dlink</node></node><node>text</node></node>...<root>
>     >
>     > Canonicalization form obtained from libxml2(<CanonicalizationMethod>
>     > Algorithm="http://www.w3.org/2006/12/xml-c14n11#WithComments")
>     >
>     > <?xml version="1.0"?>
>     > <node>
>     >   <node>text</node>
>     >   <node>
>     >     <node>
>     >       <node>text</node>
>     >       <node>text</node>
>     >     </node>
>     >     <node>text</node>
>     >   </node>
>     > </node>
>     >
>     > Shouldn't digest value base on the second one?
>     >
>     > Thank you
>     >
>     >
>     > 2012/6/3 Aleksey Sanin <aleksey at aleksey.com
>     <mailto:aleksey at aleksey.com> <mailto:aleksey at aleksey.com
>     <mailto:aleksey at aleksey.com>>>
>     >
>     >     " ... source xml file needs Canonicalization(applied to the entire
>     >     xml) ..."
>     >
>     >     That's not quite correct. You can not use the "entire xml"
>     because the
>     >     insertion of the signature changes it and the digest match during
>     >     verification would fail.
>     >
>     >     This is the part of the spec that talks about it
>     >
>     >     http://www.w3.org/TR/xmldsig-core1/#sec-ReferenceProcessingModel
>     >
>     >
>     >     Aleksey
>     >
>     >     On 6/2/12 10:34 AM, Neko wrote:
>     >     > Dear Aleksey
>     >     >
>     >     > I have a question about Canonicalization and Digest while using
>     >     xmlsec1
>     >     > to sign template xml file.
>     >     > According to my understanding of xml signature spec provided
>     by W3C,
>     >     > source xml file needs Canonicalization(applied to the entire
>     xml)
>     >     before
>     >     > calculating Digest.
>     >     >
>     >     > The template file looks like this:
>     >     >
>     >     > <?xml version="1.0"?>
>     >     > <root
>     >     >
>     >    
>     xmlns="..."><node>text</node><node><node><node>text</node><node>dlink</node></node><node>text</node></node><Signature
>     >     > xmlns="http://www.w3.org/2000/09/xmldsig#">
>     >     >    <SignedInfo>
>     >     >         <CanonicalizationMethod
>     >     > Algorithm="http://www.w3.org/2006/12/xml-c14n11#WithComments"/>
>     >     >         <SignatureMethod
>     >     > Algorithm="http://www.w3.org/2000/09/xmldsig#rsa-sha1"/>
>     >     >         <Reference URI="">
>     >     >             <Transforms>
>     >     >                 <Transform
>     >     >
>     Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature" />
>     >     >             </Transforms>
>     >     >             <DigestMethod
>     >     > Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/>
>     >     >             <DigestValue></DigestValue>
>     >     >         </Reference>
>     >     >     </SignedInfo>
>     >     >     <SignatureValue />
>     >     >     <KeyInfo>
>     >     >         <KeyValue />
>     >     >     </KeyInfo>
>     >     > </Signature></root>
>     >     > (to verify my understanding, there's no space and line changing
>     >     between
>     >     > data nodes)
>     >     >
>     >     > In the result, xmlsec1 put desired values into proper fields,
>     >     while the
>     >     > original data remains the same, like:
>     >     >
>     >     > <root
>     >     >
>     >    
>     xmlns="..."><node>text</node><node><node><node>text</node><node>dlink</node></node><node>text</node></node>...<root>
>     >     >
>     >     > However, I tried to do the Canonicalization with libxml, and the
>     >     result
>     >     > is like:(neglect signature node)
>     >     >
>     >     > <?xml version="1.0"?>
>     >     > <node>
>     >     >   <node>text</node>
>     >     >   <node>
>     >     >     <node>
>     >     >       <node>text</node>
>     >     >       <node>text</node>
>     >     >     </node>
>     >     >     <node>text</node>
>     >     >   </node>
>     >     > </node>
>     >     >
>     >     > which leads to different digest value.
>     >     > Do I misunderstand something, or the way I used xmlsec1 is
>     wrong?
>     >     >
>     >     > Thank you
>     >     >
>     >     >
>     >     > How I do the Canonicalization with libxml:
>     >     >  get nodeset by:
>     >     >   xmlXPathEvalExpression("/descendant-or-self::node()",context)
>     >     >  then get Canonicalization by:
>     >     >   xmlC14NDocSaveTo(doc, xpathresult->nodesetval, 2, NULL, 1,
>     >     > c14noutputbuffer);
>     >     >   xmlDocPtr c14ndoc =
>     >     xmlParseMemory(c14nbuffer->content,c14nbuffer->use);
>     >     >
>     >     >
>     >     >
>     >     > _______________________________________________
>     >     > xmlsec mailing list
>     >     > xmlsec at aleksey.com <mailto:xmlsec at aleksey.com>
>     <mailto:xmlsec at aleksey.com <mailto:xmlsec at aleksey.com>>
>     >     > http://www.aleksey.com/mailman/listinfo/xmlsec
>     >
>     >
>     >
>     >
>     >
>     > _______________________________________________
>     > xmlsec mailing list
>     > xmlsec at aleksey.com <mailto:xmlsec at aleksey.com>
>     > http://www.aleksey.com/mailman/listinfo/xmlsec
> 
> 

From akitsukineko at gmail.com  Sat Jun  2 13:06:46 2012
From: akitsukineko at gmail.com (Neko)
Date: Sun, 3 Jun 2012 04:06:46 +0800
Subject: [xmlsec] About Canonicalization and Digest
In-Reply-To: <4FCA6D07.9040906@aleksey.com>
References: <CAPpBuXgdM8cU-r78eYhYgt3KVPVdZT5mgKFUyD0gZQSmckmYBQ@mail.gmail.com>
 <4FCA51EC.6000408@aleksey.com>
 <CAPpBuXjd-uer1i2AUS2_LcuavCgd8Ch=H+5AziMBXogvMdk3Gg@mail.gmail.com>
 <CAPpBuXjPMBNP0yAbPDwahonsXhiuB=9qapwjhcPgKSNndT1GNg@mail.gmail.com>
 <4FCA6421.4070808@aleksey.com>
 <CAPpBuXjVydxoCPC4EbLnAHdvdv7ykppm-a=5e=rmowcjGxEo_g@mail.gmail.com>
 <4FCA6D07.9040906@aleksey.com>
Message-ID: <CAPpBuXiiMY=PBNxAtRhAGnPQMF5qZq1MntZojxxycCcoHC_rcA@mail.gmail.com>

Thank you very very much, the option will help me a lot!
And I just found the problem of my output from libxml.
The content of xmlOutputBuffer created by xmlC14NDocSaveTo is the same of
xmlsec's Canonicalization result.
But xmlParseMemory changes the content by adding whitespace and line
breaking to make it more readable. (API says nothing about this
Sorry, I should have checked the content all along the process.
Again, thank you very much.

2012/6/3 Aleksey Sanin <aleksey at aleksey.com>

> The xmlsec1 tool has an option --store-references that shows exactly
> what was digested. Run it and see for yourself.
>
> Aleksey
>
> On 6/2/12 12:33 PM, Neko wrote:
> > But the DigestValue is the digest of original xml content,
> >  <root
> >
> xmlns="..."><node>text</node><node><node><node>text</node><node>dlink</node></node><node>text</node></node>...<root>
> >
> > Does it mean that the Canonicalization result I got is not the correct
> one?
> > <?xml version="1.0"?>
> > <node>
> >   <node>text</node>
> >   <node>
> >     <node>
> >       <node>text</node>
> >       <node>text</node>
> >     </node>
> >     <node>text</node>
> >   </node>
> > </node>
> >
> > Thank you for answering
> >
> > 2012/6/3 Aleksey Sanin <aleksey at aleksey.com <mailto:aleksey at aleksey.com
> >>
> >
> >     Yes
> >
> >     Aleksey
> >
> >     On 6/2/12 11:55 AM, Neko wrote:
> >     >
> >     > Thank you for answering.
> >     > So if signing the node inside the xml file(same-document
> reference),
> >     >  first we have to get the XPath node-set,
> >     >  then do the Canonicalization on the node-set,
> >     >  and calculating Digest of the Canonicalization result.
> >     > The original content of referenced node-set won't be changed.
> >     >
> >     > But in the test case
> >     > input
> >     >
> >     > <root>
> >     >
> >
> xmlns="..."><node>text</node><node><node><node>text</node><node>dlink</node></node><node>text</node></node>...<root>
> >     >
> >     > Canonicalization form obtained from
> libxml2(<CanonicalizationMethod>
> >     > Algorithm="http://www.w3.org/2006/12/xml-c14n11#WithComments")
> >     >
> >     > <?xml version="1.0"?>
> >     > <node>
> >     >   <node>text</node>
> >     >   <node>
> >     >     <node>
> >     >       <node>text</node>
> >     >       <node>text</node>
> >     >     </node>
> >     >     <node>text</node>
> >     >   </node>
> >     > </node>
> >     >
> >     > Shouldn't digest value base on the second one?
> >     >
> >     > Thank you
> >     >
> >     >
> >     > 2012/6/3 Aleksey Sanin <aleksey at aleksey.com
> >     <mailto:aleksey at aleksey.com> <mailto:aleksey at aleksey.com
> >     <mailto:aleksey at aleksey.com>>>
> >     >
> >     >     " ... source xml file needs Canonicalization(applied to the
> entire
> >     >     xml) ..."
> >     >
> >     >     That's not quite correct. You can not use the "entire xml"
> >     because the
> >     >     insertion of the signature changes it and the digest match
> during
> >     >     verification would fail.
> >     >
> >     >     This is the part of the spec that talks about it
> >     >
> >     >
> http://www.w3.org/TR/xmldsig-core1/#sec-ReferenceProcessingModel
> >     >
> >     >
> >     >     Aleksey
> >     >
> >     >     On 6/2/12 10:34 AM, Neko wrote:
> >     >     > Dear Aleksey
> >     >     >
> >     >     > I have a question about Canonicalization and Digest while
> using
> >     >     xmlsec1
> >     >     > to sign template xml file.
> >     >     > According to my understanding of xml signature spec provided
> >     by W3C,
> >     >     > source xml file needs Canonicalization(applied to the entire
> >     xml)
> >     >     before
> >     >     > calculating Digest.
> >     >     >
> >     >     > The template file looks like this:
> >     >     >
> >     >     > <?xml version="1.0"?>
> >     >     > <root
> >     >     >
> >     >
> >
> xmlns="..."><node>text</node><node><node><node>text</node><node>dlink</node></node><node>text</node></node><Signature
> >     >     > xmlns="http://www.w3.org/2000/09/xmldsig#">
> >     >     >    <SignedInfo>
> >     >     >         <CanonicalizationMethod
> >     >     > Algorithm="http://www.w3.org/2006/12/xml-c14n11#WithComments
> "/>
> >     >     >         <SignatureMethod
> >     >     > Algorithm="http://www.w3.org/2000/09/xmldsig#rsa-sha1"/>
> >     >     >         <Reference URI="">
> >     >     >             <Transforms>
> >     >     >                 <Transform
> >     >     >
> >     Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature" />
> >     >     >             </Transforms>
> >     >     >             <DigestMethod
> >     >     > Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/>
> >     >     >             <DigestValue></DigestValue>
> >     >     >         </Reference>
> >     >     >     </SignedInfo>
> >     >     >     <SignatureValue />
> >     >     >     <KeyInfo>
> >     >     >         <KeyValue />
> >     >     >     </KeyInfo>
> >     >     > </Signature></root>
> >     >     > (to verify my understanding, there's no space and line
> changing
> >     >     between
> >     >     > data nodes)
> >     >     >
> >     >     > In the result, xmlsec1 put desired values into proper fields,
> >     >     while the
> >     >     > original data remains the same, like:
> >     >     >
> >     >     > <root
> >     >     >
> >     >
> >
> xmlns="..."><node>text</node><node><node><node>text</node><node>dlink</node></node><node>text</node></node>...<root>
> >     >     >
> >     >     > However, I tried to do the Canonicalization with libxml, and
> the
> >     >     result
> >     >     > is like:(neglect signature node)
> >     >     >
> >     >     > <?xml version="1.0"?>
> >     >     > <node>
> >     >     >   <node>text</node>
> >     >     >   <node>
> >     >     >     <node>
> >     >     >       <node>text</node>
> >     >     >       <node>text</node>
> >     >     >     </node>
> >     >     >     <node>text</node>
> >     >     >   </node>
> >     >     > </node>
> >     >     >
> >     >     > which leads to different digest value.
> >     >     > Do I misunderstand something, or the way I used xmlsec1 is
> >     wrong?
> >     >     >
> >     >     > Thank you
> >     >     >
> >     >     >
> >     >     > How I do the Canonicalization with libxml:
> >     >     >  get nodeset by:
> >     >     >
> xmlXPathEvalExpression("/descendant-or-self::node()",context)
> >     >     >  then get Canonicalization by:
> >     >     >   xmlC14NDocSaveTo(doc, xpathresult->nodesetval, 2, NULL, 1,
> >     >     > c14noutputbuffer);
> >     >     >   xmlDocPtr c14ndoc =
> >     >     xmlParseMemory(c14nbuffer->content,c14nbuffer->use);
> >     >     >
> >     >     >
> >     >     >
> >     >     > _______________________________________________
> >     >     > xmlsec mailing list
> >     >     > xmlsec at aleksey.com <mailto:xmlsec at aleksey.com>
> >     <mailto:xmlsec at aleksey.com <mailto:xmlsec at aleksey.com>>
> >     >     > http://www.aleksey.com/mailman/listinfo/xmlsec
> >     >
> >     >
> >     >
> >     >
> >     >
> >     > _______________________________________________
> >     > xmlsec mailing list
> >     > xmlsec at aleksey.com <mailto:xmlsec at aleksey.com>
> >     > http://www.aleksey.com/mailman/listinfo/xmlsec
> >
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.aleksey.com/pipermail/xmlsec/attachments/20120603/7bc1567c/attachment.html>

From re.tf at acm.org  Tue Jun  5 13:58:31 2012
From: re.tf at acm.org (Renato Tegon Forti)
Date: Tue, 5 Jun 2012 17:58:31 -0300
Subject: [xmlsec]  Trying to check sign
Message-ID: <00fc01cd435d$f7ce89e0$e76b9da0$@acm.org>

Hi,

 

I have one file that I want check sig (using KEYINFO node), I know that the
signature is valid, but tool returns me:

 

I use DTD, see xml below, please!

 

----------------------------------------------------------------------------
--------------------

 

func=xmlSecOpenSSLX509StoreVerify:file=x509vfy.c:line=360:obj=x509-store:sub
j=X509_verify_cert:error=4:crypto library function
failed:subj=/C=BR/O=ICP-Brasil/OU=ID - 1083312/OU=Autenticado por Certisign
Certificadora Digital/OU=Assinatura Tipo A1/OU=(EM BRANCO)/OU=(EM
BRANCO)/CN=MEDIATECH INFORMATICA
LTDA/emailAddress=contato at tecnomidia.com.br;err=20;msg=unable to get local
issuer certificate

func=xmlSecOpenSSLX509StoreVerify:file=x509vfy.c:line=408:obj=x509-store:sub
j=unknown:error=71:certificate verification failed:err=20;msg=unable to get
local issuer certificate

func=xmlSecOpenSSLEvpSignatureVerify:file=signatures.c:line=346:obj=rsa-sha1
:subj=EVP_VerifyFinal:error=18:data do not match:signature do not match

RESULT: Signature is INVALID

---------------------------------------------------

= VERIFICATION CONTEXT

== Status: invalid

== flags: 0x00000000

== flags2: 0x00000000

== Key Info Read Ctx:

= KEY INFO READ CONTEXT

== flags: 0x00000000

== flags2: 0x00000000

== enabled key data: all

== RetrievalMethod level (cur/max): 0/1

== TRANSFORMS CTX (status=0)

== flags: 0x00000000

== flags2: 0x00000000

== enabled transforms: all

=== uri: NULL

=== uri xpointer expr: NULL

== EncryptedKey level (cur/max): 0/1

=== KeyReq:

==== keyId: rsa

==== keyType: 0x00000001

==== keyUsage: 0x00000002

==== keyBitsSize: 0

=== list size: 0

== Key Info Write Ctx:

= KEY INFO WRITE CONTEXT

== flags: 0x00000000

== flags2: 0x00000000

== enabled key data: all

== RetrievalMethod level (cur/max): 0/1

== TRANSFORMS CTX (status=0)

== flags: 0x00000000

== flags2: 0x00000000

== enabled transforms: all

=== uri: NULL

=== uri xpointer expr: NULL

== EncryptedKey level (cur/max): 0/1

=== KeyReq:

==== keyId: NULL

==== keyType: 0x00000001

==== keyUsage: 0xffffffff

==== keyBitsSize: 0

=== list size: 0

== Signature Transform Ctx:

== TRANSFORMS CTX (status=2)

== flags: 0x00000000

== flags2: 0x00000000

== enabled transforms: all

=== uri: NULL

=== uri xpointer expr: NULL

=== Transform: c14n (href=http://www.w3.org/TR/2001/REC-xml-c14n-20010315)

=== Transform: rsa-sha1 (href=http://www.w3.org/2000/09/xmldsig#rsa-sha1)

=== Transform: membuf-transform (href=NULL)

== Signature Method:

=== Transform: rsa-sha1 (href=http://www.w3.org/2000/09/xmldsig#rsa-sha1)

== Signature Key:

== KEY

=== method: RSAKeyValue

=== key type: Private

=== key name: test-rsa

=== key usage: -1

=== rsa key: size = 1024

== SignedInfo References List:

=== list size: 1

= REFERENCE VERIFICATION CONTEXT

== Status: succeeded

== URI: "#NFe35101003593968000167550030000101640000000003"

== Reference Transform Ctx:

== TRANSFORMS CTX (status=2)

== flags: 0x00000000

== flags2: 0x00000000

== enabled transforms: all

=== uri: 

=== uri xpointer expr: #NFe35101003593968000167550030000101640000000003

=== Transform: xpointer (href=http://www.w3.org/2001/04/xmldsig-more/xptr)

=== Transform: enveloped-signature
(href=http://www.w3.org/2000/09/xmldsig#enveloped-signature)

=== Transform: c14n (href=http://www.w3.org/TR/2001/REC-xml-c14n-20010315)

=== Transform: sha1 (href=http://www.w3.org/2000/09/xmldsig#sha1)

=== Transform: membuf-transform (href=NULL)

== Digest Method:

=== Transform: sha1 (href=http://www.w3.org/2000/09/xmldsig#sha1)

== Manifest References List:

=== list size: 0

 

----------------------------------------------------------------------------
--------------------

 

Anyone can help-me to understand what I make wrong!

What this exactly can mean: "unable to get local issuer certificate"

 

This is my xml file ( the DTD is correct?):

 

----------------------------------------------------------------------------
--------------------

 

<?xml version="1.0" encoding="UTF-8"?>

<!DOCTYPE test [

<!ATTLIST infNFe Id ID #IMPLIED>

]>

<nfeProc xmlns="http://www.portalfiscal.inf.br/nfe" versao="1.10">

<NFe xmlns="http://www.portalfiscal.inf.br/nfe"><infNFe
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
Id="NFe35101003593968000167550030000101640000000003"
versao="1.10"><ide><cUF>35</cUF><cNF>000000000</cNF><natOp>VENDA MERC C/
PGTO ST C/
SUBSTITUIDO</natOp><indPag>1</indPag><mod>55</mod><serie>3</serie><nNF>10164
</nNF><dEmi>2010-10-20</dEmi><dSaiEnt>2010-10-20</dSaiEnt><tpNF>1</tpNF><cMu
nFG>3550308</cMunFG><tpImp>1</tpImp><tpEmis>1</tpEmis><cDV>3</cDV><tpAmb>1</
tpAmb><finNFe>1</finNFe><procEmi>0</procEmi><verProc>1.4.0</verProc></ide><e
mit><CNPJ>03593968000167</CNPJ><xNome>Mediatech Informatica
LTDA</xNome><xFant>Mediatech Informatica
LTDA</xFant><enderEmit><xLgr>CORREIA DE
MELO</xLgr><nro>085</nro><xBairro>BOM
RETIRO</xBairro><cMun>3550308</cMun><xMun>SAO
PAULO</xMun><UF>SP</UF><CEP>01123020</CEP><cPais>1058</cPais><xPais>BRASIL</
xPais><fone>1133521199</fone></enderEmit><IE>115633812110</IE></emit><dest><
CNPJ>11253910000100</CNPJ><xNome>AYSSO SYSTEMS LTDA
EPP</xNome><enderDest><xLgr>RUA DOZE DE
NOVEMBRO</xLgr><nro>180</nro><xCpl>APT
183</xCpl><xBairro>CENTRO</xBairro><cMun>3501608</cMun><xMun>AMERICANA</xMun
><UF>SP</UF><CEP>13465490</CEP><cPais>1058</cPais><xPais>BRASIL</xPais><fone
>1936459994</fone></enderDest><IE/></dest><det
nItem="1"><prod><cProd>1160900000000001720000</cProd><cEAN/><xProd>MIDIA
DIGITAL
CD/DVD</xProd><NCM>85234011</NCM><CFOP>5405</CFOP><uCom>PC.</uCom><qCom>100.
0000</qCom><vUnCom>2.1500</vUnCom><vProd>215.00</vProd><cEANTrib/><uTrib>PC.
</uTrib><qTrib>100.0000</qTrib><vUnTrib>2.1500</vUnTrib><vFrete>20.00</vFret
e></prod><imposto><ICMS><ICMS60><orig>0</orig><CST>60</CST><vBCST>215.00</vB
CST><vICMSST>0.00</vICMSST></ICMS60></ICMS><IPI><cEnq>999</cEnq><IPINT><CST>
53</CST></IPINT></IPI><PIS><PISAliq><CST>01</CST><vBC>215.00</vBC><pPIS>0.65
</pPIS><vPIS>1.40</vPIS></PISAliq></PIS><COFINS><COFINSAliq><CST>01</CST><vB
C>215.00</vBC><pCOFINS>3.00</pCOFINS><vCOFINS>6.45</vCOFINS></COFINSAliq></C
OFINS></imposto></det><total><ICMSTot><vBC>20.00</vBC><vICMS>0.00</vICMS><vB
CST>0.00</vBCST><vST>0.00</vST><vProd>215.00</vProd><vFrete>20.00</vFrete><v
Seg>0.00</vSeg><vDesc>0.00</vDesc><vII>0.00</vII><vIPI>0.00</vIPI><vPIS>1.40
</vPIS><vCOFINS>6.45</vCOFINS><vOutro>0.00</vOutro><vNF>235.00</vNF></ICMSTo
t></total><transp><modFrete>0</modFrete><transporta><CNPJ>07281886000138</CN
PJ><xNome>Correio - Sedex</xNome><IE>ISENTO</IE><xEnder>Rua Correia de Melo,
111</xEnder><xMun>Sao
Paulo</xMun><UF>SP</UF></transporta><vol><qVol>1</qVol><esp>CX.</esp><pesoL>
1.000</pesoL><pesoB>1.000</pesoB></vol></transp><cobr><fat><nFat>10164</nFat
><vOrig>235.00</vOrig><vLiq>235.00</vLiq></fat><dup><nDup>001</nDup><dVenc>2
010-10-20</dVenc><vDup>235.00</vDup></dup></cobr><infAdic><infCpl>Pedidos:
48033</infCpl></infAdic></infNFe><Signature
xmlns="http://www.w3.org/2000/09/xmldsig#"><SignedInfo><CanonicalizationMeth
od
Algorithm="http://www.w3.org/TR/2001/REC-xml-c14n-20010315"/><SignatureMetho
d Algorithm="http://www.w3.org/2000/09/xmldsig#rsa-sha1"/><Reference
URI="#NFe35101003593968000167550030000101640000000003"><Transforms><Transfor
m
Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature"/><Transfor
m
Algorithm="http://www.w3.org/TR/2001/REC-xml-c14n-20010315"/></Transforms><D
igestMethod
Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/><DigestValue>vj4p6FtqkZe
n6fsHlcyag8R2hF0=</DigestValue></Reference></SignedInfo><SignatureValue>Jymb
ikn/5F8aUYQA6CaZmLYY9plO4KNfyu/M4TZP5l+3fy/pjwpkIsaeV1LXXyo7nWLdpvruhCXy

ID2ptAjzIWOJ/vp1YW94e0Yy7yfBijQNkew+FI1G7GKKt7T/UUIPRrXqWwo7EA8ZpCYSoWktWqHZ

iU7j7iJone1nLdNJNjY=</SignatureValue><KeyInfo><X509Data><X509Certificate>MII
GuzCCBaOgAwIBAgIQCbCeZ64fHJPeNqAkc06I8TANBgkqhkiG9w0BAQUFADB0MQswCQYDVQQG

EwJCUjETMBEGA1UEChMKSUNQLUJyYXNpbDEtMCsGA1UECxMkQ2VydGlzaWduIENlcnRpZmljYWRv

cmEgRGlnaXRhbCBTLkEuMSEwHwYDVQQDExhBQyBDZXJ0aXNpZ24gTXVsdGlwbGEgRzMwHhcNMTAw

NzI5MDAwMDAwWhcNMTEwNzI4MjM1OTU5WjCCAQsxCzAJBgNVBAYTAkJSMRMwEQYDVQQKFApJQ1At

QnJhc2lsMRUwEwYDVQQLFAxJRCAtIDEwODMzMTIxODA2BgNVBAsUL0F1dGVudGljYWRvIHBvciBD

ZXJ0aXNpZ24gQ2VydGlmaWNhZG9yYSBEaWdpdGFsMRswGQYDVQQLFBJBc3NpbmF0dXJhIFRpcG8g

QTExFDASBgNVBAsUCyhFTSBCUkFOQ08pMRQwEgYDVQQLFAsoRU0gQlJBTkNPKTEjMCEGA1UEAxMa

TUVESUFURUNIIElORk9STUFUSUNBIExUREExKDAmBgkqhkiG9w0BCQEWGWNvbnRhdG9AdGVjbm9t

aWRpYS5jb20uYnIwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAM8txkPNL6gjEjSW4TumyO0w

zBGmxNtCqU9DFNWQD1TWIbXaYduxoxnYEwNXrehla2YDslXUiM45SWvlmjlWoVV9T7F07aOGGysP

aNLJW/y3CMq7Qrvsh+h30INqV8WWYXKHlmfLz4eNf8Di4xQvgm+7yxvkGHXXjxkWn6utBWtJAgMB

AAGjggMyMIIDLjCBrQYDVR0RBIGlMIGioDgGBWBMAQMEoC8ELTE5MDExOTY3MTEyMDk3Mzg4MDUw

MDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMKAXBgVgTAEDAqAOBAxKQUlSIFNaQVBJUk+gGQYFYEwB

AwOgEAQOMDM1OTM5NjgwMDAxNjegFwYFYEwBAwegDgQMMDAwMDAwMDAwMDAwgRljb250YXRvQHRl

Y25vbWlkaWEuY29tLmJyMAkGA1UdEwQCMAAwHwYDVR0jBBgwFoAUhLBCMzSjQiWlKJc+g+t38OhP

wlQwDgYDVR0PAQH/BAQDAgXgMFUGA1UdIAROMEwwSgYGYEwBAgELMEAwPgYIKwYBBQUHAgEWMmh0

dHA6Ly9pY3AtYnJhc2lsLmNlcnRpc2lnbi5jb20uYnIvcmVwb3NpdG9yaW8vZHBjMIIBJQYDVR0f

BIIBHDCCARgwXKBaoFiGVmh0dHA6Ly9pY3AtYnJhc2lsLmNlcnRpc2lnbi5jb20uYnIvcmVwb3Np

dG9yaW8vbGNyL0FDQ2VydGlzaWduTXVsdGlwbGFHMy9MYXRlc3RDUkwuY3JsMFugWaBXhlVodHRw

Oi8vaWNwLWJyYXNpbC5vdXRyYWxjci5jb20uYnIvcmVwb3NpdG9yaW8vbGNyL0FDQ2VydGlzaWdu

TXVsdGlwbGFHMy9MYXRlc3RDUkwuY3JsMFugWaBXhlVodHRwOi8vcmVwb3NpdG9yaW8uaWNwYnJh

c2lsLmdvdi5ici9sY3IvQ2VydGlzaWduL0FDQ2VydGlzaWduTXVsdGlwbGFHMy9MYXRlc3RDUkwu

Y3JsMB0GA1UdJQQWMBQGCCsGAQUFBwMEBggrBgEFBQcDAjCBoAYIKwYBBQUHAQEEgZMwgZAwKAYI

KwYBBQUHMAGGHGh0dHA6Ly9vY3NwLmNlcnRpc2lnbi5jb20uYnIwZAYIKwYBBQUHMAKGWGh0dHA6

Ly9pY3AtYnJhc2lsLmNlcnRpc2lnbi5jb20uYnIvcmVwb3NpdG9yaW8vY2VydGlmaWNhZG9zL0FD

X0NlcnRpc2lnbl9NdWx0aXBsYV9HMy5wN2MwDQYJKoZIhvcNAQEFBQADggEBAGI9MCc6WVmz919C

QLDB8E0R8HxfGyiz2uB14lPBDsueTJmJmlykQdnboMiyMGTocprEGsQxeI7a57BEUDVc0fSzNCCb

SOnQOp9Uswri8pTw8fQG9OAkh1LCC9haTsNNMKbTHCciO7MUh34XkHuj4A0NIWG1aCynwstRFWb8

97OZJJCc0IRvDs7yDJhgOwPmv3trFmwlfMU7n20pXtM9hKiI8o6h/0GwR6SyA1Yj4fZXfXxVENH4

EjhIHR8Yrmre2JE2I+hFjyQaNPnAEztQEa0Cae2l3O0Q0tkM1x8EkiKFrnDggpc7gSwtLCwrkQBu

jhie131VyDTuXLx9k082PLs=</X509Certificate></X509Data></KeyInfo></Signature><
/NFe>

 

<protNFe
versao="1.10"><infProt><tpAmb>1</tpAmb><verAplic>SP_NFE_PL_005e</verAplic><c
hNFe>35101003593968000167550030000101640000000003</chNFe><dhRecbto>2010-10-2
0T17:48:15</dhRecbto><nProt>135100546996360</nProt><digVal>vj4p6FtqkZen6fsHl
cyag8R2hF0=</digVal><cStat>100</cStat><xMotivo>Autorizado o uso da
NF-e</xMotivo></infProt></protNFe>

</nfeProc>

 

----------------------------------------------------------------------------
--------------------

 

Thanks a lot

 

 

 

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.aleksey.com/pipermail/xmlsec/attachments/20120605/c40910cc/attachment-0001.html>

From aleksey at aleksey.com  Tue Jun  5 19:50:46 2012
From: aleksey at aleksey.com (Aleksey Sanin)
Date: Tue, 05 Jun 2012 19:50:46 -0700
Subject: [xmlsec] Trying to check sign
In-Reply-To: <00fc01cd435d$f7ce89e0$e76b9da0$@acm.org>
References: <00fc01cd435d$f7ce89e0$e76b9da0$@acm.org>
Message-ID: <4FCEC586.3010703@aleksey.com>

This means that xmlsec (or to be precise, openssl) needs to verify the
certificate and it can't find the next certificate in the chain.

Aleksey

On 6/5/12 1:58 PM, Renato Tegon Forti wrote:
> Hi,
> 
>  
> 
> I have one file that I want check sig (using KEYINFO node), I know that
> the signature is valid, but tool returns me:
> 
>  
> 
> I use DTD, see xml below, please!
> 
>  
> 
> ------------------------------------------------------------------------------------------------
> 
>  
> 
> func=xmlSecOpenSSLX509StoreVerify:file=x509vfy.c:line=360:obj=x509-store:subj=X509_verify_cert:error=4:crypto
> library function failed:subj=/C=BR/O=ICP-Brasil/OU=ID -
> 1083312/OU=Autenticado por Certisign Certificadora Digital/OU=Assinatura
> Tipo A1/OU=(EM BRANCO)/OU=(EM BRANCO)/CN=MEDIATECH INFORMATICA
> LTDA/emailAddress=contato at tecnomidia.com.br;err=20;msg=unable
> <mailto:LTDA/emailAddress=contato at tecnomidia.com.br;err=20;msg=unable>
> to get local issuer certificate
> 
> func=xmlSecOpenSSLX509StoreVerify:file=x509vfy.c:line=408:obj=x509-store:subj=unknown:error=71:certificate
> verification failed:err=20;msg=unable to get local issuer certificate
> 
> func=xmlSecOpenSSLEvpSignatureVerify:file=signatures.c:line=346:obj=rsa-sha1:subj=EVP_VerifyFinal:error=18:data
> do not match:signature do not match
> 
> RESULT: Signature is INVALID
> 
> ---------------------------------------------------
> 
> = VERIFICATION CONTEXT
> 
> == Status: invalid
> 
> == flags: 0x00000000
> 
> == flags2: 0x00000000
> 
> == Key Info Read Ctx:
> 
> = KEY INFO READ CONTEXT
> 
> == flags: 0x00000000
> 
> == flags2: 0x00000000
> 
> == enabled key data: all
> 
> == RetrievalMethod level (cur/max): 0/1
> 
> == TRANSFORMS CTX (status=0)
> 
> == flags: 0x00000000
> 
> == flags2: 0x00000000
> 
> == enabled transforms: all
> 
> === uri: NULL
> 
> === uri xpointer expr: NULL
> 
> == EncryptedKey level (cur/max): 0/1
> 
> === KeyReq:
> 
> ==== keyId: rsa
> 
> ==== keyType: 0x00000001
> 
> ==== keyUsage: 0x00000002
> 
> ==== keyBitsSize: 0
> 
> === list size: 0
> 
> == Key Info Write Ctx:
> 
> = KEY INFO WRITE CONTEXT
> 
> == flags: 0x00000000
> 
> == flags2: 0x00000000
> 
> == enabled key data: all
> 
> == RetrievalMethod level (cur/max): 0/1
> 
> == TRANSFORMS CTX (status=0)
> 
> == flags: 0x00000000
> 
> == flags2: 0x00000000
> 
> == enabled transforms: all
> 
> === uri: NULL
> 
> === uri xpointer expr: NULL
> 
> == EncryptedKey level (cur/max): 0/1
> 
> === KeyReq:
> 
> ==== keyId: NULL
> 
> ==== keyType: 0x00000001
> 
> ==== keyUsage: 0xffffffff
> 
> ==== keyBitsSize: 0
> 
> === list size: 0
> 
> == Signature Transform Ctx:
> 
> == TRANSFORMS CTX (status=2)
> 
> == flags: 0x00000000
> 
> == flags2: 0x00000000
> 
> == enabled transforms: all
> 
> === uri: NULL
> 
> === uri xpointer expr: NULL
> 
> === Transform: c14n (href=http://www.w3.org/TR/2001/REC-xml-c14n-20010315)
> 
> === Transform: rsa-sha1 (href=http://www.w3.org/2000/09/xmldsig#rsa-sha1)
> 
> === Transform: membuf-transform (href=NULL)
> 
> == Signature Method:
> 
> === Transform: rsa-sha1 (href=http://www.w3.org/2000/09/xmldsig#rsa-sha1)
> 
> == Signature Key:
> 
> == KEY
> 
> === method: RSAKeyValue
> 
> === key type: Private
> 
> === key name: test-rsa
> 
> === key usage: -1
> 
> === rsa key: size = 1024
> 
> == SignedInfo References List:
> 
> === list size: 1
> 
> = REFERENCE VERIFICATION CONTEXT
> 
> == Status: succeeded
> 
> == URI: "#NFe35101003593968000167550030000101640000000003"
> 
> == Reference Transform Ctx:
> 
> == TRANSFORMS CTX (status=2)
> 
> == flags: 0x00000000
> 
> == flags2: 0x00000000
> 
> == enabled transforms: all
> 
> === uri:
> 
> === uri xpointer expr: #NFe35101003593968000167550030000101640000000003
> 
> === Transform: xpointer (href=http://www.w3.org/2001/04/xmldsig-more/xptr)
> 
> === Transform: enveloped-signature
> (href=http://www.w3.org/2000/09/xmldsig#enveloped-signature)
> 
> === Transform: c14n (href=http://www.w3.org/TR/2001/REC-xml-c14n-20010315)
> 
> === Transform: sha1 (href=http://www.w3.org/2000/09/xmldsig#sha1)
> 
> === Transform: membuf-transform (href=NULL)
> 
> == Digest Method:
> 
> === Transform: sha1 (href=http://www.w3.org/2000/09/xmldsig#sha1)
> 
> == Manifest References List:
> 
> === list size: 0
> 
>  
> 
> ------------------------------------------------------------------------------------------------
> 
>  
> 
> Anyone can help-me to understand what I make wrong!
> 
> What this exactly can mean: ?unable to get local issuer certificate?
> 
>  
> 
> This is my xml file ( the DTD is correct?):
> 
>  
> 
> ------------------------------------------------------------------------------------------------
> 
>  
> 
> <?xml version="1.0" encoding="UTF-8"?>
> 
> <!DOCTYPE test [
> 
> <!ATTLIST infNFe Id ID #IMPLIED>
> 
> ]>
> 
> <nfeProc xmlns="http://www.portalfiscal.inf.br/nfe" versao="1.10">
> 
> <NFe xmlns="http://www.portalfiscal.inf.br/nfe"><infNFe
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
> Id="NFe35101003593968000167550030000101640000000003"
> versao="1.10"><ide><cUF>35</cUF><cNF>000000000</cNF><natOp>VENDA MERC C/
> PGTO ST C/
> SUBSTITUIDO</natOp><indPag>1</indPag><mod>55</mod><serie>3</serie><nNF>10164</nNF><dEmi>2010-10-20</dEmi><dSaiEnt>2010-10-20</dSaiEnt><tpNF>1</tpNF><cMunFG>3550308</cMunFG><tpImp>1</tpImp><tpEmis>1</tpEmis><cDV>3</cDV><tpAmb>1</tpAmb><finNFe>1</finNFe><procEmi>0</procEmi><verProc>1.4.0</verProc></ide><emit><CNPJ>03593968000167</CNPJ><xNome>Mediatech
> Informatica LTDA</xNome><xFant>Mediatech Informatica
> LTDA</xFant><enderEmit><xLgr>CORREIA DE
> MELO</xLgr><nro>085</nro><xBairro>BOM
> RETIRO</xBairro><cMun>3550308</cMun><xMun>SAO
> PAULO</xMun><UF>SP</UF><CEP>01123020</CEP><cPais>1058</cPais><xPais>BRASIL</xPais><fone>1133521199</fone></enderEmit><IE>115633812110</IE></emit><dest><CNPJ>11253910000100</CNPJ><xNome>AYSSO
> SYSTEMS LTDA EPP</xNome><enderDest><xLgr>RUA DOZE DE
> NOVEMBRO</xLgr><nro>180</nro><xCpl>APT
> 183</xCpl><xBairro>CENTRO</xBairro><cMun>3501608</cMun><xMun>AMERICANA</xMun><UF>SP</UF><CEP>13465490</CEP><cPais>1058</cPais><xPais>BRASIL</xPais><fone>1936459994</fone></enderDest><IE/></dest><det
> nItem="1"><prod><cProd>1160900000000001720000</cProd><cEAN/><xProd>MIDIA
> DIGITAL
> CD/DVD</xProd><NCM>85234011</NCM><CFOP>5405</CFOP><uCom>PC.</uCom><qCom>100.0000</qCom><vUnCom>2.1500</vUnCom><vProd>215.00</vProd><cEANTrib/><uTrib>PC.</uTrib><qTrib>100.0000</qTrib><vUnTrib>2.1500</vUnTrib><vFrete>20.00</vFrete></prod><imposto><ICMS><ICMS60><orig>0</orig><CST>60</CST><vBCST>215.00</vBCST><vICMSST>0.00</vICMSST></ICMS60></ICMS><IPI><cEnq>999</cEnq><IPINT><CST>53</CST></IPINT></IPI><PIS><PISAliq><CST>01</CST><vBC>215.00</vBC><pPIS>0.65</pPIS><vPIS>1.40</vPIS></PISAliq></PIS><COFINS><COFINSAliq><CST>01</CST><vBC>215.00</vBC><pCOFINS>3.00</pCOFINS><vCOFINS>6.45</vCOFINS></COFINSAliq></COFINS></imposto></det><total><ICMSTot><vBC>20.00</vBC><vICMS>0.00</vICMS><vBCST>0.00</vBCST><vST>0.00</vST><vProd>215.00</vProd><vFrete>20.00</vFrete><vSeg>0.00</vSeg><vDesc>0.00</vDesc><vII>0.00</vII><vIPI>0.00</vIPI><vPIS>1.40</vPIS><vCOFINS>6.45</vCOFINS><vOutro>0.00</vOutro><vNF>235.00</vNF></ICMSTot></total><transp><modFrete>0</modFrete><transporta><CNPJ>07281886000138</CNPJ><xNome
>Correio
> - Sedex</xNome><IE>ISENTO</IE><xEnder>Rua Correia de Melo,
> 111</xEnder><xMun>Sao
> Paulo</xMun><UF>SP</UF></transporta><vol><qVol>1</qVol><esp>CX.</esp><pesoL>1.000</pesoL><pesoB>1.000</pesoB></vol></transp><cobr><fat><nFat>10164</nFat><vOrig>235.00</vOrig><vLiq>235.00</vLiq></fat><dup><nDup>001</nDup><dVenc>2010-10-20</dVenc><vDup>235.00</vDup></dup></cobr><infAdic><infCpl>Pedidos:
> 48033</infCpl></infAdic></infNFe><Signature
> xmlns="http://www.w3.org/2000/09/xmldsig#"><SignedInfo><CanonicalizationMethod
> Algorithm="http://www.w3.org/TR/2001/REC-xml-c14n-20010315"/><SignatureMethod
> Algorithm="http://www.w3.org/2000/09/xmldsig#rsa-sha1"/><Reference
> URI="#NFe35101003593968000167550030000101640000000003"><Transforms><Transform
> Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature"/><Transform
> Algorithm="http://www.w3.org/TR/2001/REC-xml-c14n-20010315"/></Transforms><DigestMethod
> Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/><DigestValue>vj4p6FtqkZen6fsHlcyag8R2hF0=</DigestValue></Reference></SignedInfo><SignatureValue>Jymbikn/5F8aUYQA6CaZmLYY9plO4KNfyu/M4TZP5l+3fy/pjwpkIsaeV1LXXyo7nWLdpvruhCXy
> 
> ID2ptAjzIWOJ/vp1YW94e0Yy7yfBijQNkew+FI1G7GKKt7T/UUIPRrXqWwo7EA8ZpCYSoWktWqHZ
> 
> iU7j7iJone1nLdNJNjY=</SignatureValue><KeyInfo><X509Data><X509Certificate>MIIGuzCCBaOgAwIBAgIQCbCeZ64fHJPeNqAkc06I8TANBgkqhkiG9w0BAQUFADB0MQswCQYDVQQG
> 
> EwJCUjETMBEGA1UEChMKSUNQLUJyYXNpbDEtMCsGA1UECxMkQ2VydGlzaWduIENlcnRpZmljYWRv
> 
> cmEgRGlnaXRhbCBTLkEuMSEwHwYDVQQDExhBQyBDZXJ0aXNpZ24gTXVsdGlwbGEgRzMwHhcNMTAw
> 
> NzI5MDAwMDAwWhcNMTEwNzI4MjM1OTU5WjCCAQsxCzAJBgNVBAYTAkJSMRMwEQYDVQQKFApJQ1At
> 
> QnJhc2lsMRUwEwYDVQQLFAxJRCAtIDEwODMzMTIxODA2BgNVBAsUL0F1dGVudGljYWRvIHBvciBD
> 
> ZXJ0aXNpZ24gQ2VydGlmaWNhZG9yYSBEaWdpdGFsMRswGQYDVQQLFBJBc3NpbmF0dXJhIFRpcG8g
> 
> QTExFDASBgNVBAsUCyhFTSBCUkFOQ08pMRQwEgYDVQQLFAsoRU0gQlJBTkNPKTEjMCEGA1UEAxMa
> 
> TUVESUFURUNIIElORk9STUFUSUNBIExUREExKDAmBgkqhkiG9w0BCQEWGWNvbnRhdG9AdGVjbm9t
> 
> aWRpYS5jb20uYnIwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAM8txkPNL6gjEjSW4TumyO0w
> 
> zBGmxNtCqU9DFNWQD1TWIbXaYduxoxnYEwNXrehla2YDslXUiM45SWvlmjlWoVV9T7F07aOGGysP
> 
> aNLJW/y3CMq7Qrvsh+h30INqV8WWYXKHlmfLz4eNf8Di4xQvgm+7yxvkGHXXjxkWn6utBWtJAgMB
> 
> AAGjggMyMIIDLjCBrQYDVR0RBIGlMIGioDgGBWBMAQMEoC8ELTE5MDExOTY3MTEyMDk3Mzg4MDUw
> 
> MDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMKAXBgVgTAEDAqAOBAxKQUlSIFNaQVBJUk+gGQYFYEwB
> 
> AwOgEAQOMDM1OTM5NjgwMDAxNjegFwYFYEwBAwegDgQMMDAwMDAwMDAwMDAwgRljb250YXRvQHRl
> 
> Y25vbWlkaWEuY29tLmJyMAkGA1UdEwQCMAAwHwYDVR0jBBgwFoAUhLBCMzSjQiWlKJc+g+t38OhP
> 
> wlQwDgYDVR0PAQH/BAQDAgXgMFUGA1UdIAROMEwwSgYGYEwBAgELMEAwPgYIKwYBBQUHAgEWMmh0
> 
> dHA6Ly9pY3AtYnJhc2lsLmNlcnRpc2lnbi5jb20uYnIvcmVwb3NpdG9yaW8vZHBjMIIBJQYDVR0f
> 
> BIIBHDCCARgwXKBaoFiGVmh0dHA6Ly9pY3AtYnJhc2lsLmNlcnRpc2lnbi5jb20uYnIvcmVwb3Np
> 
> dG9yaW8vbGNyL0FDQ2VydGlzaWduTXVsdGlwbGFHMy9MYXRlc3RDUkwuY3JsMFugWaBXhlVodHRw
> 
> Oi8vaWNwLWJyYXNpbC5vdXRyYWxjci5jb20uYnIvcmVwb3NpdG9yaW8vbGNyL0FDQ2VydGlzaWdu
> 
> TXVsdGlwbGFHMy9MYXRlc3RDUkwuY3JsMFugWaBXhlVodHRwOi8vcmVwb3NpdG9yaW8uaWNwYnJh
> 
> c2lsLmdvdi5ici9sY3IvQ2VydGlzaWduL0FDQ2VydGlzaWduTXVsdGlwbGFHMy9MYXRlc3RDUkwu
> 
> Y3JsMB0GA1UdJQQWMBQGCCsGAQUFBwMEBggrBgEFBQcDAjCBoAYIKwYBBQUHAQEEgZMwgZAwKAYI
> 
> KwYBBQUHMAGGHGh0dHA6Ly9vY3NwLmNlcnRpc2lnbi5jb20uYnIwZAYIKwYBBQUHMAKGWGh0dHA6
> 
> Ly9pY3AtYnJhc2lsLmNlcnRpc2lnbi5jb20uYnIvcmVwb3NpdG9yaW8vY2VydGlmaWNhZG9zL0FD
> 
> X0NlcnRpc2lnbl9NdWx0aXBsYV9HMy5wN2MwDQYJKoZIhvcNAQEFBQADggEBAGI9MCc6WVmz919C
> 
> QLDB8E0R8HxfGyiz2uB14lPBDsueTJmJmlykQdnboMiyMGTocprEGsQxeI7a57BEUDVc0fSzNCCb
> 
> SOnQOp9Uswri8pTw8fQG9OAkh1LCC9haTsNNMKbTHCciO7MUh34XkHuj4A0NIWG1aCynwstRFWb8
> 
> 97OZJJCc0IRvDs7yDJhgOwPmv3trFmwlfMU7n20pXtM9hKiI8o6h/0GwR6SyA1Yj4fZXfXxVENH4
> 
> EjhIHR8Yrmre2JE2I+hFjyQaNPnAEztQEa0Cae2l3O0Q0tkM1x8EkiKFrnDggpc7gSwtLCwrkQBu
> 
> jhie131VyDTuXLx9k082PLs=</X509Certificate></X509Data></KeyInfo></Signature></NFe>
> 
>  
> 
> <protNFe
> versao="1.10"><infProt><tpAmb>1</tpAmb><verAplic>SP_NFE_PL_005e</verAplic><chNFe>35101003593968000167550030000101640000000003</chNFe><dhRecbto>2010-10-20T17:48:15</dhRecbto><nProt>135100546996360</nProt><digVal>vj4p6FtqkZen6fsHlcyag8R2hF0=</digVal><cStat>100</cStat><xMotivo>Autorizado
> o uso da NF-e</xMotivo></infProt></protNFe>
> 
> </nfeProc>
> 
>  
> 
> ------------------------------------------------------------------------------------------------
> 
>  
> 
> Thanks a lot
> 
>  
> 
>  
> 
>  
> 
>  
> 
> 
> 
> _______________________________________________
> xmlsec mailing list
> xmlsec at aleksey.com
> http://www.aleksey.com/mailman/listinfo/xmlsec

From re.tf at acm.org  Wed Jun  6 04:42:34 2012
From: re.tf at acm.org (Renato Tegon Forti)
Date: Wed, 6 Jun 2012 08:42:34 -0300
Subject: [xmlsec] RES:   Trying to check sign
In-Reply-To: <4FCEC586.3010703@aleksey.com>
References: <00fc01cd435d$f7ce89e0$e76b9da0$@acm.org>
 <4FCEC586.3010703@aleksey.com>
Message-ID: <012001cd43d9$77e0fc50$67a2f4f0$@acm.org>

>> This means that xmlsec (or to be precise, openssl) needs to verify the
certificate and it can't find the next certificate in the chain.

Thanks for answer. 

One more question: what is the example
(http://www.aleksey.com/xmlsec/api/xmlsec-examples.html) that implement
"Online XML Digital Signature Verifer"? 
I want study code implementation of it!

Thanks

-----Mensagem original-----
De: Aleksey Sanin [mailto:aleksey at aleksey.com] 
Enviada em: ter?a-feira, 5 de junho de 2012 23:51
Para: Renato Tegon Forti
Cc: xmlsec at aleksey.com
Assunto: Re: [xmlsec] Trying to check sign

This means that xmlsec (or to be precise, openssl) needs to verify the
certificate and it can't find the next certificate in the chain.

Aleksey

On 6/5/12 1:58 PM, Renato Tegon Forti wrote:
> Hi,
> 
>  
> 
> I have one file that I want check sig (using KEYINFO node), I know 
> that the signature is valid, but tool returns me:
> 
>  
> 
> I use DTD, see xml below, please!
> 
>  
> 
> ----------------------------------------------------------------------
> --------------------------
> 
>  
> 
> func=xmlSecOpenSSLX509StoreVerify:file=x509vfy.c:line=360:obj=x509-sto
> re:subj=X509_verify_cert:error=4:crypto
> library function failed:subj=/C=BR/O=ICP-Brasil/OU=ID - 
> 1083312/OU=Autenticado por Certisign Certificadora 
> Digital/OU=Assinatura Tipo A1/OU=(EM BRANCO)/OU=(EM 
> BRANCO)/CN=MEDIATECH INFORMATICA 
> LTDA/emailAddress=contato at tecnomidia.com.br;err=20;msg=unable
> <mailto:LTDA/emailAddress=contato at tecnomidia.com.br;err=20;msg=unable>
> to get local issuer certificate
> 
> func=xmlSecOpenSSLX509StoreVerify:file=x509vfy.c:line=408:obj=x509-sto
> re:subj=unknown:error=71:certificate
> verification failed:err=20;msg=unable to get local issuer certificate
> 
> func=xmlSecOpenSSLEvpSignatureVerify:file=signatures.c:line=346:obj=rs
> a-sha1:subj=EVP_VerifyFinal:error=18:data
> do not match:signature do not match
> 
> RESULT: Signature is INVALID
> 
> ---------------------------------------------------
> 
> = VERIFICATION CONTEXT
> 
> == Status: invalid
> 
> == flags: 0x00000000
> 
> == flags2: 0x00000000
> 
> == Key Info Read Ctx:
> 
> = KEY INFO READ CONTEXT
> 
> == flags: 0x00000000
> 
> == flags2: 0x00000000
> 
> == enabled key data: all
> 
> == RetrievalMethod level (cur/max): 0/1
> 
> == TRANSFORMS CTX (status=0)
> 
> == flags: 0x00000000
> 
> == flags2: 0x00000000
> 
> == enabled transforms: all
> 
> === uri: NULL
> 
> === uri xpointer expr: NULL
> 
> == EncryptedKey level (cur/max): 0/1
> 
> === KeyReq:
> 
> ==== keyId: rsa
> 
> ==== keyType: 0x00000001
> 
> ==== keyUsage: 0x00000002
> 
> ==== keyBitsSize: 0
> 
> === list size: 0
> 
> == Key Info Write Ctx:
> 
> = KEY INFO WRITE CONTEXT
> 
> == flags: 0x00000000
> 
> == flags2: 0x00000000
> 
> == enabled key data: all
> 
> == RetrievalMethod level (cur/max): 0/1
> 
> == TRANSFORMS CTX (status=0)
> 
> == flags: 0x00000000
> 
> == flags2: 0x00000000
> 
> == enabled transforms: all
> 
> === uri: NULL
> 
> === uri xpointer expr: NULL
> 
> == EncryptedKey level (cur/max): 0/1
> 
> === KeyReq:
> 
> ==== keyId: NULL
> 
> ==== keyType: 0x00000001
> 
> ==== keyUsage: 0xffffffff
> 
> ==== keyBitsSize: 0
> 
> === list size: 0
> 
> == Signature Transform Ctx:
> 
> == TRANSFORMS CTX (status=2)
> 
> == flags: 0x00000000
> 
> == flags2: 0x00000000
> 
> == enabled transforms: all
> 
> === uri: NULL
> 
> === uri xpointer expr: NULL
> 
> === Transform: c14n 
> (href=http://www.w3.org/TR/2001/REC-xml-c14n-20010315)
> 
> === Transform: rsa-sha1 
> (href=http://www.w3.org/2000/09/xmldsig#rsa-sha1)
> 
> === Transform: membuf-transform (href=NULL)
> 
> == Signature Method:
> 
> === Transform: rsa-sha1 
> (href=http://www.w3.org/2000/09/xmldsig#rsa-sha1)
> 
> == Signature Key:
> 
> == KEY
> 
> === method: RSAKeyValue
> 
> === key type: Private
> 
> === key name: test-rsa
> 
> === key usage: -1
> 
> === rsa key: size = 1024
> 
> == SignedInfo References List:
> 
> === list size: 1
> 
> = REFERENCE VERIFICATION CONTEXT
> 
> == Status: succeeded
> 
> == URI: "#NFe35101003593968000167550030000101640000000003"
> 
> == Reference Transform Ctx:
> 
> == TRANSFORMS CTX (status=2)
> 
> == flags: 0x00000000
> 
> == flags2: 0x00000000
> 
> == enabled transforms: all
> 
> === uri:
> 
> === uri xpointer expr: 
> #NFe35101003593968000167550030000101640000000003
> 
> === Transform: xpointer 
> (href=http://www.w3.org/2001/04/xmldsig-more/xptr)
> 
> === Transform: enveloped-signature
> (href=http://www.w3.org/2000/09/xmldsig#enveloped-signature)
> 
> === Transform: c14n 
> (href=http://www.w3.org/TR/2001/REC-xml-c14n-20010315)
> 
> === Transform: sha1 (href=http://www.w3.org/2000/09/xmldsig#sha1)
> 
> === Transform: membuf-transform (href=NULL)
> 
> == Digest Method:
> 
> === Transform: sha1 (href=http://www.w3.org/2000/09/xmldsig#sha1)
> 
> == Manifest References List:
> 
> === list size: 0
> 
>  
> 
> ----------------------------------------------------------------------
> --------------------------
> 
>  
> 
> Anyone can help-me to understand what I make wrong!
> 
> What this exactly can mean: ?unable to get local issuer certificate?
> 
>  
> 
> This is my xml file ( the DTD is correct?):
> 
>  
> 
> ----------------------------------------------------------------------
> --------------------------
> 
>  
> 
> <?xml version="1.0" encoding="UTF-8"?>
> 
> <!DOCTYPE test [
> 
> <!ATTLIST infNFe Id ID #IMPLIED>
> 
> ]>
> 
> <nfeProc xmlns="http://www.portalfiscal.inf.br/nfe" versao="1.10">
> 
> <NFe xmlns="http://www.portalfiscal.inf.br/nfe"><infNFe
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
> Id="NFe35101003593968000167550030000101640000000003"
> versao="1.10"><ide><cUF>35</cUF><cNF>000000000</cNF><natOp>VENDA MERC 
> C/ PGTO ST C/ 
> SUBSTITUIDO</natOp><indPag>1</indPag><mod>55</mod><serie>3</serie><nNF
> >10164</nNF><dEmi>2010-10-20</dEmi><dSaiEnt>2010-10-20</dSaiEnt><tpNF>
> 1</tpNF><cMunFG>3550308</cMunFG><tpImp>1</tpImp><tpEmis>1</tpEmis><cDV
> >3</cDV><tpAmb>1</tpAmb><finNFe>1</finNFe><procEmi>0</procEmi><verProc
> >1.4.0</verProc></ide><emit><CNPJ>03593968000167</CNPJ><xNome>Mediatec
> h Informatica LTDA</xNome><xFant>Mediatech Informatica 
> LTDA</xFant><enderEmit><xLgr>CORREIA DE 
> MELO</xLgr><nro>085</nro><xBairro>BOM
> RETIRO</xBairro><cMun>3550308</cMun><xMun>SAO
> PAULO</xMun><UF>SP</UF><CEP>01123020</CEP><cPais>1058</cPais><xPais>BR
> ASIL</xPais><fone>1133521199</fone></enderEmit><IE>115633812110</IE></
> emit><dest><CNPJ>11253910000100</CNPJ><xNome>AYSSO
> SYSTEMS LTDA EPP</xNome><enderDest><xLgr>RUA DOZE DE 
> NOVEMBRO</xLgr><nro>180</nro><xCpl>APT
> 183</xCpl><xBairro>CENTRO</xBairro><cMun>3501608</cMun><xMun>AMERICANA
> </xMun><UF>SP</UF><CEP>13465490</CEP><cPais>1058</cPais><xPais>BRASIL<
> /xPais><fone>1936459994</fone></enderDest><IE/></dest><det
> nItem="1"><prod><cProd>1160900000000001720000</cProd><cEAN/><xProd>MID
> IA
> DIGITAL
> CD/DVD</xProd><NCM>85234011</NCM><CFOP>5405</CFOP><uCom>PC.</uCom><qCo
> m>100.0000</qCom><vUnCom>2.1500</vUnCom><vProd>215.00</vProd><cEANTrib
> /><uTrib>PC.</uTrib><qTrib>100.0000</qTrib><vUnTrib>2.1500</vUnTrib><v
> Frete>20.00</vFrete></prod><imposto><ICMS><ICMS60><orig>0</orig><CST>6
> 0</CST><vBCST>215.00</vBCST><vICMSST>0.00</vICMSST></ICMS60></ICMS><IP
> I><cEnq>999</cEnq><IPINT><CST>53</CST></IPINT></IPI><PIS><PISAliq><CST
> >01</CST><vBC>215.00</vBC><pPIS>0.65</pPIS><vPIS>1.40</vPIS></PISAliq>
> </PIS><COFINS><COFINSAliq><CST>01</CST><vBC>215.00</vBC><pCOFINS>3.00<
> /pCOFINS><vCOFINS>6.45</vCOFINS></COFINSAliq></COFINS></imposto></det>
> <total><ICMSTot><vBC>20.00</vBC><vICMS>0.00</vICMS><vBCST>0.00</vBCST>
> <vST>0.00</vST><vProd>215.00</vProd><vFrete>20.00</vFrete><vSeg>0.00</
> vSeg><vDesc>0.00</vDesc><vII>0.00</vII><vIPI>0.00</vIPI><vPIS>1.40</vP
> IS><vCOFINS>6.45</vCOFINS><vOutro>0.00</vOutro><vNF>235.00</vNF></ICMS
> Tot></total><transp><modFrete>0</modFrete><transporta><CNPJ>0728188600
> 0138</CNPJ><xNom
 e
>Correio
> - Sedex</xNome><IE>ISENTO</IE><xEnder>Rua Correia de Melo,  
>111</xEnder><xMun>Sao
>
Paulo</xMun><UF>SP</UF></transporta><vol><qVol>1</qVol><esp>CX.</esp><pesoL>
1.000</pesoL><pesoB>1.000</pesoB></vol></transp><cobr><fat><nFat>10164</nFat
><vOrig>235.00</vOrig><vLiq>235.00</vLiq></fat><dup><nDup>001</nDup><dVenc>2
010-10-20</dVenc><vDup>235.00</vDup></dup></cobr><infAdic><infCpl>Pedidos:
> 48033</infCpl></infAdic></infNFe><Signature
> 
>xmlns="http://www.w3.org/2000/09/xmldsig#"><SignedInfo><Canonicalizatio
>nMethod  
>Algorithm="http://www.w3.org/TR/2001/REC-xml-c14n-20010315"/><Signature
>Method  
>Algorithm="http://www.w3.org/2000/09/xmldsig#rsa-sha1"/><Reference
> 
>URI="#NFe35101003593968000167550030000101640000000003"><Transforms><Tra
>nsform  
>Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature"/><Tra
>nsform  
>Algorithm="http://www.w3.org/TR/2001/REC-xml-c14n-20010315"/></Transfor
>ms><DigestMethod  
>Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/><DigestValue>vj4p6F
>tqkZen6fsHlcyag8R2hF0=</DigestValue></Reference></SignedInfo><Signature
>Value>Jymbikn/5F8aUYQA6CaZmLYY9plO4KNfyu/M4TZP5l+3fy/pjwpkIsaeV1LXXyo7n
>WLdpvruhCXy
> 
> ID2ptAjzIWOJ/vp1YW94e0Yy7yfBijQNkew+FI1G7GKKt7T/UUIPRrXqWwo7EA8ZpCYSoW
> ktWqHZ
> 
> iU7j7iJone1nLdNJNjY=</SignatureValue><KeyInfo><X509Data><X509Certifica
> te>MIIGuzCCBaOgAwIBAgIQCbCeZ64fHJPeNqAkc06I8TANBgkqhkiG9w0BAQUFADB0MQs
> wCQYDVQQG
> 
> EwJCUjETMBEGA1UEChMKSUNQLUJyYXNpbDEtMCsGA1UECxMkQ2VydGlzaWduIENlcnRpZm
> ljYWRv
> 
> cmEgRGlnaXRhbCBTLkEuMSEwHwYDVQQDExhBQyBDZXJ0aXNpZ24gTXVsdGlwbGEgRzMwHh
> cNMTAw
> 
> NzI5MDAwMDAwWhcNMTEwNzI4MjM1OTU5WjCCAQsxCzAJBgNVBAYTAkJSMRMwEQYDVQQKFA
> pJQ1At
> 
> QnJhc2lsMRUwEwYDVQQLFAxJRCAtIDEwODMzMTIxODA2BgNVBAsUL0F1dGVudGljYWRvIH
> BvciBD
> 
> ZXJ0aXNpZ24gQ2VydGlmaWNhZG9yYSBEaWdpdGFsMRswGQYDVQQLFBJBc3NpbmF0dXJhIF
> RpcG8g
> 
> QTExFDASBgNVBAsUCyhFTSBCUkFOQ08pMRQwEgYDVQQLFAsoRU0gQlJBTkNPKTEjMCEGA1
> UEAxMa
> 
> TUVESUFURUNIIElORk9STUFUSUNBIExUREExKDAmBgkqhkiG9w0BCQEWGWNvbnRhdG9AdG
> Vjbm9t
> 
> aWRpYS5jb20uYnIwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAM8txkPNL6gjEjSW4T
> umyO0w
> 
> zBGmxNtCqU9DFNWQD1TWIbXaYduxoxnYEwNXrehla2YDslXUiM45SWvlmjlWoVV9T7F07a
> OGGysP
> 
> aNLJW/y3CMq7Qrvsh+h30INqV8WWYXKHlmfLz4eNf8Di4xQvgm+7yxvkGHXXjxkWn6utBW
> tJAgMB
> 
> AAGjggMyMIIDLjCBrQYDVR0RBIGlMIGioDgGBWBMAQMEoC8ELTE5MDExOTY3MTEyMDk3Mz
> g4MDUw
> 
> MDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMKAXBgVgTAEDAqAOBAxKQUlSIFNaQVBJUk+gGQ
> MDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMKAXBgVgTAEDAqAOBAxKQUlSIFNaQVBJUk+YFY
> MDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMKAXBgVgTAEDAqAOBAxKQUlSIFNaQVBJUk+EwB
> 
> AwOgEAQOMDM1OTM5NjgwMDAxNjegFwYFYEwBAwegDgQMMDAwMDAwMDAwMDAwgRljb250YX
> RvQHRl
> 
>
Y25vbWlkaWEuY29tLmJyMAkGA1UdEwQCMAAwHwYDVR0jBBgwFoAUhLBCMzSjQiWlKJc+g+t38OhP
> 
> wlQwDgYDVR0PAQH/BAQDAgXgMFUGA1UdIAROMEwwSgYGYEwBAgELMEAwPgYIKwYBBQUHAg
> EWMmh0
> 
> dHA6Ly9pY3AtYnJhc2lsLmNlcnRpc2lnbi5jb20uYnIvcmVwb3NpdG9yaW8vZHBjMIIBJQ
> YDVR0f
> 
> BIIBHDCCARgwXKBaoFiGVmh0dHA6Ly9pY3AtYnJhc2lsLmNlcnRpc2lnbi5jb20uYnIvcm
> Vwb3Np
> 
> dG9yaW8vbGNyL0FDQ2VydGlzaWduTXVsdGlwbGFHMy9MYXRlc3RDUkwuY3JsMFugWaBXhl
> VodHRw
> 
> Oi8vaWNwLWJyYXNpbC5vdXRyYWxjci5jb20uYnIvcmVwb3NpdG9yaW8vbGNyL0FDQ2VydG
> lzaWdu
> 
> TXVsdGlwbGFHMy9MYXRlc3RDUkwuY3JsMFugWaBXhlVodHRwOi8vcmVwb3NpdG9yaW8uaW
> NwYnJh
> 
> c2lsLmdvdi5ici9sY3IvQ2VydGlzaWduL0FDQ2VydGlzaWduTXVsdGlwbGFHMy9MYXRlc3
> RDUkwu
> 
> Y3JsMB0GA1UdJQQWMBQGCCsGAQUFBwMEBggrBgEFBQcDAjCBoAYIKwYBBQUHAQEEgZMwgZ
> AwKAYI
> 
> KwYBBQUHMAGGHGh0dHA6Ly9vY3NwLmNlcnRpc2lnbi5jb20uYnIwZAYIKwYBBQUHMAKGWG
> h0dHA6
> 
> Ly9pY3AtYnJhc2lsLmNlcnRpc2lnbi5jb20uYnIvcmVwb3NpdG9yaW8vY2VydGlmaWNhZG
> 9zL0FD
> 
> X0NlcnRpc2lnbl9NdWx0aXBsYV9HMy5wN2MwDQYJKoZIhvcNAQEFBQADggEBAGI9MCc6WV
> mz919C
> 
> QLDB8E0R8HxfGyiz2uB14lPBDsueTJmJmlykQdnboMiyMGTocprEGsQxeI7a57BEUDVc0f
> SzNCCb
> 
> SOnQOp9Uswri8pTw8fQG9OAkh1LCC9haTsNNMKbTHCciO7MUh34XkHuj4A0NIWG1aCynws
> tRFWb8
> 
> 97OZJJCc0IRvDs7yDJhgOwPmv3trFmwlfMU7n20pXtM9hKiI8o6h/0GwR6SyA1Yj4fZXfX
> xVENH4
> 
> EjhIHR8Yrmre2JE2I+hFjyQaNPnAEztQEa0Cae2l3O0Q0tkM1x8EkiKFrnDggpc7gSwtLC
> EjhIHR8Yrmre2JE2I+wrkQBu
> 
> jhie131VyDTuXLx9k082PLs=</X509Certificate></X509Data></KeyInfo></Signa
> ture></NFe>
> 
>  
> 
> <protNFe
> versao="1.10"><infProt><tpAmb>1</tpAmb><verAplic>SP_NFE_PL_005e</verAp
> lic><chNFe>35101003593968000167550030000101640000000003</chNFe><dhRecb
> to>2010-10-20T17:48:15</dhRecbto><nProt>135100546996360</nProt><digVal
> >vj4p6FtqkZen6fsHlcyag8R2hF0=</digVal><cStat>100</cStat><xMotivo>Autor
> izado o uso da NF-e</xMotivo></infProt></protNFe>
> 
> </nfeProc>
> 
>  
> 
> ----------------------------------------------------------------------
> --------------------------
> 
>  
> 
> Thanks a lot
> 
>  
> 
>  
> 
>  
> 
>  
> 
> 
> 
> _______________________________________________
> xmlsec mailing list
> xmlsec at aleksey.com
> http://www.aleksey.com/mailman/listinfo/xmlsec


From aleksey at aleksey.com  Wed Jun  6 12:15:28 2012
From: aleksey at aleksey.com (Aleksey Sanin)
Date: Wed, 06 Jun 2012 12:15:28 -0700
Subject: [xmlsec] RES:   Trying to check sign
In-Reply-To: <012001cd43d9$77e0fc50$67a2f4f0$@acm.org>
References: <00fc01cd435d$f7ce89e0$e76b9da0$@acm.org>
 <4FCEC586.3010703@aleksey.com> <012001cd43d9$77e0fc50$67a2f4f0$@acm.org>
Message-ID: <4FCFAC50.7060902@aleksey.com>

It's not on the website but it is in the examples folder.

Aleksey

On 6/6/12 4:42 AM, Renato Tegon Forti wrote:
>>> This means that xmlsec (or to be precise, openssl) needs to verify the
> certificate and it can't find the next certificate in the chain.
> 
> Thanks for answer. 
> 
> One more question: what is the example
> (http://www.aleksey.com/xmlsec/api/xmlsec-examples.html) that implement
> "Online XML Digital Signature Verifer"? 
> I want study code implementation of it!
> 
> Thanks
> 
> -----Mensagem original-----
> De: Aleksey Sanin [mailto:aleksey at aleksey.com] 
> Enviada em: ter?a-feira, 5 de junho de 2012 23:51
> Para: Renato Tegon Forti
> Cc: xmlsec at aleksey.com
> Assunto: Re: [xmlsec] Trying to check sign
> 
> This means that xmlsec (or to be precise, openssl) needs to verify the
> certificate and it can't find the next certificate in the chain.
> 
> Aleksey
> 
> On 6/5/12 1:58 PM, Renato Tegon Forti wrote:
>> Hi,
>>
>>  
>>
>> I have one file that I want check sig (using KEYINFO node), I know 
>> that the signature is valid, but tool returns me:
>>
>>  
>>
>> I use DTD, see xml below, please!
>>
>>  
>>
>> ----------------------------------------------------------------------
>> --------------------------
>>
>>  
>>
>> func=xmlSecOpenSSLX509StoreVerify:file=x509vfy.c:line=360:obj=x509-sto
>> re:subj=X509_verify_cert:error=4:crypto
>> library function failed:subj=/C=BR/O=ICP-Brasil/OU=ID - 
>> 1083312/OU=Autenticado por Certisign Certificadora 
>> Digital/OU=Assinatura Tipo A1/OU=(EM BRANCO)/OU=(EM 
>> BRANCO)/CN=MEDIATECH INFORMATICA 
>> LTDA/emailAddress=contato at tecnomidia.com.br;err=20;msg=unable
>> <mailto:LTDA/emailAddress=contato at tecnomidia.com.br;err=20;msg=unable>
>> to get local issuer certificate
>>
>> func=xmlSecOpenSSLX509StoreVerify:file=x509vfy.c:line=408:obj=x509-sto
>> re:subj=unknown:error=71:certificate
>> verification failed:err=20;msg=unable to get local issuer certificate
>>
>> func=xmlSecOpenSSLEvpSignatureVerify:file=signatures.c:line=346:obj=rs
>> a-sha1:subj=EVP_VerifyFinal:error=18:data
>> do not match:signature do not match
>>
>> RESULT: Signature is INVALID
>>
>> ---------------------------------------------------
>>
>> = VERIFICATION CONTEXT
>>
>> == Status: invalid
>>
>> == flags: 0x00000000
>>
>> == flags2: 0x00000000
>>
>> == Key Info Read Ctx:
>>
>> = KEY INFO READ CONTEXT
>>
>> == flags: 0x00000000
>>
>> == flags2: 0x00000000
>>
>> == enabled key data: all
>>
>> == RetrievalMethod level (cur/max): 0/1
>>
>> == TRANSFORMS CTX (status=0)
>>
>> == flags: 0x00000000
>>
>> == flags2: 0x00000000
>>
>> == enabled transforms: all
>>
>> === uri: NULL
>>
>> === uri xpointer expr: NULL
>>
>> == EncryptedKey level (cur/max): 0/1
>>
>> === KeyReq:
>>
>> ==== keyId: rsa
>>
>> ==== keyType: 0x00000001
>>
>> ==== keyUsage: 0x00000002
>>
>> ==== keyBitsSize: 0
>>
>> === list size: 0
>>
>> == Key Info Write Ctx:
>>
>> = KEY INFO WRITE CONTEXT
>>
>> == flags: 0x00000000
>>
>> == flags2: 0x00000000
>>
>> == enabled key data: all
>>
>> == RetrievalMethod level (cur/max): 0/1
>>
>> == TRANSFORMS CTX (status=0)
>>
>> == flags: 0x00000000
>>
>> == flags2: 0x00000000
>>
>> == enabled transforms: all
>>
>> === uri: NULL
>>
>> === uri xpointer expr: NULL
>>
>> == EncryptedKey level (cur/max): 0/1
>>
>> === KeyReq:
>>
>> ==== keyId: NULL
>>
>> ==== keyType: 0x00000001
>>
>> ==== keyUsage: 0xffffffff
>>
>> ==== keyBitsSize: 0
>>
>> === list size: 0
>>
>> == Signature Transform Ctx:
>>
>> == TRANSFORMS CTX (status=2)
>>
>> == flags: 0x00000000
>>
>> == flags2: 0x00000000
>>
>> == enabled transforms: all
>>
>> === uri: NULL
>>
>> === uri xpointer expr: NULL
>>
>> === Transform: c14n 
>> (href=http://www.w3.org/TR/2001/REC-xml-c14n-20010315)
>>
>> === Transform: rsa-sha1 
>> (href=http://www.w3.org/2000/09/xmldsig#rsa-sha1)
>>
>> === Transform: membuf-transform (href=NULL)
>>
>> == Signature Method:
>>
>> === Transform: rsa-sha1 
>> (href=http://www.w3.org/2000/09/xmldsig#rsa-sha1)
>>
>> == Signature Key:
>>
>> == KEY
>>
>> === method: RSAKeyValue
>>
>> === key type: Private
>>
>> === key name: test-rsa
>>
>> === key usage: -1
>>
>> === rsa key: size = 1024
>>
>> == SignedInfo References List:
>>
>> === list size: 1
>>
>> = REFERENCE VERIFICATION CONTEXT
>>
>> == Status: succeeded
>>
>> == URI: "#NFe35101003593968000167550030000101640000000003"
>>
>> == Reference Transform Ctx:
>>
>> == TRANSFORMS CTX (status=2)
>>
>> == flags: 0x00000000
>>
>> == flags2: 0x00000000
>>
>> == enabled transforms: all
>>
>> === uri:
>>
>> === uri xpointer expr: 
>> #NFe35101003593968000167550030000101640000000003
>>
>> === Transform: xpointer 
>> (href=http://www.w3.org/2001/04/xmldsig-more/xptr)
>>
>> === Transform: enveloped-signature
>> (href=http://www.w3.org/2000/09/xmldsig#enveloped-signature)
>>
>> === Transform: c14n 
>> (href=http://www.w3.org/TR/2001/REC-xml-c14n-20010315)
>>
>> === Transform: sha1 (href=http://www.w3.org/2000/09/xmldsig#sha1)
>>
>> === Transform: membuf-transform (href=NULL)
>>
>> == Digest Method:
>>
>> === Transform: sha1 (href=http://www.w3.org/2000/09/xmldsig#sha1)
>>
>> == Manifest References List:
>>
>> === list size: 0
>>
>>  
>>
>> ----------------------------------------------------------------------
>> --------------------------
>>
>>  
>>
>> Anyone can help-me to understand what I make wrong!
>>
>> What this exactly can mean: ?unable to get local issuer certificate?
>>
>>  
>>
>> This is my xml file ( the DTD is correct?):
>>
>>  
>>
>> ----------------------------------------------------------------------
>> --------------------------
>>
>>  
>>
>> <?xml version="1.0" encoding="UTF-8"?>
>>
>> <!DOCTYPE test [
>>
>> <!ATTLIST infNFe Id ID #IMPLIED>
>>
>> ]>
>>
>> <nfeProc xmlns="http://www.portalfiscal.inf.br/nfe" versao="1.10">
>>
>> <NFe xmlns="http://www.portalfiscal.inf.br/nfe"><infNFe
>> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
>> Id="NFe35101003593968000167550030000101640000000003"
>> versao="1.10"><ide><cUF>35</cUF><cNF>000000000</cNF><natOp>VENDA MERC 
>> C/ PGTO ST C/ 
>> SUBSTITUIDO</natOp><indPag>1</indPag><mod>55</mod><serie>3</serie><nNF
>>> 10164</nNF><dEmi>2010-10-20</dEmi><dSaiEnt>2010-10-20</dSaiEnt><tpNF>
>> 1</tpNF><cMunFG>3550308</cMunFG><tpImp>1</tpImp><tpEmis>1</tpEmis><cDV
>>> 3</cDV><tpAmb>1</tpAmb><finNFe>1</finNFe><procEmi>0</procEmi><verProc
>>> 1.4.0</verProc></ide><emit><CNPJ>03593968000167</CNPJ><xNome>Mediatec
>> h Informatica LTDA</xNome><xFant>Mediatech Informatica 
>> LTDA</xFant><enderEmit><xLgr>CORREIA DE 
>> MELO</xLgr><nro>085</nro><xBairro>BOM
>> RETIRO</xBairro><cMun>3550308</cMun><xMun>SAO
>> PAULO</xMun><UF>SP</UF><CEP>01123020</CEP><cPais>1058</cPais><xPais>BR
>> ASIL</xPais><fone>1133521199</fone></enderEmit><IE>115633812110</IE></
>> emit><dest><CNPJ>11253910000100</CNPJ><xNome>AYSSO
>> SYSTEMS LTDA EPP</xNome><enderDest><xLgr>RUA DOZE DE 
>> NOVEMBRO</xLgr><nro>180</nro><xCpl>APT
>> 183</xCpl><xBairro>CENTRO</xBairro><cMun>3501608</cMun><xMun>AMERICANA
>> </xMun><UF>SP</UF><CEP>13465490</CEP><cPais>1058</cPais><xPais>BRASIL<
>> /xPais><fone>1936459994</fone></enderDest><IE/></dest><det
>> nItem="1"><prod><cProd>1160900000000001720000</cProd><cEAN/><xProd>MID
>> IA
>> DIGITAL
>> CD/DVD</xProd><NCM>85234011</NCM><CFOP>5405</CFOP><uCom>PC.</uCom><qCo
>> m>100.0000</qCom><vUnCom>2.1500</vUnCom><vProd>215.00</vProd><cEANTrib
>> /><uTrib>PC.</uTrib><qTrib>100.0000</qTrib><vUnTrib>2.1500</vUnTrib><v
>> Frete>20.00</vFrete></prod><imposto><ICMS><ICMS60><orig>0</orig><CST>6
>> 0</CST><vBCST>215.00</vBCST><vICMSST>0.00</vICMSST></ICMS60></ICMS><IP
>> I><cEnq>999</cEnq><IPINT><CST>53</CST></IPINT></IPI><PIS><PISAliq><CST
>>> 01</CST><vBC>215.00</vBC><pPIS>0.65</pPIS><vPIS>1.40</vPIS></PISAliq>
>> </PIS><COFINS><COFINSAliq><CST>01</CST><vBC>215.00</vBC><pCOFINS>3.00<
>> /pCOFINS><vCOFINS>6.45</vCOFINS></COFINSAliq></COFINS></imposto></det>
>> <total><ICMSTot><vBC>20.00</vBC><vICMS>0.00</vICMS><vBCST>0.00</vBCST>
>> <vST>0.00</vST><vProd>215.00</vProd><vFrete>20.00</vFrete><vSeg>0.00</
>> vSeg><vDesc>0.00</vDesc><vII>0.00</vII><vIPI>0.00</vIPI><vPIS>1.40</vP
>> IS><vCOFINS>6.45</vCOFINS><vOutro>0.00</vOutro><vNF>235.00</vNF></ICMS
>> Tot></total><transp><modFrete>0</modFrete><transporta><CNPJ>0728188600
>> 0138</CNPJ><xNom
>  e
>> Correio
>> - Sedex</xNome><IE>ISENTO</IE><xEnder>Rua Correia de Melo,  
>> 111</xEnder><xMun>Sao
>>
> Paulo</xMun><UF>SP</UF></transporta><vol><qVol>1</qVol><esp>CX.</esp><pesoL>
> 1.000</pesoL><pesoB>1.000</pesoB></vol></transp><cobr><fat><nFat>10164</nFat
>> <vOrig>235.00</vOrig><vLiq>235.00</vLiq></fat><dup><nDup>001</nDup><dVenc>2
> 010-10-20</dVenc><vDup>235.00</vDup></dup></cobr><infAdic><infCpl>Pedidos:
>> 48033</infCpl></infAdic></infNFe><Signature
>>
>> xmlns="http://www.w3.org/2000/09/xmldsig#"><SignedInfo><Canonicalizatio
>> nMethod  
>> Algorithm="http://www.w3.org/TR/2001/REC-xml-c14n-20010315"/><Signature
>> Method  
>> Algorithm="http://www.w3.org/2000/09/xmldsig#rsa-sha1"/><Reference
>>
>> URI="#NFe35101003593968000167550030000101640000000003"><Transforms><Tra
>> nsform  
>> Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature"/><Tra
>> nsform  
>> Algorithm="http://www.w3.org/TR/2001/REC-xml-c14n-20010315"/></Transfor
>> ms><DigestMethod  
>> Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/><DigestValue>vj4p6F
>> tqkZen6fsHlcyag8R2hF0=</DigestValue></Reference></SignedInfo><Signature
>> Value>Jymbikn/5F8aUYQA6CaZmLYY9plO4KNfyu/M4TZP5l+3fy/pjwpkIsaeV1LXXyo7n
>> WLdpvruhCXy
>>
>> ID2ptAjzIWOJ/vp1YW94e0Yy7yfBijQNkew+FI1G7GKKt7T/UUIPRrXqWwo7EA8ZpCYSoW
>> ktWqHZ
>>
>> iU7j7iJone1nLdNJNjY=</SignatureValue><KeyInfo><X509Data><X509Certifica
>> te>MIIGuzCCBaOgAwIBAgIQCbCeZ64fHJPeNqAkc06I8TANBgkqhkiG9w0BAQUFADB0MQs
>> wCQYDVQQG
>>
>> EwJCUjETMBEGA1UEChMKSUNQLUJyYXNpbDEtMCsGA1UECxMkQ2VydGlzaWduIENlcnRpZm
>> ljYWRv
>>
>> cmEgRGlnaXRhbCBTLkEuMSEwHwYDVQQDExhBQyBDZXJ0aXNpZ24gTXVsdGlwbGEgRzMwHh
>> cNMTAw
>>
>> NzI5MDAwMDAwWhcNMTEwNzI4MjM1OTU5WjCCAQsxCzAJBgNVBAYTAkJSMRMwEQYDVQQKFA
>> pJQ1At
>>
>> QnJhc2lsMRUwEwYDVQQLFAxJRCAtIDEwODMzMTIxODA2BgNVBAsUL0F1dGVudGljYWRvIH
>> BvciBD
>>
>> ZXJ0aXNpZ24gQ2VydGlmaWNhZG9yYSBEaWdpdGFsMRswGQYDVQQLFBJBc3NpbmF0dXJhIF
>> RpcG8g
>>
>> QTExFDASBgNVBAsUCyhFTSBCUkFOQ08pMRQwEgYDVQQLFAsoRU0gQlJBTkNPKTEjMCEGA1
>> UEAxMa
>>
>> TUVESUFURUNIIElORk9STUFUSUNBIExUREExKDAmBgkqhkiG9w0BCQEWGWNvbnRhdG9AdG
>> Vjbm9t
>>
>> aWRpYS5jb20uYnIwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAM8txkPNL6gjEjSW4T
>> umyO0w
>>
>> zBGmxNtCqU9DFNWQD1TWIbXaYduxoxnYEwNXrehla2YDslXUiM45SWvlmjlWoVV9T7F07a
>> OGGysP
>>
>> aNLJW/y3CMq7Qrvsh+h30INqV8WWYXKHlmfLz4eNf8Di4xQvgm+7yxvkGHXXjxkWn6utBW
>> tJAgMB
>>
>> AAGjggMyMIIDLjCBrQYDVR0RBIGlMIGioDgGBWBMAQMEoC8ELTE5MDExOTY3MTEyMDk3Mz
>> g4MDUw
>>
>> MDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMKAXBgVgTAEDAqAOBAxKQUlSIFNaQVBJUk+gGQ
>> MDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMKAXBgVgTAEDAqAOBAxKQUlSIFNaQVBJUk+YFY
>> MDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMKAXBgVgTAEDAqAOBAxKQUlSIFNaQVBJUk+EwB
>>
>> AwOgEAQOMDM1OTM5NjgwMDAxNjegFwYFYEwBAwegDgQMMDAwMDAwMDAwMDAwgRljb250YX
>> RvQHRl
>>
>>
> Y25vbWlkaWEuY29tLmJyMAkGA1UdEwQCMAAwHwYDVR0jBBgwFoAUhLBCMzSjQiWlKJc+g+t38OhP
>>
>> wlQwDgYDVR0PAQH/BAQDAgXgMFUGA1UdIAROMEwwSgYGYEwBAgELMEAwPgYIKwYBBQUHAg
>> EWMmh0
>>
>> dHA6Ly9pY3AtYnJhc2lsLmNlcnRpc2lnbi5jb20uYnIvcmVwb3NpdG9yaW8vZHBjMIIBJQ
>> YDVR0f
>>
>> BIIBHDCCARgwXKBaoFiGVmh0dHA6Ly9pY3AtYnJhc2lsLmNlcnRpc2lnbi5jb20uYnIvcm
>> Vwb3Np
>>
>> dG9yaW8vbGNyL0FDQ2VydGlzaWduTXVsdGlwbGFHMy9MYXRlc3RDUkwuY3JsMFugWaBXhl
>> VodHRw
>>
>> Oi8vaWNwLWJyYXNpbC5vdXRyYWxjci5jb20uYnIvcmVwb3NpdG9yaW8vbGNyL0FDQ2VydG
>> lzaWdu
>>
>> TXVsdGlwbGFHMy9MYXRlc3RDUkwuY3JsMFugWaBXhlVodHRwOi8vcmVwb3NpdG9yaW8uaW
>> NwYnJh
>>
>> c2lsLmdvdi5ici9sY3IvQ2VydGlzaWduL0FDQ2VydGlzaWduTXVsdGlwbGFHMy9MYXRlc3
>> RDUkwu
>>
>> Y3JsMB0GA1UdJQQWMBQGCCsGAQUFBwMEBggrBgEFBQcDAjCBoAYIKwYBBQUHAQEEgZMwgZ
>> AwKAYI
>>
>> KwYBBQUHMAGGHGh0dHA6Ly9vY3NwLmNlcnRpc2lnbi5jb20uYnIwZAYIKwYBBQUHMAKGWG
>> h0dHA6
>>
>> Ly9pY3AtYnJhc2lsLmNlcnRpc2lnbi5jb20uYnIvcmVwb3NpdG9yaW8vY2VydGlmaWNhZG
>> 9zL0FD
>>
>> X0NlcnRpc2lnbl9NdWx0aXBsYV9HMy5wN2MwDQYJKoZIhvcNAQEFBQADggEBAGI9MCc6WV
>> mz919C
>>
>> QLDB8E0R8HxfGyiz2uB14lPBDsueTJmJmlykQdnboMiyMGTocprEGsQxeI7a57BEUDVc0f
>> SzNCCb
>>
>> SOnQOp9Uswri8pTw8fQG9OAkh1LCC9haTsNNMKbTHCciO7MUh34XkHuj4A0NIWG1aCynws
>> tRFWb8
>>
>> 97OZJJCc0IRvDs7yDJhgOwPmv3trFmwlfMU7n20pXtM9hKiI8o6h/0GwR6SyA1Yj4fZXfX
>> xVENH4
>>
>> EjhIHR8Yrmre2JE2I+hFjyQaNPnAEztQEa0Cae2l3O0Q0tkM1x8EkiKFrnDggpc7gSwtLC
>> EjhIHR8Yrmre2JE2I+wrkQBu
>>
>> jhie131VyDTuXLx9k082PLs=</X509Certificate></X509Data></KeyInfo></Signa
>> ture></NFe>
>>
>>  
>>
>> <protNFe
>> versao="1.10"><infProt><tpAmb>1</tpAmb><verAplic>SP_NFE_PL_005e</verAp
>> lic><chNFe>35101003593968000167550030000101640000000003</chNFe><dhRecb
>> to>2010-10-20T17:48:15</dhRecbto><nProt>135100546996360</nProt><digVal
>>> vj4p6FtqkZen6fsHlcyag8R2hF0=</digVal><cStat>100</cStat><xMotivo>Autor
>> izado o uso da NF-e</xMotivo></infProt></protNFe>
>>
>> </nfeProc>
>>
>>  
>>
>> ----------------------------------------------------------------------
>> --------------------------
>>
>>  
>>
>> Thanks a lot
>>
>>  
>>
>>  
>>
>>  
>>
>>  
>>
>>
>>
>> _______________________________________________
>> xmlsec mailing list
>> xmlsec at aleksey.com
>> http://www.aleksey.com/mailman/listinfo/xmlsec
> 
> _______________________________________________
> xmlsec mailing list
> xmlsec at aleksey.com
> http://www.aleksey.com/mailman/listinfo/xmlsec

From re.tf at acm.org  Thu Jun  7 12:29:33 2012
From: re.tf at acm.org (Renato Tegon Forti)
Date: Thu, 7 Jun 2012 16:29:33 -0300
Subject: [xmlsec] RES:  RES:   Trying to check sign
In-Reply-To: <4FCFAC50.7060902@aleksey.com>
References: <00fc01cd435d$f7ce89e0$e76b9da0$@acm.org>
 <4FCEC586.3010703@aleksey.com> <012001cd43d9$77e0fc50$67a2f4f0$@acm.org>
 <4FCFAC50.7060902@aleksey.com>
Message-ID: <01db01cd44e3$df87b410$9e971c30$@acm.org>

Hi Aleksey,

Thanks for your help! Really thanks a lot! If you have time to help-me
again!

I am a really confusing, I am trying understand what I need to check if one
signature is valid using your xmlsec1 tool, and then implement this on C
code!

My signed document has these properties (mt.xml):

Transform Algorithm: Enveloped
Algorithm: xmldsig#sha1

I'd try a lot of things, but all of it return me: "err=20;msg=unable to get
local issuer certificate"

For sampe:

I try this: 
xmlsec1 --verify --id-attr:Id infNFe --trusted-der mt.der.cer mt.xml 
but "mt.der.cer" is cert that is on : <KeyInfo><X509Data><X509Certificate>

So I thought the problem was the root certificate, because I already have
the certificate of the user in <X509Certificate>, then I tried:

xmlsec1 --verify --id-attr:Id infNFe --trusted-der
Autoridade_Certificadora_da_Raiz_Brasileira_v2.der.cer mt.xml
Some error "err=20;msg=unable to get local issuer certificate "

Then I tried a variation, only to check result: (--untrusted-der)

xmlsec1 --verify --id-attr:Id infNFe --untrusted-der
Autoridade_Certificadora_da_Raiz_Brasileira_v2.der.cer mt.xml
the error change to: err=18;msg=self signed certificate

I tried too:

xmlsec1 --verify --id-attr:Id infNFe --trusted-der
SERASA_Autoridade_Certificadora_Principal_v2.der.cer mt.xml
xmlsec1 --verify --id-attr:Id infNFe --trusted-der
SERASA_Autoridade_Certificadora_Digital_v2.der.cer mt.xml

Some error "err=20;msg=unable to get local issuer certificate "

Reading a book I understood that to verifying an XML Signature:

1.
Verify the signature of the <SignedInfo> element. -> To do so, recalculate
the digest of the <SignedInfo> element (using the digest algorithm specified
in the <SignatureMethod> element) and use the public verification key to
verify that the value of the <SignatureValue> element is correct for the
digest of the <SignedInfo> element. 

The public key (public verification key)  in my case is: <X509Certificate>
OK?

2.
If this step passes, recalculate the digests of the references contained
within the <SignedInfo> element and compare them to the digest values
expressed in each <Reference> element's corresponding <DigestValue> element.


Please see attached files! (meta.zip)
 -> mt.xml [file that I want check signature]
-> chain.png [cert chains]
-> Autoridade_Certificadora_da_Raiz_Brasileira_v2.der.cer [root cert in der
format]
-> SERASA_Autoridade_Certificadora_Principal_v2.der.cer ->
SERASA_Autoridade_Certificadora_Digital_v2.der.cer -> mt.der.cer [all other
certs in chain ]

What am I doing wrong? What I misunderstood?
Thanks a lot!



-----Mensagem original-----
De: Aleksey Sanin [mailto:aleksey at aleksey.com] 
Enviada em: quarta-feira, 6 de junho de 2012 16:15
Para: Renato Tegon Forti
Cc: xmlsec at aleksey.com
Assunto: Re: [xmlsec] RES: Trying to check sign

It's not on the website but it is in the examples folder.

Aleksey

On 6/6/12 4:42 AM, Renato Tegon Forti wrote:
>>> This means that xmlsec (or to be precise, openssl) needs to verify 
>>> the
> certificate and it can't find the next certificate in the chain.
> 
> Thanks for answer. 
> 
> One more question: what is the example
> (http://www.aleksey.com/xmlsec/api/xmlsec-examples.html) that 
> implement "Online XML Digital Signature Verifer"?
> I want study code implementation of it!
> 
> Thanks
> 
> -----Mensagem original-----
> De: Aleksey Sanin [mailto:aleksey at aleksey.com] Enviada em: 
> ter?a-feira, 5 de junho de 2012 23:51
> Para: Renato Tegon Forti
> Cc: xmlsec at aleksey.com
> Assunto: Re: [xmlsec] Trying to check sign
> 
> This means that xmlsec (or to be precise, openssl) needs to verify the 
> certificate and it can't find the next certificate in the chain.
> 
> Aleksey
> 
> On 6/5/12 1:58 PM, Renato Tegon Forti wrote:
>> Hi,
>>
>>  
>>
>> I have one file that I want check sig (using KEYINFO node), I know 
>> that the signature is valid, but tool returns me:
>>
>>  
>>
>> I use DTD, see xml below, please!
>>
>>  
>>
>> ---------------------------------------------------------------------
>> -
>> --------------------------
>>
>>  
>>
>> func=xmlSecOpenSSLX509StoreVerify:file=x509vfy.c:line=360:obj=x509-st
>> o re:subj=X509_verify_cert:error=4:crypto
>> library function failed:subj=/C=BR/O=ICP-Brasil/OU=ID - 
>> 1083312/OU=Autenticado por Certisign Certificadora 
>> Digital/OU=Assinatura Tipo A1/OU=(EM BRANCO)/OU=(EM 
>> BRANCO)/CN=MEDIATECH INFORMATICA 
>> LTDA/emailAddress=contato at tecnomidia.com.br;err=20;msg=unable
>> <mailto:LTDA/emailAddress=contato at tecnomidia.com.br;err=20;msg=unable
>> >
>> to get local issuer certificate
>>
>> func=xmlSecOpenSSLX509StoreVerify:file=x509vfy.c:line=408:obj=x509-st
>> o
>> re:subj=unknown:error=71:certificate
>> verification failed:err=20;msg=unable to get local issuer certificate
>>
>> func=xmlSecOpenSSLEvpSignatureVerify:file=signatures.c:line=346:obj=r
>> s a-sha1:subj=EVP_VerifyFinal:error=18:data
>> do not match:signature do not match
>>
>> RESULT: Signature is INVALID
>>
>> ---------------------------------------------------
>>
>> = VERIFICATION CONTEXT
>>
>> == Status: invalid
>>
>> == flags: 0x00000000
>>
>> == flags2: 0x00000000
>>
>> == Key Info Read Ctx:
>>
>> = KEY INFO READ CONTEXT
>>
>> == flags: 0x00000000
>>
>> == flags2: 0x00000000
>>
>> == enabled key data: all
>>
>> == RetrievalMethod level (cur/max): 0/1
>>
>> == TRANSFORMS CTX (status=0)
>>
>> == flags: 0x00000000
>>
>> == flags2: 0x00000000
>>
>> == enabled transforms: all
>>
>> === uri: NULL
>>
>> === uri xpointer expr: NULL
>>
>> == EncryptedKey level (cur/max): 0/1
>>
>> === KeyReq:
>>
>> ==== keyId: rsa
>>
>> ==== keyType: 0x00000001
>>
>> ==== keyUsage: 0x00000002
>>
>> ==== keyBitsSize: 0
>>
>> === list size: 0
>>
>> == Key Info Write Ctx:
>>
>> = KEY INFO WRITE CONTEXT
>>
>> == flags: 0x00000000
>>
>> == flags2: 0x00000000
>>
>> == enabled key data: all
>>
>> == RetrievalMethod level (cur/max): 0/1
>>
>> == TRANSFORMS CTX (status=0)
>>
>> == flags: 0x00000000
>>
>> == flags2: 0x00000000
>>
>> == enabled transforms: all
>>
>> === uri: NULL
>>
>> === uri xpointer expr: NULL
>>
>> == EncryptedKey level (cur/max): 0/1
>>
>> === KeyReq:
>>
>> ==== keyId: NULL
>>
>> ==== keyType: 0x00000001
>>
>> ==== keyUsage: 0xffffffff
>>
>> ==== keyBitsSize: 0
>>
>> === list size: 0
>>
>> == Signature Transform Ctx:
>>
>> == TRANSFORMS CTX (status=2)
>>
>> == flags: 0x00000000
>>
>> == flags2: 0x00000000
>>
>> == enabled transforms: all
>>
>> === uri: NULL
>>
>> === uri xpointer expr: NULL
>>
>> === Transform: c14n
>> (href=http://www.w3.org/TR/2001/REC-xml-c14n-20010315)
>>
>> === Transform: rsa-sha1
>> (href=http://www.w3.org/2000/09/xmldsig#rsa-sha1)
>>
>> === Transform: membuf-transform (href=NULL)
>>
>> == Signature Method:
>>
>> === Transform: rsa-sha1
>> (href=http://www.w3.org/2000/09/xmldsig#rsa-sha1)
>>
>> == Signature Key:
>>
>> == KEY
>>
>> === method: RSAKeyValue
>>
>> === key type: Private
>>
>> === key name: test-rsa
>>
>> === key usage: -1
>>
>> === rsa key: size = 1024
>>
>> == SignedInfo References List:
>>
>> === list size: 1
>>
>> = REFERENCE VERIFICATION CONTEXT
>>
>> == Status: succeeded
>>
>> == URI: "#NFe35101003593968000167550030000101640000000003"
>>
>> == Reference Transform Ctx:
>>
>> == TRANSFORMS CTX (status=2)
>>
>> == flags: 0x00000000
>>
>> == flags2: 0x00000000
>>
>> == enabled transforms: all
>>
>> === uri:
>>
>> === uri xpointer expr: 
>> #NFe35101003593968000167550030000101640000000003
>>
>> === Transform: xpointer
>> (href=http://www.w3.org/2001/04/xmldsig-more/xptr)
>>
>> === Transform: enveloped-signature
>> (href=http://www.w3.org/2000/09/xmldsig#enveloped-signature)
>>
>> === Transform: c14n
>> (href=http://www.w3.org/TR/2001/REC-xml-c14n-20010315)
>>
>> === Transform: sha1 (href=http://www.w3.org/2000/09/xmldsig#sha1)
>>
>> === Transform: membuf-transform (href=NULL)
>>
>> == Digest Method:
>>
>> === Transform: sha1 (href=http://www.w3.org/2000/09/xmldsig#sha1)
>>
>> == Manifest References List:
>>
>> === list size: 0
>>
>>  
>>
>> ---------------------------------------------------------------------
>> -
>> --------------------------
>>
>>  
>>
>> Anyone can help-me to understand what I make wrong!
>>
>> What this exactly can mean: ?unable to get local issuer certificate?
>>
>>  
>>
>> This is my xml file ( the DTD is correct?):
>>
>>  
>>
>> ---------------------------------------------------------------------
>> -
>> --------------------------
>>
>>  
>>
>> <?xml version="1.0" encoding="UTF-8"?>
>>
>> <!DOCTYPE test [
>>
>> <!ATTLIST infNFe Id ID #IMPLIED>
>>
>> ]>
>>
>> <nfeProc xmlns="http://www.portalfiscal.inf.br/nfe" versao="1.10">
>>
>> <NFe xmlns="http://www.portalfiscal.inf.br/nfe"><infNFe
>> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
>> Id="NFe35101003593968000167550030000101640000000003"
>> versao="1.10"><ide><cUF>35</cUF><cNF>000000000</cNF><natOp>VENDA MERC 
>> C/ PGTO ST C/ 
>> SUBSTITUIDO</natOp><indPag>1</indPag><mod>55</mod><serie>3</serie><nN
>> F
>>> 10164</nNF><dEmi>2010-10-20</dEmi><dSaiEnt>2010-10-20</dSaiEnt><tpNF
>>> >
>> 1</tpNF><cMunFG>3550308</cMunFG><tpImp>1</tpImp><tpEmis>1</tpEmis><cD
>> V
>>> 3</cDV><tpAmb>1</tpAmb><finNFe>1</finNFe><procEmi>0</procEmi><verPro
>>> c 
>>> 1.4.0</verProc></ide><emit><CNPJ>03593968000167</CNPJ><xNome>Mediate
>>> c
>> h Informatica LTDA</xNome><xFant>Mediatech Informatica 
>> LTDA</xFant><enderEmit><xLgr>CORREIA DE 
>> MELO</xLgr><nro>085</nro><xBairro>BOM
>> RETIRO</xBairro><cMun>3550308</cMun><xMun>SAO
>> PAULO</xMun><UF>SP</UF><CEP>01123020</CEP><cPais>1058</cPais><xPais>B
>> R 
>> ASIL</xPais><fone>1133521199</fone></enderEmit><IE>115633812110</IE><
>> /
>> emit><dest><CNPJ>11253910000100</CNPJ><xNome>AYSSO
>> SYSTEMS LTDA EPP</xNome><enderDest><xLgr>RUA DOZE DE 
>> NOVEMBRO</xLgr><nro>180</nro><xCpl>APT
>> 183</xCpl><xBairro>CENTRO</xBairro><cMun>3501608</cMun><xMun>AMERICAN
>> A 
>> </xMun><UF>SP</UF><CEP>13465490</CEP><cPais>1058</cPais><xPais>BRASIL
>> < /xPais><fone>1936459994</fone></enderDest><IE/></dest><det
>> nItem="1"><prod><cProd>1160900000000001720000</cProd><cEAN/><xProd>MI
>> D
>> IA
>> DIGITAL
>> CD/DVD</xProd><NCM>85234011</NCM><CFOP>5405</CFOP><uCom>PC.</uCom><qC
>> o
>> m>100.0000</qCom><vUnCom>2.1500</vUnCom><vProd>215.00</vProd><cEANTri
>> m>b
>> /><uTrib>PC.</uTrib><qTrib>100.0000</qTrib><vUnTrib>2.1500</vUnTrib><
>> v
>> Frete>20.00</vFrete></prod><imposto><ICMS><ICMS60><orig>0</orig><CST>
>> Frete>6
>> 0</CST><vBCST>215.00</vBCST><vICMSST>0.00</vICMSST></ICMS60></ICMS><I
>> P
>> I><cEnq>999</cEnq><IPINT><CST>53</CST></IPINT></IPI><PIS><PISAliq><CS
>> I>T
>>> 01</CST><vBC>215.00</vBC><pPIS>0.65</pPIS><vPIS>1.40</vPIS></PISAliq
>>> >
>> </PIS><COFINS><COFINSAliq><CST>01</CST><vBC>215.00</vBC><pCOFINS>3.00
>> < 
>> /pCOFINS><vCOFINS>6.45</vCOFINS></COFINSAliq></COFINS></imposto></det
>> > 
>> <total><ICMSTot><vBC>20.00</vBC><vICMS>0.00</vICMS><vBCST>0.00</vBCST
>> > 
>> <vST>0.00</vST><vProd>215.00</vProd><vFrete>20.00</vFrete><vSeg>0.00<
>> /
>> vSeg><vDesc>0.00</vDesc><vII>0.00</vII><vIPI>0.00</vIPI><vPIS>1.40</v
>> vSeg>P
>> IS><vCOFINS>6.45</vCOFINS><vOutro>0.00</vOutro><vNF>235.00</vNF></ICM
>> IS>S
>> Tot></total><transp><modFrete>0</modFrete><transporta><CNPJ>072818860
>> Tot>0
>> 0138</CNPJ><xNom
>  e
>> Correio
>> - Sedex</xNome><IE>ISENTO</IE><xEnder>Rua Correia de Melo, 
>> 111</xEnder><xMun>Sao
>>
> Paulo</xMun><UF>SP</UF></transporta><vol><qVol>1</qVol><esp>CX.</esp><
> pesoL> 
> 1.000</pesoL><pesoB>1.000</pesoB></vol></transp><cobr><fat><nFat>10164
> </nFat
>> <vOrig>235.00</vOrig><vLiq>235.00</vLiq></fat><dup><nDup>001</nDup><d
>> Venc>2
> 010-10-20</dVenc><vDup>235.00</vDup></dup></cobr><infAdic><infCpl>Pedidos:
>> 48033</infCpl></infAdic></infNFe><Signature
>>
>> xmlns="http://www.w3.org/2000/09/xmldsig#"><SignedInfo><Canonicalizat
>> io
>> nMethod
>> Algorithm="http://www.w3.org/TR/2001/REC-xml-c14n-20010315"/><Signatu
>> re
>> Method
>> Algorithm="http://www.w3.org/2000/09/xmldsig#rsa-sha1"/><Reference
>>
>> URI="#NFe35101003593968000167550030000101640000000003"><Transforms><T
>> ra
>> nsform
>> Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature"/><T
>> ra
>> nsform
>> Algorithm="http://www.w3.org/TR/2001/REC-xml-c14n-20010315"/></Transf
>> or
>> ms><DigestMethod
>> Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/><DigestValue>vj4p
>> 6F 
>> tqkZen6fsHlcyag8R2hF0=</DigestValue></Reference></SignedInfo><Signatu
>> re
>> Value>Jymbikn/5F8aUYQA6CaZmLYY9plO4KNfyu/M4TZP5l+3fy/pjwpkIsaeV1LXXyo
>> Value>7n
>> WLdpvruhCXy
>>
>> ID2ptAjzIWOJ/vp1YW94e0Yy7yfBijQNkew+FI1G7GKKt7T/UUIPRrXqWwo7EA8ZpCYSo
>> W
>> ktWqHZ
>>
>> iU7j7iJone1nLdNJNjY=</SignatureValue><KeyInfo><X509Data><X509Certific
>> a
>> te>MIIGuzCCBaOgAwIBAgIQCbCeZ64fHJPeNqAkc06I8TANBgkqhkiG9w0BAQUFADB0MQ
>> te>s
>> wCQYDVQQG
>>
>> EwJCUjETMBEGA1UEChMKSUNQLUJyYXNpbDEtMCsGA1UECxMkQ2VydGlzaWduIENlcnRpZ
>> m
>> ljYWRv
>>
>> cmEgRGlnaXRhbCBTLkEuMSEwHwYDVQQDExhBQyBDZXJ0aXNpZ24gTXVsdGlwbGEgRzMwH
>> h
>> cNMTAw
>>
>> NzI5MDAwMDAwWhcNMTEwNzI4MjM1OTU5WjCCAQsxCzAJBgNVBAYTAkJSMRMwEQYDVQQKF
>> A
>> pJQ1At
>>
>> QnJhc2lsMRUwEwYDVQQLFAxJRCAtIDEwODMzMTIxODA2BgNVBAsUL0F1dGVudGljYWRvI
>> H
>> BvciBD
>>
>> ZXJ0aXNpZ24gQ2VydGlmaWNhZG9yYSBEaWdpdGFsMRswGQYDVQQLFBJBc3NpbmF0dXJhI
>> F
>> RpcG8g
>>
>> QTExFDASBgNVBAsUCyhFTSBCUkFOQ08pMRQwEgYDVQQLFAsoRU0gQlJBTkNPKTEjMCEGA
>> 1
>> UEAxMa
>>
>> TUVESUFURUNIIElORk9STUFUSUNBIExUREExKDAmBgkqhkiG9w0BCQEWGWNvbnRhdG9Ad
>> G
>> Vjbm9t
>>
>> aWRpYS5jb20uYnIwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAM8txkPNL6gjEjSW4
>> T
>> umyO0w
>>
>> zBGmxNtCqU9DFNWQD1TWIbXaYduxoxnYEwNXrehla2YDslXUiM45SWvlmjlWoVV9T7F07
>> a
>> OGGysP
>>
>> aNLJW/y3CMq7Qrvsh+h30INqV8WWYXKHlmfLz4eNf8Di4xQvgm+7yxvkGHXXjxkWn6utB
>> W
>> tJAgMB
>>
>> AAGjggMyMIIDLjCBrQYDVR0RBIGlMIGioDgGBWBMAQMEoC8ELTE5MDExOTY3MTEyMDk3M
>> z
>> g4MDUw
>>
>> MDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMKAXBgVgTAEDAqAOBAxKQUlSIFNaQVBJUk+gG
>> MDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMKAXBgVgTAEDAqAOBAxKQUlSIFNaQVBJUk+Q
>> MDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMKAXBgVgTAEDAqAOBAxKQUlSIFNaQVBJUk+YF
>> MDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMKAXBgVgTAEDAqAOBAxKQUlSIFNaQVBJUk+Y
>> MDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMKAXBgVgTAEDAqAOBAxKQUlSIFNaQVBJUk+Ew
>> MDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMKAXBgVgTAEDAqAOBAxKQUlSIFNaQVBJUk+B
>>
>> AwOgEAQOMDM1OTM5NjgwMDAxNjegFwYFYEwBAwegDgQMMDAwMDAwMDAwMDAwgRljb250Y
>> X
>> RvQHRl
>>
>>
>
Y25vbWlkaWEuY29tLmJyMAkGA1UdEwQCMAAwHwYDVR0jBBgwFoAUhLBCMzSjQiWlKJc+g+t38OhP
>>
>> wlQwDgYDVR0PAQH/BAQDAgXgMFUGA1UdIAROMEwwSgYGYEwBAgELMEAwPgYIKwYBBQUHA
>> g
>> EWMmh0
>>
>> dHA6Ly9pY3AtYnJhc2lsLmNlcnRpc2lnbi5jb20uYnIvcmVwb3NpdG9yaW8vZHBjMIIBJ
>> Q
>> YDVR0f
>>
>> BIIBHDCCARgwXKBaoFiGVmh0dHA6Ly9pY3AtYnJhc2lsLmNlcnRpc2lnbi5jb20uYnIvc
>> m
>> Vwb3Np
>>
>> dG9yaW8vbGNyL0FDQ2VydGlzaWduTXVsdGlwbGFHMy9MYXRlc3RDUkwuY3JsMFugWaBXh
>> l
>> VodHRw
>>
>> Oi8vaWNwLWJyYXNpbC5vdXRyYWxjci5jb20uYnIvcmVwb3NpdG9yaW8vbGNyL0FDQ2Vyd
>> G
>> lzaWdu
>>
>> TXVsdGlwbGFHMy9MYXRlc3RDUkwuY3JsMFugWaBXhlVodHRwOi8vcmVwb3NpdG9yaW8ua
>> W
>> NwYnJh
>>
>> c2lsLmdvdi5ici9sY3IvQ2VydGlzaWduL0FDQ2VydGlzaWduTXVsdGlwbGFHMy9MYXRlc
>> 3
>> RDUkwu
>>
>> Y3JsMB0GA1UdJQQWMBQGCCsGAQUFBwMEBggrBgEFBQcDAjCBoAYIKwYBBQUHAQEEgZMwg
>> Z
>> AwKAYI
>>
>> KwYBBQUHMAGGHGh0dHA6Ly9vY3NwLmNlcnRpc2lnbi5jb20uYnIwZAYIKwYBBQUHMAKGW
>> G
>> h0dHA6
>>
>> Ly9pY3AtYnJhc2lsLmNlcnRpc2lnbi5jb20uYnIvcmVwb3NpdG9yaW8vY2VydGlmaWNhZ
>> G
>> 9zL0FD
>>
>> X0NlcnRpc2lnbl9NdWx0aXBsYV9HMy5wN2MwDQYJKoZIhvcNAQEFBQADggEBAGI9MCc6W
>> V
>> mz919C
>>
>> QLDB8E0R8HxfGyiz2uB14lPBDsueTJmJmlykQdnboMiyMGTocprEGsQxeI7a57BEUDVc0
>> f
>> SzNCCb
>>
>> SOnQOp9Uswri8pTw8fQG9OAkh1LCC9haTsNNMKbTHCciO7MUh34XkHuj4A0NIWG1aCynw
>> s
>> tRFWb8
>>
>> 97OZJJCc0IRvDs7yDJhgOwPmv3trFmwlfMU7n20pXtM9hKiI8o6h/0GwR6SyA1Yj4fZXf
>> X
>> xVENH4
>>
>> EjhIHR8Yrmre2JE2I+hFjyQaNPnAEztQEa0Cae2l3O0Q0tkM1x8EkiKFrnDggpc7gSwtL
>> EjhIHR8Yrmre2JE2I+C
>> EjhIHR8Yrmre2JE2I+wrkQBu
>>
>> jhie131VyDTuXLx9k082PLs=</X509Certificate></X509Data></KeyInfo></Sign
>> a
>> ture></NFe>
>>
>>  
>>
>> <protNFe
>> versao="1.10"><infProt><tpAmb>1</tpAmb><verAplic>SP_NFE_PL_005e</verA
>> p
>> lic><chNFe>35101003593968000167550030000101640000000003</chNFe><dhRec
>> lic>b
>> to>2010-10-20T17:48:15</dhRecbto><nProt>135100546996360</nProt><digVa
>> to>l
>>> vj4p6FtqkZen6fsHlcyag8R2hF0=</digVal><cStat>100</cStat><xMotivo>Auto
>>> r
>> izado o uso da NF-e</xMotivo></infProt></protNFe>
>>
>> </nfeProc>
>>
>>  
>>
>> ---------------------------------------------------------------------
>> -
>> --------------------------
>>
>>  
>>
>> Thanks a lot
>>
>>  
>>
>>  
>>
>>  
>>
>>  
>>
>>
>>
>> _______________________________________________
>> xmlsec mailing list
>> xmlsec at aleksey.com
>> http://www.aleksey.com/mailman/listinfo/xmlsec
> 
> _______________________________________________
> xmlsec mailing list
> xmlsec at aleksey.com
> http://www.aleksey.com/mailman/listinfo/xmlsec
-------------- next part --------------
A non-text attachment was scrubbed...
Name: meta.zip
Type: application/x-zip-compressed
Size: 27049 bytes
Desc: not available
URL: <http://www.aleksey.com/pipermail/xmlsec/attachments/20120607/98d65e26/attachment-0001.bin>

From aleksey at aleksey.com  Thu Jun  7 12:43:29 2012
From: aleksey at aleksey.com (Aleksey Sanin)
Date: Thu, 07 Jun 2012 12:43:29 -0700
Subject: [xmlsec] RES:  RES:   Trying to check sign
In-Reply-To: <01db01cd44e3$df87b410$9e971c30$@acm.org>
References: <00fc01cd435d$f7ce89e0$e76b9da0$@acm.org>
 <4FCEC586.3010703@aleksey.com> <012001cd43d9$77e0fc50$67a2f4f0$@acm.org>
 <4FCFAC50.7060902@aleksey.com> <01db01cd44e3$df87b410$9e971c30$@acm.org>
Message-ID: <4FD10461.6070305@aleksey.com>

You might want to find a good book on cryptography.

Shortly, the certificate verification is based on the verification
of the previous certificate in the chain until one finds a "trusted"
certificate. The errors you are getting indicate that xmlsec/openssl
can not build the certificate chain and find a "trusted" cert.


Aleksey

On 6/7/12 12:29 PM, Renato Tegon Forti wrote:
> Hi Aleksey,
> 
> Thanks for your help! Really thanks a lot! If you have time to help-me
> again!
> 
> I am a really confusing, I am trying understand what I need to check if one
> signature is valid using your xmlsec1 tool, and then implement this on C
> code!
> 
> My signed document has these properties (mt.xml):
> 
> Transform Algorithm: Enveloped
> Algorithm: xmldsig#sha1
> 
> I'd try a lot of things, but all of it return me: "err=20;msg=unable to get
> local issuer certificate"
> 
> For sampe:
> 
> I try this: 
> xmlsec1 --verify --id-attr:Id infNFe --trusted-der mt.der.cer mt.xml 
> but "mt.der.cer" is cert that is on : <KeyInfo><X509Data><X509Certificate>
> 
> So I thought the problem was the root certificate, because I already have
> the certificate of the user in <X509Certificate>, then I tried:
> 
> xmlsec1 --verify --id-attr:Id infNFe --trusted-der
> Autoridade_Certificadora_da_Raiz_Brasileira_v2.der.cer mt.xml
> Some error "err=20;msg=unable to get local issuer certificate "
> 
> Then I tried a variation, only to check result: (--untrusted-der)
> 
> xmlsec1 --verify --id-attr:Id infNFe --untrusted-der
> Autoridade_Certificadora_da_Raiz_Brasileira_v2.der.cer mt.xml
> the error change to: err=18;msg=self signed certificate
> 
> I tried too:
> 
> xmlsec1 --verify --id-attr:Id infNFe --trusted-der
> SERASA_Autoridade_Certificadora_Principal_v2.der.cer mt.xml
> xmlsec1 --verify --id-attr:Id infNFe --trusted-der
> SERASA_Autoridade_Certificadora_Digital_v2.der.cer mt.xml
> 
> Some error "err=20;msg=unable to get local issuer certificate "
> 
> Reading a book I understood that to verifying an XML Signature:
> 
> 1.
> Verify the signature of the <SignedInfo> element. -> To do so, recalculate
> the digest of the <SignedInfo> element (using the digest algorithm specified
> in the <SignatureMethod> element) and use the public verification key to
> verify that the value of the <SignatureValue> element is correct for the
> digest of the <SignedInfo> element. 
> 
> The public key (public verification key)  in my case is: <X509Certificate>
> OK?
> 
> 2.
> If this step passes, recalculate the digests of the references contained
> within the <SignedInfo> element and compare them to the digest values
> expressed in each <Reference> element's corresponding <DigestValue> element.
> 
> 
> Please see attached files! (meta.zip)
>  -> mt.xml [file that I want check signature]
> -> chain.png [cert chains]
> -> Autoridade_Certificadora_da_Raiz_Brasileira_v2.der.cer [root cert in der
> format]
> -> SERASA_Autoridade_Certificadora_Principal_v2.der.cer ->
> SERASA_Autoridade_Certificadora_Digital_v2.der.cer -> mt.der.cer [all other
> certs in chain ]
> 
> What am I doing wrong? What I misunderstood?
> Thanks a lot!
> 
> 
> 
> -----Mensagem original-----
> De: Aleksey Sanin [mailto:aleksey at aleksey.com] 
> Enviada em: quarta-feira, 6 de junho de 2012 16:15
> Para: Renato Tegon Forti
> Cc: xmlsec at aleksey.com
> Assunto: Re: [xmlsec] RES: Trying to check sign
> 
> It's not on the website but it is in the examples folder.
> 
> Aleksey
> 
> On 6/6/12 4:42 AM, Renato Tegon Forti wrote:
>>>> This means that xmlsec (or to be precise, openssl) needs to verify 
>>>> the
>> certificate and it can't find the next certificate in the chain.
>>
>> Thanks for answer. 
>>
>> One more question: what is the example
>> (http://www.aleksey.com/xmlsec/api/xmlsec-examples.html) that 
>> implement "Online XML Digital Signature Verifer"?
>> I want study code implementation of it!
>>
>> Thanks
>>
>> -----Mensagem original-----
>> De: Aleksey Sanin [mailto:aleksey at aleksey.com] Enviada em: 
>> ter?a-feira, 5 de junho de 2012 23:51
>> Para: Renato Tegon Forti
>> Cc: xmlsec at aleksey.com
>> Assunto: Re: [xmlsec] Trying to check sign
>>
>> This means that xmlsec (or to be precise, openssl) needs to verify the 
>> certificate and it can't find the next certificate in the chain.
>>
>> Aleksey
>>
>> On 6/5/12 1:58 PM, Renato Tegon Forti wrote:
>>> Hi,
>>>
>>>  
>>>
>>> I have one file that I want check sig (using KEYINFO node), I know 
>>> that the signature is valid, but tool returns me:
>>>
>>>  
>>>
>>> I use DTD, see xml below, please!
>>>
>>>  
>>>
>>> ---------------------------------------------------------------------
>>> -
>>> --------------------------
>>>
>>>  
>>>
>>> func=xmlSecOpenSSLX509StoreVerify:file=x509vfy.c:line=360:obj=x509-st
>>> o re:subj=X509_verify_cert:error=4:crypto
>>> library function failed:subj=/C=BR/O=ICP-Brasil/OU=ID - 
>>> 1083312/OU=Autenticado por Certisign Certificadora 
>>> Digital/OU=Assinatura Tipo A1/OU=(EM BRANCO)/OU=(EM 
>>> BRANCO)/CN=MEDIATECH INFORMATICA 
>>> LTDA/emailAddress=contato at tecnomidia.com.br;err=20;msg=unable
>>> <mailto:LTDA/emailAddress=contato at tecnomidia.com.br;err=20;msg=unable
>>>>
>>> to get local issuer certificate
>>>
>>> func=xmlSecOpenSSLX509StoreVerify:file=x509vfy.c:line=408:obj=x509-st
>>> o
>>> re:subj=unknown:error=71:certificate
>>> verification failed:err=20;msg=unable to get local issuer certificate
>>>
>>> func=xmlSecOpenSSLEvpSignatureVerify:file=signatures.c:line=346:obj=r
>>> s a-sha1:subj=EVP_VerifyFinal:error=18:data
>>> do not match:signature do not match
>>>
>>> RESULT: Signature is INVALID
>>>
>>> ---------------------------------------------------
>>>
>>> = VERIFICATION CONTEXT
>>>
>>> == Status: invalid
>>>
>>> == flags: 0x00000000
>>>
>>> == flags2: 0x00000000
>>>
>>> == Key Info Read Ctx:
>>>
>>> = KEY INFO READ CONTEXT
>>>
>>> == flags: 0x00000000
>>>
>>> == flags2: 0x00000000
>>>
>>> == enabled key data: all
>>>
>>> == RetrievalMethod level (cur/max): 0/1
>>>
>>> == TRANSFORMS CTX (status=0)
>>>
>>> == flags: 0x00000000
>>>
>>> == flags2: 0x00000000
>>>
>>> == enabled transforms: all
>>>
>>> === uri: NULL
>>>
>>> === uri xpointer expr: NULL
>>>
>>> == EncryptedKey level (cur/max): 0/1
>>>
>>> === KeyReq:
>>>
>>> ==== keyId: rsa
>>>
>>> ==== keyType: 0x00000001
>>>
>>> ==== keyUsage: 0x00000002
>>>
>>> ==== keyBitsSize: 0
>>>
>>> === list size: 0
>>>
>>> == Key Info Write Ctx:
>>>
>>> = KEY INFO WRITE CONTEXT
>>>
>>> == flags: 0x00000000
>>>
>>> == flags2: 0x00000000
>>>
>>> == enabled key data: all
>>>
>>> == RetrievalMethod level (cur/max): 0/1
>>>
>>> == TRANSFORMS CTX (status=0)
>>>
>>> == flags: 0x00000000
>>>
>>> == flags2: 0x00000000
>>>
>>> == enabled transforms: all
>>>
>>> === uri: NULL
>>>
>>> === uri xpointer expr: NULL
>>>
>>> == EncryptedKey level (cur/max): 0/1
>>>
>>> === KeyReq:
>>>
>>> ==== keyId: NULL
>>>
>>> ==== keyType: 0x00000001
>>>
>>> ==== keyUsage: 0xffffffff
>>>
>>> ==== keyBitsSize: 0
>>>
>>> === list size: 0
>>>
>>> == Signature Transform Ctx:
>>>
>>> == TRANSFORMS CTX (status=2)
>>>
>>> == flags: 0x00000000
>>>
>>> == flags2: 0x00000000
>>>
>>> == enabled transforms: all
>>>
>>> === uri: NULL
>>>
>>> === uri xpointer expr: NULL
>>>
>>> === Transform: c14n
>>> (href=http://www.w3.org/TR/2001/REC-xml-c14n-20010315)
>>>
>>> === Transform: rsa-sha1
>>> (href=http://www.w3.org/2000/09/xmldsig#rsa-sha1)
>>>
>>> === Transform: membuf-transform (href=NULL)
>>>
>>> == Signature Method:
>>>
>>> === Transform: rsa-sha1
>>> (href=http://www.w3.org/2000/09/xmldsig#rsa-sha1)
>>>
>>> == Signature Key:
>>>
>>> == KEY
>>>
>>> === method: RSAKeyValue
>>>
>>> === key type: Private
>>>
>>> === key name: test-rsa
>>>
>>> === key usage: -1
>>>
>>> === rsa key: size = 1024
>>>
>>> == SignedInfo References List:
>>>
>>> === list size: 1
>>>
>>> = REFERENCE VERIFICATION CONTEXT
>>>
>>> == Status: succeeded
>>>
>>> == URI: "#NFe35101003593968000167550030000101640000000003"
>>>
>>> == Reference Transform Ctx:
>>>
>>> == TRANSFORMS CTX (status=2)
>>>
>>> == flags: 0x00000000
>>>
>>> == flags2: 0x00000000
>>>
>>> == enabled transforms: all
>>>
>>> === uri:
>>>
>>> === uri xpointer expr: 
>>> #NFe35101003593968000167550030000101640000000003
>>>
>>> === Transform: xpointer
>>> (href=http://www.w3.org/2001/04/xmldsig-more/xptr)
>>>
>>> === Transform: enveloped-signature
>>> (href=http://www.w3.org/2000/09/xmldsig#enveloped-signature)
>>>
>>> === Transform: c14n
>>> (href=http://www.w3.org/TR/2001/REC-xml-c14n-20010315)
>>>
>>> === Transform: sha1 (href=http://www.w3.org/2000/09/xmldsig#sha1)
>>>
>>> === Transform: membuf-transform (href=NULL)
>>>
>>> == Digest Method:
>>>
>>> === Transform: sha1 (href=http://www.w3.org/2000/09/xmldsig#sha1)
>>>
>>> == Manifest References List:
>>>
>>> === list size: 0
>>>
>>>  
>>>
>>> ---------------------------------------------------------------------
>>> -
>>> --------------------------
>>>
>>>  
>>>
>>> Anyone can help-me to understand what I make wrong!
>>>
>>> What this exactly can mean: ?unable to get local issuer certificate?
>>>
>>>  
>>>
>>> This is my xml file ( the DTD is correct?):
>>>
>>>  
>>>
>>> ---------------------------------------------------------------------
>>> -
>>> --------------------------
>>>
>>>  
>>>
>>> <?xml version="1.0" encoding="UTF-8"?>
>>>
>>> <!DOCTYPE test [
>>>
>>> <!ATTLIST infNFe Id ID #IMPLIED>
>>>
>>> ]>
>>>
>>> <nfeProc xmlns="http://www.portalfiscal.inf.br/nfe" versao="1.10">
>>>
>>> <NFe xmlns="http://www.portalfiscal.inf.br/nfe"><infNFe
>>> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
>>> Id="NFe35101003593968000167550030000101640000000003"
>>> versao="1.10"><ide><cUF>35</cUF><cNF>000000000</cNF><natOp>VENDA MERC 
>>> C/ PGTO ST C/ 
>>> SUBSTITUIDO</natOp><indPag>1</indPag><mod>55</mod><serie>3</serie><nN
>>> F
>>>> 10164</nNF><dEmi>2010-10-20</dEmi><dSaiEnt>2010-10-20</dSaiEnt><tpNF
>>>>>
>>> 1</tpNF><cMunFG>3550308</cMunFG><tpImp>1</tpImp><tpEmis>1</tpEmis><cD
>>> V
>>>> 3</cDV><tpAmb>1</tpAmb><finNFe>1</finNFe><procEmi>0</procEmi><verPro
>>>> c 
>>>> 1.4.0</verProc></ide><emit><CNPJ>03593968000167</CNPJ><xNome>Mediate
>>>> c
>>> h Informatica LTDA</xNome><xFant>Mediatech Informatica 
>>> LTDA</xFant><enderEmit><xLgr>CORREIA DE 
>>> MELO</xLgr><nro>085</nro><xBairro>BOM
>>> RETIRO</xBairro><cMun>3550308</cMun><xMun>SAO
>>> PAULO</xMun><UF>SP</UF><CEP>01123020</CEP><cPais>1058</cPais><xPais>B
>>> R 
>>> ASIL</xPais><fone>1133521199</fone></enderEmit><IE>115633812110</IE><
>>> /
>>> emit><dest><CNPJ>11253910000100</CNPJ><xNome>AYSSO
>>> SYSTEMS LTDA EPP</xNome><enderDest><xLgr>RUA DOZE DE 
>>> NOVEMBRO</xLgr><nro>180</nro><xCpl>APT
>>> 183</xCpl><xBairro>CENTRO</xBairro><cMun>3501608</cMun><xMun>AMERICAN
>>> A 
>>> </xMun><UF>SP</UF><CEP>13465490</CEP><cPais>1058</cPais><xPais>BRASIL
>>> < /xPais><fone>1936459994</fone></enderDest><IE/></dest><det
>>> nItem="1"><prod><cProd>1160900000000001720000</cProd><cEAN/><xProd>MI
>>> D
>>> IA
>>> DIGITAL
>>> CD/DVD</xProd><NCM>85234011</NCM><CFOP>5405</CFOP><uCom>PC.</uCom><qC
>>> o
>>> m>100.0000</qCom><vUnCom>2.1500</vUnCom><vProd>215.00</vProd><cEANTri
>>> m>b
>>> /><uTrib>PC.</uTrib><qTrib>100.0000</qTrib><vUnTrib>2.1500</vUnTrib><
>>> v
>>> Frete>20.00</vFrete></prod><imposto><ICMS><ICMS60><orig>0</orig><CST>
>>> Frete>6
>>> 0</CST><vBCST>215.00</vBCST><vICMSST>0.00</vICMSST></ICMS60></ICMS><I
>>> P
>>> I><cEnq>999</cEnq><IPINT><CST>53</CST></IPINT></IPI><PIS><PISAliq><CS
>>> I>T
>>>> 01</CST><vBC>215.00</vBC><pPIS>0.65</pPIS><vPIS>1.40</vPIS></PISAliq
>>>>>
>>> </PIS><COFINS><COFINSAliq><CST>01</CST><vBC>215.00</vBC><pCOFINS>3.00
>>> < 
>>> /pCOFINS><vCOFINS>6.45</vCOFINS></COFINSAliq></COFINS></imposto></det
>>>>
>>> <total><ICMSTot><vBC>20.00</vBC><vICMS>0.00</vICMS><vBCST>0.00</vBCST
>>>>
>>> <vST>0.00</vST><vProd>215.00</vProd><vFrete>20.00</vFrete><vSeg>0.00<
>>> /
>>> vSeg><vDesc>0.00</vDesc><vII>0.00</vII><vIPI>0.00</vIPI><vPIS>1.40</v
>>> vSeg>P
>>> IS><vCOFINS>6.45</vCOFINS><vOutro>0.00</vOutro><vNF>235.00</vNF></ICM
>>> IS>S
>>> Tot></total><transp><modFrete>0</modFrete><transporta><CNPJ>072818860
>>> Tot>0
>>> 0138</CNPJ><xNom
>>  e
>>> Correio
>>> - Sedex</xNome><IE>ISENTO</IE><xEnder>Rua Correia de Melo, 
>>> 111</xEnder><xMun>Sao
>>>
>> Paulo</xMun><UF>SP</UF></transporta><vol><qVol>1</qVol><esp>CX.</esp><
>> pesoL> 
>> 1.000</pesoL><pesoB>1.000</pesoB></vol></transp><cobr><fat><nFat>10164
>> </nFat
>>> <vOrig>235.00</vOrig><vLiq>235.00</vLiq></fat><dup><nDup>001</nDup><d
>>> Venc>2
>> 010-10-20</dVenc><vDup>235.00</vDup></dup></cobr><infAdic><infCpl>Pedidos:
>>> 48033</infCpl></infAdic></infNFe><Signature
>>>
>>> xmlns="http://www.w3.org/2000/09/xmldsig#"><SignedInfo><Canonicalizat
>>> io
>>> nMethod
>>> Algorithm="http://www.w3.org/TR/2001/REC-xml-c14n-20010315"/><Signatu
>>> re
>>> Method
>>> Algorithm="http://www.w3.org/2000/09/xmldsig#rsa-sha1"/><Reference
>>>
>>> URI="#NFe35101003593968000167550030000101640000000003"><Transforms><T
>>> ra
>>> nsform
>>> Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature"/><T
>>> ra
>>> nsform
>>> Algorithm="http://www.w3.org/TR/2001/REC-xml-c14n-20010315"/></Transf
>>> or
>>> ms><DigestMethod
>>> Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/><DigestValue>vj4p
>>> 6F 
>>> tqkZen6fsHlcyag8R2hF0=</DigestValue></Reference></SignedInfo><Signatu
>>> re
>>> Value>Jymbikn/5F8aUYQA6CaZmLYY9plO4KNfyu/M4TZP5l+3fy/pjwpkIsaeV1LXXyo
>>> Value>7n
>>> WLdpvruhCXy
>>>
>>> ID2ptAjzIWOJ/vp1YW94e0Yy7yfBijQNkew+FI1G7GKKt7T/UUIPRrXqWwo7EA8ZpCYSo
>>> W
>>> ktWqHZ
>>>
>>> iU7j7iJone1nLdNJNjY=</SignatureValue><KeyInfo><X509Data><X509Certific
>>> a
>>> te>MIIGuzCCBaOgAwIBAgIQCbCeZ64fHJPeNqAkc06I8TANBgkqhkiG9w0BAQUFADB0MQ
>>> te>s
>>> wCQYDVQQG
>>>
>>> EwJCUjETMBEGA1UEChMKSUNQLUJyYXNpbDEtMCsGA1UECxMkQ2VydGlzaWduIENlcnRpZ
>>> m
>>> ljYWRv
>>>
>>> cmEgRGlnaXRhbCBTLkEuMSEwHwYDVQQDExhBQyBDZXJ0aXNpZ24gTXVsdGlwbGEgRzMwH
>>> h
>>> cNMTAw
>>>
>>> NzI5MDAwMDAwWhcNMTEwNzI4MjM1OTU5WjCCAQsxCzAJBgNVBAYTAkJSMRMwEQYDVQQKF
>>> A
>>> pJQ1At
>>>
>>> QnJhc2lsMRUwEwYDVQQLFAxJRCAtIDEwODMzMTIxODA2BgNVBAsUL0F1dGVudGljYWRvI
>>> H
>>> BvciBD
>>>
>>> ZXJ0aXNpZ24gQ2VydGlmaWNhZG9yYSBEaWdpdGFsMRswGQYDVQQLFBJBc3NpbmF0dXJhI
>>> F
>>> RpcG8g
>>>
>>> QTExFDASBgNVBAsUCyhFTSBCUkFOQ08pMRQwEgYDVQQLFAsoRU0gQlJBTkNPKTEjMCEGA
>>> 1
>>> UEAxMa
>>>
>>> TUVESUFURUNIIElORk9STUFUSUNBIExUREExKDAmBgkqhkiG9w0BCQEWGWNvbnRhdG9Ad
>>> G
>>> Vjbm9t
>>>
>>> aWRpYS5jb20uYnIwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAM8txkPNL6gjEjSW4
>>> T
>>> umyO0w
>>>
>>> zBGmxNtCqU9DFNWQD1TWIbXaYduxoxnYEwNXrehla2YDslXUiM45SWvlmjlWoVV9T7F07
>>> a
>>> OGGysP
>>>
>>> aNLJW/y3CMq7Qrvsh+h30INqV8WWYXKHlmfLz4eNf8Di4xQvgm+7yxvkGHXXjxkWn6utB
>>> W
>>> tJAgMB
>>>
>>> AAGjggMyMIIDLjCBrQYDVR0RBIGlMIGioDgGBWBMAQMEoC8ELTE5MDExOTY3MTEyMDk3M
>>> z
>>> g4MDUw
>>>
>>> MDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMKAXBgVgTAEDAqAOBAxKQUlSIFNaQVBJUk+gG
>>> MDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMKAXBgVgTAEDAqAOBAxKQUlSIFNaQVBJUk+Q
>>> MDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMKAXBgVgTAEDAqAOBAxKQUlSIFNaQVBJUk+YF
>>> MDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMKAXBgVgTAEDAqAOBAxKQUlSIFNaQVBJUk+Y
>>> MDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMKAXBgVgTAEDAqAOBAxKQUlSIFNaQVBJUk+Ew
>>> MDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMKAXBgVgTAEDAqAOBAxKQUlSIFNaQVBJUk+B
>>>
>>> AwOgEAQOMDM1OTM5NjgwMDAxNjegFwYFYEwBAwegDgQMMDAwMDAwMDAwMDAwgRljb250Y
>>> X
>>> RvQHRl
>>>
>>>
>>
> Y25vbWlkaWEuY29tLmJyMAkGA1UdEwQCMAAwHwYDVR0jBBgwFoAUhLBCMzSjQiWlKJc+g+t38OhP
>>>
>>> wlQwDgYDVR0PAQH/BAQDAgXgMFUGA1UdIAROMEwwSgYGYEwBAgELMEAwPgYIKwYBBQUHA
>>> g
>>> EWMmh0
>>>
>>> dHA6Ly9pY3AtYnJhc2lsLmNlcnRpc2lnbi5jb20uYnIvcmVwb3NpdG9yaW8vZHBjMIIBJ
>>> Q
>>> YDVR0f
>>>
>>> BIIBHDCCARgwXKBaoFiGVmh0dHA6Ly9pY3AtYnJhc2lsLmNlcnRpc2lnbi5jb20uYnIvc
>>> m
>>> Vwb3Np
>>>
>>> dG9yaW8vbGNyL0FDQ2VydGlzaWduTXVsdGlwbGFHMy9MYXRlc3RDUkwuY3JsMFugWaBXh
>>> l
>>> VodHRw
>>>
>>> Oi8vaWNwLWJyYXNpbC5vdXRyYWxjci5jb20uYnIvcmVwb3NpdG9yaW8vbGNyL0FDQ2Vyd
>>> G
>>> lzaWdu
>>>
>>> TXVsdGlwbGFHMy9MYXRlc3RDUkwuY3JsMFugWaBXhlVodHRwOi8vcmVwb3NpdG9yaW8ua
>>> W
>>> NwYnJh
>>>
>>> c2lsLmdvdi5ici9sY3IvQ2VydGlzaWduL0FDQ2VydGlzaWduTXVsdGlwbGFHMy9MYXRlc
>>> 3
>>> RDUkwu
>>>
>>> Y3JsMB0GA1UdJQQWMBQGCCsGAQUFBwMEBggrBgEFBQcDAjCBoAYIKwYBBQUHAQEEgZMwg
>>> Z
>>> AwKAYI
>>>
>>> KwYBBQUHMAGGHGh0dHA6Ly9vY3NwLmNlcnRpc2lnbi5jb20uYnIwZAYIKwYBBQUHMAKGW
>>> G
>>> h0dHA6
>>>
>>> Ly9pY3AtYnJhc2lsLmNlcnRpc2lnbi5jb20uYnIvcmVwb3NpdG9yaW8vY2VydGlmaWNhZ
>>> G
>>> 9zL0FD
>>>
>>> X0NlcnRpc2lnbl9NdWx0aXBsYV9HMy5wN2MwDQYJKoZIhvcNAQEFBQADggEBAGI9MCc6W
>>> V
>>> mz919C
>>>
>>> QLDB8E0R8HxfGyiz2uB14lPBDsueTJmJmlykQdnboMiyMGTocprEGsQxeI7a57BEUDVc0
>>> f
>>> SzNCCb
>>>
>>> SOnQOp9Uswri8pTw8fQG9OAkh1LCC9haTsNNMKbTHCciO7MUh34XkHuj4A0NIWG1aCynw
>>> s
>>> tRFWb8
>>>
>>> 97OZJJCc0IRvDs7yDJhgOwPmv3trFmwlfMU7n20pXtM9hKiI8o6h/0GwR6SyA1Yj4fZXf
>>> X
>>> xVENH4
>>>
>>> EjhIHR8Yrmre2JE2I+hFjyQaNPnAEztQEa0Cae2l3O0Q0tkM1x8EkiKFrnDggpc7gSwtL
>>> EjhIHR8Yrmre2JE2I+C
>>> EjhIHR8Yrmre2JE2I+wrkQBu
>>>
>>> jhie131VyDTuXLx9k082PLs=</X509Certificate></X509Data></KeyInfo></Sign
>>> a
>>> ture></NFe>
>>>
>>>  
>>>
>>> <protNFe
>>> versao="1.10"><infProt><tpAmb>1</tpAmb><verAplic>SP_NFE_PL_005e</verA
>>> p
>>> lic><chNFe>35101003593968000167550030000101640000000003</chNFe><dhRec
>>> lic>b
>>> to>2010-10-20T17:48:15</dhRecbto><nProt>135100546996360</nProt><digVa
>>> to>l
>>>> vj4p6FtqkZen6fsHlcyag8R2hF0=</digVal><cStat>100</cStat><xMotivo>Auto
>>>> r
>>> izado o uso da NF-e</xMotivo></infProt></protNFe>
>>>
>>> </nfeProc>
>>>
>>>  
>>>
>>> ---------------------------------------------------------------------
>>> -
>>> --------------------------
>>>
>>>  
>>>
>>> Thanks a lot
>>>
>>>  
>>>
>>>  
>>>
>>>  
>>>
>>>  
>>>
>>>
>>>
>>> _______________________________________________
>>> xmlsec mailing list
>>> xmlsec at aleksey.com
>>> http://www.aleksey.com/mailman/listinfo/xmlsec
>>
>> _______________________________________________
>> xmlsec mailing list
>> xmlsec at aleksey.com
>> http://www.aleksey.com/mailman/listinfo/xmlsec

From re.tf at acm.org  Thu Jun  7 12:53:51 2012
From: re.tf at acm.org (Renato Tegon Forti)
Date: Thu, 7 Jun 2012 16:53:51 -0300
Subject: [xmlsec] RES: RES:  RES:   Trying to check sign
In-Reply-To: <4FD10461.6070305@aleksey.com>
References: <00fc01cd435d$f7ce89e0$e76b9da0$@acm.org>
 <4FCEC586.3010703@aleksey.com> <012001cd43d9$77e0fc50$67a2f4f0$@acm.org>
 <4FCFAC50.7060902@aleksey.com> <01db01cd44e3$df87b410$9e971c30$@acm.org>
 <4FD10461.6070305@aleksey.com>
Message-ID: <01eb01cd44e7$442a9d30$cc7fd790$@acm.org>

Thanks for response.

Only one doubt: this mean that I don't have this  "trusted" certificate
installed in my machine (that I run xmlsec1 tool), this is a root cert?
I am reading "Secure XML" from Donald E. , but all it is new to me (than
very complex)

Thanks for help!

-----Mensagem original-----
De: Aleksey Sanin [mailto:aleksey at aleksey.com] 
Enviada em: quinta-feira, 7 de junho de 2012 16:43
Para: Renato Tegon Forti
Cc: xmlsec at aleksey.com
Assunto: Re: RES: [xmlsec] RES: Trying to check sign

You might want to find a good book on cryptography.

Shortly, the certificate verification is based on the verification of the
previous certificate in the chain until one finds a "trusted"
certificate. The errors you are getting indicate that xmlsec/openssl can not
build the certificate chain and find a "trusted" cert.


Aleksey

On 6/7/12 12:29 PM, Renato Tegon Forti wrote:
> Hi Aleksey,
> 
> Thanks for your help! Really thanks a lot! If you have time to help-me 
> again!
> 
> I am a really confusing, I am trying understand what I need to check 
> if one signature is valid using your xmlsec1 tool, and then implement 
> this on C code!
> 
> My signed document has these properties (mt.xml):
> 
> Transform Algorithm: Enveloped
> Algorithm: xmldsig#sha1
> 
> I'd try a lot of things, but all of it return me: "err=20;msg=unable 
> to get local issuer certificate"
> 
> For sampe:
> 
> I try this: 
> xmlsec1 --verify --id-attr:Id infNFe --trusted-der mt.der.cer mt.xml 
> but "mt.der.cer" is cert that is on : 
> <KeyInfo><X509Data><X509Certificate>
> 
> So I thought the problem was the root certificate, because I already 
> have the certificate of the user in <X509Certificate>, then I tried:
> 
> xmlsec1 --verify --id-attr:Id infNFe --trusted-der 
> Autoridade_Certificadora_da_Raiz_Brasileira_v2.der.cer mt.xml Some 
> error "err=20;msg=unable to get local issuer certificate "
> 
> Then I tried a variation, only to check result: (--untrusted-der)
> 
> xmlsec1 --verify --id-attr:Id infNFe --untrusted-der 
> Autoridade_Certificadora_da_Raiz_Brasileira_v2.der.cer mt.xml the 
> error change to: err=18;msg=self signed certificate
> 
> I tried too:
> 
> xmlsec1 --verify --id-attr:Id infNFe --trusted-der 
> SERASA_Autoridade_Certificadora_Principal_v2.der.cer mt.xml
> xmlsec1 --verify --id-attr:Id infNFe --trusted-der 
> SERASA_Autoridade_Certificadora_Digital_v2.der.cer mt.xml
> 
> Some error "err=20;msg=unable to get local issuer certificate "
> 
> Reading a book I understood that to verifying an XML Signature:
> 
> 1.
> Verify the signature of the <SignedInfo> element. -> To do so, 
> recalculate the digest of the <SignedInfo> element (using the digest 
> algorithm specified in the <SignatureMethod> element) and use the 
> public verification key to verify that the value of the 
> <SignatureValue> element is correct for the digest of the <SignedInfo>
element.
> 
> The public key (public verification key)  in my case is: 
> <X509Certificate> OK?
> 
> 2.
> If this step passes, recalculate the digests of the references 
> contained within the <SignedInfo> element and compare them to the 
> digest values expressed in each <Reference> element's corresponding
<DigestValue> element.
> 
> 
> Please see attached files! (meta.zip)
>  -> mt.xml [file that I want check signature]
> -> chain.png [cert chains]
> -> Autoridade_Certificadora_da_Raiz_Brasileira_v2.der.cer [root cert 
> -> in der
> format]
> -> SERASA_Autoridade_Certificadora_Principal_v2.der.cer ->
> SERASA_Autoridade_Certificadora_Digital_v2.der.cer -> mt.der.cer [all 
> other certs in chain ]
> 
> What am I doing wrong? What I misunderstood?
> Thanks a lot!
> 
> 
> 
> -----Mensagem original-----
> De: Aleksey Sanin [mailto:aleksey at aleksey.com] Enviada em: 
> quarta-feira, 6 de junho de 2012 16:15
> Para: Renato Tegon Forti
> Cc: xmlsec at aleksey.com
> Assunto: Re: [xmlsec] RES: Trying to check sign
> 
> It's not on the website but it is in the examples folder.
> 
> Aleksey
> 
> On 6/6/12 4:42 AM, Renato Tegon Forti wrote:
>>>> This means that xmlsec (or to be precise, openssl) needs to verify 
>>>> the
>> certificate and it can't find the next certificate in the chain.
>>
>> Thanks for answer. 
>>
>> One more question: what is the example
>> (http://www.aleksey.com/xmlsec/api/xmlsec-examples.html) that 
>> implement "Online XML Digital Signature Verifer"?
>> I want study code implementation of it!
>>
>> Thanks
>>
>> -----Mensagem original-----
>> De: Aleksey Sanin [mailto:aleksey at aleksey.com] Enviada em: 
>> ter?a-feira, 5 de junho de 2012 23:51
>> Para: Renato Tegon Forti
>> Cc: xmlsec at aleksey.com
>> Assunto: Re: [xmlsec] Trying to check sign
>>
>> This means that xmlsec (or to be precise, openssl) needs to verify 
>> the certificate and it can't find the next certificate in the chain.
>>
>> Aleksey
>>
>> On 6/5/12 1:58 PM, Renato Tegon Forti wrote:
>>> Hi,
>>>
>>>  
>>>
>>> I have one file that I want check sig (using KEYINFO node), I know 
>>> that the signature is valid, but tool returns me:
>>>
>>>  
>>>
>>> I use DTD, see xml below, please!
>>>
>>>  
>>>
>>> --------------------------------------------------------------------
>>> -
>>> -
>>> --------------------------
>>>
>>>  
>>>
>>> func=xmlSecOpenSSLX509StoreVerify:file=x509vfy.c:line=360:obj=x509-s
>>> t o re:subj=X509_verify_cert:error=4:crypto
>>> library function failed:subj=/C=BR/O=ICP-Brasil/OU=ID - 
>>> 1083312/OU=Autenticado por Certisign Certificadora 
>>> Digital/OU=Assinatura Tipo A1/OU=(EM BRANCO)/OU=(EM 
>>> BRANCO)/CN=MEDIATECH INFORMATICA 
>>> LTDA/emailAddress=contato at tecnomidia.com.br;err=20;msg=unable
>>> <mailto:LTDA/emailAddress=contato at tecnomidia.com.br;err=20;msg=unabl
>>> e
>>>>
>>> to get local issuer certificate
>>>
>>> func=xmlSecOpenSSLX509StoreVerify:file=x509vfy.c:line=408:obj=x509-s
>>> t
>>> o
>>> re:subj=unknown:error=71:certificate
>>> verification failed:err=20;msg=unable to get local issuer 
>>> certificate
>>>
>>> func=xmlSecOpenSSLEvpSignatureVerify:file=signatures.c:line=346:obj=
>>> r s a-sha1:subj=EVP_VerifyFinal:error=18:data
>>> do not match:signature do not match
>>>
>>> RESULT: Signature is INVALID
>>>
>>> ---------------------------------------------------
>>>
>>> = VERIFICATION CONTEXT
>>>
>>> == Status: invalid
>>>
>>> == flags: 0x00000000
>>>
>>> == flags2: 0x00000000
>>>
>>> == Key Info Read Ctx:
>>>
>>> = KEY INFO READ CONTEXT
>>>
>>> == flags: 0x00000000
>>>
>>> == flags2: 0x00000000
>>>
>>> == enabled key data: all
>>>
>>> == RetrievalMethod level (cur/max): 0/1
>>>
>>> == TRANSFORMS CTX (status=0)
>>>
>>> == flags: 0x00000000
>>>
>>> == flags2: 0x00000000
>>>
>>> == enabled transforms: all
>>>
>>> === uri: NULL
>>>
>>> === uri xpointer expr: NULL
>>>
>>> == EncryptedKey level (cur/max): 0/1
>>>
>>> === KeyReq:
>>>
>>> ==== keyId: rsa
>>>
>>> ==== keyType: 0x00000001
>>>
>>> ==== keyUsage: 0x00000002
>>>
>>> ==== keyBitsSize: 0
>>>
>>> === list size: 0
>>>
>>> == Key Info Write Ctx:
>>>
>>> = KEY INFO WRITE CONTEXT
>>>
>>> == flags: 0x00000000
>>>
>>> == flags2: 0x00000000
>>>
>>> == enabled key data: all
>>>
>>> == RetrievalMethod level (cur/max): 0/1
>>>
>>> == TRANSFORMS CTX (status=0)
>>>
>>> == flags: 0x00000000
>>>
>>> == flags2: 0x00000000
>>>
>>> == enabled transforms: all
>>>
>>> === uri: NULL
>>>
>>> === uri xpointer expr: NULL
>>>
>>> == EncryptedKey level (cur/max): 0/1
>>>
>>> === KeyReq:
>>>
>>> ==== keyId: NULL
>>>
>>> ==== keyType: 0x00000001
>>>
>>> ==== keyUsage: 0xffffffff
>>>
>>> ==== keyBitsSize: 0
>>>
>>> === list size: 0
>>>
>>> == Signature Transform Ctx:
>>>
>>> == TRANSFORMS CTX (status=2)
>>>
>>> == flags: 0x00000000
>>>
>>> == flags2: 0x00000000
>>>
>>> == enabled transforms: all
>>>
>>> === uri: NULL
>>>
>>> === uri xpointer expr: NULL
>>>
>>> === Transform: c14n
>>> (href=http://www.w3.org/TR/2001/REC-xml-c14n-20010315)
>>>
>>> === Transform: rsa-sha1
>>> (href=http://www.w3.org/2000/09/xmldsig#rsa-sha1)
>>>
>>> === Transform: membuf-transform (href=NULL)
>>>
>>> == Signature Method:
>>>
>>> === Transform: rsa-sha1
>>> (href=http://www.w3.org/2000/09/xmldsig#rsa-sha1)
>>>
>>> == Signature Key:
>>>
>>> == KEY
>>>
>>> === method: RSAKeyValue
>>>
>>> === key type: Private
>>>
>>> === key name: test-rsa
>>>
>>> === key usage: -1
>>>
>>> === rsa key: size = 1024
>>>
>>> == SignedInfo References List:
>>>
>>> === list size: 1
>>>
>>> = REFERENCE VERIFICATION CONTEXT
>>>
>>> == Status: succeeded
>>>
>>> == URI: "#NFe35101003593968000167550030000101640000000003"
>>>
>>> == Reference Transform Ctx:
>>>
>>> == TRANSFORMS CTX (status=2)
>>>
>>> == flags: 0x00000000
>>>
>>> == flags2: 0x00000000
>>>
>>> == enabled transforms: all
>>>
>>> === uri:
>>>
>>> === uri xpointer expr: 
>>> #NFe35101003593968000167550030000101640000000003
>>>
>>> === Transform: xpointer
>>> (href=http://www.w3.org/2001/04/xmldsig-more/xptr)
>>>
>>> === Transform: enveloped-signature
>>> (href=http://www.w3.org/2000/09/xmldsig#enveloped-signature)
>>>
>>> === Transform: c14n
>>> (href=http://www.w3.org/TR/2001/REC-xml-c14n-20010315)
>>>
>>> === Transform: sha1 (href=http://www.w3.org/2000/09/xmldsig#sha1)
>>>
>>> === Transform: membuf-transform (href=NULL)
>>>
>>> == Digest Method:
>>>
>>> === Transform: sha1 (href=http://www.w3.org/2000/09/xmldsig#sha1)
>>>
>>> == Manifest References List:
>>>
>>> === list size: 0
>>>
>>>  
>>>
>>> --------------------------------------------------------------------
>>> -
>>> -
>>> --------------------------
>>>
>>>  
>>>
>>> Anyone can help-me to understand what I make wrong!
>>>
>>> What this exactly can mean: ?unable to get local issuer certificate?
>>>
>>>  
>>>
>>> This is my xml file ( the DTD is correct?):
>>>
>>>  
>>>
>>> --------------------------------------------------------------------
>>> -
>>> -
>>> --------------------------
>>>
>>>  
>>>
>>> <?xml version="1.0" encoding="UTF-8"?>
>>>
>>> <!DOCTYPE test [
>>>
>>> <!ATTLIST infNFe Id ID #IMPLIED>
>>>
>>> ]>
>>>
>>> <nfeProc xmlns="http://www.portalfiscal.inf.br/nfe" versao="1.10">
>>>
>>> <NFe xmlns="http://www.portalfiscal.inf.br/nfe"><infNFe
>>> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
>>> Id="NFe35101003593968000167550030000101640000000003"
>>> versao="1.10"><ide><cUF>35</cUF><cNF>000000000</cNF><natOp>VENDA 
>>> MERC C/ PGTO ST C/ 
>>> SUBSTITUIDO</natOp><indPag>1</indPag><mod>55</mod><serie>3</serie><n
>>> N
>>> F
>>>> 10164</nNF><dEmi>2010-10-20</dEmi><dSaiEnt>2010-10-20</dSaiEnt><tpN
>>>> F
>>>>>
>>> 1</tpNF><cMunFG>3550308</cMunFG><tpImp>1</tpImp><tpEmis>1</tpEmis><c
>>> D
>>> V
>>>> 3</cDV><tpAmb>1</tpAmb><finNFe>1</finNFe><procEmi>0</procEmi><verPr
>>>> o
>>>> c
>>>> 1.4.0</verProc></ide><emit><CNPJ>03593968000167</CNPJ><xNome>Mediat
>>>> e
>>>> c
>>> h Informatica LTDA</xNome><xFant>Mediatech Informatica 
>>> LTDA</xFant><enderEmit><xLgr>CORREIA DE 
>>> MELO</xLgr><nro>085</nro><xBairro>BOM
>>> RETIRO</xBairro><cMun>3550308</cMun><xMun>SAO
>>> PAULO</xMun><UF>SP</UF><CEP>01123020</CEP><cPais>1058</cPais><xPais>
>>> B
>>> R
>>> ASIL</xPais><fone>1133521199</fone></enderEmit><IE>115633812110</IE>
>>> <
>>> /
>>> emit><dest><CNPJ>11253910000100</CNPJ><xNome>AYSSO
>>> SYSTEMS LTDA EPP</xNome><enderDest><xLgr>RUA DOZE DE 
>>> NOVEMBRO</xLgr><nro>180</nro><xCpl>APT
>>> 183</xCpl><xBairro>CENTRO</xBairro><cMun>3501608</cMun><xMun>AMERICA
>>> N
>>> A
>>> </xMun><UF>SP</UF><CEP>13465490</CEP><cPais>1058</cPais><xPais>BRASI
>>> L < /xPais><fone>1936459994</fone></enderDest><IE/></dest><det
>>> nItem="1"><prod><cProd>1160900000000001720000</cProd><cEAN/><xProd>M
>>> I
>>> D
>>> IA
>>> DIGITAL
>>> CD/DVD</xProd><NCM>85234011</NCM><CFOP>5405</CFOP><uCom>PC.</uCom><q
>>> C
>>> o
>>> m>100.0000</qCom><vUnCom>2.1500</vUnCom><vProd>215.00</vProd><cEANTr
>>> m>i
>>> m>b
>>> /><uTrib>PC.</uTrib><qTrib>100.0000</qTrib><vUnTrib>2.1500</vUnTrib>
>>> <
>>> v
>>> Frete>20.00</vFrete></prod><imposto><ICMS><ICMS60><orig>0</orig><CST
>>> Frete>>
>>> Frete>6
>>> 0</CST><vBCST>215.00</vBCST><vICMSST>0.00</vICMSST></ICMS60></ICMS><
>>> I
>>> P
>>> I><cEnq>999</cEnq><IPINT><CST>53</CST></IPINT></IPI><PIS><PISAliq><C
>>> I>S
>>> I>T
>>>> 01</CST><vBC>215.00</vBC><pPIS>0.65</pPIS><vPIS>1.40</vPIS></PISAli
>>>> q
>>>>>
>>> </PIS><COFINS><COFINSAliq><CST>01</CST><vBC>215.00</vBC><pCOFINS>3.0
>>> 0
>>> <
>>> /pCOFINS><vCOFINS>6.45</vCOFINS></COFINSAliq></COFINS></imposto></de
>>> t
>>>>
>>> <total><ICMSTot><vBC>20.00</vBC><vICMS>0.00</vICMS><vBCST>0.00</vBCS
>>> T
>>>>
>>> <vST>0.00</vST><vProd>215.00</vProd><vFrete>20.00</vFrete><vSeg>0.00
>>> <
>>> /
>>> vSeg><vDesc>0.00</vDesc><vII>0.00</vII><vIPI>0.00</vIPI><vPIS>1.40</
>>> vSeg>v
>>> vSeg>P
>>> IS><vCOFINS>6.45</vCOFINS><vOutro>0.00</vOutro><vNF>235.00</vNF></IC
>>> IS>M
>>> IS>S
>>> Tot></total><transp><modFrete>0</modFrete><transporta><CNPJ>07281886
>>> Tot>0
>>> Tot>0
>>> 0138</CNPJ><xNom
>>  e
>>> Correio
>>> - Sedex</xNome><IE>ISENTO</IE><xEnder>Rua Correia de Melo, 
>>> 111</xEnder><xMun>Sao
>>>
>> Paulo</xMun><UF>SP</UF></transporta><vol><qVol>1</qVol><esp>CX.</esp>
>> <
>> pesoL> 
>> 1.000</pesoL><pesoB>1.000</pesoB></vol></transp><cobr><fat><nFat>1016
>> 4
>> </nFat
>>> <vOrig>235.00</vOrig><vLiq>235.00</vLiq></fat><dup><nDup>001</nDup><
>>> d
>>> Venc>2
>>
010-10-20</dVenc><vDup>235.00</vDup></dup></cobr><infAdic><infCpl>Pedidos:
>>> 48033</infCpl></infAdic></infNFe><Signature
>>>
>>> xmlns="http://www.w3.org/2000/09/xmldsig#"><SignedInfo><Canonicaliza
>>> t
>>> io
>>> nMethod
>>> Algorithm="http://www.w3.org/TR/2001/REC-xml-c14n-20010315"/><Signat
>>> u
>>> re
>>> Method
>>> Algorithm="http://www.w3.org/2000/09/xmldsig#rsa-sha1"/><Reference
>>>
>>> URI="#NFe35101003593968000167550030000101640000000003"><Transforms><
>>> T
>>> ra
>>> nsform
>>> Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature"/><
>>> T
>>> ra
>>> nsform
>>> Algorithm="http://www.w3.org/TR/2001/REC-xml-c14n-20010315"/></Trans
>>> f
>>> or
>>> ms><DigestMethod
>>> Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/><DigestValue>vj4
>>> p
>>> 6F
>>> tqkZen6fsHlcyag8R2hF0=</DigestValue></Reference></SignedInfo><Signat
>>> u
>>> re
>>> Value>Jymbikn/5F8aUYQA6CaZmLYY9plO4KNfyu/M4TZP5l+3fy/pjwpkIsaeV1LXXy
>>> Value>o
>>> Value>7n
>>> WLdpvruhCXy
>>>
>>> ID2ptAjzIWOJ/vp1YW94e0Yy7yfBijQNkew+FI1G7GKKt7T/UUIPRrXqWwo7EA8ZpCYS
>>> o
>>> W
>>> ktWqHZ
>>>
>>> iU7j7iJone1nLdNJNjY=</SignatureValue><KeyInfo><X509Data><X509Certifi
>>> c
>>> a
>>> te>MIIGuzCCBaOgAwIBAgIQCbCeZ64fHJPeNqAkc06I8TANBgkqhkiG9w0BAQUFADB0M
>>> te>Q
>>> te>s
>>> wCQYDVQQG
>>>
>>> EwJCUjETMBEGA1UEChMKSUNQLUJyYXNpbDEtMCsGA1UECxMkQ2VydGlzaWduIENlcnRp
>>> Z
>>> m
>>> ljYWRv
>>>
>>> cmEgRGlnaXRhbCBTLkEuMSEwHwYDVQQDExhBQyBDZXJ0aXNpZ24gTXVsdGlwbGEgRzMw
>>> H
>>> h
>>> cNMTAw
>>>
>>> NzI5MDAwMDAwWhcNMTEwNzI4MjM1OTU5WjCCAQsxCzAJBgNVBAYTAkJSMRMwEQYDVQQK
>>> F
>>> A
>>> pJQ1At
>>>
>>> QnJhc2lsMRUwEwYDVQQLFAxJRCAtIDEwODMzMTIxODA2BgNVBAsUL0F1dGVudGljYWRv
>>> I
>>> H
>>> BvciBD
>>>
>>> ZXJ0aXNpZ24gQ2VydGlmaWNhZG9yYSBEaWdpdGFsMRswGQYDVQQLFBJBc3NpbmF0dXJh
>>> I
>>> F
>>> RpcG8g
>>>
>>> QTExFDASBgNVBAsUCyhFTSBCUkFOQ08pMRQwEgYDVQQLFAsoRU0gQlJBTkNPKTEjMCEG
>>> A
>>> 1
>>> UEAxMa
>>>
>>> TUVESUFURUNIIElORk9STUFUSUNBIExUREExKDAmBgkqhkiG9w0BCQEWGWNvbnRhdG9A
>>> d
>>> G
>>> Vjbm9t
>>>
>>> aWRpYS5jb20uYnIwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAM8txkPNL6gjEjSW
>>> 4
>>> T
>>> umyO0w
>>>
>>> zBGmxNtCqU9DFNWQD1TWIbXaYduxoxnYEwNXrehla2YDslXUiM45SWvlmjlWoVV9T7F0
>>> 7
>>> a
>>> OGGysP
>>>
>>> aNLJW/y3CMq7Qrvsh+h30INqV8WWYXKHlmfLz4eNf8Di4xQvgm+7yxvkGHXXjxkWn6ut
>>> B
>>> W
>>> tJAgMB
>>>
>>> AAGjggMyMIIDLjCBrQYDVR0RBIGlMIGioDgGBWBMAQMEoC8ELTE5MDExOTY3MTEyMDk3
>>> M
>>> z
>>> g4MDUw
>>>
>>> MDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMKAXBgVgTAEDAqAOBAxKQUlSIFNaQVBJUk+g
>>> MDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMKAXBgVgTAEDAqAOBAxKQUlSIFNaQVBJUk+G
>>> MDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMKAXBgVgTAEDAqAOBAxKQUlSIFNaQVBJUk+Q
>>> MDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMKAXBgVgTAEDAqAOBAxKQUlSIFNaQVBJUk+Y
>>> MDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMKAXBgVgTAEDAqAOBAxKQUlSIFNaQVBJUk+F
>>> MDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMKAXBgVgTAEDAqAOBAxKQUlSIFNaQVBJUk+Y
>>> MDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMKAXBgVgTAEDAqAOBAxKQUlSIFNaQVBJUk+E
>>> MDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMKAXBgVgTAEDAqAOBAxKQUlSIFNaQVBJUk+w
>>> MDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMKAXBgVgTAEDAqAOBAxKQUlSIFNaQVBJUk+B
>>>
>>> AwOgEAQOMDM1OTM5NjgwMDAxNjegFwYFYEwBAwegDgQMMDAwMDAwMDAwMDAwgRljb250
>>> Y
>>> X
>>> RvQHRl
>>>
>>>
>>
>
Y25vbWlkaWEuY29tLmJyMAkGA1UdEwQCMAAwHwYDVR0jBBgwFoAUhLBCMzSjQiWlKJc+g+t38OhP
>>>
>>> wlQwDgYDVR0PAQH/BAQDAgXgMFUGA1UdIAROMEwwSgYGYEwBAgELMEAwPgYIKwYBBQUH
>>> A
>>> g
>>> EWMmh0
>>>
>>> dHA6Ly9pY3AtYnJhc2lsLmNlcnRpc2lnbi5jb20uYnIvcmVwb3NpdG9yaW8vZHBjMIIB
>>> J
>>> Q
>>> YDVR0f
>>>
>>> BIIBHDCCARgwXKBaoFiGVmh0dHA6Ly9pY3AtYnJhc2lsLmNlcnRpc2lnbi5jb20uYnIv
>>> c
>>> m
>>> Vwb3Np
>>>
>>> dG9yaW8vbGNyL0FDQ2VydGlzaWduTXVsdGlwbGFHMy9MYXRlc3RDUkwuY3JsMFugWaBX
>>> h
>>> l
>>> VodHRw
>>>
>>> Oi8vaWNwLWJyYXNpbC5vdXRyYWxjci5jb20uYnIvcmVwb3NpdG9yaW8vbGNyL0FDQ2Vy
>>> d
>>> G
>>> lzaWdu
>>>
>>> TXVsdGlwbGFHMy9MYXRlc3RDUkwuY3JsMFugWaBXhlVodHRwOi8vcmVwb3NpdG9yaW8u
>>> a
>>> W
>>> NwYnJh
>>>
>>> c2lsLmdvdi5ici9sY3IvQ2VydGlzaWduL0FDQ2VydGlzaWduTXVsdGlwbGFHMy9MYXRl
>>> c
>>> 3
>>> RDUkwu
>>>
>>> Y3JsMB0GA1UdJQQWMBQGCCsGAQUFBwMEBggrBgEFBQcDAjCBoAYIKwYBBQUHAQEEgZMw
>>> g
>>> Z
>>> AwKAYI
>>>
>>> KwYBBQUHMAGGHGh0dHA6Ly9vY3NwLmNlcnRpc2lnbi5jb20uYnIwZAYIKwYBBQUHMAKG
>>> W
>>> G
>>> h0dHA6
>>>
>>> Ly9pY3AtYnJhc2lsLmNlcnRpc2lnbi5jb20uYnIvcmVwb3NpdG9yaW8vY2VydGlmaWNh
>>> Z
>>> G
>>> 9zL0FD
>>>
>>> X0NlcnRpc2lnbl9NdWx0aXBsYV9HMy5wN2MwDQYJKoZIhvcNAQEFBQADggEBAGI9MCc6
>>> W
>>> V
>>> mz919C
>>>
>>> QLDB8E0R8HxfGyiz2uB14lPBDsueTJmJmlykQdnboMiyMGTocprEGsQxeI7a57BEUDVc
>>> 0
>>> f
>>> SzNCCb
>>>
>>> SOnQOp9Uswri8pTw8fQG9OAkh1LCC9haTsNNMKbTHCciO7MUh34XkHuj4A0NIWG1aCyn
>>> w
>>> s
>>> tRFWb8
>>>
>>> 97OZJJCc0IRvDs7yDJhgOwPmv3trFmwlfMU7n20pXtM9hKiI8o6h/0GwR6SyA1Yj4fZX
>>> f
>>> X
>>> xVENH4
>>>
>>> EjhIHR8Yrmre2JE2I+hFjyQaNPnAEztQEa0Cae2l3O0Q0tkM1x8EkiKFrnDggpc7gSwt
>>> EjhIHR8Yrmre2JE2I+L
>>> EjhIHR8Yrmre2JE2I+C
>>> EjhIHR8Yrmre2JE2I+wrkQBu
>>>
>>> jhie131VyDTuXLx9k082PLs=</X509Certificate></X509Data></KeyInfo></Sig
>>> n
>>> a
>>> ture></NFe>
>>>
>>>  
>>>
>>> <protNFe
>>> versao="1.10"><infProt><tpAmb>1</tpAmb><verAplic>SP_NFE_PL_005e</ver
>>> A
>>> p
>>> lic><chNFe>35101003593968000167550030000101640000000003</chNFe><dhRe
>>> lic>c
>>> lic>b
>>> to>2010-10-20T17:48:15</dhRecbto><nProt>135100546996360</nProt><digV
>>> to>a
>>> to>l
>>>> vj4p6FtqkZen6fsHlcyag8R2hF0=</digVal><cStat>100</cStat><xMotivo>Aut
>>>> o
>>>> r
>>> izado o uso da NF-e</xMotivo></infProt></protNFe>
>>>
>>> </nfeProc>
>>>
>>>  
>>>
>>> --------------------------------------------------------------------
>>> -
>>> -
>>> --------------------------
>>>
>>>  
>>>
>>> Thanks a lot
>>>
>>>  
>>>
>>>  
>>>
>>>  
>>>
>>>  
>>>
>>>
>>>
>>> _______________________________________________
>>> xmlsec mailing list
>>> xmlsec at aleksey.com
>>> http://www.aleksey.com/mailman/listinfo/xmlsec
>>
>> _______________________________________________
>> xmlsec mailing list
>> xmlsec at aleksey.com
>> http://www.aleksey.com/mailman/listinfo/xmlsec


From aleksey at aleksey.com  Thu Jun  7 13:49:57 2012
From: aleksey at aleksey.com (Aleksey Sanin)
Date: Thu, 07 Jun 2012 13:49:57 -0700
Subject: [xmlsec] RES: RES:  RES:   Trying to check sign
In-Reply-To: <01eb01cd44e7$442a9d30$cc7fd790$@acm.org>
References: <00fc01cd435d$f7ce89e0$e76b9da0$@acm.org>
 <4FCEC586.3010703@aleksey.com> <012001cd43d9$77e0fc50$67a2f4f0$@acm.org>
 <4FCFAC50.7060902@aleksey.com> <01db01cd44e3$df87b410$9e971c30$@acm.org>
 <4FD10461.6070305@aleksey.com> <01eb01cd44e7$442a9d30$cc7fd790$@acm.org>
Message-ID: <4FD113F5.3050907@aleksey.com>

You can specify the trusted certificate to xmlsec with --trusted
option. But you must make sure that the "trusted" cert is indeed
in the chain from the certificate you used for signature.

Aleksey

On 6/7/12 12:53 PM, Renato Tegon Forti wrote:
> Thanks for response.
> 
> Only one doubt: this mean that I don't have this  "trusted" certificate
> installed in my machine (that I run xmlsec1 tool), this is a root cert?
> I am reading "Secure XML" from Donald E. , but all it is new to me (than
> very complex)
> 
> Thanks for help!
> 
> -----Mensagem original-----
> De: Aleksey Sanin [mailto:aleksey at aleksey.com] 
> Enviada em: quinta-feira, 7 de junho de 2012 16:43
> Para: Renato Tegon Forti
> Cc: xmlsec at aleksey.com
> Assunto: Re: RES: [xmlsec] RES: Trying to check sign
> 
> You might want to find a good book on cryptography.
> 
> Shortly, the certificate verification is based on the verification of the
> previous certificate in the chain until one finds a "trusted"
> certificate. The errors you are getting indicate that xmlsec/openssl can not
> build the certificate chain and find a "trusted" cert.
> 
> 
> Aleksey
> 
> On 6/7/12 12:29 PM, Renato Tegon Forti wrote:
>> Hi Aleksey,
>>
>> Thanks for your help! Really thanks a lot! If you have time to help-me 
>> again!
>>
>> I am a really confusing, I am trying understand what I need to check 
>> if one signature is valid using your xmlsec1 tool, and then implement 
>> this on C code!
>>
>> My signed document has these properties (mt.xml):
>>
>> Transform Algorithm: Enveloped
>> Algorithm: xmldsig#sha1
>>
>> I'd try a lot of things, but all of it return me: "err=20;msg=unable 
>> to get local issuer certificate"
>>
>> For sampe:
>>
>> I try this: 
>> xmlsec1 --verify --id-attr:Id infNFe --trusted-der mt.der.cer mt.xml 
>> but "mt.der.cer" is cert that is on : 
>> <KeyInfo><X509Data><X509Certificate>
>>
>> So I thought the problem was the root certificate, because I already 
>> have the certificate of the user in <X509Certificate>, then I tried:
>>
>> xmlsec1 --verify --id-attr:Id infNFe --trusted-der 
>> Autoridade_Certificadora_da_Raiz_Brasileira_v2.der.cer mt.xml Some 
>> error "err=20;msg=unable to get local issuer certificate "
>>
>> Then I tried a variation, only to check result: (--untrusted-der)
>>
>> xmlsec1 --verify --id-attr:Id infNFe --untrusted-der 
>> Autoridade_Certificadora_da_Raiz_Brasileira_v2.der.cer mt.xml the 
>> error change to: err=18;msg=self signed certificate
>>
>> I tried too:
>>
>> xmlsec1 --verify --id-attr:Id infNFe --trusted-der 
>> SERASA_Autoridade_Certificadora_Principal_v2.der.cer mt.xml
>> xmlsec1 --verify --id-attr:Id infNFe --trusted-der 
>> SERASA_Autoridade_Certificadora_Digital_v2.der.cer mt.xml
>>
>> Some error "err=20;msg=unable to get local issuer certificate "
>>
>> Reading a book I understood that to verifying an XML Signature:
>>
>> 1.
>> Verify the signature of the <SignedInfo> element. -> To do so, 
>> recalculate the digest of the <SignedInfo> element (using the digest 
>> algorithm specified in the <SignatureMethod> element) and use the 
>> public verification key to verify that the value of the 
>> <SignatureValue> element is correct for the digest of the <SignedInfo>
> element.
>>
>> The public key (public verification key)  in my case is: 
>> <X509Certificate> OK?
>>
>> 2.
>> If this step passes, recalculate the digests of the references 
>> contained within the <SignedInfo> element and compare them to the 
>> digest values expressed in each <Reference> element's corresponding
> <DigestValue> element.
>>
>>
>> Please see attached files! (meta.zip)
>>  -> mt.xml [file that I want check signature]
>> -> chain.png [cert chains]
>> -> Autoridade_Certificadora_da_Raiz_Brasileira_v2.der.cer [root cert 
>> -> in der
>> format]
>> -> SERASA_Autoridade_Certificadora_Principal_v2.der.cer ->
>> SERASA_Autoridade_Certificadora_Digital_v2.der.cer -> mt.der.cer [all 
>> other certs in chain ]
>>
>> What am I doing wrong? What I misunderstood?
>> Thanks a lot!
>>
>>
>>
>> -----Mensagem original-----
>> De: Aleksey Sanin [mailto:aleksey at aleksey.com] Enviada em: 
>> quarta-feira, 6 de junho de 2012 16:15
>> Para: Renato Tegon Forti
>> Cc: xmlsec at aleksey.com
>> Assunto: Re: [xmlsec] RES: Trying to check sign
>>
>> It's not on the website but it is in the examples folder.
>>
>> Aleksey
>>
>> On 6/6/12 4:42 AM, Renato Tegon Forti wrote:
>>>>> This means that xmlsec (or to be precise, openssl) needs to verify 
>>>>> the
>>> certificate and it can't find the next certificate in the chain.
>>>
>>> Thanks for answer. 
>>>
>>> One more question: what is the example
>>> (http://www.aleksey.com/xmlsec/api/xmlsec-examples.html) that 
>>> implement "Online XML Digital Signature Verifer"?
>>> I want study code implementation of it!
>>>
>>> Thanks
>>>
>>> -----Mensagem original-----
>>> De: Aleksey Sanin [mailto:aleksey at aleksey.com] Enviada em: 
>>> ter?a-feira, 5 de junho de 2012 23:51
>>> Para: Renato Tegon Forti
>>> Cc: xmlsec at aleksey.com
>>> Assunto: Re: [xmlsec] Trying to check sign
>>>
>>> This means that xmlsec (or to be precise, openssl) needs to verify 
>>> the certificate and it can't find the next certificate in the chain.
>>>
>>> Aleksey
>>>
>>> On 6/5/12 1:58 PM, Renato Tegon Forti wrote:
>>>> Hi,
>>>>
>>>>  
>>>>
>>>> I have one file that I want check sig (using KEYINFO node), I know 
>>>> that the signature is valid, but tool returns me:
>>>>
>>>>  
>>>>
>>>> I use DTD, see xml below, please!
>>>>
>>>>  
>>>>
>>>> --------------------------------------------------------------------
>>>> -
>>>> -
>>>> --------------------------
>>>>
>>>>  
>>>>
>>>> func=xmlSecOpenSSLX509StoreVerify:file=x509vfy.c:line=360:obj=x509-s
>>>> t o re:subj=X509_verify_cert:error=4:crypto
>>>> library function failed:subj=/C=BR/O=ICP-Brasil/OU=ID - 
>>>> 1083312/OU=Autenticado por Certisign Certificadora 
>>>> Digital/OU=Assinatura Tipo A1/OU=(EM BRANCO)/OU=(EM 
>>>> BRANCO)/CN=MEDIATECH INFORMATICA 
>>>> LTDA/emailAddress=contato at tecnomidia.com.br;err=20;msg=unable
>>>> <mailto:LTDA/emailAddress=contato at tecnomidia.com.br;err=20;msg=unabl
>>>> e
>>>>>
>>>> to get local issuer certificate
>>>>
>>>> func=xmlSecOpenSSLX509StoreVerify:file=x509vfy.c:line=408:obj=x509-s
>>>> t
>>>> o
>>>> re:subj=unknown:error=71:certificate
>>>> verification failed:err=20;msg=unable to get local issuer 
>>>> certificate
>>>>
>>>> func=xmlSecOpenSSLEvpSignatureVerify:file=signatures.c:line=346:obj=
>>>> r s a-sha1:subj=EVP_VerifyFinal:error=18:data
>>>> do not match:signature do not match
>>>>
>>>> RESULT: Signature is INVALID
>>>>
>>>> ---------------------------------------------------
>>>>
>>>> = VERIFICATION CONTEXT
>>>>
>>>> == Status: invalid
>>>>
>>>> == flags: 0x00000000
>>>>
>>>> == flags2: 0x00000000
>>>>
>>>> == Key Info Read Ctx:
>>>>
>>>> = KEY INFO READ CONTEXT
>>>>
>>>> == flags: 0x00000000
>>>>
>>>> == flags2: 0x00000000
>>>>
>>>> == enabled key data: all
>>>>
>>>> == RetrievalMethod level (cur/max): 0/1
>>>>
>>>> == TRANSFORMS CTX (status=0)
>>>>
>>>> == flags: 0x00000000
>>>>
>>>> == flags2: 0x00000000
>>>>
>>>> == enabled transforms: all
>>>>
>>>> === uri: NULL
>>>>
>>>> === uri xpointer expr: NULL
>>>>
>>>> == EncryptedKey level (cur/max): 0/1
>>>>
>>>> === KeyReq:
>>>>
>>>> ==== keyId: rsa
>>>>
>>>> ==== keyType: 0x00000001
>>>>
>>>> ==== keyUsage: 0x00000002
>>>>
>>>> ==== keyBitsSize: 0
>>>>
>>>> === list size: 0
>>>>
>>>> == Key Info Write Ctx:
>>>>
>>>> = KEY INFO WRITE CONTEXT
>>>>
>>>> == flags: 0x00000000
>>>>
>>>> == flags2: 0x00000000
>>>>
>>>> == enabled key data: all
>>>>
>>>> == RetrievalMethod level (cur/max): 0/1
>>>>
>>>> == TRANSFORMS CTX (status=0)
>>>>
>>>> == flags: 0x00000000
>>>>
>>>> == flags2: 0x00000000
>>>>
>>>> == enabled transforms: all
>>>>
>>>> === uri: NULL
>>>>
>>>> === uri xpointer expr: NULL
>>>>
>>>> == EncryptedKey level (cur/max): 0/1
>>>>
>>>> === KeyReq:
>>>>
>>>> ==== keyId: NULL
>>>>
>>>> ==== keyType: 0x00000001
>>>>
>>>> ==== keyUsage: 0xffffffff
>>>>
>>>> ==== keyBitsSize: 0
>>>>
>>>> === list size: 0
>>>>
>>>> == Signature Transform Ctx:
>>>>
>>>> == TRANSFORMS CTX (status=2)
>>>>
>>>> == flags: 0x00000000
>>>>
>>>> == flags2: 0x00000000
>>>>
>>>> == enabled transforms: all
>>>>
>>>> === uri: NULL
>>>>
>>>> === uri xpointer expr: NULL
>>>>
>>>> === Transform: c14n
>>>> (href=http://www.w3.org/TR/2001/REC-xml-c14n-20010315)
>>>>
>>>> === Transform: rsa-sha1
>>>> (href=http://www.w3.org/2000/09/xmldsig#rsa-sha1)
>>>>
>>>> === Transform: membuf-transform (href=NULL)
>>>>
>>>> == Signature Method:
>>>>
>>>> === Transform: rsa-sha1
>>>> (href=http://www.w3.org/2000/09/xmldsig#rsa-sha1)
>>>>
>>>> == Signature Key:
>>>>
>>>> == KEY
>>>>
>>>> === method: RSAKeyValue
>>>>
>>>> === key type: Private
>>>>
>>>> === key name: test-rsa
>>>>
>>>> === key usage: -1
>>>>
>>>> === rsa key: size = 1024
>>>>
>>>> == SignedInfo References List:
>>>>
>>>> === list size: 1
>>>>
>>>> = REFERENCE VERIFICATION CONTEXT
>>>>
>>>> == Status: succeeded
>>>>
>>>> == URI: "#NFe35101003593968000167550030000101640000000003"
>>>>
>>>> == Reference Transform Ctx:
>>>>
>>>> == TRANSFORMS CTX (status=2)
>>>>
>>>> == flags: 0x00000000
>>>>
>>>> == flags2: 0x00000000
>>>>
>>>> == enabled transforms: all
>>>>
>>>> === uri:
>>>>
>>>> === uri xpointer expr: 
>>>> #NFe35101003593968000167550030000101640000000003
>>>>
>>>> === Transform: xpointer
>>>> (href=http://www.w3.org/2001/04/xmldsig-more/xptr)
>>>>
>>>> === Transform: enveloped-signature
>>>> (href=http://www.w3.org/2000/09/xmldsig#enveloped-signature)
>>>>
>>>> === Transform: c14n
>>>> (href=http://www.w3.org/TR/2001/REC-xml-c14n-20010315)
>>>>
>>>> === Transform: sha1 (href=http://www.w3.org/2000/09/xmldsig#sha1)
>>>>
>>>> === Transform: membuf-transform (href=NULL)
>>>>
>>>> == Digest Method:
>>>>
>>>> === Transform: sha1 (href=http://www.w3.org/2000/09/xmldsig#sha1)
>>>>
>>>> == Manifest References List:
>>>>
>>>> === list size: 0
>>>>
>>>>  
>>>>
>>>> --------------------------------------------------------------------
>>>> -
>>>> -
>>>> --------------------------
>>>>
>>>>  
>>>>
>>>> Anyone can help-me to understand what I make wrong!
>>>>
>>>> What this exactly can mean: ?unable to get local issuer certificate?
>>>>
>>>>  
>>>>
>>>> This is my xml file ( the DTD is correct?):
>>>>
>>>>  
>>>>
>>>> --------------------------------------------------------------------
>>>> -
>>>> -
>>>> --------------------------
>>>>
>>>>  
>>>>
>>>> <?xml version="1.0" encoding="UTF-8"?>
>>>>
>>>> <!DOCTYPE test [
>>>>
>>>> <!ATTLIST infNFe Id ID #IMPLIED>
>>>>
>>>> ]>
>>>>
>>>> <nfeProc xmlns="http://www.portalfiscal.inf.br/nfe" versao="1.10">
>>>>
>>>> <NFe xmlns="http://www.portalfiscal.inf.br/nfe"><infNFe
>>>> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
>>>> Id="NFe35101003593968000167550030000101640000000003"
>>>> versao="1.10"><ide><cUF>35</cUF><cNF>000000000</cNF><natOp>VENDA 
>>>> MERC C/ PGTO ST C/ 
>>>> SUBSTITUIDO</natOp><indPag>1</indPag><mod>55</mod><serie>3</serie><n
>>>> N
>>>> F
>>>>> 10164</nNF><dEmi>2010-10-20</dEmi><dSaiEnt>2010-10-20</dSaiEnt><tpN
>>>>> F
>>>>>>
>>>> 1</tpNF><cMunFG>3550308</cMunFG><tpImp>1</tpImp><tpEmis>1</tpEmis><c
>>>> D
>>>> V
>>>>> 3</cDV><tpAmb>1</tpAmb><finNFe>1</finNFe><procEmi>0</procEmi><verPr
>>>>> o
>>>>> c
>>>>> 1.4.0</verProc></ide><emit><CNPJ>03593968000167</CNPJ><xNome>Mediat
>>>>> e
>>>>> c
>>>> h Informatica LTDA</xNome><xFant>Mediatech Informatica 
>>>> LTDA</xFant><enderEmit><xLgr>CORREIA DE 
>>>> MELO</xLgr><nro>085</nro><xBairro>BOM
>>>> RETIRO</xBairro><cMun>3550308</cMun><xMun>SAO
>>>> PAULO</xMun><UF>SP</UF><CEP>01123020</CEP><cPais>1058</cPais><xPais>
>>>> B
>>>> R
>>>> ASIL</xPais><fone>1133521199</fone></enderEmit><IE>115633812110</IE>
>>>> <
>>>> /
>>>> emit><dest><CNPJ>11253910000100</CNPJ><xNome>AYSSO
>>>> SYSTEMS LTDA EPP</xNome><enderDest><xLgr>RUA DOZE DE 
>>>> NOVEMBRO</xLgr><nro>180</nro><xCpl>APT
>>>> 183</xCpl><xBairro>CENTRO</xBairro><cMun>3501608</cMun><xMun>AMERICA
>>>> N
>>>> A
>>>> </xMun><UF>SP</UF><CEP>13465490</CEP><cPais>1058</cPais><xPais>BRASI
>>>> L < /xPais><fone>1936459994</fone></enderDest><IE/></dest><det
>>>> nItem="1"><prod><cProd>1160900000000001720000</cProd><cEAN/><xProd>M
>>>> I
>>>> D
>>>> IA
>>>> DIGITAL
>>>> CD/DVD</xProd><NCM>85234011</NCM><CFOP>5405</CFOP><uCom>PC.</uCom><q
>>>> C
>>>> o
>>>> m>100.0000</qCom><vUnCom>2.1500</vUnCom><vProd>215.00</vProd><cEANTr
>>>> m>i
>>>> m>b
>>>> /><uTrib>PC.</uTrib><qTrib>100.0000</qTrib><vUnTrib>2.1500</vUnTrib>
>>>> <
>>>> v
>>>> Frete>20.00</vFrete></prod><imposto><ICMS><ICMS60><orig>0</orig><CST
>>>> Frete>>
>>>> Frete>6
>>>> 0</CST><vBCST>215.00</vBCST><vICMSST>0.00</vICMSST></ICMS60></ICMS><
>>>> I
>>>> P
>>>> I><cEnq>999</cEnq><IPINT><CST>53</CST></IPINT></IPI><PIS><PISAliq><C
>>>> I>S
>>>> I>T
>>>>> 01</CST><vBC>215.00</vBC><pPIS>0.65</pPIS><vPIS>1.40</vPIS></PISAli
>>>>> q
>>>>>>
>>>> </PIS><COFINS><COFINSAliq><CST>01</CST><vBC>215.00</vBC><pCOFINS>3.0
>>>> 0
>>>> <
>>>> /pCOFINS><vCOFINS>6.45</vCOFINS></COFINSAliq></COFINS></imposto></de
>>>> t
>>>>>
>>>> <total><ICMSTot><vBC>20.00</vBC><vICMS>0.00</vICMS><vBCST>0.00</vBCS
>>>> T
>>>>>
>>>> <vST>0.00</vST><vProd>215.00</vProd><vFrete>20.00</vFrete><vSeg>0.00
>>>> <
>>>> /
>>>> vSeg><vDesc>0.00</vDesc><vII>0.00</vII><vIPI>0.00</vIPI><vPIS>1.40</
>>>> vSeg>v
>>>> vSeg>P
>>>> IS><vCOFINS>6.45</vCOFINS><vOutro>0.00</vOutro><vNF>235.00</vNF></IC
>>>> IS>M
>>>> IS>S
>>>> Tot></total><transp><modFrete>0</modFrete><transporta><CNPJ>07281886
>>>> Tot>0
>>>> Tot>0
>>>> 0138</CNPJ><xNom
>>>  e
>>>> Correio
>>>> - Sedex</xNome><IE>ISENTO</IE><xEnder>Rua Correia de Melo, 
>>>> 111</xEnder><xMun>Sao
>>>>
>>> Paulo</xMun><UF>SP</UF></transporta><vol><qVol>1</qVol><esp>CX.</esp>
>>> <
>>> pesoL> 
>>> 1.000</pesoL><pesoB>1.000</pesoB></vol></transp><cobr><fat><nFat>1016
>>> 4
>>> </nFat
>>>> <vOrig>235.00</vOrig><vLiq>235.00</vLiq></fat><dup><nDup>001</nDup><
>>>> d
>>>> Venc>2
>>>
> 010-10-20</dVenc><vDup>235.00</vDup></dup></cobr><infAdic><infCpl>Pedidos:
>>>> 48033</infCpl></infAdic></infNFe><Signature
>>>>
>>>> xmlns="http://www.w3.org/2000/09/xmldsig#"><SignedInfo><Canonicaliza
>>>> t
>>>> io
>>>> nMethod
>>>> Algorithm="http://www.w3.org/TR/2001/REC-xml-c14n-20010315"/><Signat
>>>> u
>>>> re
>>>> Method
>>>> Algorithm="http://www.w3.org/2000/09/xmldsig#rsa-sha1"/><Reference
>>>>
>>>> URI="#NFe35101003593968000167550030000101640000000003"><Transforms><
>>>> T
>>>> ra
>>>> nsform
>>>> Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature"/><
>>>> T
>>>> ra
>>>> nsform
>>>> Algorithm="http://www.w3.org/TR/2001/REC-xml-c14n-20010315"/></Trans
>>>> f
>>>> or
>>>> ms><DigestMethod
>>>> Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/><DigestValue>vj4
>>>> p
>>>> 6F
>>>> tqkZen6fsHlcyag8R2hF0=</DigestValue></Reference></SignedInfo><Signat
>>>> u
>>>> re
>>>> Value>Jymbikn/5F8aUYQA6CaZmLYY9plO4KNfyu/M4TZP5l+3fy/pjwpkIsaeV1LXXy
>>>> Value>o
>>>> Value>7n
>>>> WLdpvruhCXy
>>>>
>>>> ID2ptAjzIWOJ/vp1YW94e0Yy7yfBijQNkew+FI1G7GKKt7T/UUIPRrXqWwo7EA8ZpCYS
>>>> o
>>>> W
>>>> ktWqHZ
>>>>
>>>> iU7j7iJone1nLdNJNjY=</SignatureValue><KeyInfo><X509Data><X509Certifi
>>>> c
>>>> a
>>>> te>MIIGuzCCBaOgAwIBAgIQCbCeZ64fHJPeNqAkc06I8TANBgkqhkiG9w0BAQUFADB0M
>>>> te>Q
>>>> te>s
>>>> wCQYDVQQG
>>>>
>>>> EwJCUjETMBEGA1UEChMKSUNQLUJyYXNpbDEtMCsGA1UECxMkQ2VydGlzaWduIENlcnRp
>>>> Z
>>>> m
>>>> ljYWRv
>>>>
>>>> cmEgRGlnaXRhbCBTLkEuMSEwHwYDVQQDExhBQyBDZXJ0aXNpZ24gTXVsdGlwbGEgRzMw
>>>> H
>>>> h
>>>> cNMTAw
>>>>
>>>> NzI5MDAwMDAwWhcNMTEwNzI4MjM1OTU5WjCCAQsxCzAJBgNVBAYTAkJSMRMwEQYDVQQK
>>>> F
>>>> A
>>>> pJQ1At
>>>>
>>>> QnJhc2lsMRUwEwYDVQQLFAxJRCAtIDEwODMzMTIxODA2BgNVBAsUL0F1dGVudGljYWRv
>>>> I
>>>> H
>>>> BvciBD
>>>>
>>>> ZXJ0aXNpZ24gQ2VydGlmaWNhZG9yYSBEaWdpdGFsMRswGQYDVQQLFBJBc3NpbmF0dXJh
>>>> I
>>>> F
>>>> RpcG8g
>>>>
>>>> QTExFDASBgNVBAsUCyhFTSBCUkFOQ08pMRQwEgYDVQQLFAsoRU0gQlJBTkNPKTEjMCEG
>>>> A
>>>> 1
>>>> UEAxMa
>>>>
>>>> TUVESUFURUNIIElORk9STUFUSUNBIExUREExKDAmBgkqhkiG9w0BCQEWGWNvbnRhdG9A
>>>> d
>>>> G
>>>> Vjbm9t
>>>>
>>>> aWRpYS5jb20uYnIwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAM8txkPNL6gjEjSW
>>>> 4
>>>> T
>>>> umyO0w
>>>>
>>>> zBGmxNtCqU9DFNWQD1TWIbXaYduxoxnYEwNXrehla2YDslXUiM45SWvlmjlWoVV9T7F0
>>>> 7
>>>> a
>>>> OGGysP
>>>>
>>>> aNLJW/y3CMq7Qrvsh+h30INqV8WWYXKHlmfLz4eNf8Di4xQvgm+7yxvkGHXXjxkWn6ut
>>>> B
>>>> W
>>>> tJAgMB
>>>>
>>>> AAGjggMyMIIDLjCBrQYDVR0RBIGlMIGioDgGBWBMAQMEoC8ELTE5MDExOTY3MTEyMDk3
>>>> M
>>>> z
>>>> g4MDUw
>>>>
>>>> MDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMKAXBgVgTAEDAqAOBAxKQUlSIFNaQVBJUk+g
>>>> MDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMKAXBgVgTAEDAqAOBAxKQUlSIFNaQVBJUk+G
>>>> MDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMKAXBgVgTAEDAqAOBAxKQUlSIFNaQVBJUk+Q
>>>> MDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMKAXBgVgTAEDAqAOBAxKQUlSIFNaQVBJUk+Y
>>>> MDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMKAXBgVgTAEDAqAOBAxKQUlSIFNaQVBJUk+F
>>>> MDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMKAXBgVgTAEDAqAOBAxKQUlSIFNaQVBJUk+Y
>>>> MDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMKAXBgVgTAEDAqAOBAxKQUlSIFNaQVBJUk+E
>>>> MDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMKAXBgVgTAEDAqAOBAxKQUlSIFNaQVBJUk+w
>>>> MDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMKAXBgVgTAEDAqAOBAxKQUlSIFNaQVBJUk+B
>>>>
>>>> AwOgEAQOMDM1OTM5NjgwMDAxNjegFwYFYEwBAwegDgQMMDAwMDAwMDAwMDAwgRljb250
>>>> Y
>>>> X
>>>> RvQHRl
>>>>
>>>>
>>>
>>
> Y25vbWlkaWEuY29tLmJyMAkGA1UdEwQCMAAwHwYDVR0jBBgwFoAUhLBCMzSjQiWlKJc+g+t38OhP
>>>>
>>>> wlQwDgYDVR0PAQH/BAQDAgXgMFUGA1UdIAROMEwwSgYGYEwBAgELMEAwPgYIKwYBBQUH
>>>> A
>>>> g
>>>> EWMmh0
>>>>
>>>> dHA6Ly9pY3AtYnJhc2lsLmNlcnRpc2lnbi5jb20uYnIvcmVwb3NpdG9yaW8vZHBjMIIB
>>>> J
>>>> Q
>>>> YDVR0f
>>>>
>>>> BIIBHDCCARgwXKBaoFiGVmh0dHA6Ly9pY3AtYnJhc2lsLmNlcnRpc2lnbi5jb20uYnIv
>>>> c
>>>> m
>>>> Vwb3Np
>>>>
>>>> dG9yaW8vbGNyL0FDQ2VydGlzaWduTXVsdGlwbGFHMy9MYXRlc3RDUkwuY3JsMFugWaBX
>>>> h
>>>> l
>>>> VodHRw
>>>>
>>>> Oi8vaWNwLWJyYXNpbC5vdXRyYWxjci5jb20uYnIvcmVwb3NpdG9yaW8vbGNyL0FDQ2Vy
>>>> d
>>>> G
>>>> lzaWdu
>>>>
>>>> TXVsdGlwbGFHMy9MYXRlc3RDUkwuY3JsMFugWaBXhlVodHRwOi8vcmVwb3NpdG9yaW8u
>>>> a
>>>> W
>>>> NwYnJh
>>>>
>>>> c2lsLmdvdi5ici9sY3IvQ2VydGlzaWduL0FDQ2VydGlzaWduTXVsdGlwbGFHMy9MYXRl
>>>> c
>>>> 3
>>>> RDUkwu
>>>>
>>>> Y3JsMB0GA1UdJQQWMBQGCCsGAQUFBwMEBggrBgEFBQcDAjCBoAYIKwYBBQUHAQEEgZMw
>>>> g
>>>> Z
>>>> AwKAYI
>>>>
>>>> KwYBBQUHMAGGHGh0dHA6Ly9vY3NwLmNlcnRpc2lnbi5jb20uYnIwZAYIKwYBBQUHMAKG
>>>> W
>>>> G
>>>> h0dHA6
>>>>
>>>> Ly9pY3AtYnJhc2lsLmNlcnRpc2lnbi5jb20uYnIvcmVwb3NpdG9yaW8vY2VydGlmaWNh
>>>> Z
>>>> G
>>>> 9zL0FD
>>>>
>>>> X0NlcnRpc2lnbl9NdWx0aXBsYV9HMy5wN2MwDQYJKoZIhvcNAQEFBQADggEBAGI9MCc6
>>>> W
>>>> V
>>>> mz919C
>>>>
>>>> QLDB8E0R8HxfGyiz2uB14lPBDsueTJmJmlykQdnboMiyMGTocprEGsQxeI7a57BEUDVc
>>>> 0
>>>> f
>>>> SzNCCb
>>>>
>>>> SOnQOp9Uswri8pTw8fQG9OAkh1LCC9haTsNNMKbTHCciO7MUh34XkHuj4A0NIWG1aCyn
>>>> w
>>>> s
>>>> tRFWb8
>>>>
>>>> 97OZJJCc0IRvDs7yDJhgOwPmv3trFmwlfMU7n20pXtM9hKiI8o6h/0GwR6SyA1Yj4fZX
>>>> f
>>>> X
>>>> xVENH4
>>>>
>>>> EjhIHR8Yrmre2JE2I+hFjyQaNPnAEztQEa0Cae2l3O0Q0tkM1x8EkiKFrnDggpc7gSwt
>>>> EjhIHR8Yrmre2JE2I+L
>>>> EjhIHR8Yrmre2JE2I+C
>>>> EjhIHR8Yrmre2JE2I+wrkQBu
>>>>
>>>> jhie131VyDTuXLx9k082PLs=</X509Certificate></X509Data></KeyInfo></Sig
>>>> n
>>>> a
>>>> ture></NFe>
>>>>
>>>>  
>>>>
>>>> <protNFe
>>>> versao="1.10"><infProt><tpAmb>1</tpAmb><verAplic>SP_NFE_PL_005e</ver
>>>> A
>>>> p
>>>> lic><chNFe>35101003593968000167550030000101640000000003</chNFe><dhRe
>>>> lic>c
>>>> lic>b
>>>> to>2010-10-20T17:48:15</dhRecbto><nProt>135100546996360</nProt><digV
>>>> to>a
>>>> to>l
>>>>> vj4p6FtqkZen6fsHlcyag8R2hF0=</digVal><cStat>100</cStat><xMotivo>Aut
>>>>> o
>>>>> r
>>>> izado o uso da NF-e</xMotivo></infProt></protNFe>
>>>>
>>>> </nfeProc>
>>>>
>>>>  
>>>>
>>>> --------------------------------------------------------------------
>>>> -
>>>> -
>>>> --------------------------
>>>>
>>>>  
>>>>
>>>> Thanks a lot
>>>>
>>>>  
>>>>
>>>>  
>>>>
>>>>  
>>>>
>>>>  
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> xmlsec mailing list
>>>> xmlsec at aleksey.com
>>>> http://www.aleksey.com/mailman/listinfo/xmlsec
>>>
>>> _______________________________________________
>>> xmlsec mailing list
>>> xmlsec at aleksey.com
>>> http://www.aleksey.com/mailman/listinfo/xmlsec
> 

From roland.hedberg at adm.umu.se  Sat Jun  9 07:54:13 2012
From: roland.hedberg at adm.umu.se (Roland Hedberg)
Date: Sat, 9 Jun 2012 16:54:13 +0200
Subject: [xmlsec] Missing encryptedkey ?
Message-ID: <A728C5FB-BCB2-4297-8635-0AD7F623ACD2@adm.umu.se>

Hi!

I'm trying to encrypt part of a XML message.

So I'm using the command:

xmlsec1 encrypt --pubkey-cert-pem mycert.pem \
    --session-key des-192 --xml-data pre_saml2_response.xml \
    --node-xpath '/*[local-name()="Response"]/*[local-name()="Assertion"]/*[local-name()="Subject"]/*[local-name()="EncryptedID"]/text()' \
    encryption_template.xml

The encryption template looks like this:

<?xml version="1.0" encoding="UTF-8"?>
<EncryptedData xmlns="http://www.w3.org/2001/04/xmlenc#" Type="http://www.w3.org/2001/04/xmlenc#Element">
    <EncryptionMethod Algorithm="http://www.w3.org/2001/04/xmlenc#tripledes-cbc"/>
    <KeyInfo xmlns="http://www.w3.org/2000/09/xmldsig#">
        <EncryptedKey xmlns="http://www.w3.org/2001/04/xmlenc#">
            <EncryptionMethod Algorithm="http://www.w3.org/2001/04/xmlenc#rsa-oaep-mgf1p"/>
            <CipherData>
                <CipherValue></CipherValue>
            </CipherData>
        </EncryptedKey>
    </KeyInfo>
    <CipherData>
        <CipherValue></CipherValue>
    </CipherData>
</EncryptedData>

The encryption works OK (no error message) and this is what is added to the original XML file:

<EncryptedData xmlns="http://www.w3.org/2001/04/xmlenc#"
               Type="http://www.w3.org/2001/04/xmlenc#Element">
  <EncryptionMethod Algorithm="http://www.w3.org/2001/04/xmlenc#tripledes-cbc"/>
  <CipherData>
    <CipherValue>ZBx6+ENTu+nktBVSGunBlnBPGc4MXxNJg9vLd1Z/MBJKx2QU/W9kD7OJRQ+Op6ct+865Cgf/9AM=</CipherValue>
  </CipherData>
</EncryptedData>

I expected some information about the encrypted session key but nothing.
What did I do wrong ?

Now, trying to decrypt the encrypted file I get "error=45:key is not found"
which I interpret to mean that the session key is missing. Right/wrong ?

-- Roland
------------------------------------------------------
Roland Hedberg
IT Architect/Senior Researcher
ICT Services and System Development (ITS) 
Ume? University 
SE-901 87 Ume?, Sweden	
Phone +46 90 786 68 44
Mobile +46 70 696 68 44 
www.its.umu.se 


From aleksey at aleksey.com  Sat Jun  9 09:14:20 2012
From: aleksey at aleksey.com (Aleksey Sanin)
Date: Sat, 09 Jun 2012 09:14:20 -0700
Subject: [xmlsec] Missing encryptedkey ?
In-Reply-To: <A728C5FB-BCB2-4297-8635-0AD7F623ACD2@adm.umu.se>
References: <A728C5FB-BCB2-4297-8635-0AD7F623ACD2@adm.umu.se>
Message-ID: <4FD3765C.5010901@aleksey.com>

Take a look at the tests in the tests/01-phaos-xmlenc-3/ folder.
In particular, enc-element-3des-kw-3des.tmpl

Aleksey

On 6/9/12 7:54 AM, Roland Hedberg wrote:
> Hi!
> 
> I'm trying to encrypt part of a XML message.
> 
> So I'm using the command:
> 
> xmlsec1 encrypt --pubkey-cert-pem mycert.pem \
>     --session-key des-192 --xml-data pre_saml2_response.xml \
>     --node-xpath '/*[local-name()="Response"]/*[local-name()="Assertion"]/*[local-name()="Subject"]/*[local-name()="EncryptedID"]/text()' \
>     encryption_template.xml
> 
> The encryption template looks like this:
> 
> <?xml version="1.0" encoding="UTF-8"?>
> <EncryptedData xmlns="http://www.w3.org/2001/04/xmlenc#" Type="http://www.w3.org/2001/04/xmlenc#Element">
>     <EncryptionMethod Algorithm="http://www.w3.org/2001/04/xmlenc#tripledes-cbc"/>
>     <KeyInfo xmlns="http://www.w3.org/2000/09/xmldsig#">
>         <EncryptedKey xmlns="http://www.w3.org/2001/04/xmlenc#">
>             <EncryptionMethod Algorithm="http://www.w3.org/2001/04/xmlenc#rsa-oaep-mgf1p"/>
>             <CipherData>
>                 <CipherValue></CipherValue>
>             </CipherData>
>         </EncryptedKey>
>     </KeyInfo>
>     <CipherData>
>         <CipherValue></CipherValue>
>     </CipherData>
> </EncryptedData>
> 
> The encryption works OK (no error message) and this is what is added to the original XML file:
> 
> <EncryptedData xmlns="http://www.w3.org/2001/04/xmlenc#"
>                Type="http://www.w3.org/2001/04/xmlenc#Element">
>   <EncryptionMethod Algorithm="http://www.w3.org/2001/04/xmlenc#tripledes-cbc"/>
>   <CipherData>
>     <CipherValue>ZBx6+ENTu+nktBVSGunBlnBPGc4MXxNJg9vLd1Z/MBJKx2QU/W9kD7OJRQ+Op6ct+865Cgf/9AM=</CipherValue>
>   </CipherData>
> </EncryptedData>
> 
> I expected some information about the encrypted session key but nothing.
> What did I do wrong ?
> 
> Now, trying to decrypt the encrypted file I get "error=45:key is not found"
> which I interpret to mean that the session key is missing. Right/wrong ?
> 
> -- Roland
> ------------------------------------------------------
> Roland Hedberg
> IT Architect/Senior Researcher
> ICT Services and System Development (ITS) 
> Ume? University 
> SE-901 87 Ume?, Sweden	
> Phone +46 90 786 68 44
> Mobile +46 70 696 68 44 
> www.its.umu.se 
> 
> _______________________________________________
> xmlsec mailing list
> xmlsec at aleksey.com
> http://www.aleksey.com/mailman/listinfo/xmlsec

From roland.hedberg at adm.umu.se  Sat Jun  9 10:15:23 2012
From: roland.hedberg at adm.umu.se (Roland Hedberg)
Date: Sat, 9 Jun 2012 19:15:23 +0200
Subject: [xmlsec] Missing encryptedkey ?
In-Reply-To: <4FD3765C.5010901@aleksey.com>
References: <A728C5FB-BCB2-4297-8635-0AD7F623ACD2@adm.umu.se>
 <4FD3765C.5010901@aleksey.com>
Message-ID: <304B3228-6C9E-442A-840E-5C1A0CDB0DD8@adm.umu.se>


9 jun 2012 kl. 18:14 skrev Aleksey Sanin:

> Take a look at the tests in the tests/01-phaos-xmlenc-3/ folder.
> In particular, enc-element-3des-kw-3des.tmpl


Used the keys.xml from the above mentioned folder, used the template and modified the command to be:

xmlsec1 encrypt --pubkey-cert-pem ../example/sp/pki/mycert.pem \
    --session-key des-192 --xml-data pre_saml2_response.xml \
    --keys-file keys.xml \
    --node-xpath '/*[local-name()="Response"]/*[local-name()="Assertion"]/*[local-name()="Subject"]/*[local-name()="EncryptedID"]/text()' \
    enc-element-3des-kw-3des.tmpl

Same result though, the added part is:

<EncryptedData xmlns="http://www.w3.org/2001/04/xmlenc#"
               Type="http://www.w3.org/2001/04/xmlenc#Element">
  <EncryptionMethod Algorithm="http://www.w3.org/2001/04/xmlenc#tripledes-cbc"/>
  <CipherData>
    <CipherValue>ZBx6+ENTu+nktBVSGunBlnBPGc4MXxNJg9vLd1Z/MBJKx2QU/W9kD7OJRQ+Op6ct+865Cgf/9AM=</CipherValue>
  </CipherData>
</EncryptedData>

No EncryptedKey element ?
did I misunderstand you ?

-- Roland
------------------------------------------------------
Roland Hedberg
IT Architect/Senior Researcher
ICT Services and System Development (ITS) 
Ume? University 
SE-901 87 Ume?, Sweden	
Phone +46 90 786 68 44
Mobile +46 70 696 68 44 
www.its.umu.se 


From akitsukineko at gmail.com  Sat Jun  9 11:05:14 2012
From: akitsukineko at gmail.com (Neko)
Date: Sun, 10 Jun 2012 02:05:14 +0800
Subject: [xmlsec] Question about default transform and multi-signature
	suggestion
Message-ID: <CAPpBuXgrvH2hn+JYg4dibXxU1mc6u1_edd5em7U19F16qa_BqQ@mail.gmail.com>

Dear Aleksey

About transform, I want to check if my understanding is wrong.
Under self-referencing signature, the result node set of Xpath should be
canonicalized.
The CanonicalizationMethod only decides how the SignedInfo canonicalized.
If no c14n Transform specified, then xmlsec applies the default c14n, which
is http://www.w3.org/TR/2001/REC-xml-c14n-20010315
The enveloped signature transform will remove the signature node in the
content to sign, while nothing needs to be done in enveloping or detached
signature.

And about multi-signature suggestion, is there any suggested rule to
generate signatures?
It seems that enveloped signature is not suitable for this kind of use.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.aleksey.com/pipermail/xmlsec/attachments/20120610/8e16b6e7/attachment.html>

From aleksey at aleksey.com  Sat Jun  9 17:08:46 2012
From: aleksey at aleksey.com (Aleksey Sanin)
Date: Sat, 09 Jun 2012 17:08:46 -0700
Subject: [xmlsec] Missing encryptedkey ?
In-Reply-To: <304B3228-6C9E-442A-840E-5C1A0CDB0DD8@adm.umu.se>
References: <A728C5FB-BCB2-4297-8635-0AD7F623ACD2@adm.umu.se>
 <4FD3765C.5010901@aleksey.com>
 <304B3228-6C9E-442A-840E-5C1A0CDB0DD8@adm.umu.se>
Message-ID: <4FD3E58E.4020603@aleksey.com>

You need to use KW transform. Take a look at

tests/merlin-xmlenc-five/encrypt-element-tripledes-cbc-kw-aes128.tmpl


Aleksey

On 6/9/12 10:15 AM, Roland Hedberg wrote:
> 
> 9 jun 2012 kl. 18:14 skrev Aleksey Sanin:
> 
>> Take a look at the tests in the tests/01-phaos-xmlenc-3/ folder.
>> In particular, enc-element-3des-kw-3des.tmpl
> 
> 
> Used the keys.xml from the above mentioned folder, used the template and modified the command to be:
> 
> xmlsec1 encrypt --pubkey-cert-pem ../example/sp/pki/mycert.pem \
>     --session-key des-192 --xml-data pre_saml2_response.xml \
>     --keys-file keys.xml \
>     --node-xpath '/*[local-name()="Response"]/*[local-name()="Assertion"]/*[local-name()="Subject"]/*[local-name()="EncryptedID"]/text()' \
>     enc-element-3des-kw-3des.tmpl
> 
> Same result though, the added part is:
> 
> <EncryptedData xmlns="http://www.w3.org/2001/04/xmlenc#"
>                Type="http://www.w3.org/2001/04/xmlenc#Element">
>   <EncryptionMethod Algorithm="http://www.w3.org/2001/04/xmlenc#tripledes-cbc"/>
>   <CipherData>
>     <CipherValue>ZBx6+ENTu+nktBVSGunBlnBPGc4MXxNJg9vLd1Z/MBJKx2QU/W9kD7OJRQ+Op6ct+865Cgf/9AM=</CipherValue>
>   </CipherData>
> </EncryptedData>
> 
> No EncryptedKey element ?
> did I misunderstand you ?
> 
> -- Roland
> ------------------------------------------------------
> Roland Hedberg
> IT Architect/Senior Researcher
> ICT Services and System Development (ITS) 
> Ume? University 
> SE-901 87 Ume?, Sweden	
> Phone +46 90 786 68 44
> Mobile +46 70 696 68 44 
> www.its.umu.se 
> 
> _______________________________________________
> xmlsec mailing list
> xmlsec at aleksey.com
> http://www.aleksey.com/mailman/listinfo/xmlsec

From aleksey at aleksey.com  Sat Jun  9 17:09:58 2012
From: aleksey at aleksey.com (Aleksey Sanin)
Date: Sat, 09 Jun 2012 17:09:58 -0700
Subject: [xmlsec] Question about default transform and multi-signature
 suggestion
In-Reply-To: <CAPpBuXgrvH2hn+JYg4dibXxU1mc6u1_edd5em7U19F16qa_BqQ@mail.gmail.com>
References: <CAPpBuXgrvH2hn+JYg4dibXxU1mc6u1_edd5em7U19F16qa_BqQ@mail.gmail.com>
Message-ID: <4FD3E5D6.9000302@aleksey.com>

1) Correct

2) You can use XPath transforms to select any nodeset

Aleksey

On 6/9/12 11:05 AM, Neko wrote:
> Dear Aleksey
> 
> About transform, I want to check if my understanding is wrong.
> Under self-referencing signature, the result node set of Xpath should be
> canonicalized.
> The CanonicalizationMethod only decides how the SignedInfo canonicalized.
> If no c14n Transform specified, then xmlsec applies the default c14n,
> which is http://www.w3.org/TR/2001/REC-xml-c14n-20010315
> The enveloped signature transform will remove the signature node in the
> content to sign, while nothing needs to be done in enveloping or
> detached signature.
> 
> And about multi-signature suggestion, is there any suggested rule to
> generate signatures?
> It seems that enveloped signature is not suitable for this kind of use.
> 
> 
> 
> 
> _______________________________________________
> xmlsec mailing list
> xmlsec at aleksey.com
> http://www.aleksey.com/mailman/listinfo/xmlsec

From roland.hedberg at adm.umu.se  Sun Jun 10 12:15:40 2012
From: roland.hedberg at adm.umu.se (Roland Hedberg)
Date: Sun, 10 Jun 2012 21:15:40 +0200
Subject: [xmlsec] Missing encryptedkey ?
In-Reply-To: <4FD3E58E.4020603@aleksey.com>
References: <A728C5FB-BCB2-4297-8635-0AD7F623ACD2@adm.umu.se>
 <4FD3765C.5010901@aleksey.com>
 <304B3228-6C9E-442A-840E-5C1A0CDB0DD8@adm.umu.se>
 <4FD3E58E.4020603@aleksey.com>
Message-ID: <085FA557-15A3-4D15-A6CD-7C01B79EDCD1@adm.umu.se>

Sorry to bother you again Aleksey,
but there are things in the encryption process I just don't understand.

10 jun 2012 kl. 02:08 skrev Aleksey Sanin:

> You need to use KW transform. Take a look at
> 
> tests/merlin-xmlenc-five/encrypt-element-tripledes-cbc-kw-aes128.tmpl

But enc-element-3des-kw-3des.tmpl also used KW transform, right ?

Obviously, there is something here I don't understand.

This is how I have reasoned:

Let's say I have a RSA key-pair and I want to use a des-192 key as the session key.

The template would then be something like tests/01-phaos-xmlenc-3/enc-element-3des-kt-rsa1_5.tmpl .
Except for the fact that I have the RSA key in a PEM file instead of in a key-file (as in keys.xml).
So, I modified the template file to be:

<?xml version="1.0" encoding="UTF-8"?>
<EncryptedData Id="ED" Type="http://www.w3.org/2001/04/xmlenc#Element" xmlns="http://www.w3.org/2001/04/xmlenc#">
    <EncryptionMethod Algorithm="http://www.w3.org/2001/04/xmlenc#tripledes-cbc"/>
    <ds:KeyInfo xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
      <EncryptedKey Id="EK" xmlns="http://www.w3.org/2001/04/xmlenc#">
        <EncryptionMethod Algorithm="http://www.w3.org/2001/04/xmlenc#rsa-1_5"/>
        <ds:KeyInfo xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
        </ds:KeyInfo>
        <CipherData>
          <CipherValue>
          </CipherValue>
        </CipherData>
        <ReferenceList>
          <DataReference URI="#ED"/>
        </ReferenceList>
      </EncryptedKey>
    </ds:KeyInfo>
    <CipherData>
      <CipherValue>
      </CipherValue>
    </CipherData>
</EncryptedData>

Right so far ?

On to the command line, here I get:

xmlsec1 encrypt --privkey-pem mykey.pem \
    --session-key des-192 --xml-data pre.xml \
    --node-xpath '/*[local-name()="Response"]/*[local-name()="Assertion"]/*[local-name()="Subject"]/*[local-name()="EncryptedID"]/text()' \
    enc-element-3des-kt-rsa1_5_mod.tmpl 

Now, the result I expected of this is that xmlsec would construct a 3des session key, encrypt the
value of the specified element and place that value in the EncryptedData/CipherData/CipherValue element.

In the EncryptedKey/CipherData/CipherValue element I would expect to find the 3des session key encrypted with the RSA key.

But this doesn't happen. 
What happens is that the whole <KeyInfo> element in the template doesn't appear in the output.
I do get something in the EncryptedData/CipherData/CipherValue element, but I don't know which key that was used to create that value.

So, isn't it possible to do what I want with xmlsec ?
If it is where did I go wrong ?

-- Roland
------------------------------------------------------
Roland Hedberg
IT Architect/Senior Researcher
ICT Services and System Development (ITS) 
Ume? University 
SE-901 87 Ume?, Sweden	
Phone +46 90 786 68 44
Mobile +46 70 696 68 44 
www.its.umu.se 


From aleksey at aleksey.com  Sun Jun 10 17:51:02 2012
From: aleksey at aleksey.com (Aleksey Sanin)
Date: Sun, 10 Jun 2012 17:51:02 -0700
Subject: [xmlsec] Missing encryptedkey ?
In-Reply-To: <085FA557-15A3-4D15-A6CD-7C01B79EDCD1@adm.umu.se>
References: <A728C5FB-BCB2-4297-8635-0AD7F623ACD2@adm.umu.se>
 <4FD3765C.5010901@aleksey.com>
 <304B3228-6C9E-442A-840E-5C1A0CDB0DD8@adm.umu.se>
 <4FD3E58E.4020603@aleksey.com>
 <085FA557-15A3-4D15-A6CD-7C01B79EDCD1@adm.umu.se>
Message-ID: <4FD540F6.5090809@aleksey.com>

Roland,

I am not 100% sure what is going with your template. I know that the
tests in the tests folder pass and I am pretty sure that this particular
scenario works. I would suggest you start from running xmlsec unit
tests. In the log file you will find exact commands used and then you
can start modifying the command step by step to get what you need.

Best,

Aleksey

On 6/10/12 12:15 PM, Roland Hedberg wrote:
> Sorry to bother you again Aleksey,
> but there are things in the encryption process I just don't understand.
> 
> 10 jun 2012 kl. 02:08 skrev Aleksey Sanin:
> 
>> You need to use KW transform. Take a look at
>>
>> tests/merlin-xmlenc-five/encrypt-element-tripledes-cbc-kw-aes128.tmpl
> 
> But enc-element-3des-kw-3des.tmpl also used KW transform, right ?
> 
> Obviously, there is something here I don't understand.
> 
> This is how I have reasoned:
> 
> Let's say I have a RSA key-pair and I want to use a des-192 key as the session key.
> 
> The template would then be something like tests/01-phaos-xmlenc-3/enc-element-3des-kt-rsa1_5.tmpl .
> Except for the fact that I have the RSA key in a PEM file instead of in a key-file (as in keys.xml).
> So, I modified the template file to be:
> 
> <?xml version="1.0" encoding="UTF-8"?>
> <EncryptedData Id="ED" Type="http://www.w3.org/2001/04/xmlenc#Element" xmlns="http://www.w3.org/2001/04/xmlenc#">
>     <EncryptionMethod Algorithm="http://www.w3.org/2001/04/xmlenc#tripledes-cbc"/>
>     <ds:KeyInfo xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
>       <EncryptedKey Id="EK" xmlns="http://www.w3.org/2001/04/xmlenc#">
>         <EncryptionMethod Algorithm="http://www.w3.org/2001/04/xmlenc#rsa-1_5"/>
>         <ds:KeyInfo xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
>         </ds:KeyInfo>
>         <CipherData>
>           <CipherValue>
>           </CipherValue>
>         </CipherData>
>         <ReferenceList>
>           <DataReference URI="#ED"/>
>         </ReferenceList>
>       </EncryptedKey>
>     </ds:KeyInfo>
>     <CipherData>
>       <CipherValue>
>       </CipherValue>
>     </CipherData>
> </EncryptedData>
> 
> Right so far ?
> 
> On to the command line, here I get:
> 
> xmlsec1 encrypt --privkey-pem mykey.pem \
>     --session-key des-192 --xml-data pre.xml \
>     --node-xpath '/*[local-name()="Response"]/*[local-name()="Assertion"]/*[local-name()="Subject"]/*[local-name()="EncryptedID"]/text()' \
>     enc-element-3des-kt-rsa1_5_mod.tmpl 
> 
> Now, the result I expected of this is that xmlsec would construct a 3des session key, encrypt the
> value of the specified element and place that value in the EncryptedData/CipherData/CipherValue element.
> 
> In the EncryptedKey/CipherData/CipherValue element I would expect to find the 3des session key encrypted with the RSA key.
> 
> But this doesn't happen. 
> What happens is that the whole <KeyInfo> element in the template doesn't appear in the output.
> I do get something in the EncryptedData/CipherData/CipherValue element, but I don't know which key that was used to create that value.
> 
> So, isn't it possible to do what I want with xmlsec ?
> If it is where did I go wrong ?
> 
> -- Roland
> ------------------------------------------------------
> Roland Hedberg
> IT Architect/Senior Researcher
> ICT Services and System Development (ITS) 
> Ume? University 
> SE-901 87 Ume?, Sweden	
> Phone +46 90 786 68 44
> Mobile +46 70 696 68 44 
> www.its.umu.se 
> 

From re.tf at acm.org  Mon Jun 11 05:39:19 2012
From: re.tf at acm.org (Renato Tegon Forti)
Date: Mon, 11 Jun 2012 09:39:19 -0300
Subject: [xmlsec] how verify sig using xmlAddID and local certs!
Message-ID: <007101cd47cf$39abb890$ad0329b0$@acm.org>

Hi All,

 

I'm trying to understand how the xmlsec tool interprets this command:

 

xmlsec1 --verify --id-attr:Id infNFe file.xml

 

which parts of code are activated! Need to reproduce this behavior in my
code

 

Can someone explain to me?

 

In special how "xmlSecAppLoadKeys" load CA 's files of /usr/lib/ssl/certs/ :
(for sample. openssl  ssl files folder) !

 

I need use "xmlAddID" to add "infNFe" like an id! Ok? How? 

 

Anything else!

 

My test code:

 

// Copyright 2011-2012 Renato Tegon Forti

 

#define BOOST_ALL_DYN_LINK

#define BOOST_THREAD_USE_DLL  //thread header not compliant with
'BOOST_ALL_DYN_LINK'

#define BOOST_LIB_DIAGNOSTIC

 

#include <boost/test/minimal.hpp>

#include <dsafe/xmlsig.hpp>

 

#define XMLSEC_CRYPTO_OPENSSL

 

#include <libxml/tree.h>

#include <libxml/xmlmemory.h>

#include <libxml/parser.h>

 

#ifndef XMLSEC_NO_XSLT

#include <libxslt/xslt.h>

#endif /* XMLSEC_NO_XSLT */

 

#include <xmlsec/xmlsec.h>

#include <xmlsec/xmltree.h>

#include <xmlsec/xmldsig.h>

#include <xmlsec/xmlenc.h>

#include <xmlsec/templates.h>

#include <xmlsec/crypto.h>

 

 

/** 

 * verify_file:

* @mngr:                              the pointer to keys manager.

* @xml_file:                    the signed XML file name.

*

* Verifies XML signature in #xml_file.

*

* Returns 0 on success or a negative value if an error occurs.

*/

int 

verify_file(xmlSecKeysMngrPtr mngr, const char* xml_file)

{

   xmlDocPtr doc = NULL;

   xmlNodePtr node = NULL;

   xmlSecDSigCtxPtr dsigCtx = NULL;

    int res = -1;

    

    assert(mngr);

    assert(xml_file);

 

    /* load file */

    doc = xmlParseFile(xml_file);

    if ((doc == NULL) || (xmlDocGetRootElement(doc) == NULL)){

                fprintf(stderr, "Error: unable to parse file \"%s\"\n",
xml_file);

                goto done;         

    }

    

    /* find start node */

    node = xmlSecFindNode(xmlDocGetRootElement(doc), xmlSecNodeSignature,
xmlSecDSigNs);

    if(node == NULL) {

                fprintf(stderr, "Error: start node not found in \"%s\"\n",
xml_file);

                goto done;         

    }

 

    /* create signature context */

    dsigCtx = xmlSecDSigCtxCreate(mngr);

    if(dsigCtx == NULL) {

        fprintf(stderr,"Error: failed to create signature context\n");

                goto done;

    }

                

 

    

 

    /* limit the Reference URI attributes to empty or NULL */

    dsigCtx->enabledReferenceUris = xmlSecTransformUriTypeEmpty;

    

    /* limit allowed transforms for siganture and reference processing */

    if((xmlSecDSigCtxEnableSignatureTransform(dsigCtx,
xmlSecTransformInclC14NId) < 0) ||

       (xmlSecDSigCtxEnableSignatureTransform(dsigCtx,
xmlSecTransformExclC14NId) < 0) ||

       (xmlSecDSigCtxEnableSignatureTransform(dsigCtx,
xmlSecTransformSha1Id) < 0) ||

       (xmlSecDSigCtxEnableSignatureTransform(dsigCtx,
xmlSecTransformRsaSha1Id) < 0)) {

 

        fprintf(stderr,"Error: failed to limit allowed siganture
transforms\n");

                goto done;

    }

    if((xmlSecDSigCtxEnableReferenceTransform(dsigCtx,
xmlSecTransformInclC14NId) < 0) ||

       (xmlSecDSigCtxEnableReferenceTransform(dsigCtx,
xmlSecTransformExclC14NId) < 0) ||

       (xmlSecDSigCtxEnableReferenceTransform(dsigCtx,
xmlSecTransformSha1Id) < 0) ||

       (xmlSecDSigCtxEnableReferenceTransform(dsigCtx,
xmlSecTransformEnvelopedId) < 0)) {

 

        fprintf(stderr,"Error: failed to limit allowed reference
transforms\n");

                goto done;

    }

 

    /* in addition, limit possible key data to valid X509 certificates only
*/

    if(xmlSecPtrListAdd(&(dsigCtx->keyInfoReadCtx.enabledKeyData), BAD_CAST
xmlSecKeyDataX509Id) < 0) {

        fprintf(stderr,"Error: failed to limit allowed key data\n");

                goto done;

    }

    

    /* Verify signature */

    if(xmlSecDSigCtxVerify(dsigCtx, node) < 0) {

        fprintf(stderr,"Error: signature verify\n");

                goto done;

    }

 

    /* check that we have only one Reference */

    if((dsigCtx->status == xmlSecDSigStatusSucceeded) && 

        (xmlSecPtrListGetSize(&(dsigCtx->signedInfoReferences)) != 1)) {

                

        fprintf(stderr,"Error: only one reference is allowed\n");

                goto done;

    }

        

    /* print verification result to stdout */

    if(dsigCtx->status == xmlSecDSigStatusSucceeded) {

                fprintf(stdout, "Signature is OK\n");

    } else {

                fprintf(stdout, "Signature is INVALID\n");

    }    

 

    /* success */

    res = 0;

 

done:    

    /* cleanup */

    if(dsigCtx != NULL) {

                xmlSecDSigCtxDestroy(dsigCtx);

    }

    

    if(doc != NULL) {

                xmlFreeDoc(doc); 

    }

    return(res);

 

}

 

int

init_allxml_lib()

{    

   // Init libxml and libxslt libraries

   xmlInitParser();

   

   LIBXML_TEST_VERSION

   xmlLoadExtDtdDefaultValue = XML_DETECT_IDS | XML_COMPLETE_ATTRS;

   xmlSubstituteEntitiesDefault(1);

#ifndef XMLSEC_NO_XSLT

   xmlIndentTreeOutput = 1; 

#endif // XMLSEC_NO_XSLT 

                

   // Init xmlsec library 

   if(xmlSecInit() < 0) {

   fprintf(stderr, "Error: xmlsec initialization failed.\n");

   return(-1);

   }

 

   // Check loaded library version 

   if(xmlSecCheckVersion() != 1) {

   fprintf(stderr, "Error: loaded xmlsec library version is not
compatible.\n");

   return(-1);

   }    

   

   // Load default crypto engine if we are supporting dynamic

   // loading for xmlsec-crypto libraries. Use the crypto library

   // name ("openssl", "nss", etc.) to load corresponding 

   // xmlsec-crypto library.

 

#ifdef XMLSEC_CRYPTO_DYNAMIC_LOADING

   if(xmlSecCryptoDLLoadLibrary(BAD_CAST XMLSEC_CRYPTO) < 0) {

   fprintf(stderr, "Error: unable to load default xmlsec-crypto library.
Make sure\n"

                                               "that you have it installed
and check shared libraries path\n"

                                               "(LD_LIBRARY_PATH) envornment
variable.\n");

   return(-1);       

   }

#endif /* XMLSEC_CRYPTO_DYNAMIC_LOADING */

 

   // Init crypto library 

   if(xmlSecCryptoAppInit(NULL) < 0) {

      fprintf(stderr, "Error: crypto initialization failed.\n");

      return(-1);

   }

 

   // Init xmlsec-crypto library 

   if(xmlSecCryptoInit() < 0) {

   fprintf(stderr, "Error: xmlsec-crypto initialization failed.\n");

   return(-1);

   }

                               

   return 0;

}

 

void

fnit_allxml_lib()

{

   // Shutdown xmlsec-crypto library 

   xmlSecCryptoShutdown();

    

   //Shutdown crypto library 

   xmlSecCryptoAppShutdown();

    

   //Shutdown xmlsec library 

   xmlSecShutdown();

 

   // Shutdown libxslt/libxml 

#ifndef XMLSEC_NO_XSLT

   xsltCleanupGlobals();            

#endif //XMLSEC_NO_XSLT 

 

   xmlCleanupParser();  

}

 

const std::string XML_FILE =
"/Projects/project.dokfile.vses/hades/trunk/products/doksafe/engine/libs/xml
dsig/test/"

                             "mt-embedded-id-dtd-attr.xml";

 
// "mt.xml";

 

// Unit Tests 

 

void do_0()

{

   xmlSecKeysMngrPtr mngr = xmlSecKeysMngrCreate();

   if(mngr == NULL) 

   {

      fprintf(stderr, "Error: failed to create keys manager.\n");   

   }

                

   if(xmlSecCryptoAppDefaultKeysMngrInit(mngr) < 0) 

   {

      fprintf(stderr, "Error: failed to initialize keys manager.\n");

      xmlSecKeysMngrDestroy(mngr);

   }  

                

   BOOST_CHECK(init_allxml_lib() == 0);

   BOOST_CHECK(verify_file(mngr, XML_FILE.c_str()) == 0);

   

   fnit_allxml_lib();

}

 

// -

 

int test_main(int, char*[])

{

   do_0();

 

   return 0;

}

 

 

 

 

Thanks

 

 

 

 

 

 

 

 

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.aleksey.com/pipermail/xmlsec/attachments/20120611/239523b2/attachment-0001.html>

From aleksey at aleksey.com  Mon Jun 11 06:46:28 2012
From: aleksey at aleksey.com (Aleksey Sanin)
Date: Mon, 11 Jun 2012 06:46:28 -0700
Subject: [xmlsec] how verify sig using xmlAddID and local certs!
In-Reply-To: <007101cd47cf$39abb890$ad0329b0$@acm.org>
References: <007101cd47cf$39abb890$ad0329b0$@acm.org>
Message-ID: <4FD5F6B4.3010605@aleksey.com>

1) xmlAddID - look at LibXML2 documentation for the function,
it's pretty simple.

2) Actually default trusted certs are loaded in the xmlsec-openssl
init function.

Aleksey

On 6/11/12 5:39 AM, Renato Tegon Forti wrote:
> Hi All,
> 
>  
> 
> I'm trying to understand how the xmlsec tool interprets this command:
> 
>  
> 
> xmlsec1 --verify --id-attr:Id infNFe file.xml
> 
>  
> 
> which parts of code are activated! Need to reproduce this behavior in my
> code
> 
>  
> 
> Can someone explain to me?
> 
>  
> 
> In special how ?xmlSecAppLoadKeys? load CA ?s files of
> /usr/lib/ssl/certs/ : (for sample. openssl  ssl files folder) !
> 
>  
> 
> I need use ?xmlAddID? to add ?infNFe? like an id! Ok? How?
> 
>  
> 
> Anything else!
> 
>  
> 
> My test code:
> 
>  
> 
> // Copyright 2011-2012 Renato Tegon Forti
> 
>  
> 
> #define BOOST_ALL_DYN_LINK
> 
> #define BOOST_THREAD_USE_DLL  //thread header not compliant with
> 'BOOST_ALL_DYN_LINK'
> 
> #define BOOST_LIB_DIAGNOSTIC
> 
>  
> 
> #include <boost/test/minimal.hpp>
> 
> #include <dsafe/xmlsig.hpp>
> 
>  
> 
> #define XMLSEC_CRYPTO_OPENSSL
> 
>  
> 
> #include <libxml/tree.h>
> 
> #include <libxml/xmlmemory.h>
> 
> #include <libxml/parser.h>
> 
>  
> 
> #ifndef XMLSEC_NO_XSLT
> 
> #include <libxslt/xslt.h>
> 
> #endif /* XMLSEC_NO_XSLT */
> 
>  
> 
> #include <xmlsec/xmlsec.h>
> 
> #include <xmlsec/xmltree.h>
> 
> #include <xmlsec/xmldsig.h>
> 
> #include <xmlsec/xmlenc.h>
> 
> #include <xmlsec/templates.h>
> 
> #include <xmlsec/crypto.h>
> 
>  
> 
>  
> 
> /**
> 
>  * verify_file:
> 
> * @mngr:                              the pointer to keys manager.
> 
> * @xml_file:                    the signed XML file name.
> 
> *
> 
> * Verifies XML signature in #xml_file.
> 
> *
> 
> * Returns 0 on success or a negative value if an error occurs.
> 
> */
> 
> int
> 
> verify_file(xmlSecKeysMngrPtr mngr, const char* xml_file)
> 
> {
> 
>    xmlDocPtr doc = NULL;
> 
>    xmlNodePtr node = NULL;
> 
>    xmlSecDSigCtxPtr dsigCtx = NULL;
> 
>     int res = -1;
> 
>    
> 
>     assert(mngr);
> 
>     assert(xml_file);
> 
>  
> 
>     /* load file */
> 
>     doc = xmlParseFile(xml_file);
> 
>     if ((doc == NULL) || (xmlDocGetRootElement(doc) == NULL)){
> 
>                 fprintf(stderr, "Error: unable to parse file \"%s\"\n",
> xml_file);
> 
>                 goto done;        
> 
>     }
> 
>    
> 
>     /* find start node */
> 
>     node = xmlSecFindNode(xmlDocGetRootElement(doc),
> xmlSecNodeSignature, xmlSecDSigNs);
> 
>     if(node == NULL) {
> 
>                 fprintf(stderr, "Error: start node not found in
> \"%s\"\n", xml_file);
> 
>                 goto done;        
> 
>     }
> 
>  
> 
>     /* create signature context */
> 
>     dsigCtx = xmlSecDSigCtxCreate(mngr);
> 
>     if(dsigCtx == NULL) {
> 
>         fprintf(stderr,"Error: failed to create signature context\n");
> 
>                 goto done;
> 
>     }
> 
>                
> 
>  
> 
>    
> 
>  
> 
>     /* limit the Reference URI attributes to empty or NULL */
> 
>     dsigCtx->enabledReferenceUris = xmlSecTransformUriTypeEmpty;
> 
>    
> 
>     /* limit allowed transforms for siganture and reference processing */
> 
>     if((xmlSecDSigCtxEnableSignatureTransform(dsigCtx,
> xmlSecTransformInclC14NId) < 0) ||
> 
>        (xmlSecDSigCtxEnableSignatureTransform(dsigCtx,
> xmlSecTransformExclC14NId) < 0) ||
> 
>        (xmlSecDSigCtxEnableSignatureTransform(dsigCtx,
> xmlSecTransformSha1Id) < 0) ||
> 
>        (xmlSecDSigCtxEnableSignatureTransform(dsigCtx,
> xmlSecTransformRsaSha1Id) < 0)) {
> 
>  
> 
>         fprintf(stderr,"Error: failed to limit allowed siganture
> transforms\n");
> 
>                 goto done;
> 
>     }
> 
>     if((xmlSecDSigCtxEnableReferenceTransform(dsigCtx,
> xmlSecTransformInclC14NId) < 0) ||
> 
>        (xmlSecDSigCtxEnableReferenceTransform(dsigCtx,
> xmlSecTransformExclC14NId) < 0) ||
> 
>        (xmlSecDSigCtxEnableReferenceTransform(dsigCtx,
> xmlSecTransformSha1Id) < 0) ||
> 
>        (xmlSecDSigCtxEnableReferenceTransform(dsigCtx,
> xmlSecTransformEnvelopedId) < 0)) {
> 
>  
> 
>         fprintf(stderr,"Error: failed to limit allowed reference
> transforms\n");
> 
>                 goto done;
> 
>     }
> 
>  
> 
>     /* in addition, limit possible key data to valid X509 certificates
> only */
> 
>     if(xmlSecPtrListAdd(&(dsigCtx->keyInfoReadCtx.enabledKeyData),
> BAD_CAST xmlSecKeyDataX509Id) < 0) {
> 
>         fprintf(stderr,"Error: failed to limit allowed key data\n");
> 
>                 goto done;
> 
>     }
> 
>    
> 
>     /* Verify signature */
> 
>     if(xmlSecDSigCtxVerify(dsigCtx, node) < 0) {
> 
>         fprintf(stderr,"Error: signature verify\n");
> 
>                 goto done;
> 
>     }
> 
>  
> 
>     /* check that we have only one Reference */
> 
>     if((dsigCtx->status == xmlSecDSigStatusSucceeded) &&
> 
>         (xmlSecPtrListGetSize(&(dsigCtx->signedInfoReferences)) != 1)) {
> 
>                
> 
>         fprintf(stderr,"Error: only one reference is allowed\n");
> 
>                 goto done;
> 
>     }
> 
>        
> 
>     /* print verification result to stdout */
> 
>     if(dsigCtx->status == xmlSecDSigStatusSucceeded) {
> 
>                 fprintf(stdout, "Signature is OK\n");
> 
>     } else {
> 
>                 fprintf(stdout, "Signature is INVALID\n");
> 
>     }   
> 
>  
> 
>     /* success */
> 
>     res = 0;
> 
>  
> 
> done:   
> 
>     /* cleanup */
> 
>     if(dsigCtx != NULL) {
> 
>                 xmlSecDSigCtxDestroy(dsigCtx);
> 
>     }
> 
>    
> 
>     if(doc != NULL) {
> 
>                 xmlFreeDoc(doc);
> 
>     }
> 
>     return(res);
> 
>  
> 
> }
> 
>  
> 
> int
> 
> init_allxml_lib()
> 
> {   
> 
>    // Init libxml and libxslt libraries
> 
>    xmlInitParser();
> 
>   
> 
>    LIBXML_TEST_VERSION
> 
>    xmlLoadExtDtdDefaultValue = XML_DETECT_IDS | XML_COMPLETE_ATTRS;
> 
>    xmlSubstituteEntitiesDefault(1);
> 
> #ifndef XMLSEC_NO_XSLT
> 
>    xmlIndentTreeOutput = 1;
> 
> #endif // XMLSEC_NO_XSLT
> 
>                
> 
>    // Init xmlsec library
> 
>    if(xmlSecInit() < 0) {
> 
>    fprintf(stderr, "Error: xmlsec initialization failed.\n");
> 
>    return(-1);
> 
>    }
> 
>  
> 
>    // Check loaded library version
> 
>    if(xmlSecCheckVersion() != 1) {
> 
>    fprintf(stderr, "Error: loaded xmlsec library version is not
> compatible.\n");
> 
>    return(-1);
> 
>    }   
> 
>    
> 
>    // Load default crypto engine if we are supporting dynamic
> 
>    // loading for xmlsec-crypto libraries. Use the crypto library
> 
>    // name ("openssl", "nss", etc.) to load corresponding
> 
>    // xmlsec-crypto library.
> 
>  
> 
> #ifdef XMLSEC_CRYPTO_DYNAMIC_LOADING
> 
>    if(xmlSecCryptoDLLoadLibrary(BAD_CAST XMLSEC_CRYPTO) < 0) {
> 
>    fprintf(stderr, "Error: unable to load default xmlsec-crypto library.
> Make sure\n"
> 
>                                                "that you have it
> installed and check shared libraries path\n"
> 
>                                                "(LD_LIBRARY_PATH)
> envornment variable.\n");
> 
>    return(-1);      
> 
>    }
> 
> #endif /* XMLSEC_CRYPTO_DYNAMIC_LOADING */
> 
>  
> 
>    // Init crypto library
> 
>    if(xmlSecCryptoAppInit(NULL) < 0) {
> 
>       fprintf(stderr, "Error: crypto initialization failed.\n");
> 
>       return(-1);
> 
>    }
> 
>  
> 
>    // Init xmlsec-crypto library
> 
>    if(xmlSecCryptoInit() < 0) {
> 
>    fprintf(stderr, "Error: xmlsec-crypto initialization failed.\n");
> 
>    return(-1);
> 
>    }
> 
>                               
> 
>    return 0;
> 
> }
> 
>  
> 
> void
> 
> fnit_allxml_lib()
> 
> {
> 
>    // Shutdown xmlsec-crypto library
> 
>    xmlSecCryptoShutdown();
> 
>    
> 
>    //Shutdown crypto library
> 
>    xmlSecCryptoAppShutdown();
> 
>    
> 
>    //Shutdown xmlsec library
> 
>    xmlSecShutdown();
> 
>  
> 
>    // Shutdown libxslt/libxml
> 
> #ifndef XMLSEC_NO_XSLT
> 
>    xsltCleanupGlobals();           
> 
> #endif //XMLSEC_NO_XSLT
> 
>  
> 
>    xmlCleanupParser(); 
> 
> }
> 
>  
> 
> const std::string XML_FILE =
> "/Projects/project.dokfile.vses/hades/trunk/products/doksafe/engine/libs/xmldsig/test/"
> 
>                              "mt-embedded-id-dtd-attr.xml";
> 
>                                                                                                              
> // "mt.xml";
> 
>  
> 
> // Unit Tests
> 
>  
> 
> void do_0()
> 
> {
> 
>    xmlSecKeysMngrPtr mngr = xmlSecKeysMngrCreate();
> 
>    if(mngr == NULL)
> 
>    {
> 
>       fprintf(stderr, "Error: failed to create keys manager.\n");  
> 
>    }
> 
>                
> 
>    if(xmlSecCryptoAppDefaultKeysMngrInit(mngr) < 0)
> 
>    {
> 
>       fprintf(stderr, "Error: failed to initialize keys manager.\n");
> 
>       xmlSecKeysMngrDestroy(mngr);
> 
>    } 
> 
>                
> 
>    BOOST_CHECK(init_allxml_lib() == 0);
> 
>    BOOST_CHECK(verify_file(mngr, XML_FILE.c_str()) == 0);
> 
>   
> 
>    fnit_allxml_lib();
> 
> }
> 
>  
> 
> // -
> 
>  
> 
> int test_main(int, char*[])
> 
> {
> 
>    do_0();
> 
>  
> 
>    return 0;
> 
> }
> 
>  
> 
>  
> 
>  
> 
>  
> 
> Thanks
> 
>  
> 
>  
> 
>  
> 
>  
> 
>  
> 
>  
> 
>  
> 
>  
> 
>  
> 
> 
> 
> _______________________________________________
> xmlsec mailing list
> xmlsec at aleksey.com
> http://www.aleksey.com/mailman/listinfo/xmlsec

From re.tf at acm.org  Mon Jun 11 07:09:58 2012
From: re.tf at acm.org (Renato Tegon Forti)
Date: Mon, 11 Jun 2012 11:09:58 -0300
Subject: [xmlsec] RES:  how verify sig using xmlAddID and local certs!
In-Reply-To: <4FD5F6B4.3010605@aleksey.com>
References: <007101cd47cf$39abb890$ad0329b0$@acm.org>
 <4FD5F6B4.3010605@aleksey.com>
Message-ID: <007c01cd47db$e3ad0770$ab071650$@acm.org>

Hi

>>  xmlAddID - look at LibXML2 documentation for the function, it's pretty
simple.
OK

>> Actually default trusted certs are loaded in the xmlsec-openssl init
function.
Then I don't need load certs in "xmlSecKeysMngrPtr"?

I am trying to use sample "Verifying a signature with X 509 certificates."

And I changed load_trusted_certs  to accept a vector with keys file, like:

----------------------------------------------------------------------------
---------------------------------
std::vector<std::string> certs;
   
certs.push_back("/usr/lib/ssl/certs/Serasa_Certificadora_Digital_v2.pem");
certs.push_back("/usr/lib/ssl/certs/Serasa_Autoridade_Certificadora_Principa
l_v2.pem");
certs.push_back("/usr/lib/ssl/certs/Autoridade_Certificadora_Raiz_Brasileira
_v2.pem");
	
mngr = load_trusted_certs(certs);

----------------------------------------------------------------------------
---------------------------------

And for now, I using DTD on xml file:

----------------------------------------------------------------------------
---------------------------------
<?xml version="1.0" encoding="UTF-8"?><!DOCTYPE test [
<!ATTLIST infNFe Id ID #IMPLIED>
]>
----------------------------------------------------------------------------
---------------------------------

But always I received: "Signature is INVALID"!

If I use xmlsec1 command, its work in some file!

----------------------------------------------------------------------------
---------------------------------
afe/engine/libs/xmldsig/test$ xmlsec1 --verify mt-embedded-id-dtd-attr.xml
OK
SignedInfo References (ok/all): 1/1
Manifests References (ok/all): 0/0
----------------------------------------------------------------------------
---------------------------------

How I can print debug into to try see what's happening?

My current code, and file that I need check is attached!

Thanks again, and again, and again ...!

-----Mensagem original-----
De: Aleksey Sanin [mailto:aleksey at aleksey.com] 
Enviada em: segunda-feira, 11 de junho de 2012 10:46
Para: Renato Tegon Forti
Cc: xmlsec at aleksey.com
Assunto: Re: [xmlsec] how verify sig using xmlAddID and local certs!

1) xmlAddID - look at LibXML2 documentation for the function, it's pretty
simple.

2) Actually default trusted certs are loaded in the xmlsec-openssl init
function.

Aleksey

On 6/11/12 5:39 AM, Renato Tegon Forti wrote:
> Hi All,
> 
>  
> 
> I'm trying to understand how the xmlsec tool interprets this command:
> 
>  
> 
> xmlsec1 --verify --id-attr:Id infNFe file.xml
> 
>  
> 
> which parts of code are activated! Need to reproduce this behavior in 
> my code
> 
>  
> 
> Can someone explain to me?
> 
>  
> 
> In special how "xmlSecAppLoadKeys" load CA 's files of 
> /usr/lib/ssl/certs/ : (for sample. openssl  ssl files folder) !
> 
>  
> 
> I need use "xmlAddID" to add "infNFe" like an id! Ok? How?
> 
>  
> 
> Anything else!
> 
>  
> 
> My test code:
> 
>  
> 
> // Copyright 2011-2012 Renato Tegon Forti
> 
>  
> 
> #define BOOST_ALL_DYN_LINK
> 
> #define BOOST_THREAD_USE_DLL  //thread header not compliant with 
> 'BOOST_ALL_DYN_LINK'
> 
> #define BOOST_LIB_DIAGNOSTIC
> 
>  
> 
> #include <boost/test/minimal.hpp>
> 
> #include <dsafe/xmlsig.hpp>
> 
>  
> 
> #define XMLSEC_CRYPTO_OPENSSL
> 
>  
> 
> #include <libxml/tree.h>
> 
> #include <libxml/xmlmemory.h>
> 
> #include <libxml/parser.h>
> 
>  
> 
> #ifndef XMLSEC_NO_XSLT
> 
> #include <libxslt/xslt.h>
> 
> #endif /* XMLSEC_NO_XSLT */
> 
>  
> 
> #include <xmlsec/xmlsec.h>
> 
> #include <xmlsec/xmltree.h>
> 
> #include <xmlsec/xmldsig.h>
> 
> #include <xmlsec/xmlenc.h>
> 
> #include <xmlsec/templates.h>
> 
> #include <xmlsec/crypto.h>
> 
>  
> 
>  
> 
> /**
> 
>  * verify_file:
> 
> * @mngr:                              the pointer to keys manager.
> 
> * @xml_file:                    the signed XML file name.
> 
> *
> 
> * Verifies XML signature in #xml_file.
> 
> *
> 
> * Returns 0 on success or a negative value if an error occurs.
> 
> */
> 
> int
> 
> verify_file(xmlSecKeysMngrPtr mngr, const char* xml_file)
> 
> {
> 
>    xmlDocPtr doc = NULL;
> 
>    xmlNodePtr node = NULL;
> 
>    xmlSecDSigCtxPtr dsigCtx = NULL;
> 
>     int res = -1;
> 
>    
> 
>     assert(mngr);
> 
>     assert(xml_file);
> 
>  
> 
>     /* load file */
> 
>     doc = xmlParseFile(xml_file);
> 
>     if ((doc == NULL) || (xmlDocGetRootElement(doc) == NULL)){
> 
>                 fprintf(stderr, "Error: unable to parse file 
> \"%s\"\n", xml_file);
> 
>                 goto done;        
> 
>     }
> 
>    
> 
>     /* find start node */
> 
>     node = xmlSecFindNode(xmlDocGetRootElement(doc),
> xmlSecNodeSignature, xmlSecDSigNs);
> 
>     if(node == NULL) {
> 
>                 fprintf(stderr, "Error: start node not found in 
> \"%s\"\n", xml_file);
> 
>                 goto done;        
> 
>     }
> 
>  
> 
>     /* create signature context */
> 
>     dsigCtx = xmlSecDSigCtxCreate(mngr);
> 
>     if(dsigCtx == NULL) {
> 
>         fprintf(stderr,"Error: failed to create signature context\n");
> 
>                 goto done;
> 
>     }
> 
>                
> 
>  
> 
>    
> 
>  
> 
>     /* limit the Reference URI attributes to empty or NULL */
> 
>     dsigCtx->enabledReferenceUris = xmlSecTransformUriTypeEmpty;
> 
>    
> 
>     /* limit allowed transforms for siganture and reference processing 
> */
> 
>     if((xmlSecDSigCtxEnableSignatureTransform(dsigCtx,
> xmlSecTransformInclC14NId) < 0) ||
> 
>        (xmlSecDSigCtxEnableSignatureTransform(dsigCtx,
> xmlSecTransformExclC14NId) < 0) ||
> 
>        (xmlSecDSigCtxEnableSignatureTransform(dsigCtx,
> xmlSecTransformSha1Id) < 0) ||
> 
>        (xmlSecDSigCtxEnableSignatureTransform(dsigCtx,
> xmlSecTransformRsaSha1Id) < 0)) {
> 
>  
> 
>         fprintf(stderr,"Error: failed to limit allowed siganture 
> transforms\n");
> 
>                 goto done;
> 
>     }
> 
>     if((xmlSecDSigCtxEnableReferenceTransform(dsigCtx,
> xmlSecTransformInclC14NId) < 0) ||
> 
>        (xmlSecDSigCtxEnableReferenceTransform(dsigCtx,
> xmlSecTransformExclC14NId) < 0) ||
> 
>        (xmlSecDSigCtxEnableReferenceTransform(dsigCtx,
> xmlSecTransformSha1Id) < 0) ||
> 
>        (xmlSecDSigCtxEnableReferenceTransform(dsigCtx,
> xmlSecTransformEnvelopedId) < 0)) {
> 
>  
> 
>         fprintf(stderr,"Error: failed to limit allowed reference 
> transforms\n");
> 
>                 goto done;
> 
>     }
> 
>  
> 
>     /* in addition, limit possible key data to valid X509 certificates 
> only */
> 
>     if(xmlSecPtrListAdd(&(dsigCtx->keyInfoReadCtx.enabledKeyData),
> BAD_CAST xmlSecKeyDataX509Id) < 0) {
> 
>         fprintf(stderr,"Error: failed to limit allowed key data\n");
> 
>                 goto done;
> 
>     }
> 
>    
> 
>     /* Verify signature */
> 
>     if(xmlSecDSigCtxVerify(dsigCtx, node) < 0) {
> 
>         fprintf(stderr,"Error: signature verify\n");
> 
>                 goto done;
> 
>     }
> 
>  
> 
>     /* check that we have only one Reference */
> 
>     if((dsigCtx->status == xmlSecDSigStatusSucceeded) &&
> 
>         (xmlSecPtrListGetSize(&(dsigCtx->signedInfoReferences)) != 1)) 
> {
> 
>                
> 
>         fprintf(stderr,"Error: only one reference is allowed\n");
> 
>                 goto done;
> 
>     }
> 
>        
> 
>     /* print verification result to stdout */
> 
>     if(dsigCtx->status == xmlSecDSigStatusSucceeded) {
> 
>                 fprintf(stdout, "Signature is OK\n");
> 
>     } else {
> 
>                 fprintf(stdout, "Signature is INVALID\n");
> 
>     }   
> 
>  
> 
>     /* success */
> 
>     res = 0;
> 
>  
> 
> done:   
> 
>     /* cleanup */
> 
>     if(dsigCtx != NULL) {
> 
>                 xmlSecDSigCtxDestroy(dsigCtx);
> 
>     }
> 
>    
> 
>     if(doc != NULL) {
> 
>                 xmlFreeDoc(doc);
> 
>     }
> 
>     return(res);
> 
>  
> 
> }
> 
>  
> 
> int
> 
> init_allxml_lib()
> 
> {   
> 
>    // Init libxml and libxslt libraries
> 
>    xmlInitParser();
> 
>   
> 
>    LIBXML_TEST_VERSION
> 
>    xmlLoadExtDtdDefaultValue = XML_DETECT_IDS | XML_COMPLETE_ATTRS;
> 
>    xmlSubstituteEntitiesDefault(1);
> 
> #ifndef XMLSEC_NO_XSLT
> 
>    xmlIndentTreeOutput = 1;
> 
> #endif // XMLSEC_NO_XSLT
> 
>                
> 
>    // Init xmlsec library
> 
>    if(xmlSecInit() < 0) {
> 
>    fprintf(stderr, "Error: xmlsec initialization failed.\n");
> 
>    return(-1);
> 
>    }
> 
>  
> 
>    // Check loaded library version
> 
>    if(xmlSecCheckVersion() != 1) {
> 
>    fprintf(stderr, "Error: loaded xmlsec library version is not 
> compatible.\n");
> 
>    return(-1);
> 
>    }   
> 
>    
> 
>    // Load default crypto engine if we are supporting dynamic
> 
>    // loading for xmlsec-crypto libraries. Use the crypto library
> 
>    // name ("openssl", "nss", etc.) to load corresponding
> 
>    // xmlsec-crypto library.
> 
>  
> 
> #ifdef XMLSEC_CRYPTO_DYNAMIC_LOADING
> 
>    if(xmlSecCryptoDLLoadLibrary(BAD_CAST XMLSEC_CRYPTO) < 0) {
> 
>    fprintf(stderr, "Error: unable to load default xmlsec-crypto library.
> Make sure\n"
> 
>                                                "that you have it 
> installed and check shared libraries path\n"
> 
>                                                "(LD_LIBRARY_PATH) 
> envornment variable.\n");
> 
>    return(-1);      
> 
>    }
> 
> #endif /* XMLSEC_CRYPTO_DYNAMIC_LOADING */
> 
>  
> 
>    // Init crypto library
> 
>    if(xmlSecCryptoAppInit(NULL) < 0) {
> 
>       fprintf(stderr, "Error: crypto initialization failed.\n");
> 
>       return(-1);
> 
>    }
> 
>  
> 
>    // Init xmlsec-crypto library
> 
>    if(xmlSecCryptoInit() < 0) {
> 
>    fprintf(stderr, "Error: xmlsec-crypto initialization failed.\n");
> 
>    return(-1);
> 
>    }
> 
>                               
> 
>    return 0;
> 
> }
> 
>  
> 
> void
> 
> fnit_allxml_lib()
> 
> {
> 
>    // Shutdown xmlsec-crypto library
> 
>    xmlSecCryptoShutdown();
> 
>    
> 
>    //Shutdown crypto library
> 
>    xmlSecCryptoAppShutdown();
> 
>    
> 
>    //Shutdown xmlsec library
> 
>    xmlSecShutdown();
> 
>  
> 
>    // Shutdown libxslt/libxml
> 
> #ifndef XMLSEC_NO_XSLT
> 
>    xsltCleanupGlobals();           
> 
> #endif //XMLSEC_NO_XSLT
> 
>  
> 
>    xmlCleanupParser();
> 
> }
> 
>  
> 
> const std::string XML_FILE =
>
"/Projects/project.dokfile.vses/hades/trunk/products/doksafe/engine/libs/xml
dsig/test/"
> 
>                              "mt-embedded-id-dtd-attr.xml";
> 
>

> // "mt.xml";
> 
>  
> 
> // Unit Tests
> 
>  
> 
> void do_0()
> 
> {
> 
>    xmlSecKeysMngrPtr mngr = xmlSecKeysMngrCreate();
> 
>    if(mngr == NULL)
> 
>    {
> 
>       fprintf(stderr, "Error: failed to create keys manager.\n");
> 
>    }
> 
>                
> 
>    if(xmlSecCryptoAppDefaultKeysMngrInit(mngr) < 0)
> 
>    {
> 
>       fprintf(stderr, "Error: failed to initialize keys manager.\n");
> 
>       xmlSecKeysMngrDestroy(mngr);
> 
>    }
> 
>                
> 
>    BOOST_CHECK(init_allxml_lib() == 0);
> 
>    BOOST_CHECK(verify_file(mngr, XML_FILE.c_str()) == 0);
> 
>   
> 
>    fnit_allxml_lib();
> 
> }
> 
>  
> 
> // -
> 
>  
> 
> int test_main(int, char*[])
> 
> {
> 
>    do_0();
> 
>  
> 
>    return 0;
> 
> }
> 
>  
> 
>  
> 
>  
> 
>  
> 
> Thanks
> 
>  
> 
>  
> 
>  
> 
>  
> 
>  
> 
>  
> 
>  
> 
>  
> 
>  
> 
> 
> 
> _______________________________________________
> xmlsec mailing list
> xmlsec at aleksey.com
> http://www.aleksey.com/mailman/listinfo/xmlsec
-------------- next part --------------
A non-text attachment was scrubbed...
Name: mt-embedded-id-dtd-attr.xml
Type: text/xml
Size: 7527 bytes
Desc: not available
URL: <http://www.aleksey.com/pipermail/xmlsec/attachments/20120611/dd726390/attachment-0001.xml>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: xmldsig_test.cpp
URL: <http://www.aleksey.com/pipermail/xmlsec/attachments/20120611/dd726390/attachment-0001.ksh>

From aleksey at aleksey.com  Mon Jun 11 09:22:18 2012
From: aleksey at aleksey.com (Aleksey Sanin)
Date: Mon, 11 Jun 2012 09:22:18 -0700
Subject: [xmlsec] RES:  how verify sig using xmlAddID and local certs!
In-Reply-To: <007c01cd47db$e3ad0770$ab071650$@acm.org>
References: <007101cd47cf$39abb890$ad0329b0$@acm.org>
 <4FD5F6B4.3010605@aleksey.com> <007c01cd47db$e3ad0770$ab071650$@acm.org>
Message-ID: <4FD61B3A.7010403@aleksey.com>

xmlsec1 --help

Aleksey

On 6/11/12 7:09 AM, Renato Tegon Forti wrote:
> Hi
> 
>>>  xmlAddID - look at LibXML2 documentation for the function, it's pretty
> simple.
> OK
> 
>>> Actually default trusted certs are loaded in the xmlsec-openssl init
> function.
> Then I don't need load certs in "xmlSecKeysMngrPtr"?
> 
> I am trying to use sample "Verifying a signature with X 509 certificates."
> 
> And I changed load_trusted_certs  to accept a vector with keys file, like:
> 
> ----------------------------------------------------------------------------
> ---------------------------------
> std::vector<std::string> certs;
>    
> certs.push_back("/usr/lib/ssl/certs/Serasa_Certificadora_Digital_v2.pem");
> certs.push_back("/usr/lib/ssl/certs/Serasa_Autoridade_Certificadora_Principa
> l_v2.pem");
> certs.push_back("/usr/lib/ssl/certs/Autoridade_Certificadora_Raiz_Brasileira
> _v2.pem");
> 	
> mngr = load_trusted_certs(certs);
> 
> ----------------------------------------------------------------------------
> ---------------------------------
> 
> And for now, I using DTD on xml file:
> 
> ----------------------------------------------------------------------------
> ---------------------------------
> <?xml version="1.0" encoding="UTF-8"?><!DOCTYPE test [
> <!ATTLIST infNFe Id ID #IMPLIED>
> ]>
> ----------------------------------------------------------------------------
> ---------------------------------
> 
> But always I received: "Signature is INVALID"!
> 
> If I use xmlsec1 command, its work in some file!
> 
> ----------------------------------------------------------------------------
> ---------------------------------
> afe/engine/libs/xmldsig/test$ xmlsec1 --verify mt-embedded-id-dtd-attr.xml
> OK
> SignedInfo References (ok/all): 1/1
> Manifests References (ok/all): 0/0
> ----------------------------------------------------------------------------
> ---------------------------------
> 
> How I can print debug into to try see what's happening?
> 
> My current code, and file that I need check is attached!
> 
> Thanks again, and again, and again ...!
> 
> -----Mensagem original-----
> De: Aleksey Sanin [mailto:aleksey at aleksey.com] 
> Enviada em: segunda-feira, 11 de junho de 2012 10:46
> Para: Renato Tegon Forti
> Cc: xmlsec at aleksey.com
> Assunto: Re: [xmlsec] how verify sig using xmlAddID and local certs!
> 
> 1) xmlAddID - look at LibXML2 documentation for the function, it's pretty
> simple.
> 
> 2) Actually default trusted certs are loaded in the xmlsec-openssl init
> function.
> 
> Aleksey
> 
> On 6/11/12 5:39 AM, Renato Tegon Forti wrote:
>> Hi All,
>>
>>  
>>
>> I'm trying to understand how the xmlsec tool interprets this command:
>>
>>  
>>
>> xmlsec1 --verify --id-attr:Id infNFe file.xml
>>
>>  
>>
>> which parts of code are activated! Need to reproduce this behavior in 
>> my code
>>
>>  
>>
>> Can someone explain to me?
>>
>>  
>>
>> In special how "xmlSecAppLoadKeys" load CA 's files of 
>> /usr/lib/ssl/certs/ : (for sample. openssl  ssl files folder) !
>>
>>  
>>
>> I need use "xmlAddID" to add "infNFe" like an id! Ok? How?
>>
>>  
>>
>> Anything else!
>>
>>  
>>
>> My test code:
>>
>>  
>>
>> // Copyright 2011-2012 Renato Tegon Forti
>>
>>  
>>
>> #define BOOST_ALL_DYN_LINK
>>
>> #define BOOST_THREAD_USE_DLL  //thread header not compliant with 
>> 'BOOST_ALL_DYN_LINK'
>>
>> #define BOOST_LIB_DIAGNOSTIC
>>
>>  
>>
>> #include <boost/test/minimal.hpp>
>>
>> #include <dsafe/xmlsig.hpp>
>>
>>  
>>
>> #define XMLSEC_CRYPTO_OPENSSL
>>
>>  
>>
>> #include <libxml/tree.h>
>>
>> #include <libxml/xmlmemory.h>
>>
>> #include <libxml/parser.h>
>>
>>  
>>
>> #ifndef XMLSEC_NO_XSLT
>>
>> #include <libxslt/xslt.h>
>>
>> #endif /* XMLSEC_NO_XSLT */
>>
>>  
>>
>> #include <xmlsec/xmlsec.h>
>>
>> #include <xmlsec/xmltree.h>
>>
>> #include <xmlsec/xmldsig.h>
>>
>> #include <xmlsec/xmlenc.h>
>>
>> #include <xmlsec/templates.h>
>>
>> #include <xmlsec/crypto.h>
>>
>>  
>>
>>  
>>
>> /**
>>
>>  * verify_file:
>>
>> * @mngr:                              the pointer to keys manager.
>>
>> * @xml_file:                    the signed XML file name.
>>
>> *
>>
>> * Verifies XML signature in #xml_file.
>>
>> *
>>
>> * Returns 0 on success or a negative value if an error occurs.
>>
>> */
>>
>> int
>>
>> verify_file(xmlSecKeysMngrPtr mngr, const char* xml_file)
>>
>> {
>>
>>    xmlDocPtr doc = NULL;
>>
>>    xmlNodePtr node = NULL;
>>
>>    xmlSecDSigCtxPtr dsigCtx = NULL;
>>
>>     int res = -1;
>>
>>    
>>
>>     assert(mngr);
>>
>>     assert(xml_file);
>>
>>  
>>
>>     /* load file */
>>
>>     doc = xmlParseFile(xml_file);
>>
>>     if ((doc == NULL) || (xmlDocGetRootElement(doc) == NULL)){
>>
>>                 fprintf(stderr, "Error: unable to parse file 
>> \"%s\"\n", xml_file);
>>
>>                 goto done;        
>>
>>     }
>>
>>    
>>
>>     /* find start node */
>>
>>     node = xmlSecFindNode(xmlDocGetRootElement(doc),
>> xmlSecNodeSignature, xmlSecDSigNs);
>>
>>     if(node == NULL) {
>>
>>                 fprintf(stderr, "Error: start node not found in 
>> \"%s\"\n", xml_file);
>>
>>                 goto done;        
>>
>>     }
>>
>>  
>>
>>     /* create signature context */
>>
>>     dsigCtx = xmlSecDSigCtxCreate(mngr);
>>
>>     if(dsigCtx == NULL) {
>>
>>         fprintf(stderr,"Error: failed to create signature context\n");
>>
>>                 goto done;
>>
>>     }
>>
>>                
>>
>>  
>>
>>    
>>
>>  
>>
>>     /* limit the Reference URI attributes to empty or NULL */
>>
>>     dsigCtx->enabledReferenceUris = xmlSecTransformUriTypeEmpty;
>>
>>    
>>
>>     /* limit allowed transforms for siganture and reference processing 
>> */
>>
>>     if((xmlSecDSigCtxEnableSignatureTransform(dsigCtx,
>> xmlSecTransformInclC14NId) < 0) ||
>>
>>        (xmlSecDSigCtxEnableSignatureTransform(dsigCtx,
>> xmlSecTransformExclC14NId) < 0) ||
>>
>>        (xmlSecDSigCtxEnableSignatureTransform(dsigCtx,
>> xmlSecTransformSha1Id) < 0) ||
>>
>>        (xmlSecDSigCtxEnableSignatureTransform(dsigCtx,
>> xmlSecTransformRsaSha1Id) < 0)) {
>>
>>  
>>
>>         fprintf(stderr,"Error: failed to limit allowed siganture 
>> transforms\n");
>>
>>                 goto done;
>>
>>     }
>>
>>     if((xmlSecDSigCtxEnableReferenceTransform(dsigCtx,
>> xmlSecTransformInclC14NId) < 0) ||
>>
>>        (xmlSecDSigCtxEnableReferenceTransform(dsigCtx,
>> xmlSecTransformExclC14NId) < 0) ||
>>
>>        (xmlSecDSigCtxEnableReferenceTransform(dsigCtx,
>> xmlSecTransformSha1Id) < 0) ||
>>
>>        (xmlSecDSigCtxEnableReferenceTransform(dsigCtx,
>> xmlSecTransformEnvelopedId) < 0)) {
>>
>>  
>>
>>         fprintf(stderr,"Error: failed to limit allowed reference 
>> transforms\n");
>>
>>                 goto done;
>>
>>     }
>>
>>  
>>
>>     /* in addition, limit possible key data to valid X509 certificates 
>> only */
>>
>>     if(xmlSecPtrListAdd(&(dsigCtx->keyInfoReadCtx.enabledKeyData),
>> BAD_CAST xmlSecKeyDataX509Id) < 0) {
>>
>>         fprintf(stderr,"Error: failed to limit allowed key data\n");
>>
>>                 goto done;
>>
>>     }
>>
>>    
>>
>>     /* Verify signature */
>>
>>     if(xmlSecDSigCtxVerify(dsigCtx, node) < 0) {
>>
>>         fprintf(stderr,"Error: signature verify\n");
>>
>>                 goto done;
>>
>>     }
>>
>>  
>>
>>     /* check that we have only one Reference */
>>
>>     if((dsigCtx->status == xmlSecDSigStatusSucceeded) &&
>>
>>         (xmlSecPtrListGetSize(&(dsigCtx->signedInfoReferences)) != 1)) 
>> {
>>
>>                
>>
>>         fprintf(stderr,"Error: only one reference is allowed\n");
>>
>>                 goto done;
>>
>>     }
>>
>>        
>>
>>     /* print verification result to stdout */
>>
>>     if(dsigCtx->status == xmlSecDSigStatusSucceeded) {
>>
>>                 fprintf(stdout, "Signature is OK\n");
>>
>>     } else {
>>
>>                 fprintf(stdout, "Signature is INVALID\n");
>>
>>     }   
>>
>>  
>>
>>     /* success */
>>
>>     res = 0;
>>
>>  
>>
>> done:   
>>
>>     /* cleanup */
>>
>>     if(dsigCtx != NULL) {
>>
>>                 xmlSecDSigCtxDestroy(dsigCtx);
>>
>>     }
>>
>>    
>>
>>     if(doc != NULL) {
>>
>>                 xmlFreeDoc(doc);
>>
>>     }
>>
>>     return(res);
>>
>>  
>>
>> }
>>
>>  
>>
>> int
>>
>> init_allxml_lib()
>>
>> {   
>>
>>    // Init libxml and libxslt libraries
>>
>>    xmlInitParser();
>>
>>   
>>
>>    LIBXML_TEST_VERSION
>>
>>    xmlLoadExtDtdDefaultValue = XML_DETECT_IDS | XML_COMPLETE_ATTRS;
>>
>>    xmlSubstituteEntitiesDefault(1);
>>
>> #ifndef XMLSEC_NO_XSLT
>>
>>    xmlIndentTreeOutput = 1;
>>
>> #endif // XMLSEC_NO_XSLT
>>
>>                
>>
>>    // Init xmlsec library
>>
>>    if(xmlSecInit() < 0) {
>>
>>    fprintf(stderr, "Error: xmlsec initialization failed.\n");
>>
>>    return(-1);
>>
>>    }
>>
>>  
>>
>>    // Check loaded library version
>>
>>    if(xmlSecCheckVersion() != 1) {
>>
>>    fprintf(stderr, "Error: loaded xmlsec library version is not 
>> compatible.\n");
>>
>>    return(-1);
>>
>>    }   
>>
>>    
>>
>>    // Load default crypto engine if we are supporting dynamic
>>
>>    // loading for xmlsec-crypto libraries. Use the crypto library
>>
>>    // name ("openssl", "nss", etc.) to load corresponding
>>
>>    // xmlsec-crypto library.
>>
>>  
>>
>> #ifdef XMLSEC_CRYPTO_DYNAMIC_LOADING
>>
>>    if(xmlSecCryptoDLLoadLibrary(BAD_CAST XMLSEC_CRYPTO) < 0) {
>>
>>    fprintf(stderr, "Error: unable to load default xmlsec-crypto library.
>> Make sure\n"
>>
>>                                                "that you have it 
>> installed and check shared libraries path\n"
>>
>>                                                "(LD_LIBRARY_PATH) 
>> envornment variable.\n");
>>
>>    return(-1);      
>>
>>    }
>>
>> #endif /* XMLSEC_CRYPTO_DYNAMIC_LOADING */
>>
>>  
>>
>>    // Init crypto library
>>
>>    if(xmlSecCryptoAppInit(NULL) < 0) {
>>
>>       fprintf(stderr, "Error: crypto initialization failed.\n");
>>
>>       return(-1);
>>
>>    }
>>
>>  
>>
>>    // Init xmlsec-crypto library
>>
>>    if(xmlSecCryptoInit() < 0) {
>>
>>    fprintf(stderr, "Error: xmlsec-crypto initialization failed.\n");
>>
>>    return(-1);
>>
>>    }
>>
>>                               
>>
>>    return 0;
>>
>> }
>>
>>  
>>
>> void
>>
>> fnit_allxml_lib()
>>
>> {
>>
>>    // Shutdown xmlsec-crypto library
>>
>>    xmlSecCryptoShutdown();
>>
>>    
>>
>>    //Shutdown crypto library
>>
>>    xmlSecCryptoAppShutdown();
>>
>>    
>>
>>    //Shutdown xmlsec library
>>
>>    xmlSecShutdown();
>>
>>  
>>
>>    // Shutdown libxslt/libxml
>>
>> #ifndef XMLSEC_NO_XSLT
>>
>>    xsltCleanupGlobals();           
>>
>> #endif //XMLSEC_NO_XSLT
>>
>>  
>>
>>    xmlCleanupParser();
>>
>> }
>>
>>  
>>
>> const std::string XML_FILE =
>>
> "/Projects/project.dokfile.vses/hades/trunk/products/doksafe/engine/libs/xml
> dsig/test/"
>>
>>                              "mt-embedded-id-dtd-attr.xml";
>>
>>
> 
>> // "mt.xml";
>>
>>  
>>
>> // Unit Tests
>>
>>  
>>
>> void do_0()
>>
>> {
>>
>>    xmlSecKeysMngrPtr mngr = xmlSecKeysMngrCreate();
>>
>>    if(mngr == NULL)
>>
>>    {
>>
>>       fprintf(stderr, "Error: failed to create keys manager.\n");
>>
>>    }
>>
>>                
>>
>>    if(xmlSecCryptoAppDefaultKeysMngrInit(mngr) < 0)
>>
>>    {
>>
>>       fprintf(stderr, "Error: failed to initialize keys manager.\n");
>>
>>       xmlSecKeysMngrDestroy(mngr);
>>
>>    }
>>
>>                
>>
>>    BOOST_CHECK(init_allxml_lib() == 0);
>>
>>    BOOST_CHECK(verify_file(mngr, XML_FILE.c_str()) == 0);
>>
>>   
>>
>>    fnit_allxml_lib();
>>
>> }
>>
>>  
>>
>> // -
>>
>>  
>>
>> int test_main(int, char*[])
>>
>> {
>>
>>    do_0();
>>
>>  
>>
>>    return 0;
>>
>> }
>>
>>  
>>
>>  
>>
>>  
>>
>>  
>>
>> Thanks
>>
>>  
>>
>>  
>>
>>  
>>
>>  
>>
>>  
>>
>>  
>>
>>  
>>
>>  
>>
>>  
>>
>>
>>
>> _______________________________________________
>> xmlsec mailing list
>> xmlsec at aleksey.com
>> http://www.aleksey.com/mailman/listinfo/xmlsec

From re.tf at acm.org  Mon Jun 11 11:40:20 2012
From: re.tf at acm.org (Renato Tegon Forti)
Date: Mon, 11 Jun 2012 15:40:20 -0300
Subject: [xmlsec] RES: RES: how verify sig using xmlAddID and local certs!
In-Reply-To: <4FD61B3A.7010403@aleksey.com>
References: <007101cd47cf$39abb890$ad0329b0$@acm.org>
 <4FD5F6B4.3010605@aleksey.com> <007c01cd47db$e3ad0770$ab071650$@acm.org>
 <4FD61B3A.7010403@aleksey.com>
Message-ID: <009e01cd4801$a925b400$fb711c00$@acm.org>

Hi Again,

I write one new code, but I can put it to work! Please you can point me what
I forgot! 

The verify function is : verify_f

Output:

========================================================================
verify_f
========================================================================
Signature is ***INVALID***
func=xmlSecDSigCtxDebugXmlDump:file=xmldsig.c:line=1148:obj=unknown:subj=out
put != NULL:error=100:assertion:
func=xmlSecDSigCtxDebugDump:file=xmldsig.c:line=1068:obj=unknown:subj=output
!= NULL:error=100:assertion:

Thanks

-----Mensagem original-----
De: Aleksey Sanin [mailto:aleksey at aleksey.com] 
Enviada em: segunda-feira, 11 de junho de 2012 13:22
Para: Renato Tegon Forti
Cc: xmlsec at aleksey.com
Assunto: Re: RES: [xmlsec] how verify sig using xmlAddID and local certs!

xmlsec1 --help

Aleksey

On 6/11/12 7:09 AM, Renato Tegon Forti wrote:
> Hi
> 
>>>  xmlAddID - look at LibXML2 documentation for the function, it's 
>>> pretty
> simple.
> OK
> 
>>> Actually default trusted certs are loaded in the xmlsec-openssl init
> function.
> Then I don't need load certs in "xmlSecKeysMngrPtr"?
> 
> I am trying to use sample "Verifying a signature with X 509 certificates."
> 
> And I changed load_trusted_certs  to accept a vector with keys file, like:
> 
> ----------------------------------------------------------------------
> ------
> ---------------------------------
> std::vector<std::string> certs;
>    
> certs.push_back("/usr/lib/ssl/certs/Serasa_Certificadora_Digital_v2.pe
> m"); 
> certs.push_back("/usr/lib/ssl/certs/Serasa_Autoridade_Certificadora_Pr
> incipa
> l_v2.pem");
> certs.push_back("/usr/lib/ssl/certs/Autoridade_Certificadora_Raiz_Bras
> ileira
> _v2.pem");
> 	
> mngr = load_trusted_certs(certs);
> 
> ----------------------------------------------------------------------
> ------
> ---------------------------------
> 
> And for now, I using DTD on xml file:
> 
> ----------------------------------------------------------------------
> ------
> ---------------------------------
> <?xml version="1.0" encoding="UTF-8"?><!DOCTYPE test [ <!ATTLIST 
> infNFe Id ID #IMPLIED> ]>
> ----------------------------------------------------------------------
> ------
> ---------------------------------
> 
> But always I received: "Signature is INVALID"!
> 
> If I use xmlsec1 command, its work in some file!
> 
> ----------------------------------------------------------------------
> ------
> ---------------------------------
> afe/engine/libs/xmldsig/test$ xmlsec1 --verify 
> mt-embedded-id-dtd-attr.xml OK SignedInfo References (ok/all): 1/1 
> Manifests References (ok/all): 0/0
> ----------------------------------------------------------------------
> ------
> ---------------------------------
> 
> How I can print debug into to try see what's happening?
> 
> My current code, and file that I need check is attached!
> 
> Thanks again, and again, and again ...!
> 
> -----Mensagem original-----
> De: Aleksey Sanin [mailto:aleksey at aleksey.com] Enviada em: 
> segunda-feira, 11 de junho de 2012 10:46
> Para: Renato Tegon Forti
> Cc: xmlsec at aleksey.com
> Assunto: Re: [xmlsec] how verify sig using xmlAddID and local certs!
> 
> 1) xmlAddID - look at LibXML2 documentation for the function, it's 
> pretty simple.
> 
> 2) Actually default trusted certs are loaded in the xmlsec-openssl 
> init function.
> 
> Aleksey
> 
> On 6/11/12 5:39 AM, Renato Tegon Forti wrote:
>> Hi All,
>>
>>  
>>
>> I'm trying to understand how the xmlsec tool interprets this command:
>>
>>  
>>
>> xmlsec1 --verify --id-attr:Id infNFe file.xml
>>
>>  
>>
>> which parts of code are activated! Need to reproduce this behavior in 
>> my code
>>
>>  
>>
>> Can someone explain to me?
>>
>>  
>>
>> In special how "xmlSecAppLoadKeys" load CA 's files of 
>> /usr/lib/ssl/certs/ : (for sample. openssl  ssl files folder) !
>>
>>  
>>
>> I need use "xmlAddID" to add "infNFe" like an id! Ok? How?
>>
>>  
>>
>> Anything else!
>>
>>  
>>
>> My test code:
>>
>>  
>>
>> // Copyright 2011-2012 Renato Tegon Forti
>>
>>  
>>
>> #define BOOST_ALL_DYN_LINK
>>
>> #define BOOST_THREAD_USE_DLL  //thread header not compliant with 
>> 'BOOST_ALL_DYN_LINK'
>>
>> #define BOOST_LIB_DIAGNOSTIC
>>
>>  
>>
>> #include <boost/test/minimal.hpp>
>>
>> #include <dsafe/xmlsig.hpp>
>>
>>  
>>
>> #define XMLSEC_CRYPTO_OPENSSL
>>
>>  
>>
>> #include <libxml/tree.h>
>>
>> #include <libxml/xmlmemory.h>
>>
>> #include <libxml/parser.h>
>>
>>  
>>
>> #ifndef XMLSEC_NO_XSLT
>>
>> #include <libxslt/xslt.h>
>>
>> #endif /* XMLSEC_NO_XSLT */
>>
>>  
>>
>> #include <xmlsec/xmlsec.h>
>>
>> #include <xmlsec/xmltree.h>
>>
>> #include <xmlsec/xmldsig.h>
>>
>> #include <xmlsec/xmlenc.h>
>>
>> #include <xmlsec/templates.h>
>>
>> #include <xmlsec/crypto.h>
>>
>>  
>>
>>  
>>
>> /**
>>
>>  * verify_file:
>>
>> * @mngr:                              the pointer to keys manager.
>>
>> * @xml_file:                    the signed XML file name.
>>
>> *
>>
>> * Verifies XML signature in #xml_file.
>>
>> *
>>
>> * Returns 0 on success or a negative value if an error occurs.
>>
>> */
>>
>> int
>>
>> verify_file(xmlSecKeysMngrPtr mngr, const char* xml_file)
>>
>> {
>>
>>    xmlDocPtr doc = NULL;
>>
>>    xmlNodePtr node = NULL;
>>
>>    xmlSecDSigCtxPtr dsigCtx = NULL;
>>
>>     int res = -1;
>>
>>    
>>
>>     assert(mngr);
>>
>>     assert(xml_file);
>>
>>  
>>
>>     /* load file */
>>
>>     doc = xmlParseFile(xml_file);
>>
>>     if ((doc == NULL) || (xmlDocGetRootElement(doc) == NULL)){
>>
>>                 fprintf(stderr, "Error: unable to parse file 
>> \"%s\"\n", xml_file);
>>
>>                 goto done;        
>>
>>     }
>>
>>    
>>
>>     /* find start node */
>>
>>     node = xmlSecFindNode(xmlDocGetRootElement(doc),
>> xmlSecNodeSignature, xmlSecDSigNs);
>>
>>     if(node == NULL) {
>>
>>                 fprintf(stderr, "Error: start node not found in 
>> \"%s\"\n", xml_file);
>>
>>                 goto done;        
>>
>>     }
>>
>>  
>>
>>     /* create signature context */
>>
>>     dsigCtx = xmlSecDSigCtxCreate(mngr);
>>
>>     if(dsigCtx == NULL) {
>>
>>         fprintf(stderr,"Error: failed to create signature 
>> context\n");
>>
>>                 goto done;
>>
>>     }
>>
>>                
>>
>>  
>>
>>    
>>
>>  
>>
>>     /* limit the Reference URI attributes to empty or NULL */
>>
>>     dsigCtx->enabledReferenceUris = xmlSecTransformUriTypeEmpty;
>>
>>    
>>
>>     /* limit allowed transforms for siganture and reference 
>> processing */
>>
>>     if((xmlSecDSigCtxEnableSignatureTransform(dsigCtx,
>> xmlSecTransformInclC14NId) < 0) ||
>>
>>        (xmlSecDSigCtxEnableSignatureTransform(dsigCtx,
>> xmlSecTransformExclC14NId) < 0) ||
>>
>>        (xmlSecDSigCtxEnableSignatureTransform(dsigCtx,
>> xmlSecTransformSha1Id) < 0) ||
>>
>>        (xmlSecDSigCtxEnableSignatureTransform(dsigCtx,
>> xmlSecTransformRsaSha1Id) < 0)) {
>>
>>  
>>
>>         fprintf(stderr,"Error: failed to limit allowed siganture 
>> transforms\n");
>>
>>                 goto done;
>>
>>     }
>>
>>     if((xmlSecDSigCtxEnableReferenceTransform(dsigCtx,
>> xmlSecTransformInclC14NId) < 0) ||
>>
>>        (xmlSecDSigCtxEnableReferenceTransform(dsigCtx,
>> xmlSecTransformExclC14NId) < 0) ||
>>
>>        (xmlSecDSigCtxEnableReferenceTransform(dsigCtx,
>> xmlSecTransformSha1Id) < 0) ||
>>
>>        (xmlSecDSigCtxEnableReferenceTransform(dsigCtx,
>> xmlSecTransformEnvelopedId) < 0)) {
>>
>>  
>>
>>         fprintf(stderr,"Error: failed to limit allowed reference 
>> transforms\n");
>>
>>                 goto done;
>>
>>     }
>>
>>  
>>
>>     /* in addition, limit possible key data to valid X509 
>> certificates only */
>>
>>     if(xmlSecPtrListAdd(&(dsigCtx->keyInfoReadCtx.enabledKeyData),
>> BAD_CAST xmlSecKeyDataX509Id) < 0) {
>>
>>         fprintf(stderr,"Error: failed to limit allowed key data\n");
>>
>>                 goto done;
>>
>>     }
>>
>>    
>>
>>     /* Verify signature */
>>
>>     if(xmlSecDSigCtxVerify(dsigCtx, node) < 0) {
>>
>>         fprintf(stderr,"Error: signature verify\n");
>>
>>                 goto done;
>>
>>     }
>>
>>  
>>
>>     /* check that we have only one Reference */
>>
>>     if((dsigCtx->status == xmlSecDSigStatusSucceeded) &&
>>
>>         (xmlSecPtrListGetSize(&(dsigCtx->signedInfoReferences)) != 
>> 1)) {
>>
>>                
>>
>>         fprintf(stderr,"Error: only one reference is allowed\n");
>>
>>                 goto done;
>>
>>     }
>>
>>        
>>
>>     /* print verification result to stdout */
>>
>>     if(dsigCtx->status == xmlSecDSigStatusSucceeded) {
>>
>>                 fprintf(stdout, "Signature is OK\n");
>>
>>     } else {
>>
>>                 fprintf(stdout, "Signature is INVALID\n");
>>
>>     }   
>>
>>  
>>
>>     /* success */
>>
>>     res = 0;
>>
>>  
>>
>> done:   
>>
>>     /* cleanup */
>>
>>     if(dsigCtx != NULL) {
>>
>>                 xmlSecDSigCtxDestroy(dsigCtx);
>>
>>     }
>>
>>    
>>
>>     if(doc != NULL) {
>>
>>                 xmlFreeDoc(doc);
>>
>>     }
>>
>>     return(res);
>>
>>  
>>
>> }
>>
>>  
>>
>> int
>>
>> init_allxml_lib()
>>
>> {   
>>
>>    // Init libxml and libxslt libraries
>>
>>    xmlInitParser();
>>
>>   
>>
>>    LIBXML_TEST_VERSION
>>
>>    xmlLoadExtDtdDefaultValue = XML_DETECT_IDS | XML_COMPLETE_ATTRS;
>>
>>    xmlSubstituteEntitiesDefault(1);
>>
>> #ifndef XMLSEC_NO_XSLT
>>
>>    xmlIndentTreeOutput = 1;
>>
>> #endif // XMLSEC_NO_XSLT
>>
>>                
>>
>>    // Init xmlsec library
>>
>>    if(xmlSecInit() < 0) {
>>
>>    fprintf(stderr, "Error: xmlsec initialization failed.\n");
>>
>>    return(-1);
>>
>>    }
>>
>>  
>>
>>    // Check loaded library version
>>
>>    if(xmlSecCheckVersion() != 1) {
>>
>>    fprintf(stderr, "Error: loaded xmlsec library version is not 
>> compatible.\n");
>>
>>    return(-1);
>>
>>    }   
>>
>>    
>>
>>    // Load default crypto engine if we are supporting dynamic
>>
>>    // loading for xmlsec-crypto libraries. Use the crypto library
>>
>>    // name ("openssl", "nss", etc.) to load corresponding
>>
>>    // xmlsec-crypto library.
>>
>>  
>>
>> #ifdef XMLSEC_CRYPTO_DYNAMIC_LOADING
>>
>>    if(xmlSecCryptoDLLoadLibrary(BAD_CAST XMLSEC_CRYPTO) < 0) {
>>
>>    fprintf(stderr, "Error: unable to load default xmlsec-crypto library.
>> Make sure\n"
>>
>>                                                "that you have it 
>> installed and check shared libraries path\n"
>>
>>                                                "(LD_LIBRARY_PATH) 
>> envornment variable.\n");
>>
>>    return(-1);      
>>
>>    }
>>
>> #endif /* XMLSEC_CRYPTO_DYNAMIC_LOADING */
>>
>>  
>>
>>    // Init crypto library
>>
>>    if(xmlSecCryptoAppInit(NULL) < 0) {
>>
>>       fprintf(stderr, "Error: crypto initialization failed.\n");
>>
>>       return(-1);
>>
>>    }
>>
>>  
>>
>>    // Init xmlsec-crypto library
>>
>>    if(xmlSecCryptoInit() < 0) {
>>
>>    fprintf(stderr, "Error: xmlsec-crypto initialization failed.\n");
>>
>>    return(-1);
>>
>>    }
>>
>>                               
>>
>>    return 0;
>>
>> }
>>
>>  
>>
>> void
>>
>> fnit_allxml_lib()
>>
>> {
>>
>>    // Shutdown xmlsec-crypto library
>>
>>    xmlSecCryptoShutdown();
>>
>>    
>>
>>    //Shutdown crypto library
>>
>>    xmlSecCryptoAppShutdown();
>>
>>    
>>
>>    //Shutdown xmlsec library
>>
>>    xmlSecShutdown();
>>
>>  
>>
>>    // Shutdown libxslt/libxml
>>
>> #ifndef XMLSEC_NO_XSLT
>>
>>    xsltCleanupGlobals();           
>>
>> #endif //XMLSEC_NO_XSLT
>>
>>  
>>
>>    xmlCleanupParser();
>>
>> }
>>
>>  
>>
>> const std::string XML_FILE =
>>
> "/Projects/project.dokfile.vses/hades/trunk/products/doksafe/engine/li
> bs/xml
> dsig/test/"
>>
>>                              "mt-embedded-id-dtd-attr.xml";
>>
>>
> 
>> // "mt.xml";
>>
>>  
>>
>> // Unit Tests
>>
>>  
>>
>> void do_0()
>>
>> {
>>
>>    xmlSecKeysMngrPtr mngr = xmlSecKeysMngrCreate();
>>
>>    if(mngr == NULL)
>>
>>    {
>>
>>       fprintf(stderr, "Error: failed to create keys manager.\n");
>>
>>    }
>>
>>                
>>
>>    if(xmlSecCryptoAppDefaultKeysMngrInit(mngr) < 0)
>>
>>    {
>>
>>       fprintf(stderr, "Error: failed to initialize keys manager.\n");
>>
>>       xmlSecKeysMngrDestroy(mngr);
>>
>>    }
>>
>>                
>>
>>    BOOST_CHECK(init_allxml_lib() == 0);
>>
>>    BOOST_CHECK(verify_file(mngr, XML_FILE.c_str()) == 0);
>>
>>   
>>
>>    fnit_allxml_lib();
>>
>> }
>>
>>  
>>
>> // -
>>
>>  
>>
>> int test_main(int, char*[])
>>
>> {
>>
>>    do_0();
>>
>>  
>>
>>    return 0;
>>
>> }
>>
>>  
>>
>>  
>>
>>  
>>
>>  
>>
>> Thanks
>>
>>  
>>
>>  
>>
>>  
>>
>>  
>>
>>  
>>
>>  
>>
>>  
>>
>>  
>>
>>  
>>
>>
>>
>> _______________________________________________
>> xmlsec mailing list
>> xmlsec at aleksey.com
>> http://www.aleksey.com/mailman/listinfo/xmlsec
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: xmldsig_test.cpp
URL: <http://www.aleksey.com/pipermail/xmlsec/attachments/20120611/75c7f34f/attachment-0001.ksh>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: mt-embedded-id-dtd-attr.xml
Type: text/xml
Size: 7527 bytes
Desc: not available
URL: <http://www.aleksey.com/pipermail/xmlsec/attachments/20120611/75c7f34f/attachment-0001.xml>

From aleksey at aleksey.com  Mon Jun 11 11:46:00 2012
From: aleksey at aleksey.com (Aleksey Sanin)
Date: Mon, 11 Jun 2012 11:46:00 -0700
Subject: [xmlsec] RES: RES: how verify sig using xmlAddID and local
	certs!
In-Reply-To: <009e01cd4801$a925b400$fb711c00$@acm.org>
References: <007101cd47cf$39abb890$ad0329b0$@acm.org>
 <4FD5F6B4.3010605@aleksey.com> <007c01cd47db$e3ad0770$ab071650$@acm.org>
 <4FD61B3A.7010403@aleksey.com> <009e01cd4801$a925b400$fb711c00$@acm.org>
Message-ID: <4FD63CE8.7070601@aleksey.com>

I am really sorry but this goes beyond the support I provide.

Aleksey


On 6/11/12 11:40 AM, Renato Tegon Forti wrote:
> Hi Again,
> 
> I write one new code, but I can put it to work! Please you can point me what
> I forgot! 
> 
> The verify function is : verify_f
> 
> Output:
> 
> ========================================================================
> verify_f
> ========================================================================
> Signature is ***INVALID***
> func=xmlSecDSigCtxDebugXmlDump:file=xmldsig.c:line=1148:obj=unknown:subj=out
> put != NULL:error=100:assertion:
> func=xmlSecDSigCtxDebugDump:file=xmldsig.c:line=1068:obj=unknown:subj=output
> != NULL:error=100:assertion:
> 
> Thanks
> 
> -----Mensagem original-----
> De: Aleksey Sanin [mailto:aleksey at aleksey.com] 
> Enviada em: segunda-feira, 11 de junho de 2012 13:22
> Para: Renato Tegon Forti
> Cc: xmlsec at aleksey.com
> Assunto: Re: RES: [xmlsec] how verify sig using xmlAddID and local certs!
> 
> xmlsec1 --help
> 
> Aleksey
> 
> On 6/11/12 7:09 AM, Renato Tegon Forti wrote:
>> Hi
>>
>>>>  xmlAddID - look at LibXML2 documentation for the function, it's 
>>>> pretty
>> simple.
>> OK
>>
>>>> Actually default trusted certs are loaded in the xmlsec-openssl init
>> function.
>> Then I don't need load certs in "xmlSecKeysMngrPtr"?
>>
>> I am trying to use sample "Verifying a signature with X 509 certificates."
>>
>> And I changed load_trusted_certs  to accept a vector with keys file, like:
>>
>> ----------------------------------------------------------------------
>> ------
>> ---------------------------------
>> std::vector<std::string> certs;
>>    
>> certs.push_back("/usr/lib/ssl/certs/Serasa_Certificadora_Digital_v2.pe
>> m"); 
>> certs.push_back("/usr/lib/ssl/certs/Serasa_Autoridade_Certificadora_Pr
>> incipa
>> l_v2.pem");
>> certs.push_back("/usr/lib/ssl/certs/Autoridade_Certificadora_Raiz_Bras
>> ileira
>> _v2.pem");
>> 	
>> mngr = load_trusted_certs(certs);
>>
>> ----------------------------------------------------------------------
>> ------
>> ---------------------------------
>>
>> And for now, I using DTD on xml file:
>>
>> ----------------------------------------------------------------------
>> ------
>> ---------------------------------
>> <?xml version="1.0" encoding="UTF-8"?><!DOCTYPE test [ <!ATTLIST 
>> infNFe Id ID #IMPLIED> ]>
>> ----------------------------------------------------------------------
>> ------
>> ---------------------------------
>>
>> But always I received: "Signature is INVALID"!
>>
>> If I use xmlsec1 command, its work in some file!
>>
>> ----------------------------------------------------------------------
>> ------
>> ---------------------------------
>> afe/engine/libs/xmldsig/test$ xmlsec1 --verify 
>> mt-embedded-id-dtd-attr.xml OK SignedInfo References (ok/all): 1/1 
>> Manifests References (ok/all): 0/0
>> ----------------------------------------------------------------------
>> ------
>> ---------------------------------
>>
>> How I can print debug into to try see what's happening?
>>
>> My current code, and file that I need check is attached!
>>
>> Thanks again, and again, and again ...!
>>
>> -----Mensagem original-----
>> De: Aleksey Sanin [mailto:aleksey at aleksey.com] Enviada em: 
>> segunda-feira, 11 de junho de 2012 10:46
>> Para: Renato Tegon Forti
>> Cc: xmlsec at aleksey.com
>> Assunto: Re: [xmlsec] how verify sig using xmlAddID and local certs!
>>
>> 1) xmlAddID - look at LibXML2 documentation for the function, it's 
>> pretty simple.
>>
>> 2) Actually default trusted certs are loaded in the xmlsec-openssl 
>> init function.
>>
>> Aleksey
>>
>> On 6/11/12 5:39 AM, Renato Tegon Forti wrote:
>>> Hi All,
>>>
>>>  
>>>
>>> I'm trying to understand how the xmlsec tool interprets this command:
>>>
>>>  
>>>
>>> xmlsec1 --verify --id-attr:Id infNFe file.xml
>>>
>>>  
>>>
>>> which parts of code are activated! Need to reproduce this behavior in 
>>> my code
>>>
>>>  
>>>
>>> Can someone explain to me?
>>>
>>>  
>>>
>>> In special how "xmlSecAppLoadKeys" load CA 's files of 
>>> /usr/lib/ssl/certs/ : (for sample. openssl  ssl files folder) !
>>>
>>>  
>>>
>>> I need use "xmlAddID" to add "infNFe" like an id! Ok? How?
>>>
>>>  
>>>
>>> Anything else!
>>>
>>>  
>>>
>>> My test code:
>>>
>>>  
>>>
>>> // Copyright 2011-2012 Renato Tegon Forti
>>>
>>>  
>>>
>>> #define BOOST_ALL_DYN_LINK
>>>
>>> #define BOOST_THREAD_USE_DLL  //thread header not compliant with 
>>> 'BOOST_ALL_DYN_LINK'
>>>
>>> #define BOOST_LIB_DIAGNOSTIC
>>>
>>>  
>>>
>>> #include <boost/test/minimal.hpp>
>>>
>>> #include <dsafe/xmlsig.hpp>
>>>
>>>  
>>>
>>> #define XMLSEC_CRYPTO_OPENSSL
>>>
>>>  
>>>
>>> #include <libxml/tree.h>
>>>
>>> #include <libxml/xmlmemory.h>
>>>
>>> #include <libxml/parser.h>
>>>
>>>  
>>>
>>> #ifndef XMLSEC_NO_XSLT
>>>
>>> #include <libxslt/xslt.h>
>>>
>>> #endif /* XMLSEC_NO_XSLT */
>>>
>>>  
>>>
>>> #include <xmlsec/xmlsec.h>
>>>
>>> #include <xmlsec/xmltree.h>
>>>
>>> #include <xmlsec/xmldsig.h>
>>>
>>> #include <xmlsec/xmlenc.h>
>>>
>>> #include <xmlsec/templates.h>
>>>
>>> #include <xmlsec/crypto.h>
>>>
>>>  
>>>
>>>  
>>>
>>> /**
>>>
>>>  * verify_file:
>>>
>>> * @mngr:                              the pointer to keys manager.
>>>
>>> * @xml_file:                    the signed XML file name.
>>>
>>> *
>>>
>>> * Verifies XML signature in #xml_file.
>>>
>>> *
>>>
>>> * Returns 0 on success or a negative value if an error occurs.
>>>
>>> */
>>>
>>> int
>>>
>>> verify_file(xmlSecKeysMngrPtr mngr, const char* xml_file)
>>>
>>> {
>>>
>>>    xmlDocPtr doc = NULL;
>>>
>>>    xmlNodePtr node = NULL;
>>>
>>>    xmlSecDSigCtxPtr dsigCtx = NULL;
>>>
>>>     int res = -1;
>>>
>>>    
>>>
>>>     assert(mngr);
>>>
>>>     assert(xml_file);
>>>
>>>  
>>>
>>>     /* load file */
>>>
>>>     doc = xmlParseFile(xml_file);
>>>
>>>     if ((doc == NULL) || (xmlDocGetRootElement(doc) == NULL)){
>>>
>>>                 fprintf(stderr, "Error: unable to parse file 
>>> \"%s\"\n", xml_file);
>>>
>>>                 goto done;        
>>>
>>>     }
>>>
>>>    
>>>
>>>     /* find start node */
>>>
>>>     node = xmlSecFindNode(xmlDocGetRootElement(doc),
>>> xmlSecNodeSignature, xmlSecDSigNs);
>>>
>>>     if(node == NULL) {
>>>
>>>                 fprintf(stderr, "Error: start node not found in 
>>> \"%s\"\n", xml_file);
>>>
>>>                 goto done;        
>>>
>>>     }
>>>
>>>  
>>>
>>>     /* create signature context */
>>>
>>>     dsigCtx = xmlSecDSigCtxCreate(mngr);
>>>
>>>     if(dsigCtx == NULL) {
>>>
>>>         fprintf(stderr,"Error: failed to create signature 
>>> context\n");
>>>
>>>                 goto done;
>>>
>>>     }
>>>
>>>                
>>>
>>>  
>>>
>>>    
>>>
>>>  
>>>
>>>     /* limit the Reference URI attributes to empty or NULL */
>>>
>>>     dsigCtx->enabledReferenceUris = xmlSecTransformUriTypeEmpty;
>>>
>>>    
>>>
>>>     /* limit allowed transforms for siganture and reference 
>>> processing */
>>>
>>>     if((xmlSecDSigCtxEnableSignatureTransform(dsigCtx,
>>> xmlSecTransformInclC14NId) < 0) ||
>>>
>>>        (xmlSecDSigCtxEnableSignatureTransform(dsigCtx,
>>> xmlSecTransformExclC14NId) < 0) ||
>>>
>>>        (xmlSecDSigCtxEnableSignatureTransform(dsigCtx,
>>> xmlSecTransformSha1Id) < 0) ||
>>>
>>>        (xmlSecDSigCtxEnableSignatureTransform(dsigCtx,
>>> xmlSecTransformRsaSha1Id) < 0)) {
>>>
>>>  
>>>
>>>         fprintf(stderr,"Error: failed to limit allowed siganture 
>>> transforms\n");
>>>
>>>                 goto done;
>>>
>>>     }
>>>
>>>     if((xmlSecDSigCtxEnableReferenceTransform(dsigCtx,
>>> xmlSecTransformInclC14NId) < 0) ||
>>>
>>>        (xmlSecDSigCtxEnableReferenceTransform(dsigCtx,
>>> xmlSecTransformExclC14NId) < 0) ||
>>>
>>>        (xmlSecDSigCtxEnableReferenceTransform(dsigCtx,
>>> xmlSecTransformSha1Id) < 0) ||
>>>
>>>        (xmlSecDSigCtxEnableReferenceTransform(dsigCtx,
>>> xmlSecTransformEnvelopedId) < 0)) {
>>>
>>>  
>>>
>>>         fprintf(stderr,"Error: failed to limit allowed reference 
>>> transforms\n");
>>>
>>>                 goto done;
>>>
>>>     }
>>>
>>>  
>>>
>>>     /* in addition, limit possible key data to valid X509 
>>> certificates only */
>>>
>>>     if(xmlSecPtrListAdd(&(dsigCtx->keyInfoReadCtx.enabledKeyData),
>>> BAD_CAST xmlSecKeyDataX509Id) < 0) {
>>>
>>>         fprintf(stderr,"Error: failed to limit allowed key data\n");
>>>
>>>                 goto done;
>>>
>>>     }
>>>
>>>    
>>>
>>>     /* Verify signature */
>>>
>>>     if(xmlSecDSigCtxVerify(dsigCtx, node) < 0) {
>>>
>>>         fprintf(stderr,"Error: signature verify\n");
>>>
>>>                 goto done;
>>>
>>>     }
>>>
>>>  
>>>
>>>     /* check that we have only one Reference */
>>>
>>>     if((dsigCtx->status == xmlSecDSigStatusSucceeded) &&
>>>
>>>         (xmlSecPtrListGetSize(&(dsigCtx->signedInfoReferences)) != 
>>> 1)) {
>>>
>>>                
>>>
>>>         fprintf(stderr,"Error: only one reference is allowed\n");
>>>
>>>                 goto done;
>>>
>>>     }
>>>
>>>        
>>>
>>>     /* print verification result to stdout */
>>>
>>>     if(dsigCtx->status == xmlSecDSigStatusSucceeded) {
>>>
>>>                 fprintf(stdout, "Signature is OK\n");
>>>
>>>     } else {
>>>
>>>                 fprintf(stdout, "Signature is INVALID\n");
>>>
>>>     }   
>>>
>>>  
>>>
>>>     /* success */
>>>
>>>     res = 0;
>>>
>>>  
>>>
>>> done:   
>>>
>>>     /* cleanup */
>>>
>>>     if(dsigCtx != NULL) {
>>>
>>>                 xmlSecDSigCtxDestroy(dsigCtx);
>>>
>>>     }
>>>
>>>    
>>>
>>>     if(doc != NULL) {
>>>
>>>                 xmlFreeDoc(doc);
>>>
>>>     }
>>>
>>>     return(res);
>>>
>>>  
>>>
>>> }
>>>
>>>  
>>>
>>> int
>>>
>>> init_allxml_lib()
>>>
>>> {   
>>>
>>>    // Init libxml and libxslt libraries
>>>
>>>    xmlInitParser();
>>>
>>>   
>>>
>>>    LIBXML_TEST_VERSION
>>>
>>>    xmlLoadExtDtdDefaultValue = XML_DETECT_IDS | XML_COMPLETE_ATTRS;
>>>
>>>    xmlSubstituteEntitiesDefault(1);
>>>
>>> #ifndef XMLSEC_NO_XSLT
>>>
>>>    xmlIndentTreeOutput = 1;
>>>
>>> #endif // XMLSEC_NO_XSLT
>>>
>>>                
>>>
>>>    // Init xmlsec library
>>>
>>>    if(xmlSecInit() < 0) {
>>>
>>>    fprintf(stderr, "Error: xmlsec initialization failed.\n");
>>>
>>>    return(-1);
>>>
>>>    }
>>>
>>>  
>>>
>>>    // Check loaded library version
>>>
>>>    if(xmlSecCheckVersion() != 1) {
>>>
>>>    fprintf(stderr, "Error: loaded xmlsec library version is not 
>>> compatible.\n");
>>>
>>>    return(-1);
>>>
>>>    }   
>>>
>>>    
>>>
>>>    // Load default crypto engine if we are supporting dynamic
>>>
>>>    // loading for xmlsec-crypto libraries. Use the crypto library
>>>
>>>    // name ("openssl", "nss", etc.) to load corresponding
>>>
>>>    // xmlsec-crypto library.
>>>
>>>  
>>>
>>> #ifdef XMLSEC_CRYPTO_DYNAMIC_LOADING
>>>
>>>    if(xmlSecCryptoDLLoadLibrary(BAD_CAST XMLSEC_CRYPTO) < 0) {
>>>
>>>    fprintf(stderr, "Error: unable to load default xmlsec-crypto library.
>>> Make sure\n"
>>>
>>>                                                "that you have it 
>>> installed and check shared libraries path\n"
>>>
>>>                                                "(LD_LIBRARY_PATH) 
>>> envornment variable.\n");
>>>
>>>    return(-1);      
>>>
>>>    }
>>>
>>> #endif /* XMLSEC_CRYPTO_DYNAMIC_LOADING */
>>>
>>>  
>>>
>>>    // Init crypto library
>>>
>>>    if(xmlSecCryptoAppInit(NULL) < 0) {
>>>
>>>       fprintf(stderr, "Error: crypto initialization failed.\n");
>>>
>>>       return(-1);
>>>
>>>    }
>>>
>>>  
>>>
>>>    // Init xmlsec-crypto library
>>>
>>>    if(xmlSecCryptoInit() < 0) {
>>>
>>>    fprintf(stderr, "Error: xmlsec-crypto initialization failed.\n");
>>>
>>>    return(-1);
>>>
>>>    }
>>>
>>>                               
>>>
>>>    return 0;
>>>
>>> }
>>>
>>>  
>>>
>>> void
>>>
>>> fnit_allxml_lib()
>>>
>>> {
>>>
>>>    // Shutdown xmlsec-crypto library
>>>
>>>    xmlSecCryptoShutdown();
>>>
>>>    
>>>
>>>    //Shutdown crypto library
>>>
>>>    xmlSecCryptoAppShutdown();
>>>
>>>    
>>>
>>>    //Shutdown xmlsec library
>>>
>>>    xmlSecShutdown();
>>>
>>>  
>>>
>>>    // Shutdown libxslt/libxml
>>>
>>> #ifndef XMLSEC_NO_XSLT
>>>
>>>    xsltCleanupGlobals();           
>>>
>>> #endif //XMLSEC_NO_XSLT
>>>
>>>  
>>>
>>>    xmlCleanupParser();
>>>
>>> }
>>>
>>>  
>>>
>>> const std::string XML_FILE =
>>>
>> "/Projects/project.dokfile.vses/hades/trunk/products/doksafe/engine/li
>> bs/xml
>> dsig/test/"
>>>
>>>                              "mt-embedded-id-dtd-attr.xml";
>>>
>>>
>>
>>> // "mt.xml";
>>>
>>>  
>>>
>>> // Unit Tests
>>>
>>>  
>>>
>>> void do_0()
>>>
>>> {
>>>
>>>    xmlSecKeysMngrPtr mngr = xmlSecKeysMngrCreate();
>>>
>>>    if(mngr == NULL)
>>>
>>>    {
>>>
>>>       fprintf(stderr, "Error: failed to create keys manager.\n");
>>>
>>>    }
>>>
>>>                
>>>
>>>    if(xmlSecCryptoAppDefaultKeysMngrInit(mngr) < 0)
>>>
>>>    {
>>>
>>>       fprintf(stderr, "Error: failed to initialize keys manager.\n");
>>>
>>>       xmlSecKeysMngrDestroy(mngr);
>>>
>>>    }
>>>
>>>                
>>>
>>>    BOOST_CHECK(init_allxml_lib() == 0);
>>>
>>>    BOOST_CHECK(verify_file(mngr, XML_FILE.c_str()) == 0);
>>>
>>>   
>>>
>>>    fnit_allxml_lib();
>>>
>>> }
>>>
>>>  
>>>
>>> // -
>>>
>>>  
>>>
>>> int test_main(int, char*[])
>>>
>>> {
>>>
>>>    do_0();
>>>
>>>  
>>>
>>>    return 0;
>>>
>>> }
>>>
>>>  
>>>
>>>  
>>>
>>>  
>>>
>>>  
>>>
>>> Thanks
>>>
>>>  
>>>
>>>  
>>>
>>>  
>>>
>>>  
>>>
>>>  
>>>
>>>  
>>>
>>>  
>>>
>>>  
>>>
>>>  
>>>
>>>
>>>
>>> _______________________________________________
>>> xmlsec mailing list
>>> xmlsec at aleksey.com
>>> http://www.aleksey.com/mailman/listinfo/xmlsec


From re.tf at acm.org  Mon Jun 11 16:23:48 2012
From: re.tf at acm.org (Renato Forti)
Date: Mon, 11 Jun 2012 20:23:48 -0300
Subject: [xmlsec] CGI Source Code Sample!
In-Reply-To: <4FD113F5.3050907@aleksey.com>
References: <00fc01cd435d$f7ce89e0$e76b9da0$@acm.org>
 <4FCEC586.3010703@aleksey.com> <012001cd43d9$77e0fc50$67a2f4f0$@acm.org>
 <4FCFAC50.7060902@aleksey.com> <01db01cd44e3$df87b410$9e971c30$@acm.org>
 <4FD10461.6070305@aleksey.com> <01eb01cd44e7$442a9d30$cc7fd790$@acm.org>
 <4FD113F5.3050907@aleksey.com>
Message-ID: <4FD67E04.1000805@acm.org>

any place has the soucer code of cgi used in online xmldsig-verifier? 
(http://www.aleksey.com/xmlsec/xmldsig-verifier.html)

Thanks

From aleksey at aleksey.com  Mon Jun 11 16:47:11 2012
From: aleksey at aleksey.com (Aleksey Sanin)
Date: Mon, 11 Jun 2012 16:47:11 -0700
Subject: [xmlsec] CGI Source Code Sample!
In-Reply-To: <4FD67E04.1000805@acm.org>
References: <00fc01cd435d$f7ce89e0$e76b9da0$@acm.org>
 <4FCEC586.3010703@aleksey.com> <012001cd43d9$77e0fc50$67a2f4f0$@acm.org>
 <4FCFAC50.7060902@aleksey.com> <01db01cd44e3$df87b410$9e971c30$@acm.org>
 <4FD10461.6070305@aleksey.com> <01eb01cd44e7$442a9d30$cc7fd790$@acm.org>
 <4FD113F5.3050907@aleksey.com> <4FD67E04.1000805@acm.org>
Message-ID: <4FD6837F.2@aleksey.com>

xmlsec1/examples/xmldsigverify.c

Aleksey


On 6/11/12 4:23 PM, Renato Forti wrote:
> any place has the soucer code of cgi used in online xmldsig-verifier?
> (http://www.aleksey.com/xmlsec/xmldsig-verifier.html)
> 
> Thanks
> _______________________________________________
> xmlsec mailing list
> xmlsec at aleksey.com
> http://www.aleksey.com/mailman/listinfo/xmlsec


From aleksey at aleksey.com  Mon Jun 11 19:53:16 2012
From: aleksey at aleksey.com (Aleksey Sanin)
Date: Mon, 11 Jun 2012 19:53:16 -0700
Subject: [xmlsec] xmlsec1 command
In-Reply-To: <CAEiV1d77v-S1ohJqV3fvHV5NEqTD-3hNnmE3pRiOxi7ScNQM9g@mail.gmail.com>
References: <CAEiV1d77v-S1ohJqV3fvHV5NEqTD-3hNnmE3pRiOxi7ScNQM9g@mail.gmail.com>
Message-ID: <4FD6AF1C.3040208@aleksey.com>

Not sure what do you mean. There should be 3 digests and one signature.

Aleksey


On 6/11/12 6:58 PM, Giancarlo Piva wrote:
> Hi Aleksey,
> 
> I am tring to use xmlsec1 in linux to sign multiple parts of an xml
> document (header, body, timestamp)
> in my template i have 3 digests with 3 uris
> xmlsec works fine but I end up with three signature instead of one in
> the output file
> 
> I am using xmlsec1 --sign --output test.xml --pkcs12 ./certs/cert.p12
> --pwd Password --trusted-pem ./certs/RootCA.crt ./xml/template.xml
> 
> is there an option to sign multiple part of a doc via command line?
> 
> Kind Regards,
> 
> Carlo
> 


From aleksey at aleksey.com  Mon Jun 11 20:52:46 2012
From: aleksey at aleksey.com (Aleksey Sanin)
Date: Mon, 11 Jun 2012 20:52:46 -0700
Subject: [xmlsec] xmlsec1 command
In-Reply-To: <CAEiV1d7zWd+gmBborXN4deTAa4fXLKXQ=R5ooY3YNjv0rwYqow@mail.gmail.com>
References: <CAEiV1d77v-S1ohJqV3fvHV5NEqTD-3hNnmE3pRiOxi7ScNQM9g@mail.gmail.com>
 <4FD6AF1C.3040208@aleksey.com>
 <CAEiV1d7zWd+gmBborXN4deTAa4fXLKXQ=R5ooY3YNjv0rwYqow@mail.gmail.com>
Message-ID: <4FD6BD0E.5060703@aleksey.com>

X509Certificate nodes do not contain signatures. You might want
to read a book on cryptography.

Aleksey


On 6/11/12 8:50 PM, Giancarlo Piva wrote:
> Hi Alekey
> 
> That is right and that is what I am expecting as well..
> 
> I tried to run my command using your xml on the web site:
> 
> xmlsec1 --sign --output test.xml --pkcs12
> ./certs/8003620833337558-general.p12 --pwd Password --trusted-pem
> ./certs/output.pem ./xml/template_test.xml
> 
> in the output I get multiple <X509Certificate> nodes is that normal??
> 
> this is what i get:
> 
> <?xml version="1.0"?>
> <References>
>  <Book>
>   <Author>
>    <FirstName>Bruce</FirstName>
>    <LastName>Schneier</LastName>
>   </Author>
>   <Title>Applied Cryptography</Title>
>  </Book>
>  <Web>
>   <Title>XMLSec</Title>
>   <Url>http://www.aleksey.com/xmlsec/</Url>
>  </Web>
>  <Signature xmlns="http://www.w3.org/2000/09/xmldsig#">
>   <SignedInfo>
>    <CanonicalizationMethod
> Algorithm="http://www.w3.org/TR/2001/REC-xml-c14n-20010315"/>
>    <SignatureMethod Algorithm="http://www.w3.org/2000/09/xmldsig#rsa-sha1"/>
>    <Reference URI="">
>     <Transforms>
>      <Transform
> Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature"/>
>     </Transforms>
>     <DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/>
>     <DigestValue>o/5EifW/Q4LVtDznvqMgBAAC21M=</DigestValue>
>    </Reference>
>   </SignedInfo>
>   <SignatureValue>jk5S8exrQmxJPwBtz4YsEY3+zhWpAaRYW2rJNRLoo7+Rkq7PWoOAkHki63Gx5BEb
> CSmk8bQ5jjqDLoxrbFVsYCmKQiiEpq+r8Kup9lyReA9aA4PRu/FpxufkPYqBXpfN
> YML85F+LCoG44xt4LQMwaZtdE7H1KX3HZ1EX3Q+yIxoVxVp2HQjO9Y+3OJUlXUGk
> t0yn/q11H/AV4mmZ2CWK+4uUKySYTg0KEhu/Z3RpG/S2VX3zHPUg769bQy/1Bihq
> 3bwyO4INAHgP3dMjuc+iTJMMLChy/ZA5zahs5npfmWKFyJSw0ggMApZsRN4Mf8s8
> oDNtKPTja7/HbFBwdbiSdA==</SignatureValue>
>   <KeyInfo>
>    <X509Data>
> 
> 
> 
>    <X509Certificate>MIIHLDCCBhSgAwIBAgIETXl5dTANBgkqhkiG9w0BAQUFADAyMQswCQYDVQQGEwJB
> VTESMBAGA1UEChMJTkVIVEFEZW1vMQ8wDQYDVQQLEwZSb290Q0EwHhcNMTEwNjAy
> MTUyMjQwWhcNMjEwMzExMDA0NjMzWjAxMQswCQYDVQQGEwJBVTESMBAGA1UEChMJ
> TkVIVEFEZW1vMQ4wDAYDVQQLEwVTdWJDQTCCASIwDQYJKoZIhvcNAQEBBQADggEP
> ADCCAQoCggEBAN9Zc8dkNxg9pEaPRxx9Z5H8Fsxt5G7QTXhuVSqwFsxOJNLiuQq+
> Z7q9fr8nry9ulmLj9HgGiPpMqQuFhbRH0aM2kSWhiZtjybVK4d52zwiapa+WcabG
> djg8ZRZaevV6wRflwESUdyRM0g+Re8Bc+u8vEli7spKJgVNf31hvo3/zmIqiR3Vs
> YFMeT9NgqWC/rUmguwScS4v5ZLBHaJG3WfPemTvmkd8iKxxTchG0uYhoBYtOd2Gc
> vcLcj/ZWY3GRcJZIMKTIy34yWhIr1G95ZfdAD5TGfrGrv5WOgTRNGln7Kb00sedZ
> UpyIfYMeR6X6tbVsqLquS8yPgrKCc+2a9UsCAwEAAaOCBEkwggRFMA4GA1UdDwEB
> /wQEAwIBBjASBgNVHRMBAf8ECDAGAQH/AgEAMIICcAYDVR0gBIICZzCCAmMwggHY
> BgwqJAGPUYdqAQEBAQEwggHGMGgGCCsGAQUFBwIBFlxodHRwOi8vcG9saWN5LnBy
> b2Ryb290aGlnaDEucGtpLmVsZWN0cm9uaWNoZWFsdGgubmV0LmF1L3Byb2Ryb290
> aGlnaDEvcG9saWN5L05BU0hfUkNBX0NQLnBkZjCCAVgGCCsGAQUFBwICMIIBShqC
> AUZDZXJ0aWZpY2F0ZXMgdW5kZXIgdGhpcyBwb2xpY3kgYXJlIGlzc3VlZCBieSB0
> aGUgTkFTSCBSb290IENBIHRvIGl0c2VsZiBhbmQgdG8gQ0FzIHN1Ym9yZGluYXRl
> IHRvIHRoZSBOQVNIIFJvb3QgQ0EuIFJlZmVyIHRvIGh0dHA6Ly9wcm9kcm9vdGhp
> Z2gxLnBraS5lbGVjdHJvbmljaGVhbHRoLm5ldC5hdS9wcm9kcm9vdGhpZ2gxLyBm
> b3IgbW9yZSBpbmZvcm1hdGlvbi4gVXNlIG9mIHRoaXMgQ2VydGlmaWNhdGUgaXMg
> c3ViamVjdCB0byBBZ3JlZW1lbnRzIGF0IGh0dHA6Ly9wcm9kcm9vdGhpZ2gxLnBr
> aS5lbGVjdHJvbmljaGVhbHRoLm5ldC5hdS9wcm9kcm9vdGhpZ2gxLzAqBgkqJAGP
> UYdqBQIwHTAbBggrBgEFBQcCAjAPGg1Mb3cgQXNzdXJhbmNlMC8GCSokAY9Rh2oF
> AzAiMCAGCCsGAQUFBwICMBQaEk1vZGVyYXRlIEFzc3VyYW5jZTAoBgoqJAGPUYdq
> BgQAMBowGAYIKwYBBQUHAgIwDBoKSXNzdWluZyBDQTCBswYIKwYBBQUHAQEEgaYw
> gaMwVQYIKwYBBQUHMAKGSWh0dHA6Ly9uZWh0YWRlbW8ubWFuYWdlZC5lbnRydXN0
> LmNvbS9BSUEvQ2VydHNJc3N1ZWR0b05FSFRBRGVtb1Jvb3RDQS5wN2MwSgYIKwYB
> BQUHMAGGPmh0dHA6Ly9uZWh0YWRlbW8ubWFuYWdlZC5lbnRydXN0LmNvbS9PQ1NQ
> L05FSFRBUm9vdENBUmVzcG9uZGVyMIGZBgNVHR8EgZEwgY4wQaA/oD2GO2h0dHA6
> Ly9uZWh0YWRlbW8ubWFuYWdlZC5lbnRydXN0LmNvbS9DUkxzL05FSFRBREVNT1Jv
> b3QuY3JsMEmgR6BFpEMwQTELMAkGA1UEBhMCQVUxEjAQBgNVBAoTCU5FSFRBRGVt
> bzEPMA0GA1UECxMGUm9vdENBMQ0wCwYDVQQDEwRDUkwxMB8GA1UdIwQYMBaAFBDg
> Yh+sUVo0ZnLXWMH0NWk/6JFbMB0GA1UdDgQWBBRaPSKrShmC/GJzkLtwm/s56ZsS
> rDAZBgkqhkiG9n0HQQAEDDAKGwRWOC4xAwIAgTANBgkqhkiG9w0BAQUFAAOCAQEA
> XQTFvV+bBpJshxlfy9bm1gq2ZALukwYPkVB8GhKM43yqT+ZbxwC0im8PYNhbvzRB
> lzo5b50mfZcYaC97Ey5zs511qvyFAiJuZdtPTtmrEw10G+uyGqdLjL+OZTcyVwk3
> 8KAYAaSxc7BhBGxsnLf01bKUmK1HSj2anrKk/81PLIaJId2L7IfcrZFi+OlUZfAK
> THa5ayk8fxu/pI1WjHQy6+HW1IfDmKQJz+uVbTIq03XmuCW4Bwd3U2qjFhtVuQd3
> TjWcRm05d+1p/LSAKFH+jSzorewiG+URvef8Lznwbg/ChbNSaRnlLV9WQqBMsELZ
> 54vPc3pZhOkfrthJYni8jA==</X509Certificate>
> <X509SubjectName>OU=SubCA,O=NEHTADemo,C=AU</X509SubjectName>
> <X509IssuerSerial>
> <X509IssuerName>OU=RootCA,O=NEHTADemo,C=AU</X509IssuerName>
> <X509SerialNumber>1299806581</X509SerialNumber>
> </X509IssuerSerial>
> <X509Certificate>MIIDJDCCAgygAwIBAgIETXlw6TANBgkqhkiG9w0BAQUFADAyMQswCQYDVQQGEwJB
> VTESMBAGA1UEChMJTkVIVEFEZW1vMQ8wDQYDVQQLEwZSb290Q0EwHhcNMTEwMzEx
> MDAxNjMzWhcNMjEwMzExMDA0NjMzWjAyMQswCQYDVQQGEwJBVTESMBAGA1UEChMJ
> TkVIVEFEZW1vMQ8wDQYDVQQLEwZSb290Q0EwggEiMA0GCSqGSIb3DQEBAQUAA4IB
> DwAwggEKAoIBAQCz3qq/Tw5CkP+gQl+uhyislJauKGzJS/uyTveAjnuqzdTR4+bC
> MFeMjIH3da770r2n52MtLgYxhCo50YJzaAKAchV2+GDK0q+KRnut7d+obSamr9Vp
> fMFtYctNvZFaRpPKCOqyz7WfOleOmtaNLv26CUnszM4/nZBcD7CNuoItyX81e4a0
> edMFvg3rqIv7OPg+NSDNYpnBB9rdmbSe1FCLBERon5gsdPGFzh8x5DLtMpZZCwL6
> Q1srclXWLMpnfMAgXDcH8FaLGHVYSfsrHQh9uCCuoV602eic+SgE66/xQ5Uy/OHV
> oZJeB1bLzAk2OxIo8pHuVCMeH178xCI1tAGdAgMBAAGjQjBAMA4GA1UdDwEB/wQE
> AwIBBjAPBgNVHRMBAf8EBTADAQH/MB0GA1UdDgQWBBQQ4GIfrFFaNGZy11jB9DVp
> P+iRWzANBgkqhkiG9w0BAQUFAAOCAQEAcMwGYh5iXTWjYev2+Mmm5IIUD9xRntah
> qWo/lNsWP/Lb3dVpdyxQ5hQt/nFmER7SkXHZT394/deWCdh3E2LE6AE2cIZuQYr+
> 1aHbKWYeAkCnHUjdzszuZ2bEp9FW4Y0+dlH4V71LnobHwWQre/PZFTFNlZjf1xYF
> giI5YK2MeOSsWaB2ACPkq4gDY4JnsNKK3QCX2xR/zeSG1l3Zjp8A07Z0ldvUiwfa
> IFGo8rkHkbbNifCco7d8+6NPiy0qwTG5/Htt9hb7pJ5IStoLSX6AAzKevt/GaRga
> xChYv35zMQF6Bgjkk8LXsQiA2oi8r995oFTKCDbDMYdksyK7FyoFHQ==</X509Certificate>
> <X509SubjectName>OU=RootCA,O=NEHTADemo,C=AU</X509SubjectName>
> <X509IssuerSerial>
> <X509IssuerName>OU=RootCA,O=NEHTADemo,C=AU</X509IssuerName>
> <X509SerialNumber>1299804393</X509SerialNumber>
> </X509IssuerSerial>
> <X509Certificate>MIIIvjCCB6agAwIBAgIETXqLsTANBgkqhkiG9w0BAQUFADAxMQswCQYDVQQGEwJB
> VTESMBAGA1UEChMJTkVIVEFEZW1vMQ4wDAYDVQQLEwVTdWJDQTAeFw0xMjAzMDUw
> MTQyNDlaFw0xMzAzMDUwMDAwMDBaMIGfMRIwEAYKCZImiZPyLGQBGRYCQVUxEzAR
> BgoJkiaJk/IsZAEZFgNORVQxIDAeBgoJkiaJk/IsZAEZFhBFTEVDVFJPTklDSEVB
> TFRIMRQwEgYDVQQKEwtNZWRpY2FyZTMwNTE8MDoGA1UEAxMzZ2VuZXJhbC44MDAz
> NjIwODMzMzM3NTU4LmlkLmVsZWN0cm9uaWNoZWFsdGgubmV0LmF1MIIBIjANBgkq
> hkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA21303diBXMqVg0Z366xYZc4qCTeHd9zf
> oHWJRAd7/YQlfMu3q21sb7MqQI3N88bmQxICn2tg5HRPKh8rB9RqGT8gzGpKiMbz
> KFxz81dzzj87gkYkLF57WiuKARKqp98nx2mTIELKcN1ahejHbo2cVjHpkQ+m17Dt
> TZJ5sUxna2OT6+qTWEBlilnjsiit2M96iNs1/Y4eySRRCDKNXF2virN/5cqzjfRk
> iKTwfgKNQ09MNeCN+wl588JKuGmIzZ8kKQveXzHEvS9eUFQid1ZOVy8x+0jeoUHO
> YTNoRb1wckdtV7eFFx5fERE/KuTvjvMchCBezZWYz0WwUXiSKX0/qQIDAQABo4IF
> bTCCBWkwDgYDVR0PAQH/BAQDAgSwMIIBMAYIKwYBBQUHAQEEggEiMIIBHjBJBggr
> BgEFBQcwAYY9aHR0cDovL25laHRhZGVtby5tYW5hZ2VkLmVudHJ1c3QuY29tL09D
> U1AvTkVIVEFTdWJDQVJlc3BvbmRlcjBUBggrBgEFBQcwAoZIaHR0cDovL25laHRh
> ZGVtby5tYW5hZ2VkLmVudHJ1c3QuY29tL0FJQS9DZXJ0c0lzc3VlZHRvTkVIVEFE
> ZW1vU3ViQ0EucDdjMHsGCCsGAQUFBzAChm9sZGFwOi8vbmVodGFkZW1vLm1hbmFn
> ZWQuZW50cnVzdC5jb20vb3U9U3ViQ0Esbz1ORUhUQURlbW8sYz1BVT9jQUNlcnRp
> ZmljYXRlO2JpbmFyeSxjcm9zc0NlcnRpZmljYXRlUGFpcjtiaW5hcnkwHQYDVR0l
> BBYwFAYIKwYBBQUHAwEGCCsGAQUFBwMCMAwGA1UdEwEB/wQCMAAwggIyBgNVHSAE
> ggIpMIICJTCCAcQGDCokAY9Rh2oBAwEEAzCCAbIwZQYIKwYBBQUHAgEWWWh0dHA6
> Ly9wb2xpY3kudGVzdHN1Ym1vZDEucGtpLmVsZWN0cm9uaWNoZWFsdGgubmV0LmF1
> L3Rlc3RzdWJtb2QxL3BvbGljeS9OQVNIX0hQSU9fQ1AucGRmMIIBRwYIKwYBBQUH
> AgIwggE5GoIBNUNlcnRpZmljYXRlcyB1bmRlciB0aGlzIHBvbGljeSBhcmUgaXNz
> dWVkIGJ5IHRoZSBOQVNIIFN1Ym9yZGluYXRlIENBIHRvIEhlYWx0aGNhcmUgUHJv
> dmlkZXIgT3JnYW5pc2F0aW9ucy4gUmVmZXIgdG8gaHR0cDovL3Rlc3RzdWJtb2Qx
> LnBraS5lbGVjdHJvbmljaGVhbHRoLm5ldC5hdS90ZXN0c3VibW9kMS8gZm9yIG1v
> cmUgaW5mb3JtYXRpb24uIFVzZSBvZiB0aGlzIENlcnRpZmljYXRlIGlzIHN1Ympl
> Y3QgdG8gQWdyZWVtZW50cyBhdCBodHRwOi8vdGVzdHN1Ym1vZDEucGtpLmVsZWN0
> cm9uaWNoZWFsdGgubmV0LmF1L3Rlc3RzdWJtb2QxLzAqBgkqJAGPUYdqBQIwHTAb
> BggrBgEFBQcCAjAPGg1Mb3cgQXNzdXJhbmNlMC8GCiokAY9Rh2oGBwMwITAfBggr
> BgEFBQcCAjATGhFXZWJTZXJ2aWNlIERldmljZTCBgQYDVR0RBHoweIIzZ2VuZXJh
> bC44MDAzNjIwODMzMzM3NTU4LmlkLmVsZWN0cm9uaWNoZWFsdGgubmV0LmF1hkFo
> dHRwOi8vbnMuZWxlY3Ryb25pY2hlYWx0aC5uZXQuYXUvaWQvaGkvaHBpby8xLjAv
> ODAwMzYyMDgzMzMzNzU1ODCB+wYDVR0fBIHzMIHwMIGjoIGgoIGdhjpodHRwOi8v
> bmVodGFkZW1vLm1hbmFnZWQuZW50cnVzdC5jb20vQ1JMcy9ORUhUQURFTU9TdWIu
> Y3Jshl9sZGFwOi8vbmVodGFkZW1vLm1hbmFnZWQuZW50cnVzdC5jb20vb3U9U3Vi
> Q0Esbz1ORUhUQURlbW8sYz1BVT9jZXJ0aWZpY2F0ZVJldm9jYXRpb25MaXN0O2Jp
> bmFyeTBIoEagRKRCMEAxCzAJBgNVBAYTAkFVMRIwEAYDVQQKEwlORUhUQURlbW8x
> DjAMBgNVBAsTBVN1YkNBMQ0wCwYDVQQDEwRDUkw4MB8GA1UdIwQYMBaAFFo9IqtK
> GYL8YnOQu3Cb+znpmxKsMB0GA1UdDgQWBBTJ0D/1ayPl4d+NQZLxTUdJVGr/ZDAN
> BgkqhkiG9w0BAQUFAAOCAQEAEFvbTBlGeI1rj8mNZDQtoNN7pFdR1WH3N1Exbcez
> +zoUncZXAIqmvVG/pTxuDpaLx2Kg+JIBbYZSvFp/RRiea3DuV416c7yqcsbfBhMO
> pwqZs8e0UUKKMugrSy7Z2DXCTjGlxNw9gR8QDdz+ddn98dRqAlh/UV289sFBNEbK
> 5PLtjgtUxhqzn9CKmxgLO2RUkIJvWmVDRF+SvOzb8/QcGk3OX3YlWFlMeTsaHMyK
> KKnbmkrGRlj1sfK4OUWmdaLKWbIhvA2eBf5iHlwSiZ0I2LuXp2TI29KCPmCaHmkd
> h1AZzEQWh1sXCpUScS+dNkKaJiqMvuPRVBFniv5W/XZjNg==</X509Certificate>
> <X509SubjectName>CN=general.8003620833337558.id.electronichealth.net.au,O=Medicare305,DC=ELECTRONICHEALTH,DC=NET,DC=AU</X509SubjectName>
> <X509IssuerSerial>
> <X509IssuerName>OU=SubCA,O=NEHTADemo,C=AU</X509IssuerName>
> <X509SerialNumber>1299876785</X509SerialNumber>
> </X509IssuerSerial>
> </X509Data>
>    <KeyValue>
> <RSAKeyValue>
> <Modulus>
> 21303diBXMqVg0Z366xYZc4qCTeHd9zfoHWJRAd7/YQlfMu3q21sb7MqQI3N88bm
> QxICn2tg5HRPKh8rB9RqGT8gzGpKiMbzKFxz81dzzj87gkYkLF57WiuKARKqp98n
> x2mTIELKcN1ahejHbo2cVjHpkQ+m17DtTZJ5sUxna2OT6+qTWEBlilnjsiit2M96
> iNs1/Y4eySRRCDKNXF2virN/5cqzjfRkiKTwfgKNQ09MNeCN+wl588JKuGmIzZ8k
> KQveXzHEvS9eUFQid1ZOVy8x+0jeoUHOYTNoRb1wckdtV7eFFx5fERE/KuTvjvMc
> hCBezZWYz0WwUXiSKX0/qQ==
> </Modulus>
> <Exponent>
> AQAB
> </Exponent>
> </RSAKeyValue>
> </KeyValue>
>   </KeyInfo>
>  </Signature>
> </References>
> 
> 
> 
> On Tue, Jun 12, 2012 at 12:53 PM, Aleksey Sanin <aleksey at aleksey.com> wrote:
>> Not sure what do you mean. There should be 3 digests and one signature.
>>
>> Aleksey
>>
>>
>> On 6/11/12 6:58 PM, Giancarlo Piva wrote:
>>> Hi Aleksey,
>>>
>>> I am tring to use xmlsec1 in linux to sign multiple parts of an xml
>>> document (header, body, timestamp)
>>> in my template i have 3 digests with 3 uris
>>> xmlsec works fine but I end up with three signature instead of one in
>>> the output file
>>>
>>> I am using xmlsec1 --sign --output test.xml --pkcs12 ./certs/cert.p12
>>> --pwd Password --trusted-pem ./certs/RootCA.crt ./xml/template.xml
>>>
>>> is there an option to sign multiple part of a doc via command line?
>>>
>>> Kind Regards,
>>>
>>> Carlo
>>>
>>


From aleksey at aleksey.com  Mon Jun 11 21:05:00 2012
From: aleksey at aleksey.com (Aleksey Sanin)
Date: Mon, 11 Jun 2012 21:05:00 -0700
Subject: [xmlsec] xmlsec1 command
In-Reply-To: <CAEiV1d6snVyBFms1azgBURhLAkcP66iHLEc04aFMJ+fd+g-smA@mail.gmail.com>
References: <CAEiV1d77v-S1ohJqV3fvHV5NEqTD-3hNnmE3pRiOxi7ScNQM9g@mail.gmail.com>
 <4FD6AF1C.3040208@aleksey.com>
 <CAEiV1d7zWd+gmBborXN4deTAa4fXLKXQ=R5ooY3YNjv0rwYqow@mail.gmail.com>
 <4FD6BD0E.5060703@aleksey.com>
 <CAEiV1d6snVyBFms1azgBURhLAkcP66iHLEc04aFMJ+fd+g-smA@mail.gmail.com>
Message-ID: <4FD6BFEC.5010608@aleksey.com>

It depends on the certificate or to be precise pkcs12 file
you are signing with. Yours contains 3 certs.

Aleksey


On 6/11/12 9:03 PM, Giancarlo Piva wrote:
> Aleksey
> 
> My crypto knowledge is limited
> I am just trying to sign a document from the command line tool xmlsec1
> as proof of concept...
> before reading a book on cryptography.... I will better document
> myself for sure..
> and eventually read the manual.. and code my client using the xmlsec library...
> I was looking only for a hint as your X509 example on the web site the
> output file have only one "X509Certificate" node
> when I run the same example the output I get have multiple
> "X509Certificate" nodes... I dont understand why?
> 
> anyway thanks for your help
> 
> Carlo
> 
> On Tue, Jun 12, 2012 at 1:52 PM, Aleksey Sanin <aleksey at aleksey.com> wrote:
>> X509Certificate nodes do not contain signatures. You might want
>> to read a book on cryptography.
>>
>> Aleksey
>>
>>
>> On 6/11/12 8:50 PM, Giancarlo Piva wrote:
>>> Hi Alekey
>>>
>>> That is right and that is what I am expecting as well..
>>>
>>> I tried to run my command using your xml on the web site:
>>>
>>> xmlsec1 --sign --output test.xml --pkcs12
>>> ./certs/8003620833337558-general.p12 --pwd Password --trusted-pem
>>> ./certs/output.pem ./xml/template_test.xml
>>>
>>> in the output I get multiple <X509Certificate> nodes is that normal??
>>>
>>> this is what i get:
>>>
>>> <?xml version="1.0"?>
>>> <References>
>>>  <Book>
>>>   <Author>
>>>    <FirstName>Bruce</FirstName>
>>>    <LastName>Schneier</LastName>
>>>   </Author>
>>>   <Title>Applied Cryptography</Title>
>>>  </Book>
>>>  <Web>
>>>   <Title>XMLSec</Title>
>>>   <Url>http://www.aleksey.com/xmlsec/</Url>
>>>  </Web>
>>>  <Signature xmlns="http://www.w3.org/2000/09/xmldsig#">
>>>   <SignedInfo>
>>>    <CanonicalizationMethod
>>> Algorithm="http://www.w3.org/TR/2001/REC-xml-c14n-20010315"/>
>>>    <SignatureMethod Algorithm="http://www.w3.org/2000/09/xmldsig#rsa-sha1"/>
>>>    <Reference URI="">
>>>     <Transforms>
>>>      <Transform
>>> Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature"/>
>>>     </Transforms>
>>>     <DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/>
>>>     <DigestValue>o/5EifW/Q4LVtDznvqMgBAAC21M=</DigestValue>
>>>    </Reference>
>>>   </SignedInfo>
>>>   <SignatureValue>jk5S8exrQmxJPwBtz4YsEY3+zhWpAaRYW2rJNRLoo7+Rkq7PWoOAkHki63Gx5BEb
>>> CSmk8bQ5jjqDLoxrbFVsYCmKQiiEpq+r8Kup9lyReA9aA4PRu/FpxufkPYqBXpfN
>>> YML85F+LCoG44xt4LQMwaZtdE7H1KX3HZ1EX3Q+yIxoVxVp2HQjO9Y+3OJUlXUGk
>>> t0yn/q11H/AV4mmZ2CWK+4uUKySYTg0KEhu/Z3RpG/S2VX3zHPUg769bQy/1Bihq
>>> 3bwyO4INAHgP3dMjuc+iTJMMLChy/ZA5zahs5npfmWKFyJSw0ggMApZsRN4Mf8s8
>>> oDNtKPTja7/HbFBwdbiSdA==</SignatureValue>
>>>   <KeyInfo>
>>>    <X509Data>
>>>
>>>
>>>
>>>    <X509Certificate>MIIHLDCCBhSgAwIBAgIETXl5dTANBgkqhkiG9w0BAQUFADAyMQswCQYDVQQGEwJB
>>> VTESMBAGA1UEChMJTkVIVEFEZW1vMQ8wDQYDVQQLEwZSb290Q0EwHhcNMTEwNjAy
>>> MTUyMjQwWhcNMjEwMzExMDA0NjMzWjAxMQswCQYDVQQGEwJBVTESMBAGA1UEChMJ
>>> TkVIVEFEZW1vMQ4wDAYDVQQLEwVTdWJDQTCCASIwDQYJKoZIhvcNAQEBBQADggEP
>>> ADCCAQoCggEBAN9Zc8dkNxg9pEaPRxx9Z5H8Fsxt5G7QTXhuVSqwFsxOJNLiuQq+
>>> Z7q9fr8nry9ulmLj9HgGiPpMqQuFhbRH0aM2kSWhiZtjybVK4d52zwiapa+WcabG
>>> djg8ZRZaevV6wRflwESUdyRM0g+Re8Bc+u8vEli7spKJgVNf31hvo3/zmIqiR3Vs
>>> YFMeT9NgqWC/rUmguwScS4v5ZLBHaJG3WfPemTvmkd8iKxxTchG0uYhoBYtOd2Gc
>>> vcLcj/ZWY3GRcJZIMKTIy34yWhIr1G95ZfdAD5TGfrGrv5WOgTRNGln7Kb00sedZ
>>> UpyIfYMeR6X6tbVsqLquS8yPgrKCc+2a9UsCAwEAAaOCBEkwggRFMA4GA1UdDwEB
>>> /wQEAwIBBjASBgNVHRMBAf8ECDAGAQH/AgEAMIICcAYDVR0gBIICZzCCAmMwggHY
>>> BgwqJAGPUYdqAQEBAQEwggHGMGgGCCsGAQUFBwIBFlxodHRwOi8vcG9saWN5LnBy
>>> b2Ryb290aGlnaDEucGtpLmVsZWN0cm9uaWNoZWFsdGgubmV0LmF1L3Byb2Ryb290
>>> aGlnaDEvcG9saWN5L05BU0hfUkNBX0NQLnBkZjCCAVgGCCsGAQUFBwICMIIBShqC
>>> AUZDZXJ0aWZpY2F0ZXMgdW5kZXIgdGhpcyBwb2xpY3kgYXJlIGlzc3VlZCBieSB0
>>> aGUgTkFTSCBSb290IENBIHRvIGl0c2VsZiBhbmQgdG8gQ0FzIHN1Ym9yZGluYXRl
>>> IHRvIHRoZSBOQVNIIFJvb3QgQ0EuIFJlZmVyIHRvIGh0dHA6Ly9wcm9kcm9vdGhp
>>> Z2gxLnBraS5lbGVjdHJvbmljaGVhbHRoLm5ldC5hdS9wcm9kcm9vdGhpZ2gxLyBm
>>> b3IgbW9yZSBpbmZvcm1hdGlvbi4gVXNlIG9mIHRoaXMgQ2VydGlmaWNhdGUgaXMg
>>> c3ViamVjdCB0byBBZ3JlZW1lbnRzIGF0IGh0dHA6Ly9wcm9kcm9vdGhpZ2gxLnBr
>>> aS5lbGVjdHJvbmljaGVhbHRoLm5ldC5hdS9wcm9kcm9vdGhpZ2gxLzAqBgkqJAGP
>>> UYdqBQIwHTAbBggrBgEFBQcCAjAPGg1Mb3cgQXNzdXJhbmNlMC8GCSokAY9Rh2oF
>>> AzAiMCAGCCsGAQUFBwICMBQaEk1vZGVyYXRlIEFzc3VyYW5jZTAoBgoqJAGPUYdq
>>> BgQAMBowGAYIKwYBBQUHAgIwDBoKSXNzdWluZyBDQTCBswYIKwYBBQUHAQEEgaYw
>>> gaMwVQYIKwYBBQUHMAKGSWh0dHA6Ly9uZWh0YWRlbW8ubWFuYWdlZC5lbnRydXN0
>>> LmNvbS9BSUEvQ2VydHNJc3N1ZWR0b05FSFRBRGVtb1Jvb3RDQS5wN2MwSgYIKwYB
>>> BQUHMAGGPmh0dHA6Ly9uZWh0YWRlbW8ubWFuYWdlZC5lbnRydXN0LmNvbS9PQ1NQ
>>> L05FSFRBUm9vdENBUmVzcG9uZGVyMIGZBgNVHR8EgZEwgY4wQaA/oD2GO2h0dHA6
>>> Ly9uZWh0YWRlbW8ubWFuYWdlZC5lbnRydXN0LmNvbS9DUkxzL05FSFRBREVNT1Jv
>>> b3QuY3JsMEmgR6BFpEMwQTELMAkGA1UEBhMCQVUxEjAQBgNVBAoTCU5FSFRBRGVt
>>> bzEPMA0GA1UECxMGUm9vdENBMQ0wCwYDVQQDEwRDUkwxMB8GA1UdIwQYMBaAFBDg
>>> Yh+sUVo0ZnLXWMH0NWk/6JFbMB0GA1UdDgQWBBRaPSKrShmC/GJzkLtwm/s56ZsS
>>> rDAZBgkqhkiG9n0HQQAEDDAKGwRWOC4xAwIAgTANBgkqhkiG9w0BAQUFAAOCAQEA
>>> XQTFvV+bBpJshxlfy9bm1gq2ZALukwYPkVB8GhKM43yqT+ZbxwC0im8PYNhbvzRB
>>> lzo5b50mfZcYaC97Ey5zs511qvyFAiJuZdtPTtmrEw10G+uyGqdLjL+OZTcyVwk3
>>> 8KAYAaSxc7BhBGxsnLf01bKUmK1HSj2anrKk/81PLIaJId2L7IfcrZFi+OlUZfAK
>>> THa5ayk8fxu/pI1WjHQy6+HW1IfDmKQJz+uVbTIq03XmuCW4Bwd3U2qjFhtVuQd3
>>> TjWcRm05d+1p/LSAKFH+jSzorewiG+URvef8Lznwbg/ChbNSaRnlLV9WQqBMsELZ
>>> 54vPc3pZhOkfrthJYni8jA==</X509Certificate>
>>> <X509SubjectName>OU=SubCA,O=NEHTADemo,C=AU</X509SubjectName>
>>> <X509IssuerSerial>
>>> <X509IssuerName>OU=RootCA,O=NEHTADemo,C=AU</X509IssuerName>
>>> <X509SerialNumber>1299806581</X509SerialNumber>
>>> </X509IssuerSerial>
>>> <X509Certificate>MIIDJDCCAgygAwIBAgIETXlw6TANBgkqhkiG9w0BAQUFADAyMQswCQYDVQQGEwJB
>>> VTESMBAGA1UEChMJTkVIVEFEZW1vMQ8wDQYDVQQLEwZSb290Q0EwHhcNMTEwMzEx
>>> MDAxNjMzWhcNMjEwMzExMDA0NjMzWjAyMQswCQYDVQQGEwJBVTESMBAGA1UEChMJ
>>> TkVIVEFEZW1vMQ8wDQYDVQQLEwZSb290Q0EwggEiMA0GCSqGSIb3DQEBAQUAA4IB
>>> DwAwggEKAoIBAQCz3qq/Tw5CkP+gQl+uhyislJauKGzJS/uyTveAjnuqzdTR4+bC
>>> MFeMjIH3da770r2n52MtLgYxhCo50YJzaAKAchV2+GDK0q+KRnut7d+obSamr9Vp
>>> fMFtYctNvZFaRpPKCOqyz7WfOleOmtaNLv26CUnszM4/nZBcD7CNuoItyX81e4a0
>>> edMFvg3rqIv7OPg+NSDNYpnBB9rdmbSe1FCLBERon5gsdPGFzh8x5DLtMpZZCwL6
>>> Q1srclXWLMpnfMAgXDcH8FaLGHVYSfsrHQh9uCCuoV602eic+SgE66/xQ5Uy/OHV
>>> oZJeB1bLzAk2OxIo8pHuVCMeH178xCI1tAGdAgMBAAGjQjBAMA4GA1UdDwEB/wQE
>>> AwIBBjAPBgNVHRMBAf8EBTADAQH/MB0GA1UdDgQWBBQQ4GIfrFFaNGZy11jB9DVp
>>> P+iRWzANBgkqhkiG9w0BAQUFAAOCAQEAcMwGYh5iXTWjYev2+Mmm5IIUD9xRntah
>>> qWo/lNsWP/Lb3dVpdyxQ5hQt/nFmER7SkXHZT394/deWCdh3E2LE6AE2cIZuQYr+
>>> 1aHbKWYeAkCnHUjdzszuZ2bEp9FW4Y0+dlH4V71LnobHwWQre/PZFTFNlZjf1xYF
>>> giI5YK2MeOSsWaB2ACPkq4gDY4JnsNKK3QCX2xR/zeSG1l3Zjp8A07Z0ldvUiwfa
>>> IFGo8rkHkbbNifCco7d8+6NPiy0qwTG5/Htt9hb7pJ5IStoLSX6AAzKevt/GaRga
>>> xChYv35zMQF6Bgjkk8LXsQiA2oi8r995oFTKCDbDMYdksyK7FyoFHQ==</X509Certificate>
>>> <X509SubjectName>OU=RootCA,O=NEHTADemo,C=AU</X509SubjectName>
>>> <X509IssuerSerial>
>>> <X509IssuerName>OU=RootCA,O=NEHTADemo,C=AU</X509IssuerName>
>>> <X509SerialNumber>1299804393</X509SerialNumber>
>>> </X509IssuerSerial>
>>> <X509Certificate>MIIIvjCCB6agAwIBAgIETXqLsTANBgkqhkiG9w0BAQUFADAxMQswCQYDVQQGEwJB
>>> VTESMBAGA1UEChMJTkVIVEFEZW1vMQ4wDAYDVQQLEwVTdWJDQTAeFw0xMjAzMDUw
>>> MTQyNDlaFw0xMzAzMDUwMDAwMDBaMIGfMRIwEAYKCZImiZPyLGQBGRYCQVUxEzAR
>>> BgoJkiaJk/IsZAEZFgNORVQxIDAeBgoJkiaJk/IsZAEZFhBFTEVDVFJPTklDSEVB
>>> TFRIMRQwEgYDVQQKEwtNZWRpY2FyZTMwNTE8MDoGA1UEAxMzZ2VuZXJhbC44MDAz
>>> NjIwODMzMzM3NTU4LmlkLmVsZWN0cm9uaWNoZWFsdGgubmV0LmF1MIIBIjANBgkq
>>> hkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA21303diBXMqVg0Z366xYZc4qCTeHd9zf
>>> oHWJRAd7/YQlfMu3q21sb7MqQI3N88bmQxICn2tg5HRPKh8rB9RqGT8gzGpKiMbz
>>> KFxz81dzzj87gkYkLF57WiuKARKqp98nx2mTIELKcN1ahejHbo2cVjHpkQ+m17Dt
>>> TZJ5sUxna2OT6+qTWEBlilnjsiit2M96iNs1/Y4eySRRCDKNXF2virN/5cqzjfRk
>>> iKTwfgKNQ09MNeCN+wl588JKuGmIzZ8kKQveXzHEvS9eUFQid1ZOVy8x+0jeoUHO
>>> YTNoRb1wckdtV7eFFx5fERE/KuTvjvMchCBezZWYz0WwUXiSKX0/qQIDAQABo4IF
>>> bTCCBWkwDgYDVR0PAQH/BAQDAgSwMIIBMAYIKwYBBQUHAQEEggEiMIIBHjBJBggr
>>> BgEFBQcwAYY9aHR0cDovL25laHRhZGVtby5tYW5hZ2VkLmVudHJ1c3QuY29tL09D
>>> U1AvTkVIVEFTdWJDQVJlc3BvbmRlcjBUBggrBgEFBQcwAoZIaHR0cDovL25laHRh
>>> ZGVtby5tYW5hZ2VkLmVudHJ1c3QuY29tL0FJQS9DZXJ0c0lzc3VlZHRvTkVIVEFE
>>> ZW1vU3ViQ0EucDdjMHsGCCsGAQUFBzAChm9sZGFwOi8vbmVodGFkZW1vLm1hbmFn
>>> ZWQuZW50cnVzdC5jb20vb3U9U3ViQ0Esbz1ORUhUQURlbW8sYz1BVT9jQUNlcnRp
>>> ZmljYXRlO2JpbmFyeSxjcm9zc0NlcnRpZmljYXRlUGFpcjtiaW5hcnkwHQYDVR0l
>>> BBYwFAYIKwYBBQUHAwEGCCsGAQUFBwMCMAwGA1UdEwEB/wQCMAAwggIyBgNVHSAE
>>> ggIpMIICJTCCAcQGDCokAY9Rh2oBAwEEAzCCAbIwZQYIKwYBBQUHAgEWWWh0dHA6
>>> Ly9wb2xpY3kudGVzdHN1Ym1vZDEucGtpLmVsZWN0cm9uaWNoZWFsdGgubmV0LmF1
>>> L3Rlc3RzdWJtb2QxL3BvbGljeS9OQVNIX0hQSU9fQ1AucGRmMIIBRwYIKwYBBQUH
>>> AgIwggE5GoIBNUNlcnRpZmljYXRlcyB1bmRlciB0aGlzIHBvbGljeSBhcmUgaXNz
>>> dWVkIGJ5IHRoZSBOQVNIIFN1Ym9yZGluYXRlIENBIHRvIEhlYWx0aGNhcmUgUHJv
>>> dmlkZXIgT3JnYW5pc2F0aW9ucy4gUmVmZXIgdG8gaHR0cDovL3Rlc3RzdWJtb2Qx
>>> LnBraS5lbGVjdHJvbmljaGVhbHRoLm5ldC5hdS90ZXN0c3VibW9kMS8gZm9yIG1v
>>> cmUgaW5mb3JtYXRpb24uIFVzZSBvZiB0aGlzIENlcnRpZmljYXRlIGlzIHN1Ympl
>>> Y3QgdG8gQWdyZWVtZW50cyBhdCBodHRwOi8vdGVzdHN1Ym1vZDEucGtpLmVsZWN0
>>> cm9uaWNoZWFsdGgubmV0LmF1L3Rlc3RzdWJtb2QxLzAqBgkqJAGPUYdqBQIwHTAb
>>> BggrBgEFBQcCAjAPGg1Mb3cgQXNzdXJhbmNlMC8GCiokAY9Rh2oGBwMwITAfBggr
>>> BgEFBQcCAjATGhFXZWJTZXJ2aWNlIERldmljZTCBgQYDVR0RBHoweIIzZ2VuZXJh
>>> bC44MDAzNjIwODMzMzM3NTU4LmlkLmVsZWN0cm9uaWNoZWFsdGgubmV0LmF1hkFo
>>> dHRwOi8vbnMuZWxlY3Ryb25pY2hlYWx0aC5uZXQuYXUvaWQvaGkvaHBpby8xLjAv
>>> ODAwMzYyMDgzMzMzNzU1ODCB+wYDVR0fBIHzMIHwMIGjoIGgoIGdhjpodHRwOi8v
>>> bmVodGFkZW1vLm1hbmFnZWQuZW50cnVzdC5jb20vQ1JMcy9ORUhUQURFTU9TdWIu
>>> Y3Jshl9sZGFwOi8vbmVodGFkZW1vLm1hbmFnZWQuZW50cnVzdC5jb20vb3U9U3Vi
>>> Q0Esbz1ORUhUQURlbW8sYz1BVT9jZXJ0aWZpY2F0ZVJldm9jYXRpb25MaXN0O2Jp
>>> bmFyeTBIoEagRKRCMEAxCzAJBgNVBAYTAkFVMRIwEAYDVQQKEwlORUhUQURlbW8x
>>> DjAMBgNVBAsTBVN1YkNBMQ0wCwYDVQQDEwRDUkw4MB8GA1UdIwQYMBaAFFo9IqtK
>>> GYL8YnOQu3Cb+znpmxKsMB0GA1UdDgQWBBTJ0D/1ayPl4d+NQZLxTUdJVGr/ZDAN
>>> BgkqhkiG9w0BAQUFAAOCAQEAEFvbTBlGeI1rj8mNZDQtoNN7pFdR1WH3N1Exbcez
>>> +zoUncZXAIqmvVG/pTxuDpaLx2Kg+JIBbYZSvFp/RRiea3DuV416c7yqcsbfBhMO
>>> pwqZs8e0UUKKMugrSy7Z2DXCTjGlxNw9gR8QDdz+ddn98dRqAlh/UV289sFBNEbK
>>> 5PLtjgtUxhqzn9CKmxgLO2RUkIJvWmVDRF+SvOzb8/QcGk3OX3YlWFlMeTsaHMyK
>>> KKnbmkrGRlj1sfK4OUWmdaLKWbIhvA2eBf5iHlwSiZ0I2LuXp2TI29KCPmCaHmkd
>>> h1AZzEQWh1sXCpUScS+dNkKaJiqMvuPRVBFniv5W/XZjNg==</X509Certificate>
>>> <X509SubjectName>CN=general.8003620833337558.id.electronichealth.net.au,O=Medicare305,DC=ELECTRONICHEALTH,DC=NET,DC=AU</X509SubjectName>
>>> <X509IssuerSerial>
>>> <X509IssuerName>OU=SubCA,O=NEHTADemo,C=AU</X509IssuerName>
>>> <X509SerialNumber>1299876785</X509SerialNumber>
>>> </X509IssuerSerial>
>>> </X509Data>
>>>    <KeyValue>
>>> <RSAKeyValue>
>>> <Modulus>
>>> 21303diBXMqVg0Z366xYZc4qCTeHd9zfoHWJRAd7/YQlfMu3q21sb7MqQI3N88bm
>>> QxICn2tg5HRPKh8rB9RqGT8gzGpKiMbzKFxz81dzzj87gkYkLF57WiuKARKqp98n
>>> x2mTIELKcN1ahejHbo2cVjHpkQ+m17DtTZJ5sUxna2OT6+qTWEBlilnjsiit2M96
>>> iNs1/Y4eySRRCDKNXF2virN/5cqzjfRkiKTwfgKNQ09MNeCN+wl588JKuGmIzZ8k
>>> KQveXzHEvS9eUFQid1ZOVy8x+0jeoUHOYTNoRb1wckdtV7eFFx5fERE/KuTvjvMc
>>> hCBezZWYz0WwUXiSKX0/qQ==
>>> </Modulus>
>>> <Exponent>
>>> AQAB
>>> </Exponent>
>>> </RSAKeyValue>
>>> </KeyValue>
>>>   </KeyInfo>
>>>  </Signature>
>>> </References>
>>>
>>>
>>>
>>> On Tue, Jun 12, 2012 at 12:53 PM, Aleksey Sanin <aleksey at aleksey.com> wrote:
>>>> Not sure what do you mean. There should be 3 digests and one signature.
>>>>
>>>> Aleksey
>>>>
>>>>
>>>> On 6/11/12 6:58 PM, Giancarlo Piva wrote:
>>>>> Hi Aleksey,
>>>>>
>>>>> I am tring to use xmlsec1 in linux to sign multiple parts of an xml
>>>>> document (header, body, timestamp)
>>>>> in my template i have 3 digests with 3 uris
>>>>> xmlsec works fine but I end up with three signature instead of one in
>>>>> the output file
>>>>>
>>>>> I am using xmlsec1 --sign --output test.xml --pkcs12 ./certs/cert.p12
>>>>> --pwd Password --trusted-pem ./certs/RootCA.crt ./xml/template.xml
>>>>>
>>>>> is there an option to sign multiple part of a doc via command line?
>>>>>
>>>>> Kind Regards,
>>>>>
>>>>> Carlo
>>>>>
>>>>
>>


From aleksey at aleksey.com  Mon Jun 11 21:17:56 2012
From: aleksey at aleksey.com (Aleksey Sanin)
Date: Mon, 11 Jun 2012 21:17:56 -0700
Subject: [xmlsec] xmlsec1 command
In-Reply-To: <CAEiV1d6JzQtJwLbfT+aOZmMnqh5+1MOsGHuiWaVtwk0bpSFZKg@mail.gmail.com>
References: <CAEiV1d77v-S1ohJqV3fvHV5NEqTD-3hNnmE3pRiOxi7ScNQM9g@mail.gmail.com>
 <4FD6AF1C.3040208@aleksey.com>
 <CAEiV1d7zWd+gmBborXN4deTAa4fXLKXQ=R5ooY3YNjv0rwYqow@mail.gmail.com>
 <4FD6BD0E.5060703@aleksey.com>
 <CAEiV1d6snVyBFms1azgBURhLAkcP66iHLEc04aFMJ+fd+g-smA@mail.gmail.com>
 <4FD6BFEC.5010608@aleksey.com>
 <CAEiV1d6JzQtJwLbfT+aOZmMnqh5+1MOsGHuiWaVtwk0bpSFZKg@mail.gmail.com>
Message-ID: <4FD6C2F4.6090409@aleksey.com>

Nope. You need all 3 to verify the signature. Or you can
build another pkcs12 file.

Aleksey


On 6/11/12 9:14 PM, Giancarlo Piva wrote:
> Aleksey
> 
> Thanks for your answer and apologies again for my limited knowledge
> Is there any way I can tell xmlsec1 to pick one them?
> 
> regards,
> 
> Carlo
> 
> On Tue, Jun 12, 2012 at 2:05 PM, Aleksey Sanin <aleksey at aleksey.com> wrote:
>> It depends on the certificate or to be precise pkcs12 file
>> you are signing with. Yours contains 3 certs.
>>
>> Aleksey
>>
>>
>> On 6/11/12 9:03 PM, Giancarlo Piva wrote:
>>> Aleksey
>>>
>>> My crypto knowledge is limited
>>> I am just trying to sign a document from the command line tool xmlsec1
>>> as proof of concept...
>>> before reading a book on cryptography.... I will better document
>>> myself for sure..
>>> and eventually read the manual.. and code my client using the xmlsec library...
>>> I was looking only for a hint as your X509 example on the web site the
>>> output file have only one "X509Certificate" node
>>> when I run the same example the output I get have multiple
>>> "X509Certificate" nodes... I dont understand why?
>>>
>>> anyway thanks for your help
>>>
>>> Carlo
>>>
>>> On Tue, Jun 12, 2012 at 1:52 PM, Aleksey Sanin <aleksey at aleksey.com> wrote:
>>>> X509Certificate nodes do not contain signatures. You might want
>>>> to read a book on cryptography.
>>>>
>>>> Aleksey
>>>>
>>>>
>>>> On 6/11/12 8:50 PM, Giancarlo Piva wrote:
>>>>> Hi Alekey
>>>>>
>>>>> That is right and that is what I am expecting as well..
>>>>>
>>>>> I tried to run my command using your xml on the web site:
>>>>>
>>>>> xmlsec1 --sign --output test.xml --pkcs12
>>>>> ./certs/8003620833337558-general.p12 --pwd Password --trusted-pem
>>>>> ./certs/output.pem ./xml/template_test.xml
>>>>>
>>>>> in the output I get multiple <X509Certificate> nodes is that normal??
>>>>>
>>>>> this is what i get:
>>>>>
>>>>> <?xml version="1.0"?>
>>>>> <References>
>>>>>  <Book>
>>>>>   <Author>
>>>>>    <FirstName>Bruce</FirstName>
>>>>>    <LastName>Schneier</LastName>
>>>>>   </Author>
>>>>>   <Title>Applied Cryptography</Title>
>>>>>  </Book>
>>>>>  <Web>
>>>>>   <Title>XMLSec</Title>
>>>>>   <Url>http://www.aleksey.com/xmlsec/</Url>
>>>>>  </Web>
>>>>>  <Signature xmlns="http://www.w3.org/2000/09/xmldsig#">
>>>>>   <SignedInfo>
>>>>>    <CanonicalizationMethod
>>>>> Algorithm="http://www.w3.org/TR/2001/REC-xml-c14n-20010315"/>
>>>>>    <SignatureMethod Algorithm="http://www.w3.org/2000/09/xmldsig#rsa-sha1"/>
>>>>>    <Reference URI="">
>>>>>     <Transforms>
>>>>>      <Transform
>>>>> Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature"/>
>>>>>     </Transforms>
>>>>>     <DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/>
>>>>>     <DigestValue>o/5EifW/Q4LVtDznvqMgBAAC21M=</DigestValue>
>>>>>    </Reference>
>>>>>   </SignedInfo>
>>>>>   <SignatureValue>jk5S8exrQmxJPwBtz4YsEY3+zhWpAaRYW2rJNRLoo7+Rkq7PWoOAkHki63Gx5BEb
>>>>> CSmk8bQ5jjqDLoxrbFVsYCmKQiiEpq+r8Kup9lyReA9aA4PRu/FpxufkPYqBXpfN
>>>>> YML85F+LCoG44xt4LQMwaZtdE7H1KX3HZ1EX3Q+yIxoVxVp2HQjO9Y+3OJUlXUGk
>>>>> t0yn/q11H/AV4mmZ2CWK+4uUKySYTg0KEhu/Z3RpG/S2VX3zHPUg769bQy/1Bihq
>>>>> 3bwyO4INAHgP3dMjuc+iTJMMLChy/ZA5zahs5npfmWKFyJSw0ggMApZsRN4Mf8s8
>>>>> oDNtKPTja7/HbFBwdbiSdA==</SignatureValue>
>>>>>   <KeyInfo>
>>>>>    <X509Data>
>>>>>
>>>>>
>>>>>
>>>>>    <X509Certificate>MIIHLDCCBhSgAwIBAgIETXl5dTANBgkqhkiG9w0BAQUFADAyMQswCQYDVQQGEwJB
>>>>> VTESMBAGA1UEChMJTkVIVEFEZW1vMQ8wDQYDVQQLEwZSb290Q0EwHhcNMTEwNjAy
>>>>> MTUyMjQwWhcNMjEwMzExMDA0NjMzWjAxMQswCQYDVQQGEwJBVTESMBAGA1UEChMJ
>>>>> TkVIVEFEZW1vMQ4wDAYDVQQLEwVTdWJDQTCCASIwDQYJKoZIhvcNAQEBBQADggEP
>>>>> ADCCAQoCggEBAN9Zc8dkNxg9pEaPRxx9Z5H8Fsxt5G7QTXhuVSqwFsxOJNLiuQq+
>>>>> Z7q9fr8nry9ulmLj9HgGiPpMqQuFhbRH0aM2kSWhiZtjybVK4d52zwiapa+WcabG
>>>>> djg8ZRZaevV6wRflwESUdyRM0g+Re8Bc+u8vEli7spKJgVNf31hvo3/zmIqiR3Vs
>>>>> YFMeT9NgqWC/rUmguwScS4v5ZLBHaJG3WfPemTvmkd8iKxxTchG0uYhoBYtOd2Gc
>>>>> vcLcj/ZWY3GRcJZIMKTIy34yWhIr1G95ZfdAD5TGfrGrv5WOgTRNGln7Kb00sedZ
>>>>> UpyIfYMeR6X6tbVsqLquS8yPgrKCc+2a9UsCAwEAAaOCBEkwggRFMA4GA1UdDwEB
>>>>> /wQEAwIBBjASBgNVHRMBAf8ECDAGAQH/AgEAMIICcAYDVR0gBIICZzCCAmMwggHY
>>>>> BgwqJAGPUYdqAQEBAQEwggHGMGgGCCsGAQUFBwIBFlxodHRwOi8vcG9saWN5LnBy
>>>>> b2Ryb290aGlnaDEucGtpLmVsZWN0cm9uaWNoZWFsdGgubmV0LmF1L3Byb2Ryb290
>>>>> aGlnaDEvcG9saWN5L05BU0hfUkNBX0NQLnBkZjCCAVgGCCsGAQUFBwICMIIBShqC
>>>>> AUZDZXJ0aWZpY2F0ZXMgdW5kZXIgdGhpcyBwb2xpY3kgYXJlIGlzc3VlZCBieSB0
>>>>> aGUgTkFTSCBSb290IENBIHRvIGl0c2VsZiBhbmQgdG8gQ0FzIHN1Ym9yZGluYXRl
>>>>> IHRvIHRoZSBOQVNIIFJvb3QgQ0EuIFJlZmVyIHRvIGh0dHA6Ly9wcm9kcm9vdGhp
>>>>> Z2gxLnBraS5lbGVjdHJvbmljaGVhbHRoLm5ldC5hdS9wcm9kcm9vdGhpZ2gxLyBm
>>>>> b3IgbW9yZSBpbmZvcm1hdGlvbi4gVXNlIG9mIHRoaXMgQ2VydGlmaWNhdGUgaXMg
>>>>> c3ViamVjdCB0byBBZ3JlZW1lbnRzIGF0IGh0dHA6Ly9wcm9kcm9vdGhpZ2gxLnBr
>>>>> aS5lbGVjdHJvbmljaGVhbHRoLm5ldC5hdS9wcm9kcm9vdGhpZ2gxLzAqBgkqJAGP
>>>>> UYdqBQIwHTAbBggrBgEFBQcCAjAPGg1Mb3cgQXNzdXJhbmNlMC8GCSokAY9Rh2oF
>>>>> AzAiMCAGCCsGAQUFBwICMBQaEk1vZGVyYXRlIEFzc3VyYW5jZTAoBgoqJAGPUYdq
>>>>> BgQAMBowGAYIKwYBBQUHAgIwDBoKSXNzdWluZyBDQTCBswYIKwYBBQUHAQEEgaYw
>>>>> gaMwVQYIKwYBBQUHMAKGSWh0dHA6Ly9uZWh0YWRlbW8ubWFuYWdlZC5lbnRydXN0
>>>>> LmNvbS9BSUEvQ2VydHNJc3N1ZWR0b05FSFRBRGVtb1Jvb3RDQS5wN2MwSgYIKwYB
>>>>> BQUHMAGGPmh0dHA6Ly9uZWh0YWRlbW8ubWFuYWdlZC5lbnRydXN0LmNvbS9PQ1NQ
>>>>> L05FSFRBUm9vdENBUmVzcG9uZGVyMIGZBgNVHR8EgZEwgY4wQaA/oD2GO2h0dHA6
>>>>> Ly9uZWh0YWRlbW8ubWFuYWdlZC5lbnRydXN0LmNvbS9DUkxzL05FSFRBREVNT1Jv
>>>>> b3QuY3JsMEmgR6BFpEMwQTELMAkGA1UEBhMCQVUxEjAQBgNVBAoTCU5FSFRBRGVt
>>>>> bzEPMA0GA1UECxMGUm9vdENBMQ0wCwYDVQQDEwRDUkwxMB8GA1UdIwQYMBaAFBDg
>>>>> Yh+sUVo0ZnLXWMH0NWk/6JFbMB0GA1UdDgQWBBRaPSKrShmC/GJzkLtwm/s56ZsS
>>>>> rDAZBgkqhkiG9n0HQQAEDDAKGwRWOC4xAwIAgTANBgkqhkiG9w0BAQUFAAOCAQEA
>>>>> XQTFvV+bBpJshxlfy9bm1gq2ZALukwYPkVB8GhKM43yqT+ZbxwC0im8PYNhbvzRB
>>>>> lzo5b50mfZcYaC97Ey5zs511qvyFAiJuZdtPTtmrEw10G+uyGqdLjL+OZTcyVwk3
>>>>> 8KAYAaSxc7BhBGxsnLf01bKUmK1HSj2anrKk/81PLIaJId2L7IfcrZFi+OlUZfAK
>>>>> THa5ayk8fxu/pI1WjHQy6+HW1IfDmKQJz+uVbTIq03XmuCW4Bwd3U2qjFhtVuQd3
>>>>> TjWcRm05d+1p/LSAKFH+jSzorewiG+URvef8Lznwbg/ChbNSaRnlLV9WQqBMsELZ
>>>>> 54vPc3pZhOkfrthJYni8jA==</X509Certificate>
>>>>> <X509SubjectName>OU=SubCA,O=NEHTADemo,C=AU</X509SubjectName>
>>>>> <X509IssuerSerial>
>>>>> <X509IssuerName>OU=RootCA,O=NEHTADemo,C=AU</X509IssuerName>
>>>>> <X509SerialNumber>1299806581</X509SerialNumber>
>>>>> </X509IssuerSerial>
>>>>> <X509Certificate>MIIDJDCCAgygAwIBAgIETXlw6TANBgkqhkiG9w0BAQUFADAyMQswCQYDVQQGEwJB
>>>>> VTESMBAGA1UEChMJTkVIVEFEZW1vMQ8wDQYDVQQLEwZSb290Q0EwHhcNMTEwMzEx
>>>>> MDAxNjMzWhcNMjEwMzExMDA0NjMzWjAyMQswCQYDVQQGEwJBVTESMBAGA1UEChMJ
>>>>> TkVIVEFEZW1vMQ8wDQYDVQQLEwZSb290Q0EwggEiMA0GCSqGSIb3DQEBAQUAA4IB
>>>>> DwAwggEKAoIBAQCz3qq/Tw5CkP+gQl+uhyislJauKGzJS/uyTveAjnuqzdTR4+bC
>>>>> MFeMjIH3da770r2n52MtLgYxhCo50YJzaAKAchV2+GDK0q+KRnut7d+obSamr9Vp
>>>>> fMFtYctNvZFaRpPKCOqyz7WfOleOmtaNLv26CUnszM4/nZBcD7CNuoItyX81e4a0
>>>>> edMFvg3rqIv7OPg+NSDNYpnBB9rdmbSe1FCLBERon5gsdPGFzh8x5DLtMpZZCwL6
>>>>> Q1srclXWLMpnfMAgXDcH8FaLGHVYSfsrHQh9uCCuoV602eic+SgE66/xQ5Uy/OHV
>>>>> oZJeB1bLzAk2OxIo8pHuVCMeH178xCI1tAGdAgMBAAGjQjBAMA4GA1UdDwEB/wQE
>>>>> AwIBBjAPBgNVHRMBAf8EBTADAQH/MB0GA1UdDgQWBBQQ4GIfrFFaNGZy11jB9DVp
>>>>> P+iRWzANBgkqhkiG9w0BAQUFAAOCAQEAcMwGYh5iXTWjYev2+Mmm5IIUD9xRntah
>>>>> qWo/lNsWP/Lb3dVpdyxQ5hQt/nFmER7SkXHZT394/deWCdh3E2LE6AE2cIZuQYr+
>>>>> 1aHbKWYeAkCnHUjdzszuZ2bEp9FW4Y0+dlH4V71LnobHwWQre/PZFTFNlZjf1xYF
>>>>> giI5YK2MeOSsWaB2ACPkq4gDY4JnsNKK3QCX2xR/zeSG1l3Zjp8A07Z0ldvUiwfa
>>>>> IFGo8rkHkbbNifCco7d8+6NPiy0qwTG5/Htt9hb7pJ5IStoLSX6AAzKevt/GaRga
>>>>> xChYv35zMQF6Bgjkk8LXsQiA2oi8r995oFTKCDbDMYdksyK7FyoFHQ==</X509Certificate>
>>>>> <X509SubjectName>OU=RootCA,O=NEHTADemo,C=AU</X509SubjectName>
>>>>> <X509IssuerSerial>
>>>>> <X509IssuerName>OU=RootCA,O=NEHTADemo,C=AU</X509IssuerName>
>>>>> <X509SerialNumber>1299804393</X509SerialNumber>
>>>>> </X509IssuerSerial>
>>>>> <X509Certificate>MIIIvjCCB6agAwIBAgIETXqLsTANBgkqhkiG9w0BAQUFADAxMQswCQYDVQQGEwJB
>>>>> VTESMBAGA1UEChMJTkVIVEFEZW1vMQ4wDAYDVQQLEwVTdWJDQTAeFw0xMjAzMDUw
>>>>> MTQyNDlaFw0xMzAzMDUwMDAwMDBaMIGfMRIwEAYKCZImiZPyLGQBGRYCQVUxEzAR
>>>>> BgoJkiaJk/IsZAEZFgNORVQxIDAeBgoJkiaJk/IsZAEZFhBFTEVDVFJPTklDSEVB
>>>>> TFRIMRQwEgYDVQQKEwtNZWRpY2FyZTMwNTE8MDoGA1UEAxMzZ2VuZXJhbC44MDAz
>>>>> NjIwODMzMzM3NTU4LmlkLmVsZWN0cm9uaWNoZWFsdGgubmV0LmF1MIIBIjANBgkq
>>>>> hkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA21303diBXMqVg0Z366xYZc4qCTeHd9zf
>>>>> oHWJRAd7/YQlfMu3q21sb7MqQI3N88bmQxICn2tg5HRPKh8rB9RqGT8gzGpKiMbz
>>>>> KFxz81dzzj87gkYkLF57WiuKARKqp98nx2mTIELKcN1ahejHbo2cVjHpkQ+m17Dt
>>>>> TZJ5sUxna2OT6+qTWEBlilnjsiit2M96iNs1/Y4eySRRCDKNXF2virN/5cqzjfRk
>>>>> iKTwfgKNQ09MNeCN+wl588JKuGmIzZ8kKQveXzHEvS9eUFQid1ZOVy8x+0jeoUHO
>>>>> YTNoRb1wckdtV7eFFx5fERE/KuTvjvMchCBezZWYz0WwUXiSKX0/qQIDAQABo4IF
>>>>> bTCCBWkwDgYDVR0PAQH/BAQDAgSwMIIBMAYIKwYBBQUHAQEEggEiMIIBHjBJBggr
>>>>> BgEFBQcwAYY9aHR0cDovL25laHRhZGVtby5tYW5hZ2VkLmVudHJ1c3QuY29tL09D
>>>>> U1AvTkVIVEFTdWJDQVJlc3BvbmRlcjBUBggrBgEFBQcwAoZIaHR0cDovL25laHRh
>>>>> ZGVtby5tYW5hZ2VkLmVudHJ1c3QuY29tL0FJQS9DZXJ0c0lzc3VlZHRvTkVIVEFE
>>>>> ZW1vU3ViQ0EucDdjMHsGCCsGAQUFBzAChm9sZGFwOi8vbmVodGFkZW1vLm1hbmFn
>>>>> ZWQuZW50cnVzdC5jb20vb3U9U3ViQ0Esbz1ORUhUQURlbW8sYz1BVT9jQUNlcnRp
>>>>> ZmljYXRlO2JpbmFyeSxjcm9zc0NlcnRpZmljYXRlUGFpcjtiaW5hcnkwHQYDVR0l
>>>>> BBYwFAYIKwYBBQUHAwEGCCsGAQUFBwMCMAwGA1UdEwEB/wQCMAAwggIyBgNVHSAE
>>>>> ggIpMIICJTCCAcQGDCokAY9Rh2oBAwEEAzCCAbIwZQYIKwYBBQUHAgEWWWh0dHA6
>>>>> Ly9wb2xpY3kudGVzdHN1Ym1vZDEucGtpLmVsZWN0cm9uaWNoZWFsdGgubmV0LmF1
>>>>> L3Rlc3RzdWJtb2QxL3BvbGljeS9OQVNIX0hQSU9fQ1AucGRmMIIBRwYIKwYBBQUH
>>>>> AgIwggE5GoIBNUNlcnRpZmljYXRlcyB1bmRlciB0aGlzIHBvbGljeSBhcmUgaXNz
>>>>> dWVkIGJ5IHRoZSBOQVNIIFN1Ym9yZGluYXRlIENBIHRvIEhlYWx0aGNhcmUgUHJv
>>>>> dmlkZXIgT3JnYW5pc2F0aW9ucy4gUmVmZXIgdG8gaHR0cDovL3Rlc3RzdWJtb2Qx
>>>>> LnBraS5lbGVjdHJvbmljaGVhbHRoLm5ldC5hdS90ZXN0c3VibW9kMS8gZm9yIG1v
>>>>> cmUgaW5mb3JtYXRpb24uIFVzZSBvZiB0aGlzIENlcnRpZmljYXRlIGlzIHN1Ympl
>>>>> Y3QgdG8gQWdyZWVtZW50cyBhdCBodHRwOi8vdGVzdHN1Ym1vZDEucGtpLmVsZWN0
>>>>> cm9uaWNoZWFsdGgubmV0LmF1L3Rlc3RzdWJtb2QxLzAqBgkqJAGPUYdqBQIwHTAb
>>>>> BggrBgEFBQcCAjAPGg1Mb3cgQXNzdXJhbmNlMC8GCiokAY9Rh2oGBwMwITAfBggr
>>>>> BgEFBQcCAjATGhFXZWJTZXJ2aWNlIERldmljZTCBgQYDVR0RBHoweIIzZ2VuZXJh
>>>>> bC44MDAzNjIwODMzMzM3NTU4LmlkLmVsZWN0cm9uaWNoZWFsdGgubmV0LmF1hkFo
>>>>> dHRwOi8vbnMuZWxlY3Ryb25pY2hlYWx0aC5uZXQuYXUvaWQvaGkvaHBpby8xLjAv
>>>>> ODAwMzYyMDgzMzMzNzU1ODCB+wYDVR0fBIHzMIHwMIGjoIGgoIGdhjpodHRwOi8v
>>>>> bmVodGFkZW1vLm1hbmFnZWQuZW50cnVzdC5jb20vQ1JMcy9ORUhUQURFTU9TdWIu
>>>>> Y3Jshl9sZGFwOi8vbmVodGFkZW1vLm1hbmFnZWQuZW50cnVzdC5jb20vb3U9U3Vi
>>>>> Q0Esbz1ORUhUQURlbW8sYz1BVT9jZXJ0aWZpY2F0ZVJldm9jYXRpb25MaXN0O2Jp
>>>>> bmFyeTBIoEagRKRCMEAxCzAJBgNVBAYTAkFVMRIwEAYDVQQKEwlORUhUQURlbW8x
>>>>> DjAMBgNVBAsTBVN1YkNBMQ0wCwYDVQQDEwRDUkw4MB8GA1UdIwQYMBaAFFo9IqtK
>>>>> GYL8YnOQu3Cb+znpmxKsMB0GA1UdDgQWBBTJ0D/1ayPl4d+NQZLxTUdJVGr/ZDAN
>>>>> BgkqhkiG9w0BAQUFAAOCAQEAEFvbTBlGeI1rj8mNZDQtoNN7pFdR1WH3N1Exbcez
>>>>> +zoUncZXAIqmvVG/pTxuDpaLx2Kg+JIBbYZSvFp/RRiea3DuV416c7yqcsbfBhMO
>>>>> pwqZs8e0UUKKMugrSy7Z2DXCTjGlxNw9gR8QDdz+ddn98dRqAlh/UV289sFBNEbK
>>>>> 5PLtjgtUxhqzn9CKmxgLO2RUkIJvWmVDRF+SvOzb8/QcGk3OX3YlWFlMeTsaHMyK
>>>>> KKnbmkrGRlj1sfK4OUWmdaLKWbIhvA2eBf5iHlwSiZ0I2LuXp2TI29KCPmCaHmkd
>>>>> h1AZzEQWh1sXCpUScS+dNkKaJiqMvuPRVBFniv5W/XZjNg==</X509Certificate>
>>>>> <X509SubjectName>CN=general.8003620833337558.id.electronichealth.net.au,O=Medicare305,DC=ELECTRONICHEALTH,DC=NET,DC=AU</X509SubjectName>
>>>>> <X509IssuerSerial>
>>>>> <X509IssuerName>OU=SubCA,O=NEHTADemo,C=AU</X509IssuerName>
>>>>> <X509SerialNumber>1299876785</X509SerialNumber>
>>>>> </X509IssuerSerial>
>>>>> </X509Data>
>>>>>    <KeyValue>
>>>>> <RSAKeyValue>
>>>>> <Modulus>
>>>>> 21303diBXMqVg0Z366xYZc4qCTeHd9zfoHWJRAd7/YQlfMu3q21sb7MqQI3N88bm
>>>>> QxICn2tg5HRPKh8rB9RqGT8gzGpKiMbzKFxz81dzzj87gkYkLF57WiuKARKqp98n
>>>>> x2mTIELKcN1ahejHbo2cVjHpkQ+m17DtTZJ5sUxna2OT6+qTWEBlilnjsiit2M96
>>>>> iNs1/Y4eySRRCDKNXF2virN/5cqzjfRkiKTwfgKNQ09MNeCN+wl588JKuGmIzZ8k
>>>>> KQveXzHEvS9eUFQid1ZOVy8x+0jeoUHOYTNoRb1wckdtV7eFFx5fERE/KuTvjvMc
>>>>> hCBezZWYz0WwUXiSKX0/qQ==
>>>>> </Modulus>
>>>>> <Exponent>
>>>>> AQAB
>>>>> </Exponent>
>>>>> </RSAKeyValue>
>>>>> </KeyValue>
>>>>>   </KeyInfo>
>>>>>  </Signature>
>>>>> </References>
>>>>>
>>>>>
>>>>>
>>>>> On Tue, Jun 12, 2012 at 12:53 PM, Aleksey Sanin <aleksey at aleksey.com> wrote:
>>>>>> Not sure what do you mean. There should be 3 digests and one signature.
>>>>>>
>>>>>> Aleksey
>>>>>>
>>>>>>
>>>>>> On 6/11/12 6:58 PM, Giancarlo Piva wrote:
>>>>>>> Hi Aleksey,
>>>>>>>
>>>>>>> I am tring to use xmlsec1 in linux to sign multiple parts of an xml
>>>>>>> document (header, body, timestamp)
>>>>>>> in my template i have 3 digests with 3 uris
>>>>>>> xmlsec works fine but I end up with three signature instead of one in
>>>>>>> the output file
>>>>>>>
>>>>>>> I am using xmlsec1 --sign --output test.xml --pkcs12 ./certs/cert.p12
>>>>>>> --pwd Password --trusted-pem ./certs/RootCA.crt ./xml/template.xml
>>>>>>>
>>>>>>> is there an option to sign multiple part of a doc via command line?
>>>>>>>
>>>>>>> Kind Regards,
>>>>>>>
>>>>>>> Carlo
>>>>>>>
>>>>>>
>>>>
>>


From akitsukineko at gmail.com  Mon Jun 11 22:37:07 2012
From: akitsukineko at gmail.com (Neko)
Date: Tue, 12 Jun 2012 13:37:07 +0800
Subject: [xmlsec] Question about signature RSA-SHA1
Message-ID: <CAPpBuXiGOGVjaoMRiNNBFWadnPqXQ5sECwjVDj0mXx6YWxqF0g@mail.gmail.com>

Dear Aleksey

I computed the signature value with OpenSSL, while the result doesn't match
with xmlsec
I checked the message actually signed when xmlsec perform signature with
--store-signatures, it's no problem.

What I did with OpenSSL
RSA_sign(NID_sha1, digest of signinfo node, length of the digest, signature
value buff, length of signature, rsa key);
(and it can be verified with RSA_verify() too)

And I tried to trace the source code of xmlsec, I didn't find any
RSA_sign() used, but I found a lot of RSA_public_encrypt() instead.
I'm wondering if there's something I missed?

Thank you
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.aleksey.com/pipermail/xmlsec/attachments/20120612/14e381fd/attachment.html>

From re.tf at acm.org  Tue Jun 12 05:08:17 2012
From: re.tf at acm.org (Renato Tegon Forti)
Date: Tue, 12 Jun 2012 09:08:17 -0300
Subject: [xmlsec] RES:  CGI Source Code Sample!
In-Reply-To: <4FD6837F.2@aleksey.com>
References: <00fc01cd435d$f7ce89e0$e76b9da0$@acm.org>
 <4FCEC586.3010703@aleksey.com> <012001cd43d9$77e0fc50$67a2f4f0$@acm.org>
 <4FCFAC50.7060902@aleksey.com> <01db01cd44e3$df87b410$9e971c30$@acm.org>
 <4FD10461.6070305@aleksey.com> <01eb01cd44e7$442a9d30$cc7fd790$@acm.org>
 <4FD113F5.3050907@aleksey.com> <4FD67E04.1000805@acm.org>
 <4FD6837F.2@aleksey.com>
Message-ID: <00c601cd4894$0de9d3c0$29bd7b40$@acm.org>

In xmldsigverify.c you use "keys-certs.def"
(/var/www/cgi-bin/keys-certs.def) on 

>> #define XMLDSIGVERIFY_DEFAULT_TRUSTED_CERTS_FOLDER
"/var/www/cgi-bin/keys-certs.def"
>> if(xmlSecCryptoAppInit(XMLDSIGVERIFY_DEFAULT_TRUSTED_CERTS_FOLDER) < 0)
...

I would like to know, What is its purpose? Where can I find it on source
code!

Thanks again!!! :0)



-----Mensagem original-----
De: Aleksey Sanin [mailto:aleksey at aleksey.com] 
Enviada em: segunda-feira, 11 de junho de 2012 20:47
Para: re.tf at acm.org
Cc: xmlsec at aleksey.com
Assunto: Re: [xmlsec] CGI Source Code Sample!

xmlsec1/examples/xmldsigverify.c

Aleksey


On 6/11/12 4:23 PM, Renato Forti wrote:
> any place has the soucer code of cgi used in online xmldsig-verifier?
> (http://www.aleksey.com/xmlsec/xmldsig-verifier.html)
> 
> Thanks
> _______________________________________________
> xmlsec mailing list
> xmlsec at aleksey.com
> http://www.aleksey.com/mailman/listinfo/xmlsec



From re.tf at acm.org  Tue Jun 12 05:54:13 2012
From: re.tf at acm.org (Renato Tegon Forti)
Date: Tue, 12 Jun 2012 09:54:13 -0300
Subject: [xmlsec] Help to decode this error message!
Message-ID: <00ca01cd489a$78b4ca10$6a1e5e30$@acm.org>

Hi I need help to decode this error msg!

 

Certs that I load: 

 

/usr/lib/ssl/certs/Serasa_Certificadora_Digital_v2.pem

/usr/lib/ssl/certs/Serasa_Autoridade_Certificadora_Principal_v2.pem

/usr/lib/ssl/certs/Autoridade_Certificadora_Raiz_Brasileira_v2.pem

[ loaded cert with:  xmlSecCryptoAppKeysMngrCertLoad(mngr, certs[i].c_str(),
xmlSecKeyDataFormatPem, xmlSecKeyDataTypeTrusted) ]

 

ubuntu at ip-10-248-26-61:/Projects/project.dokfile.vses/hades/trunk/products/d
oksafe/engine/libs/xmldsig/test/bin/xmldsig_test.test/gcc-4.6/debug/threadin
g-multi$ sudo ./xmldsig_test

 

========================================================================

I need understand this:

========================================================================

 

func=xmlSecOpenSSLX509StoreVerify:file=x509vfy.c:line=360:obj=x509-store:sub
j=X509_verify_cert:error=4:crypto library function
failed:subj=/C=BR/O=ICP-Brasil/OU=Autoridade Certificadora Raiz Brasileira
v2/CN=SERASA Autoridade Certificadora Principal v2;err=7;msg=certificate
signature failure (? I load it! Why this error?)

func=xmlSecOpenSSLX509StoreVerify:file=x509vfy.c:line=408:obj=x509-store:sub
j=unknown:error=71:certificate verification failed:err=7;msg=certificate
signature failure (? Again!)

func=xmlSecOpenSSLX509StoreVerify:file=x509vfy.c:line=360:obj=x509-store:sub
j=X509_verify_cert:error=4:crypto library function
failed:subj=/C=BR/O=ICP-Brasil/OU=Autoridade Certificadora Raiz Brasileira
v2/CN=SERASA Autoridade Certificadora Principal v2;err=7;msg=certificate
signature failure (? Again!)

func=xmlSecOpenSSLX509StoreVerify:file=x509vfy.c:line=408:obj=x509-store:sub
j=unknown:error=71:certificate verification failed:err=7;msg=certificate
signature failure (? Again!)

func=xmlSecKeysMngrGetKey:file=keys.c:line=1370:obj=unknown:subj=xmlSecKeysM
ngrFindKey:error=1:xmlsec library function failed:

func=xmlSecDSigCtxProcessKeyInfoNode:file=xmldsig.c:line=871:obj=unknown:sub
j=unknown:error=45:key is not found: (? What this mean?!)

func=xmlSecDSigCtxProcessSignatureNode:file=xmldsig.c:line=565:obj=unknown:s
ubj=xmlSecDSigCtxProcessKeyInfoNode:error=1:xmlsec library function failed:

func=xmlSecDSigCtxVerify:file=xmldsig.c:line=366:obj=unknown:subj=xmlSecDSig
CtxSigantureProcessNode:error=1:xmlsec library function failed:

Error: signature verify

func=xmlSecDSigCtxDebugXmlDump:file=xmldsig.c:line=1148:obj=unknown:subj=out
put != NULL:error=100:assertion:

func=xmlSecDSigCtxDebugDump:file=xmldsig.c:line=1068:obj=unknown:subj=output
!= NULL:error=100:assertion:

xmldsig_test.cpp(435): test verify_xmldsig() == 0 failed in function: 'int
do_test_xmlsec()'

 

**** 1 error detected

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.aleksey.com/pipermail/xmlsec/attachments/20120612/6a3635bc/attachment-0001.html>

From aleksey at aleksey.com  Tue Jun 12 08:56:54 2012
From: aleksey at aleksey.com (Aleksey Sanin)
Date: Tue, 12 Jun 2012 08:56:54 -0700
Subject: [xmlsec] Question about signature RSA-SHA1
In-Reply-To: <CAPpBuXiGOGVjaoMRiNNBFWadnPqXQ5sECwjVDj0mXx6YWxqF0g@mail.gmail.com>
References: <CAPpBuXiGOGVjaoMRiNNBFWadnPqXQ5sECwjVDj0mXx6YWxqF0g@mail.gmail.com>
Message-ID: <4FD766C6.5050200@aleksey.com>

Neko,

You might want to read the details on the PCKCS1 format used
by XML Digital Signature spec here

http://www.w3.org/TR/xmldsig-core/#sec-SignatureAlg

Best,

Aleksey


On 6/11/12 10:37 PM, Neko wrote:
> Dear Aleksey
> 
> I computed the signature value with OpenSSL, while the result doesn't
> match with xmlsec
> I checked the message actually signed when xmlsec perform signature with
> --store-signatures, it's no problem.
> 
> What I did with OpenSSL
> RSA_sign(NID_sha1, digest of signinfo node, length of the digest,
> signature value buff, length of signature, rsa key);
> (and it can be verified with RSA_verify() too)
> 
> And I tried to trace the source code of xmlsec, I didn't find any
> RSA_sign() used, but I found a lot of RSA_public_encrypt() instead.
> I'm wondering if there's something I missed?
> 
> Thank you
> 
> 
> _______________________________________________
> xmlsec mailing list
> xmlsec at aleksey.com
> http://www.aleksey.com/mailman/listinfo/xmlsec
> 


From aleksey at aleksey.com  Tue Jun 12 08:57:42 2012
From: aleksey at aleksey.com (Aleksey Sanin)
Date: Tue, 12 Jun 2012 08:57:42 -0700
Subject: [xmlsec] RES:  CGI Source Code Sample!
In-Reply-To: <00c601cd4894$0de9d3c0$29bd7b40$@acm.org>
References: <00fc01cd435d$f7ce89e0$e76b9da0$@acm.org>
 <4FCEC586.3010703@aleksey.com> <012001cd43d9$77e0fc50$67a2f4f0$@acm.org>
 <4FCFAC50.7060902@aleksey.com> <01db01cd44e3$df87b410$9e971c30$@acm.org>
 <4FD10461.6070305@aleksey.com> <01eb01cd44e7$442a9d30$cc7fd790$@acm.org>
 <4FD113F5.3050907@aleksey.com> <4FD67E04.1000805@acm.org>
 <4FD6837F.2@aleksey.com> <00c601cd4894$0de9d3c0$29bd7b40$@acm.org>
Message-ID: <4FD766F6.7010901@aleksey.com>

This is just a set of certs for testing. Same as in the tests/keys folder

Aleksey


On 6/12/12 5:08 AM, Renato Tegon Forti wrote:
> In xmldsigverify.c you use "keys-certs.def"
> (/var/www/cgi-bin/keys-certs.def) on 
> 
>>> #define XMLDSIGVERIFY_DEFAULT_TRUSTED_CERTS_FOLDER
> "/var/www/cgi-bin/keys-certs.def"
>>> if(xmlSecCryptoAppInit(XMLDSIGVERIFY_DEFAULT_TRUSTED_CERTS_FOLDER) < 0)
> ...
> 
> I would like to know, What is its purpose? Where can I find it on source
> code!
> 
> Thanks again!!! :0)
> 
> 
> 
> -----Mensagem original-----
> De: Aleksey Sanin [mailto:aleksey at aleksey.com] 
> Enviada em: segunda-feira, 11 de junho de 2012 20:47
> Para: re.tf at acm.org
> Cc: xmlsec at aleksey.com
> Assunto: Re: [xmlsec] CGI Source Code Sample!
> 
> xmlsec1/examples/xmldsigverify.c
> 
> Aleksey
> 
> 
> On 6/11/12 4:23 PM, Renato Forti wrote:
>> any place has the soucer code of cgi used in online xmldsig-verifier?
>> (http://www.aleksey.com/xmlsec/xmldsig-verifier.html)
>>
>> Thanks
>> _______________________________________________
>> xmlsec mailing list
>> xmlsec at aleksey.com
>> http://www.aleksey.com/mailman/listinfo/xmlsec
> 
> 


From aleksey at aleksey.com  Tue Jun 12 08:58:13 2012
From: aleksey at aleksey.com (Aleksey Sanin)
Date: Tue, 12 Jun 2012 08:58:13 -0700
Subject: [xmlsec] Help to decode this error message!
In-Reply-To: <00ca01cd489a$78b4ca10$6a1e5e30$@acm.org>
References: <00ca01cd489a$78b4ca10$6a1e5e30$@acm.org>
Message-ID: <4FD76715.8090008@aleksey.com>

The code can't verify the signature on the certificate. No idea why.

Aleksey


On 6/12/12 5:54 AM, Renato Tegon Forti wrote:
> Hi I need help to decode this error msg!
> 
>  
> 
> Certs that I load:
> 
>  
> 
> /usr/lib/ssl/certs/Serasa_Certificadora_Digital_v2.pem
> 
> /usr/lib/ssl/certs/Serasa_Autoridade_Certificadora_Principal_v2.pem
> 
> /usr/lib/ssl/certs/*/Autoridade_Certificadora_Raiz_Brasileira_v2.pem/*
> 
> [ loaded cert with:  xmlSecCryptoAppKeysMngrCertLoad(mngr,
> certs[i].c_str(), xmlSecKeyDataFormatPem, xmlSecKeyDataTypeTrusted) ]
> 
>  
> 
> ubuntu at ip-10-248-26-61:/Projects/project.dokfile.vses/hades/trunk/products/doksafe/engine/libs/xmldsig/test/bin/xmldsig_test.test/gcc-4.6/debug/threading-multi$
> sudo ./xmldsig_test
> 
>  
> 
> ========================================================================
> 
> I need understand this:
> 
> ========================================================================
> 
>  
> 
> func=xmlSecOpenSSLX509StoreVerify:file=x509vfy.c:line=360:obj=x509-store:subj=X509_verify_cert:error=4:crypto
> library function failed:subj=/C=BR/O=ICP-Brasil/OU=*/Autoridade
> Certificadora Raiz Brasileira v2/*/CN=SERASA Autoridade Certificadora
> Principal v2;err=7;msg=*certificate signature failure (**?**I load it!
> Why this error?)*
> 
> func=xmlSecOpenSSLX509StoreVerify:file=x509vfy.c:line=408:obj=x509-store:subj=unknown:error=71:certificate
> verification failed:err=7;msg=*certificate signature failure (**?**Again!)*
> 
> func=xmlSecOpenSSLX509StoreVerify:file=x509vfy.c:line=360:obj=x509-store:subj=X509_verify_cert:error=4:crypto
> library function failed:subj=/C=BR/O=ICP-Brasil/OU=Autoridade
> Certificadora Raiz Brasileira v2/CN=SERASA Autoridade Certificadora
> Principal v2;err=7;msg=certificate signature failure *(**? Again!)*
> 
> func=xmlSecOpenSSLX509StoreVerify:file=x509vfy.c:line=408:obj=x509-store:subj=unknown:error=71:certificate
> verification failed:err=7;msg=certificate signature failure *(**?**Again!)*
> 
> func=xmlSecKeysMngrGetKey:file=keys.c:line=1370:obj=unknown:subj=xmlSecKeysMngrFindKey:error=1:xmlsec
> library function failed:
> 
> func=xmlSecDSigCtxProcessKeyInfoNode:file=xmldsig.c:line=871:obj=unknown:subj=unknown:error=45:key
> is not found: *(**?**What this mean?!)*
> 
> func=xmlSecDSigCtxProcessSignatureNode:file=xmldsig.c:line=565:obj=unknown:subj=xmlSecDSigCtxProcessKeyInfoNode:error=1:xmlsec
> library function failed:
> 
> func=xmlSecDSigCtxVerify:file=xmldsig.c:line=366:obj=unknown:subj=xmlSecDSigCtxSigantureProcessNode:error=1:xmlsec
> library function failed:
> 
> Error: signature verify
> 
> func=xmlSecDSigCtxDebugXmlDump:file=xmldsig.c:line=1148:obj=unknown:subj=output
> != NULL:error=100:assertion:
> 
> func=xmlSecDSigCtxDebugDump:file=xmldsig.c:line=1068:obj=unknown:subj=output
> != NULL:error=100:assertion:
> 
> xmldsig_test.cpp(435): test verify_xmldsig() == 0 failed in function:
> 'int do_test_xmlsec()'
> 
>  
> 
> **** 1 error detected
> 
>  
> 
> 
> 
> _______________________________________________
> xmlsec mailing list
> xmlsec at aleksey.com
> http://www.aleksey.com/mailman/listinfo/xmlsec
> 


From leifj at mnt.se  Tue Jul 10 16:45:36 2012
From: leifj at mnt.se (Leif Johansson)
Date: Wed, 11 Jul 2012 01:45:36 +0200
Subject: [xmlsec] problem with raw-x509-cert
Message-ID: <4FFCBEA0.9050402@mnt.se>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1



I've run into a strange problem that manifests itself when I use the
python bindings for xmlsec [1] although from what I can tell (cf below)
the problem seems to be in libxmlsec.

The issue is related to the use of the "raw-x509-cert" data klass.

The python code calls xmlSecKeyReadBinaryFile to read a file containing
a DER encoded X509 certificate (1st arg is xmlSecKeyDataRawX509CertId).

In xmlSecKeyReadBinaryFile, xmlSecKeyReadBuffer is called which in
turn calls xmlSecKeyInfoCtxInitialize to initialize a xmlSecKeyInfoCtx.

Here is where it breaks for me!

This is what the call to xmlSecKeyInfoCtxInitialize in
xmlSecKeyReadBuffer looks like in version 1.2.18 (~ src/keys.c:1173):

ret = xmlSecKeyInfoCtxInitialize(&keyInfoCtx, NULL);

However almost immediately in xmlSecKeyInfoCtxInitialize there is this:

xmlSecAssert2(keyInfoCtx->keysMngr != NULL, -1);

which of course fails. Clearly this code-path can't work, right? Either
the assert is wrong or that keyInfoCtx needs a way to find its keysMngr.

	Cheers Leif


[1] http://pypi.python.org/pypi/dm.xmlsec.binding
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk/8vqAACgkQ8Jx8FtbMZneg2QCfawDcuBek2jVn8Nn7mJekF4rl
fQoAoLe6mnLTIfmpgl86J4hJ1oDOm+V9
=5V9B
-----END PGP SIGNATURE-----

From aleksey at aleksey.com  Tue Jul 10 17:53:49 2012
From: aleksey at aleksey.com (Aleksey Sanin)
Date: Tue, 10 Jul 2012 17:53:49 -0700
Subject: [xmlsec] problem with raw-x509-cert
In-Reply-To: <4FFCBEA0.9050402@mnt.se>
References: <4FFCBEA0.9050402@mnt.se>
Message-ID: <4FFCCE9D.2000409@aleksey.com>

Leif,

Not sure which code you are looking at for the

> However almost immediately in xmlSecKeyInfoCtxInitialize there
> is this:
>
> xmlSecAssert2(keyInfoCtx->keysMngr != NULL, -1);
>

This is how this code looks for me

int
xmlSecKeyInfoCtxInitialize(xmlSecKeyInfoCtxPtr keyInfoCtx,
xmlSecKeysMngrPtr keysMngr) {
    int ret;

    xmlSecAssert2(keyInfoCtx != NULL, -1);

    memset(keyInfoCtx, 0, sizeof(xmlSecKeyInfoCtx));
    keyInfoCtx->keysMngr = keysMngr;
    ....
}


Aleksey


On 7/10/12 4:45 PM, Leif Johansson wrote:
> 
> 
> I've run into a strange problem that manifests itself when I use the
> python bindings for xmlsec [1] although from what I can tell (cf below)
> the problem seems to be in libxmlsec.
> 
> The issue is related to the use of the "raw-x509-cert" data klass.
> 
> The python code calls xmlSecKeyReadBinaryFile to read a file containing
> a DER encoded X509 certificate (1st arg is xmlSecKeyDataRawX509CertId).
> 
> In xmlSecKeyReadBinaryFile, xmlSecKeyReadBuffer is called which in
> turn calls xmlSecKeyInfoCtxInitialize to initialize a xmlSecKeyInfoCtx.
> 
> Here is where it breaks for me!
> 
> This is what the call to xmlSecKeyInfoCtxInitialize in
> xmlSecKeyReadBuffer looks like in version 1.2.18 (~ src/keys.c:1173):
> 
> ret = xmlSecKeyInfoCtxInitialize(&keyInfoCtx, NULL);
> 
> However almost immediately in xmlSecKeyInfoCtxInitialize there is this:
> 
> xmlSecAssert2(keyInfoCtx->keysMngr != NULL, -1);
> 
> which of course fails. Clearly this code-path can't work, right? Either
> the assert is wrong or that keyInfoCtx needs a way to find its keysMngr.
> 
> 	Cheers Leif
> 
> 
> [1] http://pypi.python.org/pypi/dm.xmlsec.binding
> _______________________________________________
> xmlsec mailing list
> xmlsec at aleksey.com
> http://www.aleksey.com/mailman/listinfo/xmlsec
> 


From leifj at mnt.se  Wed Jul 11 00:12:24 2012
From: leifj at mnt.se (Leif Johansson)
Date: Wed, 11 Jul 2012 09:12:24 +0200
Subject: [xmlsec] problem with raw-x509-cert
In-Reply-To: <4FFCCE9D.2000409@aleksey.com>
References: <4FFCBEA0.9050402@mnt.se> <4FFCCE9D.2000409@aleksey.com>
Message-ID: <4FFD2758.6010700@mnt.se>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 07/11/2012 02:53 AM, Aleksey Sanin wrote:
> Leif,
> 
> Not sure which code you are looking at for the
> 
>> However almost immediately in xmlSecKeyInfoCtxInitialize there is
>> this:
>> 
>> xmlSecAssert2(keyInfoCtx->keysMngr != NULL, -1);
>> 
> 
> This is how this code looks for me
> 
> int xmlSecKeyInfoCtxInitialize(xmlSecKeyInfoCtxPtr keyInfoCtx, 
> xmlSecKeysMngrPtr keysMngr) { int ret;
> 
> xmlSecAssert2(keyInfoCtx != NULL, -1);
> 
> memset(keyInfoCtx, 0, sizeof(xmlSecKeyInfoCtx)); 
> keyInfoCtx->keysMngr = keysMngr; .... }

OK so this has been fixed in trunk. I will test!


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk/9J1MACgkQ8Jx8FtbMZnf2LQCfeDHQmsft8+U/VUjU1leq31DI
xIAAmwQgyFycRRiCSBWYycrKyPRXKHK0
=9rK/
-----END PGP SIGNATURE-----

From leifj at mnt.se  Wed Jul 11 00:40:58 2012
From: leifj at mnt.se (Leif Johansson)
Date: Wed, 11 Jul 2012 09:40:58 +0200
Subject: [xmlsec] problem with raw-x509-cert
In-Reply-To: <4FFCCE9D.2000409@aleksey.com>
References: <4FFCBEA0.9050402@mnt.se> <4FFCCE9D.2000409@aleksey.com>
Message-ID: <4FFD2E0A.9000704@mnt.se>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 07/11/2012 02:53 AM, Aleksey Sanin wrote:
> Leif,
> 
> Not sure which code you are looking at for the
> 
>> However almost immediately in xmlSecKeyInfoCtxInitialize there is
>> this:
>> 
>> xmlSecAssert2(keyInfoCtx->keysMngr != NULL, -1);
>> 
> 
> This is how this code looks for me
> 

Sorry Aleksey,

I was writing that email very late (early) and I should have
explained it better. The xmlSecAssert2 is *not* where I said
it was but in xmlSecOpenSSLKeyDataX509VerifyAndExtractKey
which is called because I'm using the OpenSSL backend.

	Cheers Leif

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk/9LgoACgkQ8Jx8FtbMZncLVwCgpB15QlfzQNSYqvjuV1ZB3/C/
YDYAmgMn2BiNHBHcFJ0zV72bK+Mkuuaj
=7iJp
-----END PGP SIGNATURE-----

From leifj at mnt.se  Wed Jul 11 01:25:15 2012
From: leifj at mnt.se (Leif Johansson)
Date: Wed, 11 Jul 2012 10:25:15 +0200
Subject: [xmlsec] problem with raw-x509-cert
In-Reply-To: <4FFCCE9D.2000409@aleksey.com>
References: <4FFCBEA0.9050402@mnt.se> <4FFCCE9D.2000409@aleksey.com>
Message-ID: <4FFD386B.5040803@mnt.se>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 07/11/2012 02:53 AM, Aleksey Sanin wrote:
> Leif,
> 
> Not sure which code you are looking at for the

Just to be clear, here is the "stack trace" based on xmlSecError
using "filename:line-number(function)" to the assert I'm talking
about:

x509.c:1605(xmlSecOpenSSLKeyDataX509VerifyAndExtractKey)
x509.c:2404(xmlSecOpenSSLKeyDataRawX509CertBinRead)
keys.c:1190(xmlSecKeyReadBuffer)
keys.c:1247(xmlSecKeyReadBinaryFile)

So the assert in question is the

xmlSecAssert2(keyInfoCtx->keysMngr != NULL, -1);

on line 1605 of x509.c

	Cheers Leif
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk/9OGsACgkQ8Jx8FtbMZndyRACffm7yFqV11By1m5P96gVleLMG
AGwAn2yHZUyN+Cswu4rjaBBGlmbFmP89
=5zWv
-----END PGP SIGNATURE-----

From leifj at mnt.se  Wed Jul 11 01:38:27 2012
From: leifj at mnt.se (Leif Johansson)
Date: Wed, 11 Jul 2012 10:38:27 +0200
Subject: [xmlsec] problem with raw-x509-cert
In-Reply-To: <4FFCCE9D.2000409@aleksey.com>
References: <4FFCBEA0.9050402@mnt.se> <4FFCCE9D.2000409@aleksey.com>
Message-ID: <4FFD3B83.80607@mnt.se>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


Also this:

The fact that (as you said)

> keyInfoCtx->keysMngr = keysMngr;

in xmlSecKeyInfoCtxInitialize means that when it is called thus:


ret = xmlSecKeyInfoCtxInitialize(&keyInfoCtx, NULL);


from xmlSecKeyReadBuffer means it *will* hit that assert in
xmlSecOpenSSLKeyDataX509VerifyAndExtractKey


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk/9O4MACgkQ8Jx8FtbMZnePKgCdFY5GgdM1gxx5eNWko9HPlSsX
RzoAnRV/twAXAnoQP7gAjeCOSVOfwUwX
=q/aP
-----END PGP SIGNATURE-----

From aleksey at aleksey.com  Wed Jul 11 07:01:31 2012
From: aleksey at aleksey.com (Aleksey Sanin)
Date: Wed, 11 Jul 2012 07:01:31 -0700
Subject: [xmlsec] problem with raw-x509-cert
In-Reply-To: <4FFD3B83.80607@mnt.se>
References: <4FFCBEA0.9050402@mnt.se> <4FFCCE9D.2000409@aleksey.com>
 <4FFD3B83.80607@mnt.se>
Message-ID: <4FFD873B.6070304@aleksey.com>

This assert checks that keysMngr is not NULL. If you are hitting
it then it means that keysMngr field is NULL at that point.

Aleksey


On 7/11/12 1:38 AM, Leif Johansson wrote:
> 
> Also this:
> 
> The fact that (as you said)
> 
>> keyInfoCtx->keysMngr = keysMngr;
> 
> in xmlSecKeyInfoCtxInitialize means that when it is called thus:
> 
> 
> ret = xmlSecKeyInfoCtxInitialize(&keyInfoCtx, NULL);
> 
> 
> from xmlSecKeyReadBuffer means it *will* hit that assert in
> xmlSecOpenSSLKeyDataX509VerifyAndExtractKey
> 
> 
> 


From leifj at mnt.se  Wed Jul 11 07:30:07 2012
From: leifj at mnt.se (Leif Johansson)
Date: Wed, 11 Jul 2012 16:30:07 +0200
Subject: [xmlsec] problem with raw-x509-cert
In-Reply-To: <4FFD873B.6070304@aleksey.com>
References: <4FFCBEA0.9050402@mnt.se> <4FFCCE9D.2000409@aleksey.com>
 <4FFD3B83.80607@mnt.se> <4FFD873B.6070304@aleksey.com>
Message-ID: <4FFD8DEF.40105@mnt.se>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 07/11/2012 04:01 PM, Aleksey Sanin wrote:
> This assert checks that keysMngr is not NULL. If you are hitting it
> then it means that keysMngr field is NULL at that point.
> 

Yes because the code-path I outlined in my other emails
ensures that it is NULL.


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk/9jesACgkQ8Jx8FtbMZnfZ3gCfR9dAvYMXSWkiba6ooWRv9PAS
0U0AoKp3X+efVLFbPnygmVXitIbZAEgj
=tiyE
-----END PGP SIGNATURE-----

From aleksey at aleksey.com  Wed Jul 11 08:51:03 2012
From: aleksey at aleksey.com (Aleksey Sanin)
Date: Wed, 11 Jul 2012 08:51:03 -0700
Subject: [xmlsec] problem with raw-x509-cert
In-Reply-To: <4FFD8DEF.40105@mnt.se>
References: <4FFCBEA0.9050402@mnt.se> <4FFCCE9D.2000409@aleksey.com>
 <4FFD3B83.80607@mnt.se> <4FFD873B.6070304@aleksey.com>
 <4FFD8DEF.40105@mnt.se>
Message-ID: <4FFDA0E7.8020105@aleksey.com>

OK, now I got it. The xmlSecKeyReadBinaryFile() function is not
designed to read X509 certificates. You need to extract public
key from the certificate into PEM or DER format.

Otherwise, you might want to look at xmlSecCryptoAppKeyCertLoad()
function.

Aleksey


On 7/11/12 7:30 AM, Leif Johansson wrote:
> On 07/11/2012 04:01 PM, Aleksey Sanin wrote:
>> This assert checks that keysMngr is not NULL. If you are hitting it
>> then it means that keysMngr field is NULL at that point.
> 
> 
> Yes because the code-path I outlined in my other emails
> ensures that it is NULL.
> 
> 
> 


From leifj at mnt.se  Wed Jul 11 09:12:15 2012
From: leifj at mnt.se (Leif Johansson)
Date: Wed, 11 Jul 2012 18:12:15 +0200
Subject: [xmlsec] problem with raw-x509-cert
In-Reply-To: <4FFDA0E7.8020105@aleksey.com>
References: <4FFCBEA0.9050402@mnt.se> <4FFCCE9D.2000409@aleksey.com>
 <4FFD3B83.80607@mnt.se> <4FFD873B.6070304@aleksey.com>
 <4FFD8DEF.40105@mnt.se> <4FFDA0E7.8020105@aleksey.com>
Message-ID: <4FFDA5DF.5050104@mnt.se>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 07/11/2012 05:51 PM, Aleksey Sanin wrote:
> OK, now I got it. The xmlSecKeyReadBinaryFile() function is not 
> designed to read X509 certificates. You need to extract public key
> from the certificate into PEM or DER format.
> 
> Otherwise, you might want to look at xmlSecCryptoAppKeyCertLoad() 
> function.
> 
gotcha, will try that.


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk/9pdsACgkQ8Jx8FtbMZndegACfR+aRcAaoq5PAUiP3chRQFy2f
l7oAmwb08BQQNZ7Y/Unk5dwvGaU+5sVc
=o7Il
-----END PGP SIGNATURE-----

From aleksey at aleksey.com  Wed Jul 18 19:17:04 2012
From: aleksey at aleksey.com (Aleksey Sanin)
Date: Wed, 18 Jul 2012 19:17:04 -0700
Subject: [xmlsec] XML Sig verification failure due to Windows .NET c14n
 and libxml2 c14n difference
In-Reply-To: <500767FC.8020004@xmission.com>
References: <500767FC.8020004@xmission.com>
Message-ID: <50076E20.6090202@aleksey.com>

Well, since I wrote c14n code for libxml2 I can tell you that
this code is doing the right thing :) This is actually a known
bug that was discovered 10 years ago or so. .NET implementation
doesn't follow the spec but they refuse to change it since it
might break backward compatibility with old broken versions.

Anyway, I might suggest that you use c14n 1.1 spec if you can.
I believe it was implemented correctly in .NET.

Aleksey


On 7/18/12 6:50 PM, Tom Wood wrote:
> Aleksey,
>   I have been extensively using XML Signatures in a project over the
> past few months and have encountered what I believe is a significant
> cross platform
> problem. Fortunately, I have fully characterized the issue and can
> even resolve it (through a hack though, not pretty). But the reasons for
> the problem are troubling
> and I think you would be interested. I am hoping you can shed light on
> this issue or
> at least point me to someone who can.
> 
> Note that I have been working a lot with XMLSec and have compiled it from
> source code and have a good working knowledge of the package and
> interface and
> have even added some debugging source code along the way. The problem
> occurs with
> XML files signed in Windows .NET systems (as well as with at least one
> Java based
> system). 
> 
> -------------------------------
> I have diagnosed a problem wherein an XML signature produced on a Windows
> .NET system could not be verified using XMLSec (both on Linux and Windows).
> The reverse also occurs, where the same XML signed under XMLSec fails to
> verify on the Windows .NET system.  The actual issue lies with C14N, and
> thus
> technically, on the Linux side, involved libXML2, not XMLSec. But I
> think you will be
> interested. I appreciate your taking some time to read through this.
> 
> 
> The root of the problem is actually very simple and only occurs when
> the Signature CanonicalizationMethod is Inclusive C14N
> (http://www.w3.org/TR/2001/REC-xml-c14n-20010315).
> 
> 
> Here is the relevant part of an example <Signature> block.
> 
> <Signature:Signature xmlns="http://www.w3.org/2000/09/xmldsig#"
> xmlns:xsd="http://www.w3.org/2001/XMLSchema"
> xmlns:Signature="http://www.w3.org/2000/09/xmldsig#">
> <SignedInfo>
> <CanonicalizationMethod
> Algorithm="http://www.w3.org/TR/2001/REC-xml-c14n-20010315"/>
> <SignatureMethod
> Algorithm="http://www.w3.org/2001/04/xmldsig-more#rsa-sha256"/>
> <Reference URI="">
> <Transforms><Transform
> Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature"/></Transforms>
> <DigestMethod Algorithm="http://www.w3.org/2001/04/xmlenc#sha256"/>
> <DigestValue>PtRfa3EJKTr6yeeuokpGu4KvHnGPAcd1YqhZtts+qOs=</DigestValue>
> </Reference>
> </SignedInfo>
> ...
> ...
> 
> Under Windows .NET C14N transformation, the <SignedInfo> node is
> canonicalized to:
> 
> <SignedInfo xmlns="http://www.w3.org/2000/09/xmldsig#">
> <CanonicalizationMethod
> Algorithm="http://www.w3.org/TR/2001/REC-xml-c14n-20010315"></CanonicalizationMethod>
> <SignatureMethod
> Algorithm="http://www.w3.org/2001/04/xmldsig-more#rsa-sha256"></SignatureMethod>
> <Reference URI="">
> <Transforms><Transform
> Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature"></Transform></Transforms>
> <DigestMethod
> Algorithm="http://www.w3.org/2001/04/xmlenc#sha256"></DigestMethod>
> <DigestValue>PtRfa3EJKTr6yeeuokpGu4KvHnGPAcd1YqhZtts+qOs=</DigestValue>
> </Reference>
> </SignedInfo>
> 
> Under XMLSec (using libXML2 underneath) C14N, the <SignedInfo> node is
> canonicalized to:
> 
> <SignedInfo xmlns="http://www.w3.org/2000/09/xmldsig#"
> xmlns:Signature="http://www.w3.org/2000/09/xmldsig#"
> xmlns:xsd="http://www.w3.org/2001/XMLSchema">
> <CanonicalizationMethod
> Algorithm="http://www.w3.org/TR/2001/REC-xml-c14n-20010315"></CanonicalizationMethod>
> <SignatureMethod
> Algorithm="http://www.w3.org/2001/04/xmldsig-more#rsa-sha256"></SignatureMethod>
> <Reference URI="">
> <Transforms><Transform
> Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature"></Transform></Transforms>
> <DigestMethod
> Algorithm="http://www.w3.org/2001/04/xmlenc#sha256"></DigestMethod>
> <DigestValue>PtRfa3EJKTr6yeeuokpGu4KvHnGPAcd1YqhZtts+qOs=</DigestValue>
> </Reference>
> </SignedInfo>
> 
> The difference between the xmlns attrs in <SignedInfo> of course ruins
> Signature portability across
> these systems.
> 
> It is interesting and useful to point out that if Exclusive C14N is
> used, both systems canonicalize to
> the same <SignedInfo>. It is simply set to <SignedInfo
> xmlns="http://www.w3.org/2000/09/xmldsig#"> and
> so no problem occurs with cross platform verification.
> 
> Note that a hacked XMLSec can verify a signature from the Windows system
> if in midstream it subsititutes the
> Exclusive C14N transform instead of using the requested Inclusive C14N
> (from the XML Signature). I know this
> because I hacked a copy of XMLSec to force use of Exclusive C14N and
> suddenly XML
> signatures from a Windows .NET system verified. So the problem is
> strictly caused by the
> difference in SignedInfo node Canonicalization.
> 
> Can you or anyone your know tell me which code/system is correctly
> appying the inclusive C14N algorithm,
> Windows .NET or libXML2? 
> From my careful reading of the W3C Canonical XML spec,
> I think the result should match the libXML2 result, wherein all
> namespace attributes from
> <Signature> should be propagated into <SignedInfo>, as in
> <SignedInfo xmlns="http://www.w3.org/2000/09/xmldsig#"
> xmlns:Signature="http://www.w3.org/2000/09/xmldsig#"
> xmlns:xsd="http://www.w3.org/2001/XMLSchema">
> This is what libXML2 code produces.
> 
> Have you or anyone you know encountered this issue?
> 
> It quite surprises me that I would be the first whom has encountered
> this problem. As I am sure you can appreciate, this is a serious issue
> as cross platform verification is required.
> 
> Thanks in advance,
> Tom Wood
> wood at xmission.com
> 


From aleksey at aleksey.com  Wed Jul 18 20:30:17 2012
From: aleksey at aleksey.com (Aleksey Sanin)
Date: Wed, 18 Jul 2012 20:30:17 -0700
Subject: [xmlsec] XML Sig verification failure due to Windows .NET c14n
 and libxml2 c14n difference
In-Reply-To: <50077365.9050601@xmission.com>
References: <500767FC.8020004@xmission.com> <50076E20.6090202@aleksey.com>
 <50077365.9050601@xmission.com>
Message-ID: <50077F49.4080608@aleksey.com>

I haven't heard about any problems with Java :)

You can google for ".net c14n compatibility" to see results

Aleksey


On 7/18/12 7:39 PM, Tom Wood wrote:
> Aleksey,
>    Thanks so much for the quick answer. That certainly explains everything.
> Seems like a "dirty little secret".  Very disappointing.
> 
> Do you know of anywhere on the Web I can find more information
> documenting this known bug and Microsoft's decision to not fix it?
> Also, would you care to comment about Java based systems
> allowing for the same bug? I could well imagine that for
> interoperability Java developers might have implemented and propagated
> the same c14n bug.
> 
> Thanks again,
> Tom
> 
> 
> Aleksey Sanin wrote:
>> Well, since I wrote c14n code for libxml2 I can tell you that
>> this code is doing the right thing :) This is actually a known
>> bug that was discovered 10 years ago or so. .NET implementation
>> doesn't follow the spec but they refuse to change it since it
>> might break backward compatibility with old broken versions.
>>
>> Anyway, I might suggest that you use c14n 1.1 spec if you can.
>> I believe it was implemented correctly in .NET.
>>
>> Aleksey
>>
>>
>> On 7/18/12 6:50 PM, Tom Wood wrote:
>>   
>>> Aleksey,
>>>   I have been extensively using XML Signatures in a project over the
>>> past few months and have encountered what I believe is a significant
>>> cross platform
>>> problem. Fortunately, I have fully characterized the issue and can
>>> even resolve it (through a hack though, not pretty). But the reasons for
>>> the problem are troubling
>>> and I think you would be interested. I am hoping you can shed light on
>>> this issue or
>>> at least point me to someone who can.
>>>
>>> Note that I have been working a lot with XMLSec and have compiled it from
>>> source code and have a good working knowledge of the package and
>>> interface and
>>> have even added some debugging source code along the way. The problem
>>> occurs with
>>> XML files signed in Windows .NET systems (as well as with at least one
>>> Java based
>>> system). 
>>>
>>> -------------------------------
>>> I have diagnosed a problem wherein an XML signature produced on a Windows
>>> .NET system could not be verified using XMLSec (both on Linux and Windows).
>>> The reverse also occurs, where the same XML signed under XMLSec fails to
>>> verify on the Windows .NET system.  The actual issue lies with C14N, and
>>> thus
>>> technically, on the Linux side, involved libXML2, not XMLSec. But I
>>> think you will be
>>> interested. I appreciate your taking some time to read through this.
>>>
>>>
>>> The root of the problem is actually very simple and only occurs when
>>> the Signature CanonicalizationMethod is Inclusive C14N
>>> (http://www.w3.org/TR/2001/REC-xml-c14n-20010315).
>>>
>>>
>>> Here is the relevant part of an example <Signature> block.
>>>
>>> <Signature:Signature xmlns="http://www.w3.org/2000/09/xmldsig#"
>>> xmlns:xsd="http://www.w3.org/2001/XMLSchema"
>>> xmlns:Signature="http://www.w3.org/2000/09/xmldsig#">
>>> <SignedInfo>
>>> <CanonicalizationMethod
>>> Algorithm="http://www.w3.org/TR/2001/REC-xml-c14n-20010315"/>
>>> <SignatureMethod
>>> Algorithm="http://www.w3.org/2001/04/xmldsig-more#rsa-sha256"/>
>>> <Reference URI="">
>>> <Transforms><Transform
>>> Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature"/></Transforms>
>>> <DigestMethod Algorithm="http://www.w3.org/2001/04/xmlenc#sha256"/>
>>> <DigestValue>PtRfa3EJKTr6yeeuokpGu4KvHnGPAcd1YqhZtts+qOs=</DigestValue>
>>> </Reference>
>>> </SignedInfo>
>>> ...
>>> ...
>>>
>>> Under Windows .NET C14N transformation, the <SignedInfo> node is
>>> canonicalized to:
>>>
>>> <SignedInfo xmlns="http://www.w3.org/2000/09/xmldsig#">
>>> <CanonicalizationMethod
>>> Algorithm="http://www.w3.org/TR/2001/REC-xml-c14n-20010315"></CanonicalizationMethod>
>>> <SignatureMethod
>>> Algorithm="http://www.w3.org/2001/04/xmldsig-more#rsa-sha256"></SignatureMethod>
>>> <Reference URI="">
>>> <Transforms><Transform
>>> Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature"></Transform></Transforms>
>>> <DigestMethod
>>> Algorithm="http://www.w3.org/2001/04/xmlenc#sha256"></DigestMethod>
>>> <DigestValue>PtRfa3EJKTr6yeeuokpGu4KvHnGPAcd1YqhZtts+qOs=</DigestValue>
>>> </Reference>
>>> </SignedInfo>
>>>
>>> Under XMLSec (using libXML2 underneath) C14N, the <SignedInfo> node is
>>> canonicalized to:
>>>
>>> <SignedInfo xmlns="http://www.w3.org/2000/09/xmldsig#"
>>> xmlns:Signature="http://www.w3.org/2000/09/xmldsig#"
>>> xmlns:xsd="http://www.w3.org/2001/XMLSchema">
>>> <CanonicalizationMethod
>>> Algorithm="http://www.w3.org/TR/2001/REC-xml-c14n-20010315"></CanonicalizationMethod>
>>> <SignatureMethod
>>> Algorithm="http://www.w3.org/2001/04/xmldsig-more#rsa-sha256"></SignatureMethod>
>>> <Reference URI="">
>>> <Transforms><Transform
>>> Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature"></Transform></Transforms>
>>> <DigestMethod
>>> Algorithm="http://www.w3.org/2001/04/xmlenc#sha256"></DigestMethod>
>>> <DigestValue>PtRfa3EJKTr6yeeuokpGu4KvHnGPAcd1YqhZtts+qOs=</DigestValue>
>>> </Reference>
>>> </SignedInfo>
>>>
>>> The difference between the xmlns attrs in <SignedInfo> of course ruins
>>> Signature portability across
>>> these systems.
>>>
>>> It is interesting and useful to point out that if Exclusive C14N is
>>> used, both systems canonicalize to
>>> the same <SignedInfo>. It is simply set to <SignedInfo
>>> xmlns="http://www.w3.org/2000/09/xmldsig#"> and
>>> so no problem occurs with cross platform verification.
>>>
>>> Note that a hacked XMLSec can verify a signature from the Windows system
>>> if in midstream it subsititutes the
>>> Exclusive C14N transform instead of using the requested Inclusive C14N
>>> (from the XML Signature). I know this
>>> because I hacked a copy of XMLSec to force use of Exclusive C14N and
>>> suddenly XML
>>> signatures from a Windows .NET system verified. So the problem is
>>> strictly caused by the
>>> difference in SignedInfo node Canonicalization.
>>>
>>> Can you or anyone your know tell me which code/system is correctly
>>> appying the inclusive C14N algorithm,
>>> Windows .NET or libXML2? 
>>> From my careful reading of the W3C Canonical XML spec,
>>> I think the result should match the libXML2 result, wherein all
>>> namespace attributes from
>>> <Signature> should be propagated into <SignedInfo>, as in
>>> <SignedInfo xmlns="http://www.w3.org/2000/09/xmldsig#"
>>> xmlns:Signature="http://www.w3.org/2000/09/xmldsig#"
>>> xmlns:xsd="http://www.w3.org/2001/XMLSchema">
>>> This is what libXML2 code produces.
>>>
>>> Have you or anyone you know encountered this issue?
>>>
>>> It quite surprises me that I would be the first whom has encountered
>>> this problem. As I am sure you can appreciate, this is a serious issue
>>> as cross platform verification is required.
>>>
>>> Thanks in advance,
>>> Tom Wood
>>> wood at xmission.com
>>>
>>>     
>>
>>
>>   
> 


From aleksey at aleksey.com  Wed Jul 18 20:35:45 2012
From: aleksey at aleksey.com (Aleksey Sanin)
Date: Wed, 18 Jul 2012 20:35:45 -0700
Subject: [xmlsec] XML Sig verification failure due to Windows .NET c14n
 and libxml2 c14n difference
In-Reply-To: <50077F49.4080608@aleksey.com>
References: <500767FC.8020004@xmission.com> <50076E20.6090202@aleksey.com>
 <50077365.9050601@xmission.com> <50077F49.4080608@aleksey.com>
Message-ID: <50078091.8050503@aleksey.com>

For example, check this one

http://www.aleksey.com/pipermail/xmlsec/2008/008517.html

Aleksey


On 7/18/12 8:30 PM, Aleksey Sanin wrote:
> I haven't heard about any problems with Java :)
> 
> You can google for ".net c14n compatibility" to see results
> 
> Aleksey
> 
> 
> On 7/18/12 7:39 PM, Tom Wood wrote:
>> Aleksey,
>>    Thanks so much for the quick answer. That certainly explains everything.
>> Seems like a "dirty little secret".  Very disappointing.
>>
>> Do you know of anywhere on the Web I can find more information
>> documenting this known bug and Microsoft's decision to not fix it?
>> Also, would you care to comment about Java based systems
>> allowing for the same bug? I could well imagine that for
>> interoperability Java developers might have implemented and propagated
>> the same c14n bug.
>>
>> Thanks again,
>> Tom
>>
>>
>> Aleksey Sanin wrote:
>>> Well, since I wrote c14n code for libxml2 I can tell you that
>>> this code is doing the right thing :) This is actually a known
>>> bug that was discovered 10 years ago or so. .NET implementation
>>> doesn't follow the spec but they refuse to change it since it
>>> might break backward compatibility with old broken versions.
>>>
>>> Anyway, I might suggest that you use c14n 1.1 spec if you can.
>>> I believe it was implemented correctly in .NET.
>>>
>>> Aleksey
>>>
>>>
>>> On 7/18/12 6:50 PM, Tom Wood wrote:
>>>   
>>>> Aleksey,
>>>>   I have been extensively using XML Signatures in a project over the
>>>> past few months and have encountered what I believe is a significant
>>>> cross platform
>>>> problem. Fortunately, I have fully characterized the issue and can
>>>> even resolve it (through a hack though, not pretty). But the reasons for
>>>> the problem are troubling
>>>> and I think you would be interested. I am hoping you can shed light on
>>>> this issue or
>>>> at least point me to someone who can.
>>>>
>>>> Note that I have been working a lot with XMLSec and have compiled it from
>>>> source code and have a good working knowledge of the package and
>>>> interface and
>>>> have even added some debugging source code along the way. The problem
>>>> occurs with
>>>> XML files signed in Windows .NET systems (as well as with at least one
>>>> Java based
>>>> system). 
>>>>
>>>> -------------------------------
>>>> I have diagnosed a problem wherein an XML signature produced on a Windows
>>>> .NET system could not be verified using XMLSec (both on Linux and Windows).
>>>> The reverse also occurs, where the same XML signed under XMLSec fails to
>>>> verify on the Windows .NET system.  The actual issue lies with C14N, and
>>>> thus
>>>> technically, on the Linux side, involved libXML2, not XMLSec. But I
>>>> think you will be
>>>> interested. I appreciate your taking some time to read through this.
>>>>
>>>>
>>>> The root of the problem is actually very simple and only occurs when
>>>> the Signature CanonicalizationMethod is Inclusive C14N
>>>> (http://www.w3.org/TR/2001/REC-xml-c14n-20010315).
>>>>
>>>>
>>>> Here is the relevant part of an example <Signature> block.
>>>>
>>>> <Signature:Signature xmlns="http://www.w3.org/2000/09/xmldsig#"
>>>> xmlns:xsd="http://www.w3.org/2001/XMLSchema"
>>>> xmlns:Signature="http://www.w3.org/2000/09/xmldsig#">
>>>> <SignedInfo>
>>>> <CanonicalizationMethod
>>>> Algorithm="http://www.w3.org/TR/2001/REC-xml-c14n-20010315"/>
>>>> <SignatureMethod
>>>> Algorithm="http://www.w3.org/2001/04/xmldsig-more#rsa-sha256"/>
>>>> <Reference URI="">
>>>> <Transforms><Transform
>>>> Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature"/></Transforms>
>>>> <DigestMethod Algorithm="http://www.w3.org/2001/04/xmlenc#sha256"/>
>>>> <DigestValue>PtRfa3EJKTr6yeeuokpGu4KvHnGPAcd1YqhZtts+qOs=</DigestValue>
>>>> </Reference>
>>>> </SignedInfo>
>>>> ...
>>>> ...
>>>>
>>>> Under Windows .NET C14N transformation, the <SignedInfo> node is
>>>> canonicalized to:
>>>>
>>>> <SignedInfo xmlns="http://www.w3.org/2000/09/xmldsig#">
>>>> <CanonicalizationMethod
>>>> Algorithm="http://www.w3.org/TR/2001/REC-xml-c14n-20010315"></CanonicalizationMethod>
>>>> <SignatureMethod
>>>> Algorithm="http://www.w3.org/2001/04/xmldsig-more#rsa-sha256"></SignatureMethod>
>>>> <Reference URI="">
>>>> <Transforms><Transform
>>>> Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature"></Transform></Transforms>
>>>> <DigestMethod
>>>> Algorithm="http://www.w3.org/2001/04/xmlenc#sha256"></DigestMethod>
>>>> <DigestValue>PtRfa3EJKTr6yeeuokpGu4KvHnGPAcd1YqhZtts+qOs=</DigestValue>
>>>> </Reference>
>>>> </SignedInfo>
>>>>
>>>> Under XMLSec (using libXML2 underneath) C14N, the <SignedInfo> node is
>>>> canonicalized to:
>>>>
>>>> <SignedInfo xmlns="http://www.w3.org/2000/09/xmldsig#"
>>>> xmlns:Signature="http://www.w3.org/2000/09/xmldsig#"
>>>> xmlns:xsd="http://www.w3.org/2001/XMLSchema">
>>>> <CanonicalizationMethod
>>>> Algorithm="http://www.w3.org/TR/2001/REC-xml-c14n-20010315"></CanonicalizationMethod>
>>>> <SignatureMethod
>>>> Algorithm="http://www.w3.org/2001/04/xmldsig-more#rsa-sha256"></SignatureMethod>
>>>> <Reference URI="">
>>>> <Transforms><Transform
>>>> Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature"></Transform></Transforms>
>>>> <DigestMethod
>>>> Algorithm="http://www.w3.org/2001/04/xmlenc#sha256"></DigestMethod>
>>>> <DigestValue>PtRfa3EJKTr6yeeuokpGu4KvHnGPAcd1YqhZtts+qOs=</DigestValue>
>>>> </Reference>
>>>> </SignedInfo>
>>>>
>>>> The difference between the xmlns attrs in <SignedInfo> of course ruins
>>>> Signature portability across
>>>> these systems.
>>>>
>>>> It is interesting and useful to point out that if Exclusive C14N is
>>>> used, both systems canonicalize to
>>>> the same <SignedInfo>. It is simply set to <SignedInfo
>>>> xmlns="http://www.w3.org/2000/09/xmldsig#"> and
>>>> so no problem occurs with cross platform verification.
>>>>
>>>> Note that a hacked XMLSec can verify a signature from the Windows system
>>>> if in midstream it subsititutes the
>>>> Exclusive C14N transform instead of using the requested Inclusive C14N
>>>> (from the XML Signature). I know this
>>>> because I hacked a copy of XMLSec to force use of Exclusive C14N and
>>>> suddenly XML
>>>> signatures from a Windows .NET system verified. So the problem is
>>>> strictly caused by the
>>>> difference in SignedInfo node Canonicalization.
>>>>
>>>> Can you or anyone your know tell me which code/system is correctly
>>>> appying the inclusive C14N algorithm,
>>>> Windows .NET or libXML2? 
>>>> From my careful reading of the W3C Canonical XML spec,
>>>> I think the result should match the libXML2 result, wherein all
>>>> namespace attributes from
>>>> <Signature> should be propagated into <SignedInfo>, as in
>>>> <SignedInfo xmlns="http://www.w3.org/2000/09/xmldsig#"
>>>> xmlns:Signature="http://www.w3.org/2000/09/xmldsig#"
>>>> xmlns:xsd="http://www.w3.org/2001/XMLSchema">
>>>> This is what libXML2 code produces.
>>>>
>>>> Have you or anyone you know encountered this issue?
>>>>
>>>> It quite surprises me that I would be the first whom has encountered
>>>> this problem. As I am sure you can appreciate, this is a serious issue
>>>> as cross platform verification is required.
>>>>
>>>> Thanks in advance,
>>>> Tom Wood
>>>> wood at xmission.com
>>>>
>>>>     
>>>
>>>
>>>   
>>
> 
> _______________________________________________
> xmlsec mailing list
> xmlsec at aleksey.com
> http://www.aleksey.com/mailman/listinfo/xmlsec
> 


From john at neggie.net  Mon Jul 23 18:41:25 2012
From: john at neggie.net (John Belmonte)
Date: Mon, 23 Jul 2012 21:41:25 -0400
Subject: [xmlsec] issue with xmlSecCheckVersionExt()?
Message-ID: <CANtbB96f8c5o3xLEpxu538z1DYa-4m7=GZc40Ebi80-kzNMgNQ@mail.gmail.com>

Hi Aleksey,

I have a report that the comparison in xmlSecCheckVersionExt() may be
reversed in the xmlSecCheckVersionABICompatible case.  Would you take
a look at http://bugs.debian.org/675513 and see if it makes sense?

Regards,
--John

From aleksey at aleksey.com  Mon Jul 23 18:48:42 2012
From: aleksey at aleksey.com (Aleksey Sanin)
Date: Mon, 23 Jul 2012 18:48:42 -0700
Subject: [xmlsec] issue with xmlSecCheckVersionExt()?
In-Reply-To: <CANtbB96f8c5o3xLEpxu538z1DYa-4m7=GZc40Ebi80-kzNMgNQ@mail.gmail.com>
References: <CANtbB96f8c5o3xLEpxu538z1DYa-4m7=GZc40Ebi80-kzNMgNQ@mail.gmail.com>
Message-ID: <500DFEFA.3000809@aleksey.com>

Indeed. Fixed.

Aleksey

On 7/23/12 6:41 PM, John Belmonte wrote:
> Hi Aleksey,
> 
> I have a report that the comparison in xmlSecCheckVersionExt() may be
> reversed in the xmlSecCheckVersionABICompatible case.  Would you take
> a look at http://bugs.debian.org/675513 and see if it makes sense?
> 
> Regards,
> --John
> _______________________________________________
> xmlsec mailing list
> xmlsec at aleksey.com
> http://www.aleksey.com/mailman/listinfo/xmlsec
> 

From john at neggie.net  Thu Jul 26 17:46:29 2012
From: john at neggie.net (John Belmonte)
Date: Thu, 26 Jul 2012 20:46:29 -0400
Subject: [xmlsec] issue with xmlSecCheckVersionExt()?
In-Reply-To: <500DFEFA.3000809@aleksey.com>
References: <CANtbB96f8c5o3xLEpxu538z1DYa-4m7=GZc40Ebi80-kzNMgNQ@mail.gmail.com>
 <500DFEFA.3000809@aleksey.com>
Message-ID: <CANtbB94UGxxhrN0O4QciN31qkwLFuF0-EFa5SHgNWj1QGyjXug@mail.gmail.com>

Thanks for addressing.

Would you mind also applying a one line patch to example makefile
which I reported a few months ago?

http://bugzilla.gnome.org/674561


On Mon, Jul 23, 2012 at 9:48 PM, Aleksey Sanin <aleksey at aleksey.com> wrote:
> Indeed. Fixed.
>
> Aleksey
>
> On 7/23/12 6:41 PM, John Belmonte wrote:
>> Hi Aleksey,
>>
>> I have a report that the comparison in xmlSecCheckVersionExt() may be
>> reversed in the xmlSecCheckVersionABICompatible case.  Would you take
>> a look at http://bugs.debian.org/675513 and see if it makes sense?
>>
>> Regards,
>> --John
>> _______________________________________________
>> xmlsec mailing list
>> xmlsec at aleksey.com
>> http://www.aleksey.com/mailman/listinfo/xmlsec
>>

From aleksey at aleksey.com  Thu Jul 26 19:34:39 2012
From: aleksey at aleksey.com (Aleksey Sanin)
Date: Thu, 26 Jul 2012 19:34:39 -0700
Subject: [xmlsec] issue with xmlSecCheckVersionExt()?
In-Reply-To: <CANtbB94UGxxhrN0O4QciN31qkwLFuF0-EFa5SHgNWj1QGyjXug@mail.gmail.com>
References: <CANtbB96f8c5o3xLEpxu538z1DYa-4m7=GZc40Ebi80-kzNMgNQ@mail.gmail.com>
 <500DFEFA.3000809@aleksey.com>
 <CANtbB94UGxxhrN0O4QciN31qkwLFuF0-EFa5SHgNWj1QGyjXug@mail.gmail.com>
Message-ID: <5011FE3F.2000601@aleksey.com>

John,

Apologies. No idea how I missed it. Committed and pushed.


Aleksey

On 7/26/12 5:46 PM, John Belmonte wrote:
> Thanks for addressing.
> 
> Would you mind also applying a one line patch to example makefile
> which I reported a few months ago?
> 
> http://bugzilla.gnome.org/674561
> 
> 
> On Mon, Jul 23, 2012 at 9:48 PM, Aleksey Sanin <aleksey at aleksey.com> wrote:
>> Indeed. Fixed.
>>
>> Aleksey
>>
>> On 7/23/12 6:41 PM, John Belmonte wrote:
>>> Hi Aleksey,
>>>
>>> I have a report that the comparison in xmlSecCheckVersionExt() may be
>>> reversed in the xmlSecCheckVersionABICompatible case.  Would you take
>>> a look at http://bugs.debian.org/675513 and see if it makes sense?
>>>
>>> Regards,
>>> --John
>>> _______________________________________________
>>> xmlsec mailing list
>>> xmlsec at aleksey.com
>>> http://www.aleksey.com/mailman/listinfo/xmlsec
>>>

From xmlsec at roumenpetrov.info  Sun Jul 29 03:42:52 2012
From: xmlsec at roumenpetrov.info (Roumen Petrov)
Date: Sun, 29 Jul 2012 13:42:52 +0300
Subject: [xmlsec] suspend warning in configure.ac - autoconf 2.68+
Message-ID: <501513AC.4050408@roumenpetrov.info>

Attached file "0003-autoconf-2.68-fixes.patch" will suspend a warning if 
xmlsec is bootstrapped with autoconf 2.68+

Roumen

-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0003-autoconf-2.68-fixes.patch
Type: text/x-diff
Size: 828 bytes
Desc: not available
URL: <http://www.aleksey.com/pipermail/xmlsec/attachments/20120729/a6448dc9/attachment.patch>

From xmlsec at roumenpetrov.info  Sun Jul 29 03:44:25 2012
From: xmlsec at roumenpetrov.info (Roumen Petrov)
Date: Sun, 29 Jul 2012 13:44:25 +0300
Subject: [xmlsec] automake 1.12 remove AM_C_PROTOTYPES - automatic
 de-ANSI-fication support has been removed
Message-ID: <50151409.5080107@roumenpetrov.info>

Patch attached as 
"0004-avoid-automake-1.12-error-in-macro-AM_C_PROTOTYPES-a.patch"

Roumen
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0004-avoid-automake-1.12-error-in-macro-AM_C_PROTOTYPES-a.patch
Type: text/x-diff
Size: 1343 bytes
Desc: not available
URL: <http://www.aleksey.com/pipermail/xmlsec/attachments/20120729/cd1801f1/attachment.patch>

From xmlsec at roumenpetrov.info  Sun Jul 29 03:45:57 2012
From: xmlsec at roumenpetrov.info (Roumen Petrov)
Date: Sun, 29 Jul 2012 13:45:57 +0300
Subject: [xmlsec] feature - implement automake silent rules
Message-ID: <50151465.3090506@roumenpetrov.info>

See "0005-automake-silent-rules.patch"

Roumen

-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0005-automake-silent-rules.patch
Type: text/x-diff
Size: 757 bytes
Desc: not available
URL: <http://www.aleksey.com/pipermail/xmlsec/attachments/20120729/d08ff9df/attachment.patch>

From aleksey at aleksey.com  Sun Jul 29 16:21:26 2012
From: aleksey at aleksey.com (Aleksey Sanin)
Date: Sun, 29 Jul 2012 16:21:26 -0700
Subject: [xmlsec] feature - implement automake silent rules
In-Reply-To: <50151465.3090506@roumenpetrov.info>
References: <50151465.3090506@roumenpetrov.info>
Message-ID: <5015C576.50109@aleksey.com>

Hi Roumen,

I've applied all 3 patches. Thanks!

Aleksey

On 7/29/12 3:45 AM, Roumen Petrov wrote:
> See "0005-automake-silent-rules.patch"
> 
> Roumen
> 
> 
> 
> _______________________________________________
> xmlsec mailing list
> xmlsec at aleksey.com
> http://www.aleksey.com/mailman/listinfo/xmlsec
> 

From dont.avt at gmail.com  Tue Aug 14 08:38:51 2012
From: dont.avt at gmail.com (Roman Khlystik)
Date: Tue, 14 Aug 2012 18:38:51 +0300
Subject: [xmlsec] Verify invalid certificate chain
Message-ID: <CAGRgBF+Pqv=6oCTM3udBJGzLhg05w9DJpjbkHxzf7W_8qv=0UQ@mail.gmail.com>

Hi Aleksey!

I'm trying to develop simple license system using xmlsec library.
My idea was to build simple private PKI with one CA key pair and separate
key-pair for each customer.
Then I planned to sign xml license file with client certificate for each
client.

I decided to embbed CA certificate in our app and verify certificate chain
from xml file up to CA certificate.
But I have a problem with xmlsec library. I can't find how to verify full
certificate chain with it.
I used example from here
http://www.aleksey.com/xmlsec/api/xmlsec-verify-with-x509.html?
and I have a problem when certificate chain is invalid.
I got error to console:

func=xmlSecOpenSSLX509StoreVerify:file=x509vfy.c:line=360:obj=x509-store:subj=X509_verify_cert:error=4:crypto
library function failed:subj=/C=UA/ST=Kyiv
region/L=Kyiv/O=test/OU=test/CN=server1/emailAddress=s
func=xmlSecOpenSSLX509StoreVerify:file=x509vfy.c:line=408:obj=x509-store:subj=unknown:error=71:certificate
verification failed:err=20;msg=unable to get local issuer certificate
OK
SignedInfo References (ok/all): 1/1?
Manifests References (ok/all): 0/0?

but verification result dsigCtx->status has xmlSecDSigStatusSucceeded value.

Can you tell me how can I verify that certificate chain is invalid with
xmlsec api?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.aleksey.com/pipermail/xmlsec/attachments/20120814/34932e08/attachment.html>

From aleksey at aleksey.com  Tue Aug 14 10:03:58 2012
From: aleksey at aleksey.com (Aleksey Sanin)
Date: Tue, 14 Aug 2012 10:03:58 -0700
Subject: [xmlsec] Verify invalid certificate chain
In-Reply-To: <CAGRgBF+Pqv=6oCTM3udBJGzLhg05w9DJpjbkHxzf7W_8qv=0UQ@mail.gmail.com>
References: <CAGRgBF+Pqv=6oCTM3udBJGzLhg05w9DJpjbkHxzf7W_8qv=0UQ@mail.gmail.com>
Message-ID: <502A84FE.80706@aleksey.com>

Roman,

During the verification, xmlsec tries to verify the signature using
all possible certificate chains. It is enough to have one of them
succeed. The errors you see are from ones that failed. Safe to ignore
as long, just check the result code.

Aleksey

On 8/14/12 8:38 AM, Roman Khlystik wrote:
> Hi Aleksey!
> 
> I'm trying to develop simple license system using xmlsec library.
> My idea was to build simple private PKI with one CA key pair and
> separate key-pair for each customer.
> Then I planned to sign xml license file with client certificate for each
> client.
> 
> I decided to embbed CA certificate in our app and verify certificate
> chain from xml file up to CA certificate.
> But I have a problem with xmlsec library. I can't find how to verify
> full certificate chain with it.
> I used example from here
> http://www.aleksey.com/xmlsec/api/xmlsec-verify-with-x509.html?
> <http://www.aleksey.com/xmlsec/api/xmlsec-verify-with-x509.html%C2%B7>
> and I have a problem when certificate chain is invalid.
> I got error to console:
> 
> func=xmlSecOpenSSLX509StoreVerify:file=x509vfy.c:line=360:obj=x509-store:subj=X509_verify_cert:error=4:crypto
> library function failed:subj=/C=UA/ST=Kyiv
> region/L=Kyiv/O=test/OU=test/CN=server1/emailAddress=s
> func=xmlSecOpenSSLX509StoreVerify:file=x509vfy.c:line=408:obj=x509-store:subj=unknown:error=71:certificate
> verification failed:err=20;msg=unable to get local issuer certificate
> OK
> SignedInfo References (ok/all): 1/1?
> Manifests References (ok/all): 0/0?
> 
> but verification result dsigCtx->status has xmlSecDSigStatusSucceeded value.
> 
> Can you tell me how can I verify that certificate chain is invalid with
> xmlsec api?
> 
> 
> _______________________________________________
> xmlsec mailing list
> xmlsec at aleksey.com
> http://www.aleksey.com/mailman/listinfo/xmlsec
> 

From dont.avt at gmail.com  Wed Aug 15 01:21:59 2012
From: dont.avt at gmail.com (Roman Khlystik)
Date: Wed, 15 Aug 2012 11:21:59 +0300
Subject: [xmlsec] Verify invalid certificate chain
In-Reply-To: <502A84FE.80706@aleksey.com>
References: <CAGRgBF+Pqv=6oCTM3udBJGzLhg05w9DJpjbkHxzf7W_8qv=0UQ@mail.gmail.com>
 <502A84FE.80706@aleksey.com>
Message-ID: <CAGRgBFK_PoK8PgsUWhjW7OVFJGEUA14PYULXUMYA2xbxSwDPiQ@mail.gmail.com>

Thanks for your answer, Aleksey.

I think I've understood behaviour of xmlsec in this situation.
And according to this logic I assume (and actually I checked it) that when
there isn't any
valid certificate chain result code of signature verification is still
succeeded. Why?

Here is example using command-line tool.
ca.crt isn't related to the certificate in license-signed-ca1-server1.xml.
So, there isn't any valid certificate chain. Why verification status is OK?

> #xmlsec1 --verify --trusted-pem cas/ca2/ca/certs/ca.crt
> license-signed-ca1-server1.xml



> func=xmlSecOpenSSLX509StoreVerify:file=x509vfy.c:line=360:obj=x509-store:subj=X509_verify_cert:error=4:crypto
> library function failed:subj=/C=UA/ST=Kyiv region/L=Kyiv/O=test/OU=Ukraine
> Department/CN=server1/emailAddress=support at test.com;err=20;msg=unable to
> get local issuer certificate
> func=xmlSecOpenSSLX509StoreVerify:file=x509vfy.c:line=408:obj=x509-store:subj=unknown:error=71:certificate
> verification failed:err=20;msg=unable to get local issuer certificate
> OK
> SignedInfo References (ok/all): 1/1
> Manifests References (ok/all): 0/0



So, I have another question: Is it possibe to detect with xmlsec that there
is no one valid certificate chain up to the one of the trusted
certificates? I want to reject signed xml file if there isn't any valid
vertificate chain.

Thanks.

2012/8/14 Aleksey Sanin <aleksey at aleksey.com>

> Roman,
>
> During the verification, xmlsec tries to verify the signature using
> all possible certificate chains. It is enough to have one of them
> succeed. The errors you see are from ones that failed. Safe to ignore
> as long, just check the result code.
>
> Aleksey
>
> On 8/14/12 8:38 AM, Roman Khlystik wrote:
> > Hi Aleksey!
> >
> > I'm trying to develop simple license system using xmlsec library.
> > My idea was to build simple private PKI with one CA key pair and
> > separate key-pair for each customer.
> > Then I planned to sign xml license file with client certificate for each
> > client.
> >
> > I decided to embbed CA certificate in our app and verify certificate
> > chain from xml file up to CA certificate.
> > But I have a problem with xmlsec library. I can't find how to verify
> > full certificate chain with it.
> > I used example from here
> > http://www.aleksey.com/xmlsec/api/xmlsec-verify-with-x509.html?
> > <http://www.aleksey.com/xmlsec/api/xmlsec-verify-with-x509.html%C2%B7>
> > and I have a problem when certificate chain is invalid.
> > I got error to console:
> >
> >
> func=xmlSecOpenSSLX509StoreVerify:file=x509vfy.c:line=360:obj=x509-store:subj=X509_verify_cert:error=4:crypto
> > library function failed:subj=/C=UA/ST=Kyiv
> > region/L=Kyiv/O=test/OU=test/CN=server1/emailAddress=s
> >
> func=xmlSecOpenSSLX509StoreVerify:file=x509vfy.c:line=408:obj=x509-store:subj=unknown:error=71:certificate
> > verification failed:err=20;msg=unable to get local issuer certificate
> > OK
> > SignedInfo References (ok/all): 1/1?
> > Manifests References (ok/all): 0/0?
> >
> > but verification result dsigCtx->status has xmlSecDSigStatusSucceeded
> value.
> >
> > Can you tell me how can I verify that certificate chain is invalid with
> > xmlsec api?
> >
> >
> > _______________________________________________
> > xmlsec mailing list
> > xmlsec at aleksey.com
> > http://www.aleksey.com/mailman/listinfo/xmlsec
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.aleksey.com/pipermail/xmlsec/attachments/20120815/66a43e5c/attachment.html>

From aleksey at aleksey.com  Wed Aug 15 07:24:07 2012
From: aleksey at aleksey.com (Aleksey Sanin)
Date: Wed, 15 Aug 2012 07:24:07 -0700
Subject: [xmlsec] Verify invalid certificate chain
In-Reply-To: <CAGRgBFK_PoK8PgsUWhjW7OVFJGEUA14PYULXUMYA2xbxSwDPiQ@mail.gmail.com>
References: <CAGRgBF+Pqv=6oCTM3udBJGzLhg05w9DJpjbkHxzf7W_8qv=0UQ@mail.gmail.com>
 <502A84FE.80706@aleksey.com>
 <CAGRgBFK_PoK8PgsUWhjW7OVFJGEUA14PYULXUMYA2xbxSwDPiQ@mail.gmail.com>
Message-ID: <502BB107.4000402@aleksey.com>

That shouldn't be the case. The only possibility is that there
is a key in the signature file (not in certificate).

Run xmlsec with debug output to find out where it finds key

Aleksey

On 8/15/12 1:21 AM, Roman Khlystik wrote:
> Thanks for your answer, Aleksey.
> 
> I think I've understood behaviour of xmlsec in this situation.
> And according to this logic I assume (and actually I checked it) that
> when there isn't any
> valid certificate chain result code of signature verification is still
> succeeded. Why?
> 
> Here is example using command-line tool.
> ca.crt isn't related to the certificate
> in license-signed-ca1-server1.xml. So, there isn't any valid certificate
> chain. Why verification status is OK?
> 
>     #xmlsec1 --verify --trusted-pem cas/ca2/ca/certs/ca.crt
>     license-signed-ca1-server1.xml
> 
>  
> 
>     func=xmlSecOpenSSLX509StoreVerify:file=x509vfy.c:line=360:obj=x509-store:subj=X509_verify_cert:error=4:crypto
>     library function failed:subj=/C=UA/ST=Kyiv
>     region/L=Kyiv/O=test/OU=Ukraine
>     Department/CN=server1/emailAddress=support at test.com
>     <mailto:support at test.com>;err=20;msg=unable to get local issuer
>     certificate
>     func=xmlSecOpenSSLX509StoreVerify:file=x509vfy.c:line=408:obj=x509-store:subj=unknown:error=71:certificate
>     verification failed:err=20;msg=unable to get local issuer certificate
>     OK
>     SignedInfo References (ok/all): 1/1
>     Manifests References (ok/all): 0/0
> 
> 
> 
> So, I have another question: Is it possibe to detect with xmlsec that
> there is no one valid certificate chain up to the one of the trusted
> certificates? I want to reject signed xml file if there isn't any valid
> vertificate chain.
> 
> Thanks.
> 
> 2012/8/14 Aleksey Sanin <aleksey at aleksey.com <mailto:aleksey at aleksey.com>>
> 
>     Roman,
> 
>     During the verification, xmlsec tries to verify the signature using
>     all possible certificate chains. It is enough to have one of them
>     succeed. The errors you see are from ones that failed. Safe to ignore
>     as long, just check the result code.
> 
>     Aleksey
> 
>     On 8/14/12 8:38 AM, Roman Khlystik wrote:
>     > Hi Aleksey!
>     >
>     > I'm trying to develop simple license system using xmlsec library.
>     > My idea was to build simple private PKI with one CA key pair and
>     > separate key-pair for each customer.
>     > Then I planned to sign xml license file with client certificate
>     for each
>     > client.
>     >
>     > I decided to embbed CA certificate in our app and verify certificate
>     > chain from xml file up to CA certificate.
>     > But I have a problem with xmlsec library. I can't find how to verify
>     > full certificate chain with it.
>     > I used example from here
>     > http://www.aleksey.com/xmlsec/api/xmlsec-verify-with-x509.html?
>     <http://www.aleksey.com/xmlsec/api/xmlsec-verify-with-x509.html%C2%B7>
>     > <http://www.aleksey.com/xmlsec/api/xmlsec-verify-with-x509.html%C2%B7>
>     > and I have a problem when certificate chain is invalid.
>     > I got error to console:
>     >
>     >
>     func=xmlSecOpenSSLX509StoreVerify:file=x509vfy.c:line=360:obj=x509-store:subj=X509_verify_cert:error=4:crypto
>     > library function failed:subj=/C=UA/ST=Kyiv
>     > region/L=Kyiv/O=test/OU=test/CN=server1/emailAddress=s
>     >
>     func=xmlSecOpenSSLX509StoreVerify:file=x509vfy.c:line=408:obj=x509-store:subj=unknown:error=71:certificate
>     > verification failed:err=20;msg=unable to get local issuer certificate
>     > OK
>     > SignedInfo References (ok/all): 1/1?
>     > Manifests References (ok/all): 0/0?
>     >
>     > but verification result dsigCtx->status has
>     xmlSecDSigStatusSucceeded value.
>     >
>     > Can you tell me how can I verify that certificate chain is invalid
>     with
>     > xmlsec api?
>     >
>     >
>     > _______________________________________________
>     > xmlsec mailing list
>     > xmlsec at aleksey.com <mailto:xmlsec at aleksey.com>
>     > http://www.aleksey.com/mailman/listinfo/xmlsec
>     >
> 
> 

From isurulucky at gmail.com  Fri Aug 17 02:50:48 2012
From: isurulucky at gmail.com (Isuru Haththotuwa)
Date: Fri, 17 Aug 2012 15:20:48 +0530
Subject: [xmlsec] xmlsec for windows 64bit
Message-ID: <CAAq0x-Wu1iPJnphd2KY+DiemkyYmEW6Y17PpxkToqVk8=BeyhQ@mail.gmail.com>

Hi all,

We use xmlsec as a third party library for a web service engine. Currently
are in need of upgrading to VC10 64bit build in Windows 7. I searched on
the internet but didn't come across the topic of building xmlsec on Windows
64 bit. Are there any pre-compiled libraries available to download? If not
any help on building xmlsec on Windows 7 (64 bit) is much appreciated.


-- 
Thanks and Regards,
Isuru
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.aleksey.com/pipermail/xmlsec/attachments/20120817/059beae2/attachment.html>

From dont.avt at gmail.com  Fri Aug 17 05:38:28 2012
From: dont.avt at gmail.com (Roman Khlystik)
Date: Fri, 17 Aug 2012 15:38:28 +0300
Subject: [xmlsec] Verify invalid certificate chain
In-Reply-To: <502BB107.4000402@aleksey.com>
References: <CAGRgBF+Pqv=6oCTM3udBJGzLhg05w9DJpjbkHxzf7W_8qv=0UQ@mail.gmail.com>
 <502A84FE.80706@aleksey.com>
 <CAGRgBFK_PoK8PgsUWhjW7OVFJGEUA14PYULXUMYA2xbxSwDPiQ@mail.gmail.com>
 <502BB107.4000402@aleksey.com>
Message-ID: <CAGRgBFKvMFSi0q1NwbLY__zWd3WVucwi+DnYt1KZZM5N5X0vBA@mail.gmail.com>

Thanks, Aleksey.

Really, I had RSA key in signature file.

I made some investigation, I may be wrong, but I don't understand the
security guarantee of xml signature.
I'll try to explain my view on it, please indicate where I'm wrong.

As I've understood during signature verification xmlsec might choose key
for verification from KeyValue field or from certificate in X509Data field.
There isn't any check that public key from KeyValue is the same as public
key from certificate.
Key selection algorithm is the next:
- Xmlsec is trying to build certificate chain from certificate in the file
up to a trusted cert.
  - if it successed, key from certificate is used
  - if it failed, xmlsec is looking for the KeyValue field.
      - if KeyValue field is found, xmlsec uses it for verification.
      - if KeyValue isn't found xmlsec reports an error.

So, lets assume that I'm a bad guy and I want to substitute a signed xml
file.
All I have to do is just sign a file only with KeyValue field and without
any X509Data field.
Thus, user of signed document can't be sure that this document was sent by
expected sender.

I think that there is some misunderstanding in application of xml signature
or I've just missed something.
Maybe it's possible to force xmlsec perform verification using key only
from X509 field? Or maybe I just may ask xmlsec to ignore key from KeyValue
field?

Thanks.

2012/8/15 Aleksey Sanin <aleksey at aleksey.com>

> That shouldn't be the case. The only possibility is that there
> is a key in the signature file (not in certificate).
>
> Run xmlsec with debug output to find out where it finds key
>
> Aleksey
>
> On 8/15/12 1:21 AM, Roman Khlystik wrote:
> > Thanks for your answer, Aleksey.
> >
> > I think I've understood behaviour of xmlsec in this situation.
> > And according to this logic I assume (and actually I checked it) that
> > when there isn't any
> > valid certificate chain result code of signature verification is still
> > succeeded. Why?
> >
> > Here is example using command-line tool.
> > ca.crt isn't related to the certificate
> > in license-signed-ca1-server1.xml. So, there isn't any valid certificate
> > chain. Why verification status is OK?
> >
> >     #xmlsec1 --verify --trusted-pem cas/ca2/ca/certs/ca.crt
> >     license-signed-ca1-server1.xml
> >
> >
> >
> >
> func=xmlSecOpenSSLX509StoreVerify:file=x509vfy.c:line=360:obj=x509-store:subj=X509_verify_cert:error=4:crypto
> >     library function failed:subj=/C=UA/ST=Kyiv
> >     region/L=Kyiv/O=test/OU=Ukraine
> >     Department/CN=server1/emailAddress=support at test.com
> >     <mailto:support at test.com>;err=20;msg=unable to get local issuer
> >     certificate
> >
> func=xmlSecOpenSSLX509StoreVerify:file=x509vfy.c:line=408:obj=x509-store:subj=unknown:error=71:certificate
> >     verification failed:err=20;msg=unable to get local issuer certificate
> >     OK
> >     SignedInfo References (ok/all): 1/1
> >     Manifests References (ok/all): 0/0
> >
> >
> >
> > So, I have another question: Is it possibe to detect with xmlsec that
> > there is no one valid certificate chain up to the one of the trusted
> > certificates? I want to reject signed xml file if there isn't any valid
> > vertificate chain.
> >
> > Thanks.
> >
> > 2012/8/14 Aleksey Sanin <aleksey at aleksey.com <mailto:aleksey at aleksey.com
> >>
> >
> >     Roman,
> >
> >     During the verification, xmlsec tries to verify the signature using
> >     all possible certificate chains. It is enough to have one of them
> >     succeed. The errors you see are from ones that failed. Safe to ignore
> >     as long, just check the result code.
> >
> >     Aleksey
> >
> >     On 8/14/12 8:38 AM, Roman Khlystik wrote:
> >     > Hi Aleksey!
> >     >
> >     > I'm trying to develop simple license system using xmlsec library.
> >     > My idea was to build simple private PKI with one CA key pair and
> >     > separate key-pair for each customer.
> >     > Then I planned to sign xml license file with client certificate
> >     for each
> >     > client.
> >     >
> >     > I decided to embbed CA certificate in our app and verify
> certificate
> >     > chain from xml file up to CA certificate.
> >     > But I have a problem with xmlsec library. I can't find how to
> verify
> >     > full certificate chain with it.
> >     > I used example from here
> >     > http://www.aleksey.com/xmlsec/api/xmlsec-verify-with-x509.html?
> >     <
> http://www.aleksey.com/xmlsec/api/xmlsec-verify-with-x509.html%C2%B7>
> >     > <
> http://www.aleksey.com/xmlsec/api/xmlsec-verify-with-x509.html%C2%B7>
> >     > and I have a problem when certificate chain is invalid.
> >     > I got error to console:
> >     >
> >     >
> >
> func=xmlSecOpenSSLX509StoreVerify:file=x509vfy.c:line=360:obj=x509-store:subj=X509_verify_cert:error=4:crypto
> >     > library function failed:subj=/C=UA/ST=Kyiv
> >     > region/L=Kyiv/O=test/OU=test/CN=server1/emailAddress=s
> >     >
> >
> func=xmlSecOpenSSLX509StoreVerify:file=x509vfy.c:line=408:obj=x509-store:subj=unknown:error=71:certificate
> >     > verification failed:err=20;msg=unable to get local issuer
> certificate
> >     > OK
> >     > SignedInfo References (ok/all): 1/1?
> >     > Manifests References (ok/all): 0/0?
> >     >
> >     > but verification result dsigCtx->status has
> >     xmlSecDSigStatusSucceeded value.
> >     >
> >     > Can you tell me how can I verify that certificate chain is invalid
> >     with
> >     > xmlsec api?
> >     >
> >     >
> >     > _______________________________________________
> >     > xmlsec mailing list
> >     > xmlsec at aleksey.com <mailto:xmlsec at aleksey.com>
> >     > http://www.aleksey.com/mailman/listinfo/xmlsec
> >     >
> >
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.aleksey.com/pipermail/xmlsec/attachments/20120817/c85c7ce9/attachment.html>

From aleksey at aleksey.com  Fri Aug 17 07:33:47 2012
From: aleksey at aleksey.com (Aleksey Sanin)
Date: Fri, 17 Aug 2012 07:33:47 -0700
Subject: [xmlsec] xmlsec for windows 64bit
In-Reply-To: <CAAq0x-Wu1iPJnphd2KY+DiemkyYmEW6Y17PpxkToqVk8=BeyhQ@mail.gmail.com>
References: <CAAq0x-Wu1iPJnphd2KY+DiemkyYmEW6Y17PpxkToqVk8=BeyhQ@mail.gmail.com>
Message-ID: <502E564B.5030703@aleksey.com>

Hi Isuru,

Take a look at win32/ folder. There are nmake makefiles that should
be pretty straightforward. There are no special xmlsec options,
just a list of files to compile :)

Aleksey

On 8/17/12 2:50 AM, Isuru Haththotuwa wrote:
> Hi all,
> 
> We use xmlsec as a third party library for a web service engine.
> Currently are in need of upgrading to VC10 64bit build in Windows 7. I
> searched on the internet but didn't come across the topic of building
> xmlsec on Windows 64 bit. Are there any pre-compiled libraries available
> to download? If not any help on building xmlsec on Windows 7 (64 bit) is
> much appreciated.
> 
> 
> -- 
> Thanks and Regards,
> Isuru
> 
> 
> 
> _______________________________________________
> xmlsec mailing list
> xmlsec at aleksey.com
> http://www.aleksey.com/mailman/listinfo/xmlsec
> 

From aleksey at aleksey.com  Fri Aug 17 07:36:33 2012
From: aleksey at aleksey.com (Aleksey Sanin)
Date: Fri, 17 Aug 2012 07:36:33 -0700
Subject: [xmlsec] Verify invalid certificate chain
In-Reply-To: <CAGRgBFKvMFSi0q1NwbLY__zWd3WVucwi+DnYt1KZZM5N5X0vBA@mail.gmail.com>
References: <CAGRgBF+Pqv=6oCTM3udBJGzLhg05w9DJpjbkHxzf7W_8qv=0UQ@mail.gmail.com>
 <502A84FE.80706@aleksey.com>
 <CAGRgBFK_PoK8PgsUWhjW7OVFJGEUA14PYULXUMYA2xbxSwDPiQ@mail.gmail.com>
 <502BB107.4000402@aleksey.com>
 <CAGRgBFKvMFSi0q1NwbLY__zWd3WVucwi+DnYt1KZZM5N5X0vBA@mail.gmail.com>
Message-ID: <502E56F1.1000909@aleksey.com>

That makes sense. If you have KeyValue then xmlsec happily pick it up.
You can limit the key data used by xmlsec for looking up the key.
With xmlsec command line tool, try "--enabled-key-data" option
(use --list-key-data to see the list).

Aleksey

On 8/17/12 5:38 AM, Roman Khlystik wrote:
> Thanks, Aleksey.
> 
> Really, I had RSA key in signature file.
> 
> I made some investigation, I may be wrong, but I don't understand the
> security guarantee of xml signature.
> I'll try to explain my view on it, please indicate where I'm wrong.
> 
> As I've understood during signature verification xmlsec might choose key
> for verification from KeyValue field or from certificate in X509Data
> field. There isn't any check that public key from KeyValue is the same
> as public key from certificate.
> Key selection algorithm is the next: 
> - Xmlsec is trying to build certificate chain from certificate in the
> file up to a trusted cert.
>   - if it successed, key from certificate is used
>   - if it failed, xmlsec is looking for the KeyValue field.
>       - if KeyValue field is found, xmlsec uses it for verification.
>       - if KeyValue isn't found xmlsec reports an error.
>        
> So, lets assume that I'm a bad guy and I want to substitute a signed xml
> file.
> All I have to do is just sign a file only with KeyValue field and
> without any X509Data field.
> Thus, user of signed document can't be sure that this document was sent
> by expected sender.
> 
> I think that there is some misunderstanding in application of xml
> signature or I've just missed something.
> Maybe it's possible to force xmlsec perform verification using key only
> from X509 field? Or maybe I just may ask xmlsec to ignore key from
> KeyValue field?
> 
> Thanks.
> 
> 2012/8/15 Aleksey Sanin <aleksey at aleksey.com <mailto:aleksey at aleksey.com>>
> 
>     That shouldn't be the case. The only possibility is that there
>     is a key in the signature file (not in certificate).
> 
>     Run xmlsec with debug output to find out where it finds key
> 
>     Aleksey
> 
>     On 8/15/12 1:21 AM, Roman Khlystik wrote:
>     > Thanks for your answer, Aleksey.
>     >
>     > I think I've understood behaviour of xmlsec in this situation.
>     > And according to this logic I assume (and actually I checked it) that
>     > when there isn't any
>     > valid certificate chain result code of signature verification is still
>     > succeeded. Why?
>     >
>     > Here is example using command-line tool.
>     > ca.crt isn't related to the certificate
>     > in license-signed-ca1-server1.xml. So, there isn't any valid
>     certificate
>     > chain. Why verification status is OK?
>     >
>     >     #xmlsec1 --verify --trusted-pem cas/ca2/ca/certs/ca.crt
>     >     license-signed-ca1-server1.xml
>     >
>     >
>     >
>     >    
>     func=xmlSecOpenSSLX509StoreVerify:file=x509vfy.c:line=360:obj=x509-store:subj=X509_verify_cert:error=4:crypto
>     >     library function failed:subj=/C=UA/ST=Kyiv
>     >     region/L=Kyiv/O=test/OU=Ukraine
>     >     Department/CN=server1/emailAddress=support at test.com
>     <mailto:support at test.com>
>     >     <mailto:support at test.com
>     <mailto:support at test.com>>;err=20;msg=unable to get local issuer
>     >     certificate
>     >    
>     func=xmlSecOpenSSLX509StoreVerify:file=x509vfy.c:line=408:obj=x509-store:subj=unknown:error=71:certificate
>     >     verification failed:err=20;msg=unable to get local issuer
>     certificate
>     >     OK
>     >     SignedInfo References (ok/all): 1/1
>     >     Manifests References (ok/all): 0/0
>     >
>     >
>     >
>     > So, I have another question: Is it possibe to detect with xmlsec that
>     > there is no one valid certificate chain up to the one of the trusted
>     > certificates? I want to reject signed xml file if there isn't any
>     valid
>     > vertificate chain.
>     >
>     > Thanks.
>     >
>     > 2012/8/14 Aleksey Sanin <aleksey at aleksey.com
>     <mailto:aleksey at aleksey.com> <mailto:aleksey at aleksey.com
>     <mailto:aleksey at aleksey.com>>>
>     >
>     >     Roman,
>     >
>     >     During the verification, xmlsec tries to verify the signature
>     using
>     >     all possible certificate chains. It is enough to have one of them
>     >     succeed. The errors you see are from ones that failed. Safe to
>     ignore
>     >     as long, just check the result code.
>     >
>     >     Aleksey
>     >
>     >     On 8/14/12 8:38 AM, Roman Khlystik wrote:
>     >     > Hi Aleksey!
>     >     >
>     >     > I'm trying to develop simple license system using xmlsec
>     library.
>     >     > My idea was to build simple private PKI with one CA key pair and
>     >     > separate key-pair for each customer.
>     >     > Then I planned to sign xml license file with client certificate
>     >     for each
>     >     > client.
>     >     >
>     >     > I decided to embbed CA certificate in our app and verify
>     certificate
>     >     > chain from xml file up to CA certificate.
>     >     > But I have a problem with xmlsec library. I can't find how
>     to verify
>     >     > full certificate chain with it.
>     >     > I used example from here
>     >     >
>     http://www.aleksey.com/xmlsec/api/xmlsec-verify-with-x509.html?
>     <http://www.aleksey.com/xmlsec/api/xmlsec-verify-with-x509.html%C2%B7>
>     >    
>     <http://www.aleksey.com/xmlsec/api/xmlsec-verify-with-x509.html%C2%B7>
>     >     >
>     <http://www.aleksey.com/xmlsec/api/xmlsec-verify-with-x509.html%C2%B7>
>     >     > and I have a problem when certificate chain is invalid.
>     >     > I got error to console:
>     >     >
>     >     >
>     >    
>     func=xmlSecOpenSSLX509StoreVerify:file=x509vfy.c:line=360:obj=x509-store:subj=X509_verify_cert:error=4:crypto
>     >     > library function failed:subj=/C=UA/ST=Kyiv
>     >     > region/L=Kyiv/O=test/OU=test/CN=server1/emailAddress=s
>     >     >
>     >    
>     func=xmlSecOpenSSLX509StoreVerify:file=x509vfy.c:line=408:obj=x509-store:subj=unknown:error=71:certificate
>     >     > verification failed:err=20;msg=unable to get local issuer
>     certificate
>     >     > OK
>     >     > SignedInfo References (ok/all): 1/1?
>     >     > Manifests References (ok/all): 0/0?
>     >     >
>     >     > but verification result dsigCtx->status has
>     >     xmlSecDSigStatusSucceeded value.
>     >     >
>     >     > Can you tell me how can I verify that certificate chain is
>     invalid
>     >     with
>     >     > xmlsec api?
>     >     >
>     >     >
>     >     > _______________________________________________
>     >     > xmlsec mailing list
>     >     > xmlsec at aleksey.com <mailto:xmlsec at aleksey.com>
>     <mailto:xmlsec at aleksey.com <mailto:xmlsec at aleksey.com>>
>     >     > http://www.aleksey.com/mailman/listinfo/xmlsec
>     >     >
>     >
>     >
> 
> 

From dont.avt at gmail.com  Fri Aug 17 08:18:32 2012
From: dont.avt at gmail.com (Roman Khlystik)
Date: Fri, 17 Aug 2012 18:18:32 +0300
Subject: [xmlsec] Verify invalid certificate chain
In-Reply-To: <502E56F1.1000909@aleksey.com>
References: <CAGRgBF+Pqv=6oCTM3udBJGzLhg05w9DJpjbkHxzf7W_8qv=0UQ@mail.gmail.com>
 <502A84FE.80706@aleksey.com>
 <CAGRgBFK_PoK8PgsUWhjW7OVFJGEUA14PYULXUMYA2xbxSwDPiQ@mail.gmail.com>
 <502BB107.4000402@aleksey.com>
 <CAGRgBFKvMFSi0q1NwbLY__zWd3WVucwi+DnYt1KZZM5N5X0vBA@mail.gmail.com>
 <502E56F1.1000909@aleksey.com>
Message-ID: <CAGRgBF+u314QONa_pnDP_pX7=rM+NGJHF3MFgxOKXXHDGuZ7+w@mail.gmail.com>

Thanks, Aleksey.
It's exactly what I wanted.

2012/8/17 Aleksey Sanin <aleksey at aleksey.com>

> That makes sense. If you have KeyValue then xmlsec happily pick it up.
> You can limit the key data used by xmlsec for looking up the key.
> With xmlsec command line tool, try "--enabled-key-data" option
> (use --list-key-data to see the list).
>
> Aleksey
>
> On 8/17/12 5:38 AM, Roman Khlystik wrote:
> > Thanks, Aleksey.
> >
> > Really, I had RSA key in signature file.
> >
> > I made some investigation, I may be wrong, but I don't understand the
> > security guarantee of xml signature.
> > I'll try to explain my view on it, please indicate where I'm wrong.
> >
> > As I've understood during signature verification xmlsec might choose key
> > for verification from KeyValue field or from certificate in X509Data
> > field. There isn't any check that public key from KeyValue is the same
> > as public key from certificate.
> > Key selection algorithm is the next:
> > - Xmlsec is trying to build certificate chain from certificate in the
> > file up to a trusted cert.
> >   - if it successed, key from certificate is used
> >   - if it failed, xmlsec is looking for the KeyValue field.
> >       - if KeyValue field is found, xmlsec uses it for verification.
> >       - if KeyValue isn't found xmlsec reports an error.
> >
> > So, lets assume that I'm a bad guy and I want to substitute a signed xml
> > file.
> > All I have to do is just sign a file only with KeyValue field and
> > without any X509Data field.
> > Thus, user of signed document can't be sure that this document was sent
> > by expected sender.
> >
> > I think that there is some misunderstanding in application of xml
> > signature or I've just missed something.
> > Maybe it's possible to force xmlsec perform verification using key only
> > from X509 field? Or maybe I just may ask xmlsec to ignore key from
> > KeyValue field?
> >
> > Thanks.
> >
> > 2012/8/15 Aleksey Sanin <aleksey at aleksey.com <mailto:aleksey at aleksey.com
> >>
> >
> >     That shouldn't be the case. The only possibility is that there
> >     is a key in the signature file (not in certificate).
> >
> >     Run xmlsec with debug output to find out where it finds key
> >
> >     Aleksey
> >
> >     On 8/15/12 1:21 AM, Roman Khlystik wrote:
> >     > Thanks for your answer, Aleksey.
> >     >
> >     > I think I've understood behaviour of xmlsec in this situation.
> >     > And according to this logic I assume (and actually I checked it)
> that
> >     > when there isn't any
> >     > valid certificate chain result code of signature verification is
> still
> >     > succeeded. Why?
> >     >
> >     > Here is example using command-line tool.
> >     > ca.crt isn't related to the certificate
> >     > in license-signed-ca1-server1.xml. So, there isn't any valid
> >     certificate
> >     > chain. Why verification status is OK?
> >     >
> >     >     #xmlsec1 --verify --trusted-pem cas/ca2/ca/certs/ca.crt
> >     >     license-signed-ca1-server1.xml
> >     >
> >     >
> >     >
> >     >
> >
> func=xmlSecOpenSSLX509StoreVerify:file=x509vfy.c:line=360:obj=x509-store:subj=X509_verify_cert:error=4:crypto
> >     >     library function failed:subj=/C=UA/ST=Kyiv
> >     >     region/L=Kyiv/O=test/OU=Ukraine
> >     >     Department/CN=server1/emailAddress=support at test.com
> >     <mailto:support at test.com>
> >     >     <mailto:support at test.com
> >     <mailto:support at test.com>>;err=20;msg=unable to get local issuer
> >     >     certificate
> >     >
> >
> func=xmlSecOpenSSLX509StoreVerify:file=x509vfy.c:line=408:obj=x509-store:subj=unknown:error=71:certificate
> >     >     verification failed:err=20;msg=unable to get local issuer
> >     certificate
> >     >     OK
> >     >     SignedInfo References (ok/all): 1/1
> >     >     Manifests References (ok/all): 0/0
> >     >
> >     >
> >     >
> >     > So, I have another question: Is it possibe to detect with xmlsec
> that
> >     > there is no one valid certificate chain up to the one of the
> trusted
> >     > certificates? I want to reject signed xml file if there isn't any
> >     valid
> >     > vertificate chain.
> >     >
> >     > Thanks.
> >     >
> >     > 2012/8/14 Aleksey Sanin <aleksey at aleksey.com
> >     <mailto:aleksey at aleksey.com> <mailto:aleksey at aleksey.com
> >     <mailto:aleksey at aleksey.com>>>
> >     >
> >     >     Roman,
> >     >
> >     >     During the verification, xmlsec tries to verify the signature
> >     using
> >     >     all possible certificate chains. It is enough to have one of
> them
> >     >     succeed. The errors you see are from ones that failed. Safe to
> >     ignore
> >     >     as long, just check the result code.
> >     >
> >     >     Aleksey
> >     >
> >     >     On 8/14/12 8:38 AM, Roman Khlystik wrote:
> >     >     > Hi Aleksey!
> >     >     >
> >     >     > I'm trying to develop simple license system using xmlsec
> >     library.
> >     >     > My idea was to build simple private PKI with one CA key pair
> and
> >     >     > separate key-pair for each customer.
> >     >     > Then I planned to sign xml license file with client
> certificate
> >     >     for each
> >     >     > client.
> >     >     >
> >     >     > I decided to embbed CA certificate in our app and verify
> >     certificate
> >     >     > chain from xml file up to CA certificate.
> >     >     > But I have a problem with xmlsec library. I can't find how
> >     to verify
> >     >     > full certificate chain with it.
> >     >     > I used example from here
> >     >     >
> >     http://www.aleksey.com/xmlsec/api/xmlsec-verify-with-x509.html?
> >     <
> http://www.aleksey.com/xmlsec/api/xmlsec-verify-with-x509.html%C2%B7>
> >     >
> >     <
> http://www.aleksey.com/xmlsec/api/xmlsec-verify-with-x509.html%C2%B7>
> >     >     >
> >     <
> http://www.aleksey.com/xmlsec/api/xmlsec-verify-with-x509.html%C2%B7>
> >     >     > and I have a problem when certificate chain is invalid.
> >     >     > I got error to console:
> >     >     >
> >     >     >
> >     >
> >
> func=xmlSecOpenSSLX509StoreVerify:file=x509vfy.c:line=360:obj=x509-store:subj=X509_verify_cert:error=4:crypto
> >     >     > library function failed:subj=/C=UA/ST=Kyiv
> >     >     > region/L=Kyiv/O=test/OU=test/CN=server1/emailAddress=s
> >     >     >
> >     >
> >
> func=xmlSecOpenSSLX509StoreVerify:file=x509vfy.c:line=408:obj=x509-store:subj=unknown:error=71:certificate
> >     >     > verification failed:err=20;msg=unable to get local issuer
> >     certificate
> >     >     > OK
> >     >     > SignedInfo References (ok/all): 1/1?
> >     >     > Manifests References (ok/all): 0/0?
> >     >     >
> >     >     > but verification result dsigCtx->status has
> >     >     xmlSecDSigStatusSucceeded value.
> >     >     >
> >     >     > Can you tell me how can I verify that certificate chain is
> >     invalid
> >     >     with
> >     >     > xmlsec api?
> >     >     >
> >     >     >
> >     >     > _______________________________________________
> >     >     > xmlsec mailing list
> >     >     > xmlsec at aleksey.com <mailto:xmlsec at aleksey.com>
> >     <mailto:xmlsec at aleksey.com <mailto:xmlsec at aleksey.com>>
> >     >     > http://www.aleksey.com/mailman/listinfo/xmlsec
> >     >     >
> >     >
> >     >
> >
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.aleksey.com/pipermail/xmlsec/attachments/20120817/4f84a978/attachment.html>

From isurulucky at gmail.com  Sat Aug 18 06:07:10 2012
From: isurulucky at gmail.com (Isuru Haththotuwa)
Date: Sat, 18 Aug 2012 18:37:10 +0530
Subject: [xmlsec] xmlsec for windows 64bit
In-Reply-To: <502E564B.5030703@aleksey.com>
References: <CAAq0x-Wu1iPJnphd2KY+DiemkyYmEW6Y17PpxkToqVk8=BeyhQ@mail.gmail.com>
 <502E564B.5030703@aleksey.com>
Message-ID: <CAAq0x-WUvYhM=8+7UvupqGRy8+_nG+gVCNtShqRqBUnsX4g1sA@mail.gmail.com>

Hi Aleksey,

thanks for the reply. I had a look, read the README and proceeded with the
building. The external include files and libraries that I added are:

libxml
libxslt
openssl
iconv

however, in building, I get the following likn error:

Creating library binaries\libxmlsec.lib and object binaries\libxmlsec.exp
xmldsig.obj : error LNK2001: unresolved external symbol __imp_xmlFree
xmlenc.obj : error LNK2001: unresolved external symbol __imp_xmlFree
xmltree.obj : error LNK2001: unresolved external symbol __imp_xmlFree
xpath.obj : error LNK2001: unresolved external symbol __imp_xmlFree
soap.obj : error LNK2019: unresolved external symbol __imp_xmlFree
referenced in function xmlSecSoap12AddFaultSubcode
templates.obj : error LNK2001: unresolved external symbol __imp_xmlFree
transforms.obj : error LNK2001: unresolved external symbol __imp_xmlFree
xkms.obj : error LNK2001: unresolved external symbol __imp_xmlFree
keysdata.obj : error LNK2001: unresolved external symbol __imp_xmlFree
keysmngr.obj : error LNK2001: unresolved external symbol __imp_xmlFree
list.obj : error LNK2001: unresolved external symbol __imp_xmlFree
nodeset.obj : error LNK2001: unresolved external symbol __imp_xmlFree
dl.obj : error LNK2001: unresolved external symbol __imp_xmlFree
io.obj : error LNK2001: unresolved external symbol __imp_xmlFree
keyinfo.obj : error LNK2001: unresolved external symbol __imp_xmlFree
keys.obj : error LNK2001: unresolved external symbol __imp_xmlFree
base64.obj : error LNK2001: unresolved external symbol __imp_xmlFree
bn.obj : error LNK2001: unresolved external symbol __imp_xmlFree
buffer.obj : error LNK2001: unresolved external symbol __imp_xmlFree
c14n.obj : error LNK2001: unresolved external symbol __imp_xmlFree
xpath.obj : error LNK2001: unresolved external symbol __imp_xmlMalloc
xkms.obj : error LNK2001: unresolved external symbol __imp_xmlMalloc
xmldsig.obj : error LNK2001: unresolved external symbol __imp_xmlMalloc
xmlenc.obj : error LNK2001: unresolved external symbol __imp_xmlMalloc
xmltree.obj : error LNK2001: unresolved external symbol __imp_xmlMalloc
keysmngr.obj : error LNK2001: unresolved external symbol __imp_xmlMalloc
list.obj : error LNK2001: unresolved external symbol __imp_xmlMalloc
nodeset.obj : error LNK2001: unresolved external symbol __imp_xmlMalloc...
etc.


and it goes on and on.

I suspect the issue here is with the lib files and/or dll files of libxml
that I used. But I don't know how should I proceed from here. Any
suggestions for eliminating these errors?

Thank you.

On Fri, Aug 17, 2012 at 8:03 PM, Aleksey Sanin <aleksey at aleksey.com> wrote:

> Hi Isuru,
>
> Take a look at win32/ folder. There are nmake makefiles that should
> be pretty straightforward. There are no special xmlsec options,
> just a list of files to compile :)
>
> Aleksey
>
> On 8/17/12 2:50 AM, Isuru Haththotuwa wrote:
> > Hi all,
> >
> > We use xmlsec as a third party library for a web service engine.
> > Currently are in need of upgrading to VC10 64bit build in Windows 7. I
> > searched on the internet but didn't come across the topic of building
> > xmlsec on Windows 64 bit. Are there any pre-compiled libraries available
> > to download? If not any help on building xmlsec on Windows 7 (64 bit) is
> > much appreciated.
> >
> >
> > --
> > Thanks and Regards,
> > Isuru
> >
> >
> >
> > _______________________________________________
> > xmlsec mailing list
> > xmlsec at aleksey.com
> > http://www.aleksey.com/mailman/listinfo/xmlsec
> >
>



-- 
Thanks and Regards,
Isuru
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.aleksey.com/pipermail/xmlsec/attachments/20120818/9b5833a7/attachment.html>

From aleksey at aleksey.com  Sat Aug 18 08:49:26 2012
From: aleksey at aleksey.com (Aleksey Sanin)
Date: Sat, 18 Aug 2012 08:49:26 -0700
Subject: [xmlsec] xmlsec for windows 64bit
In-Reply-To: <CAAq0x-WUvYhM=8+7UvupqGRy8+_nG+gVCNtShqRqBUnsX4g1sA@mail.gmail.com>
References: <CAAq0x-Wu1iPJnphd2KY+DiemkyYmEW6Y17PpxkToqVk8=BeyhQ@mail.gmail.com>
 <502E564B.5030703@aleksey.com>
 <CAAq0x-WUvYhM=8+7UvupqGRy8+_nG+gVCNtShqRqBUnsX4g1sA@mail.gmail.com>
Message-ID: <502FB986.4010703@aleksey.com>

Sounds like static/dynamic libraries mismatch. Sorry, I did't
touch a windows box for close to 10 years now.

Aleksey

On 8/18/12 6:07 AM, Isuru Haththotuwa wrote:
> Hi Aleksey,
> 
> thanks for the reply. I had a look, read the README and proceeded with
> the building. The external include files and libraries that I added are:
> 
> libxml
> libxslt
> openssl
> iconv
> 
> however, in building, I get the following likn error:
> 
> Creating library binaries\libxmlsec.lib and object binaries\libxmlsec.exp
> xmldsig.obj : error LNK2001: unresolved external symbol __imp_xmlFree
> xmlenc.obj : error LNK2001: unresolved external symbol __imp_xmlFree
> xmltree.obj : error LNK2001: unresolved external symbol __imp_xmlFree
> xpath.obj : error LNK2001: unresolved external symbol __imp_xmlFree
> soap.obj : error LNK2019: unresolved external symbol __imp_xmlFree
> referenced in function xmlSecSoap12AddFaultSubcode
> templates.obj : error LNK2001: unresolved external symbol __imp_xmlFree
> transforms.obj : error LNK2001: unresolved external symbol __imp_xmlFree
> xkms.obj : error LNK2001: unresolved external symbol __imp_xmlFree
> keysdata.obj : error LNK2001: unresolved external symbol __imp_xmlFree
> keysmngr.obj : error LNK2001: unresolved external symbol __imp_xmlFree
> list.obj : error LNK2001: unresolved external symbol __imp_xmlFree
> nodeset.obj : error LNK2001: unresolved external symbol __imp_xmlFree
> dl.obj : error LNK2001: unresolved external symbol __imp_xmlFree
> io.obj : error LNK2001: unresolved external symbol __imp_xmlFree
> keyinfo.obj : error LNK2001: unresolved external symbol __imp_xmlFree
> keys.obj : error LNK2001: unresolved external symbol __imp_xmlFree
> base64.obj : error LNK2001: unresolved external symbol __imp_xmlFree
> bn.obj : error LNK2001: unresolved external symbol __imp_xmlFree
> buffer.obj : error LNK2001: unresolved external symbol __imp_xmlFree
> c14n.obj : error LNK2001: unresolved external symbol __imp_xmlFree
> xpath.obj : error LNK2001: unresolved external symbol __imp_xmlMalloc
> xkms.obj : error LNK2001: unresolved external symbol __imp_xmlMalloc
> xmldsig.obj : error LNK2001: unresolved external symbol __imp_xmlMalloc
> xmlenc.obj : error LNK2001: unresolved external symbol __imp_xmlMalloc
> xmltree.obj : error LNK2001: unresolved external symbol __imp_xmlMalloc
> keysmngr.obj : error LNK2001: unresolved external symbol __imp_xmlMalloc
> list.obj : error LNK2001: unresolved external symbol __imp_xmlMalloc
> nodeset.obj : error LNK2001: unresolved external symbol
> __imp_xmlMalloc... etc.
> 
> 
> and it goes on and on.
> 
> I suspect the issue here is with the lib files and/or dll files of
> libxml that I used. But I don't know how should I proceed from here. Any
> suggestions for eliminating these errors?
> 
> Thank you.
> 
> On Fri, Aug 17, 2012 at 8:03 PM, Aleksey Sanin <aleksey at aleksey.com
> <mailto:aleksey at aleksey.com>> wrote:
> 
>     Hi Isuru,
> 
>     Take a look at win32/ folder. There are nmake makefiles that should
>     be pretty straightforward. There are no special xmlsec options,
>     just a list of files to compile :)
> 
>     Aleksey
> 
>     On 8/17/12 2:50 AM, Isuru Haththotuwa wrote:
>     > Hi all,
>     >
>     > We use xmlsec as a third party library for a web service engine.
>     > Currently are in need of upgrading to VC10 64bit build in Windows 7. I
>     > searched on the internet but didn't come across the topic of building
>     > xmlsec on Windows 64 bit. Are there any pre-compiled libraries
>     available
>     > to download? If not any help on building xmlsec on Windows 7 (64
>     bit) is
>     > much appreciated.
>     >
>     >
>     > --
>     > Thanks and Regards,
>     > Isuru
>     >
>     >
>     >
>     > _______________________________________________
>     > xmlsec mailing list
>     > xmlsec at aleksey.com <mailto:xmlsec at aleksey.com>
>     > http://www.aleksey.com/mailman/listinfo/xmlsec
>     >
> 
> 
> 
> 
> -- 
> Thanks and Regards,
> Isuru
> 

From aleksey at aleksey.com  Fri Aug 24 08:44:43 2012
From: aleksey at aleksey.com (Aleksey Sanin)
Date: Fri, 24 Aug 2012 08:44:43 -0700
Subject: [xmlsec] Help needed and thank you
In-Reply-To: <50369d0b.834aec0a.1eaa.ffffc5fb@mx.google.com>
References: <50369d0b.834aec0a.1eaa.ffffc5fb@mx.google.com>
Message-ID: <5037A16B.4010001@aleksey.com>

Hi Walter,

The xmlsec library implements a pretty complex XMLDSig and XMLEnc
W3C specifications. I would suggest you start from reading these
specs.

Best,

Aleksey

On 8/23/12 2:13 PM, Cr. Walter Neri wrote:
> Aleksey
> 
>  
> 
> Before installing the Library, I am trying to verify an xml signed
> document using your online verifier
> http://www.aleksey.com/xmlsec/xmldsig-verifier.html
> 
>  
> 
> The thing is that I am new in this thing and  I need help to know for
> the following examples what is the signed portion to paste on the verifier.
> 
>  
> 
> http://autosuruguay.com/efactura/php/cae1F.xml
> 
> http://www.autosuruguay.com/efactura/php/DGI_sobre_efactura_firmado.xml
> 
>  
> 
> Vielen dank und herzliche gruesse von Uruguay !!
> 
>  
> 
> Walter Neri
> 
>  
> 
>  
> 

From opensc at secure-edge.com  Thu Sep  6 00:25:36 2012
From: opensc at secure-edge.com (Umberto Rustichelli aka Ubi)
Date: Thu, 06 Sep 2012 09:25:36 +0200
Subject: [xmlsec] How to reference KeyInfo and add SignedProperties?
Message-ID: <50484FF0.9060809@secure-edge.com>


Hi all,
I'm new to XMLSEC -and just giving up writing my own library (got lost 
in the canonicalization labyrinth)...-

Is it possible to use the current XMLSEC API for producing XML 
signatures that comply with the ETSI specifications and the following:

1) have a Reference (in SignedInfo) to KeyInfo (KeyInfo obviously needs 
an Id="...");

2) add the Object for QualifyingProperties (example later) and a 
Reference to that too?

Thanks a lot for any suggestion / explanation!

This is an example of the aforementioned Object (target value is the Id 
of the Signature):

     <ds:Object>
       <xades:QualifyingProperties 
xmlns:xades="http://uri.etsi.org/01903/v1.3.2#" Target="#sig">
         <xades:SignedProperties Id="sprop">
           <xades:SignedSignatureProperties>
<xades:SigningTime>2012-08-23T10:11:24+02:00</xades:SigningTime>
           </xades:SignedSignatureProperties>
         </xades:SignedProperties>
       </xades:QualifyingProperties>
     </ds:Object>

And this is how the whole should glue together:

<Envelope>
   <ds:Object xmlns:ds="http://www.w3.org/2000/09/xmldsig#" 
Encoding="UTF-8" Id="orig" MimeType="text/xml">blah blah blah...</ds:Object>
   <ds:Signature xmlns:ds="http://www.w3.org/2000/09/xmldsig#" Id="sig">
     <ds:SignedInfo>

<!-- the Reference to the object, must be expressed this way... -->
       <ds:CanonicalizationMethod 
Algorithm="http://www.w3.org/2006/12/xml-c14n11#WithComments"></ds:CanonicalizationMethod>
       <ds:SignatureMethod 
Algorithm="http://www.w3.org/2001/04/xmldsig-more#rsa-sha256"></ds:SignatureMethod>
       <ds:Reference Type="http://uri.etsi.org/01903#SignedProperties" 
URI="#SignedProperties-Signer-T-1345709484789">
         <ds:DigestMethod 
Algorithm="http://www.w3.org/2001/04/xmlenc#sha256"></ds:DigestMethod>
<ds:DigestValue>dRkQKf/Kqv/V8SZej/41+T6z4+4Pxus8wyPAFUaJM5E=</ds:DigestValue>
       </ds:Reference>

       <ds:Reference URI="#orig">blah blah blah...</ds:Reference>
       <ds:Reference URI="#crt">blah blah blah...</ds:Reference>

     </ds:SignedInfo>

     <ds:SignatureValue>blah blah blah...</ds:SignatureValue>

     <ds:KeyInfo Id="crt"><ds:X509Data><ds:X509Certificate>blah blah 
blah...</ds:X509Certificate></ds:X509Data></ds:KeyInfo>

     <ds:Object>(...as indicated above...)</ds:Object>

   </ds:Signature>
</Envelope>



From opensc at secure-edge.com  Thu Sep  6 00:28:45 2012
From: opensc at secure-edge.com (Umberto Rustichelli aka Ubi)
Date: Thu, 06 Sep 2012 09:28:45 +0200
Subject: [xmlsec] How to reference KeyInfo and add SignedProperties?
In-Reply-To: <50484FF0.9060809@secure-edge.com>
References: <50484FF0.9060809@secure-edge.com>
Message-ID: <504850AD.7050206@secure-edge.com>


Ah! I forgot to fix...

The Reference URI is not URI="#SignedProperties-Signer-T-1345709484789"
but URI="#sprop"


On 09/06/2012 09:25 AM, Umberto Rustichelli aka Ubi wrote:
>
> Hi all,
> I'm new to XMLSEC -and just giving up writing my own library (got lost 
> in the canonicalization labyrinth)...-
>
> Is it possible to use the current XMLSEC API for producing XML 
> signatures that comply with the ETSI specifications and the following:
>
> 1) have a Reference (in SignedInfo) to KeyInfo (KeyInfo obviously 
> needs an Id="...");
>
> 2) add the Object for QualifyingProperties (example later) and a 
> Reference to that too?
>
> Thanks a lot for any suggestion / explanation!
>
> This is an example of the aforementioned Object (target value is the 
> Id of the Signature):
>
>     <ds:Object>
>       <xades:QualifyingProperties 
> xmlns:xades="http://uri.etsi.org/01903/v1.3.2#" Target="#sig">
>         <xades:SignedProperties Id="sprop">
>           <xades:SignedSignatureProperties>
> <xades:SigningTime>2012-08-23T10:11:24+02:00</xades:SigningTime>
>           </xades:SignedSignatureProperties>
>         </xades:SignedProperties>
>       </xades:QualifyingProperties>
>     </ds:Object>
>
> And this is how the whole should glue together:
>
> <Envelope>
>   <ds:Object xmlns:ds="http://www.w3.org/2000/09/xmldsig#" 
> Encoding="UTF-8" Id="orig" MimeType="text/xml">blah blah 
> blah...</ds:Object>
>   <ds:Signature xmlns:ds="http://www.w3.org/2000/09/xmldsig#" Id="sig">
>     <ds:SignedInfo>
>
> <!-- the Reference to the object, must be expressed this way... -->
>       <ds:CanonicalizationMethod 
> Algorithm="http://www.w3.org/2006/12/xml-c14n11#WithComments"></ds:CanonicalizationMethod>
>       <ds:SignatureMethod 
> Algorithm="http://www.w3.org/2001/04/xmldsig-more#rsa-sha256"></ds:SignatureMethod>
>       <ds:Reference Type="http://uri.etsi.org/01903#SignedProperties" 
> URI="#SignedProperties-Signer-T-1345709484789">
>         <ds:DigestMethod 
> Algorithm="http://www.w3.org/2001/04/xmlenc#sha256"></ds:DigestMethod>
> <ds:DigestValue>dRkQKf/Kqv/V8SZej/41+T6z4+4Pxus8wyPAFUaJM5E=</ds:DigestValue> 
>
>       </ds:Reference>
>
>       <ds:Reference URI="#orig">blah blah blah...</ds:Reference>
>       <ds:Reference URI="#crt">blah blah blah...</ds:Reference>
>
>     </ds:SignedInfo>
>
>     <ds:SignatureValue>blah blah blah...</ds:SignatureValue>
>
>     <ds:KeyInfo Id="crt"><ds:X509Data><ds:X509Certificate>blah blah 
> blah...</ds:X509Certificate></ds:X509Data></ds:KeyInfo>
>
>     <ds:Object>(...as indicated above...)</ds:Object>
>
>   </ds:Signature>
> </Envelope>
>
>
> _______________________________________________
> xmlsec mailing list
> xmlsec at aleksey.com
> http://www.aleksey.com/mailman/listinfo/xmlsec
>


From aleksey at aleksey.com  Thu Sep  6 08:34:13 2012
From: aleksey at aleksey.com (Aleksey Sanin)
Date: Thu, 06 Sep 2012 08:34:13 -0700
Subject: [xmlsec] How to reference KeyInfo and add SignedProperties?
In-Reply-To: <504850AD.7050206@secure-edge.com>
References: <50484FF0.9060809@secure-edge.com>
 <504850AD.7050206@secure-edge.com>
Message-ID: <5048C275.8000609@aleksey.com>

Yes, you just need to construct the right template to sign :) There was
a discussion a few years ago:

http://www.aleksey.com/pipermail/xmlsec/2008/008269.html

Aleksey

On 9/6/12 12:28 AM, Umberto Rustichelli aka Ubi wrote:
> 
> Ah! I forgot to fix...
> 
> The Reference URI is not URI="#SignedProperties-Signer-T-1345709484789"
> but URI="#sprop"
> 
> 
> On 09/06/2012 09:25 AM, Umberto Rustichelli aka Ubi wrote:
>>
>> Hi all,
>> I'm new to XMLSEC -and just giving up writing my own library (got lost
>> in the canonicalization labyrinth)...-
>>
>> Is it possible to use the current XMLSEC API for producing XML
>> signatures that comply with the ETSI specifications and the following:
>>
>> 1) have a Reference (in SignedInfo) to KeyInfo (KeyInfo obviously
>> needs an Id="...");
>>
>> 2) add the Object for QualifyingProperties (example later) and a
>> Reference to that too?
>>
>> Thanks a lot for any suggestion / explanation!
>>
>> This is an example of the aforementioned Object (target value is the
>> Id of the Signature):
>>
>>     <ds:Object>
>>       <xades:QualifyingProperties
>> xmlns:xades="http://uri.etsi.org/01903/v1.3.2#" Target="#sig">
>>         <xades:SignedProperties Id="sprop">
>>           <xades:SignedSignatureProperties>
>> <xades:SigningTime>2012-08-23T10:11:24+02:00</xades:SigningTime>
>>           </xades:SignedSignatureProperties>
>>         </xades:SignedProperties>
>>       </xades:QualifyingProperties>
>>     </ds:Object>
>>
>> And this is how the whole should glue together:
>>
>> <Envelope>
>>   <ds:Object xmlns:ds="http://www.w3.org/2000/09/xmldsig#"
>> Encoding="UTF-8" Id="orig" MimeType="text/xml">blah blah
>> blah...</ds:Object>
>>   <ds:Signature xmlns:ds="http://www.w3.org/2000/09/xmldsig#" Id="sig">
>>     <ds:SignedInfo>
>>
>> <!-- the Reference to the object, must be expressed this way... -->
>>       <ds:CanonicalizationMethod
>> Algorithm="http://www.w3.org/2006/12/xml-c14n11#WithComments"></ds:CanonicalizationMethod>
>>
>>       <ds:SignatureMethod
>> Algorithm="http://www.w3.org/2001/04/xmldsig-more#rsa-sha256"></ds:SignatureMethod>
>>
>>       <ds:Reference Type="http://uri.etsi.org/01903#SignedProperties"
>> URI="#SignedProperties-Signer-T-1345709484789">
>>         <ds:DigestMethod
>> Algorithm="http://www.w3.org/2001/04/xmlenc#sha256"></ds:DigestMethod>
>> <ds:DigestValue>dRkQKf/Kqv/V8SZej/41+T6z4+4Pxus8wyPAFUaJM5E=</ds:DigestValue>
>>
>>       </ds:Reference>
>>
>>       <ds:Reference URI="#orig">blah blah blah...</ds:Reference>
>>       <ds:Reference URI="#crt">blah blah blah...</ds:Reference>
>>
>>     </ds:SignedInfo>
>>
>>     <ds:SignatureValue>blah blah blah...</ds:SignatureValue>
>>
>>     <ds:KeyInfo Id="crt"><ds:X509Data><ds:X509Certificate>blah blah
>> blah...</ds:X509Certificate></ds:X509Data></ds:KeyInfo>
>>
>>     <ds:Object>(...as indicated above...)</ds:Object>
>>
>>   </ds:Signature>
>> </Envelope>
>>
>>
>> _______________________________________________
>> xmlsec mailing list
>> xmlsec at aleksey.com
>> http://www.aleksey.com/mailman/listinfo/xmlsec
>>
> 
> _______________________________________________
> xmlsec mailing list
> xmlsec at aleksey.com
> http://www.aleksey.com/mailman/listinfo/xmlsec

From mpeat at unicorninterglobal.com  Fri Sep 14 07:50:09 2012
From: mpeat at unicorninterglobal.com (Mike Peat)
Date: Fri, 14 Sep 2012 15:50:09 +0100
Subject: [xmlsec] Signing over multiple files
Message-ID: <50534421.3070603@unicorninterglobal.com>

Hi

I am using xmlsec at the command line in an ebXML application.  As you 
probably know, ebXML uses SOAP-with-attachments (over HTTP) to send its 
messages.  The message thus consists of multipart-MIME content in the 
HTTP body: the first part being a SOAP document containing (among other 
things) the Signature stuff and the second being an XML document which 
is the business payload.

The Signature->SignedInfo in the SOAP document needs to contain two 
<Reference> elements: one for the SOAP document itself (URI="") and one 
for the payload XML (URI="cid:xxxxxxxx", where "xxxxxxxx" is the content 
ID of the second MIME part).

I am managing to successfully sign simple SOAP messages with no payload 
(and hence no second <Reference> element), but I just can't work out how 
to get xmlsec to sign both documents together.  I have tried many 
different ways, but to no avail.  I am sure I am missing something 
simple, but...  :-(

Any help would be very much appreciated - I've been banging my head off 
this brick wall for a week... and it is starting to really hurt!  :-(  
(That takes a while, because my brain is so dense, but even it starts 
gets sore eventually!)

TIA

Mike Peat 

From aleksey at aleksey.com  Fri Sep 14 08:57:35 2012
From: aleksey at aleksey.com (Aleksey Sanin)
Date: Fri, 14 Sep 2012 08:57:35 -0700
Subject: [xmlsec] Signing over multiple files
In-Reply-To: <50534421.3070603@unicorninterglobal.com>
References: <50534421.3070603@unicorninterglobal.com>
Message-ID: <505353EF.1080503@aleksey.com>

Mike,

You will probably need to write code to support "cid" URL scheme
and resolve references correctly to the MIME attachments:

http://www.aleksey.com/xmlsec/api/xmlsec-io.html

Aleksey

On 9/14/12 7:50 AM, Mike Peat wrote:
> Hi
> 
> I am using xmlsec at the command line in an ebXML application.  As you
> probably know, ebXML uses SOAP-with-attachments (over HTTP) to send its
> messages.  The message thus consists of multipart-MIME content in the
> HTTP body: the first part being a SOAP document containing (among other
> things) the Signature stuff and the second being an XML document which
> is the business payload.
> 
> The Signature->SignedInfo in the SOAP document needs to contain two
> <Reference> elements: one for the SOAP document itself (URI="") and one
> for the payload XML (URI="cid:xxxxxxxx", where "xxxxxxxx" is the content
> ID of the second MIME part).
> 
> I am managing to successfully sign simple SOAP messages with no payload
> (and hence no second <Reference> element), but I just can't work out how
> to get xmlsec to sign both documents together.  I have tried many
> different ways, but to no avail.  I am sure I am missing something
> simple, but...  :-(
> 
> Any help would be very much appreciated - I've been banging my head off
> this brick wall for a week... and it is starting to really hurt!  :-( 
> (That takes a while, because my brain is so dense, but even it starts
> gets sore eventually!)
> 
> TIA
> 
> Mike Peat _______________________________________________
> xmlsec mailing list
> xmlsec at aleksey.com
> http://www.aleksey.com/mailman/listinfo/xmlsec

From opensc at secure-edge.com  Wed Sep 19 03:43:44 2012
From: opensc at secure-edge.com (Umberto Rustichelli aka Ubi)
Date: Wed, 19 Sep 2012 12:43:44 +0200
Subject: [xmlsec] How to reference KeyInfo and add SignedProperties?
In-Reply-To: <5048C275.8000609@aleksey.com>
References: <50484FF0.9060809@secure-edge.com>
 <504850AD.7050206@secure-edge.com> <5048C275.8000609@aleksey.com>
Message-ID: <5059A1E0.2010509@secure-edge.com>

On 09/06/2012 05:34 PM, Aleksey Sanin wrote:
> Yes, you just need to construct the right template to sign :)

Sorry, Sanin, yet the discussion you pointed to was a bit unhelpful.
Now, I'm trying to write my code based on example 2 but there is 
something for sure that I'm missing, probably because I quite don't know 
much about XML.
Just for starting, I intended to skip the use of SignedProperties and 
SHA256, I wrote this trivial content (well, two, but they both failed):

---
<?xml version="1.0" encoding="UTF-8" ?>
<Envelope xmlns="urn:envelope"><Data Id="orig">my stuff</Data></Envelope>
---
(also tried this one)
<?xml version="1.0" encoding="UTF-8" ?>
<Envelope xmlns="urn:envelope">
   <ds:Object xmlns:ds="http://www.w3.org/2000/09/xmldsig#" 
Encoding="UTF-8" Id="orig" MimeType="text/xml"><test>my 
stuff</test></ds:Object>
</Envelope>
---

and used the following code:

doc = xmlParseFile(xml_file);

// create signature template for RSA-SHA1 enveloped signature
signNode = xmlSecTmplSignatureCreate(doc, xmlSecTransformExclC14NId, 
xmlSecTransformRsaSha1Id, NULL);

// add <dsig:Signature/> node to the doc
xmlAddChild(xmlDocGetRootElement(doc), signNode);

// add reference -Ubi: to what??? Let's say our node has Id 'orig'
refNode = xmlSecTmplSignatureAddReference(signNode, 
xmlSecTransformSha1Id, NULL, "#orig", NULL);

// add enveloped transform
xmlSecTmplReferenceAddTransform(refNode, xmlSecTransformEnvelopedId);

// add <dsig:KeyInfo/> -Ubi, we also want an ID
keyInfoNode = xmlSecTmplSignatureEnsureKeyInfo(signNode, "UbiKey");

// add reference to the key
refNode = xmlSecTmplSignatureAddReference(signNode, 
xmlSecTransformSha1Id, NULL, "#UbiKey", NULL);

// Ubi: can I do this? Put PEM-format certificate here
xmlNodeSetContent(x509DataCrtNode, crtpem);

// create signature context
dsigCtx = xmlSecDSigCtxCreate(NULL);

// load private key, assuming that there is not password
dsigCtx->signKey = xmlSecCryptoAppKeyLoad(key_file, 
xmlSecKeyDataFormatPem, NULL, NULL, NULL);

// Ubi: is this required? Set key name to the file name, this is just an 
example!
xmlSecKeySetName(dsigCtx->signKey, "UbiKey");

// sign the template
if (xmlSecDSigCtxSign(dsigCtx, signNode) < 0)
     { fprintf(stderr,"Error: signature failed\n"); goto done; }

I omitted the checks but they are in the code and there is no error 
reported (before "sign the template").
I thought that the idea of the tamplate was to put the Reference URIs so 
that the API will look for the related objects.

But running, I get (seems that passing the Id in the URI is not what I 
muast do):

func=xmlSecXPathDataExecute:file=xpath.c:line=273:obj=unknown:subj=xmlXPtrEval:error=5:libxml2 
library function failed:expr=xpointer(id('orig'))
func=xmlSecXPathDataListExecute:file=xpath.c:line=356:obj=unknown:subj=xmlSecXPathDataExecute:error=1:xmlsec 
library function failed:
func=xmlSecTransformXPathExecute:file=xpath.c:line=466:obj=xpointer:subj=xmlSecXPathDataExecute:error=1:xmlsec 
library function failed:
func=xmlSecTransformDefaultPushXml:file=transforms.c:line=2405:obj=xpointer:subj=xmlSecTransformExecute:error=1:xmlsec 
library function failed:
func=xmlSecTransformCtxXmlExecute:file=transforms.c:line=1236:obj=unknown:subj=xmlSecTransformPushXml:error=1:xmlsec 
library function failed:transform=xpointer
func=xmlSecTransformCtxExecute:file=transforms.c:line=1296:obj=unknown:subj=xmlSecTransformCtxXmlExecute:error=1:xmlsec 
library function failed:
func=xmlSecDSigReferenceCtxProcessNode:file=xmldsig.c:line=1571:obj=unknown:subj=xmlSecTransformCtxExecute:error=1:xmlsec 
library function failed:
func=xmlSecDSigCtxProcessSignedInfoNode:file=xmldsig.c:line=804:obj=unknown:subj=xmlSecDSigReferenceCtxProcessNode:error=1:xmlsec 
library function failed:node=Reference
func=xmlSecDSigCtxProcessSignatureNode:file=xmldsig.c:line=547:obj=unknown:subj=xmlSecDSigCtxProcessSignedInfoNode:error=1:xmlsec 
library function failed:
func=xmlSecDSigCtxSign:file=xmldsig.c:line=303:obj=unknown:subj=xmlSecDSigCtxSigantureProcessNode:error=1:xmlsec 
library function failed:
Error: signature failed

What is the issue?
Also, I seem to remember there is a function in libxml to set which is 
the ID attribute, because it may not be "Id", but I cannot find it any 
more. Has it anything to do with this?
Where am I wrong?

On 9/6/12 12:28 AM, Umberto Rustichelli aka Ubi wrote:
>> Ah! I forgot to fix...
>>
>> The Reference URI is not URI="#SignedProperties-Signer-T-1345709484789"
>> but URI="#sprop"
>>
>>
>> On 09/06/2012 09:25 AM, Umberto Rustichelli aka Ubi wrote:
>>> Hi all,
>>> I'm new to XMLSEC -and just giving up writing my own library (got lost
>>> in the canonicalization labyrinth)...-
>>>
>>> Is it possible to use the current XMLSEC API for producing XML
>>> signatures that comply with the ETSI specifications and the following:
>>>
>>> 1) have a Reference (in SignedInfo) to KeyInfo (KeyInfo obviously
>>> needs an Id="...");
>>>
>>> 2) add the Object for QualifyingProperties (example later) and a
>>> Reference to that too?
>>>
>>> Thanks a lot for any suggestion / explanation!
>>>
>>> This is an example of the aforementioned Object (target value is the
>>> Id of the Signature):
>>>
>>>      <ds:Object>
>>>        <xades:QualifyingProperties
>>> xmlns:xades="http://uri.etsi.org/01903/v1.3.2#" Target="#sig">
>>>          <xades:SignedProperties Id="sprop">
>>>            <xades:SignedSignatureProperties>
>>> <xades:SigningTime>2012-08-23T10:11:24+02:00</xades:SigningTime>
>>>            </xades:SignedSignatureProperties>
>>>          </xades:SignedProperties>
>>>        </xades:QualifyingProperties>
>>>      </ds:Object>
>>>
>>> And this is how the whole should glue together:
>>>
>>> <Envelope>
>>>    <ds:Object xmlns:ds="http://www.w3.org/2000/09/xmldsig#"
>>> Encoding="UTF-8" Id="orig" MimeType="text/xml">blah blah
>>> blah...</ds:Object>
>>>    <ds:Signature xmlns:ds="http://www.w3.org/2000/09/xmldsig#" Id="sig">
>>>      <ds:SignedInfo>
>>>
>>> <!-- the Reference to the object, must be expressed this way... -->
>>>        <ds:CanonicalizationMethod
>>> Algorithm="http://www.w3.org/2006/12/xml-c14n11#WithComments"></ds:CanonicalizationMethod>
>>>
>>>        <ds:SignatureMethod
>>> Algorithm="http://www.w3.org/2001/04/xmldsig-more#rsa-sha256"></ds:SignatureMethod>
>>>
>>>        <ds:Reference Type="http://uri.etsi.org/01903#SignedProperties"
>>> URI="#SignedProperties-Signer-T-1345709484789">
>>>          <ds:DigestMethod
>>> Algorithm="http://www.w3.org/2001/04/xmlenc#sha256"></ds:DigestMethod>
>>> <ds:DigestValue>dRkQKf/Kqv/V8SZej/41+T6z4+4Pxus8wyPAFUaJM5E=</ds:DigestValue>
>>>
>>>        </ds:Reference>
>>>
>>>        <ds:Reference URI="#orig">blah blah blah...</ds:Reference>
>>>        <ds:Reference URI="#crt">blah blah blah...</ds:Reference>
>>>
>>>      </ds:SignedInfo>
>>>
>>>      <ds:SignatureValue>blah blah blah...</ds:SignatureValue>
>>>
>>>      <ds:KeyInfo Id="crt"><ds:X509Data><ds:X509Certificate>blah blah
>>> blah...</ds:X509Certificate></ds:X509Data></ds:KeyInfo>
>>>
>>>      <ds:Object>(...as indicated above...)</ds:Object>
>>>
>>>    </ds:Signature>
>>> </Envelope>
>>>
>>>
>>> _______________________________________________
>>> xmlsec mailing list
>>> xmlsec at aleksey.com
>>> http://www.aleksey.com/mailman/listinfo/xmlsec
>>>
>> _______________________________________________
>> xmlsec mailing list
>> xmlsec at aleksey.com
>> http://www.aleksey.com/mailman/listinfo/xmlsec


From aleksey at aleksey.com  Wed Sep 19 08:27:47 2012
From: aleksey at aleksey.com (Aleksey Sanin)
Date: Wed, 19 Sep 2012 08:27:47 -0700
Subject: [xmlsec] How to reference KeyInfo and add SignedProperties?
In-Reply-To: <5059A1E0.2010509@secure-edge.com>
References: <50484FF0.9060809@secure-edge.com>
 <504850AD.7050206@secure-edge.com> <5048C275.8000609@aleksey.com>
 <5059A1E0.2010509@secure-edge.com>
Message-ID: <5059E473.3050805@aleksey.com>

Read the FAQ :)

http://www.aleksey.com/xmlsec/faq.html

Aleksey

On 9/19/12 3:43 AM, Umberto Rustichelli aka Ubi wrote:
> On 09/06/2012 05:34 PM, Aleksey Sanin wrote:
>> Yes, you just need to construct the right template to sign :)
> 
> Sorry, Sanin, yet the discussion you pointed to was a bit unhelpful.
> Now, I'm trying to write my code based on example 2 but there is
> something for sure that I'm missing, probably because I quite don't know
> much about XML.
> Just for starting, I intended to skip the use of SignedProperties and
> SHA256, I wrote this trivial content (well, two, but they both failed):
> 
> ---
> <?xml version="1.0" encoding="UTF-8" ?>
> <Envelope xmlns="urn:envelope"><Data Id="orig">my stuff</Data></Envelope>
> ---
> (also tried this one)
> <?xml version="1.0" encoding="UTF-8" ?>
> <Envelope xmlns="urn:envelope">
>   <ds:Object xmlns:ds="http://www.w3.org/2000/09/xmldsig#"
> Encoding="UTF-8" Id="orig" MimeType="text/xml"><test>my
> stuff</test></ds:Object>
> </Envelope>
> ---
> 
> and used the following code:
> 
> doc = xmlParseFile(xml_file);
> 
> // create signature template for RSA-SHA1 enveloped signature
> signNode = xmlSecTmplSignatureCreate(doc, xmlSecTransformExclC14NId,
> xmlSecTransformRsaSha1Id, NULL);
> 
> // add <dsig:Signature/> node to the doc
> xmlAddChild(xmlDocGetRootElement(doc), signNode);
> 
> // add reference -Ubi: to what??? Let's say our node has Id 'orig'
> refNode = xmlSecTmplSignatureAddReference(signNode,
> xmlSecTransformSha1Id, NULL, "#orig", NULL);
> 
> // add enveloped transform
> xmlSecTmplReferenceAddTransform(refNode, xmlSecTransformEnvelopedId);
> 
> // add <dsig:KeyInfo/> -Ubi, we also want an ID
> keyInfoNode = xmlSecTmplSignatureEnsureKeyInfo(signNode, "UbiKey");
> 
> // add reference to the key
> refNode = xmlSecTmplSignatureAddReference(signNode,
> xmlSecTransformSha1Id, NULL, "#UbiKey", NULL);
> 
> // Ubi: can I do this? Put PEM-format certificate here
> xmlNodeSetContent(x509DataCrtNode, crtpem);
> 
> // create signature context
> dsigCtx = xmlSecDSigCtxCreate(NULL);
> 
> // load private key, assuming that there is not password
> dsigCtx->signKey = xmlSecCryptoAppKeyLoad(key_file,
> xmlSecKeyDataFormatPem, NULL, NULL, NULL);
> 
> // Ubi: is this required? Set key name to the file name, this is just an
> example!
> xmlSecKeySetName(dsigCtx->signKey, "UbiKey");
> 
> // sign the template
> if (xmlSecDSigCtxSign(dsigCtx, signNode) < 0)
>     { fprintf(stderr,"Error: signature failed\n"); goto done; }
> 
> I omitted the checks but they are in the code and there is no error
> reported (before "sign the template").
> I thought that the idea of the tamplate was to put the Reference URIs so
> that the API will look for the related objects.
> 
> But running, I get (seems that passing the Id in the URI is not what I
> muast do):
> 
> func=xmlSecXPathDataExecute:file=xpath.c:line=273:obj=unknown:subj=xmlXPtrEval:error=5:libxml2
> library function failed:expr=xpointer(id('orig'))
> func=xmlSecXPathDataListExecute:file=xpath.c:line=356:obj=unknown:subj=xmlSecXPathDataExecute:error=1:xmlsec
> library function failed:
> func=xmlSecTransformXPathExecute:file=xpath.c:line=466:obj=xpointer:subj=xmlSecXPathDataExecute:error=1:xmlsec
> library function failed:
> func=xmlSecTransformDefaultPushXml:file=transforms.c:line=2405:obj=xpointer:subj=xmlSecTransformExecute:error=1:xmlsec
> library function failed:
> func=xmlSecTransformCtxXmlExecute:file=transforms.c:line=1236:obj=unknown:subj=xmlSecTransformPushXml:error=1:xmlsec
> library function failed:transform=xpointer
> func=xmlSecTransformCtxExecute:file=transforms.c:line=1296:obj=unknown:subj=xmlSecTransformCtxXmlExecute:error=1:xmlsec
> library function failed:
> func=xmlSecDSigReferenceCtxProcessNode:file=xmldsig.c:line=1571:obj=unknown:subj=xmlSecTransformCtxExecute:error=1:xmlsec
> library function failed:
> func=xmlSecDSigCtxProcessSignedInfoNode:file=xmldsig.c:line=804:obj=unknown:subj=xmlSecDSigReferenceCtxProcessNode:error=1:xmlsec
> library function failed:node=Reference
> func=xmlSecDSigCtxProcessSignatureNode:file=xmldsig.c:line=547:obj=unknown:subj=xmlSecDSigCtxProcessSignedInfoNode:error=1:xmlsec
> library function failed:
> func=xmlSecDSigCtxSign:file=xmldsig.c:line=303:obj=unknown:subj=xmlSecDSigCtxSigantureProcessNode:error=1:xmlsec
> library function failed:
> Error: signature failed
> 
> What is the issue?
> Also, I seem to remember there is a function in libxml to set which is
> the ID attribute, because it may not be "Id", but I cannot find it any
> more. Has it anything to do with this?
> Where am I wrong?
> 
> On 9/6/12 12:28 AM, Umberto Rustichelli aka Ubi wrote:
>>> Ah! I forgot to fix...
>>>
>>> The Reference URI is not URI="#SignedProperties-Signer-T-1345709484789"
>>> but URI="#sprop"
>>>
>>>
>>> On 09/06/2012 09:25 AM, Umberto Rustichelli aka Ubi wrote:
>>>> Hi all,
>>>> I'm new to XMLSEC -and just giving up writing my own library (got lost
>>>> in the canonicalization labyrinth)...-
>>>>
>>>> Is it possible to use the current XMLSEC API for producing XML
>>>> signatures that comply with the ETSI specifications and the following:
>>>>
>>>> 1) have a Reference (in SignedInfo) to KeyInfo (KeyInfo obviously
>>>> needs an Id="...");
>>>>
>>>> 2) add the Object for QualifyingProperties (example later) and a
>>>> Reference to that too?
>>>>
>>>> Thanks a lot for any suggestion / explanation!
>>>>
>>>> This is an example of the aforementioned Object (target value is the
>>>> Id of the Signature):
>>>>
>>>>      <ds:Object>
>>>>        <xades:QualifyingProperties
>>>> xmlns:xades="http://uri.etsi.org/01903/v1.3.2#" Target="#sig">
>>>>          <xades:SignedProperties Id="sprop">
>>>>            <xades:SignedSignatureProperties>
>>>> <xades:SigningTime>2012-08-23T10:11:24+02:00</xades:SigningTime>
>>>>            </xades:SignedSignatureProperties>
>>>>          </xades:SignedProperties>
>>>>        </xades:QualifyingProperties>
>>>>      </ds:Object>
>>>>
>>>> And this is how the whole should glue together:
>>>>
>>>> <Envelope>
>>>>    <ds:Object xmlns:ds="http://www.w3.org/2000/09/xmldsig#"
>>>> Encoding="UTF-8" Id="orig" MimeType="text/xml">blah blah
>>>> blah...</ds:Object>
>>>>    <ds:Signature xmlns:ds="http://www.w3.org/2000/09/xmldsig#"
>>>> Id="sig">
>>>>      <ds:SignedInfo>
>>>>
>>>> <!-- the Reference to the object, must be expressed this way... -->
>>>>        <ds:CanonicalizationMethod
>>>> Algorithm="http://www.w3.org/2006/12/xml-c14n11#WithComments"></ds:CanonicalizationMethod>
>>>>
>>>>
>>>>        <ds:SignatureMethod
>>>> Algorithm="http://www.w3.org/2001/04/xmldsig-more#rsa-sha256"></ds:SignatureMethod>
>>>>
>>>>
>>>>        <ds:Reference Type="http://uri.etsi.org/01903#SignedProperties"
>>>> URI="#SignedProperties-Signer-T-1345709484789">
>>>>          <ds:DigestMethod
>>>> Algorithm="http://www.w3.org/2001/04/xmlenc#sha256"></ds:DigestMethod>
>>>> <ds:DigestValue>dRkQKf/Kqv/V8SZej/41+T6z4+4Pxus8wyPAFUaJM5E=</ds:DigestValue>
>>>>
>>>>
>>>>        </ds:Reference>
>>>>
>>>>        <ds:Reference URI="#orig">blah blah blah...</ds:Reference>
>>>>        <ds:Reference URI="#crt">blah blah blah...</ds:Reference>
>>>>
>>>>      </ds:SignedInfo>
>>>>
>>>>      <ds:SignatureValue>blah blah blah...</ds:SignatureValue>
>>>>
>>>>      <ds:KeyInfo Id="crt"><ds:X509Data><ds:X509Certificate>blah blah
>>>> blah...</ds:X509Certificate></ds:X509Data></ds:KeyInfo>
>>>>
>>>>      <ds:Object>(...as indicated above...)</ds:Object>
>>>>
>>>>    </ds:Signature>
>>>> </Envelope>
>>>>
>>>>
>>>> _______________________________________________
>>>> xmlsec mailing list
>>>> xmlsec at aleksey.com
>>>> http://www.aleksey.com/mailman/listinfo/xmlsec
>>>>
>>> _______________________________________________
>>> xmlsec mailing list
>>> xmlsec at aleksey.com
>>> http://www.aleksey.com/mailman/listinfo/xmlsec
> 
> _______________________________________________
> xmlsec mailing list
> xmlsec at aleksey.com
> http://www.aleksey.com/mailman/listinfo/xmlsec

From mpeat at unicorninterglobal.com  Thu Sep 20 06:53:20 2012
From: mpeat at unicorninterglobal.com (Mike Peat)
Date: Thu, 20 Sep 2012 14:53:20 +0100
Subject: [xmlsec] Signing over multiple files
In-Reply-To: <505353EF.1080503@aleksey.com>
References: <50534421.3070603@unicorninterglobal.com>
 <505353EF.1080503@aleksey.com>
Message-ID: <505B1FD0.6080804@unicorninterglobal.com>

Thanks for that Aleksey

Initially I thought I had found a work-around, but I am now back looking 
at the problem from square one again.  Let me explain...

Another customer of the organisation I am communicating with was using 
xmlsec at the command-line to do this, which is what led me down this 
route initially.

It turns out that if the document (file) referred to in the <Reference> 
URI attribute is in the _same directory_ as the SOAP document being 
signed, xmlsec actually picks it up OK and includes its hash-value in 
the <Reference> -> <DigestValue> element... problem solved! 
(Apparently...) However, life is not so simple.

They are working on a Linux system, while I am cursed with being in 
Windows.  :-(

They are thus able to have files named "cid:/xxxxxxx/", while I am not 
(no colons allowed in file-names in Windows!).  So I changed the URI 
attribute in my Reference element to just contain a file-name with no 
"cid:" prefix, and that got things working as far as digitally signing 
the whole thing with xmlsec was concerned.  However now I am getting 
messages through to the other party's back-end system, which are being 
rejected because now _it_ can't identify the referred to document: it 
seems that it insists on using that "cid:" scheme.

So...

I need to persuade xmlsec to recognise that "cid:" prefix and, in 
effect, ignore it (if the referred-to file-name starts with "cid:", 
replace that with nothing prior to trying to open the file).

I have got the xmlsec source, but up until now have just been using Igor 
Zlatkovic's Windows binaries.

I need to (a) get xmlsec to compile in a Win32 environment and (b) know 
where to make the changes in xmlsec (or perhaps one of its libraries) in 
order to create a version which will do what I need.

I am not really a C/C++ programmer, but I can usually get by in pretty 
much anything (I have been programming since about 1972 - Oh Lord! 
That's 40 years! I'm getting too old for this!).

What compiler will I need and where do I find the code I will need to 
change?  And what build process do I need to go through?  Is there a 
make file or something similar?

Alternatively... what would it take to get somebody who actually knows 
what (s)he is doing to do this for us? We don't have much in the way of 
budget, but this is stopping a project that has months of work in it 
dead in its tracks right now, so...

TIA

Mike Peat

On 14/09/2012 16:57, Aleksey Sanin wrote:
> Mike,
>
> You will probably need to write code to support "cid" URL scheme
> and resolve references correctly to the MIME attachments:
>
> http://www.aleksey.com/xmlsec/api/xmlsec-io.html
>
> Aleksey
>
> On 9/14/12 7:50 AM, Mike Peat wrote:
>> Hi
>>
>> I am using xmlsec at the command line in an ebXML application.  As you
>> probably know, ebXML uses SOAP-with-attachments (over HTTP) to send its
>> messages.  The message thus consists of multipart-MIME content in the
>> HTTP body: the first part being a SOAP document containing (among other
>> things) the Signature stuff and the second being an XML document which
>> is the business payload.
>>
>> The Signature->SignedInfo in the SOAP document needs to contain two
>> <Reference> elements: one for the SOAP document itself (URI="") and one
>> for the payload XML (URI="cid:xxxxxxxx", where "xxxxxxxx" is the content
>> ID of the second MIME part).
>>
>> I am managing to successfully sign simple SOAP messages with no payload
>> (and hence no second <Reference> element), but I just can't work out how
>> to get xmlsec to sign both documents together.  I have tried many
>> different ways, but to no avail.  I am sure I am missing something
>> simple, but...  :-(
>>
>> Any help would be very much appreciated - I've been banging my head off
>> this brick wall for a week... and it is starting to really hurt!  :-(
>> (That takes a while, because my brain is so dense, but even it starts
>> gets sore eventually!)
>>
>> TIA
>>
>> Mike Peat _______________________________________________
>> xmlsec mailing list
>> xmlsec at aleksey.com
>> http://www.aleksey.com/mailman/listinfo/xmlsec
> .
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.aleksey.com/pipermail/xmlsec/attachments/20120920/1a1d9bca/attachment.html>

From aleksey at aleksey.com  Thu Sep 20 21:02:15 2012
From: aleksey at aleksey.com (Aleksey Sanin)
Date: Thu, 20 Sep 2012 21:02:15 -0700
Subject: [xmlsec] Signing over multiple files
In-Reply-To: <505B1FD0.6080804@unicorninterglobal.com>
References: <50534421.3070603@unicorninterglobal.com>
 <505353EF.1080503@aleksey.com> <505B1FD0.6080804@unicorninterglobal.com>
Message-ID: <505BE6C7.5050806@aleksey.com>

Mike,

You will need to look into win32/ folder and use Microsoft C compiler.
Honestly, I haven't touched Windows for years so it will be hard for
me to give you a better advice.

Another option is of course to use a VM with linux and just run it
through VM.

Aleksey

On 9/20/12 6:53 AM, Mike Peat wrote:
> Thanks for that Aleksey
> 
> Initially I thought I had found a work-around, but I am now back looking
> at the problem from square one again.  Let me explain...
> 
> Another customer of the organisation I am communicating with was using
> xmlsec at the command-line to do this, which is what led me down this
> route initially.
> 
> It turns out that if the document (file) referred to in the <Reference>
> URI attribute is in the _same directory_ as the SOAP document being
> signed, xmlsec actually picks it up OK and includes its hash-value in
> the <Reference> -> <DigestValue> element... problem solved!
> (Apparently...)  However, life is not so simple.
> 
> They are working on a Linux system, while I am cursed with being in
> Windows.  :-(
> 
> They are thus able to have files named "cid:/xxxxxxx/", while I am not
> (no colons allowed in file-names in Windows!).  So I changed the URI
> attribute in my Reference element to just contain a file-name with no
> "cid:" prefix, and that got things working as far as digitally signing
> the whole thing with xmlsec was concerned.  However now I am getting
> messages through to the other party's back-end system, which are being
> rejected because now _it_ can't identify the referred to document: it
> seems that it insists on using that "cid:" scheme.
> 
> So...
> 
> I need to persuade xmlsec to recognise that "cid:" prefix and, in
> effect, ignore it (if the referred-to file-name starts with "cid:",
> replace that with nothing prior to trying to open the file).
> 
> I have got the xmlsec source, but up until now have just been using Igor
> Zlatkovic's Windows binaries.
> 
> I need to (a) get xmlsec to compile in a Win32 environment and (b) know
> where to make the changes in xmlsec (or perhaps one of its libraries) in
> order to create a version which will do what I need.
> 
> I am not really a C/C++ programmer, but I can usually get by in pretty
> much anything (I have been programming since about 1972 - Oh Lord!
> That's 40 years! I'm getting too old for this!).
> 
> What compiler will I need and where do I find the code I will need to
> change?  And what build process do I need to go through?  Is there a
> make file or something similar?
> 
> Alternatively... what would it take to get somebody who actually knows
> what (s)he is doing to do this for us? We don't have much in the way of
> budget, but this is stopping a project that has months of work in it
> dead in its tracks right now, so...
> 
> TIA
> 
> Mike Peat
> 
> On 14/09/2012 16:57, Aleksey Sanin wrote:
>> Mike,
>>
>> You will probably need to write code to support "cid" URL scheme
>> and resolve references correctly to the MIME attachments:
>>
>> http://www.aleksey.com/xmlsec/api/xmlsec-io.html
>>
>> Aleksey
>>
>> On 9/14/12 7:50 AM, Mike Peat wrote:
>>> Hi
>>>
>>> I am using xmlsec at the command line in an ebXML application.  As you
>>> probably know, ebXML uses SOAP-with-attachments (over HTTP) to send its
>>> messages.  The message thus consists of multipart-MIME content in the
>>> HTTP body: the first part being a SOAP document containing (among other
>>> things) the Signature stuff and the second being an XML document which
>>> is the business payload.
>>>
>>> The Signature->SignedInfo in the SOAP document needs to contain two
>>> <Reference> elements: one for the SOAP document itself (URI="") and one
>>> for the payload XML (URI="cid:xxxxxxxx", where "xxxxxxxx" is the content
>>> ID of the second MIME part).
>>>
>>> I am managing to successfully sign simple SOAP messages with no payload
>>> (and hence no second <Reference> element), but I just can't work out how
>>> to get xmlsec to sign both documents together.  I have tried many
>>> different ways, but to no avail.  I am sure I am missing something
>>> simple, but...  :-(
>>>
>>> Any help would be very much appreciated - I've been banging my head off
>>> this brick wall for a week... and it is starting to really hurt!  :-( 
>>> (That takes a while, because my brain is so dense, but even it starts
>>> gets sore eventually!)
>>>
>>> TIA
>>>
>>> Mike Peat _______________________________________________
>>> xmlsec mailing list
>>> xmlsec at aleksey.com
>>> http://www.aleksey.com/mailman/listinfo/xmlsec 
>> .
>>
> 

From aleksey at aleksey.com  Thu Oct  4 07:06:00 2012
From: aleksey at aleksey.com (Aleksey Sanin)
Date: Thu, 04 Oct 2012 07:06:00 -0700
Subject: [xmlsec] Signing over multiple files
In-Reply-To: <506D8462.5080906@unicorninterglobal.com>
References: <50534421.3070603@unicorninterglobal.com>
 <505353EF.1080503@aleksey.com> <505B1FD0.6080804@unicorninterglobal.com>
 <505BE6C7.5050806@aleksey.com> <506D8462.5080906@unicorninterglobal.com>
Message-ID: <506D97C8.7040706@aleksey.com>

Great! Actually I suggest to do it 'the right way' and simply
create 'cid' protocol handlers:

http://www.aleksey.com/xmlsec/api/xmlsec-io.html#XMLSECIOREGISTERCALLBACKS


Aleksey

On 10/4/12 5:43 AM, Mike Peat wrote:
> Aleksey
> 
> Just to let you know that I have (finally!) cracked it and got xmlsec to
> build and run on Windows (and even with an addendum to your copyright
> notice that indicates that it is my own bodged version! <g>).
> 
> Now I just have to work out how to modify it (in
> xmlSecTransformInputURIOpen I think...) to strip off any leading "cid:"
> from the URI.
> 
> Thank you for your help!
> 
> Mike
> 
> On 21/09/2012 05:02, Aleksey Sanin wrote:
>> Mike,
>>
>> You will need to look into win32/ folder and use Microsoft C compiler.
>> Honestly, I haven't touched Windows for years so it will be hard for
>> me to give you a better advice.
>>
>> Another option is of course to use a VM with linux and just run it
>> through VM.
>>
>> Aleksey
>>
>> On 9/20/12 6:53 AM, Mike Peat wrote:
>>> Thanks for that Aleksey
>>>
>>> Initially I thought I had found a work-around, but I am now back looking
>>> at the problem from square one again.  Let me explain...
>>>
>>> Another customer of the organisation I am communicating with was using
>>> xmlsec at the command-line to do this, which is what led me down this
>>> route initially.
>>>
>>> It turns out that if the document (file) referred to in the <Reference>
>>> URI attribute is in the _same directory_ as the SOAP document being
>>> signed, xmlsec actually picks it up OK and includes its hash-value in
>>> the <Reference> -> <DigestValue> element... problem solved!
>>> (Apparently...)  However, life is not so simple.
>>>
>>> They are working on a Linux system, while I am cursed with being in
>>> Windows.  :-(
>>>
>>> They are thus able to have files named "cid:/xxxxxxx/", while I am not
>>> (no colons allowed in file-names in Windows!).  So I changed the URI
>>> attribute in my Reference element to just contain a file-name with no
>>> "cid:" prefix, and that got things working as far as digitally signing
>>> the whole thing with xmlsec was concerned.  However now I am getting
>>> messages through to the other party's back-end system, which are being
>>> rejected because now _it_ can't identify the referred to document: it
>>> seems that it insists on using that "cid:" scheme.
>>>
>>> So...
>>>
>>> I need to persuade xmlsec to recognise that "cid:" prefix and, in
>>> effect, ignore it (if the referred-to file-name starts with "cid:",
>>> replace that with nothing prior to trying to open the file).
>>>
>>> I have got the xmlsec source, but up until now have just been using Igor
>>> Zlatkovic's Windows binaries.
>>>
>>> I need to (a) get xmlsec to compile in a Win32 environment and (b) know
>>> where to make the changes in xmlsec (or perhaps one of its libraries) in
>>> order to create a version which will do what I need.
>>>
>>> I am not really a C/C++ programmer, but I can usually get by in pretty
>>> much anything (I have been programming since about 1972 - Oh Lord!
>>> That's 40 years! I'm getting too old for this!).
>>>
>>> What compiler will I need and where do I find the code I will need to
>>> change?  And what build process do I need to go through?  Is there a
>>> make file or something similar?
>>>
>>> Alternatively... what would it take to get somebody who actually knows
>>> what (s)he is doing to do this for us? We don't have much in the way of
>>> budget, but this is stopping a project that has months of work in it
>>> dead in its tracks right now, so...
>>>
>>> TIA
>>>
>>> Mike Peat
>>>
>>> On 14/09/2012 16:57, Aleksey Sanin wrote:
>>>> Mike,
>>>>
>>>> You will probably need to write code to support "cid" URL scheme
>>>> and resolve references correctly to the MIME attachments:
>>>>
>>>> http://www.aleksey.com/xmlsec/api/xmlsec-io.html
>>>>
>>>> Aleksey
>>>>
>>>> On 9/14/12 7:50 AM, Mike Peat wrote:
>>>>> Hi
>>>>>
>>>>> I am using xmlsec at the command line in an ebXML application.  As you
>>>>> probably know, ebXML uses SOAP-with-attachments (over HTTP) to send its
>>>>> messages.  The message thus consists of multipart-MIME content in the
>>>>> HTTP body: the first part being a SOAP document containing (among other
>>>>> things) the Signature stuff and the second being an XML document which
>>>>> is the business payload.
>>>>>
>>>>> The Signature->SignedInfo in the SOAP document needs to contain two
>>>>> <Reference> elements: one for the SOAP document itself (URI="") and one
>>>>> for the payload XML (URI="cid:xxxxxxxx", where "xxxxxxxx" is the content
>>>>> ID of the second MIME part).
>>>>>
>>>>> I am managing to successfully sign simple SOAP messages with no payload
>>>>> (and hence no second <Reference> element), but I just can't work out how
>>>>> to get xmlsec to sign both documents together.  I have tried many
>>>>> different ways, but to no avail.  I am sure I am missing something
>>>>> simple, but...  :-(
>>>>>
>>>>> Any help would be very much appreciated - I've been banging my head off
>>>>> this brick wall for a week... and it is starting to really hurt!  :-( 
>>>>> (That takes a while, because my brain is so dense, but even it starts
>>>>> gets sore eventually!)
>>>>>
>>>>> TIA
>>>>>
>>>>> Mike Peat _______________________________________________
>>>>> xmlsec mailing list
>>>>> xmlsec at aleksey.com
>>>>> http://www.aleksey.com/mailman/listinfo/xmlsec 
>>>> .
>>>>
>>>  
>> .
>>
> 

From mpeat at unicorninterglobal.com  Thu Oct 11 10:35:06 2012
From: mpeat at unicorninterglobal.com (Mike Peat)
Date: Thu, 11 Oct 2012 18:35:06 +0100
Subject: [xmlsec] Signing over multiple files
In-Reply-To: <506D97C8.7040706@aleksey.com>
References: <50534421.3070603@unicorninterglobal.com>
 <505353EF.1080503@aleksey.com> <505B1FD0.6080804@unicorninterglobal.com>
 <505BE6C7.5050806@aleksey.com> <506D8462.5080906@unicorninterglobal.com>
 <506D97C8.7040706@aleksey.com>
Message-ID: <5077034A.6090109@unicorninterglobal.com>

Hi Aleksey

Not quite as great as I had thought I'm afraid. :-(

When I went to run my shiny new xmlsec on the target platform it wanted 
msvcr100.dll. I gave it that, but it then turned out that my version was 
crashing (quietly - I had to look into the Windows Event Log to discover 
what was going on) with a problem in ntdll.dll.

I remembered the note in the README that pointed out that all the code 
had to use exactly the same version of the MS C runtime and suspected 
that the other libraries were using msvcrt.dll rather than the "100" 
version (10.0 - I was using Visual Studio 2010) my code wanted. I tried 
using older versions of Visual Studio to do the build (picture a lot of 
thumb-twiddling while I installed version after version of it <g>), but 
that was no real help: VS6 failed to understand a lot of the code; 
VS2003 had just a couple of things it was unhappy about; VS2005 compiled 
and built it all OK, but on running on the target it wanted 
msvcr80.dll... which of course resulted in the same silent runtime crash 
in ntdll.dll.

So I have now given up on Microsoft and switched to using MinGW as a 
build environment. After a bit of fighting to discover the right way to 
configure it and get to to start building, it is now coming up with an 
error during the make which I really don't understand:

    dl.c: In function 'xmlSecCryptoDLLibraryConstructFilename':
    dl.c:295:30: error: 'PACKAGE' undeclared (first use in this function)
    dl.c:295:30: note: each undeclared identifier is reported only once
    for each fun
    ction it appears in
    make[3]: *** [dl.lo] Error 1


...and bombs out.

The line (295) in dl.c that is causing the problem (in 
xmlSecCryptoDLLibraryConstructFilename) is:

    len = xmlStrlen(BAD_CAST PACKAGE) + xmlStrlen(name) +
    xmlStrlen(tmpl) + 1;


and it has a /* TODO */ comment in front of it.

I am a bit stumped.  Obviously I have some aspect of the configuration 
wrong, since the same code built OK under Visual Studio, but I have no 
idea just what in order to start fixing it.

One thing is a bit messy about how I am doing things: I couldn't get the 
configure script to work out where I had put xmllib2, so in the end I 
put the source version of that in there and told it about that instead 
(via "--with-libxml-src") and it appeared to build that without a 
problem. However I now note (in looking for any occurrence of "PACKAGE" 
- there are quite a few: almost 7,000!) that "acconfig.h" in libxml2 has 
an "#undef PACKAGE" statement in it, while its "config.h.in" has a 
couple of them, and am wondering if that could somehow be to blame. 
(Probably not, but it is the sort of thought I have when I have no idea 
what is actually going on.)

Any thoughts would be much appreciated.

TIA

Mike

On 04/10/2012 15:06, Aleksey Sanin wrote:
> Great! Actually I suggest to do it 'the right way' and simply
> create 'cid' protocol handlers:
>
> http://www.aleksey.com/xmlsec/api/xmlsec-io.html#XMLSECIOREGISTERCALLBACKS
>
>
> Aleksey
>
> On 10/4/12 5:43 AM, Mike Peat wrote:
>> Aleksey
>>
>> Just to let you know that I have (finally!) cracked it and got xmlsec to
>> build and run on Windows (and even with an addendum to your copyright
>> notice that indicates that it is my own bodged version! <g>).
>>
>> Now I just have to work out how to modify it (in
>> xmlSecTransformInputURIOpen I think...) to strip off any leading "cid:"
>> from the URI.
>>
>> Thank you for your help!
>>
>> Mike
>>
>> On 21/09/2012 05:02, Aleksey Sanin wrote:
>>> Mike,
>>>
>>> You will need to look into win32/ folder and use Microsoft C compiler.
>>> Honestly, I haven't touched Windows for years so it will be hard for
>>> me to give you a better advice.
>>>
>>> Another option is of course to use a VM with linux and just run it
>>> through VM.
>>>
>>> Aleksey
>>>
>>> On 9/20/12 6:53 AM, Mike Peat wrote:
>>>> Thanks for that Aleksey
>>>>
>>>> Initially I thought I had found a work-around, but I am now back looking
>>>> at the problem from square one again.  Let me explain...
>>>>
>>>> Another customer of the organisation I am communicating with was using
>>>> xmlsec at the command-line to do this, which is what led me down this
>>>> route initially.
>>>>
>>>> It turns out that if the document (file) referred to in the <Reference>
>>>> URI attribute is in the _same directory_ as the SOAP document being
>>>> signed, xmlsec actually picks it up OK and includes its hash-value in
>>>> the <Reference> -> <DigestValue> element... problem solved!
>>>> (Apparently...)  However, life is not so simple.
>>>>
>>>> They are working on a Linux system, while I am cursed with being in
>>>> Windows.  :-(
>>>>
>>>> They are thus able to have files named "cid:/xxxxxxx/", while I am not
>>>> (no colons allowed in file-names in Windows!).  So I changed the URI
>>>> attribute in my Reference element to just contain a file-name with no
>>>> "cid:" prefix, and that got things working as far as digitally signing
>>>> the whole thing with xmlsec was concerned.  However now I am getting
>>>> messages through to the other party's back-end system, which are being
>>>> rejected because now _it_ can't identify the referred to document: it
>>>> seems that it insists on using that "cid:" scheme.
>>>>
>>>> So...
>>>>
>>>> I need to persuade xmlsec to recognise that "cid:" prefix and, in
>>>> effect, ignore it (if the referred-to file-name starts with "cid:",
>>>> replace that with nothing prior to trying to open the file).
>>>>
>>>> I have got the xmlsec source, but up until now have just been using Igor
>>>> Zlatkovic's Windows binaries.
>>>>
>>>> I need to (a) get xmlsec to compile in a Win32 environment and (b) know
>>>> where to make the changes in xmlsec (or perhaps one of its libraries) in
>>>> order to create a version which will do what I need.
>>>>
>>>> I am not really a C/C++ programmer, but I can usually get by in pretty
>>>> much anything (I have been programming since about 1972 - Oh Lord!
>>>> That's 40 years! I'm getting too old for this!).
>>>>
>>>> What compiler will I need and where do I find the code I will need to
>>>> change?  And what build process do I need to go through?  Is there a
>>>> make file or something similar?
>>>>
>>>> Alternatively... what would it take to get somebody who actually knows
>>>> what (s)he is doing to do this for us? We don't have much in the way of
>>>> budget, but this is stopping a project that has months of work in it
>>>> dead in its tracks right now, so...
>>>>
>>>> TIA
>>>>
>>>> Mike Peat
>>>>
>>>> On 14/09/2012 16:57, Aleksey Sanin wrote:
>>>>> Mike,
>>>>>
>>>>> You will probably need to write code to support "cid" URL scheme
>>>>> and resolve references correctly to the MIME attachments:
>>>>>
>>>>> http://www.aleksey.com/xmlsec/api/xmlsec-io.html
>>>>>
>>>>> Aleksey
>>>>>
>>>>> On 9/14/12 7:50 AM, Mike Peat wrote:
>>>>>> Hi
>>>>>>
>>>>>> I am using xmlsec at the command line in an ebXML application.  As you
>>>>>> probably know, ebXML uses SOAP-with-attachments (over HTTP) to send its
>>>>>> messages.  The message thus consists of multipart-MIME content in the
>>>>>> HTTP body: the first part being a SOAP document containing (among other
>>>>>> things) the Signature stuff and the second being an XML document which
>>>>>> is the business payload.
>>>>>>
>>>>>> The Signature->SignedInfo in the SOAP document needs to contain two
>>>>>> <Reference> elements: one for the SOAP document itself (URI="") and one
>>>>>> for the payload XML (URI="cid:xxxxxxxx", where "xxxxxxxx" is the content
>>>>>> ID of the second MIME part).
>>>>>>
>>>>>> I am managing to successfully sign simple SOAP messages with no payload
>>>>>> (and hence no second <Reference> element), but I just can't work out how
>>>>>> to get xmlsec to sign both documents together.  I have tried many
>>>>>> different ways, but to no avail.  I am sure I am missing something
>>>>>> simple, but...  :-(
>>>>>>
>>>>>> Any help would be very much appreciated - I've been banging my head off
>>>>>> this brick wall for a week... and it is starting to really hurt!  :-(
>>>>>> (That takes a while, because my brain is so dense, but even it starts
>>>>>> gets sore eventually!)
>>>>>>
>>>>>> TIA
>>>>>>
>>>>>> Mike Peat _______________________________________________
>>>>>> xmlsec mailing list
>>>>>> xmlsec at aleksey.com
>>>>>> http://www.aleksey.com/mailman/listinfo/xmlsec
>>>>> .
>>>>>
>>>>   
>>> .
>>>
>>   
> .
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.aleksey.com/pipermail/xmlsec/attachments/20121011/58f917be/attachment.html>

From aleksey at aleksey.com  Thu Oct 11 12:03:53 2012
From: aleksey at aleksey.com (Aleksey Sanin)
Date: Thu, 11 Oct 2012 12:03:53 -0700
Subject: [xmlsec] Signing over multiple files
In-Reply-To: <5077034A.6090109@unicorninterglobal.com>
References: <50534421.3070603@unicorninterglobal.com>
 <505353EF.1080503@aleksey.com> <505B1FD0.6080804@unicorninterglobal.com>
 <505BE6C7.5050806@aleksey.com> <506D8462.5080906@unicorninterglobal.com>
 <506D97C8.7040706@aleksey.com> <5077034A.6090109@unicorninterglobal.com>
Message-ID: <50771819.1060504@aleksey.com>

Sorry, no ideas. I was never able to compile xmlsec with MinGW for
various reasons.

Aleksey

On 10/11/12 10:35 AM, Mike Peat wrote:
> Hi Aleksey
> 
> Not quite as great as I had thought I'm afraid. :-(
> 
> When I went to run my shiny new xmlsec on the target platform it wanted
> msvcr100.dll. I gave it that, but it then turned out that my version was
> crashing (quietly - I had to look into the Windows Event Log to discover
> what was going on) with a problem in ntdll.dll.
> 
> I remembered the note in the README that pointed out that all the code
> had to use exactly the same version of the MS C runtime and suspected
> that the other libraries were using msvcrt.dll rather than the "100"
> version (10.0 - I was using Visual Studio 2010) my code wanted. I tried
> using older versions of Visual Studio to do the build (picture a lot of
> thumb-twiddling while I installed version after version of it <g>), but
> that was no real help: VS6 failed to understand a lot of the code;
> VS2003 had just a couple of things it was unhappy about; VS2005 compiled
> and built it all OK, but on running on the target it wanted
> msvcr80.dll... which of course resulted in the same silent runtime crash
> in ntdll.dll.
> 
> So I have now given up on Microsoft and switched to using MinGW as a
> build environment. After a bit of fighting to discover the right way to
> configure it and get to to start building, it is now coming up with an
> error during the make which I really don't understand:
> 
>     dl.c: In function 'xmlSecCryptoDLLibraryConstructFilename':
>     dl.c:295:30: error: 'PACKAGE' undeclared (first use in this function)
>     dl.c:295:30: note: each undeclared identifier is reported only once
>     for each fun
>     ction it appears in
>     make[3]: *** [dl.lo] Error 1
> 
> 
> ...and bombs out.
> 
> The line (295) in dl.c that is causing the problem (in
> xmlSecCryptoDLLibraryConstructFilename) is:
> 
>     len = xmlStrlen(BAD_CAST PACKAGE) + xmlStrlen(name) +
>     xmlStrlen(tmpl) + 1;
> 
> 
> and it has a /* TODO */ comment in front of it.
> 
> I am a bit stumped.  Obviously I have some aspect of the configuration
> wrong, since the same code built OK under Visual Studio, but I have no
> idea just what in order to start fixing it.
> 
> One thing is a bit messy about how I am doing things: I couldn't get the
> configure script to work out where I had put xmllib2, so in the end I
> put the source version of that in there and told it about that instead
> (via "--with-libxml-src") and it appeared to build that without a
> problem. However I now note (in looking for any occurrence of "PACKAGE"
> - there are quite a few: almost 7,000!) that "acconfig.h" in libxml2 has
> an "#undef PACKAGE" statement in it, while its "config.h.in" has a
> couple of them, and am wondering if that could somehow be to blame.
> (Probably not, but it is the sort of thought I have when I have no idea
> what is actually going on.)
> 
> Any thoughts would be much appreciated.
> 
> TIA
> 
> Mike
> 
> On 04/10/2012 15:06, Aleksey Sanin wrote:
>> Great! Actually I suggest to do it 'the right way' and simply
>> create 'cid' protocol handlers:
>>
>> http://www.aleksey.com/xmlsec/api/xmlsec-io.html#XMLSECIOREGISTERCALLBACKS
>>
>>
>> Aleksey
>>
>> On 10/4/12 5:43 AM, Mike Peat wrote:
>>> Aleksey
>>>
>>> Just to let you know that I have (finally!) cracked it and got xmlsec to
>>> build and run on Windows (and even with an addendum to your copyright
>>> notice that indicates that it is my own bodged version! <g>).
>>>
>>> Now I just have to work out how to modify it (in
>>> xmlSecTransformInputURIOpen I think...) to strip off any leading "cid:"
>>> from the URI.
>>>
>>> Thank you for your help!
>>>
>>> Mike
>>>
>>> On 21/09/2012 05:02, Aleksey Sanin wrote:
>>>> Mike,
>>>>
>>>> You will need to look into win32/ folder and use Microsoft C compiler.
>>>> Honestly, I haven't touched Windows for years so it will be hard for
>>>> me to give you a better advice.
>>>>
>>>> Another option is of course to use a VM with linux and just run it
>>>> through VM.
>>>>
>>>> Aleksey
>>>>
>>>> On 9/20/12 6:53 AM, Mike Peat wrote:
>>>>> Thanks for that Aleksey
>>>>>
>>>>> Initially I thought I had found a work-around, but I am now back looking
>>>>> at the problem from square one again.  Let me explain...
>>>>>
>>>>> Another customer of the organisation I am communicating with was using
>>>>> xmlsec at the command-line to do this, which is what led me down this
>>>>> route initially.
>>>>>
>>>>> It turns out that if the document (file) referred to in the <Reference>
>>>>> URI attribute is in the _same directory_ as the SOAP document being
>>>>> signed, xmlsec actually picks it up OK and includes its hash-value in
>>>>> the <Reference> -> <DigestValue> element... problem solved!
>>>>> (Apparently...)  However, life is not so simple.
>>>>>
>>>>> They are working on a Linux system, while I am cursed with being in
>>>>> Windows.  :-(
>>>>>
>>>>> They are thus able to have files named "cid:/xxxxxxx/", while I am not
>>>>> (no colons allowed in file-names in Windows!).  So I changed the URI
>>>>> attribute in my Reference element to just contain a file-name with no
>>>>> "cid:" prefix, and that got things working as far as digitally signing
>>>>> the whole thing with xmlsec was concerned.  However now I am getting
>>>>> messages through to the other party's back-end system, which are being
>>>>> rejected because now _it_ can't identify the referred to document: it
>>>>> seems that it insists on using that "cid:" scheme.
>>>>>
>>>>> So...
>>>>>
>>>>> I need to persuade xmlsec to recognise that "cid:" prefix and, in
>>>>> effect, ignore it (if the referred-to file-name starts with "cid:",
>>>>> replace that with nothing prior to trying to open the file).
>>>>>
>>>>> I have got the xmlsec source, but up until now have just been using Igor
>>>>> Zlatkovic's Windows binaries.
>>>>>
>>>>> I need to (a) get xmlsec to compile in a Win32 environment and (b) know
>>>>> where to make the changes in xmlsec (or perhaps one of its libraries) in
>>>>> order to create a version which will do what I need.
>>>>>
>>>>> I am not really a C/C++ programmer, but I can usually get by in pretty
>>>>> much anything (I have been programming since about 1972 - Oh Lord!
>>>>> That's 40 years! I'm getting too old for this!).
>>>>>
>>>>> What compiler will I need and where do I find the code I will need to
>>>>> change?  And what build process do I need to go through?  Is there a
>>>>> make file or something similar?
>>>>>
>>>>> Alternatively... what would it take to get somebody who actually knows
>>>>> what (s)he is doing to do this for us? We don't have much in the way of
>>>>> budget, but this is stopping a project that has months of work in it
>>>>> dead in its tracks right now, so...
>>>>>
>>>>> TIA
>>>>>
>>>>> Mike Peat
>>>>>
>>>>> On 14/09/2012 16:57, Aleksey Sanin wrote:
>>>>>> Mike,
>>>>>>
>>>>>> You will probably need to write code to support "cid" URL scheme
>>>>>> and resolve references correctly to the MIME attachments:
>>>>>>
>>>>>> http://www.aleksey.com/xmlsec/api/xmlsec-io.html
>>>>>>
>>>>>> Aleksey
>>>>>>
>>>>>> On 9/14/12 7:50 AM, Mike Peat wrote:
>>>>>>> Hi
>>>>>>>
>>>>>>> I am using xmlsec at the command line in an ebXML application.  As you
>>>>>>> probably know, ebXML uses SOAP-with-attachments (over HTTP) to send its
>>>>>>> messages.  The message thus consists of multipart-MIME content in the
>>>>>>> HTTP body: the first part being a SOAP document containing (among other
>>>>>>> things) the Signature stuff and the second being an XML document which
>>>>>>> is the business payload.
>>>>>>>
>>>>>>> The Signature->SignedInfo in the SOAP document needs to contain two
>>>>>>> <Reference> elements: one for the SOAP document itself (URI="") and one
>>>>>>> for the payload XML (URI="cid:xxxxxxxx", where "xxxxxxxx" is the content
>>>>>>> ID of the second MIME part).
>>>>>>>
>>>>>>> I am managing to successfully sign simple SOAP messages with no payload
>>>>>>> (and hence no second <Reference> element), but I just can't work out how
>>>>>>> to get xmlsec to sign both documents together.  I have tried many
>>>>>>> different ways, but to no avail.  I am sure I am missing something
>>>>>>> simple, but...  :-(
>>>>>>>
>>>>>>> Any help would be very much appreciated - I've been banging my head off
>>>>>>> this brick wall for a week... and it is starting to really hurt!  :-( 
>>>>>>> (That takes a while, because my brain is so dense, but even it starts
>>>>>>> gets sore eventually!)
>>>>>>>
>>>>>>> TIA
>>>>>>>
>>>>>>> Mike Peat _______________________________________________
>>>>>>> xmlsec mailing list
>>>>>>> xmlsec at aleksey.com
>>>>>>> http://www.aleksey.com/mailman/listinfo/xmlsec 
>>>>>> .
>>>>>>
>>>>>  
>>>> .
>>>>
>>>  
>> .
>>
> 
> 
> 
> _______________________________________________
> xmlsec mailing list
> xmlsec at aleksey.com
> http://www.aleksey.com/mailman/listinfo/xmlsec
> 

From xmlsec at roumenpetrov.info  Thu Oct 11 13:52:34 2012
From: xmlsec at roumenpetrov.info (Roumen Petrov)
Date: Thu, 11 Oct 2012 23:52:34 +0300
Subject: [xmlsec] Signing over multiple files
In-Reply-To: <5077034A.6090109@unicorninterglobal.com>
References: <50534421.3070603@unicorninterglobal.com>
 <505353EF.1080503@aleksey.com> <505B1FD0.6080804@unicorninterglobal.com>
 <505BE6C7.5050806@aleksey.com> <506D8462.5080906@unicorninterglobal.com>
 <506D97C8.7040706@aleksey.com> <5077034A.6090109@unicorninterglobal.com>
Message-ID: <50773192.4010105@roumenpetrov.info>

HI Mike,

Mike Peat wrote:
> Hi Aleksey
> [SNIP]
> .... and switched to using MinGW as a build environment. After a bit
> of fighting to discover the right way to configure it and get to to
> start building, it is now coming up with an error during the make
> which I really don't understand:
>
>    dl.c: In function 'xmlSecCryptoDLLibraryConstructFilename':
>    dl.c:295:30: error: 'PACKAGE' undeclared (first use in this function)
>    dl.c:295:30: note: each undeclared identifier is reported only once
>    for each function it appears in
>    make[3]: *** [dl.lo] Error 1
[SNIP]

Issue is not related to compiler. May be configure fail to create config.h.

$ wc -l config.h
129 config.h

$ grep -w PACKAGE config.h
#define PACKAGE "xmlsec1"

I guess you use "standard" build process:
$ ..../configure  ...
$ make


Roumen

P.S. resend from correct email address

From mpeat at unicorninterglobal.com  Thu Oct 11 15:34:05 2012
From: mpeat at unicorninterglobal.com (Mike Peat)
Date: Thu, 11 Oct 2012 23:34:05 +0100
Subject: [xmlsec] Signing over multiple files
In-Reply-To: <50771819.1060504@aleksey.com>
References: <50534421.3070603@unicorninterglobal.com>
 <505353EF.1080503@aleksey.com> <505B1FD0.6080804@unicorninterglobal.com>
 <505BE6C7.5050806@aleksey.com> <506D8462.5080906@unicorninterglobal.com>
 <506D97C8.7040706@aleksey.com> <5077034A.6090109@unicorninterglobal.com>
 <50771819.1060504@aleksey.com>
Message-ID: <5077495D.4070909@unicorninterglobal.com>

Thanks for getting back to me anyway Aleksey.

I will just have to figure it out on my own I guess.

Weirdly, your response even helps... if _you_ couldn't get it to work, 
it makes me feel not /quite/ so inadequate and stupid that I am having 
problems. ;-)

I will let you know if I crack it (if I can get it to all work, I may 
even document it... if I have the strength! <g>)

Thanks again.

Mike

On 11/10/2012 20:03, Aleksey Sanin wrote:
> Sorry, no ideas. I was never able to compile xmlsec with MinGW for
> various reasons.
>
> Aleksey
>
> On 10/11/12 10:35 AM, Mike Peat wrote:
>> Hi Aleksey
>>
>> Not quite as great as I had thought I'm afraid. :-(
>>
>> When I went to run my shiny new xmlsec on the target platform it wanted
>> msvcr100.dll. I gave it that, but it then turned out that my version was
>> crashing (quietly - I had to look into the Windows Event Log to discover
>> what was going on) with a problem in ntdll.dll.
>>
>> I remembered the note in the README that pointed out that all the code
>> had to use exactly the same version of the MS C runtime and suspected
>> that the other libraries were using msvcrt.dll rather than the "100"
>> version (10.0 - I was using Visual Studio 2010) my code wanted. I tried
>> using older versions of Visual Studio to do the build (picture a lot of
>> thumb-twiddling while I installed version after version of it <g>), but
>> that was no real help: VS6 failed to understand a lot of the code;
>> VS2003 had just a couple of things it was unhappy about; VS2005 compiled
>> and built it all OK, but on running on the target it wanted
>> msvcr80.dll... which of course resulted in the same silent runtime crash
>> in ntdll.dll.
>>
>> So I have now given up on Microsoft and switched to using MinGW as a
>> build environment. After a bit of fighting to discover the right way to
>> configure it and get to to start building, it is now coming up with an
>> error during the make which I really don't understand:
>>
>>      dl.c: In function 'xmlSecCryptoDLLibraryConstructFilename':
>>      dl.c:295:30: error: 'PACKAGE' undeclared (first use in this function)
>>      dl.c:295:30: note: each undeclared identifier is reported only once
>>      for each fun
>>      ction it appears in
>>      make[3]: *** [dl.lo] Error 1
>>
>>
>> ...and bombs out.
>>
>> The line (295) in dl.c that is causing the problem (in
>> xmlSecCryptoDLLibraryConstructFilename) is:
>>
>>      len = xmlStrlen(BAD_CAST PACKAGE) + xmlStrlen(name) +
>>      xmlStrlen(tmpl) + 1;
>>
>>
>> and it has a /* TODO */ comment in front of it.
>>
>> I am a bit stumped.  Obviously I have some aspect of the configuration
>> wrong, since the same code built OK under Visual Studio, but I have no
>> idea just what in order to start fixing it.
>>
>> One thing is a bit messy about how I am doing things: I couldn't get the
>> configure script to work out where I had put xmllib2, so in the end I
>> put the source version of that in there and told it about that instead
>> (via "--with-libxml-src") and it appeared to build that without a
>> problem. However I now note (in looking for any occurrence of "PACKAGE"
>> - there are quite a few: almost 7,000!) that "acconfig.h" in libxml2 has
>> an "#undef PACKAGE" statement in it, while its "config.h.in" has a
>> couple of them, and am wondering if that could somehow be to blame.
>> (Probably not, but it is the sort of thought I have when I have no idea
>> what is actually going on.)
>>
>> Any thoughts would be much appreciated.
>>
>> TIA
>>
>> Mike
>>
>> On 04/10/2012 15:06, Aleksey Sanin wrote:
>>> Great! Actually I suggest to do it 'the right way' and simply
>>> create 'cid' protocol handlers:
>>>
>>> http://www.aleksey.com/xmlsec/api/xmlsec-io.html#XMLSECIOREGISTERCALLBACKS
>>>
>>>
>>> Aleksey
>>>
>>> On 10/4/12 5:43 AM, Mike Peat wrote:
>>>> Aleksey
>>>>
>>>> Just to let you know that I have (finally!) cracked it and got xmlsec to
>>>> build and run on Windows (and even with an addendum to your copyright
>>>> notice that indicates that it is my own bodged version! <g>).
>>>>
>>>> Now I just have to work out how to modify it (in
>>>> xmlSecTransformInputURIOpen I think...) to strip off any leading "cid:"
>>>> from the URI.
>>>>
>>>> Thank you for your help!
>>>>
>>>> Mike
>>>>
>>>> On 21/09/2012 05:02, Aleksey Sanin wrote:
>>>>> Mike,
>>>>>
>>>>> You will need to look into win32/ folder and use Microsoft C compiler.
>>>>> Honestly, I haven't touched Windows for years so it will be hard for
>>>>> me to give you a better advice.
>>>>>
>>>>> Another option is of course to use a VM with linux and just run it
>>>>> through VM.
>>>>>
>>>>> Aleksey
>>>>>
>>>>> On 9/20/12 6:53 AM, Mike Peat wrote:
>>>>>> Thanks for that Aleksey
>>>>>>
>>>>>> Initially I thought I had found a work-around, but I am now back looking
>>>>>> at the problem from square one again.  Let me explain...
>>>>>>
>>>>>> Another customer of the organisation I am communicating with was using
>>>>>> xmlsec at the command-line to do this, which is what led me down this
>>>>>> route initially.
>>>>>>
>>>>>> It turns out that if the document (file) referred to in the <Reference>
>>>>>> URI attribute is in the _same directory_ as the SOAP document being
>>>>>> signed, xmlsec actually picks it up OK and includes its hash-value in
>>>>>> the <Reference> -> <DigestValue> element... problem solved!
>>>>>> (Apparently...)  However, life is not so simple.
>>>>>>
>>>>>> They are working on a Linux system, while I am cursed with being in
>>>>>> Windows.  :-(
>>>>>>
>>>>>> They are thus able to have files named "cid:/xxxxxxx/", while I am not
>>>>>> (no colons allowed in file-names in Windows!).  So I changed the URI
>>>>>> attribute in my Reference element to just contain a file-name with no
>>>>>> "cid:" prefix, and that got things working as far as digitally signing
>>>>>> the whole thing with xmlsec was concerned.  However now I am getting
>>>>>> messages through to the other party's back-end system, which are being
>>>>>> rejected because now _it_ can't identify the referred to document: it
>>>>>> seems that it insists on using that "cid:" scheme.
>>>>>>
>>>>>> So...
>>>>>>
>>>>>> I need to persuade xmlsec to recognise that "cid:" prefix and, in
>>>>>> effect, ignore it (if the referred-to file-name starts with "cid:",
>>>>>> replace that with nothing prior to trying to open the file).
>>>>>>
>>>>>> I have got the xmlsec source, but up until now have just been using Igor
>>>>>> Zlatkovic's Windows binaries.
>>>>>>
>>>>>> I need to (a) get xmlsec to compile in a Win32 environment and (b) know
>>>>>> where to make the changes in xmlsec (or perhaps one of its libraries) in
>>>>>> order to create a version which will do what I need.
>>>>>>
>>>>>> I am not really a C/C++ programmer, but I can usually get by in pretty
>>>>>> much anything (I have been programming since about 1972 - Oh Lord!
>>>>>> That's 40 years! I'm getting too old for this!).
>>>>>>
>>>>>> What compiler will I need and where do I find the code I will need to
>>>>>> change?  And what build process do I need to go through?  Is there a
>>>>>> make file or something similar?
>>>>>>
>>>>>> Alternatively... what would it take to get somebody who actually knows
>>>>>> what (s)he is doing to do this for us? We don't have much in the way of
>>>>>> budget, but this is stopping a project that has months of work in it
>>>>>> dead in its tracks right now, so...
>>>>>>
>>>>>> TIA
>>>>>>
>>>>>> Mike Peat
>>>>>>
>>>>>> On 14/09/2012 16:57, Aleksey Sanin wrote:
>>>>>>> Mike,
>>>>>>>
>>>>>>> You will probably need to write code to support "cid" URL scheme
>>>>>>> and resolve references correctly to the MIME attachments:
>>>>>>>
>>>>>>> http://www.aleksey.com/xmlsec/api/xmlsec-io.html
>>>>>>>
>>>>>>> Aleksey
>>>>>>>
>>>>>>> On 9/14/12 7:50 AM, Mike Peat wrote:
>>>>>>>> Hi
>>>>>>>>
>>>>>>>> I am using xmlsec at the command line in an ebXML application.  As you
>>>>>>>> probably know, ebXML uses SOAP-with-attachments (over HTTP) to send its
>>>>>>>> messages.  The message thus consists of multipart-MIME content in the
>>>>>>>> HTTP body: the first part being a SOAP document containing (among other
>>>>>>>> things) the Signature stuff and the second being an XML document which
>>>>>>>> is the business payload.
>>>>>>>>
>>>>>>>> The Signature->SignedInfo in the SOAP document needs to contain two
>>>>>>>> <Reference> elements: one for the SOAP document itself (URI="") and one
>>>>>>>> for the payload XML (URI="cid:xxxxxxxx", where "xxxxxxxx" is the content
>>>>>>>> ID of the second MIME part).
>>>>>>>>
>>>>>>>> I am managing to successfully sign simple SOAP messages with no payload
>>>>>>>> (and hence no second <Reference> element), but I just can't work out how
>>>>>>>> to get xmlsec to sign both documents together.  I have tried many
>>>>>>>> different ways, but to no avail.  I am sure I am missing something
>>>>>>>> simple, but...  :-(
>>>>>>>>
>>>>>>>> Any help would be very much appreciated - I've been banging my head off
>>>>>>>> this brick wall for a week... and it is starting to really hurt!  :-(
>>>>>>>> (That takes a while, because my brain is so dense, but even it starts
>>>>>>>> gets sore eventually!)
>>>>>>>>
>>>>>>>> TIA
>>>>>>>>
>>>>>>>> Mike Peat _______________________________________________
>>>>>>>> xmlsec mailing list
>>>>>>>> xmlsec at aleksey.com
>>>>>>>> http://www.aleksey.com/mailman/listinfo/xmlsec
>>>>>>> .
>>>>>>>
>>>>>>   
>>>>> .
>>>>>
>>>>   
>>> .
>>>
>>
>>
>> _______________________________________________
>> xmlsec mailing list
>> xmlsec at aleksey.com
>> http://www.aleksey.com/mailman/listinfo/xmlsec
>>   
> .
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.aleksey.com/pipermail/xmlsec/attachments/20121011/41d2013e/attachment-0001.html>

From simon at josefsson.org  Mon Oct 15 12:56:35 2012
From: simon at josefsson.org (Simon Josefsson)
Date: Mon, 15 Oct 2012 21:56:35 +0200
Subject: [xmlsec] Signature in different namespace
Message-ID: <874nlvse4s.fsf@latte.josefsson.org>

Hi.  I want to implement support for signing/verifying PSKC data (RFC
6030) which uses xmldsig.  The XML schema is here:

http://tools.ietf.org/html/rfc6030#section-11

In particular it refer to xmldsig like this:

               <xs:element name="Signature"
                    type="ds:SignatureType" minOccurs="0"/>

As far as I can tell (and this is reinforced by the example in section 7
of RFC 6030), this means the XML will have a Signature element in the
PSKC namespace but with children from the xmldsig namespace.  For
example:

   <?xml version="1.0" encoding="UTF-8"?>
   <KeyContainer
       xmlns="urn:ietf:params:xml:ns:keyprov:pskc"
       xmlns:ds="http://www.w3.org/2000/09/xmldsig#"
       xmlns:xenc="http://www.w3.org/2001/04/xmlenc#"
       Version="1.0">
       <KeyPackage>
...
       </KeyPackage>
       <Signature>
           <ds:SignedInfo>
               <ds:CanonicalizationMethod
...

I'm having trouble making XMLSec cope with this.  xmlSecDSigCtxSign
calls xmlSecDSigCtxProcessSignatureNode which starts with:

    if(!xmlSecCheckNodeName(node, xmlSecNodeSignature, xmlSecDSigNs)) {
        xmlSecError(XMLSEC_ERRORS_HERE,

So I get a hard error when trying to sign with a Signature node that
isn't in the xmldsig namespace.  Any ideas on what could be done here?

(Sorry if you get a similar email later on, I recently subscribed to
re-send this e-mail.)

Thanks,
/Simon

From aleksey at aleksey.com  Mon Oct 15 13:00:34 2012
From: aleksey at aleksey.com (Aleksey Sanin)
Date: Mon, 15 Oct 2012 13:00:34 -0700
Subject: [xmlsec] Signature in different namespace
In-Reply-To: <874nlvse4s.fsf@latte.josefsson.org>
References: <874nlvse4s.fsf@latte.josefsson.org>
Message-ID: <507C6B62.3010504@aleksey.com>

I don't see example but "ds:SignatureType" defines Signature node in
the DS namespace.

Aleksey

On 10/15/12 12:56 PM, Simon Josefsson wrote:
> Hi.  I want to implement support for signing/verifying PSKC data (RFC
> 6030) which uses xmldsig.  The XML schema is here:
> 
> http://tools.ietf.org/html/rfc6030#section-11
> 
> In particular it refer to xmldsig like this:
> 
>                <xs:element name="Signature"
>                     type="ds:SignatureType" minOccurs="0"/>
> 
> As far as I can tell (and this is reinforced by the example in section 7
> of RFC 6030), this means the XML will have a Signature element in the
> PSKC namespace but with children from the xmldsig namespace.  For
> example:
> 
>    <?xml version="1.0" encoding="UTF-8"?>
>    <KeyContainer
>        xmlns="urn:ietf:params:xml:ns:keyprov:pskc"
>        xmlns:ds="http://www.w3.org/2000/09/xmldsig#"
>        xmlns:xenc="http://www.w3.org/2001/04/xmlenc#"
>        Version="1.0">
>        <KeyPackage>
> ...
>        </KeyPackage>
>        <Signature>
>            <ds:SignedInfo>
>                <ds:CanonicalizationMethod
> ...
> 
> I'm having trouble making XMLSec cope with this.  xmlSecDSigCtxSign
> calls xmlSecDSigCtxProcessSignatureNode which starts with:
> 
>     if(!xmlSecCheckNodeName(node, xmlSecNodeSignature, xmlSecDSigNs)) {
>         xmlSecError(XMLSEC_ERRORS_HERE,
> 
> So I get a hard error when trying to sign with a Signature node that
> isn't in the xmldsig namespace.  Any ideas on what could be done here?
> 
> (Sorry if you get a similar email later on, I recently subscribed to
> re-send this e-mail.)
> 
> Thanks,
> /Simon
> _______________________________________________
> xmlsec mailing list
> xmlsec at aleksey.com
> http://www.aleksey.com/mailman/listinfo/xmlsec
> 

From simon at josefsson.org  Mon Oct 15 14:27:59 2012
From: simon at josefsson.org (Simon Josefsson)
Date: Mon, 15 Oct 2012 23:27:59 +0200
Subject: [xmlsec] Signature in different namespace
In-Reply-To: <507C6B62.3010504@aleksey.com> (Aleksey Sanin's message of "Mon, 
 15 Oct 2012 13:00:34 -0700")
References: <874nlvse4s.fsf@latte.josefsson.org> <507C6B62.3010504@aleksey.com>
Message-ID: <87zk3nqvc0.fsf@latte.josefsson.org>

Aleksey Sanin <aleksey at aleksey.com> writes:

> I don't see example but "ds:SignatureType" defines Signature node in
> the DS namespace.

The example is here:

http://tools.ietf.org/html/rfc6030#section-7

and contains

   <?xml version="1.0" encoding="UTF-8"?>
   <KeyContainer
       xmlns="urn:ietf:params:xml:ns:keyprov:pskc"
       xmlns:ds="http://www.w3.org/2000/09/xmldsig#"
       xmlns:xenc="http://www.w3.org/2001/04/xmlenc#"
       Version="1.0">
...
       <Signature>
           <ds:SignedInfo>
...

I have validated the example against the schema using xmllint.  The
XMLSec library templates create a Signature element like this:

...
       <ds:Signature>
           <ds:SignedInfo>
...

With the "ds:" prefix on the Signature element, I get a schema
validation error:

    pskctool/tests/pskc-figure9.xml:30: element Signature: Schemas validity error : Element '{http://www.w3.org/2000/09/xmldsig#}Signature': This element is not expected. Expected is one of ( {urn:ietf:params:xml:ns:keyprov:pskc}KeyPackage, {urn:ietf:params:xml:ns:keyprov:pskc}Signature, {urn:ietf:params:xml:ns:keyprov:pskc}Extensions ).

However, I have come up with a temporary workaround: after
xmlSecDSigCtxSign() succeeds, I do a xmlSetNs (signNode, NULL) to clear
the namespace prefix for the Signature element.  This seems quite ugly
though.  I have yet to write the code to verify these signatures
though...

/Simon

From aleksey at aleksey.com  Mon Oct 15 14:33:22 2012
From: aleksey at aleksey.com (Aleksey Sanin)
Date: Mon, 15 Oct 2012 14:33:22 -0700
Subject: [xmlsec] Signature in different namespace
In-Reply-To: <87zk3nqvc0.fsf@latte.josefsson.org>
References: <874nlvse4s.fsf@latte.josefsson.org>
 <507C6B62.3010504@aleksey.com> <87zk3nqvc0.fsf@latte.josefsson.org>
Message-ID: <507C8122.3060101@aleksey.com>

I think it is a bug in the spec which makes it incompatible
with W3C Digital Signatures spec.

Aleksey

On 10/15/12 2:27 PM, Simon Josefsson wrote:
> Aleksey Sanin <aleksey at aleksey.com> writes:
> 
>> I don't see example but "ds:SignatureType" defines Signature node in
>> the DS namespace.
> 
> The example is here:
> 
> http://tools.ietf.org/html/rfc6030#section-7
> 
> and contains
> 
>    <?xml version="1.0" encoding="UTF-8"?>
>    <KeyContainer
>        xmlns="urn:ietf:params:xml:ns:keyprov:pskc"
>        xmlns:ds="http://www.w3.org/2000/09/xmldsig#"
>        xmlns:xenc="http://www.w3.org/2001/04/xmlenc#"
>        Version="1.0">
> ...
>        <Signature>
>            <ds:SignedInfo>
> ...
> 
> I have validated the example against the schema using xmllint.  The
> XMLSec library templates create a Signature element like this:
> 
> ...
>        <ds:Signature>
>            <ds:SignedInfo>
> ...
> 
> With the "ds:" prefix on the Signature element, I get a schema
> validation error:
> 
>     pskctool/tests/pskc-figure9.xml:30: element Signature: Schemas validity error : Element '{http://www.w3.org/2000/09/xmldsig#}Signature': This element is not expected. Expected is one of ( {urn:ietf:params:xml:ns:keyprov:pskc}KeyPackage, {urn:ietf:params:xml:ns:keyprov:pskc}Signature, {urn:ietf:params:xml:ns:keyprov:pskc}Extensions ).
> 
> However, I have come up with a temporary workaround: after
> xmlSecDSigCtxSign() succeeds, I do a xmlSetNs (signNode, NULL) to clear
> the namespace prefix for the Signature element.  This seems quite ugly
> though.  I have yet to write the code to verify these signatures
> though...
> 
> /Simon
> 

From simon at josefsson.org  Mon Oct 15 14:51:41 2012
From: simon at josefsson.org (Simon Josefsson)
Date: Mon, 15 Oct 2012 23:51:41 +0200
Subject: [xmlsec] Signature in different namespace
In-Reply-To: <507C8122.3060101@aleksey.com> (Aleksey Sanin's message of "Mon, 
 15 Oct 2012 14:33:22 -0700")
References: <874nlvse4s.fsf@latte.josefsson.org>
 <507C6B62.3010504@aleksey.com> <87zk3nqvc0.fsf@latte.josefsson.org>
 <507C8122.3060101@aleksey.com>
Message-ID: <87sj9fqu8i.fsf@latte.josefsson.org>

Interesting -- thank you for your insight.  How should XMLDsig be
referenced in XML Schemas?  I suppose you are saying that the following
approach used by PSKC is incorrect?

     <xs:complexType name="KeyContainerType">
          <xs:sequence>
...
               <xs:element name="Signature"
                    type="ds:SignatureType" minOccurs="0"/>

/Simon

Aleksey Sanin <aleksey at aleksey.com> writes:

> I think it is a bug in the spec which makes it incompatible
> with W3C Digital Signatures spec.
>
> Aleksey
>
> On 10/15/12 2:27 PM, Simon Josefsson wrote:
>> Aleksey Sanin <aleksey at aleksey.com> writes:
>> 
>>> I don't see example but "ds:SignatureType" defines Signature node in
>>> the DS namespace.
>> 
>> The example is here:
>> 
>> http://tools.ietf.org/html/rfc6030#section-7
>> 
>> and contains
>> 
>>    <?xml version="1.0" encoding="UTF-8"?>
>>    <KeyContainer
>>        xmlns="urn:ietf:params:xml:ns:keyprov:pskc"
>>        xmlns:ds="http://www.w3.org/2000/09/xmldsig#"
>>        xmlns:xenc="http://www.w3.org/2001/04/xmlenc#"
>>        Version="1.0">
>> ...
>>        <Signature>
>>            <ds:SignedInfo>
>> ...
>> 
>> I have validated the example against the schema using xmllint.  The
>> XMLSec library templates create a Signature element like this:
>> 
>> ...
>>        <ds:Signature>
>>            <ds:SignedInfo>
>> ...
>> 
>> With the "ds:" prefix on the Signature element, I get a schema
>> validation error:
>> 
>>     pskctool/tests/pskc-figure9.xml:30: element Signature: Schemas validity error : Element '{http://www.w3.org/2000/09/xmldsig#}Signature': This element is not expected. Expected is one of ( {urn:ietf:params:xml:ns:keyprov:pskc}KeyPackage, {urn:ietf:params:xml:ns:keyprov:pskc}Signature, {urn:ietf:params:xml:ns:keyprov:pskc}Extensions ).
>> 
>> However, I have come up with a temporary workaround: after
>> xmlSecDSigCtxSign() succeeds, I do a xmlSetNs (signNode, NULL) to clear
>> the namespace prefix for the Signature element.  This seems quite ugly
>> though.  I have yet to write the code to verify these signatures
>> though...
>> 
>> /Simon
>> 

From gkholman at CraneSoftwrights.com  Mon Oct 15 15:10:30 2012
From: gkholman at CraneSoftwrights.com (G. Ken Holman)
Date: Tue, 16 Oct 2012 00:10:30 +0200
Subject: [xmlsec] Signature in different namespace
In-Reply-To: <87sj9fqu8i.fsf@latte.josefsson.org>
References: <874nlvse4s.fsf@latte.josefsson.org> <507C6B62.3010504@aleksey.com>
 <87zk3nqvc0.fsf@latte.josefsson.org> <507C8122.3060101@aleksey.com>
 <87sj9fqu8i.fsf@latte.josefsson.org>
Message-ID: <7.0.1.0.2.20121016000456.02475a18@wheresmymailserver.com>

At 2012-10-15 23:51 +0200, Simon Josefsson wrote:
>Interesting -- thank you for your insight.  How should XMLDsig be
>referenced in XML Schemas?  I suppose you are saying that the following
>approach used by PSKC is incorrect?
>
>      <xs:complexType name="KeyContainerType">
>           <xs:sequence>
>...
>                <xs:element name="Signature"
>                     type="ds:SignatureType" minOccurs="0"/>

You would need to reference the Signature element declared in the 
XMLDsig schema fragment, not create your own element.  If the above 
is used somewhere, I believe it is being done incorrectly.

This is how I wrote the schema for OASIS UBL that incorporates ds:Signature:

http://docs.oasis-open.org/ubl/prd2-UBL-2.1/xsd/common/UBL-SignatureAggregateComponents-2.1.xsd

<xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema"
             xmlns:ds="http://www.w3.org/2000/09/xmldsig#"
             targetNamespace=...
    ...
    <!-- ===== Incorporate W3C signature specification-->
    <xsd:import namespace="http://www.w3.org/2000/09/xmldsig#"
                schemaLocation="UBL-xmldsig-core-schema-2.1.xsd"/>

    <!-- ===== Element Declarations ===== -->
    <xsd:element name="SignatureInformation"
                 type="SignatureInformationType"/>

    <!-- ===== Type Definitions ===== -->
    <xsd:complexType name="SignatureInformationType">
      ...
      <xsd:sequence>
        ...
        <xsd:element ref="ds:Signature" minOccurs="0" maxOccurs="1">
          <xsd:annotation>
            <xsd:documentation>
              <ccts:Definition>This is a single digital signature as 
defined by the W3C specification.</ccts:Definition>
            </xsd:documentation>
          </xsd:annotation>
        </xsd:element>
      </xsd:sequence>
    </xsd:complexType>
</xsd:schema>


I hope this helps.

. . . . . . . . . . Ken

--
Contact us for world-wide XML consulting and instructor-led training
Free 5-hour lecture: http://www.CraneSoftwrights.com/links/udemy.htm
Crane Softwrights Ltd.            http://www.CraneSoftwrights.com/z/
G. Ken Holman                   mailto:gkholman at CraneSoftwrights.com
Google+ profile: https://plus.google.com/116832879756988317389/about
Legal business disclaimers:    http://www.CraneSoftwrights.com/legal


From simon at josefsson.org  Mon Oct 15 15:23:36 2012
From: simon at josefsson.org (Simon Josefsson)
Date: Tue, 16 Oct 2012 00:23:36 +0200
Subject: [xmlsec] Signature in different namespace
In-Reply-To: <7.0.1.0.2.20121016000456.02475a18@wheresmymailserver.com>
 (G. Ken Holman's message of "Tue, 16 Oct 2012 00:10:30 +0200")
References: <874nlvse4s.fsf@latte.josefsson.org>
 <507C6B62.3010504@aleksey.com> <87zk3nqvc0.fsf@latte.josefsson.org>
 <507C8122.3060101@aleksey.com> <87sj9fqu8i.fsf@latte.josefsson.org>
 <7.0.1.0.2.20121016000456.02475a18@wheresmymailserver.com>
Message-ID: <87fw5fqsrb.fsf@latte.josefsson.org>

"G. Ken Holman" <gkholman at CraneSoftwrights.com> writes:

>        <xsd:element ref="ds:Signature" minOccurs="0" maxOccurs="1">
...
> I hope this helps.

Thank you -- 'ref="ds:Signature"' is used in SAML Assertion as well so
it seems like a good approach.

More insight into this would be appreciated.  Is there any way the RFC
6030 approach could work?  I'm concerned that there is an example in the
RFC that people may have modelled their implementations after.  My
current approach to remove the ds: prefix on the Signature element leads
to valid XML so that workaround would works even if isn't kosher.
Having some pointer to text in the XMLDsig standard explaining that this
is improper would help.

/Simon

From gkholman at CraneSoftwrights.com  Mon Oct 15 15:40:37 2012
From: gkholman at CraneSoftwrights.com (G. Ken Holman)
Date: Tue, 16 Oct 2012 00:40:37 +0200
Subject: [xmlsec] Signature in different namespace
In-Reply-To: <87fw5fqsrb.fsf@latte.josefsson.org>
References: <874nlvse4s.fsf@latte.josefsson.org> <507C6B62.3010504@aleksey.com>
 <87zk3nqvc0.fsf@latte.josefsson.org> <507C8122.3060101@aleksey.com>
 <87sj9fqu8i.fsf@latte.josefsson.org>
 <7.0.1.0.2.20121016000456.02475a18@wheresmymailserver.com>
 <87fw5fqsrb.fsf@latte.josefsson.org>
Message-ID: <7.0.1.0.2.20121016002609.023618a0@wheresmymailserver.com>

At 2012-10-16 00:23 +0200, Simon Josefsson wrote:
>"G. Ken Holman" <gkholman at CraneSoftwrights.com> writes:
>
> >        <xsd:element ref="ds:Signature" minOccurs="0" maxOccurs="1">
>...
> > I hope this helps.
>
>Thank you -- 'ref="ds:Signature"' is used in SAML Assertion as well so
>it seems like a good approach.

Not "good", but correct.  The declaration you showed creates an 
element named "Signature" in the incorrect namespace, not in the 
digital signature namespace.  I believe that example you cite is 
absolutely wrong.

>More insight into this would be appreciated.  Is there any way the RFC
>6030 approach could work?  I'm concerned that there is an example in the
>RFC that people may have modelled their implementations after.  My
>current approach to remove the ds: prefix on the Signature element leads
>to valid XML so that workaround would works even if isn't kosher.

It may be well-formed XML but it isn't valid according to the XMLDsig 
specification.  That specification states that Signature must be in 
the digital signature namespace (the prefix "ds:" is irrelevant; 
"simon:Signature" is schema valid if 
xmlns:simon="http://www.w3.org/2000/09/xmldsig#").  The specification is clear:

  http://www.w3.org/TR/2008/REC-xmldsig-core-20080610/#sec-Signature

... and the spec shows it being declared both with a prefix (in XSD) 
and without a prefix (in DTD).  The prefix is irrelevant.  The 
namespace URI is crucial.

If people don't use XML properly, I can't see why they would expect 
it to work.  This is basic namespace-valid XML stuff.

I have a free video lecture on namespaces (in general, not specific 
to digital signatures) in my XSLT class at:

   http://www.CraneSoftwrights.com/links/udemy-ptux-online.htm
   (54:09 mark of Module 1 Lecture 1 - The XML Family of Recommendations)

>Having some pointer to text in the XMLDsig standard explaining that this
>is improper would help.

Why would a standard describe what is incorrect?  How would it know 
what to put in the list if incorrect things before the standard is 
out in the public being incorrectly used?  Wouldn't having such 
examples lead to confusion if users don't read the document properly 
and start quoting the incorrect examples?  Users should just 
implement it correctly.  It looks like some are already reading not 
reading the document properly.

Please forgive my frustration.  This isn't a fault of XML, it is a 
fault of the people writing incorrect examples.

I hope this has helped.

. . . . . . . . Ken


--
Contact us for world-wide XML consulting and instructor-led training
Free 5-hour lecture: http://www.CraneSoftwrights.com/links/udemy.htm
Crane Softwrights Ltd.            http://www.CraneSoftwrights.com/z/
G. Ken Holman                   mailto:gkholman at CraneSoftwrights.com
Google+ profile: https://plus.google.com/116832879756988317389/about
Legal business disclaimers:    http://www.CraneSoftwrights.com/legal


From simon at josefsson.org  Tue Oct 16 00:53:33 2012
From: simon at josefsson.org (Simon Josefsson)
Date: Tue, 16 Oct 2012 09:53:33 +0200
Subject: [xmlsec] Signature in different namespace
In-Reply-To: <7.0.1.0.2.20121016002609.023618a0@wheresmymailserver.com>
 (G. Ken Holman's message of "Tue, 16 Oct 2012 00:40:37 +0200")
References: <874nlvse4s.fsf@latte.josefsson.org>
 <507C6B62.3010504@aleksey.com> <87zk3nqvc0.fsf@latte.josefsson.org>
 <507C8122.3060101@aleksey.com> <87sj9fqu8i.fsf@latte.josefsson.org>
 <7.0.1.0.2.20121016000456.02475a18@wheresmymailserver.com>
 <87fw5fqsrb.fsf@latte.josefsson.org>
 <7.0.1.0.2.20121016002609.023618a0@wheresmymailserver.com>
Message-ID: <87zk3mq2de.fsf@latte.josefsson.org>

Thank you for insight -- I'm not a XML expert so your pointers and
further elaboration helps, and your email will be a good a reference
when this issue with PSKC is brought up in the IETF.

/Simon

"G. Ken Holman" <gkholman at CraneSoftwrights.com> writes:

> At 2012-10-16 00:23 +0200, Simon Josefsson wrote:
>>"G. Ken Holman" <gkholman at CraneSoftwrights.com> writes:
>>
>> >        <xsd:element ref="ds:Signature" minOccurs="0" maxOccurs="1">
>>...
>> > I hope this helps.
>>
>>Thank you -- 'ref="ds:Signature"' is used in SAML Assertion as well so
>>it seems like a good approach.
>
> Not "good", but correct.  The declaration you showed creates an
> element named "Signature" in the incorrect namespace, not in the
> digital signature namespace.  I believe that example you cite is
> absolutely wrong.
>
>>More insight into this would be appreciated.  Is there any way the RFC
>>6030 approach could work?  I'm concerned that there is an example in the
>>RFC that people may have modelled their implementations after.  My
>>current approach to remove the ds: prefix on the Signature element leads
>>to valid XML so that workaround would works even if isn't kosher.
>
> It may be well-formed XML but it isn't valid according to the XMLDsig
> specification.  That specification states that Signature must be in
> the digital signature namespace (the prefix "ds:" is irrelevant;
> "simon:Signature" is schema valid if
> xmlns:simon="http://www.w3.org/2000/09/xmldsig#").  The specification
> is clear:
>
>  http://www.w3.org/TR/2008/REC-xmldsig-core-20080610/#sec-Signature
>
> ... and the spec shows it being declared both with a prefix (in XSD)
> and without a prefix (in DTD).  The prefix is irrelevant.  The
> namespace URI is crucial.
>
> If people don't use XML properly, I can't see why they would expect it
> to work.  This is basic namespace-valid XML stuff.
>
> I have a free video lecture on namespaces (in general, not specific to
> digital signatures) in my XSLT class at:
>
>   http://www.CraneSoftwrights.com/links/udemy-ptux-online.htm
>   (54:09 mark of Module 1 Lecture 1 - The XML Family of Recommendations)
>
>>Having some pointer to text in the XMLDsig standard explaining that this
>>is improper would help.
>
> Why would a standard describe what is incorrect?  How would it know
> what to put in the list if incorrect things before the standard is out
> in the public being incorrectly used?  Wouldn't having such examples
> lead to confusion if users don't read the document properly and start
> quoting the incorrect examples?  Users should just implement it
> correctly.  It looks like some are already reading not reading the
> document properly.
>
> Please forgive my frustration.  This isn't a fault of XML, it is a
> fault of the people writing incorrect examples.
>
> I hope this has helped.
>
> . . . . . . . . Ken
>
>
> --
> Contact us for world-wide XML consulting and instructor-led training
> Free 5-hour lecture: http://www.CraneSoftwrights.com/links/udemy.htm
> Crane Softwrights Ltd.            http://www.CraneSoftwrights.com/z/
> G. Ken Holman                   mailto:gkholman at CraneSoftwrights.com
> Google+ profile: https://plus.google.com/116832879756988317389/about
> Legal business disclaimers:    http://www.CraneSoftwrights.com/legal

From Frederick.Hirsch at nokia.com  Fri Oct 19 14:37:52 2012
From: Frederick.Hirsch at nokia.com (Frederick.Hirsch at nokia.com)
Date: Fri, 19 Oct 2012 21:37:52 +0000
Subject: [xmlsec] Last Call publication of XML Signature 1.1 and XML
	Encryption 1.1
Message-ID: <1CB2E0B458B211478C85E11A404A2B27017DF2B2@008-AM1MPN1-035.mgdnok.nokia.com>

The W3C XML Security working group has published updated working drafts of XML SIgnature 1.1 and XML Encryption 1.1 and is  soliciting comments through 8 November [1].

XML Signature 1.1: http://www.w3.org/TR/2012/WD-xmldsig-core1-20121018/

XML Encryption 1.1: http://www.w3.org/TR/2012/WD-xmlenc-core1-20121018/

The documents were published again as Last Call drafts since some features were removed due to lack of interop testing and some new algorithms were added. Details are in the status section of each document. 

The intent is to progress these documents to recommendation. To clarify the changes since the last recommendation publications, the working group has produced two W3C Notes summarizing the changes:

"Functional Explanation of Changes in XML Signature 1.1" : http://www.w3.org/TR/2012/NOTE-xmldsig-core1-explain-20121018/

"Functional Explanation of Changes in XML Encryption 1.1" :  http://www.w3.org/TR/2012/NOTE-xmlenc-core1-explain-20121018/

Please share any comment on the public XML Security WG list as noted in the documents.

Thanks

regards, Frederick

Frederick Hirsch, Nokia
Chair XML Security WG

[1] http://www.w3.org/News/2012#entry-9603





From Frederick.Hirsch at nokia.com  Fri Oct 19 14:58:59 2012
From: Frederick.Hirsch at nokia.com (Frederick.Hirsch at nokia.com)
Date: Fri, 19 Oct 2012 21:58:59 +0000
Subject: [xmlsec] Interested in review and implementation of XML Signature
 2.0, Canonical XML 2.0, Streaming Profile of XPath 1.0?
Message-ID: <1CB2E0B458B211478C85E11A404A2B27017DF468@008-AM1MPN1-035.mgdnok.nokia.com>

The W3C XML Security working group [1] has been working on a version 2.0 of XML Signature,  Canonical XML and XPath  that offers performance, usability and other improvements. We have a set of draft specifications, including requirements,  [2] that have received working group  review. We are seeking those interested in further review and implementation.

Although much interest in information representation in protocols appears to have moved toward JSON, I believe XML remains very relevant to document-based use cases.  The Canonicalization 2.0 specification may also be of interest in other contexts apart from XML Signature 2.0.

Review comments may be sent to the mail list noted in the drafts. If you are interested in interop participation please let me know.

The editors drafts in the first column have additional updates subsequent to the latest publications.

Thanks

regards, Frederick

Frederick Hirsch, Nokia
Chair XML Security WG

[1] http://www.w3.org/2008/xmlsec/

[2] http://www.w3.org/2008/xmlsec/wiki/PublicationStatus#XML_Security_2.0_publications





From nenjeb at gmail.com  Fri Oct 26 00:06:13 2012
From: nenjeb at gmail.com (Nenad Jebiv)
Date: Fri, 26 Oct 2012 09:06:13 +0200
Subject: [xmlsec] Id attribute
In-Reply-To: <CAAX1EaoSekEAtXc5KPnh9jpsh3EK58A5wjGpwzBp7Bk5zWH_Gw@mail.gmail.com>
References: <CAAX1EaoSekEAtXc5KPnh9jpsh3EK58A5wjGpwzBp7Bk5zWH_Gw@mail.gmail.com>
Message-ID: <CAAX1Ear04KBkWzEzhNk3UsJpQuN5z9vGEQ8hgjvTe235AAT34w@mail.gmail.com>

Hi Aleksey,

I'm using xmlsec downloaded from Zlatkovic's page on Win7/64 bit

I have problem to sign some xml (in attachement) from command line.

xmlsec --sign --id-attr:Id signXmlId --output.xml --pkcs12 cert.pfx --pwd
pwd input.xml
returns
expr=xpointer(id('signXmlId'))

xmlsec --sign --id-attr:Id RacunZahtjev --output.xml --pkcs12 cert.pfx
--pwd pwd input.xml
signs xml but output.xml does not have valid signature.

Certificate is tested with another tool and it's working fine on same xml.

Please can you tell me what I'm missing.

BR
Nenad

PS: Please don't point me to FAQ section 3.2 if possible :-)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.aleksey.com/pipermail/xmlsec/attachments/20121026/ce95de1e/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: input.xml
Type: text/xml
Size: 2711 bytes
Desc: not available
URL: <http://www.aleksey.com/pipermail/xmlsec/attachments/20121026/ce95de1e/attachment.xml>

From aleksey at aleksey.com  Fri Oct 26 07:01:56 2012
From: aleksey at aleksey.com (Aleksey Sanin)
Date: Fri, 26 Oct 2012 07:01:56 -0700
Subject: [xmlsec] Id attribute
In-Reply-To: <CAAX1Ear04KBkWzEzhNk3UsJpQuN5z9vGEQ8hgjvTe235AAT34w@mail.gmail.com>
References: <CAAX1EaoSekEAtXc5KPnh9jpsh3EK58A5wjGpwzBp7Bk5zWH_Gw@mail.gmail.com>
 <CAAX1Ear04KBkWzEzhNk3UsJpQuN5z9vGEQ8hgjvTe235AAT34w@mail.gmail.com>
Message-ID: <508A97D4.7080808@aleksey.com>

Well, you have namespaces so it complicates things a little:

--id-attr[:<attr-name>] [<node-namespace-uri>:]<node-name>

so you need to have something like this in the command line:

--id-attr:Id http://www.apis-it.hr/fin/2012/types/f73:RacunZahtjev


Aleksey

On 10/26/12 12:06 AM, Nenad Jebiv wrote:
> 
> Hi Aleksey,
> 
> I'm using xmlsec downloaded from Zlatkovic's page on Win7/64 bit
> 
> I have problem to sign some xml (in attachement) from command line.
> 
> xmlsec --sign --id-attr:Id signXmlId --output.xml --pkcs12 cert.pfx
> --pwd pwd input.xml
> returns 
> expr=xpointer(id('signXmlId'))
> 
> xmlsec --sign --id-attr:Id RacunZahtjev --output.xml --pkcs12 cert.pfx
> --pwd pwd input.xml
> signs xml but output.xml does not have valid signature.
> 
> Certificate is tested with another tool and it's working fine on same xml.
> 
> Please can you tell me what I'm missing.
> 
> BR
> Nenad
> 
> PS: Please don't point me to FAQ section 3.2 if possible :-)
> 
> 
> 
> _______________________________________________
> xmlsec mailing list
> xmlsec at aleksey.com
> http://www.aleksey.com/mailman/listinfo/xmlsec
> 

From aedelatorre at gmail.com  Sat Nov  3 07:07:21 2012
From: aedelatorre at gmail.com (Alfredo Esteban)
Date: Sat, 3 Nov 2012 15:07:21 +0100
Subject: [xmlsec]  Signing and verifying a XAdES template
Message-ID: <CAKZ=RP8CHxS0sXAOowB=bg606ZGwgOE2Qbf9uyA19ssMaPd-jg@mail.gmail.com>

Hello,

I was verifying whether xmlsec supports XAdES signature (Does it?). As
you probably know, XAdES is an European extension of XMLsign.

I'm able to sign the attached XAdES template without errors but
xmlsec1 is not able to verify its own resulting signature:

> xmlsec1 --version
xmlsec1 1.2.18 (openssl)

> xmlsec1 sign --pkcs12 ../../certificado-ceres-alfredo-esteban.p12 --output hola.xsig --pwd xxxxxxxxxxxxx ejemplo-xades-enveloped.xml

> xmlsec1 verify --trusted-der aet-cert.der ejemplo-xades-enveloped.xsig func=xmlSecOpenSSLEvpDigestVerify:file=digests.c:line=229:obj=sha1:subj=unknown:error=12:invalid data:data and digest do not match
FAIL
SignedInfo References (ok/all): 1/2
Manifests References (ok/all): 0/0
Error: failed to verify file "ejemplo-xades-enveloped.xsig"

Is it a bug? Any help is welcome.

Thanks,

Alfredo
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ejemplo-xades-enveloped.xml
Type: text/xml
Size: 3467 bytes
Desc: not available
URL: <http://www.aleksey.com/pipermail/xmlsec/attachments/20121103/1d65c986/attachment.xml>

From gkholman at CraneSoftwrights.com  Sat Nov  3 11:13:43 2012
From: gkholman at CraneSoftwrights.com (G. Ken Holman)
Date: Sat, 03 Nov 2012 14:13:43 -0400
Subject: [xmlsec] Signing and verifying a XAdES template
In-Reply-To: <CAKZ=RP8CHxS0sXAOowB=bg606ZGwgOE2Qbf9uyA19ssMaPd-jg@mail.g
 mail.com>
References: <CAKZ=RP8CHxS0sXAOowB=bg606ZGwgOE2Qbf9uyA19ssMaPd-jg@mail.gmail.com>
Message-ID: <7.0.1.0.2.20121103140153.02355548@wheresmymailserver.com>

At 2012-11-03 15:07 +0100, Alfredo Esteban wrote:
>Hello,
>
>I was verifying whether xmlsec supports XAdES signature (Does it?). As
>you probably know, XAdES is an European extension of XMLsign.
>
>I'm able to sign the attached XAdES template without errors but
>xmlsec1 is not able to verify its own resulting signature:
>
> > xmlsec1 --version
>xmlsec1 1.2.18 (openssl)
>
> > xmlsec1 sign --pkcs12 ../../certificado-ceres-alfredo-esteban.p12 
> --output hola.xsig --pwd xxxxxxxxxxxxx ejemplo-xades-enveloped.xml
>
> > xmlsec1 verify --trusted-der aet-cert.der 
> ejemplo-xades-enveloped.xsig 
> func=xmlSecOpenSSLEvpDigestVerify:file=digests.c:line=229:obj=sha1:subj=unknown:error=12:invalid 
> data:data and digest do not match
>FAIL
>SignedInfo References (ok/all): 1/2
>Manifests References (ok/all): 0/0
>Error: failed to verify file "ejemplo-xades-enveloped.xsig"
>
>Is it a bug? Any help is welcome.

I think not.  I think it is an issue with your signature.

I designed the XML scaffolding for OASIS UBL documents and I'm told 
there are a number of users of XAdES in Europe who are signing UBL 
documents using it.  An example is found here, and you can see a 
couple of XAdES fields under the ds:Object element:

  http://docs.oasis-open.org/ubl/prd2-UBL-2.1/xml/UBL-Invoice-2.0-Enveloped.xml

I used xmlsec to sign and validate this document.  The environment 
that I publish to sign and to validate UBL documents can be found here:

  http://www.CraneSoftwrights.com/resources/ubl/#digsig

Looking at the example UBL Invoice cited above, comparing it to the 
document you attached to your post, I note that the UBL document has 
a <ds:Transform> element that tells the processor to ignore 
everything under <sig:UBLDocumentSignatures> when calculating the 
signature.  Thus, when the signature information is added by the 
signing process under the <sig:UBLDocumentSignatures> element, that 
added information does not change what is calculated to determine the 
signature information at validation time.

If I've interpreted your situation correctly, the process that is 
calculating the signature for your XML is signing the entire 
document, and then you go and change what is signed by adding the 
signature information to the document without protecting it.  When 
the signature validation process acts on your document, it now 
contains the signature information which gets incorporated in the 
calculations and will never be correct.

If, however, you included a <ds:Transform> element in your document 
in order to protect the signing process from incorporating the added 
signature, then the validation process will ignore the added 
signature and come to the same calculations as the signing process.

At least that is what I think is going on.

I hope this helps.

. . . . . . . . . Ken


--
Contact us for world-wide XML consulting and instructor-led training
Free 5-hour lecture: http://www.CraneSoftwrights.com/links/udemy.htm
Crane Softwrights Ltd.            http://www.CraneSoftwrights.com/z/
G. Ken Holman                   mailto:gkholman at CraneSoftwrights.com
Google+ profile: https://plus.google.com/116832879756988317389/about
Legal business disclaimers:    http://www.CraneSoftwrights.com/legal


From aedelatorre at gmail.com  Sun Nov  4 12:29:11 2012
From: aedelatorre at gmail.com (Alfredo Esteban)
Date: Sun, 4 Nov 2012 21:29:11 +0100
Subject: [xmlsec] Signing and verifying a XAdES template
In-Reply-To: <7.0.1.0.2.20121103140153.02355548@wheresmymailserver.com>
References: <CAKZ=RP8CHxS0sXAOowB=bg606ZGwgOE2Qbf9uyA19ssMaPd-jg@mail.gmail.com>
 <7.0.1.0.2.20121103140153.02355548@wheresmymailserver.com>
Message-ID: <CAKZ=RP_R1MLdwqDS_6zfq-wXaXYV41OjS3r11ngp3VX93pjwdQ@mail.gmail.com>

Hello Ken,

Thanks a lot for your help. I will study the UBL example, modify mine
and write here the results.

Alfredo

2012/11/3 G. Ken Holman <gkholman at cranesoftwrights.com>:
> At 2012-11-03 15:07 +0100, Alfredo Esteban wrote:
>>
>> Hello,
>>
>> I was verifying whether xmlsec supports XAdES signature (Does it?). As
>> you probably know, XAdES is an European extension of XMLsign.
>>
>> I'm able to sign the attached XAdES template without errors but
>> xmlsec1 is not able to verify its own resulting signature:
>>
>> > xmlsec1 --version
>> xmlsec1 1.2.18 (openssl)
>>
>> > xmlsec1 sign --pkcs12 ../../certificado-ceres-alfredo-esteban.p12
>> > --output hola.xsig --pwd xxxxxxxxxxxxx ejemplo-xades-enveloped.xml
>>
>> > xmlsec1 verify --trusted-der aet-cert.der ejemplo-xades-enveloped.xsig
>> > func=xmlSecOpenSSLEvpDigestVerify:file=digests.c:line=229:obj=sha1:subj=unknown:error=12:invalid
>> > data:data and digest do not match
>> FAIL
>> SignedInfo References (ok/all): 1/2
>> Manifests References (ok/all): 0/0
>> Error: failed to verify file "ejemplo-xades-enveloped.xsig"
>>
>> Is it a bug? Any help is welcome.
>
>
> I think not.  I think it is an issue with your signature.
>
> I designed the XML scaffolding for OASIS UBL documents and I'm told there
> are a number of users of XAdES in Europe who are signing UBL documents using
> it.  An example is found here, and you can see a couple of XAdES fields
> under the ds:Object element:
>
>
> http://docs.oasis-open.org/ubl/prd2-UBL-2.1/xml/UBL-Invoice-2.0-Enveloped.xml
>
> I used xmlsec to sign and validate this document.  The environment that I
> publish to sign and to validate UBL documents can be found here:
>
>  http://www.CraneSoftwrights.com/resources/ubl/#digsig
>
> Looking at the example UBL Invoice cited above, comparing it to the document
> you attached to your post, I note that the UBL document has a <ds:Transform>
> element that tells the processor to ignore everything under
> <sig:UBLDocumentSignatures> when calculating the signature.  Thus, when the
> signature information is added by the signing process under the
> <sig:UBLDocumentSignatures> element, that added information does not change
> what is calculated to determine the signature information at validation
> time.
>
> If I've interpreted your situation correctly, the process that is
> calculating the signature for your XML is signing the entire document, and
> then you go and change what is signed by adding the signature information to
> the document without protecting it.  When the signature validation process
> acts on your document, it now contains the signature information which gets
> incorporated in the calculations and will never be correct.
>
> If, however, you included a <ds:Transform> element in your document in order
> to protect the signing process from incorporating the added signature, then
> the validation process will ignore the added signature and come to the same
> calculations as the signing process.
>
> At least that is what I think is going on.
>
> I hope this helps.
>
> . . . . . . . . . Ken
>
>
> --
> Contact us for world-wide XML consulting and instructor-led training
> Free 5-hour lecture: http://www.CraneSoftwrights.com/links/udemy.htm
> Crane Softwrights Ltd.            http://www.CraneSoftwrights.com/z/
> G. Ken Holman                   mailto:gkholman at CraneSoftwrights.com
> Google+ profile: https://plus.google.com/116832879756988317389/about
> Legal business disclaimers:    http://www.CraneSoftwrights.com/legal
>
> _______________________________________________
> xmlsec mailing list
> xmlsec at aleksey.com
> http://www.aleksey.com/mailman/listinfo/xmlsec

From partridgeb at vmware.com  Mon Nov  5 10:26:14 2012
From: partridgeb at vmware.com (Brian Partridge)
Date: Mon, 5 Nov 2012 10:26:14 -0800 (PST)
Subject: [xmlsec] Clang/LLVM instead of GCC
In-Reply-To: <362985137.12494084.1352135462704.JavaMail.root@vmware.com>
Message-ID: <654103805.12644298.1352139973967.JavaMail.root@vmware.com>

Hi All, 
I'm drudging up the old topic about getting xmlsec building for iOS, it looks like this was discussed in late 2011, but there is a new caveat. Building for iOS now needs to support the armv7s architechture, and this can only be generated when compiled with Clang/LLVM on OSX. 


I don't know the intimate details of building a configure script, but I do see that in the xmlsec configure script that there are plenty of gcc specific areas in it. I was wondering if anyone has been looking at what it would take to build xmlsec with LLVM, or if anyone could point me in the right direction to update the configure script to work with LLVM. Thanks. 


-- 
Brian Partridge 
partridgeb at vmware.com 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.aleksey.com/pipermail/xmlsec/attachments/20121105/d4ec2a6c/attachment.html>

From aedelatorre at gmail.com  Sat Nov 10 17:06:09 2012
From: aedelatorre at gmail.com (Alfredo Esteban)
Date: Sun, 11 Nov 2012 02:06:09 +0100
Subject: [xmlsec] Signing and verifying a XAdES template
In-Reply-To: <CAKZ=RP_R1MLdwqDS_6zfq-wXaXYV41OjS3r11ngp3VX93pjwdQ@mail.gmail.com>
References: <CAKZ=RP8CHxS0sXAOowB=bg606ZGwgOE2Qbf9uyA19ssMaPd-jg@mail.gmail.com>
 <7.0.1.0.2.20121103140153.02355548@wheresmymailserver.com>
 <CAKZ=RP_R1MLdwqDS_6zfq-wXaXYV41OjS3r11ngp3VX93pjwdQ@mail.gmail.com>
Message-ID: <CAKZ=RP-L-MbpF-4U38KpkpgSWrQwAwyTjspQ0tKqTUXiPLsstQ@mail.gmail.com>

Hello,

Ken was right. I fixed the problem adding transform nodes. But this is not
a XAdES signature yet. I'm workint on it.

I'm attaching the resulting xml. I can sign and verify it using xmlsec.

Alfredo


2012/11/4 Alfredo Esteban <aedelatorre at gmail.com>

> Hello Ken,
>
> Thanks a lot for your help. I will study the UBL example, modify mine
> and write here the results.
>
> Alfredo
>
> 2012/11/3 G. Ken Holman <gkholman at cranesoftwrights.com>:
> > At 2012-11-03 15:07 +0100, Alfredo Esteban wrote:
> >>
> >> Hello,
> >>
> >> I was verifying whether xmlsec supports XAdES signature (Does it?). As
> >> you probably know, XAdES is an European extension of XMLsign.
> >>
> >> I'm able to sign the attached XAdES template without errors but
> >> xmlsec1 is not able to verify its own resulting signature:
> >>
> >> > xmlsec1 --version
> >> xmlsec1 1.2.18 (openssl)
> >>
> >> > xmlsec1 sign --pkcs12 ../../certificado-ceres-alfredo-esteban.p12
> >> > --output hola.xsig --pwd xxxxxxxxxxxxx ejemplo-xades-enveloped.xml
> >>
> >> > xmlsec1 verify --trusted-der aet-cert.der ejemplo-xades-enveloped.xsig
> >> >
> func=xmlSecOpenSSLEvpDigestVerify:file=digests.c:line=229:obj=sha1:subj=unknown:error=12:invalid
> >> > data:data and digest do not match
> >> FAIL
> >> SignedInfo References (ok/all): 1/2
> >> Manifests References (ok/all): 0/0
> >> Error: failed to verify file "ejemplo-xades-enveloped.xsig"
> >>
> >> Is it a bug? Any help is welcome.
> >
> >
> > I think not.  I think it is an issue with your signature.
> >
> > I designed the XML scaffolding for OASIS UBL documents and I'm told there
> > are a number of users of XAdES in Europe who are signing UBL documents
> using
> > it.  An example is found here, and you can see a couple of XAdES fields
> > under the ds:Object element:
> >
> >
> >
> http://docs.oasis-open.org/ubl/prd2-UBL-2.1/xml/UBL-Invoice-2.0-Enveloped.xml
> >
> > I used xmlsec to sign and validate this document.  The environment that I
> > publish to sign and to validate UBL documents can be found here:
> >
> >  http://www.CraneSoftwrights.com/resources/ubl/#digsig
> >
> > Looking at the example UBL Invoice cited above, comparing it to the
> document
> > you attached to your post, I note that the UBL document has a
> <ds:Transform>
> > element that tells the processor to ignore everything under
> > <sig:UBLDocumentSignatures> when calculating the signature.  Thus, when
> the
> > signature information is added by the signing process under the
> > <sig:UBLDocumentSignatures> element, that added information does not
> change
> > what is calculated to determine the signature information at validation
> > time.
> >
> > If I've interpreted your situation correctly, the process that is
> > calculating the signature for your XML is signing the entire document,
> and
> > then you go and change what is signed by adding the signature
> information to
> > the document without protecting it.  When the signature validation
> process
> > acts on your document, it now contains the signature information which
> gets
> > incorporated in the calculations and will never be correct.
> >
> > If, however, you included a <ds:Transform> element in your document in
> order
> > to protect the signing process from incorporating the added signature,
> then
> > the validation process will ignore the added signature and come to the
> same
> > calculations as the signing process.
> >
> > At least that is what I think is going on.
> >
> > I hope this helps.
> >
> > . . . . . . . . . Ken
> >
> >
> > --
> > Contact us for world-wide XML consulting and instructor-led training
> > Free 5-hour lecture: http://www.CraneSoftwrights.com/links/udemy.htm
> > Crane Softwrights Ltd.            http://www.CraneSoftwrights.com/z/
> > G. Ken Holman                   mailto:gkholman at CraneSoftwrights.com
> > Google+ profile: https://plus.google.com/116832879756988317389/about
> > Legal business disclaimers:    http://www.CraneSoftwrights.com/legal
> >
> > _______________________________________________
> > xmlsec mailing list
> > xmlsec at aleksey.com
> > http://www.aleksey.com/mailman/listinfo/xmlsec
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.aleksey.com/pipermail/xmlsec/attachments/20121111/dd02a86a/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ejemplo-xades-enveloped.xml
Type: text/xml
Size: 3709 bytes
Desc: not available
URL: <http://www.aleksey.com/pipermail/xmlsec/attachments/20121111/dd02a86a/attachment.xml>

From lists at correiofacil.com  Sat Nov 17 14:03:55 2012
From: lists at correiofacil.com (Bernardo Hoehl)
Date: Sat, 17 Nov 2012 20:03:55 -0200
Subject: [xmlsec] XMLSEC and Mac Os X
Message-ID: <B6584205-7822-4688-80FC-097B135D318F@correiofacil.com>

Dear friends,


I have used XMLSEC in the past as it was installed in /opt directory using Macports.

I have an xCode project at this moment that needs to sign an XML file, and the command I would use for this would be:

export LD_LIBRARY_PATH=/opt/local/lib; /opt/local/bin/xmlsec1 sign --id-attr:Id infNFe --output /path/to/signed.xml --pkcs12 /path/to/my/p12.pfx --pwd XXXXPASSWORDXXXX --trusted-pem /path/to/my.pem /path/to/unsigned.xml

When installing XMLSEC via Mac Ports, files are linked in /opt directory as you an notice by running the command:

bernardo$  otool -L /opt/local/bin/xmlsec1 
	/opt/local/bin/xmlsec1:
	/opt/local/lib/libxmlsec1.1.dylib (compatibility version 4.0.0, current version 4.13.0)
	/opt/local/lib/libxslt.1.dylib (compatibility version 3.0.0, current version 3.26.0)
	/opt/local/lib/libxml2.2.dylib (compatibility version 10.0.0, current version 10.8.0)
	/opt/local/lib/libz.1.dylib (compatibility version 1.0.0, current version 1.2.5)
	/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 125.2.0)
	/opt/local/lib/libiconv.2.dylib (compatibility version 8.0.0, current version 8.0.0)


Unfortunately Apple demands now that apps must be sandboxed, and so my app does not have access to /opt directory, and I can not install XMLSEC on the users file system.

I have visited http://www.aleksey.com/xmlsec/api/xmlsec-notes-compiling-unix.html,and I find it very hard to understand what I need to do is to bundle XMLSEC into my xCode project, and make XMLSEC run within my sandboxed app.

Can someone please adivise me on the steps I need to take?

Has someone done this before? Can you help me with an xCode sample project that contains XMLSEC?

Thank you very much for reading my email,



Bernardo H?hl
Rio de Janeiro - Brazil

===================================

 

From aleksey at aleksey.com  Sat Nov 17 21:33:19 2012
From: aleksey at aleksey.com (Aleksey Sanin)
Date: Sat, 17 Nov 2012 21:33:19 -0800
Subject: [xmlsec] XMLSEC and Mac Os X
In-Reply-To: <B6584205-7822-4688-80FC-097B135D318F@correiofacil.com>
References: <B6584205-7822-4688-80FC-097B135D318F@correiofacil.com>
Message-ID: <50A8731F.8080301@aleksey.com>

Hi Bernardo,

To compile xmlsec in xcode you need to build it as a static library.
Simply add all the source files, include/lib paths to dependencies
(libxml2, openssl, etc.) and that's pretty much it. I don't have
an xcode project I can share but it was really simple to do.

Best,

Aleksey

On 11/17/12 2:03 PM, Bernardo Hoehl wrote:
> Dear friends,
> 
> 
> I have used XMLSEC in the past as it was installed in /opt directory using Macports.
> 
> I have an xCode project at this moment that needs to sign an XML file, and the command I would use for this would be:
> 
> export LD_LIBRARY_PATH=/opt/local/lib; /opt/local/bin/xmlsec1 sign --id-attr:Id infNFe --output /path/to/signed.xml --pkcs12 /path/to/my/p12.pfx --pwd XXXXPASSWORDXXXX --trusted-pem /path/to/my.pem /path/to/unsigned.xml
> 
> When installing XMLSEC via Mac Ports, files are linked in /opt directory as you an notice by running the command:
> 
> bernardo$  otool -L /opt/local/bin/xmlsec1 
> 	/opt/local/bin/xmlsec1:
> 	/opt/local/lib/libxmlsec1.1.dylib (compatibility version 4.0.0, current version 4.13.0)
> 	/opt/local/lib/libxslt.1.dylib (compatibility version 3.0.0, current version 3.26.0)
> 	/opt/local/lib/libxml2.2.dylib (compatibility version 10.0.0, current version 10.8.0)
> 	/opt/local/lib/libz.1.dylib (compatibility version 1.0.0, current version 1.2.5)
> 	/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 125.2.0)
> 	/opt/local/lib/libiconv.2.dylib (compatibility version 8.0.0, current version 8.0.0)
> 
> 
> Unfortunately Apple demands now that apps must be sandboxed, and so my app does not have access to /opt directory, and I can not install XMLSEC on the users file system.
> 
> I have visited http://www.aleksey.com/xmlsec/api/xmlsec-notes-compiling-unix.html,and I find it very hard to understand what I need to do is to bundle XMLSEC into my xCode project, and make XMLSEC run within my sandboxed app.
> 
> Can someone please adivise me on the steps I need to take?
> 
> Has someone done this before? Can you help me with an xCode sample project that contains XMLSEC?
> 
> Thank you very much for reading my email,
> 
> 
> 
> Bernardo H?hl
> Rio de Janeiro - Brazil
> 
> ===================================
> 
>  
> _______________________________________________
> xmlsec mailing list
> xmlsec at aleksey.com
> http://www.aleksey.com/mailman/listinfo/xmlsec
> 

From timtas at cubic.ch  Tue Nov 20 03:38:58 2012
From: timtas at cubic.ch (Tim Tassonis)
Date: Tue, 20 Nov 2012 12:38:58 +0100
Subject: [xmlsec] Trouble signing message with
 xmlSecTmplReferenceAddTransform type xmlSecTransformExclC14NId
Message-ID: <50AB6BD2.70701@cubic.ch>

Hello List

I have to create a signed soap message to an application that expects a 
reference with transport xmlSecTransformExclC14NId and not enveloped 
transport.

I always get an error "invalid data:data and digest do not match".

What I did was:

signNode = xmlSecTmplSignatureCreateNsPref(doc, \
                                            xmlSecTransformExclC14NId, \
                                            xmlSecTransformRsaSha1Id, \
                                            NULL, \
                                            "ds");

xmlAddChild(xmlDocGetRootElement(doc), signNode);

refNode = xmlSecTmplSignatureAddReference(signNode, \
                                           xmlSecTransformSha512Id, \
                                           NULL, \
                                           NULL, \
                                           NULL);

xmlSecTmplReferenceAddTransform(refNode,xmlSecTransformExclC14NId);

/*
xmlSecTmplReferenceAddTransform(refNode,xmlSecTransformEnvelopedId);
*/

keyInfoNode = xmlSecTmplSignatureEnsureKeyInfo(signNode, NULL);

xmlSecTmplKeyInfoAddX509Data(keyInfoNode);

dsigCtx = xmlSecDSigCtxCreate(NULL);
dsigCtx->signKey = xmlSecCryptoAppKeyLoad(key_file, \
                                           xmlSecKeyDataFormatPem, \
                                           key_pass, \
                                           NULL, \
                                           NULL);
xmlSecCryptoAppKeyCertLoad(dsigCtx->signKey,crt_file,xmlSecKeyDataFormatPem);

xmlSecKeySetName(dsigCtx->signKey, "private.key");

xmlSecDSigCtxSign(dsigCtx, signNode);

(I do originally have all the checks for success of the operations in 
place, I just removed them for brevity of this mail).


If I change xmlSecTransformExclC14NId to xmlSecTransformEnvelopedId in 
xmlSecTmplReferenceAddTransform, verify3 reports success (but my 
application doesn't accept it), but otherwise both verify3 and the 
application report "invalid data:data and digest do not match".

What am I doing wrong here?


Kind regards
Tim

From mpeat at unicorninterglobal.com  Tue Nov 20 08:49:34 2012
From: mpeat at unicorninterglobal.com (Mike Peat)
Date: Tue, 20 Nov 2012 16:49:34 +0000
Subject: [xmlsec] Problem with xmlsec configure
Message-ID: <50ABB49E.1040909@unicorninterglobal.com>

Hi

I am having a stupid problem configuring my build of xmlsec.  Having got 
all of the other libraries (libiconv, openssl, zlib, libxml2 and 
libxslt) to build OK (I think/hope), the xmlsec ./configure can't seem 
to find libxslt, although it finds libxml2 OK:

$ ./configure --prefix=/projects/xmlsec/xmlsec1-1.2.18 \
         --with-openssl=/projects/xmlsec/openssl-1.0.1c \
         --with-libxml=/projects/xmlsec/libxml2-2.9.0 \
         --with-libxslt=/projects/xmlsec/libxslt-1.1.27

Produces, after a bit:

...
checking for xml2-config... /projects/xmlsec/libxml2-2.9.0/bin/xml2-config
checking libxml2 /projects/xmlsec/libxml2-2.9.0/bin/xml2-config ... yes 
('2.9.0')
checking for xslt-config... no
checking for libxslt libraries >= 1.0.20... configure: error: Unable to 
find libxslt at '/projects/xmlsec/libxslt-1.1.27'

But:

$ ls -l /projects/xmlsec/libxslt-1.1.27/xslt-config
-rwxr-xr-x 1 mike Administrators 2537 Nov 19 18:57 
/projects/xmlsec/libxslt-1.1.27/xslt-config

I am a bit baffled... looking through the code in the xmlsec "configure" 
I am having trouble spotting exactly what it is that it is looking for 
but not finding. Has anyone any helpful thoughts about what I am doing 
wrong?

TIA

Mike Peat

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.aleksey.com/pipermail/xmlsec/attachments/20121120/6c6516cc/attachment.html>

From mpeat at unicorninterglobal.com  Wed Nov 21 02:09:15 2012
From: mpeat at unicorninterglobal.com (Mike Peat)
Date: Wed, 21 Nov 2012 10:09:15 +0000
Subject: [xmlsec] Problem with xmlsec configure
In-Reply-To: <50ABB49E.1040909@unicorninterglobal.com>
References: <50ABB49E.1040909@unicorninterglobal.com>
Message-ID: <50ACA84B.4060003@unicorninterglobal.com>

On 20/11/2012 16:49, Mike Peat wrote:
> Hi
>
> I am having a stupid problem configuring my build of xmlsec. Having 
> got all of the other libraries (libiconv, openssl, zlib, libxml2 and 
> libxslt) to build OK (I think/hope), the xmlsec ./configure can't seem 
> to find libxslt, although it finds libxml2 OK:
>
> $ ./configure --prefix=/projects/xmlsec/xmlsec1-1.2.18 \
>         --with-openssl=/projects/xmlsec/openssl-1.0.1c \
>         --with-libxml=/projects/xmlsec/libxml2-2.9.0 \
>         --with-libxslt=/projects/xmlsec/libxslt-1.1.27
>
> Produces, after a bit:
>
> ...
> checking for xml2-config... /projects/xmlsec/libxml2-2.9.0/bin/xml2-config
> checking libxml2 /projects/xmlsec/libxml2-2.9.0/bin/xml2-config ... 
> yes ('2.9.0')
> checking for xslt-config... no
> checking for libxslt libraries >= 1.0.20... configure: error: Unable 
> to find libxslt at '/projects/xmlsec/libxslt-1.1.27'
>
> But:
>
> $ ls -l /projects/xmlsec/libxslt-1.1.27/xslt-config
> -rwxr-xr-x 1 mike Administrators 2537 Nov 19 18:57 
> /projects/xmlsec/libxslt-1.1.27/xslt-config
>
> I am a bit baffled... looking through the code in the xmlsec 
> "configure" I am having trouble spotting exactly what it is that it is 
> looking for but not finding. Has anyone any helpful thoughts about 
> what I am doing wrong?
>
> TIA
>
> Mike Peat
>
I have now found that copying xslt-config from its "natural" location in 
/projects/xmlsec/libxslt-1.1.27 to /projects/xmlsec/xmlsec1-1.2.18 (the 
build directory) seems to work around the problem.

I /may/ try modifying the configure script to address this - does 
anybody have any thoughts?

Mike

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.aleksey.com/pipermail/xmlsec/attachments/20121121/5f4d373b/attachment.html>

From aleksey at aleksey.com  Wed Nov 21 06:11:14 2012
From: aleksey at aleksey.com (Aleksey Sanin)
Date: Wed, 21 Nov 2012 06:11:14 -0800
Subject: [xmlsec] Trouble signing message with
 xmlSecTmplReferenceAddTransform type xmlSecTransformExclC14NId
In-Reply-To: <50AB6BD2.70701@cubic.ch>
References: <50AB6BD2.70701@cubic.ch>
Message-ID: <50ACE102.5020807@aleksey.com>

You probably want *both* enveloped and exclC14N transforms. Otherwise,
you will be modifying the signed data when you add signature and this
is why you get the digest mismatch error.

Best,

Aleksey

On 11/20/12 3:38 AM, Tim Tassonis wrote:
> Hello List
> 
> I have to create a signed soap message to an application that expects a
> reference with transport xmlSecTransformExclC14NId and not enveloped
> transport.
> 
> I always get an error "invalid data:data and digest do not match".
> 
> What I did was:
> 
> signNode = xmlSecTmplSignatureCreateNsPref(doc, \
>                                            xmlSecTransformExclC14NId, \
>                                            xmlSecTransformRsaSha1Id, \
>                                            NULL, \
>                                            "ds");
> 
> xmlAddChild(xmlDocGetRootElement(doc), signNode);
> 
> refNode = xmlSecTmplSignatureAddReference(signNode, \
>                                           xmlSecTransformSha512Id, \
>                                           NULL, \
>                                           NULL, \
>                                           NULL);
> 
> xmlSecTmplReferenceAddTransform(refNode,xmlSecTransformExclC14NId);
> 
> /*
> xmlSecTmplReferenceAddTransform(refNode,xmlSecTransformEnvelopedId);
> */
> 
> keyInfoNode = xmlSecTmplSignatureEnsureKeyInfo(signNode, NULL);
> 
> xmlSecTmplKeyInfoAddX509Data(keyInfoNode);
> 
> dsigCtx = xmlSecDSigCtxCreate(NULL);
> dsigCtx->signKey = xmlSecCryptoAppKeyLoad(key_file, \
>                                           xmlSecKeyDataFormatPem, \
>                                           key_pass, \
>                                           NULL, \
>                                           NULL);
> xmlSecCryptoAppKeyCertLoad(dsigCtx->signKey,crt_file,xmlSecKeyDataFormatPem);
> 
> 
> xmlSecKeySetName(dsigCtx->signKey, "private.key");
> 
> xmlSecDSigCtxSign(dsigCtx, signNode);
> 
> (I do originally have all the checks for success of the operations in
> place, I just removed them for brevity of this mail).
> 
> 
> If I change xmlSecTransformExclC14NId to xmlSecTransformEnvelopedId in
> xmlSecTmplReferenceAddTransform, verify3 reports success (but my
> application doesn't accept it), but otherwise both verify3 and the
> application report "invalid data:data and digest do not match".
> 
> What am I doing wrong here?
> 
> 
> Kind regards
> Tim
> _______________________________________________
> xmlsec mailing list
> xmlsec at aleksey.com
> http://www.aleksey.com/mailman/listinfo/xmlsec

From aleksey at aleksey.com  Wed Nov 21 06:13:44 2012
From: aleksey at aleksey.com (Aleksey Sanin)
Date: Wed, 21 Nov 2012 06:13:44 -0800
Subject: [xmlsec] Problem with xmlsec configure
In-Reply-To: <50ABB49E.1040909@unicorninterglobal.com>
References: <50ABB49E.1040909@unicorninterglobal.com>
Message-ID: <50ACE198.3040103@aleksey.com>

"--with-XXX" option should be used for *installed* copy of the
dependencies. In your case, it sounds that you are using raw
source tree so you might want to use "--with-XXX-src" option
(note that it exists only for Libxml2/Libxslt).

Aleksey

On 11/20/12 8:49 AM, Mike Peat wrote:
> Hi
> 
> I am having a stupid problem configuring my build of xmlsec.  Having got
> all of the other libraries (libiconv, openssl, zlib, libxml2 and
> libxslt) to build OK (I think/hope), the xmlsec ./configure can't seem
> to find libxslt, although it finds libxml2 OK:
> 
> $ ./configure --prefix=/projects/xmlsec/xmlsec1-1.2.18 \
>         --with-openssl=/projects/xmlsec/openssl-1.0.1c \
>         --with-libxml=/projects/xmlsec/libxml2-2.9.0 \
>         --with-libxslt=/projects/xmlsec/libxslt-1.1.27
> 
> Produces, after a bit:
> 
> ...
> checking for xml2-config... /projects/xmlsec/libxml2-2.9.0/bin/xml2-config
> checking libxml2 /projects/xmlsec/libxml2-2.9.0/bin/xml2-config ... yes
> ('2.9.0')
> checking for xslt-config... no
> checking for libxslt libraries >= 1.0.20... configure: error: Unable to
> find libxslt at '/projects/xmlsec/libxslt-1.1.27'
> 
> But:
> 
> $ ls -l /projects/xmlsec/libxslt-1.1.27/xslt-config
> -rwxr-xr-x 1 mike Administrators 2537 Nov 19 18:57
> /projects/xmlsec/libxslt-1.1.27/xslt-config
> 
> I am a bit baffled... looking through the code in the xmlsec "configure"
> I am having trouble spotting exactly what it is that it is looking for
> but not finding. Has anyone any helpful thoughts about what I am doing
> wrong?
> 
> TIA
> 
> Mike Peat
> 
> 
> 
> _______________________________________________
> xmlsec mailing list
> xmlsec at aleksey.com
> http://www.aleksey.com/mailman/listinfo/xmlsec
> 

From mpeat at unicorninterglobal.com  Wed Nov 21 10:20:46 2012
From: mpeat at unicorninterglobal.com (Mike Peat)
Date: Wed, 21 Nov 2012 18:20:46 +0000
Subject: [xmlsec] Problem with xmlsec configure
In-Reply-To: <50ACE198.3040103@aleksey.com>
References: <50ABB49E.1040909@unicorninterglobal.com>
 <50ACE198.3040103@aleksey.com>
Message-ID: <50AD1B7E.4030700@unicorninterglobal.com>

On 21/11/2012 14:13, Aleksey Sanin wrote:
> "--with-XXX" option should be used for *installed* copy of the
> dependencies. In your case, it sounds that you are using raw
> source tree so you might want to use "--with-XXX-src" option
> (note that it exists only for Libxml2/Libxslt).
>
> Aleksey
>
>
Thanks Aleksey - that fixed /that/ problem! ;-)

Mike
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.aleksey.com/pipermail/xmlsec/attachments/20121121/34caff86/attachment.html>

From kurt at roeckx.be  Sun Nov 25 05:25:24 2012
From: kurt at roeckx.be (Kurt Roeckx)
Date: Sun, 25 Nov 2012 14:25:24 +0100
Subject: [xmlsec] Unable to find key
Message-ID: <20121125132524.GA27293@roeckx.be>

Hi,

I get the following error trying to verify a signature:
func=xmlSecKeysMngrGetKey:file=keys.c:line=1370:obj=unknown:subj=xmlSecKeysMngrFindKey:error=1:xmlsec library function failed: 
func=xmlSecDSigCtxProcessKeyInfoNode:file=xmldsig.c:line=871:obj=unknown:subj=unknown:error=45:key is not found: 
func=xmlSecDSigCtxProcessSignatureNode:file=xmldsig.c:line=565:obj=unknown:subj=xmlSecDSigCtxProcessKeyInfoNode:error=1:xmlsec library function failed: 
func=xmlSecDSigCtxVerify:file=xmldsig.c:line=366:obj=unknown:subj=xmlSecDSigCtxSigantureProcessNode:error=1:xmlsec library function failed: 

It's using X509 certificates.  But instead of adding the cert in
the xml file they put the fingerprint of the cert in KeyName, and
I have the cert locally in PEM format.

So I created a key manager and loaded the cert with
xmlSecCryptoAppKeysMngrCertLoad().  But I think that's why it
can't find the cert because I can't give it the keyname they're
sending.

I don't think I can use xmlSecKeySetName() because it's not
a key.

How can I get this working?


Kurt


From xmlsec at roumenpetrov.info  Sun Nov 25 07:29:36 2012
From: xmlsec at roumenpetrov.info (Roumen Petrov)
Date: Sun, 25 Nov 2012 17:29:36 +0200
Subject: [xmlsec] gnutls signature, x509chain test
Message-ID: <50B23960.9050600@roumenpetrov.info>

Hi Aleksey,

I would like to inform you about some failures in gnutls regression tests.

My previous test is from 2012-09-10 and current from 2012-11-24 after 
upgrade of OS (64-bit platform).

What is different :
- libxml,2 libxslt, libxml extracted from master repository. Builds in 
source tree and with options --...src=path to source
- gcrypt: 1.4.6 -> 1.5.0
- gnutls:  2.10.5 ->  3.0.23

No changes in regression test results for openssl, nss, and gcrypt back 
ends.

For instance aleksey-xmldsig-01/enveloping-rsa-x509chain test now fail 
in my new environment.

Using command line I perform additional tests
- If sing/verify operation is performed with gnutls only, i.e. same as 
in regression test, test fail.
- If sign is from openssl but verify from gnutls test pass.
- Also signature created with gnutls cannot be verified by openssl.
So I think that failure is from gnutls but I cannot confirm.

Regards,
Roumen


From aleksey at aleksey.com  Sun Nov 25 09:36:31 2012
From: aleksey at aleksey.com (Aleksey Sanin)
Date: Sun, 25 Nov 2012 09:36:31 -0800
Subject: [xmlsec] Unable to find key
In-Reply-To: <20121125132524.GA27293@roeckx.be>
References: <20121125132524.GA27293@roeckx.be>
Message-ID: <50B2571F.4070703@aleksey.com>

Simplest way would probably be to extract the public key from
the certificate using openssl command line tools and then load
it from a PEM file into xmlsec.

Aleksey

On 11/25/12 5:25 AM, Kurt Roeckx wrote:
> Hi,
> 
> I get the following error trying to verify a signature:
> func=xmlSecKeysMngrGetKey:file=keys.c:line=1370:obj=unknown:subj=xmlSecKeysMngrFindKey:error=1:xmlsec library function failed: 
> func=xmlSecDSigCtxProcessKeyInfoNode:file=xmldsig.c:line=871:obj=unknown:subj=unknown:error=45:key is not found: 
> func=xmlSecDSigCtxProcessSignatureNode:file=xmldsig.c:line=565:obj=unknown:subj=xmlSecDSigCtxProcessKeyInfoNode:error=1:xmlsec library function failed: 
> func=xmlSecDSigCtxVerify:file=xmldsig.c:line=366:obj=unknown:subj=xmlSecDSigCtxSigantureProcessNode:error=1:xmlsec library function failed: 
> 
> It's using X509 certificates.  But instead of adding the cert in
> the xml file they put the fingerprint of the cert in KeyName, and
> I have the cert locally in PEM format.
> 
> So I created a key manager and loaded the cert with
> xmlSecCryptoAppKeysMngrCertLoad().  But I think that's why it
> can't find the cert because I can't give it the keyname they're
> sending.
> 
> I don't think I can use xmlSecKeySetName() because it's not
> a key.
> 
> How can I get this working?
> 
> 
> Kurt
> 
> _______________________________________________
> xmlsec mailing list
> xmlsec at aleksey.com
> http://www.aleksey.com/mailman/listinfo/xmlsec
> 

From aleksey at aleksey.com  Sun Nov 25 09:37:45 2012
From: aleksey at aleksey.com (Aleksey Sanin)
Date: Sun, 25 Nov 2012 09:37:45 -0800
Subject: [xmlsec] gnutls signature, x509chain test
In-Reply-To: <50B23960.9050600@roumenpetrov.info>
References: <50B23960.9050600@roumenpetrov.info>
Message-ID: <50B25769.4040403@aleksey.com>

Thanks. What errors do you get? Or is it just tests failure?

Aleksey

On 11/25/12 7:29 AM, Roumen Petrov wrote:
> Hi Aleksey,
> 
> I would like to inform you about some failures in gnutls regression tests.
> 
> My previous test is from 2012-09-10 and current from 2012-11-24 after
> upgrade of OS (64-bit platform).
> 
> What is different :
> - libxml,2 libxslt, libxml extracted from master repository. Builds in
> source tree and with options --...src=path to source
> - gcrypt: 1.4.6 -> 1.5.0
> - gnutls:  2.10.5 ->  3.0.23
> 
> No changes in regression test results for openssl, nss, and gcrypt back
> ends.
> 
> For instance aleksey-xmldsig-01/enveloping-rsa-x509chain test now fail
> in my new environment.
> 
> Using command line I perform additional tests
> - If sing/verify operation is performed with gnutls only, i.e. same as
> in regression test, test fail.
> - If sign is from openssl but verify from gnutls test pass.
> - Also signature created with gnutls cannot be verified by openssl.
> So I think that failure is from gnutls but I cannot confirm.
> 
> Regards,
> Roumen
> 
> _______________________________________________
> xmlsec mailing list
> xmlsec at aleksey.com
> http://www.aleksey.com/mailman/listinfo/xmlsec

From kurt at roeckx.be  Sun Nov 25 11:24:28 2012
From: kurt at roeckx.be (Kurt Roeckx)
Date: Sun, 25 Nov 2012 20:24:28 +0100
Subject: [xmlsec] Unable to find key
In-Reply-To: <50B2571F.4070703@aleksey.com>
References: <20121125132524.GA27293@roeckx.be> <50B2571F.4070703@aleksey.com>
Message-ID: <20121125192428.GA5033@roeckx.be>

On Sun, Nov 25, 2012 at 09:36:31AM -0800, Aleksey Sanin wrote:
> Simplest way would probably be to extract the public key from
> the certificate using openssl command line tools and then load
> it from a PEM file into xmlsec.

So I did openssl x509 with "-noout -pubkey" and stored in
a file.  I loaded that key with xmlSecCryptoAppKeyLoad(),
generated the fingerprint for the cert file and set that
with xmlSecKeySetName().

However the xmlSecDSigCtxVerify() call now gives me:
func=xmlSecOpenSSLEvpSignatureVerify:file=signatures.c:line=346:obj=rsa-sha256:subj=EVP_VerifyFinal:error=18:data do not match:signature do not match

And I'm not sure if I'm doing the correct thing or that it really
failed to verify.

If I understand the message correct, the DigestValue was probably
correct, it's just that the signature didn't verify?  From what I
understand I should be able to verify this with:
openssl dgst -sha256 -verify pubkey.pem -signature sigfile datafile

I already created the pubkey.pem file as before.

I took the SignatureValue and ran "base64 -d" on
that and stored it in the sigfile.  I created what I think
is the canonical version of the xml file, and when I run
dgst I got: "Verification Failure".

Is that the right way to check it using openssl?

I'm starting to get convinced that the file I'm getting
isn't properly signed, or not with the key the claim it's
signed with.


Kurt


From xmlsec at roumenpetrov.info  Sun Nov 25 11:50:31 2012
From: xmlsec at roumenpetrov.info (Roumen Petrov)
Date: Sun, 25 Nov 2012 21:50:31 +0200
Subject: [xmlsec] gnutls signature, x509chain test
In-Reply-To: <50B25769.4040403@aleksey.com>
References: <50B23960.9050600@roumenpetrov.info> <50B25769.4040403@aleksey.com>
Message-ID: <50B27687.8040507@roumenpetrov.info>

Aleksey Sanin wrote:
> Thanks. What errors do you get? Or is it just tests failure?
May be test failure is correct answer. Verify command complain and 
output messages 'Bad signature' (gnutls) or 'signature do not match' 
(openssl) or ...VFY_EndWithSignature:error=4:crypto library function 
failed:error code=-8182;last nss error=-8182 (nss).

File with signature is one and the same with openssl and nss and could 
be verified by openssl, nss and gnutls.
Gnutls produce file without errors but with different signature and 
later other "crypto" complain for invalid signature.

I could test all above outside regression test with attached script 
"test-enveloping-rsa-x509chain.sh".

Roumen
-------------- next part --------------
A non-text attachment was scrubbed...
Name: test-enveloping-rsa-x509chain.sh
Type: application/x-sh
Size: 1089 bytes
Desc: not available
URL: <http://www.aleksey.com/pipermail/xmlsec/attachments/20121125/1dec0700/attachment.sh>

From kurt at roeckx.be  Sun Nov 25 12:20:41 2012
From: kurt at roeckx.be (Kurt Roeckx)
Date: Sun, 25 Nov 2012 21:20:41 +0100
Subject: [xmlsec] Unable to find key
In-Reply-To: <20121125192428.GA5033@roeckx.be>
References: <20121125132524.GA27293@roeckx.be> <50B2571F.4070703@aleksey.com>
 <20121125192428.GA5033@roeckx.be>
Message-ID: <20121125202041.GA10697@roeckx.be>

On Sun, Nov 25, 2012 at 08:24:28PM +0100, Kurt Roeckx wrote:
> I'm starting to get convinced that the file I'm getting
> isn't properly signed, or not with the key the claim it's
> signed with.

I can verify the file I generate myself and sign myself, so
I'll just blame the other side.


Kurt


From aleksey at aleksey.com  Mon Nov 26 10:40:46 2012
From: aleksey at aleksey.com (Aleksey Sanin)
Date: Mon, 26 Nov 2012 10:40:46 -0800
Subject: [xmlsec] Unable to find key
In-Reply-To: <20121125202041.GA10697@roeckx.be>
References: <20121125132524.GA27293@roeckx.be> <50B2571F.4070703@aleksey.com>
 <20121125192428.GA5033@roeckx.be> <20121125202041.GA10697@roeckx.be>
Message-ID: <50B3B7AE.4050306@aleksey.com>

Great. From experience, most likely reasons for that are:
1) Whitespaces and line ends are important in XML (and signatures).
2) C14N is not as easy as it sounds.

Best,

Aleksey

On 11/25/12 12:20 PM, Kurt Roeckx wrote:
> On Sun, Nov 25, 2012 at 08:24:28PM +0100, Kurt Roeckx wrote:
>> I'm starting to get convinced that the file I'm getting
>> isn't properly signed, or not with the key the claim it's
>> signed with.
> 
> I can verify the file I generate myself and sign myself, so
> I'll just blame the other side.
> 
> 
> Kurt
> 

From kurt at roeckx.be  Mon Nov 26 12:06:08 2012
From: kurt at roeckx.be (Kurt Roeckx)
Date: Mon, 26 Nov 2012 21:06:08 +0100
Subject: [xmlsec] Unable to find key
In-Reply-To: <50B3B7AE.4050306@aleksey.com>
References: <20121125132524.GA27293@roeckx.be> <50B2571F.4070703@aleksey.com>
 <20121125192428.GA5033@roeckx.be>
 <20121125202041.GA10697@roeckx.be> <50B3B7AE.4050306@aleksey.com>
Message-ID: <20121126200608.GA18641@roeckx.be>

I'm actually still looking at this, and it seems they have a problem
with the files I generated as well.

The DigestValue seems to be correct.  But the signature seems to
be incorrect for some reason.

I created a canonical version of my xml file, and sha256sum
reports the same as the value in DigestValue.  So I don't think
I'm having problems with things like whitespace in my file.

However when I put the decoded value of the SignatureValue in
a file and try to use openssl dgst to verify the signuatre the
check fails.  I can verify my signed xml file with the library,
so it's making no sense to me at this time.

I can't seem to generate the canonical xml file for the file
they send me.  The sha256sum for the file I generated is wrong,
but the library seems to say it has the correct DigestValue.
So I must be doing something wrong here.


Kurt

On Mon, Nov 26, 2012 at 10:40:46AM -0800, Aleksey Sanin wrote:
> Great. From experience, most likely reasons for that are:
> 1) Whitespaces and line ends are important in XML (and signatures).
> 2) C14N is not as easy as it sounds.
> 
> Best,
> 
> Aleksey
> 
> On 11/25/12 12:20 PM, Kurt Roeckx wrote:
> > On Sun, Nov 25, 2012 at 08:24:28PM +0100, Kurt Roeckx wrote:
> >> I'm starting to get convinced that the file I'm getting
> >> isn't properly signed, or not with the key the claim it's
> >> signed with.
> > 
> > I can verify the file I generate myself and sign myself, so
> > I'll just blame the other side.
> > 
> > 
> > Kurt
> > 
> 

From aleksey at aleksey.com  Mon Nov 26 12:10:29 2012
From: aleksey at aleksey.com (Aleksey Sanin)
Date: Mon, 26 Nov 2012 12:10:29 -0800
Subject: [xmlsec] Unable to find key
In-Reply-To: <20121126200608.GA18641@roeckx.be>
References: <20121125132524.GA27293@roeckx.be> <50B2571F.4070703@aleksey.com>
 <20121125192428.GA5033@roeckx.be> <20121125202041.GA10697@roeckx.be>
 <50B3B7AE.4050306@aleksey.com> <20121126200608.GA18641@roeckx.be>
Message-ID: <50B3CCB5.2080308@aleksey.com>

Try xmlsec with --store-signatures option

Aleksey

On 11/26/12 12:06 PM, Kurt Roeckx wrote:
> I'm actually still looking at this, and it seems they have a problem
> with the files I generated as well.
> 
> The DigestValue seems to be correct.  But the signature seems to
> be incorrect for some reason.
> 
> I created a canonical version of my xml file, and sha256sum
> reports the same as the value in DigestValue.  So I don't think
> I'm having problems with things like whitespace in my file.
> 
> However when I put the decoded value of the SignatureValue in
> a file and try to use openssl dgst to verify the signuatre the
> check fails.  I can verify my signed xml file with the library,
> so it's making no sense to me at this time.
> 
> I can't seem to generate the canonical xml file for the file
> they send me.  The sha256sum for the file I generated is wrong,
> but the library seems to say it has the correct DigestValue.
> So I must be doing something wrong here.
> 
> 
> Kurt
> 
> On Mon, Nov 26, 2012 at 10:40:46AM -0800, Aleksey Sanin wrote:
>> Great. From experience, most likely reasons for that are:
>> 1) Whitespaces and line ends are important in XML (and signatures).
>> 2) C14N is not as easy as it sounds.
>>
>> Best,
>>
>> Aleksey
>>
>> On 11/25/12 12:20 PM, Kurt Roeckx wrote:
>>> On Sun, Nov 25, 2012 at 08:24:28PM +0100, Kurt Roeckx wrote:
>>>> I'm starting to get convinced that the file I'm getting
>>>> isn't properly signed, or not with the key the claim it's
>>>> signed with.
>>>
>>> I can verify the file I generate myself and sign myself, so
>>> I'll just blame the other side.
>>>
>>>
>>> Kurt
>>>
>>

From kurt at roeckx.be  Mon Nov 26 12:40:26 2012
From: kurt at roeckx.be (Kurt Roeckx)
Date: Mon, 26 Nov 2012 21:40:26 +0100
Subject: [xmlsec] Unable to find key
In-Reply-To: <50B3CCB5.2080308@aleksey.com>
References: <20121125132524.GA27293@roeckx.be> <50B2571F.4070703@aleksey.com>
 <20121125192428.GA5033@roeckx.be>
 <20121125202041.GA10697@roeckx.be> <50B3B7AE.4050306@aleksey.com>
 <20121126200608.GA18641@roeckx.be> <50B3CCB5.2080308@aleksey.com>
Message-ID: <20121126204026.GA20959@roeckx.be>

I was a little stupid and tried to verify the same string as the
DigestValue was created over, but of course I had to use the
SignedInfo.  So I can properly verify what I signed myself,
and I'm now pretty sure the problem is all on their end.

Thanks for the help.

Kurt

On Mon, Nov 26, 2012 at 12:10:29PM -0800, Aleksey Sanin wrote:
> Try xmlsec with --store-signatures option
> 
> Aleksey
> 
> On 11/26/12 12:06 PM, Kurt Roeckx wrote:
> > I'm actually still looking at this, and it seems they have a problem
> > with the files I generated as well.
> > 
> > The DigestValue seems to be correct.  But the signature seems to
> > be incorrect for some reason.
> > 
> > I created a canonical version of my xml file, and sha256sum
> > reports the same as the value in DigestValue.  So I don't think
> > I'm having problems with things like whitespace in my file.
> > 
> > However when I put the decoded value of the SignatureValue in
> > a file and try to use openssl dgst to verify the signuatre the
> > check fails.  I can verify my signed xml file with the library,
> > so it's making no sense to me at this time.
> > 
> > I can't seem to generate the canonical xml file for the file
> > they send me.  The sha256sum for the file I generated is wrong,
> > but the library seems to say it has the correct DigestValue.
> > So I must be doing something wrong here.
> > 
> > 
> > Kurt
> > 
> > On Mon, Nov 26, 2012 at 10:40:46AM -0800, Aleksey Sanin wrote:
> >> Great. From experience, most likely reasons for that are:
> >> 1) Whitespaces and line ends are important in XML (and signatures).
> >> 2) C14N is not as easy as it sounds.
> >>
> >> Best,
> >>
> >> Aleksey
> >>
> >> On 11/25/12 12:20 PM, Kurt Roeckx wrote:
> >>> On Sun, Nov 25, 2012 at 08:24:28PM +0100, Kurt Roeckx wrote:
> >>>> I'm starting to get convinced that the file I'm getting
> >>>> isn't properly signed, or not with the key the claim it's
> >>>> signed with.
> >>>
> >>> I can verify the file I generate myself and sign myself, so
> >>> I'll just blame the other side.
> >>>
> >>>
> >>> Kurt
> >>>
> >>
> 

From aleksey at aleksey.com  Mon Nov 26 12:41:29 2012
From: aleksey at aleksey.com (Aleksey Sanin)
Date: Mon, 26 Nov 2012 12:41:29 -0800
Subject: [xmlsec] gnutls signature, x509chain test
In-Reply-To: <50B27687.8040507@roumenpetrov.info>
References: <50B23960.9050600@roumenpetrov.info>
 <50B25769.4040403@aleksey.com> <50B27687.8040507@roumenpetrov.info>
Message-ID: <50B3D3F9.10009@aleksey.com>

After about an hour trying to compile gnutls on the latest Ubuntu 12.10
I have to give up. I'll take a look when I can get gnutls package from
OS itself.

Aleksey

On 11/25/12 11:50 AM, Roumen Petrov wrote:
> Aleksey Sanin wrote:
>> Thanks. What errors do you get? Or is it just tests failure?
> May be test failure is correct answer. Verify command complain and
> output messages 'Bad signature' (gnutls) or 'signature do not match'
> (openssl) or ...VFY_EndWithSignature:error=4:crypto library function
> failed:error code=-8182;last nss error=-8182 (nss).
> 
> File with signature is one and the same with openssl and nss and could
> be verified by openssl, nss and gnutls.
> Gnutls produce file without errors but with different signature and
> later other "crypto" complain for invalid signature.
> 
> I could test all above outside regression test with attached script
> "test-enveloping-rsa-x509chain.sh".
> 
> Roumen

From mpeat at unicorninterglobal.com  Mon Dec 10 02:55:52 2012
From: mpeat at unicorninterglobal.com (Mike Peat)
Date: Mon, 10 Dec 2012 10:55:52 +0000
Subject: [xmlsec]  Problem with xmlsec configure
Message-ID: <50C5BFB8.7030908@unicorninterglobal.com>

Hi

I am trying to build xmlsec using MinGW/MSys. I have built (I think) all 
of the underlying libraries OK:

    OpenSSL: ALL TESTS SUCCESSFUL
    LibXML2: 10 errors over 2,874 tests... but: "those ebcdic tests have 
never worked on Windows"
    LibXSLT: Tests seemed mostly successful - there didn't seem to be a 
summary

I am using the following configure (after a "make clean"):

./configure --prefix=/projects/xmlsec/xmlsec1-1.2.18 \
             --with-libxml-src=/projects/xmlsec/libxml2-2.9.0 \
             --with-libxslt-src=/projects/xmlsec/libxslt-1.1.27 \
             --with-openssl=/projects/xmlsec/openssl-1.0.1c \
             --host=i686-pc-winnt

Note that if I do not use the --host-i686-pc-winnt option I get a rather 
strange error from ./configure:

configure: error: cannot run C compiled programs.
If you meant to cross compile, use `--host'.
See `config.log' for more details

Anyway, that completes OK, then I do:

make

Which eventually throws out:

libtool: link: warning: 
`e:/mingw/bin/../lib/gcc/mingw32/4.6.2/../../..//libltdl
.la' seems to be moved

*** Warning: Trying to link with static lib archive 
/projects/xmlsec/openssl-1.0
.1c/lib/libcrypto.a.
*** I have the capability to make that library automatically link in when
*** you link to this library.  But I can only do this if you have a
*** shared version of the library, which you do not appear to have
*** because the file extensions .a of this argument makes me believe
*** that it is just a static archive that I should not use here.

Followed shortly by:

xmlsec.o: In function `xmlSecAppSignFile':
E:\MinGW\msys\1.0\projects\xmlsec\xmlsec1-1.2.18\apps/xmlsec.c:1250: 
undefined r
eference to `_imp__xmlSecDSigNs'
E:\MinGW\msys\1.0\projects\xmlsec\xmlsec1-1.2.18\apps/xmlsec.c:1250: 
undefined r
eference to `_imp__xmlSecNodeSignature'
xmlsec.o: In function `xmlSecAppVerifyFile':
E:\MinGW\msys\1.0\projects\xmlsec\xmlsec1-1.2.18\apps/xmlsec.c:1312: 
undefined r
eference to `_imp__xmlSecDSigNs'
E:\MinGW\msys\1.0\projects\xmlsec\xmlsec1-1.2.18\apps/xmlsec.c:1312: 
undefined r
eference to `_imp__xmlSecNodeSignature'
xmlsec.o: In function `xmlSecAppEncryptFile':
E:\MinGW\msys\1.0\projects\xmlsec\xmlsec1-1.2.18\apps/xmlsec.c:1618: 
undefined r
eference to `_imp__xmlSecEncNs'
E:\MinGW\msys\1.0\projects\xmlsec\xmlsec1-1.2.18\apps/xmlsec.c:1618: 
undefined r
eference to `_imp__xmlSecNodeEncryptedData'
xmlsec.o: In function `xmlSecAppDecryptFile':
E:\MinGW\msys\1.0\projects\xmlsec\xmlsec1-1.2.18\apps/xmlsec.c:1707: 
undefined r
eference to `_imp__xmlSecEncNs'
E:\MinGW\msys\1.0\projects\xmlsec\xmlsec1-1.2.18\apps/xmlsec.c:1707: 
undefined r
eference to `_imp__xmlSecNodeEncryptedData'
collect2: ld returned 1 exit status
make[2]: *** [xmlsec1.exe] Error 1
make[2]: Leaving directory `/projects/xmlsec/xmlsec1-1.2.18/apps'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory `/projects/xmlsec/xmlsec1-1.2.18'
make: *** [all] Error 2

Now I have built openssl-1.0.1c with the "shared" option passed to its 
"./config" and all appeared to be OK with that.

Adding the --enable-static-linking flag to my ./configure doesn't seem 
to make any difference.

Basically... what am I doing wrong here?

Thanks in advance.

Mike

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.aleksey.com/pipermail/xmlsec/attachments/20121210/627ff9f3/attachment.html>

From xmlsec at roumenpetrov.info  Tue Dec 11 15:51:22 2012
From: xmlsec at roumenpetrov.info (Roumen Petrov)
Date: Wed, 12 Dec 2012 01:51:22 +0200
Subject: [xmlsec] Problem with xmlsec configure
In-Reply-To: <50C5BFB8.7030908@unicorninterglobal.com>
References: <50C5BFB8.7030908@unicorninterglobal.com>
Message-ID: <50C7C6FA.3050705@roumenpetrov.info>

Mike Peat wrote:
> Hi
>
> I am trying to build xmlsec using MinGW/MSys. I have built (I think) 
> all of the underlying libraries OK:
>
>    OpenSSL: ALL TESTS SUCCESSFUL
>    LibXML2: 10 errors over 2,874 tests... but: "those ebcdic tests 
> have never worked on Windows"
Ignore this. It is out of scope
>    LibXSLT: Tests seemed mostly successful - there didn't seem to be a 
> summary
>
> I am using the following configure (after a "make clean"):
>
> ./configure --prefix=/projects/xmlsec/xmlsec1-1.2.18 \
>             --with-libxml-src=/projects/xmlsec/libxml2-2.9.0 \
>             --with-libxslt-src=/projects/xmlsec/libxslt-1.1.27 \
>             --with-openssl=/projects/xmlsec/openssl-1.0.1c \
>             --host=i686-pc-winnt
>
> Note that if I do not use the --host-i686-pc-winnt option I get a 
> rather strange error from ./configure:
You host triplet has to be resolved to prefix of cross compiler and 
--host= is option . Review you output from configure command. For instance
lest see argument i686-mingw32 . Why with this - just because name of my 
cross-compiler is i686-mingw32-gcc.
$ ./config.sub i686-mingw32
i686-pc-mingw32

$ /configure ..... --host=i686-mingw32
checking build system type... x86_64-gnu-linux-gnu
checking host system type... i686-pc-mingw32
...
checking whether make sets $(MAKE)... yes
checking for i686-mingw32-gcc... i686-mingw32-gcc
checking whether the C compiler works... yes
....


> configure: error: cannot run C compiled programs.
> If you meant to cross compile, use `--host'.
> See `config.log' for more details
Please see config.log !

>
> Anyway, that completes OK, then I do:
>
[SNIP]

> Followed shortly by:
>
> xmlsec.o: In function `xmlSecAppSignFile':
> E:\MinGW\msys\1.0\projects\xmlsec\xmlsec1-1.2.18\apps/xmlsec.c:1250: 
> undefined r
> eference to `_imp__xmlSecDSigNs'
So you build is native. Error is not expected .
Skip --host argument. Ensure that you build use mingw compiler not msys 
one.


[SNIP]

> Now I have built openssl-1.0.1c with the "shared" option passed to its 
> "./config" and all appeared to be OK with that.
Not all platforms support mixing static and dynamic libraries.

> Adding the --enable-static-linking flag to my ./configure doesn't seem 
> to make any difference.
>
> Basically... what am I doing wrong here?

Try to build in apps directory (after make clean !) with following :
$ make CPPFLAGS='<YOU_CPPFLAGS> -DXMLSEC_EXPORT_VAR=extern'
Get <YOU_CPPFLAGS> from Makefile.
If xmlsec binary work fine build system could be improved. I mean 
configuration with --enable-static-linking flag. May be binary will be 
linked with static xmlsec libraries and all other as shared .

> Thanks in advance.
> Mike

Regards,
Roumen


From aleksey at aleksey.com  Wed Dec 12 08:21:56 2012
From: aleksey at aleksey.com (Aleksey Sanin)
Date: Wed, 12 Dec 2012 08:21:56 -0800
Subject: [xmlsec] Digital signature
In-Reply-To: <00a301cdd87c$fac59710$f050c530$@hr>
References: <00a301cdd87c$fac59710$f050c530$@hr>
Message-ID: <50C8AF24.1080403@aleksey.com>

Please read FAQ

http://www.aleksey.com/xmlsec/faq.html

Aleksey

On 12/12/12 7:25 AM, Milan Tribuson wrote:
> Hi Aleksey,
> 
>  
> 
> we are trying to create a digital signature for xml invoice in Croatia
> and we can't make it work and we can't get the correct value.
> 
> I've tried using your sign3.py in original and with changes (adding
> refNode.addTransform(xmlsec.transformExclC14NId()) and referencing to
> URI which I can't get to work.
> 
> I can reference to id but URI doesn't work (refNode =
> signNode.addReference(xmlsec.transformSha1Id(), None, "#RacunZahtjev",
> None)), even when I add dsig_ctx.enabledReferenceUris =
> xmlsec.TransformUriTypeAny and
> dsig_ctx.keyInfoReadCtx.retrievalMethodCtx.enabledUris =
> xmlsec.TransformUriTypeAny, I always get an error:
> 
>  
> 
> func=xmlSecXPathDataExecute:file=xpath.c:line=273:obj=unknown:subj=xmlXPtrEval:error=5:libxml2
> library function failed:expr=xpointer(id('RacunZahtjev'))
> 
> func=xmlSecXPathDataListExecute:file=xpath.c:line=356:obj=unknown:subj=xmlSecXPathDataExecute:error=1:xmlsec
> library function failed:
> 
> func=xmlSecTransformXPathExecute:file=xpath.c:line=466:obj=xpointer:subj=xmlSecXPathDataExecute:error=1:xmlsec
> library function failed:
> 
> func=xmlSecTransformDefaultPushXml:file=transforms.c:line=2395:obj=xpointer:subj=xmlSecTransformExecute:error=1:xmlsec
> library function failed:
> 
> func=xmlSecTransformCtxXmlExecute:file=transforms.c:line=1226:obj=unknown:subj=xmlSecTransformPushXml:error=1:xmlsec
> library function failed:transform=xpointer
> 
> func=xmlSecTransformCtxExecute:file=transforms.c:line=1286:obj=unknown:subj=xmlSecTransformCtxXmlExecute:error=1:xmlsec
> library function failed:
> 
> func=xmlSecDSigReferenceCtxProcessNode:file=xmldsig.c:line=1571:obj=unknown:subj=xmlSecTransformCtxExecute:error=1:xmlsec
> library function failed:
> 
> func=xmlSecDSigCtxProcessSignedInfoNode:file=xmldsig.c:line=804:obj=unknown:subj=xmlSecDSigReferenceCtxProcessNode:error=1:xmlsec
> library function failed:node=Reference
> 
> func=xmlSecDSigCtxProcessSignatureNode:file=xmldsig.c:line=547:obj=unknown:subj=xmlSecDSigCtxProcessSignedInfoNode:error=1:xmlsec
> library function failed:
> 
> func=xmlSecDSigCtxSign:file=xmldsig.c:line=303:obj=unknown:subj=xmlSecDSigCtxSigantureProcessNode:error=1:xmlsec
> library function failed:
> 
> Error: signature failed
> 
>  
> 
>  
> 
> My XML looks like:
> 
> <tns:RacunZahtjev Id="RacunZahtjev"
> xmlns:tns="http://www.apis-it.hr/fin/2012/types/f73"
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
> 
>                 <tns:Zaglavlje>
> 
>                               
> <tns:IdPoruke>4ddfcb83-df33-413b-974c-ab90bdb69022</tns:IdPoruke>
> 
>                               
> <tns:DatumVrijeme>12.12.2012T09:56:35</tns:DatumVrijeme>
> 
>                 </tns:Zaglavlje>
> 
>                 <tns:Racun>
> 
>                                <tns:Oib>68111664044</tns:Oib>
> 
>                                <tns:USustPdv>true</tns:USustPdv>
> 
>                               
> <tns:DatVrijeme>12.12.2012T09:56:35</tns:DatVrijeme>
> 
>                                <tns:OznSlijed>P</tns:OznSlijed>
> 
>                                <tns:BrRac>
> 
>                                               
> <tns:BrOznRac>37</tns:BrOznRac>
> 
>                                               
> <tns:OznPosPr>S1</tns:OznPosPr>
> 
>                                               
> <tns:OznNapUr>31</tns:OznNapUr>
> 
>                                </tns:BrRac>
> 
>                                <tns:Pdv>
> 
>                                                <tns:Porez>
> 
>                                                               
> <tns:Stopa>25.00</tns:Stopa>
> 
>                                                               
> <tns:Osnovica>0.64</tns:Osnovica>
> 
>                                                               
> <tns:Iznos>0.16</tns:Iznos>
> 
>                                                </tns:Porez>
> 
>                                </tns:Pdv>
> 
>                                <tns:Pnp/>
> 
>                                <tns:OstaliPor>
> 
>                                                <tns:Porez>
> 
>                                                               
> <tns:Naziv>PNV</tns:Naziv>
> 
>                                                               
> <tns:Stopa>10.00</tns:Stopa>
> 
>                                                               
> <tns:Osnovica>0.64</tns:Osnovica>
> 
>                                                               
> <tns:Iznos>0.06</tns:Iznos>
> 
>                                                </tns:Porez>
> 
>                                </tns:OstaliPor>
> 
>                                <tns:IznosUkupno>0.86</tns:IznosUkupno>
> 
>                                <tns:NacinPlac>G</tns:NacinPlac>
> 
>                                <tns:OibOper>66666666666</tns:OibOper>
> 
>                               
> <tns:ZastKod>57da4ce965fa09fe81070918b016422d</tns:ZastKod>
> 
>                                <tns:NakDost>false</tns:NakDost>
> 
>                 </tns:Racun>
> 
> </tns:RacunZahtjev>
> 
>  
> 
>  
> 
> Then I've tried using xmlsec1 but that doesn't work either. It
> calculates a wrong digital signature. I've tried with (like you've said
> in http://www.mail-archive.com/xmlsec at aleksey.com/msg05017.html):
> 
> xmlsec1 --sign --id-attr:Id
> http://www.apis-it.hr/fin/2012/types/f73:RacunZahtjev --output test.xml
> --pkcs12 fiskal1.pfx --pwd password  racun_nepotpisani2.xml
> 
>  
> 
> Please help me if you can, I can give you more details if you need them.
> 
>  
> 
> Thank you in advance!
> 
>                 Milan
> 
> 
> 
> __________ Information from ESET NOD32 Antivirus, version of virus
> signature database 7793 (20121212) __________
> 
> The message was checked by ESET NOD32 Antivirus.
> 
> http://www.eset.com

From aleksey at aleksey.com  Wed Dec 12 13:26:46 2012
From: aleksey at aleksey.com (Aleksey Sanin)
Date: Wed, 12 Dec 2012 13:26:46 -0800
Subject: [xmlsec] Digital signature
In-Reply-To: <001e01cdd89f$d6d586d0$84809470$@hr>
References: <00a301cdd87c$fac59710$f050c530$@hr>
 <50C8AF24.1080403@aleksey.com> <001e01cdd89f$d6d586d0$84809470$@hr>
Message-ID: <50C8F696.8010805@aleksey.com>

Section 3.2

Aleksey

On 12/12/12 11:35 AM, Milan Tribuson wrote:
> I did and didn't find an answer...
> 
> -----Original Message-----
> From: Aleksey Sanin [mailto:aleksey at aleksey.com] 
> Sent: Wednesday, December 12, 2012 5:22 PM
> To: Milan Tribuson; xmlsec at aleksey.com
> Subject: Re: Digital signature
> 
> Please read FAQ
> 
> http://www.aleksey.com/xmlsec/faq.html
> 
> Aleksey
> 
> On 12/12/12 7:25 AM, Milan Tribuson wrote:
>> Hi Aleksey,
>>
>>  
>>
>> we are trying to create a digital signature for xml invoice in Croatia 
>> and we can't make it work and we can't get the correct value.
>>
>> I've tried using your sign3.py in original and with changes (adding
>> refNode.addTransform(xmlsec.transformExclC14NId()) and referencing to 
>> URI which I can't get to work.
>>
>> I can reference to id but URI doesn't work (refNode = 
>> signNode.addReference(xmlsec.transformSha1Id(), None, "#RacunZahtjev", 
>> None)), even when I add dsig_ctx.enabledReferenceUris = 
>> xmlsec.TransformUriTypeAny and 
>> dsig_ctx.keyInfoReadCtx.retrievalMethodCtx.enabledUris = 
>> xmlsec.TransformUriTypeAny, I always get an error:
>>
>>  
>>
>> func=xmlSecXPathDataExecute:file=xpath.c:line=273:obj=unknown:subj=xml
>> XPtrEval:error=5:libxml2 library function 
>> failed:expr=xpointer(id('RacunZahtjev'))
>>
>> func=xmlSecXPathDataListExecute:file=xpath.c:line=356:obj=unknown:subj
>> =xmlSecXPathDataExecute:error=1:xmlsec
>> library function failed:
>>
>> func=xmlSecTransformXPathExecute:file=xpath.c:line=466:obj=xpointer:su
>> bj=xmlSecXPathDataExecute:error=1:xmlsec
>> library function failed:
>>
>> func=xmlSecTransformDefaultPushXml:file=transforms.c:line=2395:obj=xpo
>> inter:subj=xmlSecTransformExecute:error=1:xmlsec
>> library function failed:
>>
>> func=xmlSecTransformCtxXmlExecute:file=transforms.c:line=1226:obj=unkn
>> own:subj=xmlSecTransformPushXml:error=1:xmlsec
>> library function failed:transform=xpointer
>>
>> func=xmlSecTransformCtxExecute:file=transforms.c:line=1286:obj=unknown
>> :subj=xmlSecTransformCtxXmlExecute:error=1:xmlsec
>> library function failed:
>>
>> func=xmlSecDSigReferenceCtxProcessNode:file=xmldsig.c:line=1571:obj=un
>> known:subj=xmlSecTransformCtxExecute:error=1:xmlsec
>> library function failed:
>>
>> func=xmlSecDSigCtxProcessSignedInfoNode:file=xmldsig.c:line=804:obj=un
>> known:subj=xmlSecDSigReferenceCtxProcessNode:error=1:xmlsec
>> library function failed:node=Reference
>>
>> func=xmlSecDSigCtxProcessSignatureNode:file=xmldsig.c:line=547:obj=unk
>> nown:subj=xmlSecDSigCtxProcessSignedInfoNode:error=1:xmlsec
>> library function failed:
>>
>> func=xmlSecDSigCtxSign:file=xmldsig.c:line=303:obj=unknown:subj=xmlSec
>> DSigCtxSigantureProcessNode:error=1:xmlsec
>> library function failed:
>>
>> Error: signature failed
>>
>>  
>>
>>  
>>
>> My XML looks like:
>>
>> <tns:RacunZahtjev Id="RacunZahtjev"
>> xmlns:tns="http://www.apis-it.hr/fin/2012/types/f73"
>> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
>>
>>                 <tns:Zaglavlje>
>>
>>                               
>> <tns:IdPoruke>4ddfcb83-df33-413b-974c-ab90bdb69022</tns:IdPoruke>
>>
>>                               
>> <tns:DatumVrijeme>12.12.2012T09:56:35</tns:DatumVrijeme>
>>
>>                 </tns:Zaglavlje>
>>
>>                 <tns:Racun>
>>
>>                                <tns:Oib>68111664044</tns:Oib>
>>
>>                                <tns:USustPdv>true</tns:USustPdv>
>>
>>                               
>> <tns:DatVrijeme>12.12.2012T09:56:35</tns:DatVrijeme>
>>
>>                                <tns:OznSlijed>P</tns:OznSlijed>
>>
>>                                <tns:BrRac>
>>
>>                                               
>> <tns:BrOznRac>37</tns:BrOznRac>
>>
>>                                               
>> <tns:OznPosPr>S1</tns:OznPosPr>
>>
>>                                               
>> <tns:OznNapUr>31</tns:OznNapUr>
>>
>>                                </tns:BrRac>
>>
>>                                <tns:Pdv>
>>
>>                                                <tns:Porez>
>>
>>                                                               
>> <tns:Stopa>25.00</tns:Stopa>
>>
>>                                                               
>> <tns:Osnovica>0.64</tns:Osnovica>
>>
>>                                                               
>> <tns:Iznos>0.16</tns:Iznos>
>>
>>                                                </tns:Porez>
>>
>>                                </tns:Pdv>
>>
>>                                <tns:Pnp/>
>>
>>                                <tns:OstaliPor>
>>
>>                                                <tns:Porez>
>>
>>                                                               
>> <tns:Naziv>PNV</tns:Naziv>
>>
>>                                                               
>> <tns:Stopa>10.00</tns:Stopa>
>>
>>                                                               
>> <tns:Osnovica>0.64</tns:Osnovica>
>>
>>                                                               
>> <tns:Iznos>0.06</tns:Iznos>
>>
>>                                                </tns:Porez>
>>
>>                                </tns:OstaliPor>
>>
>>                                <tns:IznosUkupno>0.86</tns:IznosUkupno>
>>
>>                                <tns:NacinPlac>G</tns:NacinPlac>
>>
>>                                <tns:OibOper>66666666666</tns:OibOper>
>>
>>                               
>> <tns:ZastKod>57da4ce965fa09fe81070918b016422d</tns:ZastKod>
>>
>>                                <tns:NakDost>false</tns:NakDost>
>>
>>                 </tns:Racun>
>>
>> </tns:RacunZahtjev>
>>
>>  
>>
>>  
>>
>> Then I've tried using xmlsec1 but that doesn't work either. It 
>> calculates a wrong digital signature. I've tried with (like you've 
>> said in http://www.mail-archive.com/xmlsec at aleksey.com/msg05017.html):
>>
>> xmlsec1 --sign --id-attr:Id
>> http://www.apis-it.hr/fin/2012/types/f73:RacunZahtjev --output 
>> test.xml
>> --pkcs12 fiskal1.pfx --pwd password  racun_nepotpisani2.xml
>>
>>  
>>
>> Please help me if you can, I can give you more details if you need them.
>>
>>  
>>
>> Thank you in advance!
>>
>>                 Milan
>>
>>
>>
>> __________ Information from ESET NOD32 Antivirus, version of virus 
>> signature database 7793 (20121212) __________
>>
>> The message was checked by ESET NOD32 Antivirus.
>>
>> http://www.eset.com
> 
> 
> __________ Information from ESET NOD32 Antivirus, version of virus signature
> database 7793 (20121212) __________
> 
> The message was checked by ESET NOD32 Antivirus.
> 
> http://www.eset.com
> 
> 
>  
> 
> __________ Information from ESET NOD32 Antivirus, version of virus signature
> database 7793 (20121212) __________
> 
> The message was checked by ESET NOD32 Antivirus.
> 
> http://www.eset.com
>  
> 
> 

From magnus_qwerty at hotmail.com  Tue Dec 18 05:37:38 2012
From: magnus_qwerty at hotmail.com (Magnus R)
Date: Tue, 18 Dec 2012 14:37:38 +0100
Subject: [xmlsec] Verifying signature for enveloped signature with multiple
	signatures
Message-ID: <DUB002-W1110AB33FBCFF21345ED1828F310@phx.gbl>

Hello, 
I have a question regarding signature verification for enveloped signatures.
The question seems related to previous discussions in the forum:

http://www.aleksey.com/pipermail/xmlsec/2010/008910.html
http://www.aleksey.com/pipermail/xmlsec/2010/008911.html
http://www.aleksey.com/pipermail/xmlsec/2012/009340.html
http://www.aleksey.com/pipermail/xmlsec/2012/009341.html

But even with help of the previous posts I have not been able to verify my xml file.
I have tried the command line application "xmlsec1", as well as writing code, 
but it seems the same problem happens in both cases, so I will show the code below,
which is similar to the "verify3.c" example application shipped with the xmlsec library.


The relevant code part looks like this (written in C++):
==================================================
    std::cout << "Will find start node" << std::endl;

    // find start node
    xmlNodePtr node = xmlSecFindNode(xmlDocGetRootElement(doc), xmlSecNodeSignature, xmlSecDSigNs);
    if(node == NULL)
    {
        throw std::string("Start node not found in XML file");
    }

    std::cout << "-Found this node: \"" << node->name << "\"" << std::endl;

    // create signature context
    xmlSecDSigCtxPtr dsigCtx = xmlSecDSigCtxCreate(mngr);
    if(dsigCtx == NULL)
    {
        throw std::string("failed to create signature context");
    }
==================================================


When I run the application i get the following output:

-----------------------------------
Will verify file
Will load file: signedmod.xml
Will find start node
-Found this node: "Signature"
Will verify signature
func=xmlSecXPathDataExecute:file=xpath.c:line=273:obj=unknown:subj=xmlXPtrEval:error=5:libxml2 library function failed:expr=xpointer(id('SignedRouting'))
func=xmlSecXPathDataListExecute:file=xpath.c:line=356:obj=unknown:subj=xmlSecXPathDataExecute:error=1:xmlsec library function failed: 
func=xmlSecTransformXPathExecute:file=xpath.c:line=466:obj=xpointer:subj=xmlSecXPathDataExecute:error=1:xmlsec library function failed: 
func=xmlSecTransformDefaultPushXml:file=transforms.c:line=2395:obj=xpointer:subj=xmlSecTransformExecute:error=1:xmlsec library function failed: 
func=xmlSecTransformCtxXmlExecute:file=transforms.c:line=1226:obj=unknown:subj=xmlSecTransformPushXml:error=1:xmlsec library function failed:transform=xpointer
func=xmlSecTransformCtxExecute:file=transforms.c:line=1286:obj=unknown:subj=xmlSecTransformCtxXmlExecute:error=1:xmlsec library function failed: 
func=xmlSecDSigReferenceCtxProcessNode:file=xmldsig.c:line=1571:obj=unknown:subj=xmlSecTransformCtxExecute:error=1:xmlsec library function failed: 
func=xmlSecDSigCtxProcessSignedInfoNode:file=xmldsig.c:line=804:obj=unknown:subj=xmlSecDSigReferenceCtxProcessNode:error=1:xmlsec library function failed:node=Reference
func=xmlSecDSigCtxProcessSignatureNode:file=xmldsig.c:line=547:obj=unknown:subj=xmlSecDSigCtxProcessSignedInfoNode:error=1:xmlsec library function failed: 
func=xmlSecDSigCtxVerify:file=xmldsig.c:line=366:obj=unknown:subj=xmlSecDSigCtxSigantureProcessNode:error=1:xmlsec library function failed: 
Error: signature verify
-----------------------------------


The XML input XML file is shown at the end of this email. 
(also see the attached file signedxml.xml)


As can be seen from the output, the call to xmlSecFindNode() succeeds, and the node found is "Signature":
      -Found this node: "Signature"

However, after this the call to xmlSecDSigCtxCreate() fails. 

My guess it that first the "Signature" node is (correctly) found, 
but since this is an enveloped signature rather than an enveloping signature, the call fails. 

I have looked through the example XML files at the xmlsec online verifier web page:
http://www.aleksey.com/xmlsec/xmldsig-verifier.html

In those examples, the "Signature" tag is the outermost tag, with everything else contained in it.
However, in my case, the "Signature" tag is embedded in other tags that should be included in the signature. 

I guess the problem is that the "Signature" tag is found, but not everything needed to verify the
signature is contained in that tag. Instead, some information is outside of the tag.

So the question is, how should I solve this? 
Can you give some hints how I should implement the signature verification for my XML document?

The XML document will always have the same structure/XML schema, so it would be possible to
hard code search paths etc rather than making the solution generic enough for all kinds of documents. 


Regards
/Magnus




+++++++++++++++++++++++++++++++++
<soap:Envelope xmlns:myapp="http://www.mycompany.com/myapp" xmlns:soap="http://www.w3.org/2001/12/soap-envelope">
  <soap:Header>
    <myapp:Routing Filename="testfile.docx" ID="SignedRouting">
      <myapp:Transforms>
        <myapp:Transform Order="1" Type="Base64"></myapp:Transform>
      </myapp:Transforms>
    </myapp:Routing>
    <myapp:MyWorker ID="SignedMyWorker"></myapp:MyWorker>
  <Signature xmlns="http://www.w3.org/2000/09/xmldsig#">
    <SignedInfo>
      <CanonicalizationMethod Algorithm="http://www.w3.org/TR/2001/REC-xml-c14n-20010315" />
      <SignatureMethod Algorithm="http://www.w3.org/2000/09/xmldsig#rsa-sha1" />
      <Reference URI="#SignedRouting">
       <Transforms>
         <Transform Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature" />
       </Transforms>
       <DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1" />
       <DigestValue>RHhNanfgz950DdpZUZeX3zNdvmY=</DigestValue>
      </Reference>

      <Reference URI="#SignedBody">
       <Transforms>
        <Transform Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature" />
       </Transforms>
       <DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1" />
       <DigestValue>jdfsfsdlfkjsdflkjsdflkjdsf</DigestValue>
      </Reference>
     </SignedInfo>
   <SignatureValue>poisdufsoifusdofiusdoifusdfpuidsf</SignatureValue>
   <KeyInfo>
     <KeyValue>
       <RSAKeyValue>
         <Modulus>ksfhsdkhfsdkjfhskdhf</Modulus>
         <Exponent>AQAB</Exponent>
       </RSAKeyValue>
     </KeyValue></KeyInfo>
    </Signature>
   </soap:Header>
  <soap:Body ID="SignedBody">
    <myapp:FileData>
      <![CDATA[UEIUYIUYUIYUIYUIYUIY
]]>
    </myapp:FileData>
  </soap:Body>
</soap:Envelope>
+++++++++++++++++++++++++++++++++

 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.aleksey.com/pipermail/xmlsec/attachments/20121218/09a38d1e/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signedmod.xml
Type: application/xml
Size: 1538 bytes
Desc: not available
URL: <http://www.aleksey.com/pipermail/xmlsec/attachments/20121218/09a38d1e/attachment.xml>

From magnus_qwerty at hotmail.com  Tue Dec 18 07:20:05 2012
From: magnus_qwerty at hotmail.com (Magnus R)
Date: Tue, 18 Dec 2012 16:20:05 +0100
Subject: [xmlsec] Verifying signature for enveloped signature with
 multiple signatures
In-Reply-To: <DUB002-W1110AB33FBCFF21345ED1828F310@phx.gbl>
References: <DUB002-W1110AB33FBCFF21345ED1828F310@phx.gbl>
Message-ID: <DUB002-W363DD12309F4E3F437F8D68F310@phx.gbl>

Hello again, 

I made a mistake in the question:

It is not the call to xmlSecDSigCtxCreate() that fails. 
Instead, it is the call to xmlSecDSigCtxVerify() that fails. 



Here is the code:
==============

    std::cout << "Will find start node" << std::endl;

    // find start node
    xmlNodePtr node = xmlSecFindNode(xmlDocGetRootElement(doc), xmlSecNodeSignature, xmlSecDSigNs);
    if(node == NULL)
    {
        throw std::string("Start node not found in XML file");
    }

    std::cout << "-Found this node: \"" << node->name << "\"" << std::endl;

    // create signature context
    xmlSecDSigCtxPtr dsigCtx = xmlSecDSigCtxCreate(mngr);
    if(dsigCtx == NULL)
    {
        throw std::string("failed to create signature context");
    }

    std::cout << "Will verify signature" << std::endl;

    // Verify signature
    if(xmlSecDSigCtxVerify(dsigCtx, node) < 0)
    {
        fprintf(stderr,"Error: signature verify\n");
        return false;
    }

===============================

Regards
/Magnus


From: magnus_qwerty at hotmail.com
To: xmlsec at aleksey.com
Date: Tue, 18 Dec 2012 14:37:38 +0100
Subject: [xmlsec] Verifying signature for enveloped signature with multiple	signatures




Hello, 
I have a question regarding signature verification for enveloped signatures.
The question seems related to previous discussions in the forum:

http://www.aleksey.com/pipermail/xmlsec/2010/008910.html
http://www.aleksey.com/pipermail/xmlsec/2010/008911.html
http://www.aleksey.com/pipermail/xmlsec/2012/009340.html
http://www.aleksey.com/pipermail/xmlsec/2012/009341.html

But even with help of the previous posts I have not been able to verify my xml file.
I have tried the command line application "xmlsec1", as well as writing code, 
but it seems the same problem happens in both cases, so I will show the code below,
which is similar to the "verify3.c" example application shipped with the xmlsec library.


The relevant code part looks like this (written in C++):
==================================================
    std::cout << "Will find start node" << std::endl;

    // find start node
    xmlNodePtr node = xmlSecFindNode(xmlDocGetRootElement(doc), xmlSecNodeSignature, xmlSecDSigNs);
    if(node == NULL)
    {
        throw std::string("Start node not found in XML file");
    }

    std::cout << "-Found this node: \"" << node->name << "\"" << std::endl;

    // create signature context
    xmlSecDSigCtxPtr dsigCtx = xmlSecDSigCtxCreate(mngr);
    if(dsigCtx == NULL)
    {
        throw std::string("failed to create signature context");
    }
==================================================


When I run the application i get the following output:

-----------------------------------
Will verify file
Will load file: signedmod.xml
Will find start node
-Found this node: "Signature"
Will verify signature
func=xmlSecXPathDataExecute:file=xpath.c:line=273:obj=unknown:subj=xmlXPtrEval:error=5:libxml2 library function failed:expr=xpointer(id('SignedRouting'))
func=xmlSecXPathDataListExecute:file=xpath.c:line=356:obj=unknown:subj=xmlSecXPathDataExecute:error=1:xmlsec library function failed: 
func=xmlSecTransformXPathExecute:file=xpath.c:line=466:obj=xpointer:subj=xmlSecXPathDataExecute:error=1:xmlsec library function failed: 
func=xmlSecTransformDefaultPushXml:file=transforms.c:line=2395:obj=xpointer:subj=xmlSecTransformExecute:error=1:xmlsec library function failed: 
func=xmlSecTransformCtxXmlExecute:file=transforms.c:line=1226:obj=unknown:subj=xmlSecTransformPushXml:error=1:xmlsec library function failed:transform=xpointer
func=xmlSecTransformCtxExecute:file=transforms.c:line=1286:obj=unknown:subj=xmlSecTransformCtxXmlExecute:error=1:xmlsec library function failed: 
func=xmlSecDSigReferenceCtxProcessNode:file=xmldsig.c:line=1571:obj=unknown:subj=xmlSecTransformCtxExecute:error=1:xmlsec library function failed: 
func=xmlSecDSigCtxProcessSignedInfoNode:file=xmldsig.c:line=804:obj=unknown:subj=xmlSecDSigReferenceCtxProcessNode:error=1:xmlsec library function failed:node=Reference
func=xmlSecDSigCtxProcessSignatureNode:file=xmldsig.c:line=547:obj=unknown:subj=xmlSecDSigCtxProcessSignedInfoNode:error=1:xmlsec library function failed: 
func=xmlSecDSigCtxVerify:file=xmldsig.c:line=366:obj=unknown:subj=xmlSecDSigCtxSigantureProcessNode:error=1:xmlsec library function failed: 
Error: signature verify
-----------------------------------


The XML input XML file is shown at the end of this email. 
(also see the attached file signedxml.xml)


As can be seen from the output, the call to xmlSecFindNode() succeeds, and the node found is "Signature":
      -Found this node: "Signature"

However, after this the call to xmlSecDSigCtxCreate() fails. 

My guess it that first the "Signature" node is (correctly) found, 
but since this is an enveloped signature rather than an enveloping signature, the call fails. 

I have looked through the example XML files at the xmlsec online verifier web page:
http://www.aleksey.com/xmlsec/xmldsig-verifier.html

In those examples, the "Signature" tag is the outermost tag, with everything else contained in it.
However, in my case, the "Signature" tag is embedded in other tags that should be included in the signature. 

I guess the problem is that the "Signature" tag is found, but not everything needed to verify the
signature is contained in that tag. Instead, some information is outside of the tag.

So the question is, how should I solve this? 
Can you give some hints how I should implement the signature verification for my XML document?

The XML document will always have the same structure/XML schema, so it would be possible to
hard code search paths etc rather than making the solution generic enough for all kinds of documents. 


Regards
/Magnus




+++++++++++++++++++++++++++++++++
<soap:Envelope xmlns:myapp="http://www.mycompany.com/myapp" xmlns:soap="http://www.w3.org/2001/12/soap-envelope">
  <soap:Header>
    <myapp:Routing Filename="testfile.docx" ID="SignedRouting">
      <myapp:Transforms>
        <myapp:Transform Order="1" Type="Base64"></myapp:Transform>
      </myapp:Transforms>
    </myapp:Routing>
    <myapp:MyWorker ID="SignedMyWorker"></myapp:MyWorker>
  <Signature xmlns="http://www.w3.org/2000/09/xmldsig#">
    <SignedInfo>
      <CanonicalizationMethod Algorithm="http://www.w3.org/TR/2001/REC-xml-c14n-20010315" />
      <SignatureMethod Algorithm="http://www.w3.org/2000/09/xmldsig#rsa-sha1" />
      <Reference URI="#SignedRouting">
       <Transforms>
         <Transform Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature" />
       </Transforms>
       <DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1" />
       <DigestValue>RHhNanfgz950DdpZUZeX3zNdvmY=</DigestValue>
      </Reference>

      <Reference URI="#SignedBody">
       <Transforms>
        <Transform Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature" />
       </Transforms>
       <DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1" />
       <DigestValue>jdfsfsdlfkjsdflkjsdflkjdsf</DigestValue>
      </Reference>
     </SignedInfo>
   <SignatureValue>poisdufsoifusdofiusdoifusdfpuidsf</SignatureValue>
   <KeyInfo>
     <KeyValue>
       <RSAKeyValue>
         <Modulus>ksfhsdkhfsdkjfhskdhf</Modulus>
         <Exponent>AQAB</Exponent>
       </RSAKeyValue>
     </KeyValue></KeyInfo>
    </Signature>
   </soap:Header>
  <soap:Body ID="SignedBody">
    <myapp:FileData>
      <![CDATA[UEIUYIUYUIYUIYUIYUIY
]]>
    </myapp:FileData>
  </soap:Body>
</soap:Envelope>
+++++++++++++++++++++++++++++++++

 		 	   		  

_______________________________________________
xmlsec mailing list
xmlsec at aleksey.com
http://www.aleksey.com/mailman/listinfo/xmlsec 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.aleksey.com/pipermail/xmlsec/attachments/20121218/7bf5bad1/attachment-0001.html>

From aleksey at aleksey.com  Tue Dec 18 08:10:54 2012
From: aleksey at aleksey.com (Aleksey Sanin)
Date: Tue, 18 Dec 2012 08:10:54 -0800
Subject: [xmlsec] Verifying signature for enveloped signature with
 multiple signatures
In-Reply-To: <DUB002-W363DD12309F4E3F437F8D68F310@phx.gbl>
References: <DUB002-W1110AB33FBCFF21345ED1828F310@phx.gbl>
 <DUB002-W363DD12309F4E3F437F8D68F310@phx.gbl>
Message-ID: <50D0958E.5070203@aleksey.com>

Section 3.2 in the FAQ

http://www.aleksey.com/xmlsec/faq.html

Aleksey

On 12/18/12 7:20 AM, Magnus R wrote:
> Hello again,
> 
> I made a mistake in the question:
> 
> It is not the call to xmlSecDSigCtxCreate() that fails.
> Instead, it is the call to xmlSecDSigCtxVerify() that fails.
> 
> 
> 
> Here is the code:
> ==============
> 
>     std::cout << "Will find start node" << std::endl;
> 
>     // find start node
>     xmlNodePtr node = xmlSecFindNode(xmlDocGetRootElement(doc),
> xmlSecNodeSignature, xmlSecDSigNs);
>     if(node == NULL)
>     {
>         throw std::string("Start node not found in XML file");
>     }
> 
>     std::cout << "-Found this node: \"" << node->name << "\"" << std::endl;
> 
>     // create signature context
>     xmlSecDSigCtxPtr dsigCtx = xmlSecDSigCtxCreate(mngr);
>     if(dsigCtx == NULL)
>     {
>         throw std::string("failed to create signature context");
>     }
> 
>     std::cout << "Will verify signature" << std::endl;
> 
>     // Verify signature
>     if(xmlSecDSigCtxVerify(dsigCtx, node) < 0)
>     {
>         fprintf(stderr,"Error: signature verify\n");
>         return false;
>     }
> 
> ===============================
> 
> Regards
> /Magnus
> 
> 
> ------------------------------------------------------------------------
> From: magnus_qwerty at hotmail.com
> To: xmlsec at aleksey.com
> Date: Tue, 18 Dec 2012 14:37:38 +0100
> Subject: [xmlsec] Verifying signature for enveloped signature with
> multiple signatures
> 
> Hello,
> I have a question regarding signature verification for enveloped signatures.
> The question seems related to previous discussions in the forum:
> 
> http://www.aleksey.com/pipermail/xmlsec/2010/008910.html
> http://www.aleksey.com/pipermail/xmlsec/2010/008911.html
> http://www.aleksey.com/pipermail/xmlsec/2012/009340.html
> http://www.aleksey.com/pipermail/xmlsec/2012/009341.html
> 
> But even with help of the previous posts I have not been able to verify
> my xml file.
> I have tried the command line application "xmlsec1", as well as writing
> code,
> but it seems the same problem happens in both cases, so I will show the
> code below,
> which is similar to the "verify3.c" example application shipped with the
> xmlsec library.
> 
> 
> The relevant code part looks like this (written in C++):
> ==================================================
>     std::cout << "Will find start node" << std::endl;
> 
>     // find start node
>     xmlNodePtr node = xmlSecFindNode(xmlDocGetRootElement(doc),
> xmlSecNodeSignature, xmlSecDSigNs);
>     if(node == NULL)
>     {
>         throw std::string("Start node not found in XML file");
>     }
> 
>     std::cout << "-Found this node: \"" << node->name << "\"" << std::endl;
> 
>     // create signature context
>     xmlSecDSigCtxPtr dsigCtx = xmlSecDSigCtxCreate(mngr);
>     if(dsigCtx == NULL)
>     {
>         throw std::string("failed to create signature context");
>     }
> ==================================================
> 
> 
> When I run the application i get the following output:
> 
> -----------------------------------
> Will verify file
> Will load file: signedmod.xml
> Will find start node
> -Found this node: "Signature"
> Will verify signature
> func=xmlSecXPathDataExecute:file=xpath.c:line=273:obj=unknown:subj=xmlXPtrEval:error=5:libxml2
> library function failed:expr=xpointer(id('SignedRouting'))
> func=xmlSecXPathDataListExecute:file=xpath.c:line=356:obj=unknown:subj=xmlSecXPathDataExecute:error=1:xmlsec
> library function failed:
> func=xmlSecTransformXPathExecute:file=xpath.c:line=466:obj=xpointer:subj=xmlSecXPathDataExecute:error=1:xmlsec
> library function failed:
> func=xmlSecTransformDefaultPushXml:file=transforms.c:line=2395:obj=xpointer:subj=xmlSecTransformExecute:error=1:xmlsec
> library function failed:
> func=xmlSecTransformCtxXmlExecute:file=transforms.c:line=1226:obj=unknown:subj=xmlSecTransformPushXml:error=1:xmlsec
> library function failed:transform=xpointer
> func=xmlSecTransformCtxExecute:file=transforms.c:line=1286:obj=unknown:subj=xmlSecTransformCtxXmlExecute:error=1:xmlsec
> library function failed:
> func=xmlSecDSigReferenceCtxProcessNode:file=xmldsig.c:line=1571:obj=unknown:subj=xmlSecTransformCtxExecute:error=1:xmlsec
> library function failed:
> func=xmlSecDSigCtxProcessSignedInfoNode:file=xmldsig.c:line=804:obj=unknown:subj=xmlSecDSigReferenceCtxProcessNode:error=1:xmlsec
> library function failed:node=Reference
> func=xmlSecDSigCtxProcessSignatureNode:file=xmldsig.c:line=547:obj=unknown:subj=xmlSecDSigCtxProcessSignedInfoNode:error=1:xmlsec
> library function failed:
> func=xmlSecDSigCtxVerify:file=xmldsig.c:line=366:obj=unknown:subj=xmlSecDSigCtxSigantureProcessNode:error=1:xmlsec
> library function failed:
> Error: signature verify
> -----------------------------------
> 
> 
> The XML input XML file is shown at the end of this email.
> (also see the attached file signedxml.xml)
> 
> 
> As can be seen from the output, the call to xmlSecFindNode() succeeds,
> and the node found is "Signature":
>       -Found this node: "Signature"
> 
> However, after this the call to xmlSecDSigCtxCreate() fails.
> 
> My guess it that first the "Signature" node is (correctly) found,
> but since this is an enveloped signature rather than an enveloping
> signature, the call fails.
> 
> I have looked through the example XML files at the xmlsec online
> verifier web page:
> http://www.aleksey.com/xmlsec/xmldsig-verifier.html
> 
> In those examples, the "Signature" tag is the outermost tag, with
> everything else contained in it.
> However, in my case, the "Signature" tag is embedded in other tags that
> should be included in the signature.
> 
> I guess the problem is that the "Signature" tag is found, but not
> everything needed to verify the
> signature is contained in that tag. Instead, some information is outside
> of the tag.
> 
> So the question is, how should I solve this?
> Can you give some hints how I should implement the signature
> verification for my XML document?
> 
> The XML document will always have the same structure/XML schema, so it
> would be possible to
> hard code search paths etc rather than making the solution generic
> enough for all kinds of documents.
> 
> 
> Regards
> /Magnus
> 
> 
> 
> 
> +++++++++++++++++++++++++++++++++
> <soap:Envelope xmlns:myapp="http://www.mycompany.com/myapp"
> xmlns:soap="http://www.w3.org/2001/12/soap-envelope">
>   <soap:Header>
>     <myapp:Routing Filename="testfile.docx" ID="SignedRouting">
>       <myapp:Transforms>
>         <myapp:Transform Order="1" Type="Base64"></myapp:Transform>
>       </myapp:Transforms>
>     </myapp:Routing>
>     <myapp:MyWorker ID="SignedMyWorker"></myapp:MyWorker>
>   <Signature xmlns="http://www.w3.org/2000/09/xmldsig#">
>     <SignedInfo>
>       <CanonicalizationMethod
> Algorithm="http://www.w3.org/TR/2001/REC-xml-c14n-20010315" />
>       <SignatureMethod
> Algorithm="http://www.w3.org/2000/09/xmldsig#rsa-sha1" />
>       <Reference URI="#SignedRouting">
>        <Transforms>
>          <Transform
> Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature" />
>        </Transforms>
>        <DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1" />
>        <DigestValue>RHhNanfgz950DdpZUZeX3zNdvmY=</DigestValue>
>       </Reference>
> 
>       <Reference URI="#SignedBody">
>        <Transforms>
>         <Transform
> Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature" />
>        </Transforms>
>        <DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1" />
>        <DigestValue>jdfsfsdlfkjsdflkjsdflkjdsf</DigestValue>
>       </Reference>
>      </SignedInfo>
>    <SignatureValue>poisdufsoifusdofiusdoifusdfpuidsf</SignatureValue>
>    <KeyInfo>
>      <KeyValue>
>        <RSAKeyValue>
>          <Modulus>ksfhsdkhfsdkjfhskdhf</Modulus>
>          <Exponent>AQAB</Exponent>
>        </RSAKeyValue>
>      </KeyValue></KeyInfo>
>     </Signature>
>    </soap:Header>
>   <soap:Body ID="SignedBody">
>     <myapp:FileData>
>       <![CDATA[UEIUYIUYUIYUIYUIYUIY
> ]]>
>     </myapp:FileData>
>   </soap:Body>
> </soap:Envelope>
> +++++++++++++++++++++++++++++++++
> 
> 
> _______________________________________________ xmlsec mailing list
> xmlsec at aleksey.com http://www.aleksey.com/mailman/listinfo/xmlsec
> 
> 
> _______________________________________________
> xmlsec mailing list
> xmlsec at aleksey.com
> http://www.aleksey.com/mailman/listinfo/xmlsec
> 

From magnus_qwerty at hotmail.com  Wed Dec 19 02:25:09 2012
From: magnus_qwerty at hotmail.com (Magnus R)
Date: Wed, 19 Dec 2012 11:25:09 +0100
Subject: [xmlsec] Verifying signature for enveloped signature with
 multiple signatures
In-Reply-To: <50D0958E.5070203@aleksey.com>
References: <DUB002-W1110AB33FBCFF21345ED1828F310@phx.gbl>
 <DUB002-W363DD12309F4E3F437F8D68F310@phx.gbl>,<50D0958E.5070203@aleksey.com>
Message-ID: <DUB002-W1065AA139C256BE9BB16358F300@phx.gbl>

Thanks a lot Aleksey, now I got the command line verification to work as excpected.

The solution was to use several --id-attr parameters to xmlsec1.

This is the command line I used:
xmlsec1 --verify --id-attr:ID 'http://www.mycompany.com/myapp:Routing' --id-attr:ID 'http://www.w3.org/2001/12/soap-envelope:Body' signedmod.xml

The command invocation adds the ID:s for both the "Routing" and the "Body" tag.

When called with the XML I provided below, xmlsec1 will correctly come to the conclusion that the signature of that document does not match - since I have modified it.

This is the output I get:
=============================
func=xmlSecOpenSSLEvpDigestVerify:file=digests.c:line=229:obj=sha1:subj=unknown:error=12:invalid data:data and digest do not match
FAIL
SignedInfo References (ok/all): 0/1
Manifests References (ok/all): 0/0
Error: failed to verify file "signedmod.xml"
=============================

When used with a document with a signature that does match I get:

=============================
OK
SignedInfo References (ok/all): 2/2
Manifests References (ok/all): 0/0
=============================


Now the command line is up and running, so then I should be able to do the same in code using xmlAddID().

Many thanks.

Regards
/Magnus



> Date: Tue, 18 Dec 2012 08:10:54 -0800
> From: aleksey at aleksey.com
> To: magnus_qwerty at hotmail.com
> CC: xmlsec at aleksey.com
> Subject: Re: [xmlsec] Verifying signature for enveloped signature with multiple signatures
> 
> Section 3.2 in the FAQ
> 
> http://www.aleksey.com/xmlsec/faq.html
> 
> Aleksey
> 

 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.aleksey.com/pipermail/xmlsec/attachments/20121219/511d8b04/attachment.html>