|
G'day,
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.
-- Geoff |
_______________________________________________ Coolkey-devel mailing list Coolkey-devel@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/coolkey-devel
