Some background on CAC.
The common access card contains a collection of Java applets. There is a well-defined API for the PKI applet, which allows access to a certificate, PIN verification and certain cryptographic operations. There should be three instances of the PKI applet on the card: one for the authentication certificate, one for the email signing certificate, and one for the email encryption certificate. In my application I am only interested in the email signing certificate since it contains the necessary Microsoft extensions for smartcard logon via PKINIT.
The PKI applet API is quite simple and it took me only a few days to construct the necessary smartcard protocol commands and make the necessary PC/SC calls to access a CAC (Coolkey is fine, but I just wanted a CAC implementation, not a CAC implementation + arbitrary MUSCLE app implementation, so I went back to the reference documentation and built my own).
But there is no PKCS#11 profile defined (that I am aware of) that sits above the PKI applet. There is a Basic Services Interface (BSI) layer defined, but nothing higher level than that. Any PKCS#11 implementation needs to make arbitrary decisions on how certain PKCS#11 meta data (such as token labels, CKA_ID attribute values, etc) are represented.
It should also be noted that CAC is being replaced by PIV, although there are plans to introduce transitional cards that are CAC with PIV.
> 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?
PKCS#11 token labels are not defined by CAC, so the actual values are arbitrary and up to the particular PKCS#11 library. Similarly for other meta-data such as token manufacturer ID.
> 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.
The PKCS#11 key objects have capabilities, but PKCS#11 does not enforce any restriction other than PIN verification on whether such capabilities can be accessed. It is really up to the application to get the key usage details from the certificate (and also check that the certificate has not been revoked, etc) and then decide if the appropriate PKCS#11 private key operation should be called.
> 3. "Other" Mechanism support. Is CKM_RSA_PKCS really the
> only supported PKCS11 mechanism for CAC?
The PKI applet on the CAC supports a PRIVATE SIGN/DECRYPT operation, and since the CAC only contains certificates with RSA keys, this means that only raw RSA with PKCS#1 padding operations are supported. This maps neatly to CKM_RSA_PKCS mechanism in PKCS#11.
Of course, the PKCS#11 library may implement SHA1 internally to allow CKM_SHA1_RSA_PKCS mechanism on top of CKM_RSA_PKCS, if necessary. But in general some other crypto library would be used to generate the SHA1 digest and create the necessary ASN.1 DigestInfo encoding before calling C_Decrypt or C_Sign.
> 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?
How a PKCS#11 CKA_ID attribute is defined is up to the PKCS#11 library. This has nothing to do with CAC. The PKCS#11 library built on top of CAC can use arbitrary values, so long as the CKA_ID for the certificate, public key, and private key objects are matched. I think that Coolkey uses the PKI applet instance here (in two bytes), but generally the CKA_ID would be the subject key identifier value.
> Is there even a decent mapping between the CAC applet
> API and the PKCS11 interface?
Not that I am aware of.
> 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.
Send an email to cacsupport@xxxxxxxxxxxxxxxx and ask for the CAC developers kit and some test cards. You may also wish to request the "DoD Implementation Guide for Transitional PIV II SP 800-73 v1" document as well.
_______________________________________________ Coolkey-devel mailing list Coolkey-devel@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/coolkey-devel