Re: [Opensc-devel] Need for simple C_Initialize [was: Issues connecting to OpenVPN with Smartcard]

[Douglas E. E. <dee...@an...>]

On 2/20/2013 11:56 AM, Martin Paljak wrote:
> On Wed, Feb 20, 2013 at 5:53 PM, Nikos Mavrogiannopoulos
> <n.m...@gm...> wrote:
>> And that looks like a very good reason why C_Initialize should be
>> simple in OpenSC and not take several seconds (e.g., by trying to probe
>> the inserted cards). Consider enabling smart card support with opensc in
>> a forking server and then realize that each child would wait 4-6 seconds
>> for C_Initialize on creation, irrespective whether smart cards are used
>> on it.
>
> True, I can only think of some forgotten specifics for 2.11 why slots
> are created on C_Initialize rather than C_GetSlotList.

Yes there is a difference.


PKCS #11 2.11, revision 1, November 2001

Section 11.5 Slot and token management functions

   All slots which C_GetSlotList reports must be able to be queried as valid slots by
   C_GetSlotInfo.  Furthermore, the set of slots accessible through a Cryptoki library
   is fixed at the time that C_Initialize is called.  If an application calls C_Initialize
   and C_GetSlotList, and then the user hooks up a new hardware device, that device cannot
   suddenly appear as a new slot if C_GetSlotList is called again.  To recognize the new
   device, C_Initialize needs to be called again (and to be able to call C_Initialize
   successfully, C_Finalize needs to be called first).  Even if C_Initialize is
   successfully called, it may or may not be the case that the new device will then be
   successfully recognized.  On some platforms, it may be necessary to restart the entire
   system.


PKCS#11 2.20

Section 11.5 Slot and token management functions

   All slots which C_GetSlotList reports must be able to be queried as valid slots by
   C_GetSlotInfo. Furthermore, the set of slots accessible through a Cryptoki library is
   checked at the time that C_GetSlotList, for list length prediction (NULL pSlotList
   argument) is called. If an application calls C_GetSlotList with a non-NULL pSlotList,
   and then the user adds or removes a hardware device, the changed slot list will only be
   visible and effective if C_GetSlotList is called again with NULL. Even if C_
   GetSlotList is successfully called this way, it may or may not be the case that the
   changed slot list will be successfully recognized depending on the library
   implementation. On some platforms, or earlier PKCS11 compliant libraries, it may be
   necessary to successfully call C_Initialize or to restart the entire system.


The way I read these, we could move the call for the card_detect out of
C_Initialize.  A 2.11 caller does not know if C_Initialize has done
anything with slots until a call is made that needs to get slots
and at that time the 2.11 caller expects the number of slots will be fixed
and would not be trying to use the 2.20 requirement to call C_GetSlotList
with a NULL pSlotList to get a new list of slots.

The issue is then if any internal OpenSC code depends on the card_detect being
called early.

>
> Martin
>
> ------------------------------------------------------------------------------
> Everyone hates slow websites. So do we.
> Make your web apps faster with AppDynamics
> Download AppDynamics Lite for free today:
> http://p.sf.net/sfu/appdyn_d2d_feb
> _______________________________________________
> Opensc-devel mailing list
> Ope...@li...
> https://lists.sourceforge.net/lists/listinfo/opensc-devel
>

-- 

  Douglas E. Engert  <DEE...@an...>
  Argonne National Laboratory
  9700 South Cass Avenue
  Argonne, Illinois  60439
  (630) 252-5444