|[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]|
I'm pretty sure I traced this to the CoolKey-CAC code. I have used other PKCS11 implementations where this was not enforced.
Say an application wants to use one of the certificates on the CAC and specify which one on the command line or config file. Since the CKA_LABEL and CKA_ID are meaningless (across PKCS11 implementations), the only way to do this is to grab all certs, parse the X.509, and do the compare at that level. Lots of overhead for something that could be very straight forward if it were defined/standardized as a generic token interface.
As far as mechanisms go, it can take a few seconds to get a mechanism list from the card/PKSC11 lib. It's much faster for me to try to use CKM_SHA1_RSA_PKCS to sign something and fall back to creating the SHA1 hash myself (in OpenSSL) and use the card for CKM_RSA_PKCS. But if I try C_SignInit() with CKM_SHA1_RSA_PKCS, and the card does not support that mechanism, it should return an error, not a valid signature for the CKM_RSA_PKCS mechanism.
I guess I just need to admit that PKCS11 is not the generic token interface it was supposed to be, because most of the card vendors developed such card-specific APIs. I'm not a Windows developer, but I wonder if there are similar problems with various CSP vendors? Do you need to write your application to a vendor-specific CSP?
_______________________________________________ Coolkey-devel mailing list Coolkey-devel@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/coolkey-devel
[Home] [Fedora Legacy List] [Fedora Maintainers] [Fedora Desktop] [Red Hat 9 Bible] [Fedora Bible] [Fedora SELinux] [Big List of Linux Books] [Yosemite News] [Yosemite Photos] [KDE Users] [Fedora Tools]