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(_dot_)pechanec(_at_)oracle(_dot_)com>