S/MIME MailMessage.ValidateSignature

+1 vote
asked Feb 13, 2010 by Daniel Spurny (400 points)
edited Feb 15, 2010

I need more informations about parameter ValiadtionOptions. I found in documentation option "UseCacheOnly". Because i do not have sources of lib i thing that: For verification of the certificate is used object X509Chain from System.Security.Cryptography.X509Certificates. I do not know using option "UseCacheOnly" means calling X509Chain with ChainPolicy.RevocationMode setted to "Offline" or "NoCheck". For my application i need verify signs in that way:

  1. Get CRLs from Windows store.
  2. Ignore state if in Windows store is not CRL. (Unknown Revocation Status)

I think that right call for that method is MailMessage.ValidateSignature(false, Rebex.Security.Certificates.ValidationOptions.IgnoreAllRevUnknown | Rebex.Security.Certificates.ValidationOptions.UseCacheOnly).

Second problem which i have is "detect issuing authority of signing certificate". For my application i need "filter" trusted certificate issuers (standard windows store has installed much more trusted issuers than i need). I think that there is two possibly ways to do this:

  1. Give to verification process another than standard windows "trusted certificate store".
  2. Do it manually by identifiing root certificate from Verifiyng X509Chain.

Can You give me some suggestion?

Applies to: Rebex Secure Mail

1 Answer

0 votes
answered Feb 15, 2010 by Lukas Pokorny (109,650 points)
edited Feb 15, 2010
 
Best answer

Problem 1

We don't use System.Security.Cryptography.X509Certificates or X509Chain to validate the certificates. We use Win32 API because when we wrote our certificate classes, X509Chain and X509Certificate2 were not available yet.

To construct a certificate chain for validation, we use CertGetCertificateChain function. When the "UseCacheOnly" flag is specified, the following flags are passed to this function:

CERT_CHAIN_CACHE_ONLY_URL_RETRIEVAL | CERT_CHAIN_REVOCATION_CHECK_CACHE_ONLY

According to the function's documentation, these have the following meaning:

CERT_CHAIN_CACHE_ONLY_URL_RETRIEVAL: Uses only cached URLs in building a certificate chain. The Internet and intranet are not searched for URL-based objects.

CERT_CHAIN_REVOCATION_CHECK_CACHE_ONLY: Revocation checking only accesses cached URLs.

So it looks like this is actually what you need!

Problem 2

I don't think it's possible to skip the standard Windows trusted certificate stores when constructing the certificate chain for validation using the CertGetCertificateChain function. It's possible to specify an additional store, but this is used in addition to trusted certificate stores then. So the second method - check the root certificates manually - is the one to use. You can keep using Rebex classes for this. CertificateChain.BuildFrom method can build a chain corresponding to the specified Certificate and the resulting CertificateChain class has a RootCertificate property to easily access the root CA certificate.

commented Feb 15, 2010 by Daniel Spurny (400 points)
Ok Problem 2 solution is acceptable for me. But Problem 1 answer disappointing me. My app working on server cut off the "internet" i have on intranet CRL for download. Does the "Validate" with passed arguments look into windows certificate store? Or it only looks in "Cache"?
commented Feb 15, 2010 by Lukas Pokorny (109,650 points)
My understanding us that "Windows Certificate Store" is only for certificates, not for revocation lists. CRLs have their own "CRL Store" that is actually called "CRL Cache". There is nothing wrong with this - just like each Windows account has a "Certificate Store", it also has a "CRL Cache". Both are managed by CryptoAPI and shared by all application that use the corresponding CryptoAPI functionality. Check out the MS article at http://technet.microsoft.com/en-us/library/bb457027.aspx for more information about this if interested.
commented Feb 16, 2010 by Daniel Spurny (400 points)
My understanding no 1: I think that CRL is X509 v2 format and norm X509 is whole about certificates. From that point i get thing that CRL is special certificate. It supports this fact: if i import CRL on Windows machine i see it in certificate store (utility "certmgr.msc").
commented Feb 16, 2010 by Daniel Spurny (400 points)
My understanding no 2: Is from utility certutil after you call command "certutil -URLCache crl" return this utility actual crl cache. You will delete this cache with calling "certutil -URLCache clr delete". What dissapointing me is fact if you clear one of the meaned stores (Windows certificate store, URLCache) there is no impact in other store. This, by my mean, say in windows are two places for CRL. I think there is question if we call CryptoApi with specified flags what this exactly do look strictly in cache or try put into cache crom WSCrtStore? At this time i unable find this information.
commented Feb 16, 2010 by Daniel Spurny (400 points)
Ok - i found it in the document which is reffered in third comment. There is exactly written: "Generally, CryptoAPI first searches the local certificate stores and the local cache for any CRL signed by the issuer (Certification Authority) of the certificate being validated. A cached version of a current CRL will always be used, rather than downloading a CRL that is available locally. The following logic is used to evaluate the CRL." That definitelly meaning we two have the truth. ;)
commented Feb 16, 2010 by Lukas Pokorny (109,650 points)
Thanks for this information, I was not aware that it's also possible to store CRLs "locally" in certificate stores! This doesn't seem to be used very often (there is only one old CRL in the certificate store on my machine), but it might be convenient in some situations.
...