Thanks for your answer, but does the Keystore implementation support hardware tokens like smart card??,
https://developer.mozilla.org/en-US/docs/JSS Java provides a JCE provider called SunPKCS11, see Java PKCS#11 Reference > Guide<http://download.java.net/jdk7/docs/technotes/guides/security/p11guide.html>, > SunPKCS11 can be configured to use NSS module as the crytographic provider. > If you are planning to just use JSS JCE provider as a bridge to NSS's FIPS > validated PKCS#11 module, then the SunPKCS11 JCE provider may do all that > you need. Note that Java 1.5 claimed no FIPS compliance, and Java > 1.6<http://java.sun.com/javase/6/docs/technotes/guides/security/enhancements.html> > or > higher needs to be used. *A current limitation to the configured > SunPKCS11-NSS bridge configuration is if you add a PKCS#11 module to the > NSS database such as for a smartcard, you won't be able to access that > smartcard through the SunPKCS11-NSS bridge. * If you use JSS, you can > easily get lists of modules and tokens that are configured in the NSS DB > and freely access all of it. furthermore, check this: http://www.mozilla.org/projects/security/pki/jss/provider_notes.html > The following classes don't work very well: > > > - *KeyStore:* There are many serious problems mapping the JCA keystore > interface onto NSS's model of PKCS #11 modules. The current implementation > is almost useless. Since these problems lie deep in the NSS design and > implementation, there is no clear timeframe for fixing them. Meanwhile, the > org.mozilla.jss.crypto.CryptoStore class can be used for some of this > functionality. > > On Fri, Apr 12, 2013 at 4:54 AM, helpcrypto helpcrypto <helpcry...@gmail.com > wrote: > 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". > > Yes, that would be a wise choose for CKA_ID but as I told you our provider is doing that and the PKCS#11 spec doesn't push him to do otherwise. > > > 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 > -- Jaime Hablutzel - RPC 987608463 -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
