[xmlsec] RE: OpenSSL vs mscrypto

Thu Jan 12 21:33:57 PST 2006

PostScript:

It seems that OpenOffice.org V2.0 also does not check certificate chains
when validating a signature. 

It will show the public issuer in the chain hierarchy (if it is loaded in
the ROOT store) when you View the Certificate in the Certification Path tab.
It will not show any hierarchy if it the issuer is not present. That is, it
will just show the signer's certificate in the 1 line path.

However it will not display any warning or error if the issuer cannot be
found.

I believe OpenOffice.org uses xmlsec with nss.

Ed

-----Original Message-----
From: Edward Shallow [mailto:ed.shallow at rogers.com] 
Sent: January 12, 2006 11:57 PM
To: 'Aleksey Sanin'
Cc: 'xmlsec at aleksey.com'
Subject: OpenSSL vs mscrypto

Aleksey,

Sorry for the lengthy dialogue on this topic, but we really have a
fundamental problem here with mscrypto.

Please let me state first that the observations below are with the unpatched
xmlsec V 1.2.8 using mscrypto, which is supposed to verify cert chains but
in fact does not. In fact there are no circumstances I can detect under
which it does. I doubt it ever has. So unless someone describes otherwise,
it is starting to look like the only hope for cert chain verification with
mscrypto may very well lie with Dmitry's patch. I have yet to test it, but I
will tomorrow.

With xmlsec 1.2.8 and mscrypto ...

The <dsig:KeyName> is in the signed document (which we are attempting to
verify the chain on) because that is the way you tell mscrypto how to select
the key for signing. So it is left over from the sign operation.

I "again" performed the test that both Dmitry and you suggested.

If you remove the "Test User 1" key from all the MS crypto stores ('MY' and
'AddressBook') you get the following on the verify: 

func=xmlSecMSCryptoX509FindCert:file=..\src\mscrypto\x509vfy.c:line=754:obj=
unknown:subj=xmlSecMSCryptoCertStrToName:error=1:xmlsec library function
failed: ;last error=-2146885597 (0x80092023);last error msg=The string
contains an invalid X500 name attribute key, oid, value or delimiter.

func=xmlSecKeysMngrGetKey:file=..\src\keys.c:line=1364:obj=unknown:subj=xmlS
ecKeysMngrFindKey:error=1:xmlsec library function failed: ;last
error=-2146885628 (0x80092004);last error msg=Cannot find object or
property.

func=xmlSecDSigCtxProcessKeyInfoNode:file=..\src\xmldsig.c:line=871:obj=unkn
own:subj=unknown:error=45:key is not found: ;last error=-2146885628
(0x80092004);last error msg=Cannot find object or property.

func=xmlSecDSigCtxProcessSignatureNode:file=..\src\xmldsig.c:line=565:obj=un
known:subj=xmlSecDSigCtxProcessKeyInfoNode:error=1:xmlsec library function
failed: ;last error=-2146885628 (0x80092004);last error msg=Cannot find
object or property.

func=xmlSecDSigCtxVerify:file=..\src\xmldsig.c:line=366:obj=unknown:subj=xml
SecDSigCtxSigantureProcessNode:error=1:xmlsec library function failed: ;last
error=-2146885628 (0x80092004);last error msg=Cannot find object or
property.

If you load the "Test User 1" certificate only into the 'AddressBook'
certificate store (which is called "Other People" in the IE UI) it verifies
successfully even when you do NOT have the upu-cacert.der (i.e. the issuer
public root cert) loaded anywhere, in KeysMngr or in the MS ROOT store. In
other words, the chain is never being checked with xmlsec 1.2.8 and mscrypto
or it would have detected the absence of the issuer.

I do not know why any cert store is being searched at all when verifying
signatures if the X509Certificate end cert is in the signed document. One
simply needs to call the crypt32.dll certCreateCertificateContext
initializing the pbCertEncoded argument with the certificate extracted from
the signed document instead of expecting it to already be in a MS crypto
store ? This would avoid the need for the verifier to have the signer's
public certificate in any of their stores, which is highly desireable.

This is the desired functionality for "end certificate in the signed
document" scenarios and is exactly what openssl does. In fact mscrypto
should behave exactly like openssl when verifying signed documents which
include the X509 cert and the xmlSecCryptoAppKeysMngrCertLoad has loaded the
issuer cert.

This is how we need xmlsec to work when the application is a server-based
verification service and no public end certs exist on that server just
public trusted issuers loaded via xmlSecCryptoAppKeysMngrCertLoad. Again
exactly like openssl behaves. The fact that openssl has no store is
irrelevant here since the store is just getting in the way for a verify
especially for the end cert in the chain.

If Dmitry's patch expects the end certificate to be in a store (i.e. Test
User 1 in our example) for a verify to work, then it has the same problem.

If the X509 cert is not in the signed document, then that is another story
and expecting it to be in a store would be justified.

Ed

-----Original Message-----
From: xmlsec-bounces at aleksey.com [mailto:xmlsec-bounces at aleksey.com] On
Behalf Of Aleksey Sanin
Sent: January 12, 2006 5:55 PM
To: ed.shallow at rogers.com
Cc: xmlsec at aleksey.com
Subject: [Bulk] Re: [xmlsec] Verify - OpenSSL vsmscrypto

I believe that in this case xmlsec-mscrypto does not construct the
certificates chain at all. The document has <dsig:KeyName> element and
xmlsec simply finds the signature key in the MSCrypto store using this key
name. For openssl, there is not "permanent"
key storage and everything works fine.

To correctly test this, you need to either delete the key from your MSCrypto
keys store or login as a different user (with different key store). I
believe Dmitry already suggested this before but I missed the point then :(

Aleksey

Edward Shallow wrote:
> Here they are ... 
> 
> -----Original Message-----
> From: xmlsec-bounces at aleksey.com [mailto:xmlsec-bounces at aleksey.com]
> On Behalf Of Aleksey Sanin
> Sent: January 12, 2006 1:01 AM
> To: ed.shallow at rogers.com
> Cc: xmlsec at aleksey.com
> Subject: [Bulk] Re: [Bulk] Re: [Bulk] Re: [Bulk] Re: [xmlsec] Verify - 
> OpenSSL vsmscrypto
> 
> Can you share the designed-enveloped.xml and upu-cacert.der, please?
> 
> Aleksey
> 
> Edward Shallow wrote:
>> Aleksey wrote:
>>
>> Please, try to reproduce the problem with xmlsec command line utility.
>>
>>
>>
>>
_______________________________________________
xmlsec mailing list
xmlsec at aleksey.com
http://www.aleksey.com/mailman/listinfo/xmlsec