Andrew, The application need not worry about co-locating the keys and operations on one slot, because not only is it a cumbersome task, but in some cases it is bad. For this reason, NSS (and I'm sure other PKCS11 implementations as well) gives you the GetBestSlot function, and automatically moves keys between tokens IF necessary.
Imagine a private key on a smart card which is often TOO slow for signature ops - typically the private key is migrated to a token that has a faster implementation of signature (provided the smart card is used in non-FIPS mode). So, while your concern is a valid one, the system takes care of the ugly stuff for you. In short, there is nothing we need to change.... -Tej Andrew Fan wrote: > > > Aleksey Sanin wrote: > > > Andrew, > > > > Will you please describe a use case scenario which you are > > trying to solve here? Why GetBestSlot from NSS does not work > > for you? > > As we know, a PKCS#11 system has one or more slots. application can > connect to token in any or all of those slots. The use case scenario > like: > 1. a high level application get a key object( symmetric or asymmetric > key handler ) from a slot; > 2. the application try to set the key into a xml encryption/signature > context; ( because the key handler is based on the slot which creates > it, it can not work with other slot in the system. ) > 3. the application call signature or encryption functions.( because the > internal key data only can identify the slot created by GetBestSlot, it > is possible that the action suffers a defeat. ) > > I think, in PKCS11 environment, if the keys are not created internally > in xmlSec, the problem will arise. > > Thanks, > Andrew > > > > > Aleksey > > _______________________________________________ xmlsec mailing list [EMAIL PROTECTED] http://www.aleksey.com/mailman/listinfo/xmlsec
