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.
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?
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.
>
> 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
>
>
--
Douglas E. Engert <DEEngert at anl.gov>
Argonne National Laboratory
9700 South Cass Avenue
Argonne, Illinois 60439
(630) 252-5444
