Crypt32
Crypt32.dll is where most of the CryptoAPI is implemented. It supports encryption, decryption, and manipulation of certificates and related data structures. The actual encryption and decryption routines are implemented by a Cryptographic Service Provider, or CSP. The RSA enhanced provider was added by MichaelJung. JuanLang is implementing the certificate stores.
Currently crypt32 supports encoding and decoding of certificates and certificate revocation lists (CRLs) in DER format, and a reasonable subset of certificate stores and cryptographic messages.
TODO
CTLs
Certificate stores actually store certificates, CRLs, and certificate trust lists (CTLs.) Wine doesn't yet implement CTLs, as they seem to be used rarely. The only app I've seen so far that attempts to use a CTL is Windows Live Messenger (aka MSN Messenger.) It calls CertAddEncodedCTLToStore during its installation. The installation continues even though this fails, so it doesn't appear critical to support CTLs yet.
Messages
The CryptMsg and CryptMessage APIs implement cryptographic messages. These are either PKCS #7 messages, or the more recent CMS messages. There's a basic implementation of them in Wine, but it doesn't handle streaming mode for most messages. So far, Outlook seems to be the only app blocked on streaming mode.
Microsoft Root Certificates
Some Microsoft software won't install because the installation checks the PKCS7 message of a file, and it's signed by a Microsoft root certificate. The Microsoft root certificates aren't typically installed on a Linux system, so the resulting certificate chains aren't signed by a trusted root. One app that fails as a result is IE7:
Certificate Chains
The Wine version of CertGetCertificateChain only builds simple chains. Complex chains depend on CTLs, which remain unimplemented.
It also doesn't support very many extensions. For instance, it doesn't check for allowed usages. Consult RFC 3280 for more details on what's needed.
CertVerifyCertificateChainPolicy doesn't support the SSL policy. One key difference between the base policy and the SSL policy is that in the base policy, if a certificate omits the basic constraints extensions, it is assumed to be allowed to be a CA. According to RFC 3280, every CA cert must include a basic constraints extension, and must be allowed to be a CA. The SSL policy doesn't allow a cert to be a CA implicitly (by omitting a basic constraints extension.) See Microsoft Security Bulletin MS02-050 for more about that vulnerability.
Miscellaneous
- Lots more tests