NSS and PKCS#11 versions of modules
Martin Paljak
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? Does the
version number change the way NSS (or Firefox in that matter) behaves?
--
Martin Paljak
http://martin.paljak.pri.ee
+372.515.6495
Nelson B Bolyard
> 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.
Martin Paljak
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.
> _______________________________________________
> dev-tech-crypto mailing list
> dev-tec...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-tech-crypto
Robert Relyea
> 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.
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
Martin Paljak
that slots can only be added. I cant find the place where it forbids
removing.
--
Sent from my mobile device
Martin Paljak
mar...@paljak.pri.ee
http://martin.paljak.pri.ee
GSM:+3725156495
Robert Relyea
> Thanks for tips! Could you point me to the line in spec where it says
> that slots can only be added. I cant find the place where it forbids
> removing.
>
we discussed this. The original agreement was that removal was
forbidden. Unfortunately the current spec does not forbid removing slots.
Firefox does not allow removal. It'll be a small change to the code to
handle removal, though it makes the slot checks more expensive. If you
could write a bug up I'd appreciate it.
The upshot, however, is if you want it to work in Firefox 2 or 3 you'll
have to disallow removals.
bob
Nelson Bolyard
> Martin Paljak wrote:
>> Thanks for tips! Could you point me to the line in spec where it says
>> that slots can only be added. I cant find the place where it forbids
>> removing.
>>
> That's what I get for not checking the spec after the meeting in which
> we discussed this. The original agreement was that removal was
> forbidden. Unfortunately the current spec does not forbid removing slots.
Bob, as you may know, the PKCS#11 working group will be meeting by telephone
Thursday morning at 6 AM Pacific Time. This seems like a good issue to
raise in that call. SEED will also be discussed in that call.
> Firefox does not allow removal. It'll be a small change to the code to
> handle removal, though it makes the slot checks more expensive. If you
> could write a bug up I'd appreciate it.
I don't recall the details now, but as I recall, there was some nasty
problem with shrinking sets of slots. I think it was simply that if the
module can shrink it while it is in use, it may cause the code outside
the module to reference a stale pointer. Something like that.
Do you recall the particulars?
> The upshot, however, is if you want it to work in Firefox 2 or 3 you'll
> have to disallow removals.
Indeed.
Martin Paljak
> Robert Relyea wrote:
>> Martin Paljak wrote:
>>> Thanks for tips! Could you point me to the line in spec where it
>>> says
>>> that slots can only be added. I cant find the place where it
>>> forbids
>>> removing.
>>>
>> That's what I get for not checking the spec after the meeting in
>> which
>> we discussed this. The original agreement was that removal was
>> forbidden. Unfortunately the current spec does not forbid removing
>> slots.
>
> Bob, as you may know, the PKCS#11 working group will be meeting by
> telephone
> Thursday morning at 6 AM Pacific Time. This seems like a good issue
> to
> raise in that call. SEED will also be discussed in that call.
is anything else I could provide before that time or clarifications
needed, let me know. If it is a "public" meeting I could as well call
too if required.
>> Firefox does not allow removal. It'll be a small change to the code
>> to
>> handle removal, though it makes the slot checks more expensive. If
>> you
>> could write a bug up I'd appreciate it.
>
> I don't recall the details now, but as I recall, there was some nasty
> problem with shrinking sets of slots. I think it was simply that if
> the
> module can shrink it while it is in use, it may cause the code outside
> the module to reference a stale pointer. Something like that.
> Do you recall the particulars?
How many slots does FF/NSS support (if I need to add new slots with
every different reader for 2 days, when will I run out of slots..)
Martin Paljak
On 09.12.2008, at 22:17, Robert Relyea wrote:
> Martin Paljak wrote:
>> Thanks for tips! Could you point me to the line in spec where it says
>> that slots can only be added. I cant find the place where it forbids
>> removing.
>>
> That's what I get for not checking the spec after the meeting in
> which we discussed this. The original agreement was that removal was
> forbidden. Unfortunately the current spec does not forbid removing
> slots.
> Firefox does not allow removal. It'll be a small change to the code
> to handle removal, though it makes the slot checks more expensive.
> If you could write a bug up I'd appreciate it.
Is the removal support related to NSS or it is a Firefox centric
issue? Does NSS support slot removal? I'll write a bug report ASAP
(against NSS or FF?)
> The upshot, however, is if you want it to work in Firefox 2 or 3
> you'll have to disallow removals.
Thanks for clarifications. I *do* want to work with FF 2.x and 3.x, so
I believe having a configurable in OpenSC to toggle the removal
feature (defaulting to false) in v2.20 mode will be OK.
Reading about the C_WaitForSlotEvent feature in NSS I was trying to
figure out if sending an unknown slot ID from C_WaitForSlotEvent
contradicts somehow the description of C_GetSlotList which tells, that
only after you have called it with NULL, the new slot listing (and
essentially the slot ID) becomes valid.
Most probably it doesn't matter if NSS calls C_GetSlotList just after
getting the unknown slot ID from the event waiting thread, but just
asking for comments.
Does NSS open more than two threads (one waiting for slot events and
one doing other tasks) to a module? If a module is designed to only
allow up to two threads to access the module (one thread blocked and
locked on C_WaitForSlotEvent and all other access being synchronized
with a module-global lock), is it OK from NSS point of view?
Thanks again,
Nelson B Bolyard
> On 10.12.2008, at 8:08, Nelson Bolyard wrote:
>>> Martin Paljak wrote:
>>>> Thanks for tips! Could you point me to the line in spec where it
>>>> says that slots can only be added. I cant find the place where it
>>>> forbids removing.
>>>>
>>> That's what I get for not checking the spec after the meeting in
>>> which we discussed this. The original agreement was that removal was
>>> forbidden. Unfortunately the current spec does not forbid removing
>>> slots.
>>
>> telephone Thursday morning at 6 AM Pacific Time. This seems like a
>> good issue to raise in that call. SEED will also be discussed in that
>> call.
>
> What kind of working group? Mozilla centric or some generic? If there is
> anything else I could provide before that time or clarifications needed,
> let me know. If it is a "public" meeting I could as well call too if
> required.
The PKCS standards are published by RSA laboratories, but they are
products of their respective working groups. There are two working
groups for PKCS standards, one specific to PKCS#11 (named "cryptoki"),
and one that covers all other PKCS standards (named PKCS-TNG).
For some PKCS standards, when the standard is published, its working
group becomes inactive, and ceases to function separately and any further
discussion of that standard takes places in the general PKCS-TNG list.
The one working group that has been active in an on-going fashion for
long (about a decade now) is the cryptoki group. They mostly communicate
by email through the working group's mailing list, but they occasionally
(rarely) have "work shops" and/or conference calls. One such event will
be tomorrow.
More information about these subjects may be found at
http://www.rsa.com/rsalabs/node.asp?id=2143
Discussions in the cryptoki mailing list is very strictly limited to
discussion of potential revisions or additions to the standard.
No other general discussion of cryptography or security is allowed.
>>> Firefox does not allow removal. It'll be a small change to the code
>>> to handle removal, though it makes the slot checks more expensive.
>>> If you could write a bug up I'd appreciate it.
>> I don't recall the details now, but as I recall, there was some nasty
>> problem with shrinking sets of slots. I think it was simply that if
>> the module can shrink it while it is in use, it may cause the code
>> outside the module to reference a stale pointer. Something like that.
>> Do you recall the particulars?
>
> How many slots does FF/NSS support
It's dynamic. No fixed limit. But presently, the list may only grow,
not shrink.
> (if I need to add new slots with every different reader for 2 days, when
> will I run out of slots..)
I think you're talking about a common implementation where the token and
reader are one and the same, and the act of connecting the token also
connects a new reader. One way to implement that in PKCS#11 is to add a
slot for every reader. But I don't know of ANY implementation that
actually works that way. The more common approach, used by MANY vendors,
is to re-use slots. When a reader is removed, the slot simply shows as
having the token removed. The slot never disappears during the lifetime
of that process. When a different reader is connected, it reuses an
existing slot that previously showed an absent token, unless all slots
are in use, in which case it adds a new slot.
IMO, that it definitely the preferred way to handle such removable readers.
Robert Relyea
>
>>>> Firefox does not allow removal. It'll be a small change to the code
>>>> to handle removal, though it makes the slot checks more expensive.
>>>> If you could write a bug up I'd appreciate it.
>>>>
>>> I don't recall the details now, but as I recall, there was some nasty
>>> problem with shrinking sets of slots. I think it was simply that if
>>> the module can shrink it while it is in use, it may cause the code
>>> outside the module to reference a stale pointer. Something like that.
>>> Do you recall the particulars?
>>>
spec might fail (in bad ways) if actual number of slots changed. It may
be they decided that the NULL pointer to get the count was all the
semantic that was needed.
>> How many slots does FF/NSS support
>>
>
> It's dynamic. No fixed limit. But presently, the list may only grow,
> not shrink.
>
>
>> (if I need to add new slots with every different reader for 2 days, when
>> will I run out of slots..)
>>
>
> I think you're talking about a common implementation where the token and
> reader are one and the same, and the act of connecting the token also
> connects a new reader. One way to implement that in PKCS#11 is to add a
> slot for every reader. But I don't know of ANY implementation that
> actually works that way.
Coolkey creates a slot for it. When the reader is removed, the slot
still exists, but is marked empty. When the same token is inserted, the
slot gets reused (in some cases the slot may reused for any new token of
the same time). In Coolkey's case whether or not a slot gets reused
depends on the reader driver and what name the reader gives the new
token. It's pretty easy just to mark the slot as empty until a new
reader drops in. Software already handles insertions an removals OK.
bob
Nelson B Bolyard
> Nelson B Bolyard wrote:
>> I think you're talking about a common implementation where the token and
>> reader are one and the same, and the act of connecting the token also
>> connects a new reader. One way to implement that in PKCS#11 is to add a
>> slot for every reader. But I don't know of ANY implementation that
>> actually works that way.
> Coolkey does. When you insert a token with reader the first time,
> Coolkey creates a slot for it. When the reader is removed, the slot
> still exists, but is marked empty. When the same token is inserted, the
> slot gets reused (in some cases the slot may reused for any new token of
> the same time). In Coolkey's case whether or not a slot gets reused
> depends on the reader driver and what name the reader gives the new
> token. It's pretty easy just to mark the slot as empty until a new
> reader drops in. Software already handles insertions an removals OK.
Yes, I believe you're saying that coolkey works as I described below.
This is in contrast to the scheme that I believe was being described by
Martin, in which when a reader is removed, the slot is actually deleted,
and not merely marked empty.