crypt32: Revert 8ed5a777de6c9797a285829e07d7a27b3ed01257

[Juan Lang]

Ordinarily removing tests seems like a bad idea, but in this case it
seems the only rational response to the test failures the tests
produce.  The tests check the state of three bits with a variety of
certificate and CRL combinations.  One of these bits is apparently not
set by any version of Windows for any of the tests.  Testing its
absence doesn't seem correct, and I'll explain why in more detail in a
second.  Every permutation of the remaining two bits appears on at
least one Windows version, and no Windows version is obviously more
correct than the rest, so testing them doesn't seem worthwhile.

The one bit that doesn't appear to be set is the bit saying that a
certificate is revoked.  I created CRLs that do in fact revoke some of
the tested certificates, so it appears to me that the bit should be
set.  It's possible that Windows doesn't bother checking the
revocation status of a certificate whose anchor isn't trusted, but
it's impossible to test this in an automated regression test suite,
because adding a trusted certificate requires clicking OK (or its
equivalent) in a dialog.  The dialog is invoked by the system process,
so I can't use a dialog hook to suppress it.  I can test this
hypothesis manually, but it isn't possible to do so in an automated
way.

Another possibility is that Windows doesn't examine locally installed
CRLs to determine whether a certificate is revoked, and instead relies
on checking for an issuing distribution point or authority information
access extension to a) retrieve a recent CRL from the certificate
issuer, or b) check the certificate's revocation status with OCSP.
This is a two-part hypothesis.  The second part involves setting up a
web server to serve a CRL and to respond to OCSP queries, but that's
orthogonal to these tests.  The first part of the hypothesis is that
Windows is merely broken, and that it incorrectly assumes a
certificate isn't revoked even when it has a CRL revoking it.  Even if
this is correct, adding a test that constrains Wine to act in the same
way seems counterproductive.

Therefore I'm removing the tests for now.
--Juan
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0004-Revert-8ed5a777de6c9797a285829e07d7a27b3ed01257.patch
Type: text/x-patch
Size: 23681 bytes
Desc: not available
URL: <http://www.winehq.org/pipermail/wine-patches/attachments/20091129/bffc665e/attachment-0001.bin>