///////////////////////////////////////////////////
// Functions of crypt32.dll that are implemented

*********** Key ***********
**   F = FIXME (Stub)
**   + = Function present and complete
**   - = Function present but incomplete

** Source:  cert.c
*******************
F: CertAddCRLContextToStore
F: CertCloseStore
-: CertCreateCRLContext
F: CertEnumCertificatesInStore
F: CertFindCertificateInStore
F: CertFreeCRLContext
F: CertFreeCertificateContext
F: CertOpenStore
F: CertOpenSystemStoreA
F: CertOpenSystemStoreW
F: CertSaveStore

** Source:  main.c
*******************
F: CryptGetOIDFunctionValue
F: CryptProtectData
F: CryptRegisterDefaultOIDFunction
+: CryptRegisterOIDFunction
+: CryptSIPAddProvider
F: CryptSIPLoad
F: CryptSIPRemoveProvider
F: CryptSIPRetrieveSubjectGuid
F: I_CryptCreateLruCache
F: I_CryptFindLruEntryData
F: I_CryptFlushLruCache
F: I_CryptFreeLruCache


/////////////////////////////////
// Design & Implementation notes

It appears as if there are only 2 functions that are fully implemented and functioning in crypt32.  Most of the functions are either not defined or single-statement FIXME stubs.  The 3 functions that are implemented are CertCreateCRLContext (cert.c), CryptRegisterOIDFunction (main.c), and CryptSIPAddProvider (main.c).

We decided to start by writing a conformance test for CertCreateCRLContext because it appeared to be the only working function in cert.c; however, while we were developing a test plan for the function we soon discovered that the function implementation was less than 50% complete.  According to MSDN, the function is supposed to take an encoded certificate revocation list (CRL) in raw format and create a PCCRL_CONTEXT structure, which contains all of the CRL data packaged so each field can be accessed easily.  The current wine implementation of CertCreateCRLContext just creates a new PCCRL_CONTEXT structure and copies the encoded data into one of the fields; no data decoding is performed so the returned structure is no more useful than the encoded data.

The specifics of CryptRegisterOIDFunction and CryptSIPAddProvider are not documented on MSDN.  Additionally, MSDN's documentation of the function's operation is not much more descriptive than the function name itself.  "CryptRegisterOIDFuction register a DLL containg the function to be called for a specific encoding type..."  The wine code mainly adds entries in the registry, which is usually how Windows registers components, but the MSDN documentation does not specify which registry keys are created.  A quick check through our system's registry seems to confirm wine's method for registering functions.  CryptSIPAddProvider works in a similar manner to CryptRegisterOIDFunction, in that the SIP provider is added by adding entries to the registry.

We've decided not to write a test for CertCreateCRLContext because it is not complete.  We are planning to write conformance tests for the other 2 functions with the assumption that the DLLs are registered in the usual manner that windows registers DLLs.