On Mar 3, 2007, at 4:44 PM, Bob Relyea 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.
not as a generic crypto interface, but as a generic smartcard/token interface
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.
There already seems to be some enforcement (such as cannot sign with CAC Email Encryption Cert).
3. "Other" Mechanism support. Is CKM_RSA_PKCS really the only supported PKCS11 mechanism for CAC?Given the bug, I assume you mean lack of CKM_SHA1_RSA_PKCS as opposed to lack of CKM_DES_CBC or similar.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.
I have no problem doing the SHA1 part "above" the PKCS11 layer. If the card or PKCS11 library does not support a mechanism, it should return an error if you try to use it. It should not return the results of a different mechanism.
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.
What I'm reading is that the CAC API just does not align well with PKCS11. Since you need to know the internals of a PKCS11 library (what label strings or CKA_ID values are used), the idea of a generic smartcard interface library is just not applicable to CAC. Further, I would infer that the CAC was never designed in a way to support a generic interface. As an application developer, you would write your CAC application to use the "Acme Brand" CAC interface library. Just hope that Acme doesn't go out of business or stop supporting your OS.
Is the PIV any better in this respect?
In short your best bet is to build your applications on a crypto library that uses PKCS #11 (like NSS).
When writing a security application, adding a such a large library where I'm using only 1 or 2 functions is undesirable (support, security, size, memory, etc). All I need is a interface to the token, preferably something standard and consistent.
-Ken
Attachment:
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ Coolkey-devel mailing list Coolkey-devel@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/coolkey-devel
