[Date Prev][Date Next] [Chronological] [Thread] [Top]

Re: support for arbitrary PKCS11 pin input method



Hi!

Am 11.10.2010 20:30, schrieb Howard Chu:

> Rich Megginson wrote:
>> Silvan Marco Fin wrote:
>>>   I searched through tls_m.c for means to enter the token PIN for a
>>> PKCS11 token. I found a call to PK11_SetPasswordFunc(). The callback is
>>> set to tlsm_pin_prompt(), which by itself uses tlsm_get_pin().
>>> tlsm_get_pin() only supports reading the PIN from file or via STDIN. To
>>> be usable within any form of gui, there would have to be some method to
>>> pass a GUI callback to ask for the PIN.

To clarify: GUI callback is too specific. In any application requesting
PINs to access some sort of crypto device, there would be the need of a
callback function which can be registered to openldap in the same way in
the same way openldap registers its own functions to the crypto library
(PK11_SetPasswordFunc() in this case), since we might not read from
STDIN and file is insecure, as is stated in the comments in tlsm_get_pin().

>> How would this work?  Would you pass in a callback function with your
>> private context, and this callback function would be called with the
>> current MozNSS context + your provided context?  What would be the
>> possible return values from your callback?  What should the code do
>> depending upon each return value?  Is there currently a way, via the
>> OpenLDAP API, to pass in such a function and context?

The parameters to the PK11_SetPasswordFunc() are described in

http://www.mozilla.org/projects/security/pki/nss/ref/ssl/pkfnc.html#1023128

Instead of tlsm_pin_prompt() the applications callback function should
be registered.

> For what it's worth, we need to add this feature for
> sasl_interactive_bind as well. Thus far, for the ldap_sasl interface all
> of the callback parameters have been passed on the function invocation,
> as opposed to being set by a separate ldap_set_option(). It makes for a
> clunky function signature, but seems safest in terms of re-entrancy...

 Is there a roadmap for these adaptions or can you give any hint, on
wether this will be done in the near future?

 Kind regards,
  Silvan


Attachment: signature.asc
Description: OpenPGP digital signature