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

Wed Aug 28 18:09:20 PDT 2002

(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>
>