But why do you need to store all this cruft? If it's a
legacy/superseded decryption key, all you need is the
private-key components for decryption (usually stored in a
highly compact card-specific format) and the
issuerAndSerialNumberHash so you can locate it (in fact for
any decryption key, even a currently active one, you don't
actually need to store the cert). The overhead for the non-
private-key components would probably be 50-100 bytes,
depending on how much other stuff your PKCS #15
implementation stores alongside it. So your card contains
the current decryption key and its cert, and one (or possibly
more, although you probably need to ask why the user is
losing that many keys) decryption keys and the index info
needed to find them. The indexing overhead for half a dozen
decryption keys is going to be less than that for a single
certificate.
Sounds good, but I suppose we still need to select the keys somehow
(using the certs) through the CryptoAPI CSP and RSA CrypTokI interface,
so that the applications are satisfied.
I assume PKCS#11 is not that a big problem in terms of key
types/parameters since it recognises keys with key usage bits and relays
key parameters from the PKCS#15 structure, but if I don't remember
incorrectly, MSoft CSP is a problem since it only recognises two types
of keys (AT_KEYEXCHANGE and AT_SIGNATURE) and thus it has no clue about
the key usage bits. And both interfaces can do the mapping between
public keys and corresponding private keys.
But I don't recall if there is an attribute that could store
issuerAndSerialNumber in either PKCS#11 or CSP specifications. So could
we really relay this info to apps ?
This implies more or less that the applications have to locate the
decryption key (private key) based on certificate comparison (or public
key comparison) to locate the related public key. And when using
certificates, comparing issuerAndSerialNumber is not good enough since
it only recognises the certificate, not the entity nor the key pair
described in the cert.
If we compare the subject and issuer data (key ids, subject and issuer
names, subject and issuer unique ids), we recognise the entity
identified by the certificate, not the certificate itself - and in my
opinion, this is what we are after when we are using certificates. Eg.
in S/MIME, we figure out if the encrypted mail is really intended to the
entity trying to open it rather than figuring out if the certificate
linked to the recipient's private key he/she is trying to use in
decrypting the mail, is the same certificate that was used to encrypt
the mail.
Saku.