G'day,
> > 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
> > layer and not in the raw token itself.
>
> There already seems to be some enforcement (such as cannot sign
> with CAC Email Encryption
Cert).
The PKI Applet specifications that I have
seen do not mention any restriction on using the PRIVATE SIGN/DECRYPT command
other than verifying the PIN first. I'm assuming that a signing operation using
the private key associated with the email encryption certificate will be
permitted by the PKI applet, and I will try this out later to confirm, but can
you tell me where are you seeing this enforcement?
> 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.
CAC was not designed with PKCS#11 in
mind. It is not an API itself, but a collection of java applets and a set
of commands for accessing the applets on the card. The commands use standard
Global Platform instruction set and additional instructions.
In this respect it is no different to an
Axalto Cyberflex card (for example), which also has a collection of java applets
and a well-defined set of instructions for accessing those applets. I haven't
seen the instruction set that Axalto publishes, but it will be Global Platform
compliant, and in all probability does not include specific PKCS#11 data such as
CKA_ID values. Those values will be determined in the Axalto PKCS#11
library.
I don't understand your concern with
CKA_LABEL and CKA_ID attributes. The PKCS#11 standard mentions that CKA_ID
attribute is only meant to distinguish multiple key pairs held by the same
subject, but what the CKA_ID value should be is not defined or enforced. It is
suggested, for interoperability, that this value should be the subject key
identifier, but in reality it can be any value. Generally you locate the
certificate you want, get its CKA_ID value, then locate the private key with the
same CKA_ID value.
The CKA_LABEL is simply a description of
the object, and may in fact be empty. There is no further information in PKCS#11
about the value that should be found in CKA_LABEL.
> 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.
There are multiple references in the CAC
documentation to the Basic Services Interface (BSI), which is a C language
binding of an API defined in GSC-IS. I think there is a bundle in MUSCLE
that uses BSI? So if you write a BSI implementation that makes the
appropriate PC/SC calls using the CAC instruction set, then it should just "plug
in" to the MUSCLE PKCS#11 library (I'm not sure about this, but I think it is
possible).
I haven't implemented a BSI layer yet (I'm
calling PC/SC directly, as does Coolkey), but it looks trivial. There's no
reason why a PKCS#11 library could not be built on top of BSI. There are various
PKCS#11 vendors that provide a BSI implementation for CAC (such as
ActivIdentity).
> Is the PIV any better in this
respect?
Not to my understanding. It is a card
layout and communication standard, just like CAC.
>> 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.
PKCS#11 is that standard. But you must
remeber that the token generally provides limited cryptographic support. Most
tokens I have seen (Axalto, Gemplus, CAC, etc) will provide CKM_RSA_PKCS
mechanism for signing and decrypting. CKM_SHA1_RSA_PKCS may be provided
for signing, but that is generally not done in hardware. So either the PKCS#11
library provides the hashing algorithm, or this is left up to the application
before calling PKCS#11.
There are no standard set of mechanisms or
operations that must be provided on the token. The application needs to
interrogate the token to see what mechanisms it supports so that it can
determine how to perform its cryptographic operations. Typically openssl would
be used, and a EVP_PKEY that delegates its RSA operations to PKCS#11 would be
required.
But if you do not want to use openssl, then
your application must at least know how to generate SHA1 digests to be
interoperable with most tokens. SHA1 is not difficult. You also need to know how
to generate DigestInfo encodings, but these are constant and are defined in
PKCS#1.
-- Geoff
_______________________________________________ Coolkey-devel mailing list Coolkey-devel@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/coolkey-devel
