On 17/01/07, Valerie Anne Bubb <[EMAIL PROTECTED]> wrote:
On Tue, 16 Jan 2007, Alon Bar-Lev wrote:
> On 1/16/07, Ludovic Rousseau <[EMAIL PROTECTED]> wrote:
>> > This causes problems with PKCS#11 providers that fix the reader list
>> > when C_Initialize is called.
>>
>> So it is a bug in the PKCS#11 provider. No?
>
> No.
> PKCS#11 specification states a static reader map...
> Sadly for all, it does not support plug&play... :(
PKCS#11v2.20 does support getting a new slot list. I don't have
the current spec handy, but I believe it is with a new option
to C_GetSlotList().
In PKCS #11 v2.20, 28 June 2004, C_GetSlotList page 107:
"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."
and the last sentence of the paragraph is:
"On some platforms, or earlier PKCS11 compliant libraries, it may be
necessary to successfully call C_Initialize or to restart the entire
system. "
Still, 2.20 is still fairly new, so not everyone will support that.
That may be a problem. PKCS#11 provider using the "old" API and/or
application using the "old" API.
Bye,
--
Dr. Ludovic Rousseau
_______________________________________________
Muscle mailing list
[email protected]
http://lists.drizzle.com/mailman/listinfo/muscle
