> Since the minidriver is being built within the Microsoft Crypto > framework, rather then using OpenSSL SHA1, we could use a Microsoft > hash > function. > > Thus we do not depend on #ifdef ENABLE_OPENSSL for this one purpose. >
Ok, this is a good idea. I can make this change. One question though - it seems that the way things are currently designed place the _get_guid as a function of a pkcs15 card and not the minidriver. For example, pkcs15-tool seems to display the guid whether or not the minidriver is in use. What this means is that we would need to be able to generate a guid even if the minidriver is not enabled, and that this guid would then be different if you were not on Windows, or hadn't enabled the minidriver. I guess that currently this is all theoretical, as the guid is only practically used within the minidriver (as far as I can tell). Is there a plan to use this elsewhere? Is it acceptable for the guid to be different if the minidriver is not in use? I guess the real question is - why is the guid generation a function of the pkcs15 framework and not the minidriver? Are there future plans for this 'guid'? If so, and we need it to be the same, then we might need to rather build in some sort of hash generation functionality into the main code. Regards, Will _______________________________________________ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel