Martin Paljak wrote, On 2008-12-10 03:50: > On 10.12.2008, at 8:08, Nelson Bolyard wrote: >> 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. > > 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. _______________________________________________ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
