On 02/08/2011 16:22, Felipe Blauth wrote: > Java Cryptographic is based on JCA/JCE arquitecture. The document at > http://download.oracle.com/javase/1.5.0/docs/guide/security/p11guide.html , > preety much explains everything you need to know. I'll have to reread it.
> It says, for example, > that only trusted certificates or pairs (key, certificates) are listed > as aliases from a Java perspective. Noticed that. So no way to use plain keypairs w/o certs... >> - once I can read a cert, how could I determine which slot I should >> authenticate against to use the corresponding private key? > The slot is fixed at the properties file. SUNPKCS #11 demands that you > use diferent properties files for diferent slots. I'm generating the 'config' file on-the-fly anyway, but I'd need a method to know what-is-where. >> - should I avoid SunPKCS11 and base my program on "simple" PC/SC? > I would say no. If you can code in C, it is better to use pure C PKCS > #11 (or some helper like libp11 or pkcs11-helper), since working with > APDU's is not easy (nor necessary). If you need to stick to Java, maybe > JNI is the answer. I usually do C, but this time I need a java applet for: 1) a web-based password manager I have to write for the office 2) safely and strongly authenticate users to a plain HTTP page (very shared-hosting friendly!) -- I already can authenticate users w/ a smartcard (on https), but it needs Firefox to load its PKCS11 that "locks" the card and no other process can use it. I don't really like JNI since it usually needs uncommon client-side libraries, that's why I thought about pcsc (even if, after all, it's JNI anyway), since I already studied it and deps-wise it doesn't need anything more than the minimum. BYtE, Diego. _______________________________________________ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel