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. 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? So CertOpenStore/CertEnumStore et al wouldn't need to do any asn.1 decoding, at least not from the get-go.
What did I miss? --Juan
__________________________________ Do you Yahoo!? Yahoo! Small Business $15K Web Design Giveaway http://promotions.yahoo.com/design_giveaway/
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
--- Robert Shearman R.J.Shearman@warwick.ac.uk wrote:
CryptGetOIDFunctionAddress is kind of like GetProcAddress and so all of the real work is done by CertDllOpenStoreProv which is provided by the certificate provider.
<snip>
CertOpenStore is just a wrapper for CryptGetOIDFunctionAddress("CertDllOpenStoreProv" ...) and the real work is done elsewhere.
I couldn't find any evidence that this is the case for the built-in providers (file, reg, in-memory, collection) on my Win2k system. When I search through the registry, the only CertDllOpenStoreProv entry I find is for an LDAP provider.
Unless you know which DLLs implement the built-in providers, I'm still assuming crypt32 implements them itself. As far as why I'd want to do it this way, I'm assuming the most common usage is of the system provider, which is really just a reg provider with the root key predefined. That's where I'd like to start.
--Juan
__________________________________ Do you Yahoo!? Yahoo! Small Business $15K Web Design Giveaway http://promotions.yahoo.com/design_giveaway/
Juan Lang wrote:
--- Robert Shearman R.J.Shearman@warwick.ac.uk wrote:
CryptGetOIDFunctionAddress is kind of like GetProcAddress and so all of the real work is done by CertDllOpenStoreProv which is provided by the certificate provider.
<snip> > CertOpenStore is just a wrapper for > CryptGetOIDFunctionAddress("CertDllOpenStoreProv" > ...) and the real work is > done elsewhere.
I couldn't find any evidence that this is the case for the built-in providers (file, reg, in-memory, collection) on my Win2k system. When I search through the registry, the only CertDllOpenStoreProv entry I find is for an LDAP provider.
Unless you know which DLLs implement the built-in providers, I'm still assuming crypt32 implements them itself.
Yes, I assume that is the case since it doesn't appear to load any other DLLs when using the built-in providers mentioned.
As far as why I'd want to do it this way, I'm assuming the most common usage is of the system provider, which is really just a reg provider with the root key predefined. That's where I'd like to start.
Ok, but build a nice expandable framework and implementing the others should be relatively easy and could be taken on by others.
Rob
-
Juan Lang -
Robert Shearman