Cert validation errors (was RE: [xmlsec] 0.0.8a build error on Win32)

Wed Aug 28 18:13:45 PDT 2002

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:aleksey at aleksey.com] 
>Sent: Wednesday, August 28, 2002 9:04 PM
>To: Moultrie, Ferrell (ISSAtlanta)
>Cc: xmlsec at aleksey.com
>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:aleksey at aleksey.com] 
>>Sent: Wednesday, August 28, 2002 7:59 PM
>>To: Moultrie, Ferrell (ISSAtlanta)
>>Cc: xmlsec at aleksey.com
>>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:aleksey at aleksey.com] 
>>>Sent: Wednesday, August 28, 2002 7:36 PM
>>>To: Moultrie, Ferrell (ISSAtlanta)
>>>Cc: xmlsec at aleksey.com
>>>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 (ferrell at iss.net)
>>>>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
>>>>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
>>>
>>>
>>>   
>>>
>>>      
>>>
>> 
>>
>>-----------------------------------------------------------------------
>>    
>>
>-
>  
>
>><ISSKeys Source="ISS Atlanta"><!-- TestKey ISS keygen -->
>><Contacts><Contact><Keys Address1="2626 Somewhere Lane" Address2="suite
>>    
>>
>200A" City="Atlanta" Country="US" Email="keys at iss.net"
>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="customer_relations at iss.net" 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="support at iss.net" 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="gjetson at sprokets.net" 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>
>>
>  
>