Juan Lang wrote:
Hi Robert,
Robert wrote:
It depends on which part you are trying to
implement.
For the Certificate Store functions I would
recommend
implementing the "OID support functions" first,
I was taking a look at implementing the certificate store functions, and I was thinking (hoping?) I could avoid the OID stuff.
I don't know why you would want to do that. CryptGetOIDFunctionAddress is kind of like GetProcAddress and so all of the real work is done by CertDllOpenStoreProv which is provided by the certificate provider.
Maybe I'm missing something, but a cert will be stored in the registry in some well-known format, and as long as Wine handles the registry I/O bit, OpenSSL ought to be able to read the certs, right?
There are a number of built-in providers that will have to be implemented, which are shown at http://msdn.microsoft.com/library/default.asp?url=/library/en-us/security/se curity/certopenstore.asp
So CertOpenStore/CertEnumStore et al wouldn't need to do any asn.1 decoding, at least not from the get-go.
I'm not sure where the asn.1 decoding is done, but I'm guessing it is done in the CERT_STORE_PROV_FILE provider. You can implement the others independently of it.
What did I miss?
CertOpenStore is just a wrapper for CryptGetOIDFunctionAddress("CertDllOpenStoreProv" ...) and the real work is done elsewhere.
Rob