This discussion should probably move away from coolkey-devel and into the cryptoki mailing list (cryptoki@xxxxxxxxxxxxxxx).
> 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.
In the general case, there are numerous certificate attributes that you could examine: CKA_SUBJECT, CKA_ISSUER, CKA_SERIAL_NUMBER, CKA_HASH_OF_SUBJECT_PUBLIC_KEY. Unfortunately, the only attributes that are required are CKA_SUBJECT and CKA_VALUE. There's also the CKA_CERTIFICATE_CATEGORY attribute which can be used to identify end-user certificates.
But the PKCS#11 standard does not have the rich array of certificate identification functions or attributes that an application may usually require. In the worst case, as you note, you need to decode the certificate and get whatever info you need for identification.
In my case, I need to know which certificates are suitable for smartcard logon to Active Directory. This means decoding each certificate on the token, checking the extensions for the existence of a UPN in the subject alternative name extension, and for the existence of smartcard logon oid in the extended key usage extension.
For CAC, if you want to do email signing as opposed to email encryption, then there is no standard across all PKCS#11 implementations that will allow you to unambiguously select the desired certificate. The application needs to load each certificate on the token to determine which one is for email signing, which one is for email encryption, and which one is for authentication.
Since I am only interested in the certificate that can be used for smartcard logon, I am toying with the idea of only making the email signing certificate visible to PKCS#11 to make this easier.
> As far as mechanisms go, it can take a few seconds to get a mechanism list
> from the card/PKSC11 lib. It's uch 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.
That's a valid approach. But you do need to use openssl to generate a SHA1 hash.
> 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've seen commercial PKCS#11 implementations that have CKM_SHA1_RSA_PKCS listed in the supported mechanisns, with CKF_ENCRYPT flag set (PKCS#11 only permits CKF_SIGN and CKF_VERIFY operations here).
But C_SignInit() should only succeed for a mechanism if that mechanism is listed in the supported mechanisms list and that mechaninism has the CKF_SIGN flag enabled.
So it's not unusual to find dodgy PKCS#11 implementations.
_______________________________________________ Coolkey-devel mailing list Coolkey-devel@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/coolkey-devel