Douglas E. Engert wrote: > > > Glenn Barry wrote: >> Glenn Barry wrote: >>> Attached are the PSARC fast-track case proposal and man pages. >>> >>> A few notes: >>> * Sam said on the mitdev list that these interfaces are not fully >>> stable yet so we've given them a Stability level of Volatile >>> * Those interested in the pkcs11 slotid/certid issue pls take a >>> close look at the note I added and make sure it gives both sides a >>> decent summary >>> * We've left the pkcs11 module_name keyword in for now but may >>> remove it per the thread on this list last week. >> >> We've finally got pkinit w/smartcard tested (thanks Doug, IainM, Sun-Ray >> team, Val, Tony) so we need to finalize these interfaces asap and >> submit the ARC case. >> >> We've decided to remove the PKCS11 module_name opt for now and require >> the PKCS11 module to be installed as a crypto provider via >> libpkcs11(3LIB). Although we think we have the linker magic (thanks >> Nico and >> RodE) to make it happen directly the bigger issue is we need >> more experience/discussion with the module(s) under libpkcs11(3LIB) to >> see if it's necessary and a good idea (legal, technical, etc) to have >> a direct option. > > I think you are making a mistake removing the module= and using libpkcs11 > directly: > > o Libpkcs11 is used by many applications, not just ones needing > access to authentication or signing material. Every provider gets > loaded and initialized when libpkcs11 is called. > > o An individual provider may have high overhead costs when loaded. > For example opensc-pkcs11 may have to access a smart card to get some > of the information that may be needed. I have seen sshd load libpkcs11 > that loads opensc-pkcs11 that then reads the cert from the card > even though sshd should not be doing anything with the smartcard. > even klist will cause the card to be accessed. This adds 5 seconds to > the execution of each of these commands! > > o A individual provider may return more then one slot, depending on > its configuration. Thus any slot renumbering done by libpkcs11 > may change between invocations of libpkcs11 thus making slot_id= > a useless parameter. (I have not looked at the mapping in libpkcs11 > for slots. If it does something like 10*p+s where p is a provider > index > and s is the slot from the provider then this might be OK.) > > o If additional readers or tokens are plugged in between calls > the slot mapping in an individual provider may change too. > > o As Nico pointed out "First, Solaris supports a notion of multiple > seats, including remote seats (e.g., via Sun Ray)." libpkcs11 > as far as I can tell has no way to limit access readers based > on the "seat' of the user. > > o opensc-pkcs11 may return multiple slots for the same card. This is > because pkcs11 C_Login can only provide one pin per session, but > a card may have multiple certs/keys each with different pin. It is > not clear how libpkcs11 will handle this. > > I would suggest that you leave the module= in the code, while some > of these issues are addressed by libpkcs11.
yea, that came-up in our weekly krb5 eng mtg Tues morn. I favored keeping the code in (but not ARC/doc-it yet) but there were some objections but I forget the details. Anybody strongly object to this? We can add a comment to the code saying the module_name opt can be changed or removed at any time (when/if we are fully happy with libpkcs11). Btw, I don't think I made this clear -- if we are not satisfied with libpkcs11 we can ARC/doc the module_name opt later. The current proposal does not prevent that (and I should make that more clear in the proposal). > > Many of these issues are caused by location of the user, multiple > usb devices, vagueness in pkcs11 associations between slots and readers, > and need to have multiple views of a card vis multiple slots. > Having to use pcscd also complicates this. > > I am familiar with opensc-pkcs11, but there might be other pkcs11 > libs provided by specific card vendors for Solaris, Have you looked > at any of them? Not yet. I have read some about MUSCLE and will likely test it next. But for this resync we're happy that the new MIT Kerb PKINIT feature works and agree more sc middleware stacks/configurations/cards need to be tested going forward. And hopefully libpkcs11 (and lower layers) can improve/evolve if need be to handle them. > > In regard to the opensc with multiple slots there are two options: > > 1) If an admin knows what cards are being used, they can modify > the opensc.conf to specify how many slots per card, and how many > virtual slots are defined. > > 2) The onepin-opensc-pkcs11.so might help. It was added I believe to be > used with some versions of Mozilla and some cards to simplify > the interface Mozilla would see. > > thx for the good info and comments. > >> >> And I'm sure there will be more refinements to this base pkinit as we >> move >> on to the pkinit pam_krb5 support. >> >> Anyways, here's the ARC proposal diffs to remove module_name....thx, >> glenn: >> >> *** mit163-pkinit-psarc.txt.old.module-name Tue Oct 7 20:28:07 2008 >> --- mit163-pkinit-psarc.txt Tue Oct 7 20:42:55 2008 >> *************** >> *** 4,10 **** >> 1.2. Name of Document Author/Supplier: >> Author: Glenn Barry >> 1.3 Date of This Document: >> ! Sep, 2008 >> 4. Technical Description >> >> ABSTRACT >> --- 4,10 ---- >> 1.2. Name of Document Author/Supplier: >> Author: Glenn Barry >> 1.3 Date of This Document: >> ! Oct, 2008 >> 4. Technical Description >> >> ABSTRACT >> *************** >> *** 480,502 **** >> pkcs12-file-name is the name of a `PKCS #12' format file, >> containing the user's certificate and private key. >> >> ! >> PKCS11:[module_name=]module-name[:slotid=slot-id][:token=token-label][:certid=cert-id][:certlabel=cert-label] >> >> >> ! All keyword/values are optional. module-name specifies the >> ! location of a library implementing `PKCS #11'. If a value is >> ! encountered with not keyword, it is assumed to be the >> module-name. >> ! If no module-name is specified, the default is >> `/usr/lib/libpkcs11.so'. >> ! slotid= and/or token= may be specified to force the use of a >> ! particular smard card reader or token if there is more than one >> ! available. certid= and/or certlabel= may be specified to force >> ! the selection of a particular certificate on the device. See the >> ! `pkinit_cert_match' configuration option for more ways to >> select a >> ! particular certificate to use for pkinit. >> >> ! Note the slotid and certid keywords are controversial as some Sun >> ! Engineers believe they are a bad idea as there is no guarenteed >> ! ordering of slots returned from C_GetSlotList (for slotid). The >> ! MIT distro developers responded with (and I quote): >> >> The problem with using slot labels is that some devices will >> have multiple slots all with the same label but different >> IDs. OpenSC does this for example. The only way to >> --- 480,508 ---- >> pkcs12-file-name is the name of a `PKCS #12' format file, >> containing the user's certificate and private key. >> >> ! >> PKCS11:[slotid=slot-id][:token=token-label][:certid=cert-id][:certlabel=cert-label] >> >> >> >> ! All keyword/values are optional. PKCS11 modules (for example, >> ! opensc-pkcs11.so) must be installed as a crypto provider under >> ! libpkcs11(3LIB). slotid= and/or token= may be specified to force >> ! the use of a particular smard card reader or token if there is >> ! more than one available. certid= and/or certlabel= may be >> ! specified to force the selection of a particular certificate on >> ! the device. See the `pkinit_cert_match' configuration option for >> ! more ways to select a particular certificate to use for pkinit. >> >> + Notes: >> + >> + * The MIT distro allows a module_name=path keyword/value to >> load the >> + PKCS11 module directly but Solaris has libpkcs11(3LIB) so we've >> + disabled that keyword and thus require the PKCS11 module to be >> + installed as a crypto provider (see cryptoadm(1M)). >> + >> + * The slotid and certid keywords are controversial as some Sun >> + Engineers believe they are a bad idea as there is no guarenteed >> + ordering of slots returned from C_GetSlotList (for slotid). >> The >> + MIT distro developers responded with (and I quote): >> + >> The problem with using slot labels is that some devices will >> have multiple slots all with the same label but different >> IDs. OpenSC does this for example. The only way to >> *************** >> *** 528,534 **** >> >> * The MIT Kerberos plugin framework API will not be exposed at this >> time. >> * pam_krb5(5) support for PKINIT will be added in a future project. >> - * <gtb: add smartcard middlewhere status in OpenSol> >> * RFC4557 (PKINIT with OCSP) is not in the MIT Kerberos PKINIT >> module and >> won't be delivered with this project >> >> --- 534,539 ---- >> >> >> >> _______________________________________________ >> kerberos-discuss mailing list >> kerberos-discuss at opensolaris.org >> http://mail.opensolaris.org/mailman/listinfo/kerberos-discuss >> >> >
