No problem at all :) And actually I prefer this bug report much more than the others you send me today (as you can guess, because it's not a bug in my stuff :) ) And anyway, thanks a lot for all of your reports!
Aleksey Moultrie, Ferrell (ISSAtlanta) wrote: >(replying with egg all over face) >Wow! -- you're right. Never trust a Java-programming web guy to give you >what he said he did. (:>) I pulled the <KeyValue> node out of the >document and sure enough it fails. Then, adding --trusted to the command >line results in it properly verifying using the cert chain -- as I >thought was happening before. Sorry for the bogus bug report -- it's >been quite a day. >Ferrell > >-----Original Message----- >From: Aleksey Sanin [mailto:[EMAIL PROTECTED]] >Sent: Wednesday, August 28, 2002 9:04 PM >To: Moultrie, Ferrell (ISSAtlanta) >Cc: [EMAIL PROTECTED] >Subject: Re: Cert validation errors (was RE: [xmlsec] 0.0.8a build error >on Win32) > > >Please take a look at your file. It has public RSA key after the >certificate. >The xmlsec fails to verify cert but after this it is able to find good >key in the ><sig:RSAKeyValue /> element. And XMLSec is perfectly happy with it :) >For example, if you run the xmlsec utility with '--allowed x509' option >then >you'll have something like this: > >[aleksey@/tmp/test]$ xmlsec verify --allowed x509 --print-all >test_allkey_99.xml >xmlSecX509DataNodeRead (keyinfo.c:1191): error 31: cert verification >failed : >xmlSecKeyValueNodeRead (keyinfo.c:670): error 16: invalid key origin : >xmlSecKey >OriginKeyValue >xmlSecKeysMngrGetKey (keys.c:451): error 17: key not found : >xmlSecSignedInfoRead (xmldsig.c:1385): error 17: key not found : >xmlSecSignatureRead (xmldsig.c:1124): error 2: xmlsec operation failed : > >xmlSecS >ignedInfoRead - -1 >xmlSecDSigValidate (xmldsig.c:729): error 2: xmlsec operation failed : >xmlSecSig >natureRead - -1 >ERROR >Error: operation failed > > > >Aleksey. > > >Moultrie, Ferrell (ISSAtlanta) wrote: > > > >>Aleksey: >> There is only one key and it's only certified by one CA, a >> >> >self-signed > > >>root CA. So, w/o the PEM file, it must fail. I'm attaching a test >>document to this e-mail. Try: >> xmlsec verify --print-all test_allkey_99.xml >>It says everything is cool (except the cert validation error) -- but it >>can't really be OK since there's no way to verify the cert w/o a >> >> >trusted > > >>root specification. >> xmlsec verify --print-all --trusted new_export.pem test_allkey_99.xml >> >> > > > >>The above works completely because the root of the cert can be >>validated. The issue appears to be that there must be at least one key >>whose certification passes *and* one of those certifiable keys must be >>used to validate the signed hash. Anything less is a security problem >>because anyone can resign the document with any key they choose based >> >> >on > > >>a self-signed root and that root will be trusted -- the validation will >>succeed and there's no real way to tell it didn't. As you point out, I >>can't merely look for a cert validation error -- since the cert that >>fails may not be needed to validate the signature. Somehow xmlsec *has* >>to ensure that any key it reports success on must have been validated >> >> >by > > >>a trusted cert chain. >>Thanks! >> Ferrell >> >>-----Original Message----- >>From: Aleksey Sanin [mailto:[EMAIL PROTECTED]] >>Sent: Wednesday, August 28, 2002 7:59 PM >>To: Moultrie, Ferrell (ISSAtlanta) >>Cc: [EMAIL PROTECTED] >>Subject: Re: [xmlsec] 0.0.8a build error on Win32 >> >> >>Not necessary. Suppose your are signing a message with a key and >>provide more than one certificate for this key (for example, signed by >>root CAs A and B). It is possible that one of your recipients trusts >>the root CA A but not B and another trusts root CA B and not A. >>Then in this case *both* recipients will be able to successfully >>validate >>the message and both of them will have the same error. >>I believe that in your case the message verification succeeds because >>XML Sec library was able to find correct keys for the message in some >>other place (another cert, keys manager, etc.). From my point of view, >>this is a correct behavior and the verification *must* succeed (see >>scenario above). >> >> >>Aleksey >> >> >> >>Moultrie, Ferrell (ISSAtlanta) wrote: >> >> >> >> >> >>>Aleksey: >>>One other question .. when xmlSecDSigValidate() returns I'm getting a >>>return code of zero, and pResult->result is equal to >>>xmlSecTransformStatusOk. According to the doc, that means it worked. >>>However, down in the guts of x509 verification, the following error is >>>being generated: "error 31: cert verification failed : ". >>> >>> >>> >>> >>Unfortunately, >> >> >> >> >>>while that does result in a callback to the default error handler, it >>>doesn't result in any final error status from the verification >>> >>> >routine. > > >>>So, unless I monitor the error handler, I don't know that the error >>>occurred. In this case, because the uncertified public key is really >>> >>> >OK > > >>>and the hash is OK and the data is OK, the verify returns OK -- but it >>>really isn't OK because I forgot to supply the PEM data needed to >>>authenticate the certificate. Shouldn't this have resulted in a >>> >>> >>> >>> >>failure? >> >> >> >> >>>Verification with an invalid cert really isn't validation of the >>>signature, IMO. >>>Thanks! >>>Ferrell >>> >>>-----Original Message----- >>>From: Aleksey Sanin [mailto:[EMAIL PROTECTED]] >>>Sent: Wednesday, August 28, 2002 7:36 PM >>>To: Moultrie, Ferrell (ISSAtlanta) >>>Cc: [EMAIL PROTECTED] >>>Subject: Re: [xmlsec] 0.0.8a build error on Win32 >>> >>> >>>Ferrell, >>> >>>Thanks for reporting the problem! I am really sucks :( and I am doing >>>new >>>build right now. For 0.0.8 release I've tried to use a new box for >>> >>> >>> >>> >>doing >> >> >> >> >>>builds but looks like it was really WRONG idea. I did 0.0.9 release on >>>the >>>old box and now smoke testing it. Should be done in 15-30 minutes. >>> >>>Sorry for the inconvinience, >>>Aleksey >>> >>>Moultrie, Ferrell (ISSAtlanta) wrote: >>> >>> >>> >>> >>> >>> >>> >>>>When I try to build 0.0.8a, I get an error: >>>>D:\xmlsec-0.0.8\src\enveloped.c(24) : fatal error C1083: Cannot open >>>>include file: 'xmlsec/xpath.h': No such file or directory >>>> >>>>I don't see an xmlsec/xpath.h in the xmlsec distribution (there is >>>> >>>> >one > > >>>>in libxml2 -- but this specifically asks for xmlsec/xpath.h). >>>> >>>>If I simply comment out the line: >>>>//#include <xmlsec/xpath.h> >>>>.. then everything builds OK. >>>> >>>>Am I missing something? This same error persists in the 020828 daily >>>>build also. >>>>Thanks! >>>>Ferrell >>>> >>>>===================================== >>>>Ferrell Moultrie ([EMAIL PROTECTED]) >>>>Software Engineer >>>> >>>>Internet Security Systems, Inc. >>>>6303 Barfield Road >>>>Atlanta, Georgia 30328 >>>>Phone: 404-236-2600 >>>>Direct: 404-236-2849 >>>>Fax: 404-236-2632 >>>>http://www.iss.net >>>> >>>>Internet Security Systems -- The Power to Protect >>>>===================================== >>>>_______________________________________________ >>>>xmlsec mailing list >>>>[EMAIL PROTECTED] >>>>http://www.aleksey.com/mailman/listinfo/xmlsec >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>_______________________________________________ >>>xmlsec mailing list >>>[EMAIL PROTECTED] >>>http://www.aleksey.com/mailman/listinfo/xmlsec >>> >>> >>> >>> >>> >>> >> >> >>----------------------------------------------------------------------- >> >> >- > > >><ISSKeys Source="ISS Atlanta"><!-- TestKey ISS keygen --> >><Contacts><Contact><Keys Address1="2626 Somewhere Lane" Address2="suite >> >> >200A" City="Atlanta" Country="US" Email="[EMAIL PROTECTED]" >Fax="778-555-1212" Phone="777.555.1212" PostCode="30064" >Weburl="http://web.fubar.net";></Keys><CustomerRelations Address1="1313 >knowwhere Lane" Address2="suite 300A" City="Atlanta" Country="US" >Email="[EMAIL PROTECTED]" Fax="778-555-7799" >Phone="777.555.7788" PostCode="30064" >Weburl="http://web.customer_relations_iss.net";></CustomerRelations><Supp >ort Address1="1234 Anvil Rd." Address2="suite 440B" City="Atlanta" >Country="US" Email="[EMAIL PROTECTED]" Fax="778-555-7755" >Phone="777.555.7744" PostCode="30064" >Weburl="http://web.suport_iss.net";></Support><Version>1.0</Version><OCN> >163444</OCN><Source>ISS >Atlanta</Source><Serial>ACC64BB4-A53D-AC83-3E6F-E0AB737DEC9D</Serial><Ti >mestamp>2000-06-14 10:34:09</Timestamp><sig:Signature >xmlns:sig="http://www.w3.org/2000/09/xmldsig#";> > > >><sig:SignedInfo> >><sig:CanonicalizationMethod >> >> >Algorithm="http://www.w3.org/TR/2001/REC-xml-c14n-20010315";></sig:Canoni >calizationMethod> > > >><sig:SignatureMethod >> >> >Algorithm="http://www.w3.org/2000/09/xmldsig#rsa-sha1";></sig:SignatureMe >thod> > > >><sig:Reference URI=""> >><sig:Transforms> >><sig:Transform >> >> >Algorithm="http://www.w3.org/TR/1999/REC-xpath-19991116";> > > >><sig:XPath> >>not(ancestor-or-self::sig:Signature) >>and ( >> (ancestor-or-self::node() = /ISSKeys/Contacts/Contact) >>) >></sig:XPath> >></sig:Transform> >><sig:Transform >> >> >Algorithm="http://www.w3.org/TR/2001/REC-xml-c14n-20010315#WithComments"; > > >></sig:Transform> >></sig:Transforms> >><sig:DigestMethod >> >> >Algorithm="http://www.w3.org/2000/09/xmldsig#sha1";></sig:DigestMethod> > > >><sig:DigestValue>pj96s6n/wNTsaxKWMtqyTsWbTrU=</sig:DigestValue> >></sig:Reference> >></sig:SignedInfo> >><sig:SignatureValue>jDZBVuX7vtG1MgIQyii5+10NcG8nrE8ak0Vds12Kmrq3s7hiqUk >> >> >6yP6ntt7izos/uDkakrrW0qwA > > >>WrfRa0MfqIUdojyM1nzbqTmGX23BhCeU1BKvjFf75CEMikEhC+ZgY4lKN9BiIE5SV2DbirL >> >> >87TsZ > > >>Kjta6tlwYgEMxGlCs4I=</sig:SignatureValue> >><sig:KeyInfo> >><sig:X509Data> >><sig:X509Certificate> >>MIICCjCCAXMCBDzvGMIwDQYJKoZIhvcNAQEEBQAwTDELMAkGA1UEBhMCVVMxFjAUBgNVBAo >> >> >TDVdl > > >>YiBEZXZlbG9wZXIxCzAJBgNVBAsTAklUMRgwFgYDVQQDEw9JU1MgS2V5Z2VuIFRlc3QwHhc >> >> >NMDIw > > >>NTI1MDQ1MzIyWhcNMjcwMTE0MDQ1MzIyWjBMMQswCQYDVQQGEwJVUzEWMBQGA1UEChMNV2V >> >> >iIERl > > >>dmVsb3BlcjELMAkGA1UECxMCSVQxGDAWBgNVBAMTD0lTUyBLZXlnZW4gVGVzdDCBnzANBgk >> >> >qhkiG > > >>9w0BAQEFAAOBjQAwgYkCgYEAy6ACsVtGJ69fkeKxJUlZqUP4FJFDIrkrUEi04c8UAAmC6jx >> >> >u9+mM > > >>uLD+766Ztrjp/2anYX0QS7ReD+Q78ky3a0nmPDIpAzv8P7tUCBc6Yq11w5c1yHSNDdLPxLl >> >> >X6+JT > > >>nUXnmXMsfAyC2cnoevc38gfEEkEJnS4iCzUC7WHsNgMCAwEAATANBgkqhkiG9w0BAQQFAAO >> >> >BgQBy > > >>08EvqGY4QL5GYhuT5Lx26t7V0Tk9bKxzh9YKxtyTLux0sqDFcAQWu1UpjPSOLwgNhE+uaS+ >> >> >CuyIK > > >>wsSzMx84gOIk7/fOS5F7oRk2ouC0QPPhY0iT2wXi9Zhvd6CifjNwvCdDe0tinSeQNfvpo0F >> >> >Slg8c > > >>GL2eqXYylPEeMvZ5aw== >></sig:X509Certificate> >></sig:X509Data> >><sig:KeyValue> >><sig:RSAKeyValue> >><sig:Modulus> >>y6ACsVtGJ69fkeKxJUlZqUP4FJFDIrkrUEi04c8UAAmC6jxu9+mMuLD+766Ztrjp/2anYX0 >> >> >QS7Re > > >>D+Q78ky3a0nmPDIpAzv8P7tUCBc6Yq11w5c1yHSNDdLPxLlX6+JTnUXnmXMsfAyC2cnoevc >> >> >38gfE > > >>EkEJnS4iCzUC7WHsNgM= >></sig:Modulus> >><sig:Exponent>AQAB</sig:Exponent> >></sig:RSAKeyValue> >></sig:KeyValue> >></sig:KeyInfo> >></sig:Signature></Contact></Contacts><EndUsers><EndUser Address1="666 >> >> >Rockets way" Address2="Apt. B" City="Scienceville" CompanyName="Spacely >Sprockets" Country="US" Email="[EMAIL PROTECTED]" PostCode="" >State="Disturbed" SubjectName="George Jetson" Title="Whipping >Boy"><Version>1.0</Version><OCN>163444</OCN><Source>ISS >Atlanta</Source><Serial>CE8135D7-8D27-4BC4-BCA6-2DBDE703B6AE</Serial><Ti >mestamp>2000-06-14 >10:34:09</Timestamp></EndUser></EndUsers><LicensedModules><LicensedModul >e ContactInfo="ACC64BB4-A53D-AC83-3E6F-E0AB737DEC9D" >EndUserInfo="CE8135D7-8D27-4BC4-BCA6-2DBDE703B6AE" Identity="RO" >LicenseExpiration="2003-06-14" LicenseType="evaluation" >Limit="2147483647" LimitOutOfMaintenance="0" >MaintenanceExpiration="2003-06-14"><Version>1.0</Version><OCN>163444</OC >N><Source>ISS >Atlanta</Source><Serial>F61BD0F3-D5D9-2F90-A24D-BF989200D712</Serial><Ti >mestamp>2000-06-14 >10:34:09</Timestamp></LicensedModule></LicensedModules></ISSKeys> >> > > _______________________________________________ xmlsec mailing list [EMAIL PROTECTED] http://www.aleksey.com/mailman/listinfo/xmlsec
