[xmlsec] xmlsec-mscrypto code review (patch #3)

[Wouter]

>
>>>xmlSecMSCryptoX509StoreVerify() :
>>>...
>>>
>>>
> The certificate chain is a list of certificates cert_0, cert_1, cert_2,
> ...., cert_N
> where
>        Subject(cert_k) = Issuer(cert_k+1) where k = 0, ..., N - 1
> The chain is valid if and only if
>     1) each cert in the chain is good (i.e. it has valid signature on
> itself, valid time
>     restrictions not before/not after, it is not revoked by some CRL,
> ...);
>     2) the root of the chain (cert_0) is trusted by application
> You are right and xmlsec wants to use crypto engines to create certs
> chain. In typical
> case xmlsec has a certificate it is interested in and it just asks
> crypto engine if there is a
> valid chain for this certificate (using trusted certs in crypto engine
> and untrusted certs
> from the xmlsec and crypto engine). Unfortunately, MSCrypto does not
> provide
> such a function (to be precise, as I wrote in the email, this function
> is not available
> on Windows 9x). Instead it has a function
> "CertVerifySubjectCertificateContext(cert, issuerCert)"
> that (as far as I can understand) simply does a check that
>     - cert is good (see above what does this mean)
>     - Subject(issuerCert) == Issuer(cert)
> This check validates that issuerCert + cert can be a part of
> certificates chain but it does not
> validate the cert! Your code did not construct the certs chain longer
> than 2 certs and it did not
> verify that chain's root is trusted. Which is a big security hole from
> my point of view :)

Yes, that is (of course) a security hole, and the code was not meant to
behave like that. However the function CertVerifySubjectCertificateContext
can also validate against CRL and current (local system) time. The CRL
however must reside in the same certs store as the certificate, and it is
not exactly clear to me how the MS verification proceeds internally. What
I did is make seperate routines that check the certificate against given
time, and against any given CRL. But what to do when no CRL is available?
Just mark the cert as invalid, and disable it for usage in the lib? It may
well be that another protocol is used for revocation checking. MS Crypto
API does not have any CRL available for you, that must be handled by the
application itself.

>
> The whole question about trust in the X509 PKI model is based on which
> certs you (your
> application) are marked as "trusted".  xmlsec library does not involved
> in these descsision.
> It's just something your have to do yourself as a system architect.

> However, xmlsec command line
> utility provides a way to say: I trust this certificate ("--trusted"
> option). The exact meaning
> of this is
>         "the cert specified with --trusted option can be root cert
> cert_0 for a valid certificates chain".
> If you have no trusted certs then you have no valid certificates chain.
>
> Current xmlsec-mscrypto implementation maintains its own list of trusted
> certs in the keys manager.
> As I wrote before, certs marked as "trusted" in the MS Crypto certs
> store are not considered as such
> by xmlsec due to the MSCyrpto API restrictions. I think it's a good idea
> to enable this functionality
> but it's a separate big task from the code review I did. My change was
> to just plug in a security hole
> in the
>  certificates processing.

You're right, and as far as I know, in MS Certs store certificates are
even without revocation checking trusted there, not to mention other
'features' bugs MS has in the certificate validation scheme their using
(who knows the scheme in the first place?)

But thanks for you explanation, it sheds some light in my darkness :) I
agree that the real validation of the certificates, if you want to do it
full, can better be seperated from the lib, since it involves quite some
complex processing.

Wouter