Robert Relyea wrote, On 2008-12-10 17:12: > 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. >> 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
