On Fri, Apr 12, 2013 at 7:33 PM, Jaime Hablutzel Egoavil < hablutz...@gmail.com> wrote:
> Thanks for your answer, but does the Keystore implementation support > hardware tokens like smart card??, > It does, if you have a pkcs#11 library for your 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. > Yes, we have smartcards and use them with Java. A little example: http://stackoverflow.com/a/8429162 Nice day! > 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 > -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
