On Wed, Dec 17, 2014 at 03:52:50PM -0800, Jan Pechanec wrote: > On Wed, 17 Dec 2014, Nikos Mavrogiannopoulos wrote: > >I don't follow how the above require the slots to be known in order to > >figure where the object is. In gnutls we handle all of these use cases, > >and we don't need to know the slot at all. First you iterate all slots > >searching for the object, and then you login and search again. How would > >knowing the slot would have helped that? > > hi Nikos, if I expect a token to be inserted with some key > (rather then identifying the key to use) then specifying the slot > where such token is to be found seems useful to me. If I understand > it correctly, that's how pam_pkcs11 works. It has two configuration > options for this - slot description and slot ID. That only works with a PKCS#11 implementation like Solaris' libpkcs11. In general PKCS#11 slot IDs are unreliable, and that's why Nikos objects. > I know that the slot ID is cryptoki module specific. It would > have been nice if the specification supported token serial number as > it does for tokens. It needn't be stable even for one module. > the updated text would have to provide information about > general unreliability using the slot ID, for example. Please post proposed new text. Time is running out. Nico --