2011/8/3 NdK <ndk.cla...@gmail.com>: > The wallet must allow for use of a smart card or a simple password > (obviously highly sensitive passwords will have to be restricted to > stronger method). Not really different at the programmatic level, since > I can store "anything" in the "encryptedPrivateKey" field: an actual key > or a reference to a token. Understood. Java signed applets seems the most homogeinic way of doing it. (Better than writing one script for each browser)
> That's exactly what I noticed. Seems the key is the "friendly flag" > that's (IMVHO) badly thought (since I can access both friendly and > unfriendly tokens w/ the same lib). Is that a opensc flag? (remember i dont use opensc, so dont know the internals) > And (more general question) why a slot identifies a pin? What about > "insecure" keys and their certs? See below. An slot doesnt need to have a PIN, as stated on PKCS#11 standard. Even if FF does a bad implementation, and always require a PIN using C_Login, the slot/token could return CKR_OK and continue. Our public cert is stored on a public area of our card, that can be readed and added to NSS without prompting for PIN. Maybe we are talking about different issues here. >> I think we should exchange experiences :P > Mine is just: too buggy to be actually used w/ smartcards, useful only > in the simplest scenarios. In my experience, i can guarantee that NSS is enough stable to be used with smartcard among with Java Applet. We have lot of users, and just a few of known problems. (I already talked about a PSM/NSS deep review)... > I can't retrieve now the bug #, but IIRC it keeps the session to the > token open. Maybe your card allows for more than one channel. No. Our card is a stupidcard rather than smartcard. I noticed FF try to retrieve the session that was previosly used (that is closed when smartcard removed and inserted on reader), but this is easily solved saying "CKR_INVALID_HANDLE" (was this CKR_, right?) Anyway, i agree...PSM/NSS has aspect that could be improved. (And the community...including you and me, could improve) > No, but writing 9 different apps is not the solution, IMVHO. We just have one applet (to rule them all) and some cross.browser js support to detect them. > Nope. You can install sw only if the policy allows you to do it. And > often (think about a kiosk) it's forbidden. A signed applet can AT MOST > have the same rights of the user, IIRC (I don't remember a poliy to give > an applet more rights than the ones assigned to the user running it...). Totally right. Then, your applet should be self-running...and that means no JSS. You should look for a method to locate your PKCS#11 module and so. If you go in this direction, let me know, cause will be our next target soon. >>> - handles multiple slots >> What you mean with this? > That's something I still couldn't understand well... > Reading PKCS11-v2.30b specs, it seems a slot is just a physical object > where a card can be placed. So a reader should present more than one > slot only if it accepts more than one token: > "Cryptoki provides an interface to one or more cryptographic devices > that are active in the system through a number of “slots”. Each slot, > which corresponds to a physical reader or other device interface, may > contain a token. A token is typically “present in the slot” when a > cryptographic device is present in the reader. Of course, since Cryptoki > provides a logical view of slots and tokens, there may be other physical > interpretations. It is possible that multiple slots may share the same > physical reader. The point is that a system has some number of slots, > and applications can connect to tokens in any or all of > those slots." (page 17). 1 - PKCS#11 standard was designed a long time ago, so consider it has several lacks, for example "concurrent access", "multiple pin auth/virtual slots"...or this "strange/complex explanation about slots" In the smartcard approach you and me are using, this is translated as: "One slot for each reader" When the card is inserted in the slot, the token info is retrieved and shown. In my case, as user should have only 1 card, we want to avoid problems, 'cause we have to code our library... we have just 1 slot, no matter which number of readers you have, and when a card is inserted, we loop trough all the readers to check if our card is present. Its not perfect, but works like a charm. > So I can understand that when I plug in another reader I get another set > of slots. Well..more or less, that will be the idea. > What I don't understand is why I get a slot for every PIN on > my card, plus a PnP (always empty) slot. You dont simply get an slot for evrey PIN... (as usual, EXPERTS: correct me if im wrong) If your smartcard has multiple pin auth system (like many applications, each on with a pin), thers should be a way to login on each one. Consider the following: smartcard with 2 apps, both of them containing certificates. How you should do to use any of these? If you map slot->reader->card, this cant be achieved. As the PKCS#11 standard doenst handle virtual slots, the way to do it its create one slot for each one. Understood now? > SunPKCS11 pulls this to the limit that I have: > 1) to know the slot I'll need to use before opening the KeyStore Sure...do you know the PKCS#11 module name? can you list the PKCS#11 modules? > 2) to supply the PIN to open the KeyStore, even if I only need access to > public objects I dont know if that is true, cause i dont remember, but i believe you, and this should be a "bug" on the interface. Regards _______________________________________________ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
