Ken Renard (CONTRACTOR) wrote:
Are you trying to use the PKCS #11 library as a generic crypto interface? That's specifically not encouraged by the PKCS #11 spec. You will almost always need a standard crypto library to 'fill-in' those areas the hardware does not support.Posted as Bugzilla Bug 218766 on 12/07/06If used via NSS, there is no problem. But as a PKCS library, bug still exists.
Other confusing stuff, not sure if this is CoolKey's area or DoD PKI's area...There isn't any CAC specified label. We set the label to something in the certificate itself.1. PKCS11 cert labels are arbitrary: while this is not technically incorrect, it is inconsistent from one PKSC11 library to another. Is there anything _actually_ on the CAC itself that can/should be used as the label? When trying to write code that selects cert based on label, you end up needing different labels for each PKCS11 lib
We can fix this to match the EKU of the certificates (with the proper mapping), but in practice the CAC keys will do any RSA private key operation, since it does raw operations, the card can't tell the difference between a signing and decryption operation. This means the enforcement of any attributes are in the middleware layer and not in the raw token itself.2. PKCS11 key usage attributes for certificates/keys. While they seem to match the EKUs of the certs (card applets), the SIGN/DECRYPT/etc. attributes of key objets are hard-coded in the lib.
Given the bug, I assume you mean lack of CKM_SHA1_RSA_PKCS as opposed to lack of CKM_DES_CBC or similar.3. "Other" Mechanism support. Is CKM_RSA_PKCS really the only supported PKCS11 mechanism for CAC?
So the CAC only supports CKM_RSA_X_509 itself (the PKCS #11 library supplies the RSA padding). The most CAC cards have support for things like SHA1 and DES on chip, but the CAC applet does not export those functions. To support CKM_SHA1_RSA_PKCS, the PKCS #11 module would need to supply a software implementation of SHA1. This is over kill since that SHA1 implementation should be supplied by the host library using PKCS #11 (NSS, for instance). CKM_SHA1_RSA_PKCS is used by tokens which cannot do CKM_RSA_X_509, or CKM_RSA_PKCS. Those tokens, however, cannot support SSL client auth and have become extremely rare.
It's library specific. CAC doesn't specify what the CKA_ID value is, so the library has to set it to something special. Applications should not be depending on a specific CKA_ID value, only that the value for the private key matches the value for the certificate (This is the PKCS #11 spec).4. Did the actual CACs recently go from a 1-byte to a 2-byte CKA_ID for cert/key objects or is the size of the CKA_ID value a library-specific thing?
Not in any document I've seen. The CAC api is very thin. It's basically a container applet that holds a private key, a certificate, and provides the ability to read the cert or operate with the private key. Everything else needs to be derived in some way.These really come down to support for CAC itself. Is the CAC "middleware" (interface with CAC Java applets) used to its fullest extent? Can info about the labels, and other attributes be looked up from the actual card instead of hard-coded assignments in the CoolKey/MUSCLE/etc library?
Is there even a decent mapping between the CAC applet API and the PKCS11 interface?It's taken me a long time to get my hands on one. The API is pretty simplistic. Most of the functions have to be generated on the fly.I don't know what the CAC applet API looks like, if this is even possible, but looking through the CoolKey code that supports CAC (as well as the code for MUSCLE-based implementations such as MacOS PKCS11), it just seems very arbitrary. If a CAC applet API document exists, I would like to see it.
Many of these inconsistencies is because you are looking at the CAC through different PKCS #11 interfaces. There is not CAC spec which says how to map CAC to PKCS #11. The things that are different are things that actually differ from token to token (how the certs are labelled, what the CKA_ID value is, etc.). The PKCS #11 spec tries to call out things applications can depend on an things that it can't. You'll notice that NSS is able to deal with the various different CAC implementations pretty well. That's because NSS has to deal with tokens that are even weirder than CAC.
In short your best bet is to build your applications on a crypto library that uses PKCS #11 (like NSS).
bob
Attachment:
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ Coolkey-devel mailing list Coolkey-devel@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/coolkey-devel
