Martin Paljak wrote:
Thanks!

I was only trying to figure out if there is any difference in 2.11 vs 2.20 handling.

2.20 allows slots to be added during the lifetime of a cryptoki application. Can you also explain how NSS handles the feature or any gotchas in implementing support for hotpluggable PC/SC readers? If/when does NSS call C_GetSlotList with NULL to update the slot list?

(I'm currently going through updating OpenSC PKCS#11 module to be more 2.20 compliant. Usability via Firefox is a key problem)

m.
NSS accepts new slots from either kind of module, but it does require application support. There an NSS called SECMOD_UpdateSlotList() which queries the module to see if new slots were added. Usually the application would have to call this function itself. (NOTE: as per PKCS #11 NSS accepts new slots but does not allow old slots to be deleted --- though they can be marked 'removed' or 'not present'.

SECMOD_UpdateSlotList() does it's check as follows:

It calls C_GetSlotList(FALSE, NULL, &count). If count is greater than the current count, it then calls C_GetSlotList(FALSE, slotIDs, &count) to get the list. NOTE that per the PKCS #11 spec we expect that count can only change on a call with NULL for the slot list (since slot list has to be allocated based on the previous C_GetSlotList() call.

Firefox does not call SECMOD_UpdateSlotList directly.

Firefox (ast least 2.0 and later) uses SECMOD_WaitForAnyTokenEvent() for any module that has removable slots. This does one of 2 things: If the module supports C_WaitForSlotEvent, it calls C_WaitForSlotEvent. If that function returns a slot that NSS does not yet know about, NSS will call SECMOD_UpdateSlotList(). If the module does not suport C_WaitForSlotEvent, NSS will pull the module periodically both calling SECMOD_UpdateSlotList and checking any change in the presence status of the token.

So from the PKCS #11 module point of view, to get this to work with Firefox:
1) make sure you have at least one removable slot in your module (it can always be disabled if you like). 2) when you add new modules, bump the C_GetSlotList count when slotID's is NULL. 3a) If you don't support C_WaitForSlotEvent you should be good to go (though I don't recommend this because it causes Firefox to pull your token. 3b) If you do support C_WaitForSlotEvent, return your new slotid and Firefox will automatically recognize it.

bob
On 05.12.2008, at 19:29, Nelson B Bolyard wrote:

Martin Paljak wrote, On 2008-12-05 07:03:
Hi!

PKCS#11 modules advertise its versions in two different places: in the
structure returned by C_GetFunctionList and in C_GetInfo. What happens
if those versions mismatch or which one has higher priority?

Answering only for NSS,

NSS ignores the value in the structure returned by C_GetFunctionList, and
only pays attention to the value in the structure returned by C_GetInfo.

Does the version number change the way NSS (or Firefox in that matter)
behaves?

NSS requires that the major version number be exactly 2. The minor version
number affects two aspects of NSS's behavior towards that module.

1) It affects the value of the argument passed to C_Initialize.
If the minor version number is zero, NSS knows that it must pass a NULL
argument to C_Initialize, and must provide its own locking around many
calls to PKCS#11 functions, because v2.0 modules are not defined to provide
their own.  Otherwise, NSS passes the address of a CK_C_INITIALIZE_ARGS
structure to C_Initialize, and determines whether the module requires
external locking through other means.

2) It affects how NSS waits for events from slots, such as token insertion
and removal events.
If the minor version number is non-zero, NSS uses C_WaitForSlotEvent.
If the minor version number is zero, or if C_WaitForSlotEvent returns
CKR_FUNCTION_NOT_SUPPORTED, NSS uses its own algorithm, polling periodically
to wait for slot events.
_______________________________________________
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

--Martin Paljak
http://martin.paljak.pri.ee
+372.515.6495




_______________________________________________
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

Attachment: smime.p7s
Description: S/MIME Cryptographic Signature

_______________________________________________
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

Reply via email to