> 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

Reply via email to