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

Wed, 28 Aug 2002 21:09:20 -0400

(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.=20
Ferrell

-----Original Message-----
From: Aleksey Sanin [mailto:aleksey@aleksey.com]=20
Sent: Wednesday, August 28, 2002 9:04 PM
To: Moultrie, Ferrell (ISSAtlanta)
Cc: xmlsec@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=20
certificate.
The xmlsec fails to verify cert but after this it is able to find good=20
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=20
test_allkey_99.xml
xmlSecX509DataNodeRead (keyinfo.c:1191): error 31: cert verification=20
failed :
xmlSecKeyValueNodeRead (keyinfo.c:670): error 16: invalid key origin :=20
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 :=20
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@aleksey.com]=20
>Sent: Wednesday, August 28, 2002 7:59 PM
>To: Moultrie, Ferrell (ISSAtlanta)
>Cc: xmlsec@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:
>
> =20
>
>>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 : ".
>>   =20
>>
>Unfortunately,
> =20
>
>>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
>>   =20
>>
>failure?
> =20
>
>>Verification with an invalid cert really isn't validation of the
>>signature, IMO.=20
>>Thanks!
>> Ferrell
>>
>>-----Original Message-----
>>From: Aleksey Sanin [mailto:aleksey@aleksey.com]=20
>>Sent: Wednesday, August 28, 2002 7:36 PM
>>To: Moultrie, Ferrell (ISSAtlanta)
>>Cc: xmlsec@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
>>   =20
>>
>doing
> =20
>
>>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:
>>
>>=20
>>
>>   =20
>>
>>>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).=20
>>>
>>>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
>>>
>>>=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
>>>Ferrell Moultrie (ferrell@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
>>>=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
>>>_______________________________________________
>>>xmlsec mailing list
>>>xmlsec@aleksey.com
>>>http://www.aleksey.com/mailman/listinfo/xmlsec
>>>
>>>
>>>  =20
>>>
>>>     =20
>>>
>>_______________________________________________
>>xmlsec mailing list
>>xmlsec@aleksey.com
>>http://www.aleksey.com/mailman/listinfo/xmlsec
>>=20
>>
>>   =20
>>
>
> =20
>
>-----------------------------------------------------------------------
-
>
><ISSKeys Source=3D"ISS Atlanta"><!-- TestKey ISS keygen -->
><Contacts><Contact><Keys Address1=3D"2626 Somewhere Lane" =
Address2=3D"suite
200A" City=3D"Atlanta" Country=3D"US" Email=3D"keys@iss.net"
Fax=3D"778-555-1212" Phone=3D"777.555.1212" PostCode=3D"30064"
Weburl=3D"http://web.fubar.net"></Keys><CustomerRelations =
Address1=3D"1313
knowwhere Lane" Address2=3D"suite 300A" City=3D"Atlanta" Country=3D"US"
Email=3D"customer_relations@iss.net" Fax=3D"778-555-7799"
Phone=3D"777.555.7788" PostCode=3D"30064"
Weburl=3D"http://web.customer_relations_iss.net"></CustomerRelations><Sup=
p
ort Address1=3D"1234 Anvil Rd." Address2=3D"suite 440B" City=3D"Atlanta"
Country=3D"US" Email=3D"support@iss.net" Fax=3D"778-555-7755"
Phone=3D"777.555.7744" PostCode=3D"30064"
Weburl=3D"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=3D"http://www.w3.org/2000/09/xmldsig#">
><sig:SignedInfo>
><sig:CanonicalizationMethod
Algorithm=3D"http://www.w3.org/TR/2001/REC-xml-c14n-20010315"></sig:Canon=
i
calizationMethod>
><sig:SignatureMethod
Algorithm=3D"http://www.w3.org/2000/09/xmldsig#rsa-sha1"></sig:SignatureM=
e
thod>
><sig:Reference URI=3D"">
><sig:Transforms>
><sig:Transform
Algorithm=3D"http://www.w3.org/TR/1999/REC-xpath-19991116">
><sig:XPath>
>not(ancestor-or-self::sig:Signature)
> and (
>    (ancestor-or-self::node() =3D /ISSKeys/Contacts/Contact)=20
>)
></sig:XPath>
></sig:Transform>
><sig:Transform
Algorithm=3D"http://www.w3.org/TR/2001/REC-xml-c14n-20010315#WithComments=
"
></sig:Transform>
></sig:Transforms>
><sig:DigestMethod
Algorithm=3D"http://www.w3.org/2000/09/xmldsig#sha1"></sig:DigestMethod>
><sig:DigestValue>pj96s6n/wNTsaxKWMtqyTsWbTrU=3D</sig:DigestValue>
></sig:Reference>
></sig:SignedInfo>
><sig:SignatureValue>jDZBVuX7vtG1MgIQyii5+10NcG8nrE8ak0Vds12Kmrq3s7hiqUk
6yP6ntt7izos/uDkakrrW0qwA
>WrfRa0MfqIUdojyM1nzbqTmGX23BhCeU1BKvjFf75CEMikEhC+ZgY4lKN9BiIE5SV2DbirL
87TsZ
>Kjta6tlwYgEMxGlCs4I=3D</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=3D=3D
></sig:X509Certificate>
></sig:X509Data>
><sig:KeyValue>
><sig:RSAKeyValue>
><sig:Modulus>
>y6ACsVtGJ69fkeKxJUlZqUP4FJFDIrkrUEi04c8UAAmC6jxu9+mMuLD+766Ztrjp/2anYX0
QS7Re
>D+Q78ky3a0nmPDIpAzv8P7tUCBc6Yq11w5c1yHSNDdLPxLlX6+JTnUXnmXMsfAyC2cnoevc
38gfE
>EkEJnS4iCzUC7WHsNgM=3D
></sig:Modulus>
><sig:Exponent>AQAB</sig:Exponent>
></sig:RSAKeyValue>
></sig:KeyValue>
></sig:KeyInfo>
></sig:Signature></Contact></Contacts><EndUsers><EndUser Address1=3D"666
Rockets way" Address2=3D"Apt. B" City=3D"Scienceville" =
CompanyName=3D"Spacely
Sprockets" Country=3D"US" Email=3D"gjetson@sprokets.net" PostCode=3D""
State=3D"Disturbed" SubjectName=3D"George Jetson" Title=3D"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=3D"ACC64BB4-A53D-AC83-3E6F-E0AB737DEC9D"
EndUserInfo=3D"CE8135D7-8D27-4BC4-BCA6-2DBDE703B6AE" Identity=3D"RO"
LicenseExpiration=3D"2003-06-14" LicenseType=3D"evaluation"
Limit=3D"2147483647" LimitOutOfMaintenance=3D"0"
MaintenanceExpiration=3D"2003-06-14"><Version>1.0</Version><OCN>163444</O=
C
N><Source>ISS
Atlanta</Source><Serial>F61BD0F3-D5D9-2F90-A24D-BF989200D712</Serial><Ti
mestamp>2000-06-14
10:34:09</Timestamp></LicensedModule></LicensedModules></ISSKeys>
>