On Wed, 17 Dec 2014, Nikos Mavrogiannopoulos wrote: >On Tue, 2014-12-16 at 17:42 -0600, Nico Williams wrote: >> The rationale is this: >> - you may have a PKCS#11 library with various slots, and you may have >> builtin tokens as well as removable tokens, and... > >Correct. > >> - you need to intelligently pick one at logon time so you don't prompt >> the user for PIN entry for tokens they don't have access to (e.g., >> the TPM), just the one smartcard they plugged in. > >Correct. > >> PKCS#11 is pretty lousy at this, and all we have to match on are the >> various slot and token attributes. >> There are tokens that won't let you list public objects without PIN >> entry. And there are tokens where incorrect PIN entry can lead to >> logout. And PAM has limits as to what it can do in terms of >> intelligently prompting a user for a slot/token/object. > >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. 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. also, the PKCS#11 URI can be used to identify PKCS#11 objects, tokens, and libraries. I think that adding attributes to add the last major element, a token, is a good idea. the updated text would have to provide information about general unreliability using the slot ID, for example. Jan. -- Jan Pechanec <jan.pechanec@xxxxxxxxxx>