[xmlsec] Canonicalization problem?
Hello! I'm using xmlsec 0.0.15 and have a problem using the LF/NL and CR entities in xmlfiles used for enveloped-signature. Eks: tag#13;#10;Some text!/tag - looks like this in XEmacs after signing: tag^M Some text/tag OK, as far as I understand this is the canonicalization procedure which replace the enities with ASCII LF/NL. The problem is, the signed file will not be verified. Isn't that a bit strange, the canonicalization takes place before any digest is made, and the binary representation will be the same in both ends(when making digest before signing and before verifying)?... However if I drop the CR sign the ^M sign is gone and the signed file verifies. Any thoughts on what's wrong? Regards, Johannes ___ xmlsec mailing list [EMAIL PROTECTED] http://www.aleksey.com/mailman/listinfo/xmlsec
Re: [xmlsec] Canonicalization problem?
current version is 1.1.1. please update. I cannot see this problem in current. Johannes Kjos wrote: Hello! I'm using xmlsec 0.0.15 and have a problem using the LF/NL and CR entities in xmlfiles used for enveloped-signature. Eks: tag#13;#10;Some text!/tag - looks like this in XEmacs after signing: tag^M Some text/tag OK, as far as I understand this is the canonicalization procedure which replace the enities with ASCII LF/NL. The problem is, the signed file will not be verified. Isn't that a bit strange, the canonicalization takes place before any digest is made, and the binary representation will be the same in both ends(when making digest before signing and before verifying)?... However if I drop the CR sign the ^M sign is gone and the signed file verifies. Any thoughts on what's wrong? Regards, Johannes ___ xmlsec mailing list [EMAIL PROTECTED] http://www.aleksey.com/mailman/listinfo/xmlsec ___ xmlsec mailing list [EMAIL PROTECTED] http://www.aleksey.com/mailman/listinfo/xmlsec
Re: [xmlsec] Re: XML Security Library 1.1.1 is released
Hello community, Please don't hesitate to post you work for MS CryptoAPI though very alpha code. ___ xmlsec mailing list [EMAIL PROTECTED] http://www.aleksey.com/mailman/listinfo/xmlsec
Re: [xmlsec] Canonicalization problem?
The canonicalization does not change the signed xml document. C14N happens during calculating digests or signatures and the result is never written back. Thus canonicalization could not make this change #13;#10; --- \x0D\x0A. The only idea I have for you is that you have problems with saving the file (i.e. when you calculate the digest, it is calculated against #13;#10; but when you save it, the entities are converted to \x0d\x0a). Please try to sign your file with xmlsec command line utility. Try --print-references (for 0.0.15) or --store-references (for 1.x) option and check *what* was signed by xmlsec1. Also it might depend on libxml2 version used. Try the latest version. Aleksey ___ xmlsec mailing list [EMAIL PROTECTED] http://www.aleksey.com/mailman/listinfo/xmlsec
Re: [xmlsec] Canonicalization problem?
Oops wrong. problem exist. I think that this is libxml2 problem. Roumen Petrov wrote: current version is 1.1.1. please update. I cannot see this problem in current. Johannes Kjos wrote: Hello! I'm using xmlsec 0.0.15 and have a problem using the LF/NL and CR entities in xmlfiles used for enveloped-signature. Eks: tag#13;#10;Some text!/tag - looks like this in XEmacs after signing: tag^M Some text/tag OK, as far as I understand this is the canonicalization procedure which replace the enities with ASCII LF/NL. The problem is, the signed file will not be verified. Isn't that a bit strange, the canonicalization takes place before any digest is made, and the binary representation will be the same in both ends(when making digest before signing and before verifying)?... However if I drop the CR sign the ^M sign is gone and the signed file verifies. Any thoughts on what's wrong? Regards, Johannes ___ xmlsec mailing list [EMAIL PROTECTED] http://www.aleksey.com/mailman/listinfo/xmlsec ___ xmlsec mailing list [EMAIL PROTECTED] http://www.aleksey.com/mailman/listinfo/xmlsec
[xmlsec] Verify on Microsoft-produced sig
Hi Aleksey, The attached file is a signature produced by Microsoft's InfoPath (XML forms Manager from Office 2003). It's an enveloped signature with an extra reference to a comment element. XMLSec verify reports data and digest problem (as below). InfoPath uses the latest .Net Framework librairies which is used across all Microsoft XMLDSIG implementations. Is this the same problem as referenced in your FAQ section 3.2 ? Or is this something else ? Ed C:\XMLSecxmlsec verify --store-signatures --print-debug inout/SimpleForm-2003-08-13.xml func=xmlSecOpenSSLEvpDigestVerify:file=..\src\openssl\digests.c:line=164:obj =sha1:subj=unknown:error=12:invalid data:data and digest do not match FAIL P.S. For all the XMLSec followers waiting for a MS CAPI implementation, we have a work-around for our desktop signer which essentially exports the key from the MS Crypto Store using CAPICOM. There XMLSEC can get at it as a P12/PFX on the file system. There is a password prompt, but we enforce password protection of the MS Crypto Store anyway. The only pre-requisite is that the key/cert must be marked as exportable when initially loaded into the MS Crypto Store. It has been getting us by while we wait. Our XMLSec is running OpenSSL on the desktop. SimpleForm-2003-08-13.zip Description: Zip compressed data
Re: [xmlsec] Verify on Microsoft-produced sig
It does not look like it's a problem with undefined ID attributes. If you run xmlsec command line utility with --store-references flag you'll see that we could not verify the first reference. It's has an xslt transform and with --store-references flag you can see the result of processing this transform: my:myFields xmlns:my=http://schemas.microsoft.com/office/infopath/2003/myXSD/2003-04-12T15:07:25; xml:lang=en-us my:OrderNumber1234/my:OrderNumber my:txtNameEdward Shallow/my:txtName my:intCustomerNumber xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance;12345678/my:intCustomerNumber my:signatures1/my:signatures1 /my:myFields This is the data that goes into digest and after that digests do not match. I would suspect that there is an interop problem between MS xslt engine and libxslt. It would be helpfull if you can apply the same xslt template to the same data using MS engine and compare results. Aleksey ___ xmlsec mailing list [EMAIL PROTECTED] http://www.aleksey.com/mailman/listinfo/xmlsec
