On Thu, Apr 11, 2013 at 11:59 PM, Jaime Hablutzel Egoavil <
hablutz...@gmail.com> wrote:
> Hi, I have a hardware token accesible via PKCS#11 which is storing private
> keys and certificate like this :
>
> certificate A, CKA_ID: 1234
> certificate B, CKA_ID: 1234
>
Hi Jaime.
In our case CKA_ID=hash(public key)...i think sha1.
This way its much more "friendly".
> priv key for certificate A, CKA_ID: 1234
> priv key for certificate B, CKA_ID: 1234
>
> Well, then I get 'certificate A' and
> call org.mozilla.jss.CryptoManager#findPrivKeyByCert passing it as a
> parameter and I can get 'priv key for certificate B' instead of 'priv key
> for certificate A' because of the way findPrivKeyByCert is implemented
> depending on 'PK11_MatchItem' method from NSS which in its documentation
> states:
>
We move from jss to KeyStore and we are happier since then.
>
> /*
> * given a PKCS #11 object, match it's peer based on the KeyID. searchID
> * is typically a privateKey or a certificate while the peer is the
> opposite
> */
>
> As long as now it could seem a problem with the hardware token
> manufacturer, repeating CKA_IDs for objects, but then if you see
> PKCS#11v2.20 spec, in *10.6.3 X.509 public key certificate objects*:
>
> *The CKA_ID attribute is intended as a means of distinguishing multiple
> > publickey/
> > **private-key pairs held by the same subject (whether stored in the same
> > token or not).
> > **(Since the keys are distinguished by subject name as well as
> identifier,
> > it is possible that keys for different subjects may have the same
> CKA_IDvalue without introducing any ambiguity.)
> > **
> > **It is intended in the interests of interoperability that the subject
> > name and key identifier
> > **for a certificate will be the same as those for the corresponding
> > public and private keys
> > **(though it is not required that all be stored in the same token).
> > However, Cryptoki does
> > **not enforce this association, or even the uniqueness of the key
> > identifier for a given
> > **subject; in particular, an application may leave the key identifier
> > empty.*
>
>
> So NSS should not depend only on CKA_ID, but it should use CKA_Subject too,
> but if you see the last bold section these attributes are not 100%
> trustable.
>
> I see this as a implementation problem, maybe after finding a 'matching
> item' NSS should check if it actually matches, and if it isn't it should
> resort to another strategy for finding the matching item.
>
> What do you think?
>
Just an opinion, but forget JSS and use Java Provider and Java Keystore;)
entries = ks.aliases();
while (entries.hasMoreElements()) {
alias = entries.nextElement();
//Check if its a cert with a private key
if (ks.isKeyEntry(alias)) {
...
--
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto
